Remediating least privilege issues using AWS IAM Access Analyser

The ‘shift-left’ movement has put much focus on being proactive and preventing security -related issues as early as possible — which is fantastic.

Remediation and the streamlining thereof might slack behind at times.

Our responsibility as analysts often stops at the point where we log something while later checking in on a cadence until the issues are fully remediated (depending on environment).

Picture a scenario where you’re sitting with a substantial amount of excessive permission findings in AWS.

We all know that developers love analysts logging findings, but we often forget to ease the remediation process for devs.

Keeping that in mind, how do we go about remediating these excessive permission issues already deployed, while making it as convenient and fool-proof for developers?

The run down

IAM Access Analyser is a free service with multiple use cases. The use case at hand, is the means with which it determines the bare minimum permissions that an IAM role needs based on the principle of least privilege.

First off, enable access analyser, it’s free. Navigate to IAM to enable the service. You would have to setup/select a CloudTrail trail, to provide the log data needed.

Login as admin into your applicable account. Identify the IAM role you would like to evaluate.

• Take note, that for this example I’ve assigned two AWS Full Access policies to my role ‘S3BucketRole’. This in itself is bad practice, but reflects a real-world scenario, especially in a testing environment.

You will be presented with an option to “Generate policy based on CloudTrail events”. Click “Generate policy” to kick off the process.

• Do take in regard, that Access Analyser might not be as effective, in cases where roles are shared between multiple workloads/cloud entities (this is not best practice anyways), especially instances from varying services. This will result in Access Analyser identifying a wide scope of permissions, which isn’t what we want.

Select the timeframe and CloudTrail trail (this can be an Organization trail) plus service linked role (default is fine).

• Might take 2–5 minutes to generate — depending on timeframe ext.

Access Analyser will generate a new policy — which is customisable. Identified actions showcased in the screenshot above.

• Calls which are unsuccessful or denied, will also be used to generate the new permissions (CloudTrail: DescribeTrails e.g.), as it pitches up in the logs and classified as behaviour. For example, even if you tried to open the IAM dashboard of a service in the console, while not having access, the denied ‘List’/’Describe’ calls will still be included in the Access Analyser generated policy.

You do have the option to further customise the generated JSON policy.

• ‘BucketName’ is highlighted, reason being that merely stating ‘BucketName’ does not align with the principle of least privilege. The specific bucket(s) needs to be specified to comply with the principle of least privilege.

After navigating through the ‘Review and Create’ stage, you can attach the new generated IAM policy to your Role directly.

Our role now has the least privilege policy attached. Other overly permissive policies can now be removed.

That’s about it.

Quick mention regarding overly permissive IAM policies

Poor IAM policies invite security incidents. Unit 42 by Prisma Cloud states that initial access through exposed credentials is a serious concern, but that once an attacker gains initial access, it’s not uncommon for attackers to move laterally with ease as 99% of cloud identities are overly permissive. It is also known that attackers don’t even need to undergo privilege escalation at times, as IAM role permissions attached to compromised identities are so grossly over privileged.

Conclusion

Reduce risk and enhance your security posture by scoping down on permissions while refining the remediation process. Work smarter — not harder.