Automating reporting on compliance controls at cloud scale

Good afternoon, everyone. Uh thank you for joining us. I know it's like the first day of re:Invent, you probably have 100 other things you could do. Uh probably 1000 if you're like extended to Vegas. But uh very thankful to have you here. Uh spending the next one hour with Jeremiah and I, I hope you're all here because we love IAM and want to know more about it. Alright.

Uh so today, we'll be spending time uh talking about the new IAM Access Analyzer features and, and how they can help you on your journey to least privilege. Uh I'm Uj, I'm a principal product manager on the IAM Access Analyzer team and I'm joined here by Jeremiah. He's a senior software development manager on the same team as well.

So to talk about the agenda today, we are going to first start by looking at how AWS or we at AWS think about access controls across a across your AWS environments. Talk about the concept of risk privilege or the principle of risk privilege and specifically who's responsible for orchestrating lease privilege in our AWS environment. And then finally, we are going to talk about a bulk of the session is going to be about IAM Access Analyzer and how it helps you simplify lease privilege or the journey to lease privilege.

Now, we are going to be brave and we are going to be doing live demos. I can assure you these were working like 30 minutes ago. But, but if we run into like a, some kind of kinks or bumps, just bear with us. We'll, we'll make it work. We'll get through it all together. Alright.

Alright. So let's get started. Let's talk about access controls for your AWS estate. And how do you think about all the different access controls that AWS has to offer? Uh so this is a good visual of how we think about access controls within AWS. Um and, and how you can get started. So we broadly classify those as two. So you have data parameters which are co grain controls that you would set primarily at your AWS organization level. So like a multi-account set up. Uh these are things you could think of as like your service control policies, for example. Uh and then you have fine grain permissions which are things like your IAM roles, resource permissions, all of those that you set primarily at the account level or at a per account level.

Now, uh generally when people think about managing permissions for these fine grain permissions, it's like a permissions life cycle. So the way we sort of organize is we think of this as you basically start by setting the right permissions, verifying access over time and then refining permissions um over time uh periodically.

Now there's this definition or concept of lease privilege that I'm sure a lot of you are already familiar with, but I'm gonna still just quickly go through it. Lease privilege essentially means uh that your users should have the right permissions and only the right permissions that they need to build their applications or, or do their jobs.

So talking about lease privilege, uh lease lease privilege is great, right? But, but who is actually responsible for, for getting your environments to lease privilege permissions? Uh well, we think broadly, these are organized in two personas. Now, these might have different names depending on what company you work for. But broadly how we've heard our customers organize is there is a centralized persona which could be like your cloud platform team, your central security team, cloud se there's multiple different names and then you have your decentralized team, which is generally your application team, your developer team, these two personas broadly collaborate to get um your and AWS uh permissions to least privilege.

Um and uh so you would be sort of happy to know that we actually have people representing these two personas right here with us today and that's us. Uh so for the purposes of this session, we are going to be embodying the security team and the developer team and we are going to take you through this session and uh hopefully we'll, we'll do a good job of it.

You draw. Yep, you look different. Oh, yeah. Uh I mean, I'm, I'm the security team. You see Jeremiah security can sometimes do that to you. Sorry, I, I, uh so I'm channeling my inner security team, right? So as my, in my role as a central security team, what is my goal? My goal is essentially to set up builders like Jeremiah up for success to build and to make sure they adhere to my, my company's security standards.

Now, in order to fulfill this goal, I have a few responsibilities, my first responsibility is actually defining what my security standards really are. So these could be defining like what critical permissions should be restricted in terms of the access controls or building preventative guard rails so that those critical permissions are not granted to the people who don't need it. The second is creating data parameters. These are the coarse grain controls that we talked about making sure we, we establish a data parameter and generally that happens at the organization level or at a multi-account level.

The third responsibility that I have is is to actually configure or track or inspect my IAM configurations to make sure that I can actually notify my teams when their permissions go broader than what I expect. And then finally making sure the security team and my builders have the right tools to be able to security securely build in AWS.

So that was my role in the central security team for this session. Specifically, we're gonna focus on the, the, the two roles on the left or on your right, I guess. Uh, and we're going to talk about how do you set the right security standards and inspect permissions for those standards and how do you inspect IAM permissions over time and and notify your teams when they get broad? Alright. So that was my role as the security team.

Hey J Mayo, what do you do as a developer?

Well as a developer, as you might imagine, my goal is to build things, right, build things that satisfy, you know, the business objectives that our company has. But because I know UW is going to hound me if I don't do that with security in mind, it's also my goal to keep him off my back.

So within that goal, I have a few different roles. So one is on the tooling side, basically understand the ecosystem of what things AWS offers, what third party tools are out there for me to use to build things more efficiently, more securely. Also, when it comes to defining permissions, I need to make sure that the resources that I provision in AWS also have the right access. And of course, I i want to do that keeping in mind our company's security standards to make sure that UW is absolutely happy.

And, and then over time, like as, as my application evolves, I want to make sure that I continue to refine and modify those permissions, not only to ensure that it keeps working, but that it doesn't have any more permissions than what it absolutely needs. So that's what I'm going to do and similar to for the purpose of this talk, I'm focused on these two things on the right.

Turns out my right is your right because we're actually kind of looking at the same. I think I got that wrong. That's ok.

Yeah. And so make sure that we adhere to security best practices and make sure that we refine permissions over time so that our application only gets what it needs.

Alright. So now that we understand our respective roles, let's dive into uh IAM Access Analyzer. Um IAM Access Analyzer is a feature within IAM and it helps you analyze, as the name says, analyze access in IAM. Um specifically, it helps you simplify your journey to lease privilege.

Now, lease privilege, the way we want to, we want our customers to think about least privilege is least privilege is not a destination. It is a journey. So the reason, the reason i say that is because as you build applications in AWS, your teams might change, your infrastructure set up, might change, even your use cases might change. So with that in mind, we like to think of you lease privilege as more of a journey than a destination.

Um so as you're on this journey, where does Access Analyzer actually fit in right here? So Access Analyzer basically fits in um when you're setting your fine grain permissions um on on your IAM rolls your resource permissions all of that good stuff.

So diving into this, the the permissions life cycle that we discussed, um Access Analyzer has tools across each of these three steps in the permissions life cycle. Um so Access Analyzer can help you set the right permissions right from the outset. It can help you verify access with findings so that you can review who can access what over time. And it also helps you identify and remove broad access. Um so you can refine permissions over time as well.

So that being said, let's dive right into the the site permissions uh specific uh part of the life cycle. And to do that, I would like a resident developer expert Jeremiah to to walk us through it.

Excellent, cool. Thanks you. Yeah, you want to change places with me maybe. Yeah. Yeah. Ok. I'm not stealing your oh yeah, yeah, you stay over there. Alright.

So yeah, on the set permissions effectively, the reason that I'm handling this part as a developer is because well, in a decentralized model, I'm the one authoring the policies, right that will describe what my application needs. However, I know that Udal cares about what I'm going to write and he has thoughts, he has presumably defined the security standards for our organization or at least contributed to those. And so he would like to review the policies that I'm going to write. But if there's, well, let's say it's not just me, let's say there's 100 of me who are authoring policies, he's going to get overwhelmed. So our goal is to automate policy review and that's what we're trying to do at the set phase.

So before we even create set, before we even upload policies into AWS, we want to make sure that they have been verified to meet our security standards. Ok. And so why do we want to do this? Well, because for me, I want to experiment, I want to build things quickly and but i wanna, you know, i i want to be safe mostly just so doesn't bother me about it. And yeah, and what does want to do? Well, he wants that to happen as smoothly and quickly as possible so that he can focus on other more important things i got things to do. Yeah, he's got things to do. Ok?

So we have for quite some time had this feature in IAM Access Analyzer called policy validation. And what policy validation does is it actually uses a set of, you could think of them as like aws defined best practices as well as like basic syntax checks and things like that to ensure that your policies are functional and coherent. Yep, might even say sane, like there are probably some things you should really think twice about doing. And so you can see this in the console. If you use the IAM policy editor, you'll see as you're editing the policy down at the bottom, there's security warnings, errors, regular warnings and then suggestions for things you should consider and all of those are generated from policy validation.

However, because we're AWS and we make web services and not web consoles. Well, you can also access this functionality via API. So we have a validate policy API and how this works is well as you might very similar to the console, you basically pass your policy into the API it's the only parameter and then we generate findings that get returned to you. And so these include things like if your policy is overly permissive, if you have some kind of syntax error, like you're missing an action could also just be basic JSON syntax challenges or if there are some nonsecurity related best practices, like you're like you're trying to do, I don't know you have a date field but you don't have a valid date in there and then other like stylistic improvements. So just good hygiene.

So if you're not using validate policy today to examine your policies, it's a nice easy, just kind of sanity check to make sure your policy is going to, you know, do something that is reasonable. Ok. However, last night, yes, we announced a brand new feature which is custom policy checks.

So, validate policy will check your policies for things that AWS thinks you should care about, which is very, very broad and very general, but not at all specific to the things that your organization believes are important. So with custom policy checks, we have two new APIs and those two APIs are things that you can configure. And when I say configure, well, you can basically pass in a parameter that says here's the policy and here's the thing that represents my security standard or something that i care about, check the policy against that stuff. Ok?

And how that works is you pass those two things in. So in the case of our check, no new access API um you pass in the it says previous and new policy, but you can think of it as I'm going to pass in a policy and then I'm going to pass in a reference that reference policy could be the old policy. And if you pass in the old policy check, no new access will tell you this new version of the policy does not grant any additional access or it does. Ok. So if you're trying to ensure that things are scoping down over time, you, you could use that kind of a check to ensure that, you know, you're not adding any new permissions.

Of course, sometimes you know, a lot of times developers when they add new functionality will want to add new permissions. So maybe that style of check isn't as valid. So you might want to use something that we would call a reference policy, reference policy. You can think of as kind of like a soft permission boundary. Ok? So you define, yeah, here's kind of the universe of everything that's ok. If you if you are trying to use anything that's outside of this, that should fail, makes sense. Ok?

And in the event that the check fails, you know, policies can get pretty large and you probably have a lot of statements. We've actually also we will return to you which statement contains some offending permission that is failing the check.

Um yeah, the second API which is, is actually a much simpler API is called check access not granted. And so in that case, you pass in the policy that you want to check and you pass in a list of up to 100 actions. And then this API will tell you if that policy is attempting to grant access to any of those actions

So you can think of these as like these are my forbidden actions or my, hey, maybe you shouldn't do those actions. Ok? And similarly, it will return pass or fail and whether and which statement contains the the issue. Ok.

So our pro tip, although I don't think you necessarily needed me to tell you this is that you should become besties with these APIs because they're very fun. They're very flexible. They can do a lot for you and they can save you a lot of time. So you might ask yourself. Ok. So in the case of ValidatePolicy, we're doing syntax checking, we're just parsing the JSON and looking at things to see if there's weird stuff in, in the policy. But these two new checks are not doing that. They are actually using our secret sauce, which we call automated reasoning.

Ok. So, automated reasoning. Well, let me take a step back real quick. I am a math nerd. Ok. That, that was my first love. Math is my first love anybody else here. Math nerds. Yes. Yes. Ok. Great. Well, when I went to college there was two paths you could take in math. You could either go, you could either do pure math or you could do applied math. Now, I was allergic to anything applied. Ok. I was like, whoa, that's terrible. I wanted to do pure math. Right. So, we do proofs, right? Lots of symbols. Anything that had numbers in it. I was like, ah, this is awful.

And then of course, you know, after I got out of college, it's like, oh, well, unless i want to become a professor i probably can't get a job. So I'd probably better use some real numbers at some point. The interesting thing is automated reasoning is actually kind of sort of not really either of those, it's like applied pure math. Ok. Here, let me take a step back. Let me try that again.

Basically, we do mathematical proofs to guarantee, you know, some property of the system, right? So that's what we're doing. So when you say, hey, is it possible for this policy to grant this role access to delete a DynamoDB table? We will go, well, let's use some math and construct a proof and see if it is actually possible in any conceivable case. And so if we say nope, well, that means nope. Ok.

So this diagram is basically what it's representing is you provide the policies, the question that you want to ask, we model how AWS IAM and authorization works. We turn all that into math, we feed it into these fancy programs called SMT solvers. And out the other end comes this mathematical proof. It's pretty cool if you want to learn more about automated reasoning. Um yeah, we have, we published a lot of a lot of papers, a lot of blogs. Um there have been several past re:Invent talks you can find as well. Um yeah, i encourage you to go check those out. Ok? But enough about that, let's get back to the new APIs.

So CheckNoNewAccess. As we, as i said means you can test a policy against a reference policy. So in addition to ValidatePolicy in our validation box. Now we also have CheckNo, NoAccess. So make sure we didn't introduce anything new that we shouldn't have. As I said, it takes two policies. So updated policy and a reference policy and then checks to see if there is any new access above and beyond. What's in the reference policy pass fail and gives you some helpful debugging information.

So if for some reason it failed, you can quickly zero in on the statement that had the failure CheckAccessNotGranted. Again, this you want to use if you want to ensure that a list of critical actions is not granted by the policy. So now we have that new API as well. And yep again, takes a policy a list of up to 100 IAM actions and then checks to see if at least one of them is allowed by the policy pass fail and tells you which statement that occurred in.

Ok. So to review, ValidatePolicy has been around for a while and because this is like things that we think everybody should do is a, is a good set of defaults for you to follow a good set of best practices. That is a, that is complimentary. You can just call that service as many times as you want for these Check, New, New Access things because they use automated reasoning because they are highly customizable and configurable to whatever your needs are. Those do incur charges.

So and you can find all the pricing information and everything on on our website. Ok. So APIs are cool and console is cool and all of that. But what we expect how we expect people to actually use, this is probably in something like CI, right? So developer is going to author policy, developer is going to make an update to the policy and when they do, we want to automatically run these checks. So that way security people like here never have to be bothered in that process. At least not unless there is a failure. And the developer really thinks they need the permission that is in the policy that caused the failure. Ok.

So in talking to several customers about this and planning this feature, what we found was their expectation was that the this functionality would automate something like 80 to 90% of their policy reviews. So they wouldn't have to manually look at any policies because as long as it passes these automated checks, no problem, just let that update flow through so it could save you a lot of time and ensure that everybody's moving quickly and safely.

Ok. Now, if you're a really creative person, you might think, well, hey, CI, why would it even happen at build time? Why wouldn't i have like a premit hook or some other place even earlier in the development process where this check gets run from to give the developer feedback? Even earlier. Absolutely could do that. It's just an API so yeah, shift left is our, is our pro tip. We give the developers feedback early, early enough in the process, it will keep everything moving quickly. Ok?

Speaking of again, we talked about how these policies or these APIs take policies, you might think to yourself. Well, i don't define my policies as policies. I use infrastructure as code, i use CloudFormation, i use Terraform. So maybe these APIs don't help me out all that much. Well, we, we feel you and we thought about this and so there are some open-source tools there and these tools have been around for a little while.

The first one is called CfnPolicyValidator. And what this does is basically takes your policy that is defined in CloudFormation and extracts the policy out. Ok? So like in this case, let's say we called Validate, right? Because that was a old API that we've had for a while and what it will do is it will go, ok? Here's the policy, but this policy contains an attribute which is my QARN. Well, we have no idea what the ARN is going to be at this moment because that doesn't get assigned until the resource gets created.

So CfnPolicyValidator says no problem. I'll just turn that into something that looks like a real ARN. So that way it's a valid policy and we can call these APIs yeah. Ok. So yeah and that that's just in GitHub. So yeah, feel free to go use that. We also because i know lots and lots and lots of folks love Terraform. We also have TerraformIAMPolicyValidator and guess what TerraformPolicyValidator does? Well, basically the same thing as CfnPolicyValidator um with some caveats because well, Terraform works a little differently than CloudFormation. But yeah, similar idea, extract the policy, find the thing that is not real and let's make it real and then pass that off to the APIs ok.

Right. It's time for a demo. Oh, no, no, i mean, yay. All right. Um yes. So live demo. Ok. All right. So what i'm gonna show you is um first i'm gonna show you the CheckNoNewAccess in the IAM console. Ok? So kind of like how we saw in the screenshot where ValidatePolicy is in the IAM console. We have also updated the console to allow you to check uh for new, the introduction of new access.

So I just pulled up a policy here in the editor if i edit it. Ok. Here we go. Let's say that. Oh well, first, just to show you down here at the bottom, right? So kind of near the PolicyValidator things. It says Check for new access if you click that you will see this and you will note, it says, hey, uh well, there's a charge associated with this. It's small but you know, we don't want you to, you know, you know, transparency, right? Make sure you know what's going on. And so i haven't modified anything. So if i check the policy, it will say, hey, no, no new access. Well, obviously i haven't edited anything yet.

Ok. But let's say that, oh, let's say i did something crazy like i deleted this condition which restricts access to this bucket to just one you know, one account. And then i checked my policy again. It will say, oh, actually you did introduce some new access and it is in this statement. So how did it know that it wasn't because i changed in action. It was because i removed a condition that actually constrained what principles could access this?

Ok. So if we put that back, put the condition back and check again, it'll say no, it's all good. And then let's say i did something a little better. Like i thought, well, you know, maybe i don't really need delete bucket because that's kind of a lot and then check again and it'll say no, you're good

You did in fact decrease the permission surface. Ok. There you go. So Consul. In fact, I had a, I had a Solutions Architect one time. Tell me he said, you know, one time I made a policy update, the policy was really complicated and I changed the condition. I just tweaked it and effectively, it turned the policy into a lous star. And he was like, I really wish I could have figured that out ahead of time. Well, guess what with this? You could cause you click that button and it would say, hey, it's more permissive and you're like, what, what? Really? Ok. Um so that's console and console is cool. But as a developer, I don't really use a console that much. I like to use things like pipelines, right? I do things in C I CD.

So ahead of time I created this pipeline, a really simple one. So just to show you how it works, there's only three steps, there's one that sources that a change from code commit. So somebody goes and check, commits a change, codecommit, gets the new code, then we're going to run a build step which is going to run check no new access and check access, not granted our two new apis and then it's going to deploy if those things pass. Ok?

So the one other thing that you need to know about this setup is you might ask, well, where are? Oh ok. So I have a bucket here s3 bucket that contains two files. One is my reference policy, right? For the check, no new access and one is my list of sensitive actions for the check access not granted, right? So this pipeline is going to pull those two things in. Ok? Let's go see what those look like, so my reference policy, well, it looks it's kind of small, let me make it bigger. You can see it says, yeah, we're cool allowing anything except past rule on any of these sensitive rules shouldn't be doing that. All right. So that's our, that's our reference policy. Let's make sure people don't do that stuff and here's our sensitive actions. Well, it's not very exciting, it's just dynamo db delete table but you know something that you probably don't want people doing very often. Ok.

So this is what our pipeline is going to do. All right. So here's my im policy and you will note it's actually a cloud formation, it's defined in cloud formation. So we are using this open source cfn policy validator tool that i mentioned earlier to run these checks. So and here's all this does the policy says allow these things and allow a pass roll. Ok?

Ok. So let's say that i was, you know, trying to make u have a bad day going rogue. Yeah, i mean, i, i would, yeah, go rogue. I would never do that. Of course. Ok. So let's say added dymo dv, delete star because you know, that's something i'm not supposed to do. And let's also say, you know, my sensitive rules, let's also say i can type, oh and in fact, let me make sure let's just do it up, right? Let me go grab the real good roll, my custom admin roll yeah, it was me. Oh, actually here for funzies, i'm gonna lie and say it was uba. Ok.

Ok. All right. So we're gonna commit that. Ok? And then we go back to our pipeline and yeah, well, it, so this is the part where we wait in case you, in case you didn't know running a pipeline like we did some timing. It takes like about two minutes to do this while we're waiting. Jeremiah. I have a question about these, these custom checks. Yeah. So these sensitive actions you say? Right? Why can't i just like create an scp and just like outright block it for my entire organization? Like why do i even need to like, prevent it for certain?

Yeah. Well, i mean, you could create an scp but if you create an scp for things like s3 delete bucket, well, that would mean nobody in the org could ever delete a bucket, which is probably, i mean, probably somebody should be able to do that once in a while. Right. Yeah. Yeah. Or like dynamo db delete table. Same idea, right. Are you feeling up to a question? One question from the audience? 00. Right. Go for it. What's your one question? What's that? What about permission boundaries?

Yeah. Right. Ok. So yeah, so the question or the point was, well, you could actually define a permission boundary and just restrict permissions that way you're right. However, there are some kind of gray area things where it's like, generally, no, you shouldn't be able to do this. But if i apply permission boundary, it means you definitely can't ever. Right. So it's kind of more like as the security person, i kind of want to, i'm going to be, i can be a little, i can have a bigger reach, i can say, well, i at least want to inspect these uses of things. There might be like certain situations where you might actually be able to allow it where you would want to do like a manual approval as a, as compared to a permission boundary, like just deny, not allowing it. Yeah, exactly. Exactly.

Oh, let's see. Did we uh how are we doing? Ok. Still in progress? Oh, see it took uh before it took two minutes. Oh, it felt perfect. Right on. Oh, it failed. Ok. All his success in this scenario. Oh yeah. Oh, by the way that yeah, that's what i wanted to happen. So, so, hey, it worked. Ok, good. All right. Well, if we go look at the logs and by that, i mean, if we scroll through 4900 some lines of logs to get to the actual thing that we want to see. Ok. Let's see. Ok. Right. Yeah. Check no new access. A ha it says modified permissions, grant, new access and that happens in statement one. Ok. Yeah. Which i mean that was the one i edited. So sure. All right. And let's go look at what the other one says. Ok. And this one says, oh yeah, dynamo db delete table. That was a bad thing that we made. So. Ok, so good. So our pipeline was blocked, it found the two things that it wasn't supposed to find and i'm happier. I was happy. Well, that was, that was the goal. Ok. Um oh, well, happily. Oh, that was it. That was, that was my demo. So, all right.

Ok. So let's let's go back to the site. Yes. Yes. And it actually it actually worked. Ok. Great. Worked as planned. Ok. Additional resources. So this first link just this morning, we published a security blog that introduces custom policy checks and actually, this blog has detailed steps to create the pipeline setup that i just demoed. So if you want to get started, in fact, i literally just followed the block. It was great. So yeah, i'd say check that out. And if you think this idea of a reference policy, right? Making a policy that has all the crazy conditions and things you might want to inspect is interesting, but you're not really sure where to get started. We actually have a whole github repo with a bunch of examples that was made by a security specialist solutions architect. So i definitely encourage you to check those out super useful resource. And now is the point where i turn it back over to usual all right. Thank you, jeremiah.

Yeah, thank you. Um all right. So what jeremiah talked about was set permissions or how i like to think about it is least privilege when you're setting new permissions. So what about your permissions or your existing permissions that you've already said? How do you ensure least privilege on your existing permissions? So that's where the verify and refine steps come in and we have a few existing a i access analyzer capabilities that help you

So I'm gonna quickly go through the existing ones because we want to spend more time on the new ones.

Uh the existing one, first of, first of, first of the features is policy generation. So in this one, I Access Analyzer reviews your CloudTrail logs, looks at access activity for more than 200 services, generates fine grain policies based on what is actually used, and also gives you some resource placeholders to customize if you want to restrict the access further to specific resources.

The way the pro tape or the way we want to, we want you to think about policy generation is it is a great tool if your applications are stable in a sandbox environment and if you're looking to promote them to broad because now you sort of know what specific permissions are actually being used.

The next one is external access findings. So we also generate these findings on your resource permissions. And we basically what Access Analyzer does here is it continuously analyzes access to and uses the automated reasoning secret source that Jeremiah just talked about for custom policy checks. But it's looking for any public or cross fund access allowed by my resource policies on my attached resources. So these are existing resource policies attached to your resources.

It generates comprehensive findings and helps you look at external access or any public or cross fund access in terms of the supported resources for the external access findings. So we have 11 services and 14 resource types within these 11 services that are supported today by these external access findings.

And then finally, so this is about your resource permissions looking at public or cross point access. What about unused access access that you had granted a while ago to your roles and were never used by your development teams because they never needed it.

So we do have last access to information through in our console for specific roles within the specific role, details and IAM user page and also available through IAM where you can find the last access time stamps for unused IAM roles, unused credentials which are like console passwords and access keys for your IAM users and also specifics for active roles and users also specific service and action permissions that they haven't used but have been granted to them.

So this is a great, the last access information is great when you know specifically what role or user you are looking to investigate or inspect a lot of our customers have been telling us this is great that I can actually go into a specific role and dive deeper into unused access. But what if I need like visibility at scale? Right.

And so I'm really happy to announce that just yesterday, we announced these unused access findings which actually give you visibility into unused access at scale. So what does that mean? So basically with these this new feature, what I Access Analyzer does is that it continuously monitors your environments for unused or broad I access, it actually reviews and generates findings on a for all the roles and users and user credentials that have been unused within a set threshold.

So you define what is your period of inactivity? Um and then it actually the, the the the big change that we've done this time is actually reviews and aggregates it into a centralized summary dashboard. So you can actually visually look at what your posture looks like in terms of unused access.

And we've actually extended the dashboard for our external access findings as well. Um if you are using Security Hub and you're like, I don't actually want to go to IM Access Analyser console to look at this stuff, you can actually find the findings in Security Hub itself. So we send our findings to Security Hub as one of the integrated services.

Or if you're looking for more automated notifications, you can actually integrate IM Access Analyzer to EventBridge and actually get events through that, that you can then integrate into your third party tools like Slack, for example.

All right. So what does this look like? Or, or how do you get started? Um as I mentioned, 14 resource types, external access already supported and we've now introduced unused access. So technically, these are four new finding types, findings for unused IM access keys, findings for unused IM user console, passwords, unused or inactive IM roles. And then also for your active IM users and roles, we will tell you specific services or actions that they are allowed to take action on, but haven't taken those actions.

Um in terms of getting started, you just enable the analyzer, it aggregates, it generates the finding aggregates them through the dashboard. And additionally, you can do the uh Security Hub or EventBridge integration as well to, to look at the findings through those uh avenues.

All right. So this is a screenshot, although I will do a live demo of the dashboard as well. This is a screenshot of how your dashboard could look like. Now, one thing I did forget to mention was you can actually create these analyzers at your account level. So you can look at unused access at scale for an account or you can actually create this analyzer at the AWS organization level. So effectively, you're looking at all of the unused access across all of your accounts at the organization level.

The goal with this feature that we are looking for is as I mentioned at the top, one of the security responsibilities is to inspect IAM configurations over time and then refine broad access. This is a good tool to help you do that.

Alright. So how this fits in just quickly in terms of the existing access analysis is we already have the public and cross on findings. We already have the last access information on a per, per user or role level. All of those are available to you at no additional cost. So you can do anything you can do, basically use those APIs or the console to do that for these new unused access analysis and the continuous monitoring and the reporting we do there is an additional charge.

Um and so yeah, I think in terms of pro tip, I would say use these at your maybe start testing these at your account level to see if these are useful and then turn them on eventually uh for your entire organization and, and start reducing broad permissions in finding and reducing broad permissions.

Um all right. So now it's time for my demo. So let's get started right. So right now I'm in the IAM Access Analyzer console in within the IAM console. Uh so I wanted to get started with uh the setup. So I'm gonna get started. So in analyzer settings, you can create an analyzer as you can see i already have an analyzer for the unused access uh analysis as well as one for external access analysis.

Um just to show you the the setup process and how simple it is, you can basically select the type of finding that you want to create the analyzer for. I'm just gonna select the new one. Uh you can define the tracking period. So this is basically what you think is your period of inactivity for the purposes of the demo. And because we were lazy and we did not set this up three months ago, our tracking period is five days, but uh you can effectively go up until 180 days if you want like a six month tracking period for defining inactivity, right?

Uh and you can, again, so in terms of the scope of the analysis, you can choose whether to turn this on for your organization or your account and y and uh uh optionally add tags if you want. So, since I already have my analyzer created, I'm just gonna use that.

Uh so as you can see you have findings here, so 28 findings, it tells you whether it's unused permissions, access keys, uh an unused role. This is actually at the organization level. So it also tells you the different account IDs. Um so you can see at the bottom there are a few other account IDs.

Um and uh yeah, so this is the summary dashboard. So when you click on the dashboard, you will see findings for the findings for external access and also findings for unused access. And so the good thing is i don't have any publicly accessible resources, which is good is the secure thing to do, especially as the security person, i should not have public access.

Um i do have 12 access from outside of the organization which in some cases might be ok if you're giving access to your vendors or something like that to your trusted third party. Um it also tells me the specific uh different resource types that allow the cross account access or public access.

And then this is the the new unused access findings that we introduced. So it'll tell you there are like 12 unused credentials, seven unused roles, nine unused permissions on active roles. And it also gives you a distribution so you can actually go find out.

Um so, and then the final thing, sorry is we also tell you what accounts. So we give you an account by account breakup of your unused access findings. So you could actually see that app team one. Hey, jeremiah, isn't that your account? Um yeah, so you can see like app team one clearly has a lot of findings. So 17 findings.

So let me go inspect that. So i click on app team one. It already filters it by the owning account and it tells me that, hey, there's a bunch of findings. Um and i can also filter by the finding type to look at specific findings.

Um so for example, i see this jmd old IAM user has unused access keys. That's not good. I should probably go prod jeremiah to get him to delete those access keys.

All right. The other thing i could do is i could go to Security Hub and then in the integrations on the left, i see IAM Access Analyzer is one of the integrations. So you can start or stop accepting findings. I've already done that. So if i go click on see findings, Security Hub will already filter the findings that they have specifically to IAM Access Analyzer and also provide a severity level.

So I'm gonna go look at my medium findings. And again, i see that there are some unused roles and also unused access keys uh that some of my uh that, that are there in my across my organization and specifically some in jeremiah's account.

So i can actually go poke jeremiah to, to go and, and, and remove those. Uh i think just because of time, we, we're just gonna like, we actually had this plan where jemiah goes and deletes the unused roles. But since we just have 10 minutes left, i'm gonna assume he's gonna do that some good work. I promise right after the session, i'll go delete my unused stuff.

All right. So i'm gonna switch back. So that was the demo of our unused access findings. Um it's, it's pretty simple on the console. All of these, all of these unused access findings, by the way, are available through the API you can also, as i mentioned, integrate with EventBridge and, and do that.

And Jeremiah, do you want to talk more about other ways that can use these findings or are features?

Absolutely. Yeah. So of course, at AWS, we love our partners. We actually have, well, this is not an exhaustive list, but these are some of the launch partners that we've worked with for these new features.

So if you're using any of the third, if you're using third-party products that are provided by these partners, they either already have integrated these features or will have them soon. So um yeah, if you use these, you might just get these for free as part of your, you know, part of using the products already, ok?

And of course, we expect that list to just grow over time. So takeaways from our session. So the first and most important is definitely use IAMs Analyzer on your journey to least privilege, right? Regardless of what features you use, uh there's lots of good things in there that will help you if you're working.

If you're at the set phase of your life cycle, use custom policy checks to automate policy reviews, obviously, definitely use policy validation as well to make sure that your policies are in good shape.

At the verify phase, use unused access findings. What who you all just talked through to essentially inspect, you know, unused things that are in your org. And then finally, the refinement stage, once you find, once you see what those are, then it's pretty simple to just go delete them.

Um and that will, you know, make your overall permission surface area smaller, which is what we want. If you really, really love this content or like this kind of content, there is a breakout session tomorrow that will it's a 300 level session that will cover a little bit about these features and a bunch of other identity and access.

It actually goes much deeper into I access analyser like one part of it, but it also talks about a bunch of other things, data parameters that we did not specifically talk about all of those things. That's right.

Yep. So that's a really, that's a really great session. There are also if kind of like you saw in the demo, if you actually want to get hands on with these features, there are two workshops, they're, it's a repeat, right? So one workshop, but two different sessions, one tomorrow and one on thursday.

Um definitely encourage you to go check that out. Um so you can get your hands with this stuff. I think that includes both the custom policy checks and, and configuring unused access findings as well as policy validation, i think is also included in. Nice.

Yeah, sounds really useful. And if you want to get the next wave of announcements from and, and lots of other security things, save the date for Reinforce, which is going to be in Philadelphia next year.

And final, final, final calls to action. Uh if you want, feel free to connect with Ujall and I on LinkedIn or shoot us an email if you have additional questions uh or thoughts and please, please please fill out session survey in the app.

Yep, i'm gonna be at the booth as well all three days tomorrow onwards. 10 to 12. So if you have any other questions, identity and the, the security, identity and complaints booth. Yeah. Yeah. Nice. Ok, awesome. Thank you all very much for your time.