Ensuring proper, consistent Identity and Access Management (IAM) in AWS is both a toil-heavy chore and a persistent risk. Often, engineers are expected to be responsible for this when they may or may not know what the specific access should look like for their application. In other cases, a lone (and typically overwhelmed) cloud security expert is saddled with an insurmountable amount of custom policy development, which can significantly slow down engineering and product release velocity. In the worst case scenario, overly permissive configurations can lead to an event like the Capital One hack in 2019.

It doesn’t have to be this way. You can have development velocity and security working in lockstep with just a few easy Prowler IAM checks. (If you’re not familiar with Prowler, check out our first post in this series.) For each check we list below, you’ll also get remediation steps to help if your environment fails that check.

The Prowler IAM checks fall into roughly 5 groupings that are based off the AWS IAM Security best practices:

Root Account Protections

AWS recommends that you treat your root user access key “like you would your credit card numbers or any other sensitive secrets.” You only want it to set up your admin account, and then you want to use roles and groups to delegate permissions. This set of checks helps you see if/when the root account has been accessed, ensure MFA is enabled, and control access keys for the root account, including:

Key and Credential Rotation

AWS recommends rotating access keys every 90 days, and disabling credentials that are unused for 90 days or greater. These checks confirm those timelines, plus an extra one for those that prefer a shorter window.

Password Hygiene

Policing passwords is no fun, and if you use SAML you don’t have to worry about this (but having these checks properly set up is still a good practice)! If you are using AWS IAM as a user and password database, these checks make it simple to see if something snuck through that shouldn’t have. This set checks for:

Admin/Ops Details

Keep your who, where, what details up to date in case something goes wrong. This set covers important details like:

Users, Roles, and Groups

By default, IAM users, groups, and roles have no access to AWS resources. IAM policies are the means by which privileges are granted to users, groups, or roles. AWS recommends that IAM policies be applied directly to groups and roles but not users. Assigning privileges at the group or role level reduces the complexity of access management as the number of users grows. Reducing access management complexity may in turn reduce the opportunity for a user to inadvertently receive or retain excessive privileges. This set verifies that:

Privilege Escalation

We made a special category for this, because it’s something that can catch you off guard in really nasty ways. Essentially, users with some IAM permissions may be allowed to elevate their privileges up to administrator rights. It’s critical to know if you have any of those privileges lurking in your infrastructure that an attacker could potentially exploit, from things like creating a new version of an IAM policy, to making a new EC2 instance and gaining access to all the permissions that the associated instance profile/service role has, or creating a new user access key that could grant them full administrator access (and a bunch more bad things that stem from privilege escalation). 

Logs and Alerts

Root account logins, unauthorized API calls, and policy changes or auth failures could all be simple mistakes or signs of malicious activity. Either way, find out as soon as possible with this set of checks that makes sure log metric filters and alarms exist for:

This is the tip of the Prowler iceberg, which has over 240 checks for comprehensive coverage of all your AWS use cases. Stay tuned for our next post in this series, which covers key Prowler checks for preventing ransomware attacks.

Sign up for Prowler Training

This free course covers everything from the history of Prowler to advanced features.

Toni de la Fuente

Founder of Prowler Open Source & Lead of Prowler Pro

I’m founder of Prowler Open Source, tool for AWS security best practices. I also worked for AWS as security engineer and security consultant. I’m passionate about FLOSS (Free Libre Open Source Software) in general and Information Security, Incident Response and Digital Forensics in particular. I like everything related to cloud computing and automation. I have done some things for security and the Open Source community like Prowler, phpRADmin, Nagios plugin for Alfresco, Alfresco BART (backup tool). I’ve also contributed in books and courses related to Linux, Monitoring and AWS Security for PacktPublishing.