Best Practices for Privilege Management in AWS

by Sarah Harvey / October 25th, 2019

Could what happened at Capital One happen at your organization?

That depends on your commitment to cloud security. This breach could happen to any organization that’s not educated on AWS vulnerabilities and best practices. We’ve talked about how security misconfigurations played a role in Capital One’s breach, but now let’s discuss how privilege management contributed to this successful hack.

What Happened at Capital One with IAM Misconfigurations?

According to Verizon’s 2019 DBIR, misuse of privileges is the cause of nearly 70% of breaches and 29% of all breaches involve the use of stolen credentials. Privilege management, misuse, and Identity & Access Management (IAM) misconfigurations led to the first misstep in the Capital One Breach.

When the attacker executed the first command, the hack began. This command allowed the attacker to acquire security credentials for a specific WAF-role with elevated privileges that had access to folders in Capital One’s AWS environment.

Did this role need elevated privileges?

The public can’t know for a fact. Were those credentials protected appropriately? Apparently not, because the environment was susceptible to the SSRF attack that had detrimental consequences for Capital One. It’s important to evaluate privileges assigned to all roles in your organization.

The Principle of Least Privileges in AWS

In AWS, the concept of least privilege means that you give users the least amount of access and responsibility necessary to complete their duties. Least privilege is also referred to as role-based access or need-to-know access and falls under AWS Identity and Access Management policies.

Configuring a system based on least privileges and need-to-know principles aren’t new concepts, but many organizations fail in this area. Best practice for least privileges comes down to the assignment of roles and responsibilities, limiting access based on what’s required, and creating a separation of duties. Consider the following requirements from industry frameworks:

SOC 2 common criteria 6.3 says, “The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.”
We see the subject of least privileges again in PCI Requirement 7.1.2, where it requires organizations to limit access to privileged user IDs to personnel who truly require it for the function of their job.
Least privileges and minimum necessary is also key to the HIPAA Privacy Rule, which requires covered entities to enhance their safeguards to limit unnecessary or inappropriate access to and disclosure of PHI.

AWS Security Best Practices for IAM

Best practice for least privileges is to ensure that your policies allow the fewest actions and access to resources as possible.

It is even AWS’ recommendation that when you create IAM policies, you begin with least privileges and then grant elevated privileges when necessary. IAM policies should also be tested by someone with knowledge of your AWS environment and IAM policies for assurance that they are functioning as intended.

AWS recommends creating IAM policies surrounding these subject areas:

Lock Away AWS Account Root User Access Keys
Create Individual IAM Users
Use Groups to Assign Permissions to IAM Users
Grant Least Privilege
Get Started Using Permissions with AWS Managed Policies
Use Customer Managed Policies Instead of Inline Policies
Use Access Levels to Review IAM Permissions
Configure a Strong Password Policy for Users
Enable MFA
Use Roles for Applications that Run on Amazon EC2 Instances
Use Roles to Delegate Permissions
Do Not Share Access Keys
Rotate Credentials Regularly
Remove Unnecessary Credentials
Use Policy Conditions for Extra Security
Monitor Activity in Your AWS Account

Don’t underestimate the value and complexity of IAM policies, though – especially in AWS. IAM policies are one of the most complicated things out there because you have to have an operational and security perspective. IAM policies give your organization the power over which actions can be performed by or on any given resource in your AWS environment. How does your organization ensure that IAM policies protect your AWS environment?

How to Strengthen AWS Environments With Proper IAM

As more data migrates to AWS, organizations must have processes in place to validate their cloud security efforts. Whether that’s through consulting with an AWS Cloud Practitioner or CCSK, something like a SOC 2 audit, or advanced penetration testing, you need a third party’s perspective and expertise to gain assurance.

What consequences would you face if, like Capital One, your clients’ data was compromised?

We don’t want you to ever have to find out. Let’s partner together to secure your AWS environment.