Mapping The Battlefield By Untangling Cloud IAM

In this video, Joe South — Principal Cloud Security Engineer — uncovered the intricate world of Cloud Identity and Access Management (IAM). This session goes beyond technical jargon, focusing on the pivotal task of building an impregnable fortress against cyber threats while granting rightful access. Joe emphasizes the need for unwavering vigilance, stressing the vital task of ensuring correct and secure settings amidst the cloud's complexity. Each cloud platform speaks a unique language, and mastering the security protocols of one does not guarantee proficiency in others, each with distinct rules and pitfalls. At the end, he underscored the pivotal role of governance, ensuring everyone understands the protocols governing cloud resource access. Key Takeaways:

• Constant Vigilance: Proactive monitoring of configurations is paramount, preventing breaches by identifying and rectifying misconfigurations promptly.
• Multi-Cloud Expertise: Mastering the unique IAM protocols of each platform is crucial in the complex landscape of multi-cloud environments, ensuring comprehensive security coverage.
• Sturdy Governance: Strong, well-defined policies form the bedrock of consistent security practices, fostering a culture of security awareness and responsibility across the organization.

Karen Levy (00:00): All right, everyone. Thanks for sticking around. Great session coming up. I'm going to introduce Joe South, collector of rare whiskeys and a principal cloud security engineer at Volkswagen Financial Services. He's going to talk to us all about Mapping The Battlefield By Untangling Cloud IAM. Joe, over to you. Joe South (00:22): Thanks so much for the introduction, Karen. Welcome everyone to Access Summit 2023. Today, we're going to be talking about Mapping The Battlefield By Untangling Cloud IAM. So my name is Joe South. Let's go ahead and dive into a little bit about my background. So I've spent over nine years at this point in cybersecurity, as you could probably tell from having no hair at this point. But I started my career in IAM, and currently, I'm a principal cloud security engineer for Volkswagen Financial Services. And I also host the Security Unfiltered Podcast, where we talk about a whole host of different topics, including cloud IAM and all the challenges around it. (01:13): So the ability to create users and roles at will is the advantage of the cloud and the downfall of cloud IAM. I can't tell you the amount of times that I have seen environments that have allowed their developers to get into the cloud before the organization knew about it or was ready. And as soon as security gets ahold of the cloud environment, they have tens of thousands, if not hundreds of thousands of roles, accounts, service accounts that they did not expect, and now they have a much larger environment than they ever thought that they did. So what are some of the cloud challenges, or cloud IAM challenges with, I guess, managing IAM in the cloud? (02:04): So we have excessive permissions. It's very easy to get excessive permissions within your environment within the cloud. The cloud, as easy as they make everything, it is also extremely easy to just assign a user God admin roles within a certain cloud environment. And you think that it's even locked down and this environment has no external pathways outside of your environment or into it, and it does, in fact. And unless you have a really great monitoring solution in place or you have a really great, I guess, tracking solution in place for tracking these different changes, you're going to miss it. (02:52): And a developer can easily create a role or an account with two excessive of permissions, which leads to misconfigurations. Misconfigurations is the biggest one that we always hear about. We always hear about that 98, 99% of the cloud breaches or the breaches in the cloud are related to misconfigurations. Well, why is that? So the cloud is much more, encompassing much larger than we assume, and one small misconfiguration leads to another, and it spiderwebs and grows to the point where anyone can just get into your environment from the outside in ways that you don't even know about, in ways that you aren't even tracking or monitoring. (03:46): And this creates a lot of issues because you want to... one, you want to stop them from getting into your environment, but two, if they do get in, you want to be able to detect it immediately. So it makes these first two points extraordinarily difficult because of how expansive the cloud can actually become. And then, we have compliance and audit challenges, privilege escalation, and multi-cloud risks. So these two are really interesting here. Privilege escalation in the cloud is very different from any other privilege escalation on-prem, and we'll get into that a little bit more. We have multi-cloud risks, which is you might as well be learning multiple languages when you start diving into multi-cloud. (04:37): Insider threats and privilege abuse that is absolutely a risk, and we're going to dive into that a bit. We also have poor access management policies and practices, data access risks, and de-provisioning users. This last one, de-provisioning users, I can't tell you the amount of times that I've seen organizations that claim that they de-provision their users on a regular basis, that it's all put into the workflow. So when someone gets off-boarded, this is something that happens. And then here we have 150 different accounts that all had super admin privileges in the cloud that these people left years ago, and we're just now discovering that they still have accounts. So cloud IAM is the new front lines of cloud security overall. (05:38): I guess I'll go back. With cloud IAM, it's no longer the firewall being the perimeter. It's no longer even having a WAF as the perimeter. Cloud IAM is the actual perimeter in the cloud because of how open it is. You can go to aws.com, or whatever it is, or AWS portal, right, and if you know the correct permissions, if you know the correct account and the account name and all of that, you can get into someone else's environment, hands down. If they don't have a strong password policy, if they don't have strong access controls around the accounts that are allowed to access their environment, you can absolutely get in. And so that's why it puts cloud IAM at the very top of the threat stack when we're talking about greatest threats to the environment and how they're actually exploited. (06:42): So we have to first start with lowering the blast radius or increasing complexity, right. This is the balance that us, as security professionals, we always have within every environment, right. And it's about lowering the blast radius to the point where you know what the entry points are, you know where data is even leaving your environment, and you have to avoid increase in the complexity of these environments. So what's the best way to actually do this? You're going to want to map everything in your environment, and this is far easier said than done, but that's why we have different technologies out there that are actually able to hook into your cloud environment and map where everything is. (07:37): You're going to want to monitor all activity and privileged account use. You're going to want to heavily use just-in-time access within your cloud environment because, as an admin in a cloud environment, how often do I actually need my admin access? It's pretty few. It's lesser than once a week, right. And so there's no reason why I can't request admin access from someone else in the organization and get that admin access for a certain period of time. That's really the most important part right there is getting that access for only the amount of time that you need it. And then even performing only allowed actions within that timeframe. (08:25): Some clouds manage this better than others, and that is absolutely something as a security professional when you're going into the cloud that you have to keep in mind as a key feature set that you would want. So you have to know when, where, and how to enforce these cloud IAM policies and also avoid the hoarder mentality with roles and accounts. So earlier on in my career, I was looking at an environment, and the IAM manager asked me to look at the roles and the accounts in the environment. They told me a little bit of the history, and the dev teams actually had access to these environments or the cloud overall for a couple of years before the rest of the company kind of caught up and security was established and had even the manpower to really protect the environment. (09:28): And when I logged into their environment, they had 400,000 accounts and roles, and it was created within a very small time span. It wasn't created over the entire two years that the devs had ahead of the rest of the organization. It was created very quickly. That's a huge difference between the cloud and on-prem. On-prem, if you write a PowerShell script that's going to deploy 400,000 different roles and accounts and service accounts, you're going to bog down your system. You're going to DDoS yourself basically. But if you do that in the cloud, the cloud has no issue with it, right. At least it shouldn't because they're building their service off of high availability and the services always being up and able to take virtually any amount of traffic. (10:26): In the cloud, this is a very simple thing to do. The script is about five lines at that, and anyone can launch it. If they have access to the cloud, virtually anyone can launch it. So how to protect the admin from themself. This is a interesting topic because the admin... I think of it from being an admin myself, right. I want to have access to everything at all times because I'm doing work in various environments. There's no telling what kind of work I might be doing throughout the day, and so I need to have full access because it just slows me down if I don't have that access. I've heard this myself several times from other admins. I have used this excuse probably once or twice in my career, but at the end of the day, there still has to be controls in place to actually protect us from ourselves. (11:34): So the first one is cloud misconfiguration. And before I dive into the content of this slide, I'll bring up an example. So with cloud misconfiguration, I was recently doing a Cloud WAF PoC for Volkswagen Financial Services actually. And I tried to, with my admin access, just deploy a vulnerable asset into a sandbox environment that wasn't connected to anything. And with that, I've ran into a whole host of issues that I've never had before with just deploying an EC2. And I actually had to spend several hours over the next several days with someone else going through how to actually get this thing deployed in the environment so that we could run tests against it. (12:30): That's a really great example of protecting the admin from themself is the ability to, even though someone has admin access in the environment, the ability to stop them from doing something and correct their path because it was automatically interacting with my service groups, interacting with... or the security groups rather, the IAM roles that I was assigning it all these other things. And that can be frustrating at points. It was very frustrating for me, especially because I'm an admin, and I think that I should have this access, and I need this access. But at the end of the day, the environment or this automatic service that is monitoring the environment is saying, "Well, there's no exception in place. We need to stop this configuration because they don't know what they're doing, right." (13:27): This service is telling them... is telling everyone else, right, saying like, "Hey, this is a problem. It's alerting everyone, and we had to work through that issue." So setting configuration-based rules will ensure even admins cannot make insecure configurations. Like I said, it's like a battle where you're trying to just get your job done in the environment. And then this configuration rule is trying to ensure that you get your job done in a secure way. Misconfigurations are the most common data breach path. We see this with over-provisioning, public assets, unencrypted assets, storing credentials in the wrong places. It brings up a really interesting question that I always ask when I start getting into an environment. How many public assets do you actually have? (14:25): Do you know what your perimeter is, what your perimeter looks like? Are you scanning it? Do you have a vulnerability scanner that is able to catch different new assets and configuration changes within three seconds of actually deploying it? The answer to all of those questions are typically no, right, which those are very difficult questions to actually answer and execute on in any environment. So, moving on from that, we also have privilege escalation. Privilege escalation in the cloud looks extremely different from privilege escalation on-prem. The reason why this is that you can exploit an external facing web application, something that is serving legitimate traffic within your environment for your customers. And the attacker will then have access to the application that sits on potentially an EC2 instance. (15:34): And that EC2 instance has assumed roles and different dev IAM roles that are used to give that instance access within the environment. And so once the attacker figures that out, they have far more access to the environment than what that normal average user would typically have when they're logging into just that web application. And so we have the blend between human and machine service identities, right. We're seeing a human account transition into the machine or the service world of extreme proportion, right. There's no limit once you break that boundary. We also have unintended inheritance of permissions, which I actually just talked about, permission explosion, and assumed role attacks. And then we have multi-cloud risks. So this is maybe the most difficult part for an organization to actually reel in because all it takes is a credit card to start a cloud presence. (16:55): Literally, if your devs have a company card, they can just put it on their company card. And I've worked for companies before where, for years, they didn't even have an actual contract in place with the cloud provider. They were running it off of someone's corporate card, which really begs the question of how much was actually going on that card and how were you able to put that through the system. But that's a different discussion for a different day. But along with that, each cloud is learning a brand new language. We're talking about learning English in AWS and then learning German in Azure and then switching it up and going to Spanish in GCP, right. That's the closest... I guess that's the closest example that I can actually bring to the table with this is because after learning most of the big three clouds, it is actually learning a whole new language. (18:06): Because when I'm talking to my Azure people, I have to use different ways of describing it. I have to use different service names. I have to understand how the services are interacting and how they're functioning, the different security controls around them. The security principles and the basics of the cloud those things never change, right. So I know that I have to encrypt my unencrypted data at rest. I know that I have to use lease privilege in my environment, but how I accomplish that from AWS to Azure to GCP are all very different things. And that's why I say that learning a multi-cloud is like learning different languages. And then we have de-provisioning of users. We have off-boarding users just as important as onboarding them. Disgruntled former employees are a very real risk in this environment. (19:06): And not only do you have to worry about de-provisioning the users, but you must determine what to do with their cloud assets. So now we have users that are leaving the environment, hopefully on the best terms possible. I was actually speaking with a friend of mine, and his company was recently hacked. And they discussed how it was hacked, and it was a disgruntled former employee that they didn't even know was disgruntled. He actually left on good terms it seemed. He left on his own accord and he used an account that he had in the environment that wasn't off-boarded or de-provisioned. And he had full access to the environment, and he was pulling data and doing other things that raised a lot of alarms, and he wasn't the most stealthy with these actions. And so they were able to catch him mid-flight as he was actually doing it. But you have other users out there that are going to be much smarter about it, right. (20:17): That will kind of just siphon data out slowly to ensure that they're not caught, that it doesn't look like anything new or anything wrong in the environment. And then we have another... a whole other, I guess, aspect of it is a lot of the times when we off-board a user in the environment, we don't even have a line item in the off-boarding process for de-provisioning that user. And then also reassigning the cloud assets of that user. How are you actually monitoring what assets this user owned in the environment, right? Because all of those things need to be transitioned to someone else. And typically, we don't have a very good process around doing any of that. So the cloud has forced enterprise CMDB to expand to include identity inventory. What does this mean, right? (21:16): So typically, when we're talking about on-prem environments, the first thing that a security professional is going to want to see is the CMDB, or we're going to at least ask if there's a CMDB. And with that, the reason why we're doing is because we want to know what's in the environment. How can we possibly protect something that's in the environment that we don't know about? If it's our responsibility to protect it, and we don't know about it, then how can we possibly protect it? And with the cloud, this exacerbates this problem and expands it to the identities in the environment. Previously, if there was a critical asset or a critical resource in your environment on-premise, you would want to know who has access to it. (22:09): In the cloud, you would want to know the same thing, but now you have to worry about the service accounts, the infrastructure that is underlying that critical service or whatever it might be that has assumed roles attached to it, that gives it much broader access to the environment than what the IAM role is using to connect to this critical service. And so it's much more complex. It really goes to a couple slides ago, where it's a battle between reducing the complexity and having the proper security controls in place. So, really, it all starts with governance, right. As a security professional, we always like to say, "Oh, it starts with great security practices. It starts with secure by default and things of that nature, right." But that's not the case because all those things are great. (23:07): And yes, they're absolutely correct. You should absolutely have good security practices within the environment. But if your governance doesn't have the proper policies in place of giving you the power to enforce something within the environment, then your good security practice kind of has a timer on it, to be honest, because your employees they will find ways of getting around the different security controls roles. I was working for a company earlier on in my career, and they said to me, "There's no way that data is going to leave this environment. It is completely safe, and we don't have to deploy this DLP solution here. It's already configured with this other solution, and we're good." (24:00): And to me, as a security professional, it almost triggered something in my mind that said, "Okay, well, we'll put that theory to the test, right. This is an easy one to test to verify that it's all secure, right. I trust you, but I need to verify what you're saying to me because I'm the one that actually needs to protect this environment." And sure enough, within 20 minutes, I was able to get data out of the environment that they claimed was completely secured and didn't need different solutions and security controls in place. And it left everyone in the room very confused as to how I accomplish that, right. And the admins tried to explain it away, but at the end of the day, I still got the data out. (24:49): And so, with that being said, you need to have good policies, good strong policies in place that allow the security team to have the teeth that they need to actually execute on the security practices or the good security practices start and end all the way through. And with that, I will turn it back, but if you want to reach out to me on LinkedIn, the name is Joseph South. The Twitter is SecUnfPodcast. I know I couldn't get the full name in there. They didn't allow me to have that many characters. And if you're looking for the podcast that's available on all podcasting platforms, but you can go to securityunfiltered.com to find my podcast. And with that, I think we may have a few questions from the audience. Is that true, Karen? Karen Levy (25:47): It sure is. I think that session was so jam-packed full of information. We have a ton of questions covering a range of topics, so let's dive in. I think we have a couple of minutes to cover some questions. So Steve asked... Sounds like Steve's just getting started and saying, "What do I do if I don't exactly know where my data is in the cloud? Do you have a recommendation?" Joe South (26:08): Yeah, that is a difficult one that I think everyone is encountering to some extent. I almost approach this question from the aspect of if you tell me that you know where your data is in the cloud, you probably don't actually know where it is in the cloud. The best way to accomplish this is to actually get other solutions out there that give you visibility into the cloud, right. Because when we're going into the cloud, and we're configuring these different resources and whatnot, we're seeing it almost from a list perspective, right. (26:46): You see the list of the different EC2s or the different Lambdas in your environment for AWS, of course, but you don't see what's actually on those EC2s. You have to go and work with the team that deployed it. You have to go and go actually into the EC2 and determine what's going on. And so if you don't have a good, powerful solution around it to actually tell you what's going on in your environment, you're really going to have a hard time figuring out where your data is. Karen Levy (27:18): I think that's a great answer. I love the realization that if you know, do you really know? I think that's exactly the case for most people. We're going to wrap up- Joe South (27:29): [inaudible 00:27:29] trust but verify. Karen Levy (27:30): Yeah, exactly. We're going to wrap up questions live right now, and Joe has been nice enough to offer to stick around and continue to answer your questions in the chat. So if we didn't get a chance to ask your question or you have additional questions, go ahead, put them in the chat. (27:44): Joe's going to be interacting with our audience, and I'm going to say up next, we have our next session called Five Tips to Build Identity Strategy Your CISO Will Love. So, if you know what you want to do when you're trying to convince your CISO, stick around to learn more. Thanks again, Joe. Joe South (27:59): Thank you.