whoIAM: Lack of IAM controls

The AWS console requires authentication (username/password) in order to start using their services. This applies to programmatic access to AWS too. In AWS, there are 3 types of identities — IAM users, federated users, and resources — that can use identity roles to perform actions.

If any of the identities that can authenticate to AWS lose their credentials due to a public data breach or by being accidentally shared with an attacker, this can be quite bad for the organization. This gets worse when the compromised identity has permissions that allow them to do a lot more than what their current role in the organization should allow for which leads to the birth of whoIAM—the lack of IAM controls villain. 

Common causes

Managing AWS IAM users, including the permissions they would have across an AWS account, gets very complicated when put in the context of multiple double and triple-digit AWS accounts. This results in IAM users having multiple sets of permissions across multiple AWS accounts.

If you do not ensure role-ased access control (RBAC) or Attribute-based access control (ABAC) when a user permission is created, promoted, demoted in an organization, identities can end up with more permissions than they should have given access to. This can be overwhelming, depending on how many users are  managed in AWS.

Third parties are required to connect to AWS using IAM roles with external IDs, so they can use the AWS API to scan and work with the resources in the AWS account. IAM issues occur when permissions in the roles are excessive when compared to what the third party actually needs.

Problems caused by a lack of IAM controls

One of the most common causes of a data breach is a compromised username and password that were targeted by attackers. It’s hard to predict which user would be compromised, so by not ensuring RBAC or ABAC, it could mean that the compromised credentials could have more permissions then they should have access to. This makes the exposed risk a lot higher than just losing the username/password. The best example for this is the Uber breach in Septemper 2022.

A lack of a regular review process to check permissions on active users, including whether users that are active should all be active users, can lead to blindspots (like over-privileged users) that can be potentially exploited by attackers.

3 places in AWS where whoIAM likes to hide

1. AWS IAM policies can be used to add permissions to an IAM identity (IAM user, group, or role). Depending on the number of users and groups that have to be managed across multiple AWS accounts, can it be hard to manage them, leading to lack of consistent IAM controls across AWS accounts.

2. AWS trusted entities are external parties that have be provided access to AWS accounts. They should be part of a periodic review process of third-party suppliers to ensure permissions are provided only to services and actions that the third-party should be allowed to have access to.

3. AWS Identity Anywhere attached IAM roles use x509 certificates (digital certificate that verifies that a public key belongs to the user, computer or service identity) to provide non-AWS hosted services access to AWS hosted services. The permission assigned to these roles can have excessive permission that allow them access to more resource than they should have access to in AWS Accounts 

3 ways to stop whoIAM

1. The simplest way to get ahead of whoIAM is to use cloud native services with the principle of least privilege access to ensure that, when assigning permissions, there is a process defined for user role changes and change of services. Ensure alerts are created for IAM Policies with * permission in them to remediate them immediately.

2. AWS IAM policy simulator is a reliable service from AWS to help define the exact permissions required and being issued to a role, service, user or group. Using the IAM policy simulator when creating new permissions or modifying existing ones can be a good way to ensure RBAC and ABAC principles are followed.

3. Limit who can make changes to permissions for IAM and services, especially in sensitive environments like production. In addition, using infrastructure as code (IaC) to define user permissions will ensure that pre-defined permissions are the only ones used in each AWS Account.