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?
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 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.
Back to Basics: Least Privileges
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.
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
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.