Ashish Rajan: [00:00:00] We're at AWS re:Inforce 2024 and we got a chance to speak to Brigid Johnson, who is a GM for IAM Access Analyzer. We got to speak about the customer use cases, how people are using Access Analyzer for not just finding unused access, but also being able to prevent using preview policies to understand, Hey, what policy would actually make more sense instead of using an overtly permissive policy?

A lot more announcements came through and we spoke about a lot of that in this episode of Cloud Security Podcast. I hope you enjoyed this episode with Brigid Johnson from AWS. If you are here for a second or third time, if you enjoy this content, what you're hearing and watching, definitely give us a subscribe and follow on your audio platforms and video platforms.

Otherwise, enjoy this episode. I'll see you soon. Welcome to AWS re:Inforce conversation here with about IAM, specifically access analyzer. Welcome to the show. I'm happy to be back. I'm excited to talk to you, but maybe if you can tell us a bit about yourself to the audience. Get to know Brigid as well

Brigid Johnson: and pickles.

Yeah, so my name is Brigid Johnson. I'm a director in AWS identity. I've been in AWS and identity for 10 years. I just celebrated my 10 years, so it's really exciting. So I do everything access controls. I really like [00:01:00] it. I have a passion around helping everyone who's building on the cloud get to the right access controls and the right permissions.

So I like that for both their workloads and their human users and I do have a horse. His name is Pickles and i'll share that this year we started showing him. So it's very exciting. He's won a first place ribbon. So

Ashish Rajan: wow already

very excited. Yeah.

Wow. Okay You touched on the whole workload identity and human identity a lot of the industry kind of calls out as human and non human user Yes What is that in AWS specifically?

And you go to the bit more granularity of it.

Brigid Johnson: Yeah, so when we talk about access in AWS, access is going to happen through roles, no matter what, right? And so you're going to have an identity, maybe coming in from your, for human users, coming in through an identity provider, you'll federate into AWS, and you'll assume a role.

You'll get, short term credentials. And then those credentials will have access to pop around AWS, maybe provision some things, maybe explore some new services that got launched, and that's the human use case. And then you also have your workloads and those are going to be your Lambda functions who are also going to assume a role as a Lambda service.

And [00:02:00] then access DynamoDB or access some data. And so it all comes down to those roles and what permissions those roles have.

Ashish Rajan: When people say non human users in the general industry, what they're referring to is the roles, or IAM roles, in the context of AWS. Yeah, and there's different ways to do workload identity but a lot of it in AWS is gonna come down to a service assuming a role, and that's how they'll get access to certain things.

Talking about access as well, Access Analyzer. How would you define Access Analyzer for people who have not heard of the service yet?

Brigid Johnson: Access Analyzer is all about helping folks Get to the right permissions. And so we do that in two ways. One is helping a central security team identify broad permissions, inspect their whole entire AWS environment, figure out where they need to go spend some time and attention.

And then we are also investing in helping the developers get to the right answer earlier when it comes to permissions. And we think of this as a life cycle, right? You set your permissions, you verify that they work, you verify they're not broad, and then you refine them further.

Ashish Rajan: These days, no one really has just one account anymore.

They have multiple accounts because Access Analyzer goes across all the accounts.

Brigid Johnson: Yeah, so a lot of our [00:03:00] analysis is enabled at the organization level. But then which we just launched, recommendations to remediate broad access. You'll want to do that down in the actual account because that's where the permissions are.

So it's a little bit of a two sided story.

Ashish Rajan: Oh, actually, so what are the two announcements from Reinforce?

Brigid Johnson: Yeah last time we talked, we announced that Access Analyzer, you can go to the org level or within the account level. Yeah. And turn on unused access findings. And that will go through and find your unused access keys, your unused roles, if you created them.

Unused IAM passwords, don't want those lying around. And then for things that are used, it will give you your unused access keys. services and actions. So you will let us say Hey, you have this role. You granted all these permissions. You're only using this subset. So that was as of a week ago. As of yesterday, now you can go to that finding and it will be like, okay, now I have all these broad permissions.

What do I do? Oh, you can click on a button that says preview policy and you'll see the old policy that's broad and the new policy that has removed the actions that you didn't use. And so it's really easy. Yesterday I did a demo on stage. It was so cool. I like copy paste it. I was like, let's just do it.

Just go for it, see if it [00:04:00] works, and we copied, pasted, reduced the permissions, finding was remediated. Everything still works because it's based on data. And that's a story that you have your central security team, you're going to identify broad access, and then pop down into the account. Maybe it's your prod account, maybe it's a dev account, wherever you're at, and then easily reduce that access.

Ashish Rajan: Because I think people usually think of IAM access keys as just the Ashish password. With a local user inside AWS access keys. How does this kind of apply to those broader other pieces that people normally get worried about?

Brigid Johnson: So when we think about AWS access controls, we have access controls in multiple places, right?

And this is so you can define fine grained permissions, who can access what, under which condition. So we have service control policies where you can restrict access for your org. But then when you're looking at granting access, you can either do it from a role, or for some resource types, you can actually say, Ashish just allowed to access this bucket, or anybody in my org can access this bucket.

DynamoDB just launch resource based policies. So a similar use case they did launch with block public access on, so there's no, we're going to be no public dynamo DB [00:05:00] table. So that's really nice. So then you're granting direct cross account access to those resources. So what you can do with access analyzer is you're like, okay, I have all these resources.

We like to focus on the data resources types and with access analyzer you turn on the analyzer and it will identify any public resources you have. So buckets, SQS queues, but also identifies external access. So maybe I have shared with you my DynamoDB table. Maybe you're outside my organization.

Probably central security wants to make sure that you're a trusted entity

Ashish Rajan: In the world of AI that we're moving into. This kind of has become a lot more prominent because a lot of people are working towards that data security project and one of the biggest things would be who has access and how much access does this individual have?

Are you finding that people are using access or customers are using Access Analyzer as a way to whether streamline or what's the use case customers are using it for the moment

Brigid Johnson: Two I think one. We talked about the central security team and you're just like, okay, I want to make sure that I have the right permissions trending in the right [00:06:00] direction across my environment.

The other one is just helping developers get to the right answer sooner, right? And so we launched a few checks at re:Invent called custom policy checks. And this is where teams, I'll say, and companies can define their security standards. And then run these checks we're seeing customers put them in CICD pipelines, in tooling, we have a few AWS Toolkit integration, CloudFormation integration, and you basically define what you care about, right?

And you're like, hey, I don't think people should be granting access to delete my Crown Jewels, Pickles, DynamoDB tables, so I'm gonna make sure every policy doesn't grant that access, unless it's maybe an extension. And all these checks are based off of provable security, so automated reasoning.

So it's not just parsing, it's not just Brigid looking at the policy. It actually has a math based proof along with it. Wow. So that's really powerful. And what we just added yesterday was, check no public access so when you're going around and you're putting policies on your buckets, on your DynamoDB tables, on your roles, all the things you can basically say, let's just make sure this [00:07:00] policy is not going to grant public access before I touch it.

And so just shifting that verification earlier, closer to development to give people some feedback and kind of confidence that they got the right thing going on.

Ashish Rajan: Awesome. It's also good to see the IAM space evolved quite a bit because I started in IAM my career. So I have always been a soft corner in the cloud space because identity is the most important parameters.

I definitely. Hope people listen to this, use access analyzer and figure out who's actually overtly permissive across the entire AWS account space.

Brigid Johnson: And I think you started with some people were not aware of Access Analyzer. And I would just say for anybody who is working with permissions in the cloud, which if you're building, Or if you're a human user, there's probably some permission in there somewhere to take a look at access analyzer.

Because what we're trying to do is put the tools where people are setting those permissions, where they need them and help you.

Ashish Rajan: Yeah. And it's all API enabled as well.

Brigid Johnson: So all API, there's some console, some dashboards, if you enable at the org level. So a little bit of something for everyone.

Ashish Rajan: Yeah. And they can integrate this with their [00:08:00] CI CD pipeline and otherwise. as well. You mentioned as well. Yeah.

Awesome. No, thank you so much for sharing all of that. I really appreciate this. I will. Now, you know about Access Analyzer part two, there's part three at re invent coming. so much for coming on the show. Thank you for listening or watching this episode of Cloud Security Podcast.

We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister podcast called AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Seamer, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of chat, GPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at cloudsecuritypodcast. tv. I'll drop them in the description [00:09:00] and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍