Navigating the Challenges of Cloud Permissions: Ownership, Maturity, and Centralized Control

Sandy Bird (00:00): Thank you, Karen. Welcome, Alex. How are you? Alex Shulman (00:03): Fine. Hi, Sandy. Thank you all for joining. Exciting session today. Sandy Bird (00:09): It is exciting and I'm super happy to have Alex with me today. Alex and I have some history. We worked together years ago at IBM and when I knew Alex, Alex was very deep into securing cloud and things like object stores and access to object stores and container escapes and all kinds of fun stuff. Alex, give us a couple minutes about yourself. Most of the people here probably know I'm the founder and CTO of Sonrai Security, but you may be new to a few people. Alex Shulman (00:38): Thank you, Sandy, and good morning, all. My name is Alex Schulman and I'm a cloud security leader at EY. I have helped hundreds of clients with cloud security and identity and access management. But Sandy, before we start, let me remind you another story from our joint past. 16 years ago when object storage has just started, I was asked about its weaknesses. Obviously my first response was that access control is going to be a major problem and I started promoting changing the defaults and adding more secure options. But it took me time to understand why, why there is an industry push to have data sharing options open. Right? (01:24): Interesting question. The answer is that the most influential early days cloud customers were companies developing social media platforms are offering products for sharing of images or videos. They wanted users to share all of their data by default because it accelerated their platform growth. And these requirements of these companies went into the designs of many of the cloud platforms that we're using today and the influence, the creation of all the access and sharing options that we'll be discussing today, and we're struggling to disable now. So with this, Sandy, let's go deeper and discuss the risks and the solutions. Sandy Bird (02:11): Exactly. The defaults in early days of cloud were terrible for sure. They caused some very large problems to happen. Now again, Alex, you're now with EY, big company. So of course we have to put these lovely disclaimers out. And, you know, the only real important, very important point here is this last one. Everyone should look at this. If Alex and I give you tax advice today, you should not take that and actually should never take tax advice probably from Alex or myself, so thank you EY for adding this lovely disclaimer to our slides. Look, Alex, I think if you can give us two minutes. Look. I love this identity as the new perimeter. It truly is in cloud, but can you explain a little bit more about why this is so different in the way we do governance in cloud today for identity? Alex Shulman (02:57): Yes. Yes. Thanks, Sandy. It is critical to understand this point. Let's look at cloud services like object storage. When, for example, permissions on objects or packets are misconfigured, they can directly expose the sensitive data by passing all of the network defenses. And this is for two reasons because these services, first of all, are shared among all of the cloud customers. They are not isolated and deployed for each customer. And then, second, they're running over the internet. And this is a major difference from what we have on-prem where we are deploying our data and other systems within our organization and behind the network perimeter. So in our traditional environments, our network perimeter is protecting us. And if access control is misconfigured, it is just internal. Obviously there's still a problem, but it will not immediately expose the data in the same way as it does in the cloud because cloud is shared and over the internet. (04:08): But let's also discuss solutions. Unfortunately, most of the identity and access management solutions that we have today were designed for human identities. There were no design for all the machine identities and all the permissions on resources and services that we have in the cloud. So we need our tools in the cloud to speak the cloud language and we need them to be able to check and fix things at cloud scale and speed because when we are provisioning thousands of resources, nothing can be checked and configured manually. So with this, Sandy, let me pass it to you to give some examples maybe of what may go wrong. And I know that there are so many options of what may go wrong, but let's review maybe some examples to give our audience this understanding. Sandy Bird (05:01): Yeah. No. I remember my days again back at IBM where there were five layers of firewalls between our development lab in the outside internet. You know, there was no way you could ever make a mistake in identity that caused that problem. And in cloud, you know, one small slip-up and all of a sudden you've given everybody in the world access to your data. It's also way more complicated just to understand how access works in the cloud. We see so many examples where you have some workload, sometimes that's an automation role that's doing things. Sometimes it's a serverless function that's part of your application. Sometimes it's a container running inside of a cluster somewhere that has access to object stores or other things. And the access can be granted to the identity itself. It can be granted at the resource level using resource policies. It can be granted via RBAC. It could be access keys. There's lots of ways that access is granted, but in cloud there's so much impersonation that happens and you have this scenario where you have trust between things. (05:55): This piece of compute can become this identity and then do things with it. And I have so many interesting stories from the last five years of selling these cloud infrastructure entitlement management solutions where developers have done things for sometimes convenience, sometimes because they thought it was a good idea, but just really exposed stuff in ways they never intended. And one I always like to tell is that we had this customer where they were basically putting trust relationships between their workloads and these cloud identities and the workloads would run them and do everything that they were supposed to do, but the developers struggled to test things because they had to get the workload to do it and then did it work? It did not work. And they thought it would be way easier if they could actually just impersonate the identity that the workload was using and test the things themselves to see if they were getting errors or not. And so they added this trust relationship, and this is an AWS thing. (06:44): You can do similar things in Azure and GCP where that trusted the account it was in. Unbeknownst to the developer that did it though, that actually meant every single identity in that account could now become that workload role. So the lowest privilege thing that could actually assume that could end up using it and abusing it and doing things. And they opened up massive amounts of lateral movement risk in their cloud just by doing that one simple little thing. And so there's lots of these stories of how this works. I'm not going to go into this here today. We've got more sessions for everyone on the call that are so great. Nigel's dude's doing one on cloud permissions. Rich Mogul's doing one on SCPs and boundary conditions. They're going to go deep into this world and it's super interesting stuff. So again, spend some time on that in some of the other sections. Alex, state of the market today, where do we see customers at with this? Alex Shulman (07:35): Yes. Thank you. And let me start with some examples from the ground. We're doing many penetration testing exercises and most of the penetration testing packages have automated tests, typically about 20 tests for each cloud automating privilege escalation flows, and almost every penetration test exercise finds these valid attack patterns allowing privilege escalation. And these are just statistics from projects that I was involved with. But I think it is pretty shocking, first, that we have so many options to do privilege escalation and then that it actually works in many of the cases. Once again, going back to what I described, remember cloud was designed to allow this fast growth of social media platform customers. So the main considerations when these systems were designed were things like flexibility, ease of deployment and cross services integrations, which means many permissions across the services. (08:44): And this is exactly what allows these 20 and more privilege escalation flows in almost every cloud. Right? So these unfortunate design decisions that were made very early for good reasons because indeed some customers needed this, but now we are paying the price because we have all of these options to do privilege escalation and we need to be very careful in actually not allowing this to happen, which means constantly checking that we don't have this doing penetration testing exercises and constantly improving. But before going further, Sandy, I know that you also have very interesting statistics on the state of privileged access. Can you please share these examples? Sandy Bird (09:29): Yeah. Last year was really a year for me where we spent so much time just focusing on why customers were not being successful in fixing these problems. We had a product that solved them. We give them lots of visibility into the problems. We give them remediations to fix it. And we were saying, why are people not fixing this? And we were looking at their cloud saying, okay, statistically what's going on here? Right? And we know that clouds have a lot of permissions, tens of thousands of permissions per cloud and different kind of models. But when we looked at things like the really sensitive permissions, not the 14,000 permissions, the thousand most sensitive permissions in AWS, the thousand most sensitive permissions in Azure, and looked at identities that had those permissions, 92% of those identities never once used them. So they had the ability to create a new network or create a new pre-signed URL that bypassed all the network rules or had the ability to create an access key and 92% of the identities that could do it, never ever did it. (10:26): It was just completely overprivileged across a varying set of customers, large financials right down to small startups, so you saw this. The other thing was this really interesting time thing. If you were in cloud for a very long time, and I'm going to say five years because that's a long time for cloud, if you're in cloud for more than five years, most likely half of the identities that exist in your cloud are unused, completely unused. They don't get used anymore at all. And so you just have this lingering set of technical debt you need to go clean up, but yet no one would fix it. And I have this kind of really interesting, this was truly the epiphany for me back in 2023. Customer in one of these states, half their identities are unused. They actually get popped by their own red team. Red team basically completely owns the account. And they did that simply by using a Git Runner, access that they got, got the Git Runner to basically create a new identity and the cloud attach administrator access to it, they own the whole world, do anything that they want. (11:24): And when we looked at the identity that got popped, because again of course they come to their CIEM vendors and say, "Hey, how come we didn't detect this?" It's like, "Well, we've been telling you this forever. This thing's not least privileged." It hasn't been, you know, it actually had been used, it was a Git Runner proper, but it hadn't used any of these sensitive permissions in a very long time. And we looked at it and the things that actually had happened, this creating of this IAM user and attaching the [inaudible 00:11:44] it had never done that. And we said, "Well, why didn't you fix that?" (11:47): Well, this is behind all of these other things that we have to fix. And so it really was this kind of epiphany that went off that says, look, we have to do something different. We can't actually have every identity get fixed. And so we were looking at the time it was taking to fix it and it was like 30 minutes per identity so we could generate the perfect policy for it. They had to put it somewhere into a code repo somewhere. They would have to update the Terraform. They'd have to put it in a staging environment. They'd have to test it. And then they have to roll it to prod. And honestly, if you could do that in 30 minutes, you'd be doing pretty well. Most people take longer than that. But these customers just couldn't do this when they had tens of thousands of identities in their cloud. It just wasn't a possibility to do this. And so I kind of ended up in this state where it was like, okay, I wanted perfection. Cloud gave us this ability. We had all the log data. We could see every identity. (12:37): We could do all of these things. And for five years of my life I was like, we're going to build the perfect identities for everything. But last year was this point in time when I was like, this isn't working. And so when we looked across all of these kind of interesting customers, there was a trend that we saw that was kind of the telltale sign. If somebody was a highly governed entity, large financials, they had teams of people that looked at identity and cloud teams, five people, seven people. And in almost every case they had written centralized guardrails across their cloud for identity that took away the most outrageous things a developer could do. So as an example, turning off cloud trail, creating a VPC, changing the security group rules, creating presign deals, using services that were not approved for use because they didn't comply to the standards that they needed within those organizations. Those organizations could actually take the results we gave and do least privilege in the most important area of their clouds and do amazing things. (13:43): But it was because they weren't worried about all the other areas of their clouds that were out of control because they had already put the centralized guardrails in place to make sure they couldn't make mistakes. And so we had this kind of interesting set of maturity stages. You know, everybody else starts out in the wild, wild west and sometimes that never gets fixed. You end up at that point where you have 50% of identities undone, not used and these 92% of identities that have sensitive permissions that never use it. (14:08): You have to get that wild west under control, but nobody ever gets to the tight super low risk thing unless you really have a whole team of people doing it. People just don't have that. Right? And so you needed this centralized, or we'll call it this part in the middle, the good enough state of this security. So you know, Alex, you've done some work with a lot of customers. One of the great things about this session is Sandy builds a lot of products and Alex has a lot of time consulting with customers. So we have this great mix. Tell us a bit about who's responsible for these things, Alex, and the process around that that they use to fix it. Alex Shulman (14:45): Yes. And before jumping into this, let me also remind you that I used the lead cloud security for one of the major financials. Sandy Bird (14:52): That's true. Alex Shulman (14:54): So I spent a huge amount of my time developing these guardrails. And while we can develop guardrails, for example, to monitor that logging is not disabled, or for example, everything is encrypted as planned, identity and access management is truly different. Because it is very difficult, we can have certain generic guardrails, but it is very difficult to create guardrails to ensure that everyone is enforcing the principle of least privilege. It's a very tricky thing and it requires understanding of the application. And we don't have this as security teams in many cases. So when security teams, like in your previous chart, when security teams are trying to create these tight policies and control everything, they are typically becoming a bottleneck because they don't have all the data and they cannot scale in a way that is needed to truly support all of the development and cloud teams. So for this, it means we need to bring automation, but first let's discuss indeed who needs to be involved and then we'll discuss how to automate this. So obviously we have the identity and access management and the security team. (16:10): These are the teams building the guardrails, defining identity and access management policies, and creating the rules of the road for everyone. This is their job. But then once we have these policies created, who is responsible to actually implement it? And this typically falls on the development and the Cloud Ops teams, but for them implementing the principle of least privilege is a nice thing, but not the most critical one. And in many cases, even when the security teams are giving this guidance, it is not prescriptive enough for them actually to understand what is the meaning of these security requirements for the roles that I'm creating now for this application. So there is a lot of discussions and many things that need to happen for them to actually understand how to configure these permissions and roles. And finally, we have the SecOps team. It is a very critical team, but they will be handling only the most critical events. (17:14): For example, our account is compromised and we need to wake up someone in the middle of the night right now, but they will not be handling, for example, a role that is overprivileged or a role that is not used for a while. So all of this will go to the development of the Cloud Ops teams. Let's move to the next slide and discuss what is being done today. This is the most common automation flow that we are seeing in the industry with cloud identity and entitlement management solutions schemes that are very popular and many companies actually already have them. But let's discuss what are we doing with this? Obviously most of these dashboards are typically read. As you mentioned, most customers have roles that are not used or overprivileged or have toxic combinations. And even though the systems are integrated with the security operations center, these are not SOC alerts. We will not be in a way kind of putting these incident response team members to solve this role misconfiguration issues. It is not their job. (18:29): So for this, once again, once the identity and access management team defines the rules of the road and what needs to happen, and we have key monitoring and creating these events and alerts, the result of automation that needs to happen through ServiceNow to actually do this auto-ticketing, send this to the development and CloudOps teams, and then help to reduce the load. Because as you can imagine, they're getting a lot of tickets and the fact that there is a role that is not used and may be abused is typically not their main priority. And this is why it's so difficult to fix all these things. And unfortunately in many cases, these teams simply don't have the resources to allocate to bring the system to this desired green state. But Sandy, please share more. I know that you also have a lot of experience with CIEM systems and working with customers and all of these workflows. Sandy Bird (19:29): Yeah. It's interesting when you look at this whole thing, this handing this to the developer as a ticket was kind of this concept of we want the developers involved in security. We want them to do the right thing. We want to shift everything left. And it's interesting, again, looking at the last five years of our life in doing this, to your point, the fixing of the identity problems was never a priority. And there's kind of two reasons why that is. One is there's always another priority. Right? We got to get the workload out. We have to fix the vulnerability. That's super critical. There's all of those things. But then there's also the one where the developers aren't really incentivized to do it in any way unless the management and leadership of the company believes it's a priority. And honestly, if you run by governance rules and the governance rules say you'll fix vulnerabilities on these dates and you will get to least privilege, but least privilege doesn't have a CVSS score on it, there's a lot of gray areas to what that is. (20:26): And it'll causes this kind of riff back and forth between the two teams as to what's really needs to be done. And so you just end up with this fight. That said, there's no excuse that people should be putting star permissions everywhere. Sometimes they do, but it's not. You know, you should be linting those things using whatever tools you have before stuff goes into production. So you have reasonable policies. We can't be doing that. And to your point, Alex, you need guard rails for, I think somebody called them the dirty dozen permissions, like stopping the logging data. That can't be done by a developer. It needs to be done by turning off some central control somewhere. And so you need kind of this balance of these two things. But there was this, you know, sometimes you have to get to the bottom before you realize, okay, there's another way to do something and do this. And this was this kind of epiphany that I had last year where, to your point, none of the central teams would put guard rails in because they were so worried they were going to break something. (21:21): They said, we can do it for stopping cloud trail. We can do it for these things that we don't, we know that nobody's using. But I can't stop people from editing the security groups on the machines because the reality is they need to do that. That's part of their job is to roll out infrastructure as part of these scaled workloads. And so they need to be able to do that. I can't block that. And so we took a different look. We said, look, how would we make the development teams involved in the process in a really low friction way for these really sensitive permissions and in a scenario where they need it, be able to give it back to them very quickly. And again, I don't completely take credit for this idea. We saw certain organizations that were super mature that were doing this. (22:03): And what they had discovered was they could actually protect a lot of permissions by simply creating a scenario that when someone used that permission for the first time, and I say someone, could be a human, could be a Terraform deployment, could be whatever, it would happen first in the development environment and then get migrated through staging and then to production. And because of that, if they could catch it the first time it was needed and interact with the person or the team using it and say, hey, you just tried to edit the security group rules. You just tried to create a pre-signed URL. You just tried to make this virtual disk a URL on the internet. That's a bad idea. You just tried to do this. Do you need approval for this? And by allowing the teams to self-approve this, what happened was that 92% of overprivileged things didn't happen anymore because the 92% never asked for it, so the central guardrail worked. In the 8% that did need it, they just made an exemption for that. (23:00): And what's interesting is Amazon over the last couple of years had been talking about attribute-based access, ABAC, which I thought was the most worst idea in the world when I heard it. I'm like, seriously, ad tag becomes the most sensitive permission in your whole cloud. But what's interesting is if you implement it right, there's a way to make very quick changes to these centralized guardrails and protect the guardrails you have in place and actually get your access back almost instantly. And so this is this kind of aha moment that we can use some of these crazy cloud providers' complex tooling that they've created to create an engagement with the development teams to basically allow them to overprivilege things when they develop them because they don't know what to do, but put the centralized guardrails on top of them and use things like attribute-based access and real time alerting when people bump into the guard rails to give them back the access when they need it. And so again, we spent a lot of time on this over the last little while. (23:55): As Joseph said, there's a free offer if people want to give this a try. It's a different way to do it. It's not perfect least privilege. It's not the epiphany that we all wanted five years ago that says we had all the logs. We have all the identity. Let's make it all perfect. But for those people that are sitting in that Wild West zone trying to figure out how they're going to get to perfection and they'd have a team of a half a person a week to do it, this is an amazing spot to start where literally within a couple days, you can get to really close to least privilege in doing that. (24:22): So again, that's the world I've spent my last couple of months certainly focused on, Alex. Alex, you spent some time on lifecycle. I actually think this is one of the most important things people need to do all the time. And so we built this cloud permission firewall to give access back right away, but it doesn't stop the need for least privilege in the important areas of your cloud. If you have most sensitive data, you still need to get the least privilege. Take us through this kind of lifecycle 'cause this is really important. Alex Shulman (24:50): Yes. Thanks, Sandy. And let me highlight also, it is critical. Right? Although we discussed it we're not waking people in the middle of the night because of access control, but most of the breaches that we've seen today involve some aspects of compromised access control. So this problem is big. It is critical. We need to remediate it and we need to continuously manage it through automation, as Sandy, you, just described. But what is the lifecycle? For most organizations, the first step is to remediate. Right? Let's use automation. Let's use tools. Let's clean our environment and remove these unnecessary permissions. But just removing them is not enough. We need to ensure that things are not going again into production. So it is through, first, education of all the teams. Second, bringing them these guardrails and tools that will protect them, that will give them another step to check are they doing the right thing? And the more we will protect them when they're deploying, the better the situation because we don't want these misconfigurations to go into production. (26:03): So the more checks we can add pre-deployment, for example, as Sandy just described, checking is this really what you need? Or having scanning tools checking that they're not granting full privileges when they don't need this. The more we will add at these pre-deployment phases, the better the situation because then we don't need to spend too much time on remediating. Right? As I described, it takes sometimes too long to remediate. So the flow is first to remediate. Then ensure that new mistakes are not going to production, and then have this automation and monitoring in place to get your environments under control. And it is very critical to set this as a strategy, have this agreed upon between the teams, communicate that this is what we are doing, and then keep the environments under control. Because unfortunately, the situation for many organizations right now, is just too risky and they need to do everything possible to de-risk and manage this workflow just throughout their life cycle. So back to you, Sandy. I know that you're also working on these topics with your [inaudible 00:27:16] Sandy Bird (27:16): Yeah. This is something that we see that's so interesting. And again, stories are great from the field. Right? You know, we spend all this time building these CIEM products trying to get people to say, and I'll use the simplest example, this identity hasn't been any used in a year. Let's delete it. And we had full automation for that in our product. And we would find scenarios where customers have thousands and thousands of these. We'd say, please just run this automation. We just clean these up. They're unused. And the customers would come back. I always wondered why? Why aren't people deleting these things? It's so easy. And we spent a lot of time with them. And what we discovered was a lot of times the person that put that identity there doesn't even work for the company anymore. They're long gone. No one really knows how it was configured or what it was configured for. So no one wants to take ownership of it, but they're all scared to delete it because if they were to delete it, and it's really important, they have no idea how to put it back. (28:11): And this gets really complicated in the clouds because what actually happens to these identities are they're often referenced in other things. They're referenced in a resource-based policy, which might be in a different account. If it's something that has an access key and you delete it and the key material goes away, you can never generate that key material again, but that may be used in an application somewhere. And so they were just scared to delete these things. And so again, using automation, we found a better way. We said, what if we didn't delete them? What if we just took their permissions away? So again, most of the cloud providers support a way to do a deny scenario. And so you could deny them and say, and nothing it does will work, but just deny it. And people all of a sudden became very comfortable with it. They were willing to do this to thousands of things because they knew that if one of the thousand woke back up and said, I actually need to run, there was a way to put it back exactly like it was before, and it just made people comfortable. (29:04): And it was again, another one of these kind of lessons learned in the field that says, perfection isn't always what people need. They need something that meets them where they are today in their current situation, and they can implement quickly and do this. But the monitoring and remediation becomes an interesting state there and to say, quite literally it's been quarantined for three years, surely we can delete it now. Right? You know, there has to be a scenario where you go back to this world and say, we actually have to clean up our mess sometime [inaudible 00:29:32] Look, Alex and I- Alex Shulman (29:33): [inaudible 00:29:34]. Sandy Bird (29:34): Yeah. Alex and I, this is our kind of recommendation slides for this. We'll spend a minute each and then we're just going to open it up for Q&A. We'd love to talk to everybody. If you have questions, I think Karen's going to come back on stage. She's going to run the Q&A for us on that side. Again, I can summarize this entire slide for me in two things. Most of your cloud needs to be good enough. You have development environments. You have sandboxes. You have staging environments, but you don't hold your most sensitive crown jewels and sensitive data there. You need to get some really good centralized controls. (30:05): You've got to get developers doing good enough type security there. You need the teams involved, and you need a way to grant them privileges so they can do stuff quickly. You've got to do that. There is one part of your cloud though that holds your most sensitive data. And for that area, wherever it is, you actually have to do least privilege right. And so if you separate your whole world into these two zones, you can actually start to think about it in a really effective way, I think. Alex, what are your closing thoughts? Alex Shulman (30:34): Yes. Two points from my side on why we cannot do this manually. And there are two reasons for this. Sometimes when the data is misconfigured, humans cannot respond fast enough to close the access and prevent data exposure. It will always take at least two hours for humans to respond. This is why we need tools. Second, because of the complexity of our cloud systems, humans cannot analyze all the potential flows of toxic combinations or privilege escalation attack scenarios. We can do this only through code and automation. So this is why we do need to bring solutions to manage this through code. But then we also need to build a corporate strategy around this. What are the rules of the road? What is the expected behavior? How we are mediating things? And how we are preventing new mistakes from happening in production? So these are my closing thoughts, but can talk about this topic for hours. So anyone who is interested, please reach out and would love to continue this discussion. Sandy Bird (31:42): Absolutely. Karen Levy (31:45): All right. I'm back. Thank you very much. What a great amount of knowledge, both on the technical side and the experience. Thank you for sharing with us. And of course we have some questions from the audience. Reminder you can chat your questions, put them in the Q&A, and I will ask them to Alex and Sandy. First off, somebody is just wondering what's the best way to learn about cloud IAM? We touched the surface today, but do you have recommendations for people that want to go further? Maybe they're responsible for this in their role and they just need some better education. Alex Shulman (32:16): Yes. Thank you. So maybe I can start with some generic recommendations and then, Sandy, I know that you have plenty of materials on this topic. Yes. From my side, first of all, follow communities like the Cloud Security Alliance or the CloudSec Community where many people are just publishing what they're noticing, what is possible. There are always new ways to escalate privilege that people are finding and they're publishing this. So follow these blogs. Read about what may go wrong because this will help you to understand how to better protect your systems. So just communities and blogs, that's my recommendation. Sandy, what about you? Sandy Bird (32:58): Yep. I have again, two scenarios which are interesting. One, if you're looking for more generalized knowledge and you're reading the communities and blogs and stuff, never forget that each of the clouds has a completely different IAM model. And what you're learning from one does not apply to the other. So when you're, again, if you're looking up, talk about centralized deny controls in AWS, it's going to be different in Azure, which is an allow model versus a deny bottle versus GCP. And so just remember it doesn't transfer over, so you have to learn each one. So the one you should specialize in is the one you're using the most of. The second thing is that if you want to get a little bit practical and you want to play with the permissions, the best thing in the world you can do is stand up like a cloud tenant or org for yourself to try some of these things in and use it. (33:48): A company called Rhino Security that has some interesting things called CloudGoat which are these kind of amazingly vulnerable AWS accounts you can create and you can try some of these attacks on them. And it's a great way to learn the way that these things work and how you can actually abuse the IAM models to gain access to sensitive things in the cloud. So again, those are great ways to do this. We also, at Sonrai Security, have a massive blog session. If you're interested in some of the centralized guardrails, we've got some great blogs on writing SCPs and certain SCPs you can use just kind of carte blanche and they just work. And then other ones where you know what, you've got to put these kind of controls in place to make sure that people can get the permissions back when they need them. Karen Levy (34:31): All right. Great. Next question, different topic a little bit. What is the proper divide between IAM that is deployed from IAC infrastructure as code and IAM that is deployed from identity governance systems and directories? Sandy Bird (34:45): Yeah. Interesting. Do you want this one, Alex, or do you want me? Alex Shulman (34:50): Maybe once again, I can start with my kind of 2 cents. First, through infrastructure as code, you're typically deploying permissions that are related to cloud resources or services. You still need to have your corporate integration with your single sign-on and other systems. And ideally large organizations should be managing their users and groups in their corporate systems and integrating this with the cloud. So my answer is that you need both. You need to control both, and you need to have clear policies for both, both on the identity and access management side, how are you integrating, what is allowed, what is not allowed? And then infrastructure is code side, what is allowed, and you need to have these tools scanning your infrastructure's code that you are not deploying over privileged things. Sandy, what are your thoughts? Sandy Bird (35:44): Yeah. I have this two-by-two matrix in my head that I always give to people. You have on the people side, as you say, you're going to have something that's doing governance, that's you're storing in a corporate directory somewhere with some groups. And based on those groups, you're giving access to those people in the cloud. But you have to have two parts to that. One, you have to have, we'll call it view access versus privileged access. And you need different controls on those. And I find that the common governance solutions, like whatever, say you're using SailPoint to put access into AWS using identity center, there's not enough granularity there often to break out what's privileged access versus view access and things like that. Stuff just becomes too wide. And then when you get into the, we'll call it the machine identity side of this, which may be deployed with infrastructure as code, it may be deployed with some really interesting governance, depending on how mature you are as an organization. (36:42): There you have to worry about two things, the identities themselves and their resources and how they get created and the policies on them, but then also any access key material that gets generated and how that's stored, that becomes secrets and then you need to make sure nothing else can access those. And so there's this kind of two-by-two metrics where it's people standard access into the cloud with then very privileged access. And then you have the non-people side, which is the machine identities that are being used, but then also the secrets and it's different rules and regs across all of those. We could do a whole nother 45 minute session on that entire two-by-two metrics. Karen Levy (37:17): Okay. One last question, keeping an eye on time, we have about three minutes for wrap up. This is on the people side of things. So we've talked a lot about process and technology, but if you were to start from scratch in a new organization, how would you architect the team responsibility around cloud IAM? Sandy Bird (37:38): Alex, you're the consultant. You should answer this one. Alex Shulman (37:42): First, I would quote the cloud providers. It's the shared responsibility model. So this is why we do need all of the teams to be involved. This is not just the problem of the IAM team or the security team. Everyone needs to understand they're part of the shared responsibility model. So we're building from scratch first, clarifying who is responsible for what. As we discussed identity and access management, setting up the governance, the requirements, the policies, developers, and Cloud Ops need to follow the principle of least privilege. Clarifying what it means and giving prescriptive guidance, giving these examples, not just quoting standards and frameworks, but translating this to what it means to them, what are they expected to deploy, and how their deployments will be checked, and how their deployments will be modified through automation if them misconfigured. So creating all these rules of the road and communicating things, and then following this remediation lifecycle from the very beginning. Because most probably, even if you're starting from scratch, there are mistakes, but you want to catch them early and ensure that they're not happening again. Sandy, what are your thoughts? Sandy Bird (39:04): I will tell you. So all of that, and then I'll tell you about the two personalities you need in that centralized team that's doing the identity stuff. You need somebody who is a phenomenal leader that can work with very different organizations and very different personalities because this, as Alex says, involves everybody. You're going to be talking to security people, identity people, the actual developers on the ground and the cloud infrastructure people, and you're going to have support tickets with the cloud providers. So you need a leader that can deal with all of those personalities and actually help foster this through the organization because the organization has to be a priority for them. But you also need an expert. Whatever cloud you're in, if you're an Amazon, if you're an Azure or GCP, whatever it is, you need an expert on identity in that cloud that understands it end to end. (39:50): Because if you don't, you'll end up with this scenario. And we see this on our sales call sometime and kind of talk about all of this, and the person will be like, we don't have this problem. We use Okta for our people to log into cloud, and that controls all the conditional access. I don't understand why we're talking to you. And that statement alone tells you exactly how secure their cloud probably is, because it's not just a people problem getting into your cloud. It's all these non-people identities. It's all these workload identities. The complexity of resource policies and boundary conditions and all these things that you're going to hear in the next sessions are so important. So I'm sure Karen's going to give me the hook very shortly. So again, just to wrap up, I want to thank absolutely everybody for enjoying this session. Alex and I were first in the day. There's some great sessions coming up all day long. If you guys have any questions, please drop them in the Q&A and in the chat and we'll answer them all day as we're here. Karen Levy (40:42): [inaudible 00:40:44]. Sandy Bird (40:44): Thank you, Alex, by the way. Alex Shulman (40:49): Great. Thank you. Thank you, Sandy. Thank you all. Have a great day. Karen Levy (40:50): Thank you, Sandy. Thank you, Alex. We will continue to answer quest-