Stop Over-Privileging Your Cloud: A Data-Driven Approach to IAM Cleanup

TLDR: Most cloud environments suffer from "permission explosion," where roles accumulate excessive access over time, creating massive security gaps. By calculating a Permission Utilization Ratio (PUR) based on actual usage data, you can systematically identify and revoke unused permissions. This methodology, paired with the PermCutter tool, allows you to enforce least-privilege access without breaking production workflows.

Cloud security is often treated as a configuration problem, but it is fundamentally a data problem. We spend hours auditing JSON policies and debating the merits of managed versus inline policies, yet we rarely look at what is actually happening in the environment. When a developer needs access to an S3 bucket for a one-off task, they get it. Six months later, that permission is still there, sitting in a role that is now attached to a production microservice. This is how you end up with Broken Access Control, the most common path to a full account takeover.

The Mechanics of Permission Explosion

Permission explosion happens because the cost of being too restrictive is immediate—your code breaks, and you get a PagerDuty alert. The cost of being too permissive is invisible—until an attacker uses those extra permissions to move laterally or exfiltrate data.

The research presented at Black Hat 2023 highlights a simple, effective way to quantify this risk. Instead of guessing what a role needs, you look at what it actually uses. By pulling IAM access logs and mapping them against the roles in your environment, you can calculate a Permission Utilization Ratio (PUR).

The formula is straightforward:

PUR = (median_num_days_used * num_users_used) / (total_num_days * total_num_users)

If a permission has a PUR of 0.1, it means that even if the role has the right to perform that action, it is effectively unused by 90% of the users or for 90% of the time. This is your signal to prune.

From Theory to Execution

During the talk, the speaker demonstrated how to turn this data into a repeatable process using a standard stack: Python for scripting, Google Colab for analysis, and SigmaJS for visualizing the resulting permission graphs.

The demo showed a clear before-and-after scenario. By identifying permissions with a PUR below 0.1 and revoking them, the team reduced the total number of permissions in their environment by over 60%. This isn't just about "cleaning up"; it is about reducing the blast radius. If an attacker compromises a service, they are limited to the actions that the service actually performs, not the entire kitchen sink of permissions granted during its development lifecycle.

To implement this, you need to push your IAM data into a structured format. The schema used in the research involves mapping users, roles, resource types, and actions into a central role_permissions table. Once you have this, you can run queries to identify the "bloat."

Real-World Pentesting and Bug Bounty Impact

For a pentester or a bug bounty hunter, this is the gold mine. When you land on a machine or gain access to a set of AWS credentials, you are almost always looking for ways to escalate privileges. You run iam:GetAccountAuthorizationDetails or use tools like Pacu to map out what you can do.

If you find a role with 700+ permissions, you know the organization has not implemented a cleanup process. You don't need to find a zero-day; you just need to find the one permission in that massive list that allows you to modify a security group or read a secret from AWS Secrets Manager.

When you are on an engagement, look for roles that are shared across multiple services. These are the most likely candidates for permission explosion. If you can demonstrate that a role has access to s3:PutObject on a bucket it never writes to, you have a valid finding. It is a classic case of failing to adhere to the principle of least privilege, and it is a finding that CISOs actually care about because it is quantifiable and fixable.

Automating the Fix

The most important takeaway is that you cannot do this manually. If you clean up permissions today, they will be bloated again by next month. The solution is to automate the policy generation.

The PermCutter tool released alongside this research automates the process of pulling usage data and generating a new, minimal IAM policy. By running this on a weekly schedule, you turn a massive, one-time security project into a background maintenance task.

Defenders should focus on integrating this into their CI/CD pipelines. If a new role is created, it should start with a baseline of zero permissions and only gain what it needs based on observed behavior. This is the only way to stop the cycle of over-provisioning.

Stop auditing policies by hand. Start looking at the data. If your roles have more permissions than they use, you are just waiting for an attacker to find the ones you forgot about.