In the cloud, securing identities and workloads is both paramount and complex. Inventories of AWS customer security breaches help us learn from publicly disclosed incidents—but until now, not much concrete data has been shared around the usage of security mechanisms that could have helped prevent these incidents. For this report, we examined real-world data from a sample of more than 600 organizations and thousands of AWS accounts that use Datadog's Cloud Security Management.
To shed light on the state of security of AWS security in 2022, we analyzed trends in the implementation of security best practices and took a closer look at various types of misconfigurations that contribute to the most common causes of security breaches. In particular, we’ll see some of the main challenges of managing static, long-lived credentials; the importance of identifying and fixing insecure defaults early; and how the complexity of AWS Identity and Access Management (IAM) may lead organizations to unintentionally expose sensitive resources publicly. Read on to learn more about the state of AWS cloud security in real-world environments.
IAM users are challenging to securely manage at scale
AWS Identity and Access Management (IAM) users can be used to authenticate humans, either by setting up a password that allows access to the AWS Console or a long-lived access key that allows authentication to the AWS API. Access keys are also frequently used to authenticate workloads.
Because access keys are static credentials that do not expire, they are widely regarded as highly sensitive and a major cause of AWS security breaches. A 2022 GitGuardian study found that, on average, every 10,000 Git commits leak 84 AWS access keys. Access keys are frequently leaked (e.g., in logs, build outputs, stack traces) and targeted by attacker groups such as TeamTNT.
In particular, we found that:
- 40 percent of IAM users have not used their credentials in the past 90 days (access key or console password), affecting 70 percent of organizations.
- 40 percent of organizations have at least one IAM user that has AWS Console access and does not have multi-factor authentication (MFA) enabled, accounting for a 10 percent of all IAM users. Without the additional protection of MFA, these users are particularly vulnerable to credential stuffing and brute force attacks.
Furthermore, among IAM users with active access keys:
- 25 percent of IAM users have an active access key that’s both older than one year and hasn’t been used in the past 30 days. This combination of characteristics typically corresponds to IAM users that are unused and should be removed.
- 75 percent of IAM users have an active access key that’s older than 90 days. Rotating IAM access keys is highly challenging, especially at scale.
This data highlights the difficulty of properly managing IAM credentials when, for instance, an employee leaves the company or an application is decommissioned. Furthermore, it reinforces the importance of not using IAM users to authenticate humans and workloads when other, safer alternatives are available, such as AWS IAM Identity Center (formerly AWS SSO) for humans and EC2 instance roles or Lambda execution roles for applications.
IAM root user credential usage is low, but still represents a risk
The root user is automatically provisioned when an AWS account is created. This user has unlimited administrative permissions. In particular, it can download any sensitive data and even completely delete the whole AWS account. To reduce risk, it is a best practice to avoid creating any access keys for the root user in the first place.
However, we identified that:
- Roughly 10 percent of organizations have an active root user access key. This represents 3 percent of all AWS accounts. Some of these keys are up to 13 years old.
- 25 percent of organizations had used root user credentials in the 30-day period preceding the making of this research.
Usage of root user credentials does not always automatically signal a red flag. These credentials are required in highly specific situations, such as changing AWS account settings. However, the overhead of maintaining active root user access keys represents a significant risk, as long-lived static credentials often end up being leaked in source code, configuration files, logs, or stack traces and are responsible for many documented AWS customer security breaches. Compromised root user credentials can be particularly problematic because they grant unrestricted access to the entire account.
The complexity of AWS IAM leads to publicly exposed resources
When using services such as Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS), or Amazon S3, organizations commonly configure cross-account access by using a resource-based IAM policy attached to the resource itself.
We identified that:
- 18 percent of organizations that use SQS have at least one publicly exposed queue, allowing anyone to receive or publish messages to those queues.
- 15 percent of organizations that use SNS have at least one publicly exposed topic, allowing anyone to perform sensitive actions against those topics (e.g., retrieving or publishing notifications).
- 36 percent of organizations that use S3 have at least one publicly exposed bucket, representing 2 percent of all S3 buckets.
We assess that this can be attributed to the complexity of creating AWS IAM policies that grant only required permissions. Creating secure IAM policies that grant least-privilege, granular permissions can be difficult in complex environments that involve many teams, applications, and ephemeral resources. After encountering one too many "access denied" errors, teams may find it more convenient to create less restrictive IAM policies in order to avoid bottlenecking their workflows.
This problem is so prevalent that members of the community have developed tools like Repokid and Policy Sentry to address various IAM-related pain points. Although these tools can help, they also highlight the ongoing challenges of crafting IAM policies that grant necessary permissions—and keeping them up to date as those requirements change—without blocking workflows.
The Instance Metadata Service V2 (IMDSv2) is not enforced by default, leaving EC2 instances at risk
Server-side request forgery (SSRF) is an application-level vulnerability that has been consistently and frequently exploited by attackers for years. In AWS, this type of vulnerability allows an attacker to trick an application into calling the EC2 Instance Metadata Service (IMDS) in order to successfully obtain credentials bound to an instance role. An attacker can then use these credentials to authenticate against the AWS API or access the AWS Console.
This technique has been used in several high-profile incidents, such as the Capital One breach, and was even called out by name by U.S. Senator Ron Wyden in a letter to AWS: "A number of cybersecurity experts have publicly speculated that the Capital One hacker exploited a Server-Side Request Forgery (SSRF) vulnerability, a flaw about which experts have been warning for years. To the best of Amazon's knowledge, was a SSRF attack used to gain access to Capital One's customer data?"
In 2019, AWS released version 2 of the EC2 IMDS (IMDSv2) to help mitigate this vulnerability. However, we identified that the vast majority of EC2 instances (93 percent) are not enforcing the usage of IMDSv2. Overall, 95 percent of organizations that use EC2 have at least one vulnerable instance.
We believe that this can be attributed to a lack of secure defaults. Unless explicitly configured to enforce version 2, newly created EC2 instances still allow the use of version 1 of the IMDS, leaving them vulnerable to SSRF attacks.
At least 40 percent of organizations use multiple AWS accounts
Adopting a multi-account strategy in AWS is essential for limiting the blast radius of a compromised application or user account, among other benefits. However, some early stage organizations may opt to use a single AWS account in order to reduce the overhead of creating and managing multiple accounts. Services such as AWS Organizations are designed to help address this concern by centralizing account governance and automating the creation of new AWS accounts (e.g., by using infrastructure as code).
Our data shows that at least 41 percent of organizations have adopted a multi-account strategy in AWS.
Six percent of organizations heavily implement a multi-account strategy by using more than 10 AWS accounts. Furthermore, a long tail of 0.6 percent use more than 100 AWS accounts—and some of these organizations have several thousands of AWS accounts.
These figures should be interpreted as lower bounds, because organizations using Datadog may not monitor all of their AWS accounts, such as those used for testing or development purposes.
Findings are based on data collected in September 2022.
For this report, we analyzed the AWS security posture of a sample of more than 600 organizations that use Datadog's Cloud Security Management and AWS integration to monitor their environments. While the results presented are biased by the fact that the data comes from our customer base, these organizations are widely diverse in terms of geography, industry, size, and maturity in their cloud journey. Consequently, we believe they provide an accurate representation of organizations using AWS worldwide.
This research was performed against an anonymized dataset that does not contain personally identifiable information or sensitive information, such as resource names or tags.
SQS queues and SNS topics
We define a publicly accessible SQS queue or SNS topic as a queue or topic that has a resource-based policy that allows the principal “*” to perform an action, and does not have a condition statement that further restricts the context in which the action is authorized.
We define a publicly accessible S3 bucket as a bucket that matches at least one of the following criteria:
- Bucket policy has at least one statement that allows an action on the bucket without conditions
- Bucket ACL grants full control to ”authenticated users”
- Bucket ACL grants full control to all users
IAM users and multi-factor authentication (MFA)
We define an “IAM user with AWS Console access that does not have MFA enabled” as an IAM user that (a) has created an AWS Console password and (b) has not enrolled an MFA device.
RATIO COMPUTED OVER
|Organizations with more than 1 AWS account||41 %||All organizations|
|Organizations with more than 10 AWS accounts||5 %||All organizations|
|IAM users with inactive credentials (console password or access key active, and not used in the past 90 days)||39 %||All organizations|
|Organizations with at least 1 IAM user with inactive credentials||70 %||All organizations|
|IAM users with an access key older than 1 year that has not been used in the past 30 days||25 %||All IAM users|
|IAM users with at least 1 active access key older than 90 days||60 %||All IAM users|
|IAM users with at least 1 active access key older than 90 days||76 %||IAM users with at least 1 active access key|
|Organizations with at least 1 IAM user with console access and no MFA device enrolled||40 %||All organizations|
|IAM users with console access and no MFA device enrolled||11 %||All IAM users|
|Organizations with at least 1 active root user access key||9 %||All organizations|
|AWS accounts with at least 1 active root user access key||3 %||All AWS accounts|
|Organizations having used root user credentials in the last 30 days (access key or console password)||23 %||All organizations|
|EC2 instances not enforcing usage of the IMDSv2||93 %||All EC2 instances|
|Organizations with at least 1 EC2 instance not enforcing usage of the IMDSv2||95 %||Organizations with at least 1 EC2 instance|
|Organizations with at least 1 publicly readable S3 bucket||36 %||Organizations with at least 1 S3 bucket|
|Publicly accessible S3 buckets||36 %||Organizations with at least 1 S3 bucket|
|Organizations with publicly exposed SNS topics||15 %||Organizations with at least 1 SNS topic|
|Organizations with publicly exposed SQS queues||18 %||Organizations with at least 1 SQS queue|