IAM in the Cloud: Successes, Pitfalls, and Lessons Learned

Chad Lorenc (00:00): All right. Thank you for having me. Once again, I'm Chad Lorenc. I actually manage a large team of security professionals that do professional services for AWS, for our commercial accounts in the US. So, we have a lot of opportunities, have a lot of visibility into different customers, and we've been able to recognize some typical pitfalls, and even some of the thinking around it that tends to get people stuck in those places, and just some lessons learned and even some patterns that we can give you today that can help you get unstuck or can help you plan better for the future. So, hopefully this is a really valuable session. I've packed tons of information in here, so I'm going to go really fast. (00:41): When I get to the patterns, I also publish QR codes, so I promise I won't hack you with them, but take a look at those. I didn't let the marketing team link through them, so no one's going to hunt you down or chase you down. But those patterns are patterns that my teams developed to help customers get unstuck from some of these scenarios. So, with that, let's start talking about the success. We're going to start by talking about where you start with IAM. We're going to talk about how you check your plumbing. So, pipelines is really a key concept and it's really important for IAM in the cloud. We've talk about roles, which is probably more what you expect in some of the IAM, but then I'm going to get past roles. And by the way, if you didn't see Rich's session on SCPs and stuff, that was a great session. He went deeper into roles than I will, so I encourage you to go check that one out if you haven't. (01:30): I'm going to talk a little bit more about ownership. So, who should be provisioning and managing these permissions? Because that RACI can get complicated. It doesn't look like anything on-premise. And so, you really have to think through this in the cloud. So, we're going to talk about that and give you some patterns for that as well. We're also going to talk about the importance of connecting your IAM alerts to your SOC, and why that's so important in the cloud, and really tease apart a little bit more about identity as the edge is a nice cliche, but it doesn't mean anything. We're going to tell you what specific things you should be doing as far as using identity as an edge and how that plays out in security operations. And then last, entropy is a real thing that is a disorder comes to all systems. IAM has a natural disorder more so than even on-premise. And so, it's really important that there's actually a management strategy for your IAM in the cloud. (02:31): So, I'm also going to talk about some of those anti-patterns, and processes, and thinking that people get stuck in. One account to rule them all, it's just a pipeline. It's just read-only access. It's just a service. Set it and forget it. If you've heard these things, if you've said these things, you're probably in a mindset that's going to set you to a pitfall and we're going to talk a little bit more about that. So, that's our session for today. Again, I'm Chad Lorenc. I've been in security for a really long time. If you've been in longer than me, you probably carried a floppy disk and a gun. And yes, I did learn the Rainbow series. So, I've always loved cutting edge. I actually even got one of the early beta iPhones and helped them understand why I would not put them on my corporate network, and wrote all the controls that now Apple uses. So, you're welcome for that. (03:25): But yeah, I had an opportunity to unblock iPhones of the network, so I've always loved being on the edge. I've always been a hacker. I did hack my college mainframe as my first hack from a thin terminal, but I wouldn't recommend it. So, I'd love to connect with you on LinkedIn, so feel free to connect with me. That's usually the easiest way to get hold of me and it avoids all the sales teams, so you can talk to me directly. I am an engineer, and an implementer, and a manager of Teams and so they don't let me see sales numbers. So, I'm a safe person to reach out to and I will not follow up with you from anything in this organization. So, I just wanted to let you know that. (04:04): Wanted to talk about where you start. And we're going to start backwards. We're going to start with the wrong thinking. The thinking, and admittedly this was even a pattern in the early days of the cloud, is we're going to create one account to rule them all. It'll be easier if we can manage it all in one place. This thinking is broken and I'll talk to that in a minute. It's easier to audit. This also ends up not being true. It is more resilient. Now, those first two can be logical assumptions. More resilient probably there should be an inherent, if I only have one account, I'm probably not more resilient, and scales easily. There's actually a more complicated piece to this resilient scales easier. There are some very real IAM limitations as far as total permissions and boundaries that you can go that are hard set in AWS. So, you will reach a point if you're using a single account where you can no longer provision users or limit controls and access. So, one account to rule them out will get you in trouble really quickly at AWS. (05:15): There is a managed organization approach. This is really important and one of the reasons why is some of our basic security principles, just like you wouldn't save your server logs on the server, because if the server is compromised now your logs are somewhat meaningless, same thing's true in the cloud. There's natural boundaries created by accounts. You can take logs out of accounts and bring them into an audit or security accounts, and now you have that non-repudiation, that protection. Accounts in general create natural control boundaries and I'm going to deep dive into that. It also enables that single sign-on. So, you have a single sign-on to all your accounts and you can connect to your normal directories and services that you use natively. (06:02): Also, those boundaries not only create security boundaries, but they also create protection. So, one team can't do a really bad change that takes down the whole organization, and that's where we get into some of that resiliency and scale. The other thing that you can do in the cloud, and I'm just going to touch on real quickly here because it does have an IAM overlay, it was really hard to set up blue-green environments on-premise. It was very expensive. In the cloud, you can build those, you can spin them up, you can test them, you can tear them down with little to no cost. It also allows you to experiment with permissions. It also allows you to do things in a test account without having to do them in production. So, there's a lot of flexibility that comes with organizations and having a really clear organization strategy that will help drive and simplify your IAM. (06:54): I'm going to take this from a really high level quickly here though is, there's this policy pyramid. So, the reality is, cloud does not actually work on a lease privileged principle. It works from a how do you push permissions down to the lowest level that's appropriate? So, the idea is, instead of trying to have a central team that tells everybody what to do and it gets to be the bottleneck for everything, that doesn't work on-premise anyway, but it really doesn't work in a dynamic environment in the cloud. Instead in the cloud, we create these concept of guardrails. Which is first the SCPs, which again we have been talked about earlier today, that you can broadly apply. And these are the absolute you don't do. This is the admin, this is the controls, these are the regions you don't go into. You begin to build out those guardrails. (07:48): And then you push down from there and you say, okay, these are the things that nobody can do or only these teams can do. And you get to those permission boundaries and you say, these are only the networks that it can come through with VPC. These are the sessions and you start to put limits on what sessions can do. So, it's not who we get to the very bottom of the policy pyramid that you get to normal on-premise identity where you're talking about identity policies for people. (08:17): Also notice there's resource policies which are non-human identities that you're defining as well as your overlay with your data encryption protection. So, you get finer and finer detail, and the idea is you're pushing that control down the pyramid. And organizations are one of the keys that enable this. Organizations at the top level and then account boundaries help enable these different levels. So, that is the first key to IAM. If you get this right, you'll at least be set up to have things correct in the future. (08:51): Next thing also a unique idea on the cloud is this idea a pipeline. The reality is, most customers have a leaky pipe. The philosophy that gets you in trouble here is it's just a pipeline. It needs access to everything because it's a pipeline that provisions. That's actually not true. We could just use an access key. You heard in some of the earlier sessions, never use an access key. That includes for your pipeline. That access key can do all kinds of damage to your environment. And it's sitting there in your pipeline for anybody who has access to that or could abuse that, they now have entire access to your cloud environment. And this is a real unintended access opportunity for organizations to find themselves in a lot of trouble. So, again, even if your vendor tells you to put an access key on the pipeline, do not do that. (09:52): Trust. So, I'm going to shift here and I need to define that. So, the pipeline has to have permission into the cloud and you have to define that. The pipeline also can provision access to the cloud. So, as we make that shift, your pipeline should not just trust any configuration it gets to push into the cloud from an identity perspective. It also should not just automatically trust, "Hey, if it's in the repo, it's going to be a good policy and I should trust it and I should provision that IAM." Your access control actually begins at the pipe for the cloud. You have to limit access based on function, that includes the pipeline itself. You need to assume roles or worst case, rotate secrets, but assume roles is the best practice. That is instead of an access key. And I'm going to give you a pattern here so you can see what that looks like. (10:50): So, again, now we're shifting that boundary. In your pipeline, you need to build role checks. There's a number of different role checkers that you can put into pipelines. You need to build the role checker into your pipeline to make sure that roles are not being provisioned incorrectly. That starts with the basic don't provision star or any access to certain things, but it gets a lot more granular from there. So, make sure you have those checks built into your pipelines. (11:21): And I want to go back to that permission of the pipeline. This is the role vending machine. This is built by one of my brilliant engineers, Benjamin Morris. And it's built in Terraform just because that's a very common pattern, get hub to Terraform. So, that's what this is built in. If you don't have those, you can actually look at this code and probably modify it for any design, but that's the most common one we've built it for. So, if you want to scan on that, that'll take you to the repo where you can see this. But what this does is when someone pushes a request, it goes and looks at what is the access needed to provision this to the cloud. It then on the backend, builds that permission, sends it to an admin for approval. So, now you have someone actually looking at what is this trying to do in this code and what access does it need? So, it's a great way to build in a peer review that's focused on that access piece. (12:18): When the admin approves it, that actually builds the assume role in the cloud. And so, now when the pipeline pushes, it will assume the role that has the permissions needed to it and deploy it. So, this is a great way to make sure that process is not abused in any way and that you have some kind of oversight. So, I honestly think every pipeline in the cloud should have this pattern. And for some reason it's not out there until we built it. But this was our number one recommendation. I highly recommend you take some time to look at this. And feel free to make comments or questions in the repo too. I know that we pretty actively monitor that. (13:02): So, let's go into the next piece, the check your role. So, we talked a little bit about this in the pipeline. Everyone loves to argue with me on this, but I can show you case after case, every role in the cloud should be treated as privileged. So, from an IAM onsite, what you consider privileged roles, what you put through a privileged access manager, every role in the cloud is actually a privileged role. So, let me respond with your first argument, which is, it's a read-only role. Is it? Let's grab a managed role that AWS manages that is a read-only role. It's going to allow you get list and search on every resource in the environment. Is that a read-only role? (13:56): So, think about your data that's sitting in S3 buckets that can be get... you can pull it, you can list it, and you can search it. This is not an uncommon read-only role. So, be aware. Does your read-only role allow you to read or see privileged data? Does it allow you to access or leverage a resource's permissions? Because if you can change the resource's permissions, then it doesn't really matter. It's not really a read-access only. Can you see secrets or passwords and code? Can you roll chain to more access? (14:33): So, let me give some access. Every role in the cloud is one step from a privileged access role. And I absolutely can prove that. Every role is one step from a privileged access role. And that's why every cloud role should be treated as a privileged role. One is this concept of role-chaining. So, I can go to a device and assume that device's role, and now I have those permissions. So, I'm beginning to accumulate access if you will. And this begins to build up to create what we call toxic combinations, where now this read-only person can provision whatever they want in the cloud. That would be maybe I took over a Lambda, I assume the Lambda's permissions, Lambda executes code, now I can pretty much do whatever I want in the account. (15:22): Cross-access rules. Sometimes your read-only role has cross-account. So, now we're crossing those account boundaries. And you only have read in... worse, you have only read access in test. But you have a cross-account role and suddenly, that read-only test is a production full-access role. And we've actually seen this happen at customers. So, maybe it's not. If you can assume or use any of those resources, you're going to have a problem. This is a really common problem with EC2 instances by the way. So, if you can create or find a key, so an old provisioning model used to be give your EC2 access with a key. If this read-only access gets you onto an EC2 instance, you can grab that key or you can just use that EC2's access and have that EC2 access as permission. EC2 is right compute. What does compute usually use? It usually uses data. So, it's going back to an S3, or an EBS store, or some other data repository. So, you're effectively with read-only access, probably giving access to data. (16:35): Obviously if you're on an app team and you're like, "Well, there's none of that." If you can see embedded secrets, which is off to the old bad pattern that application developers did between front end to back end into your database, you have access to the database, you have the keys. So, that read-only suddenly gives you data access again. Also simply being able to read certain data so that list, there are cases where we've seen that expose PII or PHI regulated data simply by being able to do that list command depending on how you label your files when you put them in your buckets. So, really, really think about that as you go through. (17:23): So, what does that look like? I want to get really practical here. And this goes back to Richard's talking about the importance of having a strategy. I'm going to give you the key wins, the key things like when we come in as professional services, what are the first things we look at? And we think of frequency versus risk, that traditional, how frequent versus how risky, and what do we need to look at? The first thing we actually do look at is describe and list. This is in the old on-premise model when a attacker was pivoting through your environment, he was looking at your directory, and looking for your file, shares, and all those things, that's how you do it in the cloud. This is describe and list functions of the way you navigate and see around the cloud. So, perhaps if I am on-premise and I'm looking for network scanners, scanning the network as a pre-incident for my SOC, you probably should be looking at describe and list as a pre-incident for your SOC in the cloud. (18:29): Here's where it gets complicated. EC2, Lambda, and DynamoDB. These access permissions grow over time. So, how they're provisioned, which you may have locked down really well, and where they end up, can be dramatically different. So, we really carefully look at these resources because they tend to gain access and they end up having a lot more access than intended. And if it's being done on a broad scale at an EC2 or Lambda level versus a unique resource, you may be giving a lot of people access you don't realize. So, understanding where those access is really key. (19:09): Then we get into the more toxic access. KMS is your key management store. The worst thing would be someone to encrypt your data with your own key management store and steal the key. Not that I've ever heard of any kind of crypto ransomware kind of thing like that, but that would be a theoretical problem. IAM, if they can change your IAM rules, they own your environment, your domain admin on AD effectively, if you have that IAM, those are the toxic permissions that you have to really look at. The other side ones that people don't think about is if someone can change your single sign-on access, that could be bad, especially if maybe you have a compromise on-premise that's trying to leverage into the cloud. If they can affect your network infrastructures like direct connect, we don't see that very often, but high, high impact if they can change network resources. (20:07): So, I'm going to go back to think about that pyramid, and identity is just like on-premises, the wrong thinking. But I'm going to try to help you by breaking down what should that ownership actually look like. So, let's talk a little bit about that. If you're thinking is it's just a service and I'm just provisioning, deprovisioning, you're in trouble. If you think it's just giving people access, you're in trouble. If you think, "I don't need to worry about identity in cloud because it's managed through SSO and I'll just manage it in Okta or AD," you're going to be in trouble. These are the mindsets that get you in trouble. If you think it's not that dynamic in the cloud, you probably don't understand how the cloud works. So, understanding it's extremely dynamic is an important part to figuring out how to manage identity in the cloud. (20:58): Identity is your firewall in the cloud. It limits the boundaries of your organization. It will limit the boundaries of your accounts. So, we're talking about these different boundaries again that you can set up. It limits the boundaries of your resources, like your buckets in your EC2 instances. And the whole idea of all this ownership is create boundaries and guardrails so people can self-provision. So, that dynamic piece of the cloud is self-provisioned and you're building the controls on the top of that equipment. Hopefully you've seen this before. If you've worked identity in AWS, this is the magic key to everything. This will tell you where to troubleshoot to figure out where your access is breaking. What I want to talk to today in this presentation is about... there's a lot of talk of complexity. (21:56): The opposite of complexity is simplicity. Simplicity is not good in IAM because you don't have very much control or flexibility. The complexity of IAM in AWS gives you a ton of control so that you can build these high-level controls versus trying to build them all at the back end. So, when you think of traditional IAM, that's these identity-based policies in the middle. We have these SCPs and resource ones that allow that lockdown. But then we also have permission boundaries on the back of those policies that can limit what those policies can do so that you can give that policy control to that lower account. So, understanding why it's this way will really help you leverage it in a way that makes it valuable versus cumbersome. The worst thing to do is think least privilege and try to lock down every single one of these. You will break everything. That is the wrong way to manage IAM with cloud. It's really that top-down strategy and breaking the funnel down until you can get to that self-provisioned at the dynamic level. (23:14): What does that look like? Again, I'm going to give you a cheat sheet. Those federated roles should be managed by a central team. But when you get to the workload roles with permissions for users, access to resources, application, servicers, that's what you want to get down to that developer level. Permission boundaries that limit what people could do, again, central team. But when you get to IAM users and policies, that is the anti-pattern. Because hopefully, your pattern is that IAM workload roles. If someone needs users or if they want exception policies for specific workloads, that's, again, central team with some leadership overlay because you're probably getting into some risk acceptance at that point. So, there's a really quick, easy RACI to break down of what that begins to look like when you're provisioning. (24:13): So, I'm going to take another look at that and we're going to come back to this fallacy. This is just a service is going to shoot your incident response team in the foot, because this is what it really means. When we say identity is the edge, this is what it really means. It's not provisioning and deprovisioning, it's not people access, it's not managed by SSO. It's actually one of your security perimeters on your edge. And it has to have alerting and tie-ins built to your security operations, including your SOC. You don't want one guy being your cloud security guy trying to figure this all out. You've got to build that security operations support. Things like if a root user is used or created, that should be an automatic incident. Your SOC team should be responding to that instantly. If an IAM user or user key is created, that should be an incident, because we just talked about that RACI only the central team can do that and it has to be exception managed. (25:18): You've got to create an environment where if you see these behaviors, these are the first behaviors people who don't belong in your cloud will do. So, make sure you have a way to manage that. The other piece that you need to really be aware of is cross-account role creation. This starts to undermine those boundaries you've created. There are great cases for cross-account roles, but those need to go through some kind of... this is where you're putting that fine-grained control inspection, is those cross-account roles to make sure that there's an approval process and that makes sense. Because the other stuff we've controlled with guardrails. But this is the one thing that goes around guardrails. So, make sure you have inspection on that. (26:06): So, identity is your data perimeter. So, let's talk about this a little bit deeper. On the identity side, you want to use resource-based policies to control what identity gets to resources. But you can also control what networks get to those. So, here's where that weird identity and firewall overlay works. So, now you're using VPC endpoint policies, overlaid with those IAM to create what is your access control? And that's on the identity level. On the resource level. So, think EC2, S-III bucket, DynamoDB. What identities can access those? You can define that at that top org level at the SCPs. You should know what people need that privilege data and what people should not have it. (26:54): But you can also define at the network level from VPC endpoint policies, who should get access to that? So, again, the network identity overlay. You can also take a network perspective, which is more of a true firewall perspective and say what identities can access what resources? That is a broad policy at your SCP level. And my resources can only be accessed from expected networks. Again, resource-based policies applied to your network VPCs. So, we've boiled this all the way down to what IAM you want to change and manage on this if you go into the roles. So, very great strategy to start from if you're trying to figure out where do I need to live on this? (27:42): Okay. So, this is actually the heart of it, is that in the end, your IAM will enter fee. It has to be maintained. It is not just a user provisioning, deprovisioning process. It's not just an annual manager checkbox audit. Is this what you intended? You can't set it and forget it. So, what you need to do is monitor and maintenance your IAM. You've got to look for those old accounts. These are great targets, these zombie accounts. You've got to make sure the boundaries for your accounts are maintained and a lot of that comes to that cross accounts. You want to watch the resource boundaries and make sure those are not changing. And again, this is the key to allowing that fast-moving cloud dynamic environment. You manage these high levels and you maintain them so that you can trust that self-provisioning at the lower levels. (28:44): This is the risk with the zombie accounts is, someone can find those and access data, and it's going to look normal because nobody ever uses those accounts. So, how do we maintain this? There are two built-in tools inside of AWS that are free that you can use that really help with this. Hopefully, this presentation helps that make a little bit more sense, that the first thing IAM Access Analyzer does is help you figure out where your public access is and where your cross account access is. Which sounds an oddly lot like a firewall looking at North-South, and East-West traffic. Public's your North-South, cross account's your East-West. Access Analyzer also creates those user policies at a least privileged level if you need a starting point, just based on CloudTrail and what... (29:39): CloudTrail is, our access logging mechanism, it'll pull in the logs and say, "Hey, this is what they're using it for right now. Do you want to lock it down to this?" And again, you can look at that and say, wow, they're getting the KMS, I don't want them to do that. I'm going to put an SAP. But yeah, they can keep on doing that. So, I'm going to give them broader access as those resources like EC2 change change. You can validate your policy conditions. So, that big, ugly chart, if you don't want to do it that way, you can build your permissions, put it in as policy validator, and it'll tell you how it's going to respond to that. Also, you can validate those key permissions for public and cross-account access before you provision them. So, again, really interested in those because those maintain your boundaries and your edges. (30:29): The other piece we have is Access Advisor. It lets you know what things can access what. So, again, it's going to reverse engineer that. You can grab a resource and say, "What has access to this?" And it'll tell you, "Hey, these are the things that can access this EC2 instance or this lambda. This is what it can do." So, a people side versus a resource side on a lot of this, but it gives you both those permissions. So, these are great tools, even if you're just trying to learn how identity works in the cloud. There are some other tools to help you. Those tools are really good for spot-checking audit, I would say. They're going to be great ways to audit yourself. I like a little bit more active monitoring and that also scales a lot better in the cloud. And you want this active monitoring to look for privilege escalation, for those over-permissive identities, for role training happening in your environment, for cross-account access. (31:39): So, again, we've touched on all those. Hopefully you have an idea what those means. And then of course your zombie stale roles policies. One of the things that's really helpful, I always like to recommend a free tool and the best free tool and the best paid tool. I really believe in PMapper as a great snapshot scan of some of this information. And one of the reasons I present at this conference is I really do believe in Sonrai as one of the top tools to quickly scale when you're trying to do this privileged management in the cloud. So, highly encourage IAM is really your edge. It is your security in your cloud. You have to understand that. You have to shift from that on-premise thinking. You have to build those network operation ties and security operation ties because IAM Network data protection and SOC, they're all tied together in the cloud. You can't be siloed like you are in on-premise. (32:46): And Sonrai is a great single dashboard to get some of that visibility and to have some of those connections, and a single point of truth. So, again, high recap, one account will rule and break them all. It's just a pipeline that owns your entire environment. It's just read-only access that can exfiltrate data and execute code. It's just a service that will override all the other layers of the security in the cloud, and set it, and forget it until someone external starts managing it for you. So, avoid those pitfalls and hopefully these patterns will set you up for success in the future. And with that, I'm going to invite Joseph to come back on for some of our Q&A. Joseph Barringhaus (33:32): I'm here. I'm here. And I like free tools too. And just a reminder everyone, we have a free tool for everyone that's here today too. I love free tools too. So, just to reminder free in the chat as well. But let's do what we came here for. Q&A, we've got a handful in the Q&A section. Anyone that's got something for the chat, that in the chat or in the Q&A section, we'll get to them right now. We're going to grill, I mean, sorry, dive into questions with Chad. Joaquin asked, what is the name of the tool in GCP, that can be used as IAM Access Analyzer? Well, we're going to ask the AWS guy about GCP. Chad Lorenc (34:10): I would ask why? Why are you doing that? It's Sonrai. Sonrai is the tool. Joseph Barringhaus (34:15): There you go. Good answer. Chad Lorenc (34:17): Because the reality is you're not going to have deep permission management across three clouds. Use a cloud native tool for your primary cloud. If you need to do more, bring in a third party tool like Sonrai. Joseph Barringhaus (34:32): Great answer. Did not expect that. Thank you for that, Chad. So, this is from Tom. Will these privileges grant practices rules work in AWS with Entra, Okta identities? Chad Lorenc (34:44): Yes. So, we do have a number of integrations and patterns with Okta. It does depend on how far you provision them in or whether you're just using them for SQL sign-on. So, there's some intricacies to that question, but yes, there is an interaction between the two of them and it's just understanding where to best apply it. Joseph Barringhaus (35:08): Love it. Okay, I've got this one person didn't say their name but that's okay. We heavily use assume role like you described, but I have a problem seeing assumed role chains. What's the best way to deal with this? I want to curtail lateral movement and still allow self-provisioning. Any tips there, Chad? Chad Lorenc (35:27): It is complicated in AWS today, to be honest with you. There is some tools that you can use with Detective. So, if you're not familiar with Detective, I encourage you to check that out. Detective can give you some of that visibility. Detective is our instant investigation tool. So, there's that. You can also dump it to a security lake and do some assessment there. But the easy answer is still probably Sonrai as the answer. But I would check if you're looking for native tools and you're trying to do this from an incident response or a threat flag checking, if you're doing some threat hunting, start with Detective for threat hunting. That's a great way to go. If you're looking for more active monitoring management, I would do Sonrai. Joseph Barringhaus (36:24): Yeah, I think that's a good call. Not to be a plug the whole time, but we are actually about to show a little bit of how we do what we do. If you want to talk with our team about how we do it to help you get to lease privilege in a few clicks instead of maybe months in some scenarios, or years, that's what we specialize in. All right, back to the questions. Do these tools, Access Analyzers, take into account SCPs permission batteries and resource permissions? From Jadid. Chad Lorenc (36:50): Yeah, so they're going to take you through that whole chain that I showed earlier. So, that's the intent, is to simplify that manual effort and automate it in the AWS way. Joseph Barringhaus (37:02): Love it. This is another GCP, Azure question that I dare ask and you can tell me to skip it too. But I'll ask it and we can move on. There are other open source tools to get privileged identities on GCP and Azure beyond PMapper in AWS. I think the question is are there other open source tools beyond PMapper? Chad Lorenc (37:19): I'm also a big Prowler fan. Prowler will give you visibility to that as well as a lot of other infrastructure pieces. So, if you're just trying to learn some tools and experiment... and again, I like Prowler because it has a free version as well. I worked with Tony in full disclosure. But Prowler is a great way to get started if you just want that snapshot visibility and get that first entry level. So, I would start with Prowler and it works across all three clouds. Joseph Barringhaus (37:53): This is an awesome question. We hear this a lot, not just with Access Analyzer, but with any type of tool like that that shows you a bunch of alerts and doesn't actually make solves. This question is, how do I solve all of the outputs IAM Access Analyzer tells me I need to go solve? I've got a ton of identities not used. Chad Lorenc (38:12): No, I mean this is the complication. It is a lot of work to clean up identities. The further you are behind them, the more effort it is. Again, what we recommend, we come into these cases a lot as ProServe when someone's like, "Oh, man, I've inherited a mess. I need help." Take step back and take your security approach back to that edge approach. You're looking at data network and IAM. Start with your key data. Work backwards from that. Use Access Analyzer to figure out what has access to your key data. Protect all that first. Make sure you have your network right. Make sure you have your IAM right and you're protecting your data. So, protect your environment first. Then do cleanup on the back end. (39:05): The other thing is if you protect your environment, you have data now. And AWS is big fans of data and you can now say, "So, management, I have a problem. This PHI data was exposed to the entire organization for four years and we can't trace who was accessing it. That's a great lead-in for why we should go buy Sonrai or some other tool. If you don't know where your data is, AWS has a service called Macie that will help you discover it if you can define the patterns." So, that would be a pre-step if you don't know what the data is. (39:43): But that was my recommendation, don't tackle IAM for IAM's sake. Tackle it to protect your environment, collect your data, use that as a justification with your management. And again, now that Joseph has his five free accounts, maybe just do Sonrai, and collect the data there, and then you can say this tool would do this for us in all our accounts. But it doesn't matter if it's Prowler, Sonrai, AWS, use the resources you're available to collect the data to justify. Don't go ask them to spend a million dollars to clean up your IAM. You're going to have to tie it to business. Joseph Barringhaus (40:22): I feel like that's a great leadership tip that a lot of people do. They go in and they say, "I want this tool," but they don't explain why you need a tool to solve a problem or the business benefits of it. Awesome leadership move there. Chad, we got a lot of questions about the tooling. Can you just recap really quick, the AWS tools that you mentioned were free that they could use? Access Analyzer, Macie I know is not free, but awesome tool. Can you go through them real quick? Chad Lorenc (40:43): Macie is free for 30 days and we're building a pattern [inaudible 00:40:46] maximize your data discovery in 30 days with Macie. That blog will be out shortly from Jason's- Joseph Barringhaus (40:52): Even better. Macie it is. Great. Chad Lorenc (40:54): So Macie Data Discovery. It has a free 30-day trial. IAM Access Analyzer. And out my brain with the other one. Sorry. Joseph Barringhaus (41:09): Did you say guard duty? Am I wrong? Did you say guard duty? Chad Lorenc (41:12): No, sorry. I'll just go back and pull that for you. Joseph Barringhaus (41:15): Yeah, where was it? Chad Lorenc (41:16): There we go. Joseph Barringhaus (41:16): Thank you. Chad Lorenc (41:16): Access Advisor, not quite sure. Joseph Barringhaus (41:16): Access Advisor. Chad Lorenc (41:20): These are the two native free IAM tools in AWS, that I encourage you to use before you even go look at other tools so that you understand how IAM works and maybe so you understand the time, and effort, and cost so that you can appreciate why you might use a different tool. So, this is a great place to start. I would always start with these two tools, figure out what you know, what you don't know, and then work from there. So, IAM Access Analyzer, access Advisor, and Macie. These are both subtools in the IAM console of AWS. So, just go to IAM and AWS, and you'll find two links in there. Joseph Barringhaus (42:03): I guess you'll find out really quick if you have the permissions to access those services or not. Awesome, awesome session from Chad. Thank you so much again, Chad. Check your probably leaky plumbing. Don't use access keys. Check your roles. Every role should be treated as privileged. Remember, no read-only roles. Or not only. No only read-only roles. But read-only roles can access additional permissions too. There you are as well. Protect against entropy. Dive deep into all of your IAM policies. I want to thank Chad again for joining us today. Find him on LinkedIn, meet them at re:Invent. Chat with us at Sonrai at re:Invent as well.