Accelerate Identity Security Maturity in the Cloud

Imagine accelerating your identity security maturity in the vast expanse of the cloud. At the Access 2023 Cloud Identity Access and Permission Summit, Chad Lorenc, a seasoned security manager from AWS, shared invaluable insights on mastering this vital aspect of cybersecurity. Key Principles: Chad emphasized that all cloud access is privileged access. He stressed the need for understanding roles and centralizing them through robust organizational structures. By mapping roles to identity policies, businesses can tailor security measures to their unique needs. Understanding Cloud Identities: In the complex cloud landscape, comprehending the nuances of identities is paramount. Chad highlighted various identity types, from cloud users to root users. This knowledge forms the bedrock of secure cloud environments. Phases of Identity Security Maturity: Chad outlined a roadmap for your journey. Begin by establishing a baseline of identities. Then, build protections around your business objectives and fine-tune them for maximum efficiency. The ultimate phase involves continuous monitoring, ensuring your security evolves with your needs. Aligning Security with Business: Don’t just implement security measures; integrate them with your business objectives. Chad urged against merely promoting "least privilege". Instead, showcase how it streamlines operations, ensures compliance, reduces errors, fortifies security, and facilitates scalability. Key Takeaways:

• Understand Identities: Recognize the diverse identity types in the cloud—from users to cloud owners.
• Align Security: Integrate security seamlessly with your business objectives for tangible benefits.
• Continuous Monitoring: Implement robust monitoring and response strategies, ensuring your identity security stays ahead of the curve.

Embark on this transformative journey armed with knowledge, and watch as your cloud security reaches new heights.

Jeff Moncrief (00:00): Hi, everyone. Welcome to Access 2023, the Cloud Identity Access and Permission Summit. We are so excited that you're here to join us today. We have some incredible sessions lined up, some incredible speakers, and my name is Jeff Moncrief. I'm Sonrai's field CTO, and I also run the sales engineering team. I'm joined today with my incredible host, Karen. Karen, do you want to say hello? Karen Levy (00:21): Hi everyone. Karen Levy of the product marketing here. And couldn't be more excited about all the content we have lined up today, Jeff. Jeff Moncrief (00:28): Awesome, awesome. I am so excited. We've got some, like I said, incredible speakers, some live demonstrations, a lot of great advice and just lessons learned around this world that we live in, Karen, of cloud infrastructure, entitlements management. And just a little bit about myself. I've been in InfoSec for a little over 20 years now and focus primarily on public cloud security for the last six years. And I'm on my fourth year now here at Sonrai just where I live, and I'm immersed in this world of access and privilege. Just really, really excited about today's session. Karen? Karen Levy (01:03): Great. Hi, everyone. I've also been in security almost 20 years and finishing up my first year here at Sonrai Security. Want to give you a couple of housekeeping rules for the sessions today. We're going to keep it interactive. Lots of content at various levels, interactive thought leadership. Share your questions in the chat, talk to other people in the sessions. Make it interactive. All of our presenters are available to answer questions during and after sessions. All sessions will be recorded and made available as well as all slides that we can make available will be sent out after the session. And with that, I think we're ready to kick it off with our first presenter, Chad Lawrence from AWS who's going to talk about how you can accelerate your identity security maturity in the cloud. Over to you, Chad. Chad Lorenc (01:47): Hello. Thank you for the introduction, and welcome, everyone, to Access, the Cloud Identity Access and Permission Summit. My name is Chad Lawrence. I am a security manager with Professional Services at AWS, and I help customers mature their cloud security at scale. I'm excited to be a keynote for our inaugural kickoff of Access this year. (02:09): In my session, I'm going to talk to you about where you are in your cloud identity journey. I am passionate about cloud identity security, and the reason is when I get a call on somebody's worst day, the first place we start is identity. When I get a call, someone asking me, "How do I start in cloud?" The answer is identity. And when someone calls me and says, "How do I mature my security maturity in the cloud. What's my first step?" We start with identity. Everything in cloud security starts with IAM, identity management. (02:44): We're going to build from that. I'm going to walk you through four phases. These are prescriptive, but you don't have to apply them directly. You don't have to be in a certain phase. It's not bad if you're in one phase or the other. It's simply a roadmap to give you an idea of how to build out your own roadmap on how to mature your identity. Understand it's not perfect, but it should be a basic guideline to give you an idea. Also, we're flying at 1,000 foot level here. We're going to go really fast, we're going to cover lots of topics. I really want to set up all the different talks you're going to hear today that will deep dive into all these different areas. But I want to give you a big picture of how they all fit together, and so that's what today is going to be. There'll be lots of information for you. I have QR codes, I have a reference at the end for the slides when they're sent out. You'll have access to them. Lots and lots of reference material. But go along with me on this journey on how you mature your identity in the cloud. (03:49): And so just some housekeeping. We are going to be sharing with you in this forum where you can have discussions on chat, so feel free to drop anything in chat, any questions, and we will make sure we get those answered. All the speakers will be happy to engage with you throughout the day. (04:13): Let me just jump in and let you know this is how we're going to do it. I'm going to give you a phrase, I'm going to give you a picture, I'm going to give you a maturity rating, and then I'm going to dump all the data on you. What I'm wanting you to remember is either that phrase or that picture and how that relates to a maturity so that you can begin to map where you are and figure out where your next steps are. With that, let's jump on in. (04:42): The first key is by default, all cloud access is privileged access. This is a key principle that I want you to wrap your head around because it's different than what we're used to in identity All access is privileged access in the cloud. In the AWS speak, we call that a principle. Here's my little icon for you to recognize a principle. (05:08): The first thing we do when we're trying to look at maturity is we begin to understand where are we in the business objectives. Where are we mapping to our business? And that very first baseline, you're just trying to get in and you're trying to enable secure cloud access so that you can facilitate innovation in your company. This is the quick and dirty. Hopefully your business isn't ahead of you, but maybe they are and you're trying to come and get this cleaned up. But you want to set your identity baseline as your first step. Again, treat all cloud users as privileged access. Whatever rules you have in your PAM or your privilege access policy, you're going to apply that. And that usually starts with multifactor authentication. First place you want to start. Easy way to make sure that you're protecting your cloud MFA. (06:00): The next is temporary credentials, and I'm going to spend a little bit of time on this. I'm not going to dive deep in very many places, but I do want to talk about this. If you're familiar with PAM solutions, this may be isn't a new idea, but for those of you who aren't, the idea is you are not actually authenticating all the way into your data point on the end or your endpoint, you're actually hitting an intermediary, and that is giving you a token that goes. And that token is time-based, so if anybody intercepts that communication, they're getting a time-based token versus your username password. This is a level of maturity above some of our typical identity solutions and maps more closely to what you'd experience with a privileged access management solution. If you're trying to wrap your head around that, first QR code, temporary credential lab. It's really amazing lets you build and play with the cloud and see how that plays out if you're a hands-on person with your learning. Last of all, most privileged access policies require you to log all access. You want to log access directly into a cloud anytime a principal is doing access, whether that be by console, API, or any other programmatic method. (07:21): The first thing you're going to do is you're going to map those identities in the cloud. What does that look like? First, you're going to figure out what are your roles? And hopefully you're going to centralize that through some kind of organizational structure. You're going to take those roles and you're going to create a single sign-on or a federation. There's no reason to recreate your whole identity provider in the cloud. You want to federate where you've already got roles that align to job descriptions set up. There's usually an internal directory. That internal directory, then you map a dev role to an identity policy in the cloud. Most cloud providers have managed identity policies already set up. These are not perfect, but they're a great place to start. Map your developer to a developer role, map your auditor to a auditor role. Now you can map those groups to groups and you immediately have a baseline of identity that is not any any. Do not start by saying We're developers, "We're developers, we're going to give any any access." There are roles built for that already in your cloud environment. Get started, get in the habit of using roles. (08:37): Another concept to the cloud that I want to set up here is there's actually multiple identities in the cloud. And this is where cloud can get confusing sometimes, and so I want to break that down just a little bit for you. The first thing is the cloud users. These are those privileged access. We call those principles from AWS terms. But those people can go into the cloud, they can build, they can spin up instances, they can build server lists, set databases, push data, pull data. They are master administrators. Principles are your first user that you have to be aware of. However, you're going to have a whole new user base that's going to be application users. And a lot of times you're going to throw something on front of this like a Cognito in AWS, but some kind of a front end that's going to allow you to bring users into the application. But they're not actually coming into those backend resources, and so they are a different level of user. And it's important that you understand when you're talking to cloud people the difference between a cloud user or a principal and an application user. (09:47): The next level, we call them service accounts on-prem. In the cloud, especially AWS terms, we call them resources. There are these resources, they have to have identity policies to access one resource to another. Understanding there's a whole set of identity policies between resources. You have users, users to resources, and resources to resources. Those resources to resources are service accounts. They're at the resource level in the cloud, but then you may have even other service accounts that are application to application. (10:24): Next is account owners. Conceptually, AWS works in a structure of accounts. You can bring all these accounts together in an organization, but every account has an account owner. This is really important because those owner identities are actually, from a security standpoint, they're a free threat intelligence service or IDS. Those account owners are the first point of contact if there's a security incident, if there's a finance incident or billing incident. You want to make sure your account owners are defined and clearly set up. That's both primary owners and your alternative contacts like your security contact. The next QR code is using some infrastructure service called a Terraform. And that infrastructure's code allows you to quickly automate and set all the account owners in your organization. Take a look at that. Don't forget account owners. I'm not going to talk about them again, but I always want to make sure we point that out because that's a key identity we don't always recognize in the cloud. (11:34): Then last is the root users. There's really not a whole lot of comparison to root users except in the Unix world where you sign as a user and then you SU to root. These root users are the master users. They can do everything. Super important account. It's actually more important than that privileged account. Root user account is the other identity you need to recognize when building out the cloud. (12:01): That's your baseline. If you can get that understanding and you can put those basic pieces in place, you've started your journey. You're still in the red, but you've moved away from the lost and confused phase. And that's what we're really trying to get to is how do we get those first steps? And you've made your first step into your cloud journey, so what's next? (12:24): Next, we have to create the layers that enable and protect the business. I could have used the overused statement here that identity is the new edge, but that doesn't really go into the full complexity of it. However, just like in on-premise where you could pull a network firewall configuration and you could see the flow in the communication of the apps and the business, that's how identity works in the cloud. It is that connector in those permissions and that flow of data, and it tells you what communicates and what flows to it. And that's why it becomes so important both as a control but also as visibility of who has access to what. (13:08): Again, we always, always, always want to think from a business objective standpoint. When you go to build your defenses, why are you building defenses? You're looking to enhance security while enabling rapid resource provisioning for faster development. Again, you're building guardrails around the business to help them. This is instead of giving a developer access to everything, giving the developer developer access to the environments that he's developing in. You want those developers to be quickly and easily provisioned into that environment without you having to think twice about it. (13:47): The way we do that is we build these fences and gates and guardrails and say, "Okay, I'm going to let you do whatever you want, but I'm going to keep it within these contexts." And there's a few ways to build these boundaries. Some of them are guardrails at the organization level. Some of them I call fences. They're permission boundaries inside accounts. And then there's these gates where you can actually put conditions on specific users or roles. QR code here to help you kind of tease that apart, but it's really important to understand it can look confusing when you map all this out, but the reason you have this granular access is so that you can create closer and closer defined guardrails so that you can provision people into areas without having to do this server with this session like we used to do in firewalls where you can say, "Okay, I know this is the environment you're in. I'm going to give you access to do your things in this environment because I know this environment is contained." It's building that containment. (14:54): The next thing you need to do once you've built that containment is figure out what are my high risk identities? Again, we're taking a security standpoint on this, so once we've gated those in, then we need to look at what are the next highest risk we should worry about? And that goes back to that root user. Lock away that user. That user should never be used. Those keys actually should rarely or never be created. If you need to have some kind of backend admin access or emergency access, build a break glass account. A best practice is not even to build that for the root user but for the role that's going to need to support it. You could build that dev role a break glass account in case the federation or something else broke so that they could get back in. Some great guidance on break glass that gets away from the fear of, oh, I need to have root users. Great article there. Check that out and get some more information on how to build that so that you can eliminate root users from your environment. (16:01): Service accounts. I touched on this also earlier. First of all, never, never, never start by using keys as service accounts. This gets really dangerous. You decide to make an EC2 instance use a key so it can access other resources. Now anybody who uses that EC2 instance can grab that key and use it somewhere else and abuse it with the same roles that you intended for the resource, IE the server compute resource. The way you avoid this is through roles. I really encourage you guys to build roles versus keys. And that's the temporary access we talked about earlier. Eliminate not just for those privileged accounts, don't have them use keys, but also use temporary roles for your service accounts. (16:56): Secrets management is another layer. That's more application to application. But again, don't code passwords or any kind of other authentication method or identity into your apps, use secret management. There's a lot of tools out there for that. But make sure you're doing that. We're eliminating any ability to collect identities within the cloud. If for some reason you can't do those two things, you have another mitigation. It's not nearly as good as not having them, but it is a mitigation, and that is you can rotate the keys often. Worst case is you have a key or a secret and it's not rotated. Make sure secrets are always rotated and keys, if you have to have them, are regularly rotated. (17:46): Now I'm going to shift a little bit left. And the way you shift left in identity is through your automation pipeline. This is where you're delivering infrastructure as code. You can put your identity as code in this pipeline and you can begin to manage how identities are created. And so now you're starting to get into automated identity management and creation within a pipeline. And that's really important at that first phase that you figure out how to incorporate identity into your pipeline. (18:18): And then now you're starting to really get moving. Now we're starting to up that security maturity, so what's the next phase? We've done our build phase. The next phase, and this is the phrase I want you to remember, is nobody wants to buy your lease privilege. The reason this is so important is we forget as security people this is a great principle. It's a terrible, horrible boardroom technique. You do not want to sell your board, and hopefully if you're a vendor, you're not selling lease practice either. Nobody wants to buy lease practice. There is no business outcome of lease practice. It's expensive, and it's not tied to data or any kind of justification. (19:07): Stop selling lease privilege. Instead, business objective. You want to enable a robust lease privilege access control framework that... And here it is. You have lease privilege in there, but what is it is that you're trying to accomplish? Streamline operations, simplify compliance, minimize human error, enhance security processes, facilitate scalability. Now, I've made these broad so that you can grab them. And you should adapt them to your business because your business outcomes should be measurable and have metrics. You should be able to show how much you're saving in compliance, how much you're saving in provisioning, how much you're saving by moving human error out of the equation. You should have your own business statistics to attach that. That's why we want least privilege, not for least privileged sake, not so that we as security practitioners can make a principle, but so that we can help move the business forward. (20:13): How do you do that? You start with risk. You've got to drive down risk. And you do that by the objective. Go back to your objective. What risk are you trying to address? What are you trying to drive out? And work backwards from your data points because that's where your impact is is your data. You're going to build lease privilege from your highest risk data backwards in whatever way enables your business objective. That is the key. If you don't remember anything else from this presentation, remember that. We'll be a lot more successful if we can help educate our boards and our CISOs and our CIOs on the value of lease privilege instead of trying to sell lease privilege on how we're enabling them to their business objectives. As you move towards that, again, focus, focus, focus on business objective. (21:06): Remember when I told you to grab those default provider policies for users? Now it's time to go back and customize it to your business. Now don't just use the generic cloud ones, but start customizing those identity policies so they fit you. The next level of tuning is get a baseline tool. Understand who's accessing what and how. That's how you're going to get those prescriptive guidance on the identity policies. There's some great tools. IAM Analyzer is one of them. But find a tool that can help you baseline that use. Remember, we're securing those privileged users, those cloud users, and we're securing resources. You're tuning the identity on both of those; and make sure your tool can do the same. (21:57): Look for opportunities to simplify. This is a huge one. There are often, especially when you're provisioning compute, using some kind of tagging methodology and building your identity based on how things are tagged or how they're identified is an accelerator, especially when provisioning compute. Often called attribute based access control. I'm not going to go into it very deeply here, but be aware there are opportunities like that where you can... Once you understand your business, once you're trying to get to that least privilege, you can actually simplify things. Because we're not trying to make things more complex, you want to keep low operational overhead as you move towards this lease privilege. (22:41): Use automated tools to identify high risk. It's really key that you understand what tools are out there. It doesn't matter what tool you use so much as it's important that you understand what you're trying to measure for and towards from that business objective. Look for those high risk ones. Role chaining, cross account access, and unattended public access. Role chaining is when someone uses one role to access another role and they start to build privileges. It's something you have to be aware of. In the cloud, it's a little bit unique. I encourage you to look into that. Cross account access is when you go from one account to another. Again, going back to our boundaries, making sure you understand where people are breaking out of those boundaries that you set up and that those are intended. And last of all, of course, unintended public access. (23:40): What's our next step? You don't know what you don't know. And this one I know is a little bit more cliche. At the end of the day, monitor, monitor, monitor. The key to identity access is to really baseline, build what you're going to do, but then monitor it. Again, monitoring, you want to tie to your business objective. You want to be so confident in your monitoring that you can instantly provision users and environments. That is the goal. That's how you enable the business. That's how you speed delivery to market and how you drive efficiency. (24:21): Some of the infrastructure behind that; pipelines. You can do inspection and enforcement of identity and access controls in your pipelines before they ever go to the cloud. Great protective, preventative measure. You should be, at this point in your maturity, moving everything to your pipeline. You want to be able to detect. I'm a big fan of honey tokens. If you're not familiar with that, check out the link. Great way to enhance your monitoring. If someone grabs a honey token you've placed around, you instantly know you have a problem. Monitor for any changed identities or roles, you should have some kind of change management process that you can track and tie that to. Otherwise, that's a great indicator. (25:08): Root key usage is another key. You should not have any key usage except maybe the few you defined as exceptions, and you should not have any root usage. As soon as you see that, that's an incident. Another key monitoring place. There's a concept in IAM that we call entropy. That is your IAM will get worse and worse unless you monitor and maintain it. People will gain permissions, they'll abuse permissions, make sure that you're doing the basic blocking tackling, that you have a way or a tool or a process that's looking at unused identities, stale identities, overly permissive identities, unused. This can be both in resources and in users, so keep in mind that we're looking at both of those. And I encourage you to extend that to your service accounts, even your secrets management. (26:07): Last of all, respond. We have to know how to respond. Tying this back to your internal processes and your internal teams is key. Red, blue teaming, if you don't understand what your risks are, it's really hard to know what to monitor. Encourage you to check out, IAM Vulnerable. It's a great exercise to help you understand what your risks are. Bring in third parties to give you pen tests and oversight; another great way to validate your thing. And last of all, make sure your incident response teams have some kind of playbooks and analysis. Make sure they understand what tools they have in the cloud to do that analysis. Great blog here on how to use some native tools to do analysis for your IAM. (26:55): Now you're really raising the bar, you're really pushing your maturity to the top, so where do we go now? It's not a security presentation if we don't have the four slides in the cycle. But we're going to baseline with that privileged access user. Everything's privilege. We're going to build around the business. We're going to tune, and we're not going to sell lease privilege, but we're going to tune to business enablement. And last of all is the monitoring. You have to know what you don't know. (27:34): That's it. The last big question that I always come to is how do I get to 100%? The goal, and we definitely have customers here, is humans do not need access to production In cloud accounts. You can do everything through pipelines and there's no human access in the cloud. That's really where you want to go. That simplifies everything through the stack for building and monitoring and base lining. (28:03): Hopefully that gives you a vision of where we want to go. I know that we have maybe a couple minutes for questions, and so I want to thank everybody for coming. Godspeed on your cloud journey. And I want to give it back to Karen for any questions we might have. Karen Levy (28:20): Chad, thank you so much. You clearly have a wealth of knowledge. What a great way to start our summit. I really appreciate how programmatic and prescriptive those maturity levels are for the audience. I think we have about one minute to quickly address one question that came in. I think everyone's trying to figure out how do I grade myself? Can you quickly tell us how do I know at what stage I am? How do I just level set myself? Chad Lorenc (28:45): Yeah. And I think that real key is to go back and look, hey, do I know my access? Can I baseline it? No, I can't baseline it. I'm probably in that first phase. Am I at a place where I'm building those constructs? If I'm not, I'm probably not there. If I am, I'm probably at that phase if you know how to monitor those constructs. Very high level, do I know what I have? Am I building protections? Am I monitoring protections... Or am I tuning protections? And then am I monitoring the protections? And you may have that journey both in a project and the bigger. Your bigger may be moving along that, and you may introduce a new project or a new role, and that role may be at a different maturity model, so there's probably an opportunity to break this out and rate by app or by group as well. Karen Levy (29:38): Great. That keeps it really simple. Thanks again, Chad. We're up against time. I'm going to thank you again and welcome everyone. Join us for the next session. Thank you.