On this episode, AWS Security Practice Manager, Chad Lorenc, joins Matt to talk about Cloud Security. Chad has spent over 20 years building and implementing security programs for numerous organizations, ranging from global Fortune 500 infrastructure teams to billion-dollar financial institutions. He has previously served as Senior Infrastructure Security Architect at Keysight Technologies, President of Montana Chapter, and Information Security and Risk Management Infrastructure Architect at Agilent Technologies.
Today, Chad talks about the roadmap to security maturity, security best practices, and benchmarking assessments. Why doesn’t AWS necessarily hire people with Cloud skills? Hear about The Five Pillars, when Cloud security goes wrong, CISO reporting Cloud security, and Chad’s formula for personal growth.
· [01:24] A bit about Chad.
· [03:13] Chad’s role at AWS.
· [04:03] Transitioning to AWS.
· [08:30] AWS doesn’t hire for Cloud skills.
· [10:41] Where to start.
· [13:54] Assessment benchmarking.
· [15:09] Getting to security maturity.
· [19:17] The Five Pillars.
· [24:21] Cloud security gone wrong.
· [32:14] The Cloud Center of Excellence.
· [35:15] Reporting Cloud security maturity.
· [40:54] Chad’s formula for personal growth.
· [44:50] Chad’s words of wisdom.
· “There’s no algorithm for compressing security experience.”
· “Figuring out how to integrate Cloud into your operational processes and technology is key.”
· “The key to growing fast is to prioritize ruthlessly.”
Resources:Secure applications from code to cloud.
Matt Chiodi (00:14):
How awesome is it that we are able to get Chad Lorenc from Amazon Web Services on the podcast? It's awesome when you get to speak to someone who is actually living in the giant that we all know as AWS. I thought we would take this opportunity because it was interesting back at Reinforce in 2022; Chad gave a talk on "Crawl, Walk, Run, Accelerating Security Maturity". And I really wanted to dig into that talk because I know a lot of you are not able to be at Reinforce. And so as usual, I start off with a little bit of his background, but I really dig into his role and how he helps customers on AWS become more secure; I hope you enjoy the show. Chad, welcome to the show.
Chad Lorec (01:07):
Matt Chiodi (01:09):
Alright, let's jump right in. I've never worked for AWS but I have worked around the AWS ecosystem for the better part of a decade. I'm super interested in how things work, therefore let's just start right at the top. Tell us a little bit about your role at AWS and color that a little bit with, if you think over the last six months or the last year, what are you most proud of?
Chad Lorec (01:34):
I've been at AWS for over two years now. I have had a couple roles; I actually came in as a Senior Consultant, therefore I had an opportunity to work directly with customers as a builder. And then I transitioned into a manager role, which was kind of my goal all along, coming into AWS. Right now I am managing 29 people, and that is actually probably one of the most fun things I've ever done. I've managed some offshore teams that I really enjoyed managing, so I knew I enjoyed managing. However, it's just the quality of people and the opportunities and the culture here to be builders of innovators is really exciting. They slice us out of your time to dive deep and play within our free sandbox that we have, and this is probably our least politicized, most valuable employment opportunity: the government unlimited sandbox for consultants to build in. Therefore, we've gotten to build a lot of really cool things as a team, and that's probably some of the most fun things I've done. Probably my most proud thing that I enjoyed was speaking at Reinforce and some of the opportunities that AWS gave through that. There are a lot of fun, and exciting opportunities that throwback to the old days when the old guys would talk about how cool HP was or back to the IBM days when they were innovators. Getting to be part of a culture like that is super fun.
Matt Chiodi (03:12):
What is your role now? You mentioned that you do consulting and managing, however, what is your team focused on doing at AWS?
Chad Lorec (03:24):
That's a great question! We are a part of the commercial professional services team for the US West. Therefore I manage all the US west region, and our focus really is removing security blockers for the cloud. We do that through mostly collaboration with security teams; in which we are trying to help upscale or accelerate them so that they can have the confidence to move their production workloads in.
Matt Chiodi (03:54):
That's a huge challenge which I will be asking a little bit about later on, but I want to dig a little bit more into your background because I think there's a lot of people who want to get into cloud. They want to get into cloud security, and I noticed that before coming to AWS, you were at a company called Keysight for about six years before joining AWS. Therefore take us back a little bit to what was it that actually led you to want to join AWS and what was that transition like from Keysight.
Chad Lorec (04:32):
It's been a fun circular journey. I started consulting with HP on their Cisco split off of a company called Agilent. Therefore when Hp bought Compaq, they spilled out all of their life science type of workloads. And so they moved out with this life science and testing business, and the life sciences took off. I left Cisco and went to work for Agilent, and then about six years into my Agilent career, they said, "Hey, we're thinking about spinning off a company that will be a Fortune 600 level company out of the gate, and we're going to break off the life sciences from that test and measurement." Test and measurement is a lot of geeky stuff for example, testing your SB port or testing your iPhone to see if it's radiating your brain. Testing radio signals for the government so that you can help do anti warfare kind of stuff.
Chad Lorec (05:41):
Therefore there was a whole range of spectrum but all test measurements at Keysight. And it was a really cool company, I would say some of our IOT pieces that I was helping to secure drove me into the cloud as we were starting to move more and more data out to the cloud. And then we bought a really cool company called Ixia Breaking Point and we had a lot of stuff in the cloud. And so that was my journey; believe it or not, I also started in the cloud. I built my own cloud back in the day when we called it ASP; I built an ISP and did an EMC storage and security out of the cloud using configure Soft, who is now part of the VMware platform for some of their security management. Therefore, it came full circle, but I have always been interested in the scope and scale of the cloud, and I really wanted to figure out how to get deeper into that; however, I was in a limited role. And I think a lot of our customers find themselves in a lot of security practitioners where if clouds are these big overwhelming things and you're trying to figure out, how do I get my hands around this? And they do all the day-to-day activities that they're trying to pull off as a security professional or in my case, as a Security Architect overseeing all the new things that we're rolling out.
Matt Chiodi (07:05):
What actually led you to join AWS and what was that transition like? AWS is known as being a result oriented, and a very driven company. Therefore what was that transition like and what led you to join AWS?
Chad Lorec (07:20):
It was honestly some of the leadership principles; I was interviewing for CISO, director level positions. AWS actually reached out to me and I thought, well, it's AWS, you've got to at least try. I knew I was really interested in the cloud from some of the things I'd done at Keysight and wanted to fully get into that. And in the interview process, I just really realized that their culture of diving deep, delivering results and inventing & simplifying really fit with how I actually defined myself. And I said, oh, this might be a fit, right? For a person that likes to drive fast and do cutting edge technology and those kinds of things. Therefore as a result of that interview process, I did talk to one of my mentors who was my boss at the time, and had come in from a CISO role from a big credit card company. And so I had an opportunity to grow in place and wrap my head around the cloud in a way that I hadn't had an opportunity before.
Matt Chiodi (08:27):
That's awesome! I noticed that on LinkedIn there was a post that you had back in January of 2023, and I found something interesting that you said in terms of what Amazon looks for when hiring, at least for your team; you said this, "A secret about my division in AWS, we do not hire for cloud skills." Unpack that for us, how is it possible that the leader in cloud does not require cloud skills, or at least for your team?
Chad Lorec (09:04):
That's a great question, and I think it's a secret that most people disqualify themselves often by. And the reason really is if you look at the quote that I put in there from Jeff Bezos, there's no algorithm for compressing security experience. You can't just gain experience out the door, and what we found is a Security Practitioner can pretty easily learn a new technology, I think more than any other person in It, as Security Practitioners, we're required to dive deep into a new technology, figure the ins and outs, and then secure it. And so that mentality really serves security people well, therefore, when you come to the cloud, and when you have a focused time to just focus on one security element, it's pretty easy to upscale you on security. However, if you teach somebody a bunch of cloud security skills and they don't have the security element, we found a gap because the reality is no matter which side of the table I sat on, whether it was the VAR or whether I was the customer, I realized very quickly that people aren't looking for a product expert. They're looking for a security expert that can identify opportunities with their product, and so really shifting to what the customer was looking for and working backwards from that, which is bringing some security professionals that can help me understand how to take my security paradigm that I'm living in now and bring that into the cloud.
Matt Chiodi (10:41):
One of the biggest questions that I often get from my clients at Ian's research, maybe those that are new to the cloud or finally catching up with their development teams who've been in the cloud for sometimes multiple years, is, where do I start when attempting to secure the cloud? And sometimes I'm surprised with the question; the company that it's coming from, because I was like, wow, I'd have thought you would've been on this for maybe years at this point. Sometimes it's coming from a more heavily regulated industry, which explains why they're sometimes slower to adopt than others. However, I'm curious, and I'm sure this is a question that you probably get daily, but how do you answer that question? Where do I start when attempting to secure the cloud?
Chad Lorec (11:27):
It still goes back to some of the basics, it's understanding why are you trying to get into the cloud? What are you trying to accomplish? And so there is a certain amount of a plan where you understand that as a security person you're trying to align to your business and why they're getting to the cloud. With that it helps you to understand maybe what you're trying to accomplish as a security professional. And there's a number of different angles you can take from compliance to driving down risks and top through those different maturity models. However, the first point is to really understand where your business is coming from. As soon as you understand where you're coming from, you're going to want to do an assessment and set a baseline. You may be assessing against a compliance standard, you may be assessing against a best practice. Or you may be assessing against your controls on site to figure out what you have in the cloud currently. And so that first assessment where you can set a baseline is really the key, because otherwise it's this big ambiguous thing that you can't tackle. The reason I suggest assessment is until you assess, it's pretty hard to know where your pain points are and where you want to start. I do know and I can talk through the journey. You're going to go in and you're going to do an assessment and then you're going to go, wow, there's no centralized control, what am I supposed to do? And then all of a sudden talking about control power and service control policies and how you build a paradigm where you have a central management structure makes sense, but sometimes you have to get in there and assess it and go, oh, it's like a million accounts all over the place, what am I supposed to do with this before you understand the value of some of that. We see customers go through that maturity as they go, "I need some central control, I need some monitoring. I'm going to need an IRT plan, or I'm going to need vulnerability management." They go through a pretty natural progression we find but you can't drag somebody through the process. They have to assess it themselves, wrap their brain around, Hey, what are my pain points and gaps? And then start coming in with answers. Otherwise, again, it just looks like you're a vendor throwing tools at somebody, and that doesn't really help anybody, we get enough of that in our industry.
Matt Chiodi (13:52):
One of the things that I've pointed people to is, there seems to be a number of frameworks that are out there. Is there one or two that you can suggest, or maybe AWS has their own? Where do you typically point people to? Let's say that they say, I'm not ready for an assessment yet, I want to be able to do my own assessment, but I'm not sure where to benchmark off of. Is there something that's go-to for you?
Chad Lorec (14:19):
I definitely recommend AWS fundamentals best practice because that's continuously updated. It's the most current one usually, however, from a tool standpoint though, I would recommend Prowler, and it’s free. It's a quick and easy way to do assessment. There's a number of tools out there, however we find Prowler to be one of the easier ones, and then if you want to ramp it up, it's got some nice options for ramping up. However, that's actually how we assess even as professional services, and we're going to come in and we're going to ask to run Prowler. It gives you a good baseline before you start pulling into native services where we can do a lot of baselining. Therefore, if you're looking for that snapshot assessment, Prowler is probably where I would start.
Matt Chiodi (15:07):
You mentioned that Reinforced was one of your highlights from the last couple months. I was looking at your talk from 2022 that you gave, and it was called "Crawl, Walk, Run, Accelerating Security Maturity". And so building off your previous answer on where to start, how can security teams move from the tactical low-hanging fruit type of things like enabling 2FA to knowing where they actually sit from a maturity perspective?
Chad Lorec (15:37):
There are two standpoints, you've got some people that want to say, give me a roadmap and I'll just build it, and then there are other people that say, I'm going to keep on blocking and tackling until I get there. And there can be a case for either way to get to security maturity. The crawl, walk, run was me looking at my small kids; you've got one that falls out of mom and starts running and he's slamming into the walls. And then you've got the other one that will worm and he won't even crawl, however, at the end of the day, they're all standing upright humans walking around. They have reached that maturity through that iteration process.
Chad Lorec (16:21):
That's where I would start, it's not about perfection, and you don't have to do it all right out of the gate. There are a lot of opportunities in the cloud to grow and iterate. However, with that, there are some models in place, for if you like, man, I need something to grasp onto, and there's a few ways to think about that. One is, Hey, I just want to align with best practices. Therefore, we have an entire best practice document for security, which is our security reference architecture. It's a great place to start, it's really popular, and it is end to end. And so that can also be overwhelming, but if you're architectural minded, it's a great way to say, okay, this is what good looks like. However, if you're a little bit more security minded and you're like, I just want to drive down risk, tell me the first things I do, the security maturity model is another great model to start with. Then you will think these are the first things I do, and these are the easy quick wins. However, that's the chipping away at it piece; you've got the big bang, and you got the chipping away at it. I really think the fastest way is to try to align yourself to your business, it's a little painful upfront and it's a practice that we're not always good at as security professionals. However if you can figure out how your security enables business objectives, then it becomes a much easier story as you feed it up the chain, as you ask for funding, as you try to get the training and some of those key components that you really need. Therefore, instead of saying, I want to put up a bunch of guardrails and SEPs then people are like, what are you talking about? You might as well be speaking Greek. To be able to go to your business and say, Hey, I want to build a set of guardrails around an account so that developers can quickly develop and innovate without creating risk for the organization. Well, as a CIO of CSO, I can buy into that, or I want to implement an IM strategy that allows instant provisioning and access but still creates an isolated environment where they can't impact other business production workloads. Those are things that a CIO, CSO, or your board of directors can grab onto and go, yeah, I understand why I'm investing in this. If you say I want to build IAM, or I want to build guardrails, you might as well just be speaking a different language. Some of it is learning to talk the language and sell it, and that's going to allow you to tackle bigger pieces and go after a more foundational structure as we define five foundational pillars in our practice that are the first five pillars you should tackle when you're trying to tackle cloud security.
Matt Chiodi (19:17):
What are those five pillars? I'm curious.
Chad Lorec (19:20):
IAM is the first one; it is so foundational and it is a key component of your edge in the cloud. I think that's becoming true throughout all of it, but everything accelerates in the cloud with security. And so IAM is rushed to the front. Threat detection is another one that we push, understanding how to get your threat detection in the cloud is different. You don't just put in a firewall and call it good, right? There's a little bit more caveats to it than that, and so understanding, hey, how do I get my threat information? Where does that get collected, and where does it go? And then right after that is your incident response. How do I get that threat detection into a sim, into my soc, or into my processes? And then how do I do investigations. Therefore the third pillar is that incident response. The next piece is unique to the cloud in my opinion. Data protection is something that's really challenging to do on site, go to the Oracle database admin and ask them if you can encrypt the database if you don't believe me. The cost and complexity of some of the data protection strategies on premise are pretty high and the risk return is probably not worth the cost. That all shifts in the cloud, and so data protection becomes one of your front end strategies, in fact, we just announced it last week. By default, your S3 buckets are going to be encrypted with AEs 256; therefore no cost and no performance impact of encryption. It's an easy win, and it's a tool in our tool belt that we're not used to using as security professionals. Therefore that's a huge one that is really valuable to start thinking through that data protection element. And then the last piece kind of lands, this is where every security person wants to start with the infrastructure protections; where do I throw my WAF? Where do I throw my firewall? However, in the infrastructure and we're actually even growing and iterating with our customers, we currently have things like DevOps embedded in that and building a pipeline. You're going to see some of that come out, and some of our application security WAF is embedded in that, and you will see us start to iterate and separate that out.
Chad Lorec (22:03):
Container security is another piece that it falls into; so that infrastructure piece has grown quite a bit. And we're going to continue to tease out, and iterate as the industry grows and customers grow. However, that's the fifth and somewhat fat pillar. I am in that pillar; the fat pillars that squeeze everything in. Those are the five steps we take or the pillars that we kind of take from mentality, and that aligns all the way back to cloud adoption framework and some of the reference architectures that your CTO or your cloud architect is using. Therefore it helps to create that common language and that common flow through. We do a lot to try to help culture and organizations align in some of their communications as they build out the cloud too, because that is often one of the pain points.
Matt Chiodi (22:55):
It is, I always tell people that moving to the cloud, which many most organizations are already there or in the process of it. So much of it is more philosophy and more people than just anything else. I'm sure you've seen that probably more than most people.
Chad Lorec (23:13):
People processing technology is like everything in the cloud, it's all more extreme, so to speak. You really have to get all three of those pillars moving together, and that is where it breaks the technology isn't actually the hard part of the cloud, in my opinion.
Prisma Cloud secures infrastructure, applications, data and entitlements across the world's largest clouds, all from a single unified solution. With a combination of cloud service provider APIs in a unified agent framework, users gain unmatched visibility and protection. Prisma Cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan infrastructure as code templates, container images, server less functions, and more, while gaining powerful full stack runtime protection. This is unified security for DevOps and security teams. To find out more, go to Prismacloud.io.
Matt Chiodi (24:20):
What story or stories can you tell us in terms of cloud security gone wrong and maybe what was the root cause. Was it a lack of budget? Obviously, get in details and be as specific as you can be, because a part of what it is, is I think listeners always want to know what it was. And I think a lot of times people just assume it's always a lack of budgeting. That's probably what it was, what's your side of it?
Chad Lorec (24:54):
It's rarely budget, however, I think that's a good call out. I have three phrases that tend to come out in the process of a train wreck. The first usually starts out with something like we are a dev friendly culture. We give everyone admin, we trust everyone; that's how we grow, and that's how we innovate. Growing, innovating, and scaling are all things that hit home with AWS. We love development and all that, but understanding how to shift from, we're a dev friendly culture to, hey, we know how to build a foundation with appropriate guardrails so that we can grow and experiment in a safe, containerized way. We understand the purpose of having tiered accounts, and this is something that's always been hard on site. To have a test the dev, a UAT and a production; that gets a lot simpler in the cloud. Again, those are another one of those security paradigms we've struggled with because of cost. A lot of that disappears in some of the ways you use cloud when you're paying as you go, you're not paying to manage an entire server infrastructure just for tests. You spin it up, you test it, and then you spin it back down. Or maybe you don't even need to be server less and you're doing server less, and you have a lot of pay as you go. And so now you're just paying for the testing that return on investment becomes a lot more meaningful than this giant sunk investment. That's the first shift that we look for, and that's kind of the first pothole and that aligns obviously strongly to some of that IAM culture as well with that pillar. It's understanding that a dev friendly culture doesn't mean we're all admin and we all use root keys and everything's fast and easy.
Chad Lorec (26:53):
You make it fast and easy, but you put guardrails around it to make sure that people don't hurt themselves. It's like trying to roller skate on the edge of a cliff, but that's probably not advised. You're eventually going to make the mistake so you put up the guardrails and the protection. The next thing is, and this was actually how I smashed myself into the cloud, we're just going to replicate what we do on Premise. From a security standpoint, this is so attractive, you've already built in your flows. You know your IRT process works, you know how your logs flow, you know how these tools will report, and you know how to parse them and how to assess them. It's so much simpler and you know how those controls align to your compliance and your frameworks.
Chad Lorec (27:44):
Therefore, I totally get that beautiful idea of we're just going to replicate what we do on Premise. Unfortunately it doesn't work that way, and so that's the second phrase that we hear that usually says, oh boy, we have a train wreck coming. And it's not that all tools don't translate, some tools translate really well, and some really don't. Sometimes the mental aspect of, "Oh my gosh! I'm going to have to figure all this out," we make it bigger than it needs to be. The cloud is so flexible and adaptable, you can change a lot of things to fit easier than you can with your traditional infrastructure. You can't manipulate your firewall very much, however, you could pretty much manipulate everything in AWS from a code standpoint. And so understand that there are a lot of things set up and you're not the first customer running into it. Therefore, there's a lot of quick, easy wins. It's just overwhelming in that first grasp, so being able to sit down and really do a thoughtful assessment, and understanding, hey, these native tools are going to be faster to implement, they're going to be updated quicker, and they're going to be more meaningful than trying to drag an on premise tool into the cloud that doesn't really know how to work or function there. Or maybe even in my case, disabled some of the functionality of the cloud in the early days, so again, that's a part of aligning with that business objective, understanding that, hey, if I move this security tool into the cloud or these set of controls, I'm going to be working against the business objective. You're going to end up losing that battle and you're going to waste a lot of time. And that's a personal stub toe of mine.
Chad Lorec (29:33):
In the early 2000s, I tried to move to the cloud. And so the third one is, if we created a cloud team, we don't need to upskill the organization or change the culture. If you create a cloud culture team and you throw them over on the side and they're out of IT, or a subset of IT, that doesn't usually work. Especially from a security standpoint, you would want to do an incident response; does that go to a cloud guy? Is that cloud guy trained on incident response? Does he have access to any of the soc pools or sim? Does he understand what to do if it's calling inside? And what if inside's calling in? If you break that, you break everything, and so it's so much harder. And this kind of touches on that people process technology pain points that you were talking about. Figuring out how to integrate cloud into your operational processes and technology is so key versus just creating it on the side. And this is because then you will just be creating power bubbles, struggles and gaps. And the reality is, if I'm a Palo Alto Firewall Engineer, I want to know how to run my firewalls here, but I also want to understand the firewalls in the cloud. And I want to understand how that data flows through my panorama, and I want to understand how that goes to the soc. breaking that apart, you break all that intelligence, and now you've created a bunch of disconnects in your organization. And so something that we definitely try to avoid is you're the cloud team and you're completely different and we're going to have a three week change management process and you're going to be working in the cloud. Those two things don't really work together, that's the old school change management to the cloud. Therefore, there are a lot of those pieces that we run into, and the perfect disaster is, hey, we've got a dev friendly culture, don't worry about it, give everybody access. We're just going to replicate what we do on Premise because we want the easy button and we're going to isolate that team because that just sounds simpler and they're going to function separately and they'll be the cloud team. When we hear those three in combination that usually equals the customer that's in for a lot of pain and struggling. And the reality is they end up having to reverse all those stances before they're successful.
Matt Chiodi (32:06):
I've seen all three of those so I can attest that those are all real. The last one though; having a cloud specific team, I want to double click on that. And this is because I have seen at a number of organizations where, and most of this was probably in the last three to five years I haven't seen too much of it recently, but what I saw a lot of is, they would launch some kind of cloud center of excellence; some kind of COE found cloud. Because usually these usually were in organizations that were pretty large that have a very massive on-premise footprint. Maybe they had a lot of legacy apps and they've got challenges with culture change. There's something as big as cloud, even though cloud is not new, and I've seen them create the cloud center of excellence where they take a number of people from IT, some people from security, and maybe somebody from legal, and they essentially create this mini company. Then they try to mix cloud in there and they try to do things that way. Why doesn't that approach work? What have you seen? It sounds good on paper, right?
Chad Lorec (33:21):
Yes, well it's a great birth, right? You're the baby, you're learning to crawl; that's a great way to learn to crawl. The problem is, if you don't have a plan to exit that phase and integrate into the organization; the IT, then it eventually breaks. You eventually get big enough and you're doing complex enough stuff that you can't rely on a single security person to be your bridge. And I'll take the security because that's where I live most of the time, Bernie. That core security person cannot be the bridge to compliance, to security, to incident response, and to managing all those things. In fact, most of the time they don't even have the access to the correct systems anymore on the security side that they had. And so now you've got this broken parallel, but we see it all through the organization.
Chad Lorec (34:09):
You don't want a cloud database team and an on-site database team and them not understanding. You don't want a storage team in both, you don't want all these teams in a permanent state of disjunction. And so I think that's a good best practice for birthing something, but that can't be your end goal or you'll eventually get stuck. And to answer your question, the end result is the cloud team gets further and further isolated from corporate IT and the further isolated they get, the less valuable they become. And then you end up with this orphaned organization that's considered not successful because they're not integrated into the day-to-day processes. They'll struggle with compliance, they struggle with incident response, and they struggle with basic hygiene walking and tackling. All that knowledge is still sitting over in your organization and you haven't upskilled them to be able to bring that to the cloud.
Matt Chiodi (35:15):
One of the things that I've, I've been asked about, and I'm curious if you've worked with this is just we talked a little bit about cloud security maturity. One of the things that I have been curious about is what have you seen work well in terms of rolling that up from, let's say if there's a cloud security team rolling that up through the CISO and enabling the CISO to be able to report that then at the board level. What have you seen work well in terms of reporting out that maturity?
Chad Lorec (35:48):
This is how I would start, if you have the CISO; you have one of the key cloud stakeholders that's often left out of the equation. That really is one of the key successes to cloud implementation; it's having your CISO on board and having that top down direction. As far as a CISO reporting up the infrastructure, again, I think some of the business objectives are really key to defining how you're enabling the business. And so that security is not viewed as a blocker, but in viewed as an enabler, but also being able to communicate that there are costs disassociated. Sometimes we get in the cloud and it's cheaper, the cloud is cheaper because you don't do security, the cloud is cheaper because you leverage some of the scalability and benefits and only charge for what you pay for.
Chad Lorec (36:44):
It's not because you ignore the function, but understanding that bringing the security along and helping to understand that these are the security pieces that go and play with this kind of enablement and being able to have that talking point. However, some of the other traditional means that we've always communicated as CISOs, are aligning to CIS or NIS if those are your internal controls, and if not using AWS foundational best practices. And all of those can be collected and reported up through security hub, which is an AWS security hub, cloud native tool. However, there are also other tools out there that do that. And the one thing about the cloud is everything happens faster in the cloud than it does on Premise. And so if you're not a native tool, you have to be a tool that can respond. You need minutes to your updates, they need to be measured in minutes, not hours or days in order to stay in front of that and keep that data relevant. And it also needs to be an active automated tool but you absolutely can use that tool to help understand your risk, but one of the other things that I love about that is then using, and this kind of goes to the board reporting too; starting to funnel down some of that and shift it left the DevOps whether that's removing all the people from your environment and forcing everything to go through pipelines and running co-testing tools and liters where you can show that you are looking at libraries and dependencies. And ensuring that I'm not injecting code or having code injected into my environment and removing people out of the environment. Doing some of those things they will become our traditional funnel points. If you can funnel everything through a pipeline, that's a great place to collect metrics from a security standpoint. Also I'll use Security Hub as an example, but there are other tools that do this. If you enable the security hub centrally, all the reporting flows up to a central desk where it gives you access across all your AWS. And this is the big selling point that everybody gets excited about, but as professional services, what we get excited about is because it also pushes it down. And so now I can say, "Hey, you own this dev account, check your security hub dashboard every week and it's going to tell you that last push that I did just created seven vulnerabilities." Developers want to work with code too, we don't give them enough credit as security people, but they want to write good code too. Therefore if they have a meaningful feedback loop and mechanism that they understand, whether that's static code testing, more dynamic testing or cloud posture management that they can go look at, click through and say, "Okay, I understand that I probably shouldn't print out terminal everywhere," that makes sense. "I was doing that in dev, I didn't think about taking that for production, I could take that out." Those kinds of educational opportunities upskill your dev team, but they also can help you catch a lot of those behaviors earlier on. And so that's another really powerful metric, it shows that not only did our security posture get better, but that security posture is dynamic and we're catching those and shifting those left. And so as a CISO you want to be able to show that I'm upskilling our workforce, I'm helping to change the culture. I'm reaching outside my security practice and helping developers or helping other teams to drive some of those security practices and skills deeper into their groups.
Matt Chiodi (40:51):
I love that; that's great feedback. Now obviously anybody who's working at AWS; things are moving fast. You guys are known for constantly innovating, and never standing still. I think it is something that Jeff Bezos has said in the past. And so for you, Chad, when it comes to personal growth; staying on top of what's happening, and staying sharp, what's the formula that works for you?
Chad Lorec (41:16):
That's good, like I said, AWS culture was a good overlay for the way I liked to function. And so a lot of these things have been practiced throughout my security and professional growth. One, I still always put family first, sometimes there's this idea that to grow fast you have to sacrifice that work-life balance. And I often challenge that even with my own people. I really believe the key to growing fast is to ruthlessly prioritize and understand that your time is the most valuable asset and ask your boss to prioritize for you. And there are a few things that that comes down to, one, you have to know what your superpower is. You've got to figure out where you can contribute in a way that is unique that most others can't.
Chad Lorec (42:12):
And so we do a lot to try to discover what your strengths are. You don't want a toolbox full of hammers, you want a hammer, you want a screwdriver, and all these different tools. So instead of trying to be what other people are, figure out what your unique contribution is and then you're not trying to work millions of hours to be somebody else. Another thing is automate, automate, automate; if you're doing a task that you can automate, spend three hours to automate a 15 minute task, because if you're doing that 15 minute task every week, that payoff is a lot faster than you think it is. Not to mention you can then usually scale that out to other people. Another thing I often do is mentoring, if you're doing a task and you've mastered that task to the point that it's boring, you shouldn't be doing that task anymore.
Chad Lorec (43:11):
You now have knowledge of how to master that task. You should be training someone else who's dying for an opportunity to do the task but it's boring you. And one, they'll put more time into it, but two, they'll probably have new ideas and insight to improve it. And three, they'll probably take it over for you because they're excited for the opportunity, so don't waste your time doing something you could upscale somebody else and give them a new opportunity for. And then the very last is, I strongly believe in the red blue mentality. If you only know how to build firewalls, wafts or antivirus or whatever our latest endpoint security is, you're missing the puzzle. You're not understanding some of the value of what you're doing; you should know the other side of this. And I have to say I'm just stealing from Ed Scotus on this. I was trained in the early days of Sands. I believe every security person should be able to run the common set of red tools, and test tools. Drop into their console, whether that's AWS or your firewall or whether it's your endpoint; know what those tools look like, know what they're doing and know how that works. And this is why I like people to come off socs a lot of times because they have that insight, but you've got to know how to work both sides of the equation or you're really missing some important insights that you should have; those are my keys to success.
Matt Chiodi (44:49):
Do you have any parting words for our listeners or maybe perhaps anything that you wanted to share that I didn't ask you about?
Chad Lorec (44:57):
I think mainly as a security industry, as we grow and mature; I grew up with .com and put everyone on the internet and then started getting phone calls of their stuff was being hacked and rolled out some of the first firewalls in southern Colorado. And then it just grew from there, so I've been in the security industry as long as you can without carrying a gun or running around with a floppy disk to the mainframes. However, our industry continues to mature; we're trying to bring on new people. We're trying to figure out how to address this gap, and I really believe we need to be mentoring people but we also need to be compassionate with each other. This is a hard industry, it has a high burnout, it's challenging, and we need to be there to support people. And I hope our security community continues to grow and accept more and more diversity. And also accept that we're all going to make mistakes in this and look for ways to help each other, and not dogpile on everybody when they make a mistake. I can guarantee that you I've made my share of them and, and fortunately my name hasn't ended up in newspapers next to them, but it's a hard industry and we're all learning, we're all iterating together. However, I think we just need to create a new environment in our security industry that's a little bit more positive than some of the directions we've taken in the past.
Matt Chiodi (45:28):
Well, Chad, thank you so much for joining us today. I've enjoyed the conversation; I love talking about the technical pieces, but I love hearing the personal things at the end. And so thanks for sharing those things with us.
Chad Lorec (46:41):
Thank you for having me, and I really appreciate the opportunity.
Thank you for joining us for today's episode. To find out more, please visit us at Cloudsecuritytoday.com.