IAM

Identity and Access Management  Security with AltorCloud

MultiCloud Identity and Access management security, AWS, AZURE, and GCP

Evin Hernandez
Mar 19, 2023

Identity and Access Management (IAM) security is crucial in maintaining the security of cloud services. However, managing IAM can be challenging and risky, leading to overburdened IT and cloud security engineers, delayed engineering, release velocity, or overly permissive configurations. AltorCloud provides a solution to maintain proper IAM security with a few simple IAM checks. AltorCloud IAM checks are based on cloud IAM security best practices in various categories, such as root account security, key and credential rotation, password hygiene, admin/ops specifications, roles and groups, privilege escalation, logs, and alerts.

Maintaining proper, consistent Identity and Access Management (IAM) in the cloud is an uphill task and a constant risk. Engineers are often expected to oversee this, even though they may need to learn what the specific access should look like for their application. In most cases, a single (often overburdened) cloud engineer is overwhelmed with an insurmountable amount of custom policy development. In the worst-case scenario, overly permissive configurations could result in an event like the Capital One hack in 2019. This does not have to be the case. Development and security teams can work with just a few simple AltorCloud IAM checks. You'll also get remediation steps for each check we list below if your environment fails that check.

The AltorCloud IAM checks are based on cloud IAM Security best practices in these categories:

• Root Account Security 
• Key and Credential Rotation 
• Password Hygiene 
• Admin/Ops Specifications 
• Roles and Groups 
• Privilege Escalation 
• Logs and Alerts

Root Account Security

AWS recommends treating 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 can delegate permissions using roles and groups. These checks allow you to see if/when the root account has been accessed, ensure MFA is enabled, and control root account access keys, including:

• If the root account has been accessed (and if so, how recently)
• If a root account access key is present
• If the root account has MFA enabled
• If hardware MFA for the root account is enabled (this is helpful for some specific regulations    that require hardware MFA)
• Whether or not MFA is enabled for all IAM users with console passwords (If someone has a console password and disabled MFA, they are listed in the output.)
• Did any IAM users with root privileges receive access keys during the initial user setup?

Rotation of Keys and Credentials

AltorCloud recommends rotating access keys every 90 days and deactivating credentials that have been inactive for 90 days or more. These checks confirm those timelines and an additional one for those who prefer a shorter time frame.

• Disable credentials that have been inactive for 90 days or more.
• Make certain that access keys are rotated every 90 days or less.
• Disable credentials that have been inactive for 30 days or more.

Password Maintenance

Password policing is a pain, and if you use SAML, you won't have to worry about it (though having these checks properly configured is still good practice)! If you're using a CSP IAM as a user and password database, these checks make it easy to see if something slipped through the cracks. 

This set examines:
• At least one capital letter
• A minimum of one lowercase letter
• Include at least one symbol
• At least one digit
• Minimum length of 14 characters or more
• Reusing passwords (up to 24 previous passwords)
• The expiration date is 90 days or less.

Admin/Ops Specifics

Keep current who, where, and what information if something goes wrong. This set includes critical details such as:

• Whether or not security questions are set up in the AWS account
• Keeping contact email and phone numbers for AWS accounts up to date (and map to more than one individual in your organization)
• Registering your security team's contact information
• Ensuring the creation of a support role to manage incidents with AWS Support.

Users, Roles, and Groups


IAM users, groups, and roles cannot access AWS resources by default. IAM policies are how users, groups, or roles are granted privileges. AWS recommends that IAM policies be applied to groups and roles rather than users. As the number of users grows, assigning privileges at the group or role level reduces the complexity of access management. Reduced access management complexity may minimize the possibility of a user inadvertently receiving or retaining excessive privileges. This set demonstrates:

• IAM policies are only applied to specific groups or roles.
• IAM instance roles are used to grant instances access to AWS resources.
• MFA tokens are enabled for users in groups with an Administrator Access policy.
• There are no IAM custom policies that provide permissive role assumption (such as sts: AssumeRole on *).  
• The existence of two active access keys for IAM users. 
• If Hardware MFA is enabled for IAM users 
• If SAML Providers exist (Without a designated SAML provider, users with AWS CLI or AWS API access can use IAM static credentials. SAML helps users assume the proper role by default each time they authenticate.)

Privilege Escalation

Because it can take you off guard and do some serious harm, we created a specific category just for it. In essence, IAM permissions may allow some users to increase their privileges to administrator access. It's crucial to be aware of any privileges that an attacker could use to compromise your infrastructure, such as the ability to make a new IAM policy, launch a new EC2 instance, and access all of the associated instance profile/service role permissions, or create a new user access key that could give them full administrator access (and a bunch more bad things that stem from privilege escalation). 

• IAM policies that grant complete "*:*" administrative rights are not created
• Customer Managed IAM regulations prohibit behaviors that could escalate privileges.

Alerts and Logs 

Unauthorized API requests, policy changes, auth failures, and root account logins could all be unknown mistakes or indications of nefarious activity. Regardless, use this set of checks to ensure that log metric filters and alarms exist for the following: 

  • Unapproved API calls 
  • Signing into the Management Console without MFA 
  • Utilizing the root account 
  • IAM policy alterations 
  • Errors with the AWS Management Console's authentication 
This only scratches the surface of Altor Cloud's over 700 checks for thorough coverage of all your AWS, Azure, and GCP use cases. 
IAM

Similar posts

Subscribe to our CSPM in Action newsletter 

The CSPM in Action newsletter is for busy cloud security professionals who want to keep up to date with the cloud security industry.