I hope you all enjoyed that break. We're going to keep the content rolling right along. Our next session is called CISO versus Security Architect, Battling to Secure the Cloud. Our presenters are Amanda, who's the CISO and CIO at Prove, and her senior systems architect, Darren Lewis. I happen to know that outside of their cloud security expertise, they have some fun hobbies. Amanda's a sous chef, and Darren is a pilot of drones. Take it away, Amanda and Darren.
All right. Awesome. Thank you for the intro. It's been a while since we've been speaking. Darren and I have been really busy at a new endeavor, so we're so excited. Thanks for having us. What we wanted to do today was give a little bit of a sneak peek about what's behind things that happen in the cloud security space. You'll often have this dynamic of a CISO or a CIO and somebody who's trying to run through with the business drivers, and then you'll have somebody who's trying to drive the technical side of everything. That can be a quite adversarial relationship. Today, we wanted to tell you what we're going to tell you, which is that it's not adversarial. We have found a common ground, and we're going to tell you how we did that. We're going to tell you what we told you about basically moving from these norms of security and then moving it to the cloud. And then, we're going to tell you how we hope you can use these things in a tactical format for yourself.
Welcome to our session and we're going to dive right in. Darren, we had this wonderful, amazing intro, so everyone already knows who we are, but what I would like to do is probably approach this where we're going to talk a little bit about some things we learned on this journey together, and at some point, we became friends and we started solving for the same thing. We're going to start with a little bit of a highlight of the work journey, and we'll start with Symantec. You and I first met there and we worked together for about 12 years now, and it was four different organizations. This was our first one.
My focus at Symantec, I was a service delivery manager way back in the day, and my big thing was I was trying to manage the security for Fortune 50 companies, but I was trying to do this with business drivers in mind. I was so focused on what the costs were, how to get the most bang for your buck. That was also going to align with what these customers could do and deploy in the time that they did. These large companies have a really difficult time with deployment. My driver was business and making customers happy. How would you characterize what your driver was at the time with Symantec?
I was hired to do mainly threat intelligence at Symantec, applying it both to the corporate environment and also participating in delivery of that threat intelligence to customers. It was a big place, large organization, complicated structure, and it makes a real difference when you're doing security. You need tools and support. At least they got it though. Being a security company, the management and the people there understood what security was and where their gaps were, I guess. But I got to see how everybody else did security, which was the cool thing for me.
Yeah, I tend to look at this in my personal career experiences that I worked at a lot of US government entities where I could see how people wanted to do good security but couldn't get it done, didn't necessarily have the budget. But then in the Fortune 50 realm at Symantec, we saw the people who had the budget but couldn't get it done for different reasons, and those deployment, that adoption for different things. But at this point, security was really still focused on these fundamental concepts of security that we've seen all along. This was before we'd really had a huge adoption that went to the cloud, and so this was all the realm of the prevent, detect, respond, the pillars, kill chain, that hashtag Lockheed Martin 2008. Really focusing on things like we have an end user, we had to store these things on servers somewhere. It felt like we had the moat and we had to put protections in place there and it was not cloud focused, which is an interesting and very different type of doing threat modeling for threat intelligence.
I guess to kind of cap out Symantec, which I don't think we're going to have a lot to say about how we did things in cloud there, because we weren't really driven for that yet. This was the beginning where we really focused on foundational security things that we were learning together. But from a threat intel perspective, I am curious for you, how did you try to focus on the threat model at that point? It had to have all been on-prem things at that point, is that right?
It was all on-prem. Even people were not interested in doing hybrid with some stuff in their data center and some stuff in the cloud. There was just a mistrust of cloud at the point. It had not gotten to the level it is today. We found a lot of people that would buy toys and not know how to configure them properly or just not configure them at all. They were sitting on a ton of hardware and just not getting the job done. Really, my purpose there was making sure that we walked through everything and found any gaps, and it was those gaps that were kind of the reason for being.
This is where you and I are going to have our first argument that everyone's looking for is that, I mean, wasn't it easier to do risk modeling and threat intelligence whenever it was all on-prem or are you just going to say it's the same?
No, no, it was definitely easier. There was less spread. Things were in one place, you knew where your perimeters were. There was a whole lot less SaaS going on, so you didn't have 50 different components.
Exactly. Yeah, it was easier though.
Right. I think the biggest takeaway, I'll say, for Symantec, and we can move on, but I really want to say, at this time, we really watched so many organizations. We've said this a couple of times, but I want to get specific about something here about what we mean about the configuration. You could have a very large retail company that they would have paid for all the bells and whistles. They had great logging, they had great detections, they were really good at preventative, they would work closely with Darren's team to make sure they were focused on threat intel, and everything was wonderful, but they did it based upon what they thought their risk surface attack was the most important, which would be the point of sale.
They were focused on themselves as a retail entity, and they ended up dealing and getting hit with an advanced threat in the corporate headquarters, which they didn't have all those things deployed. It's one of those things that we didn't move to the cloud as much yet, but this was where we first learned the importance of let's be aware of all the egresses and making sure that when we do this surface attack threat modeling, we understand all of the footprints, as opposed to just what you think the most important one is. That was our big takeaway there.
We moved on at the time to a large insurance financial entity, and this was a big one. This was a very different foundation. But as you mentioned with cloud, this is the onset whenever people were still very adverse to moving their data to the cloud, but they had let in the dulcet tones of Microsoft 365. As soon as people did that, you really kind of had a foothold to start talking about how we could move our stuff to the cloud for data in a security purpose. But people didn't want to trust the cloud for security. At this point, how would you really characterize some of the more important security concepts that you got for cloud at this location that we were at together? Because we were there for not long, but long enough for us to start to see the importance of this.
Some of the things that I saw there were in a large organization, it's like steering a cruise ship, where you turn the wheel and then you wait because things don't go very quickly. Even when you know exactly what you need to do, it's really hard to get it accomplished. IAM was really complicated and in that size organization as well, even if you knew where all the pieces were and you didn't know who had access to them, what level of access they had, monitoring that, keeping it together was just a nightmare. We did get to lean into threat intel here though. Being such a big name, they actually were targeted, so it was more interesting from my standpoint, knowing that there were threat actors out there that were really gunning for them. Being in insurance, of course, there's money in it, so it was a challenge.
Yeah, I think this is where it felt like an adoption of really turning the crank in maturation where we go from prevent, detect, respond, and kill chain, MITRE, CAPEC, et cetera. We have these different frameworks in mind, but here is where we started focusing on... We knew we had 365, we knew we were going to move some things to the cloud, and so some of the things that were from the business drivers, we had to have... Your biggest thing you mentioned is about centralization. We had to centralize everything in one place so that we could then standardize and we could then automate. We were never going to be able to accomplish what we needed to do with lifting and shifting, moving anything into the cloud unless we did these three things.
The centralization, standardization, and automation were important. There has to be security at every layer. We had to read that out to board meetings, to the CIO, because we reported into him. We had to centralize the management of the components, which was difficult because we didn't control them. They were actually over in engineering. That's always a really interesting rub when you're trying to do all the things but you don't have the ownership and management of the devices. Redundancy was a big one. This is where BCDR started to rear its ugly head, and, man, wasn't cloud great for that. All of a sudden, we had it built in that we could leverage all of the capabilities of a cloud platform because they had to focus on BCDR. That was built into the whole point of why elasticity and scalability was so important.
Also, deployments were a lot easier. You can spin things up, spin things down, super useful, alerting, notification, all of these things came into play in our very short time that we were at this place. The reason why this was so impactful was because it was right in that precipice when hybrid, when it was an adoption of some things but not everything. As soon as you started to adopt into cloud, you opened yourself up into the chain problem. Third parties become an issue. Their potential risks that they have become part of your risk. That's whenever for each vendor that you start to incorporate and allow to host your data or to move data for you or cache it, et cetera, locations, GDPR was starting to come up. Privacy is starting to come up. It was this great amazing time, and what did we do? We went somewhere else, and we got to experience all of these things somewhere else.
Let's move for Relativity. I don't think we could have any problem. We're so proud of that program that we put together there. I'm going to say what I was attracted to, what we came in there for. And then, we're going to move over to some specifics with you about what you saw with the security program for cloud. I went to Relativity because it was the first time somebody had told me I could build everything I wanted, best in class. They were 100% committed to it, from the board, from the CEO, from the founder, everyone, and they wanted it to be the best cloud security you could have. The data that we would be hosting is the most important data that's out there. It's for government entities, it's for law, it's all of these things, and we wanted to be honoring the data that we hosted in our cloud.
We were built on Azure, and it was all about identity and access. This is where we're going to actually spend the rest of the few minutes here, is really focusing on these cloud concepts that we built out. The focus, for example, when we came in about identity access management, I'm going to get specific because I always love it. People will say these general terms, but they don't give you a really double click on it. Let me get specific for a minute. When we first come in, the people could have access to something. Was up in 190, 200 people could have access to something, and it was the first thing we attacked and said, "Okay. Who has access to what for how long?" And so, Just-in-time became really important for us. We actually ended up setting up our own tool that we created for this that people would get access to the thing they needed for just the amount of time they needed. And then, that was it. No longer were we going to have stale permissions, which is a huge concern with the cloud.
We wanted to be honorable about this data, about how it was being secured. We all wanted to feel worthy of it and that we were doing something we knew that people wouldn't be able to afford and support the way that we did. No one was going to love the data the way that we did., So we created this award-winning tool for Just-in-time. We created an award-winning threat intelligence stream. I'm going to pause there and say we spend so much time here building out amazing things. How do you characterize that relativity security program and what were some of the big things that hit you for cloud besides those two? No, you can mention those two.
Relativity was a little different. We had an opportunity to actually build something almost from the ground up. If you're not aware, Relativity is software for lawyers. It hadn't been a really high profile target for threat actors, and that gave us the time and the focus to be able to sit down, look at security fundamentals, make sure everything was watertight. I had the opportunity at that company to really learn to work with other groups and to get close and in their business, as if you ask anyone there would tell you. A lot of that was around compliance and legal and other groups to find out kind of what they were focused on and what they wanted out of the solutions and get their viewpoint.
It was kind of our first cloud-only company together. I mean, we hadn't done cloud before. As we mentioned, the previous company was starting down that path with a private internal cloud, but really hadn't given any major thoughts to being a real cloud player. We had some learnings, and I think we made a few mistakes. Some of those mistakes were around when to do things. I think we did the right things, but some of them we may have done too early, too late, usually too early. Because once you know what you want to do, you want to rush right out and do it. But often, it's better to wait until it really slots in and the time is exactly right for that. But it was as I-
This was a turning point, I was going to say, between the two of us, because putting you in a position where you could have the candy shop, you could get whatever you wanted from an architectural standpoint, you would design a program and you would say, "I want this," and then I would go and get it. I was like, "Okay. We need the budget for this. This is what he wants to do, et cetera, et cetera." This became this candy shop dynamic. To be clear, a mistake that we made, for sure, we did Splunk too early. We knew we needed that centralization of all the data for alerting, for detections, for the access we were talking about. We knew we wanted to build a lot on it. We weren't ready for it. The reason why is the business drivers. We didn't have governance in place, so we really needed to have more governance about who was going to use it or how much, what was the trajectory of spend.
COGS is a huge issue that you have to deal with with your cloud, and Splunk comes into that as well. I think this is where it was an interesting shift that I went to trust everything that you would say at this point because you never steered me wrong. And so, you would get everything, but too fast because you weren't expecting that. You weren't expecting that to happen that quickly. You said you wanted it and I was like, "Got it, no problem." I should have slowed down and been like, "Okay. I want us to do this." We do that now. We definitely put things through the ringer now, but that was a big learning about when you're building a cloud program so quickly, be careful, make sure you know what good looks like and that you're planning for five years from now, because spend on all of your tooling when it comes to cloud can go out the door so quickly and become ridiculous.
Yeah. It caused another problem as well. That was it caused a great big IAM nightmare getting all of the accounts for everything managed, especially since we were cloud-cloud first. We have all the components in the cloud and all those millions of little buttons that you can press for things in the cloud, but also all the SaaS components together, and who has access to what and what level and how to manage all of that. It just came up so quickly and I think it swamped us. We really did struggle a bit with getting the IAM components right.
Okay. And then, which has hit upon the buzzword that we all know in this industry then. This is also where containers came in. Talk about what you felt with the containerization experience.
Containers were an interesting development. I mean, they've been around for years in Linux. As a Linux guy, I felt at home with them. What I did not find very pleasurable or pleasant was the experience of Windows in containers. I still to this day think it's too premature a technology, but containerization is the way to go. It allows you to use your resources most effectively. They scale automatically, they can scale up and scale down for you. The technology's there and it does the right stuff, but that's another bit of IAM nightmare. Again, managing all those permissions and people and having visibility into the container, which I think security-wise is still my biggest concern with them, is being able to see what's happening inside the container. I don't want to wait until something breaks out to find out about it.
I think this is where I feel like when we left Relativity and we moved on to where we're at now, we feel like this is the fundamental security concepts that we had over the careers we had before we got to Symantec. When we got to Symantec and we watched the Fortune 50 and all of those different things and major breaches and how they came about and so on, it was the cusp of like, "We're going to look at cloud." Then we went to an insurance financial company that definitely was like, "Okay. We're interested, but it's going to take us five years to get there." It was painful. You have to feel that pain. And then, we went to a company that was rubber banding us, and we went so fast and we shot past everything. These basic things we focused on in terms of the identity access management, making sure that we had good hygiene there, that we had those fundamental security concepts of prevent, detect, response still came to play because we always needed to have amazing visibility.
Even with containers, we still struggle with the amount of visibility we could get from a forensic standpoint, but this idea of we still have to have the security fundamentals in the program, they're just different. And so, we still do threat modeling and surface attack reduction, but differently. We accept that we're going to have third parties and we're going to have the supply chain attacks, methodology we have to concern ourselves with. Let's accept that this is a threat, but let's mitigate it with those things like defense in depth that we know very well about how we're going to do that. Again, this is where we also transit and so much effort in the backup and recovery policies. And then, this is the one thing I noticed when we came to Prove as we transition to that part of the story, backups. More and more cloud, more and more backups, more and more ability process to make sure that we have things in place that we can do that.
Let's talk about cloud at Prove. Everything here was about cloud migration. I came in and found out there was a data center and there was a cloud and we were hybrid as a product company. I immediately was like, "Okay. Well, we got to get rid of that." I'm not a data center company, I'm a product, and so I need everything to be in the cloud because I need those SLAs. I need that 99.95 or et cetera, or 99.99. I need this to be my business driver. Super reliable, super capable to be innovative, and then secure by default. So, I need those things to be resolved behind the scenes immediately and not to take things down and have downtime. For you, we came to Prove together, how has this been for you with this cloud program?
I think it's been like Relativity than any of the other organizations I worked for. I look back, and believe it or not, it's been 28 years since I started doing this security stuff, so it's been a while. But we're in the background of financial transactions here. We're still not really well known by threat actors. I think it's very much like Relativity was where until you get noticed and someone, figures out that you're a linchpin, they're not targeting you. But I see that changing soon and probably all at once. We've been able to build here though just as we did at Relativity. That kind of makes work a real joy for me. We're well underway to be a threat-intelligence driven, security-first company. It's kind of the world I live in and live for, and it's just a pleasure to see things come to life and know that you could have a real positive impact on a company, it's culture and how the customers see you.
Again, company moving to a cloud first environment. Biggest difference is that security responsibility model. We have some, cloud provider has some. That makes it difficult to draw a fine line with some of their products and services exactly where your responsibilities are. We have a ton of SaaS products and services. Again, always cloud-based and supply chain attacks make it harder to secure. And we have the same IAM problem where we have data center in the cloud and soon hopefully just cloud only. It's a beast. You have to get all those fine grain permissions control with all the people involved and know who has what and not let permissions pile up on anybody, and at the same time, give everybody what they need in order to do their jobs.
One thing that's been a transition, and we're moving towards a conclusion here for a couple things because we've got some questions, but I want to say one thing that's been a real transition that took place between Relativity and here, I'll pivot this actually into our conclusion. One of the things people expect is that you and I were going to be adversarial. You're solving for how to do things the right way, securely and technical way. I'm trying to solve for the business drivers, but in a secure way, of course, because my background's all cybersecurity. But the reality is I have to answer to the board, I have to answer to the executive team, I have to answer it to my P&L. I got to answer to all these numbers. How do I make these things work with what we have?
One thing that we experienced at Relativity that was a huge helpful way to make this not adversarial is I just told you what I was solving for. I would just give you the visibility and say, "I'm solving for this." And so, huge impact was giving you access to compliance control language. Whenever someone is trying to solve for a contract for a customer or a compliance control, I always ask for you. It's a joke now in this company where they think you're my Pokemon, because I throw you at things. I'll throw a Darren at it because they'll say, "Well, throw a Darren at it," because you learned to come from a path of, yes, I'm going to tell you how you can do this securely and I'm going to give you my recommendation. The probability is Amanda's going to back me up no matter what I say, because she trusts me and we've had so many years together. But this dynamic of know what we're solving for shifted so many things in this dynamic for the security program, the cloud, what we're solving. All of it was just so much difference.
Now, I think I've been trained, and I've learned so much from you over the years, that whenever I have to push, push, push and when I shouldn't push, but there's some best practices that I walked away from. You leaned into compliance and contract language and there's nothing I wouldn't trust with your interpretation from either of those. You've gone to me and definitely taught me. There's a few things, like being careful about who I choose as a service cloud provider. This responsibility matrix that you mentioned earlier, the importance of understanding whose responsibilities are what and who's going to be accountable and making sure we watch for that, focusing on that hardening for the security access, the identity access management, and harden what we can and remove the things that we can so that people don't have the capability to be a higher risk audit.
Wow. In Relativity, we built into all the audit logs whenever people did access and it was wonderful. You built that into the product, and it was just a really great thing of beauty. And so, I think there's a certain amount of having this architect behind everything that says, "Great product, great thing you're doing. Here's how you can do something now that's going to help your cloud program later for visibility and detections that we're going to have." And then, you've always taught me keeping everything encrypted both in transit and locally. Those are my big things that I took away from cloud best practices that are just... They go toe to toe every time I'm in a board meeting or if I'm in an exec meeting. If one of those concepts come up, that you've taught me well. So you, I'll say, what are some of your tactical takeaways that you would give for people from all these programs we've been with?
Yeah, I'll be quick. I know we want to get some questions in. Getting used threat intelligence, data that's relevant to your organization. You can't protect yourself unless you know what's out there and what's coming for you. Bring in people and train them up. I know that they're seem to not be enough people in the industry today to fill all the slots available, but there really are. You just got to quit looking for magic unicorn of security and instead invest in somebody with enough basic knowledge and skills to make them a security superstar. Finally, make sure everyone in your organization works for security. Make it a culture, make sure everyone is truly involved and not just doing mandatory trainings.
Yeah. Awesome. Well, I appreciate that we've had the time to talk about some of the tactical stuff here. We've gone through a long journey. I don't know, I think we've argued about things, we still argue about things at times, but we've always come from a place of we just want to do an amazing job and we want to be proud and honoring what we've got. But this last thing I'll say before we move to questions is really that we just don't want to put a $100 lock on a glass door. We want to make sure we're doing the best thing with the best things all the time, that are going to contribute and make it a really solid program. That takes thoughtfulness, and it takes people and talent like you. I've always appreciated you, so thank you, Darren. All right. Karen, I'll open it up. I think you're coming on for some questions.
Thank you both. It's great to see the dynamic between the two of you and all the experience you've had together. Thank you for sharing with all of us. We do have a ton of questions. When people hear about real life experiences, they get thinking about their own and want to learn more. One thing, one question that came in, from Jack, is, can you tell me more about metrics and where they come from?
Yeah. I can cover that one actually, because I'm the one that has to report them, although Darren puts them together for me. It's a fun one. Over the years, Darren and I have put together kind of a compilation of things that we think are the most important. I've learned that the metrics is really about, we educate others and that's our job. I educate the board, the exec team and so on and my peers, and say, "These are the things for security maturity that I care the most about for our cloud, for our product, for our company." It's a combination of cybersecurity framework, ISO 27001 controls, as well as SOC 2 controls, and CMMI, a maturity scoring, that you want to know where you're at and where you're going.
The highest level, I could say, is that we really focus on threat intelligence, which is normally the area, it's like car insurance. No one wants to spend money on it but we do, because we believe that that prevention is the best type of security. Obviously, you want to have a good response system, you want to have really good detection, but you really need good threat intelligence to get in front of it. We've always done that because Darren's taught me that. Detection and analytics is kind of a big bucket as well with one of the metrics. Risk reduction, have you identified all your assets, what's your asset management look like, how are you eliminating risk associated with your third party providers, and so on.
Forensics and response, like I said, you're always going to have to respond and you really hope you can get good forensic data about it, but you won't get it if you didn't set up for it. If you go in and you look for those logs after the fact, it's not going to be there. And then, product security, for us, because we are a product team. We really do focus on these high level buckets. And behind that, the metrics all come from a compilation of what metrics work best for you. We're a product security. We care a lot about our maturity and our product security. Not everybody does. Some people are going to be focused on an old brick-and-mortar kind of situation. All right. Next question.
Great. I think we're out of time. We had some great content here and there are more questions. Our presenters have agreed to stay in the chat and answer questions, so keep the questions coming in. They're going to answer questions in the chat, and stay tuned for what's coming next. Thank you both.
Cool. Thank you.