Auditing AWS IAM for better security practices
How security teams can tackle the challenge of auditing identity access management systems in their IT Infrastructure.
Organizations today use SaaS, PaaS, IaaS, and other types of cloud resources as part of their IT infrastructure. All these services come with in-built effortless (a couple of clicks) identity access management (IAM) feature. Amazon Web Services (AWS) includes a very useful feature called AWS IAM to control identity based access management.
Failing to evaluate, monitor and audit all type of improper access to resources is one of the reasons for insider leaks and data breaches. The problem becomes difficult to tackle over time, as organizations add new services to their IT infrastructure without improving the capability to evaluate, audit and monitor their access provisioning and de-provisioning process.
This article talks about how we implement these practices at Postman. You can take these as a recipe and apply to the IAM setup of your organization.
Setup AWS IAM to reflect organization structure
Understanding organization structure is the first step towards setting clear processes to grant and remove access in IAM. These ensure uniformity to a certain level so that auditing them becomes simpler from a SecOps point of view.
IAM Users: Employees are assigned email addresses in the format <firstname>.<lastname>@getpostman.com. These email addresses map to the user credentials for AWS access.
IAM Groups for teams: There are separate groups for internal functions like Services, App, DevOps, Security, Data Science, and Marketing. These help us in assigning group level policy for access to resources, depending on the team’s needs. We also create sibling IAM groups, such as <team>-admins, <team>-power-users, <team>-users, and <team>-interns to grant finer access controls.
IAM Groups for services: With a microservice architecture for our services stack, we set up separate IAM groups for all of our service admins and owners. These groups follow a naming convention like <service-name>-admins.
We take the following criteria into account while deciding on how we split the groups and teams:
Resource Usage
- Services: CloudWatch, Beanstalk (includes all the services that it manages), RDS, ElastiCache, Route53, S3, etc.
- Security: IAM, Guard Duty, Inspector, Macie, WAF and Shield, Config, VPC, CloudTrail, read access to resource configurations, etc.
- Data Science: DynamoDB, Kinesis, Firehose, DMS, Redshift, API Gateway, Lambda, Athena, EMR, Data Pipeline, Glue, Step functions, etc
- App: S3, CloudFront, etc
- Marketing: S3, Lambda, CloudFront, etc
- DevOps: All of the above
Resource Access & Permissions
<team>-admins: Near full access is granted for the resources under the corresponding team’s function. Lethal destructive actions are prohibited. Admins have the capacity to grant access to resources under their team.<team>-users: Sandboxed (no-delete) Beta and Prod only access, Most destructive actions are prohibited.<team>-interns: Sandboxed (no-delete) Beta only access<team>-power-users(optional): Similar to admins, but some delete actions are permitted (Extent is specific to and depends on the exact team in question).
IAM Roles
IAM entity with permission that can be assumed by authorized entities, such as IAM users, IAM groups, or AWS services.
IAM Policies
IAM entity that, when attached to an identity or resource, defines their permissions.
A strategy to audit the AWS IAM system
A strategy helps us to define the scope and approach to audit the AWS IAM system.
1) Checks for authentication scheme, password policy, MFA enforcement, etc.
2) Interaction of IAM entities (user, role, group, and policy) with AWS services.
- Credential rotations
- Inactive IAM entities
- Unused and not recently used permissions in associated policies.
3) Alignment of current IAM structure with our defined organization structure at any point of time.
- Ensure that the mapping between IAM users, IAM roles, IAM Groups, and IAM policy is done correctly.
- Check if any Non-Admin group is attached to the policies that grant destructive permissions.
A checklist to execute audit strategy
The 3rd item in the strategy list above depends on your organization structure. Here is a checklist you can use to implement point 1) and 2) from that list.
1) Check if root user access keys are disabled.
2) Check if the strong password policy is set for an AWS account.
- Minimum password length (10 characters)
- Require at least one lowercase letter
- Require at least one number
- Require at least one non-alphanumeric character
- Allow users to change their own password
- Enable password expiration (365 days)
- Prevent password reuse (cannot use 24 previous passwords)
3) Identify IAM users (humans) whose active access keys are not being rotated for every 45 days.
4) Identify if IAM users (bots) whose active access keys are not being rotated for every 180 days.
5) Identify IAM users (humans) who are inactive for more than 180 days.
6) Identify IAM users (bots) who are inactive for more than 180 days.
7) Check if MFA is enabled for IAM users (humans).
8) Identify all the permissive policies attached to the roles.
- Permissive policies: where the value of “Principle” or “Action” is “ * ” (wildcard character).
9) Identify unused and not recently used (not last accessed in 180 days) permissions provisioned via policies attached with IAM entity (user, group, role, or policy) using service Last Accessed Data.
A Postman Collection to automate AWS SecOps
For our first audit, we tried auditing our AWS IAM system manually using the checklist. It took 3 days to complete the in-depth audit. We realized that the manual approach won’t be feasible in the long run. We also realized the need to increase the frequency of audit, knowing the ever-changing nature of permission association with IAM entities.
So, we built a Postman Collection that uses AWS IAM’s REST API to perform the checks mentioned above and pipe the data to Slack for the relevant people to remain notified.
The collection makes extensive use of scripting in Postman, as both pre-request scripts and tests. We have used AWS authorization helpers throughout the collection to make signed requests to the AWS API. This collection is run on a schedule on a Monitor to ensure everything is tested regularly.
The AWS IAM Audit Template
We published the collection as a Template in Postman.
To audit your AWS account, load the template in your Postman app by clicking the New button -> Templates -> Search for “AWS IAM & Organization Audit”.
Prerequisite:
Create an IAM user and generate access key & secret access key:
- Select AWS access type as “Programmatic access” to generate an access key and secret access key.
- Ensure that the AWS Managed Policy IAMReadOnlyAccess is attached with the IAM user.
Go to Slack API’s incoming webhooks page to generate a webhook URL to push data to Slack.
Now, set the following environment variables:
- aws_access_key_id: AWS access key
- aws_secret_access_key: AWS secret access key.
- slack_url: Slack incoming webhook URL.
With these things in place, you can now run the collection through the Postman app, in the command-line using newman or on a schedule using Monitors.
The collection truncates results if it is greater than 40,000 characters. You can look at the Postman console to see the entire result.
You can also view the collection on its published documentation page. Feel free to import it into Postman and make changes to fit your audit workflow and reporting channel.
Mitigating the risks
Auditing a system is just not sufficient, you will also need an actionable strategy to mitigate the risks discovered.
We won’t dive into exact mitigation steps in this article. But, here is a set of quick links from AWS that you can follow to build a mitigation strategy.
Well-designed APIs lend themselves to interesting workflows. This was a glimpse at how the infosec community can use the APIs published by AWS to implement SecOps practices. What does your security audit workflow look like?
