Improving your AWS Security posture: Key learnings from the State of AWS Security study

Introduction

We recently released a study on the State of AWS Security in 2022. We analyzed the AWS security posture of 600+ organizations and thousands of AWS accounts and concluded that:

• IAM users are often mismanaged and the industry views leaked access keys as a major cause of breaches in AWS environments;
• Many organizations still expose S3 buckets publicly, as well as other resources such as SQS queues and SNS topics;
• The vast majority of EC2 instances are not enforcing usage of the instance metadata service V2 (IMDSv2).

Key recommendations to improve your AWS security posture

Cloud security is an ongoing challenge for many organizations, particularly as teams are increasingly tasked with managing complex environments. However, implementing just a few key best practices can help significantly reduce your attack surface and protect your organization from security breaches. Below, we'll walk through recommendations that will enable you to improve your AWS security posture.

Don’t use IAM users for humans

Using IAM users to authenticate humans is both cumbersome and risky, especially in multi-account environments. Leaked credentials are a common cause of security breaches in AWS, so you should avoid creating IAM users for use cases that don't require them. For instance, it is a common misconception that IAM users are required for using the AWS Command Line Interface (CLI) or SDKs. In reality, AWS IAM Identity Center (formerly AWS SSO) and IAM role federation provide safer and more convenient solutions. AWS IAM Identity Center integrates with popular identity providers, such as Okta and Azure Active Directory, to make this workflow even more seamless.

If you'd like to automatically enforce this best practice, you can set up an AWS organization-wide service control policy (SCP) to prevent IAM users from being created in certain accounts or parts of your organization.

Avoid using IAM users for workloads

Workloads that need to access the AWS API frequently use IAM users to do so. However, if your workloads are running in AWS, it is highly recommended to use AWS-native mechanisms instead. This helps ensure that you don't run the risk of leaking long-lived, static credentials.

AWS provides a range of solutions to help specific types of workloads securely authenticate to AWS without using IAM access keys.

For any workloads that do not run in AWS, you can use a credentials broker, such as HashiCorp Vault, to act as an intermediary between your application and AWS. This helps mitigate security risks by ensuring that your workloads will only use temporary credentials to authenticate to AWS. AWS also recently released IAM Roles Anywhere, which allows legacy applications to generate temporary credentials using client-side X.509 certificates.

Alternatively, if your legacy application uses a fixed IP to access AWS, you can restrict the use of an IAM user to that specific IP by configuring your identity-based policy to explicitly deny access to all other IPs.

Restrict use of the root user

The root user should not be used for daily operations; it should only be used for a very specific set of tasks when no other option is available. As a best practice, you should not create any access keys for the root user because it can add significant risk in the event that these access keys are leaked and used by a malicious actor.

You can use an organization-wide service control policy (SCP) to proactively block usage of the root user, as shown in this example.

Enforce usage of the EC2 Instance Metadata Service V2 (IMDSv2)

The EC2 Instance Metadata Service Version 2 (IMDSv2) is designed to help protect applications from server-side request forgery (SSRF) vulnerabilities. By default, newly created EC2 instances will allow use of both versions of the IMDS. However, you can use a service control policy (SCP) to enforce the use of IMDSv2 across all EC2 instances created in an AWS account. Failure to do so will result in an access denied error.

To remediate existing workloads, you can use an open source tool like Metabadger, or consult AWS’s guide to transitioning to IMDSv2.

Finally, AWS recently released a new AMI setting that causes the IMDSv2 to be enforced by default for new EC2 instances created from this image.

Although IMDSv2 was released in 2019, note that some applications or scripts are still not compatible or may require changes to make use of it.

Enable account-wide S3 Block Public Access

To reduce the impact of misconfigured S3 buckets, AWS provides a feature known as S3 Block Public Access. This enables you to safely block public access to individual buckets or even across an entire AWS account. It is recommended that you use this feature to block public access to all S3 resources in your AWS account. You can then place buckets that are intended to be public behind a CloudFront distribution.

Optionally, you can use an SCP to prevent users from modifying S3 Block Public Access settings.

How Datadog can help

Modern cloud environments need to support rapidly evolving services, teams, and business requirements, which can make it challenging for organizations to identify and focus on the threats that matter most. The Datadog Cloud Security Platform can help safeguard your production environment by providing real-time threat detection, continuous configuration audits, and visibility into code-level vulnerabilities. Below, we'll explore how Datadog can help you prevent, detect, and mitigate security issues in real time.

Cloud Security Management

Datadog Cloud Security Management makes it easier to assess and visualize the current and historic security posture of your cloud environment, automate audit evidence collection, and catch misconfigurations that leave your organization vulnerable to attacks.

You can automatically detect the vulnerabilities discussed in the study by using the following out-of-the-box rules to ensure that:

• Multi-factor authentication is enabled for all IAM users with a console password
• IAM credentials have been used within the last 90 days
• No root user access key exists
• Root account credentials have not been used in the past 30 days
• No IAM access keys are older than one year and have not been used in the last 30 days
• Access keys are rotated every 90 days or less
• EC2 instance uses IMDSv2
• SNS topic is not publicly accessible
• SQS queue is not publicly accessible
• S3 bucket is configured with Block Public Access

Cloud SIEM

Datadog Cloud SIEM provides robust threat detection for dynamic, cloud-scale environments. With Cloud SIEM, you can analyze operational and security logs in real time—regardless of their volume—while utilizing curated, out-of-the-box integrations and rules to detect threats. Developers, security, and operations teams can also leverage detailed observability data to accelerate security investigations in a single, unified platform.

You can use the following out-of-the-box rules to identify exploitation of the vulnerabilities discussed in the study:

• AWS root account activity
• AWS Console login without MFA
• Potential brute force attack on AWS Console login
• AWS Console login without MFA triggered Impossible Travel scenario

Application Security Management

Datadog Application Security Management (ASM) delivers deep, real-time visibility into attacks that target your web applications and APIs.

You can use the following out-of-the-box rules to identify exploitation of SSRF vulnerabilities in AWS, which is a popular method used by attackers to compromise cloud credentials:

• SSRF vulnerability triggered
• SSRF attempts on route executing network queries

Conclusion

In this post, we reviewed the key findings from the State of AWS Security study. We then discussed several cloud-native mechanisms that help maintain a good security hygiene in an AWS environment.

Investing early in securing identities, implementing guardrails and providing secure defaults goes a long way towards securing cloud environments against the most common causes of data breaches.