Identity and Access Management in the Cloud: Beyond Mere Access Control

TLDR;

• To Show Value of IAM improvements to Leadership, map them to outcomes like Cost Improvement from Audit/SOX perspective, Developer Productivity Gains via Provisioning improvements and MTTD & MTTR from Incident Response perspective.
• To keep Cloud Security complexity to minimum, bring all your data sources (like SIEM, SOAR, IDS/IPS) together and Monitor your Security Posture.
• For your Production Account security, avoid providing access to Humans and definitely a no Access Keys. Implement IaC and Pipelines for Provisioning.

Transcript

Host: Hi, everyone. This is Purushottam, and thanks for tuning into Scale to Zero podcast. Today's episode is with Chad Lorenc. Chad is a security practice manager at AWS Professional Services, with over 20 years of experience in building and implementing security programs for various organizations.

He's an expert in cloud security, security architecture, and security maturity models. He has a passion to help security professionals overcome the obstacles to enable their businesses to embrace and secure emerging technologies. And he has also been a speaker at top cloud security events and podcasts. Chad, welcome to the show. For our audience, do you want to briefly share about your journey?

Chad: Yeah, yeah. You know, I'm old enough that I got my start in the dot com days. I was working as an accountant and IT manager mix and, uh, dot com took off and I joined, um, some Cisco pre-sales work. And so it was doing Cisco and started selling, uh, T ones to the internet.

And then all my customers got compromised and went back to Cisco and they said, you should sell some firewalls. And so we went and sold firewalls then people couldn't get in. We sold VPNs and it kind of built from there. So had a lot of good experience, launched my own company and built an ISP, kind of an early cloud. We did storage and security from the hosted environment out to our customer sites.

And then I ended up joining a couple of my customers, first a big bank in Colorado, and then eventually working my way into a company I helped spin out of HP and then actually help them spin out another company before joining AWS. So lots of Fortune 500 experience, but also kind of some startup and some financial services. And I really love the new disruption of the cloud.

It reminds me a lot of the old dot com days when we had those massive disruptions and those big learning curves, and it was a really exciting time. And I'm looking forward to some of the AI ML opportunities on the horizon that I think may add another disruption already coming into our environment.

Host: Yeah, that's quite a journey, like pre-cloud to cloud and now moving to like Gen.AI and AI ML workloads, right? So before we start the podcast, we generally ask this question to all the guests and I get unique answers, right?

What does a day in your life look like, like nowadays?

Chad: Yeah, you know, a day in my life can be kind of complicated. I manage anywhere between 10 and 30 security consultants for the US West for AWS. So I am in a lot of the big name accounts. In fact, if you look at your cell phone, I'm probably involved with a significant number of those names you see in the apps list there.

We do...A lot of work, so sometimes I'm sitting down with CISOs and putting together strategic plans. Other times I'm in kicking off engagements and making sure that we're staffing it with the right people. And then there's other times that I'm going into non-security engagements, AI ML, and having discussions about, you know, what is the, what is the correct controls and security practices to build around? This kind of environment to ensure that our customers are always more secure in the cloud than they are on their on-premise.

That's kind of my main charge is helping customers migrate to the cloud, removing security blockers, but also putting them in a position where their cloud environment is more secure than their on-premise.

Host: So one thing that I'm very curious to learn about is that you work with a lot of customers, right? So you have seen challenges that a lot of customers have faced and how you have recommended what you have recommended and how they have worked through to improve their security, right? So out of all of those areas, like today we'll be focusing on IAM and cloud security, right? So let's dive into the security questions.

Chad: Yes.

Host: So in a recent summit in October, you presented a session on identity, security, maturity in the cloudSOX-compliant. And IAM has been in our lives for over a decade. Right?

Why do you think it's still, it still needs attention? Isn't it already solved?

Chad: Yeah, I mean, IAM feels like a boring area, right? IAM is like one of those painful hygiene issues you feel like you have to do as a security person. And on-prem, that's kind of the way it's been, right? Kind of started with us doing mainframe, then I think some of our SOX compliance and some of those things pushed it out where we had more systems and we were really concerned about controls. And then we kind of shifted from compliance to be more security-minded.

and saying, you know, what access are we really giving people? And we started on onboarding third parties. And then IAM added another dimension of complexity. But we kind of slowly started to solve some of those things with Privilege Access Management tools and some of these other pieces, right? We kind of figured out our audit programs on how to audit users. And I'm going to use an example from one of my olden days. This was actually a SOX-compliant app.

And I was auditing it this particular time and I went in to audit it. And the app was beautiful. Like all the controls in the app were perfectly defined out, like least privilege, you saw the finances for your vertical and nothing else. You could pull in comparison and roll up finances, but it didn't show you any of the pictures that would give you too much information, right? Cause you're trying to avoid insider training. Like, wow, this is an amazing app. Right? So I'm looking at the app.

So then I back up and I said, well, let's break this out. Let's kind of threat model this out. And then I found a database and the database was pretty broad open. And I'm like, well, that's not great. Pretty much everybody in IT can get into the database. And I was like, how many see how we get the data into the database? And they say, well, everyone drops all these highly confidential forward-looking financial documents into an open file share on the network and the database sucks it.

So you had this amazingly thought-out built app that was completely compromised underneath with a file share. That's the cloud, right? That was an on-premise example, but that is the reality of the cloud is you have to be able to look at all those components and understand them, but your exposure is much greater.

And I think for a long time,We had a false sense of security with networking edge and firewalls and, you know, I was guilty, right? You had your firewall and then you had your IPS and then you had your web proxy and then you had your sandbox that detonated your malware. Yeah, I mean, you just, by the end, URL filtering going out, right? You have this gigantic stack on the edge. And we kind of ignored IAM, but what's happened is when you shift into the cloud,

If that stack wasn't already relevant, which in some ways, it's definitely less relevant than we maybe made it as security practitioners, a lot of those network controls disappear. A lot of the networking happens kind of underneath the hood. There's not logical choke points, right? I mean, that was as a security person, that's what we always wanted to do is create choke points where we could see all the data and see all the traffic. That doesn't really happen in the cloud. And so...

What it's done is it's shifted the burden of those controls that we placed on the edge from being network-centric to being IAM-centric. And because we hadn't really fully ever matured our models for IAM outside of applications, just like my example where you have the exposed database and even worse you have the exposed file share, that's...those lessons when you put them in the cloud really burn you.

Because now that exposed file share has all your financial information is actually exposed to the entire world instead of your entire organization. And so the consequences got greater for the mistakes, and the controls shifted. And that's really what has brought IAM back up to the front. I think IAM is the new edge is a little bit of an overused term.

But there is some reality and truth in that, that I would argue that from a defense in depth model, and I do believe security starts on the network, but we became over reliant on that layer of defense. And when that didn't translate well into the cloud, it caused us some problems.

And so helping, one of the big things I do is help people when they're moving into the cloud, make that mental transition from my network is my edge to my network provides some insights and inspection points, but my IAM is actually my edge. That is what I should be evaluating. Just like we used to walk firewall rules. You gotta walk your IAM rules to understand what your exposures are.

And you're just like your firewall rules where you poked holes in your environment, your IAM rules poke holes and allow access across your environment, but you have to understand where those are. And you have to understand cascading impacts, which back in the network phase, we called that pivoting, right? How you can pivot from one device to another to gain network access. Same is true with IAM. You can pivot across IAM controls. So that's kind of the reason why it's become a new thing again and forced us to mature something that I'm not sure we ever fully matured.

Host: I remember IAM and S3, particularly when speaking of AWS, where the early services which were rolled out, right? And we are still trying to... We, like for folks who moved from on-prem to cloud, you were very accurate in saying that their focus was primarily on network, but some of the network was abstracted by AWS, right? You don't have to think about some of the networking aspects because AWS takes care of it. But I am never got that attention, which should have been there but I'm glad that like there is a lot more attention to IIM now.

What has changed recently? Why folks are now paying attention to IAM versus like five years ago?

Host: You know, it's a good question. It's actually a question I'd ask myself. I know there's been CISO magazine came out and said, the number one spending item is going to be IAM, specifically Cloud IAM in this upcoming year for CISOs. Some of that has been just like in a network where you tried to compromise the softest host and pivot it off of it.

We've seen that same behavior start to happen in cloud using IAM, where you're trying to find that weakest permission or most exposed permission and then pivot through the permissions. Interestingly enough, sometimes that's your directory. Sometimes that's your single sign-on provider. We're seeing a lot of exposures outside of the cloud with third parties basically granting access into the cloud.

So a little bit different than those early IAM days where, oops, I let everybody into my bucket. We're starting to see more sophisticated attacks at the IAM infrastructure. I think because of that, it starts to shift, oh, I just need to do least privilege to, oh, I've got to figure out how to basically build a detection service around IAM similar to how we did with the network.

Host: No, makes sense. One of the things that you highlighted is that CISO magazine is saying that most of the Cloud IAM is one of the areas that businesses or CISOs want to spend money on. But I want to ask, one of the quotes you had in the presentation also was that everybody likes to say that, hey,

we want least privilege, but nobody wants to buy least privilege. So for a security team, it's a great goal to achieve, but sounds very technical, right?

How do you recommend security leaders translate that goal to business objectives so that they can take it to their leaders and say, hey, I need to buy this tool or I need to use these technologies? How do they translate that technical language of IAM to business language?

Chad: Yeah, no, it's a good question. And I think least privilege is the Achilles heel of the whole IAM strategy. I think many of us tried to get to least privilege. I would even ascertain that Zero Trust is really just the newest generation of trying to explain least privilege.

Least privilege is almost by definition impossible to obtain. It's expensive, an expensive goal, and it doesn't have any direct business value or outcome. And as a result, when you pitch least privilege to management, it basically just sounds like flush your money down a black hole, because you'm not gonna get any benefit and it's gonna be really expensive and time-consuming.

So. As security practitioners, we need to understand that the least privileged kind of needs to go up there with defense in depth as a strategy, but not as it's not something you sell. Defense in depth was a hard sell at the board level too, right? But the least privileged is even more ambiguous and more focused on the small corner. How do you broaden that out and say, OK, what am I trying to accomplish with least privilege?

And there's really three high-level things you're trying to accomplish. I mentioned SOCs, right? Auditability is definitely one of the things with least privilege. So tying it to audit programs, audit programs tend to be high cost, both manpower and high expertise.

The quality of your audit depends on your expertise. So if you're talking IAM, you should probably look at, how can I save time, money, energy on audit programs? from an audit perspective.

If you're looking at IAM from a provisioning model, that's kind of the second piece, then you are provisioning to something, right, that has a business value.

In my world, the cloud is provisioning access to developers. You're provisioning access to developers to drive innovation. They're driving innovation to try to drive some kind of business outcome. So what you want to do is understand what your business is trying to accomplish, why they're in the cloud in the first place, or why they're building a new app, and be able to pitch, hey, I can drive down the cost of provisioning users I can make it lower cost, faster, and more secure.

And I can achieve these business outcomes faster. So if that means if I can onboard developers instantaneously instead of two weeks, and I have 20 developers to launch this app, you have a very real metric there to drive why you're trying to do IAM.

And do it in a way that makes your CIO happy, or your CTO happy, so they can quickly launch and ramp up and innovate, but also makes your CISO happy, because he feels comfortable that we're provisioning into an environment that has guardrails, that has protections, so nobody's gonna do anything criminally stupid and end me up in the newspapers, but I'm still enabling the business and I still have the insight I need.

Host: So I liked, like there are two takeaways from it. One is like show cost savings, how you can save costs and all of that.

Like by tying it to audit programs and stuff like that. The second one is the productivity, right? How can you get your new members or existing members to be productive quickly so that shows value to CIOs or CTOs. The last thing I forgot to mention is like showing value to see so right like they do not want to Be on the forefront when the company is getting hacked.

Chad: And that's really the third value, right, that looks more like that detection element that we used to do metrics for networking, right? Meantime to detection, meantime to remediation, right? You can tie IAM strategies that are based around detection, that are based on around visibility to those threat detection incident response metrics.

So that's really the third kind of entry point as far as positioning IAM with something that's more meaningful from business strategy. Now, so drive down audit costs, drive down risk, drive down provisioning costs and time are really your three big outcomes you're looking for.

Host: Makes sense. So a follow up question to that is, let's say I convinced my board or leadership and we bought a tool.

How do I show the progress of it to my leadership so that there is continued investment in that area?

Chad: Yeah, that's a good question. So one of the mistakes we often make as IT people is we run out and provision something. Before you provision something, take the time to baseline where you're at and capture those metrics, capture those pain points. So understand that your current process of quote-unquote least privilege, you know, takes two weeks and four reviewers or whatever the case is, right?

Um, "understand how that impacts the timelines and your speed to market of your apps". Once you understand those, then you can start tracking against metrics. You can start setting up North Stars that say, OK, before the tool, two weeks to onboard a developer and get them working. After the tool, where was it, right? And you can do that for each one of the pieces. You can do that for your audit program. What was my cost to audit before the tool? What was the cost after? You can do that with a TDIR.

How quickly can I detect events in the cloud before? How quickly? And so you want to tie it to really hard business metrics, because that's the way that the business level speaks. That's your board, your CISO, your CTO, CIO. You want to be able to speak at that level and show progress on that level in your maturity.

Host: Yeah, I liked how you connected your to the outcomes, right? For each outcome, you have a baseline and then you slowly map the progress to those outcomes so that the leadership sees value in the new tool that you have procured or for the continued investment.

Another thing that you highlighted in the presentation and this I find it a little funny, but was that humans do not need access to production cloud accounts, which is like a golden rule, right? But in practice, it doesn't happen. We often see that there are human accounts and with access keys in production environments. So according to you,

Why do you think organizations are not able to follow or even achieve this?

Chad: So we do actually have customers that do achieve that. There are some prerequisites to get there, right? And that's one of the reasons why I wanted to talk through a whole maturity model is that's not where you usually get to start, right? And in fact, you've really progressed to the top of the ladder to get to that point.

So what are kind of the pieces you got to get in play to get there? You know, one of the first things you have to figure out is how you're deploying without click ops, right? How are you using some kind of IAC?

And not just IAC, so not running Terraform off your desktop on 20 different developers all pushing their own updates, right? I mean, like, real through a pipeline IAC manage, right? Pipelines are the automated, fast way to do change management. I remember when ITIL was so the cool thing we were all talking ITIL and change management, and that's how we were going to drive down errors in IT and everything.

Pipelines is really just the automated version of that, and expediting it and speeding it up, but making sure you have your checks. So that's one of the first things. The pipeline is one of the keys to getting people out of the production. Another thing is another dynamic shift that has to happen in moving to the cloud from on-site.

Everybody on site would have loved to have a play area, a test sandbox area, a dev area, a UAT, and a production. Rarely to never did I see that happen. Maybe if your financial institution and my online banking app, we got to do that. There were some select areas where I got to see that. But it's cost-prohibitive because really, you're amassing a mass amount of tech debt for every one of those environments.

So it's not just the upfront costs, but it's all the sunk cost of supporting that in tech debt. So we kind of as IT people killed the development life cycle in a meaningful way on the on-premise environment. Bringing that back to life, especially for us, us IT guys that have been around forever and understanding that, hey, in the cloud, I can spin up and spin down resources like that. I only pay for what I use.

On the mass tech debt, realizing that in the cloud, there is no reason why you would not set up that kind of environment and how easy it is to cost justify it, how easy it is to deploy using pipelines and do checks. But that mindset is a huge mindset shift. And so you have to have the mindset shift. You have to have the pipelines.

And then you have to have the governance, people process technology around to drive it. But those two pieces are where the struggle often is. At times, I think people get so distracted by, oh, we have to be multi-cloud. So we'll just have no governance, or we'll just manage to the lowest cloud denominator. You're never going to get there if that's your.

You've got to figure out how to optimize in the environment you're in, which is a big ask right now for people that are being told, hey, go ahead and just manage the four environments. Take these three clouds and take this on-premise. By the way, we also have an on-premise cloud. You have a private cloud. Now you have five environments.

At some point, the shift of understanding that if I had discipline in one environment where I had that full stack, where I was doing everything through, you know, a sandbox maybe where you're allowed to do click ops, and then immediately start going to test and dev that are going through a pipeline, and then going through some kind of security assessment, static, dynamic, and then going through user acceptance testing.

But really, a UAT environment is a great environment to test not letting anybody have access to, right? So you can actually start testing that there, still have production access because everyone's scared about breaking stuff, right? But do that until you get that discipline and that muscle built out and then roll your no humans that you've forced in your UAT into your production environment. And obviously, you still build bright glasses, you still have exceptions, but that makes monitoring.

So going back to IAM, if I'm monitoring and I know there should be no humans in this account, detection is so fast. And even if you have the worst built app or your app, for some reason, decides to use some old library that's been sold out and compromised and now bad guy has a back door directly into your environment, completely outside of your control, you're gonna know it instantly, right?

And I like canary tokens in between, right? You plant those canary tokens around and different things to catch bad guys, but you don't need canary tokens if you have an environment where anytime you see a human pivoting, it's an incident that you investigate, right? Or it's a break last exception that you already know about and have documented and are expecting. So, I mean, that is...

That's where we're going to reach the level of maturity people really want is when they're able to get to that stage.

Host: I love that state that you highlighted, right? That you follow click ops, you have a sandbox environment where your developers can experiment, but even in UAT you highlighted that, maybe we should restrict that in UAT, we follow the click ops so that there is no chance of somebody getting access into production because you have already vetted that out in the UAT environment itself. So yeah, I love that like the practice that you were suggesting, right? That you use the pipelines, you use ISE, click ops to make sure no human has access, no access keys are there in production, stuff like that. I have one last question on IAM.

So if I, let's say I am running a fintech startup and I'm growing, if I need to follow a checklist on IAM, what would be your top five?

Chad: Yeah, I mean, at the very beginning, don't use root users, right? I mean, that's how people get in trouble. MFA, everything you can, right? Those are two easy, easy places where you have huge mitigation of risk for relatively little effort. Then the third thing, though, would be to understand organizational structures.

And everybody has their own version of that. But AWS calls it organizations. Because that's where you're going to be able to put broader guardrails around your environment from an IAM perspective. And those are enforcement mechanisms, right? Where you do not allow statements in any of my accounts. So very quickly, you want to get, once you do that basic blocking and tackling with MFA and I guess.

The other thing that organizations enable is single sign-on, right? So now you have a directory, and so when people leave the company, they don't still have access to your cloud, right? And you're getting that, that visioning model. But that centralization really comes in earlier than people realize it.

And so even if you're a FinTech, as soon as you start really building, you're gonna wanna start breaking out those accounts. It's really hard to go into customers who have used a single account for five years, and now they're trying to move to an org structure. And at some point, you hit all the limits of all the things you can do in a single account if you're a fast-growing fintech.

So you undo the benefit of the scale of the cloud by not understanding how to leverage that, but you also create an IAM nightmare. If your whole company is trying to survive in a single account, the IAM permissions become very costly to manage. And that's not what we want. We want simple, easy boundaries with guardrails that you can provision into. If you can think of accounts almost as buckets, say, OK, you can get access to this bucket. You're going to have this permission. But now I'm not exposing every bucket across my organization.

Host: Right. That makes sense. And especially like the org, like understanding the org structure and setting some guardrails. Because we often see that due to business regions, let's say you only offer your services in a particular region. So it's better to have guardrails so that no resources are getting spun up in any other region. Let's say you cover only US.

All of a sudden, if you see there is a resource getting spun up in Australia, that means it was an anomaly, right? So unless you have the guardrails in place, you cannot block those types of activities. So yeah, that, that makes a lot of sense. Um, so, so that was on the IAM. Now I'm, I want to move to cloud security a little bit, right?

So most of the cloud practitioners, are building, building, and deploying workloads, they spend a lot of time on architectures and interaction between services.

Now, when you bring in cloud into the mix, it adds one more attack surface or your attack surface grows. Now, how can organizations ensure that they have decent cloud hygiene and keep the attack surface minimum? I know that we spoke about IAM, but any other ideas to keep in mind when rolling out services on the cloud?

Chad: Yeah, there's a couple of things that feed into that as far as where we see people be successful and where they struggle. Um, one of the great things has been the cloud center of excellence and the CTOs that are driving some of this innovation. Um, where that can get you sideways security is if you build a bunch of security in a silo and you have not tied that security back to your security operations, sooner or later that goes poorly.

And so understanding how to quickly transition from, hey, this is the cloud center of excellence and we're doing this, to operationalizing it as part of your mainstream is the key. And so my favorite example is a very clear one. You can set up a beautiful org structure. You can collect all your logs.

But if your one cloud security guy is the one that's supposed to look at all those logs and action all of them, you just left an entire operation team sitting in a sock somewhere, probably some expensive SIMSOR tool that could have been doing all that analysis. And you've got one guy that you've overwhelmed looking at logs instead of doing innovative security things. So figure out how to tie your incident response and your logging and all those things back into your SIM, back into your SOC, and make it part of the security operations. And that's the best way to keep the continuity. And there are some nuances, right? You need to have separate incident response plans for the cloud. You have separate tooling.

So there may be a point where the SOC goes, ooh. You know, this is part of the preset alerts that you told me are bad, or maybe even better yet, GuardDuty found it, pushed it to me, and I validated, yeah, it is bad. I don't know how to go and do the next level investigation. I push it to my cloud SME security guy, and now he knows how to use detective to sort through logs. And he knows how to, how to make some of those changes in containment and all that stuff, but you've got to have that connection and that scale so that you can scale with the organization and you're not trying to scale alone in your cloud center of excellence. And that really goes across, right?

There's often IAM teams, there's often an SIEM, and a SOX that needs to go through. There's sometimes a separate incident response forensics team that you should be engaging. Often there's an application security team or at least the application audit team that you should be coordinating with, right? So you want to bring in those pieces of business. And then at some point, right, the other thing is you want a complete picture of where your maturity is in the cloud. I like to use Security Hub, it aligns with CIS and also to AWS foundational best practices, which are two of my favorite standards in the cloud. I also like the CSA cloud maturity model, but you can map to all those in Security Hub and have an ongoing posture management, which you absolutely, whether you use Security Hub or someone else, you've got to have a cloud posture management tool because it's a, it's a component of vulnerability management that doesn't exist on site. Right. So that's probably the other, the other big gap that you have to really be aware of is that there is this whole new vulnerability management. Yeah. You need inspector on your containers. You need our duty to provide that IDS, IPS visibility.

But in the end, you have this huge gap that nobody is going to address unless the cloud team takes it on, and that's that cloud posture management. And so understanding also, can you upscale your vulnerability management team so that they're able to do that? Of course, the other way to scale in the cloud is to keep up with internal security you don't have to build machines from scratch, right?

You can do some golden image automation where it automatically pulls the image, checks it, scans it, updates it, and pushes it out there and you keep a current image. You roll them out of your load balancers, roll the new ones in and life keeps on going, right? So there's a lot of automation in the cloud that simplifies different components of security. So that's the other thing to understand is that there's a lot of simplification, especially vulnerability management and threat detection.

Host: Okay. I like two things which are very important that you highlighted it. One is like bringing data in so that you have visibility across all the systems. And also you have this like posture management. Like security hub is a great example that you shared, right? Like look at how you are doing from a CIS perspective or AWS best practices perspective. So that you know how is your problem posture improving or degrading and how you can address them. So a follow-up question to that is, like

When any organization moves to cloud or the organization has been in cloud, are there any particular resources that you refer or you recommend to your customers so that they manage the cloud security complexity in a better way?

Chad: Yeah, yeah. So from a kind of pure architecture model, I love the security reference architecture. You can literally go through the components and check those off and say, do I have a cloud posture management tool? If yes, insert it there. If no, security hub. Do I have a detection tool that can look into databases and containers, analyze NetFlow, can do all those things?

Yes, no, if no, guard duty. And you can literally go through that checklist with SRA from an architecture perspective. I like the Cloud Foundations model more from a governance perspective because it brings in some of those other things like backup. I think with ransomware, we've all come to realize that backup is part of your security and recovery strategy. So you have to do that and assess some of those broader things. So I like some of the governance and additional pieces on the Cloud Foundations model brings in as well. So I use a mix of those two models primarily in trying to help customers so that they can have a reference architecture and a governance model.

Host: OK, now forward looking, like now today we are talking about IAM. We are also getting into like GenAI, AI/ML usage.

What do you expect to be like the next complex area of cloud security for which like organization should be ready?

Chad: Yeah, I mean, I think cloud is always going to be, is always gonna have a growing data gravity. So it doesn't matter if we're talking LLMs or we're talking data lakes or any kind of thing you're doing, the natural place to put large amounts of data to assess it, use it, leverage it for your company is the cloud.

As we see large amounts of data moving, IAM becomes critically important.

But I think the next big wave for security is we're going to have to learn, really learn and understand privacy. So figuring out how to overlay privacy models. Actually, interesting enough, our privacy team just released a privacy reference architecture to overlay the security reference architecture, which was a really cool thing update that they made there. But I really do believe privacy in many ways is going to be the next front that we have to deal with.

I mix the idea of data governance with privacy. I know that's some privacy, some protection, but data governance, data sovereignty. As we see laws around privacy or around other compliance requirements that require specific data to stay in specific locations.

That's probably the other big thing I see us trying to solve, especially again, with that data gravity of some of these large amounts of data moving to the cloud. How do you honor privacy? How do you honor data governance? How do you manage data sovereignty? I think that's the next big wave for us.

Host: Yeah, I totally agree because now with LLMs and all, you need a lot of data to train the models and even to generate some findings, right? Useful findings. So,

you'll be feeding in a lot of data. So where does, like, how do you take care of privacy in that case? So yeah, that makes a lot of sense. And yeah, that's a great way to end the security questions on IAM and cloud as well.

Let's move on to the rating security practices section.

Rating Security Practices

So in this, I'll share one security practice and you need to rate between one to five, one being the worst and five being the best.

And you can add context like why you think it's a one or a five. So the first practice is always lock your computers when you leave your desk, even if it's just for a short time.

Chad: Yeah, so, you know, it's kind of funny. There is a set of security hygiene that has become religion, right? Like, this is what you always have to do. It's on every checklist in the world. But in the end, if you step back and take a security risk perspective, I'm not sure that control is that important in your overall layers of defense.

I would put it at like a two because when I was at the bank, we had somebody run in and grab a terminal and run out with it. So guess what? The fact that you locked it made no difference at all. We still had to report it, right? I mean, this is really what drove the disk encryption world, right, is your workstation is locked really means nothing unless you're layering multi-factor authentication on top of it.

So if someone has access to your device, old, old Microsoft laws, right? If I have access to the device, I own it. Right. And so I, I don't, I think it's good security hygiene. I think there's some circumstances. Um, if your password is under your keyboard, it doesn't really matter if you walk away and lock it. So when I did bank audits. I got into lots of locked workstations with sticky notes that were on monitors with passwords. So again, that control is only as meaningful as the environment that's around it. And on its own, I don't think that's significant of a control because it requires a framework of controls around it to be effective. So.

Host: I think the keyword is hygiene, right? It's a good security hygiene, but don't take it for granted that will cover all your security risks in a way, right?

Chad: Yeah, it's a false security that, hey, I checked off these hygiene things, but they may not have actually met your security risk that you're trying to address.

Host: Right. The next one is DevOps practices are needed to move fast and to deploy code to production. Security practices are not the most important right now.

Chad: Yeah, unfortunately, I hear that one a lot still. I would rate that a one. And what I would encourage, again, as you have those discussions, that you begin baselining, what is the cost of retrofitting security? I could tell you, first of all, as a longtime security architect and security practitioner, retrofitting security is always a compromise. Like,

When you're bolting it on, it's never as secure if you would have built it, right? I built an online banking app from scratch. I built a credit card processing system from scratch. Those systems built from scratch in a true Agile lifecycle where you're injecting security along the way, low cost at the end, right, from a security standpoint. Systems where I built it, right?

where the system would land on my desk and say, will you approve this so we can go live tomorrow? Math, like a multiple year roadmap path of rework to get it to where it is. And that whole time, you've created an exposure for your business. And so, absolutely puts you in a horrible position. The other problem is, is usually the teams that do the work move on. So now they're gonna do all the same bad security practices on the next app in your company and the next places they go, you know, from a more global perspective. So if you can build security into your agile cycles, developers love to learn. And so educate them as they go, they get better. Like developers don't take knowledge and throw it out. Their whole life is about absorbing knowledge.

So every time I've invested in developers, I did a whole podcast that went viral many years back, actually went viral in Europe of all places, about WAF. But the key point of it was the most effective impact I had on my application security as measured through my WAF was when I took part of my security budget and paid for my developers to get security training in development. All right, that's where you make the impact, not on catching it on a WAF and trying to block it and going back and trying to change the app and everything else.

Developing securely upfront. So giving those immediate feedback to developers is so much more meaningful and powerful and leads to better outcomes for the company, both short-term and long-term.

Host: Make sense. The last one is continuous integration is a must for DevOps practices. Security architecture review should be conducted as part of the integration itself. It's very similar to the previous one. But yeah, how would you rate that?

Chad: Yeah. So I would rate that one a three because I think security people can also break pipelines, where it's not really a pipeline where it goes through step one, step two, and then it jumps out to a security committee for review, and then you push it back into the pipeline. That should be a very short interim phase, if you're bouncing in and out of your pipeline.

And so architecture review, you should figure out what your key principles are and figure out a way to automate those principles in a pipeline and assess dynamically on the fly in a true continuous integration. So I am all for continuous integration. I think some of us security practitioners need to be a little bit more dynamic in the way that we figure out how to interact.

I think you have to apply the 80 20 rule, which is hard for us security people because we like things a hundred percent secure, but if you can knock out 80% of the problems with automation, build the automation, knock out the 80% and then address the 20% in your final stages of testing or whatever, right? But figure out how to automate it. So you're, you're not slowing the process down the continuous integration.

So yeah, that was the that was kind of the, and I'm reading a ton between the lines of the question there, but continuous integration and architecture review sometimes end up clashing with each other. So you have to be really careful that your architecture reviews and their design phase, then you let people build with some kind of guardrails, and then you go back at the end and assess against what you agreed upon so that you're not breaking that true continuous integration process.

Host: Yeah, I love the 80-20 thing that you highlighted, right? Like, try to automate as much as you can. Do not block the pipeline from moving forward.

just because of security reasons, but yeah, I love that. Yeah, and I have one last question. Any reading recommendation that you have for our audience, a blog or a book or a podcast or anything.

Chad: Yeah, I mean, I love Ashish's podcast on cloud security. He hits at multiple different levels. I think he does a really good job. So I've had a privilege of being on that one. That's probably my favorite one. As far as books, I'm a little bit geeky in management. One of my favorites is this one. This is why I actually recommend this one to my employees.

which is kind of funny, it says fire your boss, but it's about self-management, right? And about how, and it kind of ties back to some of these security objective ideas. How do you tie what you're doing to value versus just doing to get things done? Because if you're just doing to get things done, there's always more work than you're ever gonna get done. So how do you prioritize your work so...

Host: Right. I love the title. Yeah, so that.

Chad: You're working on the high value things so you can prioritize your life to be focusing on the high value things in your life. And so, yeah, that's probably my favorite book that I often recommend.

Host: We are at the end of the podcast. Thank you so much Chad for joining. Uh, it was so insightful to speak with you. Yeah. Thank you so much for coming. And it was a pleasure to chat with you. Uh, and to our audience. Yeah. And to our audience, thank you for watching. See you in the next episode. Thank you.

Chad: Yeah, thank you for having me. Yeah. Great.