Securing the Inevitable: Disarming Identity and Permissions Risks in Your Cloud

In this session, Sandy revealed the hidden cloud security complexities that are often overlooked. Unlike the conventional focus on entry points, Sandy spotlighted the threats residing within the cloud's web of identities and permissions. He exposed the risks posed by unused identities, often forgotten of past projects, which could turn into significant concerns, allowing lateral movements and privilege escalation by intruders, and proposed a systematic purge of unused identities as a solution. By meticulously cleaning up the cloud environment, organizations can substantially reduce security risks. However, it is important to preserve essential access points designed for emergencies, as well as getting an strategic understanding of cloud dynamics, advocating for a proactive blend of insights, analytics, and foresight. This approach transforms security from a reactive stance to a proactive shield. Key Takeaways:

• Unused Identities: Dormant identities within the cloud pose hidden threats. While eliminating them is crucial, it requires a nuanced approach to preserve essential access roles, balancing risk mitigation with operational necessity.
• Strategic Security: By integrating insights and analytics, organizations can proactively shape their security protocols, adapting to evolving threats with strategic foresight.
• Regular Review: Security isn't a one-time task but an ongoing journey.Periodic reviews, blending analytics and operational acumen, ensure that the cloud's security posture remains adaptive, evolving alongside the ever-changing landscape of threats while seamlessly managing complexity and vulnerabilities.

Karen (00:07): All right, everyone. Hope you've been enjoying our content up to this point. It's my pleasure to introduce Sandy Bird, CTO and co-founder, presenting our last formal session of the summit, titled Securing the Inevitable: Disarming Identity and Permissions Risks in Your Cloud. (00:24): I always like to make sure that our audience has some clear takeaways after a summit like this, and there's been a lot of great content and takeaways, but this session gives you clear actions to take to really reduce some risk in your cloud. So take it away, Sandy. Sandy Bird (00:38): Thank you, Karen. And guys, I'm going to share this presentation. Hopefully, Karen, you get many compliments on your jacket today. I really like the purple sequins. They're very nice. (00:47): So I'm going to share my screen and get us going. As Karen said, this one is very much about takeaways. We really want to talk about what can you take home after this conference back to your day job and actually implement something that'll probably make a difference in your own posture. (01:03): So let's start through this. It's an interesting scenario. You heard in many of the previous sessions, of course, about intruders getting in, and they'll always find a way in, and there's many ways that that happens through vulnerabilities that are there, through some insecure access point, or your own architecture in some ways. But once they're in to your environment, identity becomes the soft, mushy center that it's way too easy to walk through. And through combinations of privilege escalation and lateral movement through these accounts in public cloud, they can get to the prize, whatever that happens to be. (01:41): Maybe they're looking to do damage, they want to ransomware or something. Maybe they're looking to exfiltrate your most sensitive data, whatever that is. But it becomes way too easy, and there's lots of interesting examples for how this works. If you're familiar with AWS, there's a permission called pass role, which you can use to grant other roles to resources and then use their permissions. If you're used to things like Azure, there's these run command scenarios where you can run thing on a machine, and if that machine has a different permission set, you can use that. (02:13): So there's lots of ways that this happens. There's thousands of these combinations that allow for this lateral movement. Of course, if your whole cloud is configured highly overprivileged with STAR, maybe you don't need any of those. You can just walk through the cloud as it is. We hope that's not the case, but if it is, certainly something that you also need to get a handle on from there. (02:32): That said, if we take a look at some of these examples, and we'll use this example of pass role, some of them are non-trivial, and so we spend a lot of time with customers trying to educate them that these trust relationships between the boundaries of their cloud. It's like, "Oh, we have a microsegmentation strategy, so everything's all segmented off in its own." And I hate the word "network" when it comes to cloud. They say "network zones", and you're like, "Really? What's the trust between these network zones?" (03:02): And you may have a scenario like this where you end up with, it could be any piece of compute. This happens to be a lambda function. It, of course, has an identity sitting in this sandbox account on the left-hand side of the screen, and it can do some things, maybe it can deploy some infrastructure, whatever. But through that, it has the ability to jump into another account. (03:22): Now, its ability is actually controlled by the staging account in this case, in these production accounts, because they have roles in them that trust something back in the sandbox account, and sometimes they trust the whole account. That's one way to set it up. Sometimes they trust an individual resource in it. But as they do this, they gather up more and more permissions, and even to the point that when you end up in these other zones, like in this production zone, they can privilege escalate by creating yet a new piece of compute and passing it a role and executing the function, and having it execute as that role that they passed it. (03:53): And so all of a sudden you have something that starts in a low zone, maybe it's a sandbox, maybe it's a development environment, something, that through a number of these jumps gets to this production environment. And these are the things that we want to try to protect against in cloud. It's not your classic human problem, right? It's not a person identity. However, the person may get control of the lambda function and cause it to do this if they're trying to do something nefarious. And so these are the types of things that we're working at. (04:20): Now, this is a pretty little picture. We love to use this in our examples, we use it in our demo environments, but the reality of what you're facing in your public cloud probably looks much different than this. You probably have thousands of AWS accounts, thousands of GCP projects. And because of that, and this is an example of a real customer, when you're looking for these lateral movements of scenarios, the number of accounts and jump points through this becomes much more complex. And you're not going to solve it just by necessarily breaking one chain in this environment and saying, "Oh, well, the problem has completely gone away." (04:54): You're going to have to understand how the identity infrastructure was architected across your cloud. And some of these will be easy to fix, and some of them will be architected in, and they're functioning as designed, but maybe not in the best architected way. And so you can end up with this scenario where one or two identities can get to literally the entire cloud estate. (05:15): And so this probably is a little more real in terms of what your environments look like. So it's not a simple problem as a pretty little picture like we show in some of the demo environments. But we've done a lot of research on this. We've spent a huge amount of time. And one thing that's common across almost all of our customer base is that when you look at the number of unused identities sitting in the cloud... And when we talk about unused identities, they're not person identities necessarily. Sometimes they are. (05:45): You have unused identities, rather they're users sitting in GCP or they're active directory users that have entitlements that have never used them in a long time in Azure. But oftentimes, these are machine identities. They're the thing that somebody set up an experiment to test something and then they just never removed the identity that was there, but it still is trusted by the lambda service. So again, another lambda could use that identity. (06:10): And there's lots of different ways that gets set up in cloud, we don't need to go through that today. But we took a look across a number of customers, and this is a real customer. This is one example, and there's many more that look slightly different than this, but they all have a similar pattern to them that says, "If you just remove the unused identities, how much of your problem goes away?" (06:29): And so in this particular customer, 25% of all the identities in their cloud disappear by removing the ones that are unused. They have 25% unused identities. And then you take a set of those identities, and some of them allow third-party trust. So they're not actually your own workloads being able to assume into your cloud. They're a third party that you're using for something else. (06:48): Maybe it's ServiceNow doing automation in the cloud. Maybe you're using Tableau and because of that, it has some access to gather data out of some of your sensitive data stores. There's lots of examples of this. Maybe you're using Sonrai security and we're actually monitoring your cloud, and so we're a third-party trust relationship. But this is almost worse than the unused identities, because these identities, you don't control what's on the other side. And we found in this customer, 34% of the third-party identities were completely unused. (07:16): So again, huge amount of risk gets removed from your third party risk just by getting rid of those. And then on the far side of this lateral movement example that we just talked about also collapses. In this particular customer, we saw 27% of all of the lateral movement risk in their cloud disappears just by removing the unused identities, because a lot of them are overprivileged. (07:37): And so this is actually a real example to say, "Hey, you know what?" If you want to take one thing away from this entire conference today, let's go back and look at your clouds and start removing the stuff that you don't use anymore. It'll actually make a real impact to your risk. It'll lower your risk, and it's low-cost and easy to do. Now you always kind of want to challenge that and say, "Well, why wouldn't I do this?" They say, "I'm super easy. I should just go do this tomorrow." (08:00): There is one thing you do have to be slightly cautious about in removing all of the unused identities, and that is, there are some number of identities that are in your cloud environments that are designed to be there but are actually used very infrequently. And one of those scenarios are things like break glass roles or the role the cloud ops team uses in case of an emergency if there's a breach or something like that, or whatever that scenario is. (08:27): Those roles themselves, you need to somehow have identified outside of all of the other roles. You could do that in many different ways, use your certification processes for them, whatever you're doing. But before you remove all of the unused identities, you need to make an exception for those roles, because they need to stay there, and you don't ever want to delete those even though they're unused, because someday they may need to be there. Often those roles are very highly privileged too. So again, it's one of the things that you have to be careful of in terms of removing those. (08:55): But once you have that, so you've actually identified those critical roles, and we've identified them, now you actually can remove all of those unused identities. And so the step two would be, you actually do that, and that removes everything that you saw in the previous slide where literally 25% of your identities may go away. Maybe your cost for certain products will go away because you have less identities that they're monitoring now. You'll have much less risk because you'll break some of those lateral movement chains and they no longer will be there. And so you actually get this huge benefit from just removing these identities that are no longer there. (09:27): These are AWS examples here, IAM users, roles. In Azure, it's a little different. You're going to want to remove entitlements, right? So the RBAC assignments of the identity has access to the subscription with a contributor role. Those are the types of things you're going to take away, the entitlement, not the actual identity necessarily, depending on what the origin of that identity is. It could be in your active directory or something. (09:47): And then once you've done that, you want to then focus on these kind of lateral movement scenarios. AssumeRole, PassRole, run command, these types of things that allow for one identity to jump to the next identity. And those too, many of these are actually monitored actions in the cloud. You know things that use AssumeRole. PassRole's a little more complicated. It's not directly monitored because it's a permission, but there's ways to figure out if it needs to be there. (10:13): So you can use those to then start to constrain, though. And if you do these three steps, you really can reduce the overall footprint of your cloud. And there's ways to do this using products. There's ways in the cloud providers' consoles to do some of this work. They provided tools for it. There's some open sources. There's lots of different ways where you can start to tackle this kind of very simple task of just removing the unused stuff from those clouds. (10:36): And so I leave with this. We want to leave everybody with the option that if you're interested, please feel free. We have this kind of Cloud Identity Diagnostic service. If you want to grab some visibility into what's going on in your cloud, we can certainly offer this to you with no cost or very low cost to get into this. (10:55): And then again, as I say with the last, the cloud provider tools have some scenarios as well where you can go in and actually see unused roles. As long as you have a way to know which ones are the break glass roles, it's pretty easy to start to remove those. So I think this is a great way to understand where your risk lies and really start to clean up your cloud from there. So Karen, I'm going to kind of wrap on that, back to you for a second, and I think maybe there's some questions from the audience. Karen (11:23): Thanks, Sandy. That was great. I think that slide looks pretty hairy, the one with all the actual paths in a cloud. I'm always wondering what the reaction is in the audience. Do people have mini panic attacks thinking, "Does my cloud look like that?" (11:35): Luckily, there are some things they can do just by removing those unused identities, and a lot of people were thinking about what they could do in their cloud and have some questions. First question is from Jonah, wondering, "What are all the risks associated with removing these?" So I think he's thinking about doing it and wants to think through what could go wrong. Sandy Bird (11:54): Yeah, and we tried to kind of allude to that to the front part there about the break glass roles and things. The problem with unused identities are, and it's easy to prove that they're unused in most cases, is that there should be almost no risk. It wasn't used, and depending on how long your history window is, if you've got six months of history and you know it hasn't been used in six months, the risk is actually quite low. (12:15): The reality is, though, if that is the break glass account that somebody's going to use in the case of an emergency, maybe it's the SOC's account that they're going to use to go in and do some investigation or something, and they've never done that in the last six months, when they go to use it in the case of the emergency, it will no longer be there. And so that is a problem. (12:35): Now, if you have a really mature company and they have a really mature process for making sure that they test all this stuff, they run monthly test cases to make sure all the accounts work and do what they're supposed to in case of emergency, you'll probably have activity on those accounts, because even their own testing will make them show up. (12:52): But if that's not your company and we realize it's not for a lot of them, you need another way to do that. You need a way to go back to those teams and ask. I will say, when you go and look at those identities by name, there's some of them that are going to be obvious. If it's called Test Lambda One, you can probably get rid of it if it hasn't been used, that's not the scenario. If this is called the SOC operator role or something, then somebody should go to that team and ask them, "You guys have an identity in here that you're not using," and find that out. (13:19): So there is some legwork that has to be done for sure, but I will say you can, even just looking at the identities, it becomes pretty quick to understand. A lot of the stuff that gets left behind is stuff that shouldn't be there anymore. People will deploy a New Relic test account and they're using that because they're doing monitoring, and then you switch from New Relic to Datadog, and all of a sudden you don't remove the New Relic ones. "Oh, we're not using that anymore. Let's get rid of that." And so it'll become pretty easy to get rid of some of those. (13:47): Anyway, Karen, I think it can be done, and certainly lots of things to do, but there is that risk that you'll break something that is infrequently used but will need to be used in the future. So you just have to be careful of those ones that are possibly for some other process. Karen (14:01): Yeah, I like that. Some more good advice from Sandy, a good reason to test those break glass accounts regularly, because you'll catch them, then they won't appear as unused. (14:12): Someone else is asking, just basics, "How do I find out how many unused I have? It sounds like it varies by cloud. How do I just get a quick answer?: Sandy Bird (14:22): And again, it does vary by cloud provider themselves. Each of them have their own ways to see this, and as I say, I actually separate the difference between unused identities versus unused, and I'll use the word "entitlement". If you're into the world of cloud, it's probably called a role assignment. (14:38): But in AWS, there's actually some decent tools right in the AWS console where you can list all of your roles and your IM users, and they will tell you the last time that it was used. There's some weird caveats in some of the numbers that they use there, but generally speaking, if it says it hasn't been used for the last eight months, it hasn't been used for the last eight months. So those are a pretty good way to get a list of the AWS ones. It's annoying, you got to go to each account and there's some struggle in that, but the reality is it can be done. (15:07): In Azure, it's a little more complicated if you don't have the high-end subscriptions like a P5 or P2. I always forget the numbers of these things, but you have to get to a certain level before they expose some of this data and track it. But as long as you have the higher level ones, there are interfaces in there that will show you the last time some of these identities and entitlements were used in there. (15:29): GCP also has, I think it's something Advisor, and it also has some metrics in there. They often require you to go to the individual projects or the individual places to look at this. It's kind of not a global view, but there are places in almost all of the clouds. (15:45): Karen, you talked about that, or I talked about the diagnostic report. You could use something like the Sonrai Diagnostic Report, which is kind of a run once, get a report out of it, that actually will give you those lists of unused identities too. What it does is it just goes back in time, looks through all the audit data, and then builds it off of that. It's another way to get that list as kind of that quick access level. Karen (16:06): Okay. Sandy, the next question is specific to one of your slides, a question around, "What is the remaining risk in those graphs?" Sandy Bird (16:14): So it could be many things, right? We didn't really show the risks in those graphs. What we showed was what was left of the unused identities or what was left of the lateral movement paths. When you take those and actually divide those up by risk, you'll kind of find differences in each category. (16:30): But if you removed all of the unused ones, what usually ends up staying there are things that you intend to be there. It's a role that's used maybe by your team. They assume into that role and then they assume into that role into different accounts. And what that's starting to expose to you is that you have this kind of jump point that allows this access for many identities to get from one point in your cloud to another point in your cloud. That's something that may be fit for design and is okay and you intend it to be that way and you don't believe that it has a lot of risk because of the way that it's set up, and you could risk that, certify that. (17:05): But if you look at it and discover that the control on the front side of that, any identity that's in the developer account, which people just randomly add and remove things to allow for this jump point, you may want to re-architect that and deal with it to remove that type of risk. So that's one type that will be left over. There are intentional things that are there, but they may not be functioning in the way you would want your identity architected, and that requires some investigation. (17:29): The other one are these lateral movement chains, and so a lot of times the identity that can perform this lateral movement is used, so it's used for some other purpose, it's been overprivileged, and the lateral movement permissions are not used. And in that case, you can fix those often by actually removing or denying the lateral movement permissions but leaving the rest of the permissions alone, and that also helps reduce this risk quite a bit. (17:53): But a lot of that lateral movement in that particular customer, I think 73% or something was left, that 73% could be closed off by removing some of those permissions if they're not needed. (18:06): So that is what's left. You end up with a lot of lateral movement, you end up with kind of overprivileged identities that don't use all the permissions that they have, and then you end up with these intentionally architected methods of possibly jumping through your cloud, which maybe are not architected in a way that you wanted but are still used today, and if you turn them off would cause some amount of grief. So you need to architect around them and change the way that that works. Karen (18:31): All right. I think what we just heard is a preview of Sandy's session for Summit 2024, so we'll see you all back next year. (18:36): I'm going to ask one more question, and for the audience, stay on, we're going to wrap up the formal session and then we have tons of networking opportunities. So we have one more question and that's where we're headed after this. Last question, someone's thinking about doing this. "How often should I go through this process and remove unused identities?" What's a recommendation there? Sandy Bird (18:56): It's good. I myself would say at least once a month I would think would be a good time. Generally, you want to automate this process a little more where you have something that's doing the certification in the front, so if somebody needs a highly privileged identity for a break glass role, you have some record of that somewhere, rather you're using a CIM product or something to do that, or you're using some privileged access management system to do that, there's a way to do that. (19:22): And as long as you have that list, you can kind of continually monitor the systems to say, "Okay, well, an identity is more than 30 days old and hasn't been used in 30 days. We should remove it. An identity is 90 days old and hasn't been used in 30 days, we should remove it." So once a month is probably a good time to do this. I realize that's probably more work than most people can do if they're doing it manually. In that case, you could stretch that out maybe to 90 days or something. But if you really want to close the risk down, I think 30 days is a better thing to do. (19:52): The one warning we always tell people is that you may see identities that say, "This identity has never been used," and you're like, "Oh, I should delete that." You also want to look at when it was created. If it was only created two days before, you may want to give the team time to actually get around to using it. So if it hasn't actually been there for a while, you may not want to remove it right away. You want to give the team time to exercise it, and then after they have not exercised it for some period of time, 14 days, 30 days, then remove it. Karen (20:20): Good reminder. Thanks, audience, for all the questions and interactions. I'm going to hand this back to Sandy to wrap our content from the summit, and then I'll introduce the networking sessions. (20:31): Sandy, what did you think overall of content, and what should the audience be taking away from this day? Sandy Bird (20:36): Look, I got a lot out of this conference, actually. I was in one of the sessions where I was talking to Accenture. That was a great session, and Johann and Simon really kind of talked about this fact that the way that we've classically and enterprise has done privileged access management, vaulting of secrets, and IGA in general, or identity and access governance in general, is quite different in cloud, and they've built whole practices around helping customers transform their operations into cloud and getting a handle on this. But they also will admit it's somewhat new, and if they were to go back and do it all again, they would probably do it different than the way they did it initially. They've learned a lot in the last few years. I think that's a good takeaway for everybody. (21:22): The Chris from Albertsons session was really neat in that he talked a lot about not focusing on the big red alarm bell all the time and the fact that the risk is really high, but instead, find the risk that you can actually solve. Take them to your teams and say, "We're going to burn this risk down. We're really going to focus on it and get it done." I thought that was a good takeaway for everybody, because again, as security, we have a tendency to talk about the doom and gloom all the time versus, "Hey, let's take this thing and really focus on it and get that thing burnt down." I think that's a good one. (21:53): Then I think the other one is that in the early session with Nicole from EQB, and I think Chad was on from AWS, they talked a lot about the fact that if you're kind of in the identity side of the house coming to this, and your CloudOps teams and your DevOps teams have been running wild for a period of time, you kind of need to get a baseline of where you are. If you don't know, it is kind of an unknown problem at that period of time, and so if you can get that baseline so you have something to start measuring against, that's super helpful, because now actually you have something to say, "Yes, we're getting better or we're getting worse over time." (22:31): The clouds have tons of preventative controls in them to kind of stop from this point forward getting worse, but you've got to actually take the time to implement those so that you don't get worse, and then you can start focusing on the technical debt that's been built up over the last few years. (22:44): So lots of great sessions. I think a lot of people talked about the fact, as I did at the front of this session, the attacker will get in, the nefarious actor will get in, the insider's already in. What can they do once they're there with the access that they have? And I think in most cases we've discovered that the insides of these clouds are too soft and too easy. (23:03): So again, I thank everyone, please join us for networking. I think it's going to be fun. I'm going to be over there. We've got lots of other executives in the networking sessions as well from lots of different companies that actually have these types of solutions deployed, are struggling with identity, some that are experts in it. So I think the networking will be good for everyone, and looking forward to seeing you there. Karen (23:25): Absolutely. Thank you very much for your session and joining the networking with us, Sandy. Thank you everyone for joining. If you missed a session or want to rewatch, all sessions are recorded and will be available, as well as presentations as we can share them. Thank you very much for joining the first Annual Summit, and stay tuned and join one of our networking sessions. You can just click that Rooms tab at the top of your screen and pick the networking session of your choice. Thanks, everyone. See you next year.