CIS Benchmarks for AWS: A Practical Security Hardening Guide

Key Takeaways

• CIS AWS Foundations Benchmark v3.0.0 provides 60+ security controls across IAM, storage, logging, monitoring, and networking.
• AWS Security Hub automates compliance scanning with built-in CIS benchmark standards, providing continuous assessment.
• Common misconfigurations include root account usage, public S3 buckets, disabled CloudTrail, and overly permissive security groups.
• Mapping to compliance frameworks like SOC 2 and ISO 27001 is straightforward since both require the same fundamental security controls.
• Start with IAM and logging controls before moving to service-specific configurations, as these provide the broadest security impact.

If you're running infrastructure on AWS, you've likely asked the question: "How do we know our AWS environment is actually secure?" The CIS Benchmarks for AWS provide a concrete answer, offering consensus-driven security guidelines that translate abstract security requirements into specific, actionable configurations.

This guide covers what the CIS AWS Benchmarks are, the key controls you need to implement, common misconfigurations we encounter during audits, and how these controls map to compliance frameworks like SOC 2 and ISO 27001.

What Are CIS Benchmarks for AWS?

The Center for Internet Security (CIS) publishes security configuration guidelines for major cloud platforms, operating systems, and applications. For AWS, the primary document is the CIS Amazon Web Services Foundations Benchmark, currently at version 3.0.0 (released January 2024).

The benchmark provides prescriptive guidance covering:

• Identity and Access Management (IAM): Root account security, password policies, MFA requirements, access key rotation
• Storage: S3 bucket security, EBS encryption, access logging
• Logging: CloudTrail configuration, log file validation, encryption
• Monitoring: CloudWatch alarms, metric filters for security events
• Networking: VPC configuration, security groups, flow logs

Each control includes a rationale explaining why it matters, audit procedures to check compliance, and remediation steps to fix issues.

For background on how CIS Benchmarks relate to CIS Controls, see our guide on CIS Benchmarks.

Understanding the AWS Foundations Benchmark

The CIS AWS Foundations Benchmark organizes controls into sections that align with AWS service categories. Unlike operating system benchmarks that might contain hundreds of settings, the AWS benchmark focuses on account-level and service-level configurations that apply broadly across your AWS environment.

Profile Levels

Like other CIS Benchmarks, AWS controls are divided into two levels:

Most organizations should implement all Level 1 controls and selectively adopt Level 2 controls based on their risk profile and compliance requirements.

Key CIS Controls by Service Area

Identity and Access Management

IAM misconfigurations represent the highest-risk issues in AWS environments. The CIS Benchmark dedicates significant attention to this area:

Avoid using the root account for daily operations. The root account has unrestricted access to all resources and cannot be limited by IAM policies. Use it only for account-level tasks that specifically require root credentials, such as changing account settings or closing the account.

Enable MFA for the root account. This is non-negotiable. A compromised root account without MFA means complete loss of control over your AWS environment. Use a hardware MFA device for root, not a virtual authenticator that could be compromised along with other credentials.

Enable MFA for all IAM users with console access. Every human user who can log into the AWS Console should have MFA enabled. This single control blocks the majority of credential-based attacks.

Don't create access keys for the root account. Root access keys are particularly dangerous because they provide programmatic access with unlimited permissions. If root access keys exist, delete them immediately.

Rotate access keys every 90 days or less. Long-lived credentials are a liability. Better yet, minimize the use of access keys entirely by using IAM roles with temporary credentials for applications and AWS Identity Center for human users.

Enforce a strong password policy. The CIS Benchmark recommends:

• Minimum 14 characters
• At least one uppercase letter, lowercase letter, number, and symbol
• Password expiration within 90 days
• Prevent password reuse (remember at least 24 passwords)

Remove unused credentials. Access keys and passwords that haven't been used in 90 days should be disabled or deleted. AWS provides credential reports that show last-used timestamps for all IAM users.

S3 Storage Security

S3 misconfigurations remain one of the most common causes of data breaches in cloud environments:

Block public access at the account level. AWS provides S3 Block Public Access settings that can be applied at the account level. Enable all four settings (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) unless you have a specific, documented need for public buckets.

Enable S3 server-side encryption. All buckets should have default encryption enabled using either SSE-S3 (Amazon-managed keys) or SSE-KMS (customer-managed keys). SSE-KMS provides additional audit capabilities through CloudTrail.

Enable S3 bucket logging. Access logs provide visibility into who is accessing your data and when. These logs are essential for incident investigation and compliance evidence.

Require SSL for bucket access. Configure bucket policies to deny requests that don't use HTTPS. This prevents data interception during transit.

Enable versioning for critical buckets. Versioning protects against accidental deletion and provides a recovery path for ransomware scenarios. For compliance-sensitive data, combine versioning with Object Lock for immutable storage.

CloudTrail Logging

CloudTrail is the foundation of AWS security monitoring. Without it, you have no visibility into API activity:

Enable CloudTrail in all regions. A single trail with multi-region logging enabled captures API activity across all AWS regions, including regions you don't actively use. Attackers often target unused regions precisely because monitoring is weaker there.

Enable log file validation. CloudTrail can cryptographically sign log files to detect tampering. This is essential for maintaining log integrity and provides evidence that logs haven't been modified.

Encrypt CloudTrail logs with KMS. While CloudTrail logs are stored in S3 with server-side encryption by default, using a customer-managed KMS key provides additional access control and audit capabilities.

Ensure the CloudTrail S3 bucket is not publicly accessible. This should be obvious, but we've seen it misconfigured. CloudTrail logs contain sensitive information about your AWS activity and must be protected.

Enable access logging for the CloudTrail S3 bucket. This provides audit trails of who accessed your CloudTrail logs, which is important for detecting tampering attempts.

CloudWatch Monitoring

The CIS Benchmark specifies metric filters and alarms that should be configured to detect security-relevant events:

Create alarms for unauthorized API calls. Filter for events where errorCode contains *UnauthorizedAccess* or AccessDenied. Repeated unauthorized access attempts may indicate credential compromise or reconnaissance.

Create alarms for root account usage. Any root account activity should trigger an alert since root should rarely be used. Filter for $.userIdentity.type = "Root" and $.userIdentity.invokedBy NOT EXISTS.

Create alarms for IAM policy changes. Changes to IAM policies can indicate privilege escalation attempts. Monitor for CreatePolicy, DeletePolicy, CreatePolicyVersion, DeletePolicyVersion, AttachUserPolicy, DetachUserPolicy, and similar actions.

Create alarms for CloudTrail configuration changes. Attackers often try to disable logging to cover their tracks. Alert on StopLogging, DeleteTrail, and UpdateTrail events.

Create alarms for security group changes. Unauthorized changes to security groups can expose resources to the internet. Monitor for AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, and related events.

Create alarms for network ACL changes. Changes to NACLs can affect traffic flow across your VPC. These changes should be rare and deliberate.

Create alarms for VPC changes. Creation, deletion, or modification of VPCs, internet gateways, and route tables can have significant security implications.

VPC and Networking

Network security controls create defense-in-depth by limiting blast radius:

Ensure no security groups allow unrestricted SSH access. No security group should allow inbound SSH (port 22) from 0.0.0.0/0 or ::/0. Use AWS Systems Manager Session Manager, bastion hosts with restricted IP ranges, or VPN access instead.

Ensure no security groups allow unrestricted RDP access. The same principle applies to RDP (port 3389). Direct internet exposure of management ports is a significant risk.

Enable VPC Flow Logs for all VPCs. Flow logs capture network traffic metadata and enable you to detect anomalies, investigate incidents, and demonstrate network monitoring for compliance. The storage cost is minimal compared to the visibility gained.

Restrict the default security group. The default security group in each VPC should deny all inbound and outbound traffic. Resources should use custom security groups with explicit, documented rules.

EC2 and Compute

Enable EBS encryption by default. Configure your AWS account to encrypt all new EBS volumes by default. This ensures encryption is applied consistently without relying on individual engineers to remember.

Use IMDSv2 for EC2 instances. Instance Metadata Service version 2 (IMDSv2) requires session tokens for metadata requests, mitigating SSRF attacks that target the metadata endpoint. Configure instances to require IMDSv2.

Enable detailed monitoring for production instances. While basic monitoring provides metrics at 5-minute intervals, detailed monitoring provides 1-minute granularity needed for effective alerting.

RDS Database Security

Enable encryption for RDS instances. Like EBS, RDS encryption should be enabled at creation time. Encrypting an existing unencrypted database requires a migration process involving snapshot, restore, and cutover.

Disable public accessibility. RDS instances should not have public IP addresses unless absolutely necessary. Access databases through private subnets and use bastion hosts or Session Manager for administrative access.

Enable automated backups. Automated backups with appropriate retention periods protect against data loss and are typically required for compliance.

Enable deletion protection for production databases. This prevents accidental deletion of critical databases.

KMS Key Management

Enable key rotation for customer-managed KMS keys. AWS can automatically rotate KMS keys annually. This limits the exposure if key material is compromised and satisfies compliance requirements for key rotation.

Restrict key policies to necessary principals. KMS key policies should follow least privilege, granting encryption and decryption permissions only to the roles and users that need them.

Common AWS Misconfigurations We Find During Audits

Based on our compliance and security work with AWS customers, these issues appear repeatedly:

Root Account Used for Daily Operations

We frequently find organizations where the root account is used regularly, sometimes because it was the first account created and habits formed, sometimes because engineers find it easier than setting up proper IAM users. Root account usage creates massive risk because there's no way to limit what root can do.

The fix: create IAM users or use AWS Identity Center for all human access. Reserve root for the handful of tasks that specifically require it, and alert on any root usage.

Missing or Incomplete CloudTrail

Some organizations have CloudTrail enabled in their primary region but not globally. Others have it enabled but are only logging management events, missing data events for S3 and Lambda. Without comprehensive logging, incident response becomes guesswork.

The fix: enable a single trail with multi-region logging and log file validation. Consider enabling data events for S3 buckets containing sensitive information.

Public S3 Buckets

Whether intentional (for static website hosting) or accidental (misconfigured bucket policy), public buckets appear regularly in our assessments. The risk isn't just data exposure, it's also that attackers scan for public buckets and probe them automatically.

The fix: enable S3 Block Public Access at the account level. If you genuinely need public buckets, use a separate AWS account dedicated to public content and apply strict controls.

Overly Permissive Security Groups

We regularly find security groups allowing SSH from 0.0.0.0/0 that were created during initial setup and never locked down. The same applies to database ports exposed to the internet for "temporary" development access that became permanent.

The fix: audit all security groups allowing traffic from any source. Replace broad rules with specific IP ranges or use Session Manager for authenticated access without opening inbound ports.

Long-Lived Access Keys

Static access keys that haven't been rotated in years create significant risk, especially given the prevalence of credential-stealing malware and supply chain attacks. We find access keys embedded in configuration files, CI/CD pipelines, and developer machines.

The fix: use IAM roles instead of access keys wherever possible. For CI/CD, use OIDC federation with your provider (GitHub Actions, GitLab, etc.). For human users, use AWS Identity Center with short-lived credentials.

No MFA on IAM Users

Despite MFA being one of the most effective security controls, we still find AWS accounts where most IAM users don't have MFA enabled. Sometimes MFA is enabled initially but disabled when users complain about inconvenience.

The fix: enforce MFA through IAM policies that deny actions unless MFA is present. Make MFA non-negotiable for console access.

Using AWS Security Hub for CIS Compliance

AWS Security Hub provides automated compliance scanning against CIS Benchmarks. When you enable the CIS AWS Foundations Benchmark standard in Security Hub, it continuously evaluates your AWS accounts against the benchmark controls.

Key capabilities include:

Automated compliance checks: Security Hub runs periodic compliance assessments and generates findings when configurations don't meet benchmark requirements.

Compliance dashboard: View your compliance percentage across all controls, broken down by severity and status.

Integration with other AWS services: Security Hub aggregates findings from GuardDuty, Inspector, Macie, and third-party tools into a single view.

Multi-account support: Use AWS Organizations integration to assess compliance across all accounts in your organization.

Automated remediation: Combine Security Hub with AWS Config rules and Lambda functions to automatically remediate certain findings.

One limitation: not all CIS controls can be fully automated. Some require manual review or organizational processes that can't be detected through API scanning. Security Hub compliance percentages represent automated checks only.

Enabling CIS Benchmark Scanning

To enable CIS compliance scanning in Security Hub:

1. Navigate to AWS Security Hub in the Console
2. Go to Security standards
3. Enable "CIS AWS Foundations Benchmark"
4. Select the benchmark version (v1.4.0 or v3.0.0)

Security Hub will begin running compliance checks within a few hours and update continuously thereafter.

Mapping CIS Benchmarks to SOC 2 and ISO 27001

If you're pursuing SOC 2 Type 2 or ISO 27001 certification, CIS Benchmark compliance provides strong coverage of the technical controls these frameworks require.

SOC 2 Alignment

The SOC 2 Trust Services Criteria map directly to CIS controls:

ISO 27001 Alignment

ISO 27001 Annex A controls also align with CIS recommendations. The table below references ISO 27001:2022 control categories:

Implementing CIS Benchmarks doesn't automatically make you compliant with either framework, but it addresses the majority of technical controls auditors will examine.

AWS Security Hardening Checklist

Use this checklist to assess your current CIS Benchmark compliance:

IAM

• Root account has MFA enabled (hardware device preferred)
• No root account access keys exist
• Root account is not used for daily operations
• All IAM users with console access have MFA enabled
• Strong password policy configured (14+ characters, complexity, rotation)
• Access keys rotated within 90 days
• Unused credentials disabled or deleted
• IAM policies follow least privilege

Storage

• S3 Block Public Access enabled at account level
• S3 default encryption enabled on all buckets
• S3 bucket logging enabled
• S3 bucket policies require SSL
• EBS default encryption enabled
• Versioning enabled for critical buckets

Logging

• CloudTrail enabled in all regions
• CloudTrail log file validation enabled
• CloudTrail logs encrypted with KMS
• CloudTrail S3 bucket not publicly accessible
• CloudTrail S3 bucket logging enabled

Monitoring

• Alarm for unauthorized API calls
• Alarm for root account usage
• Alarm for IAM policy changes
• Alarm for CloudTrail configuration changes
• Alarm for security group changes
• Alarm for NACL changes
• Alarm for VPC changes

Networking

• No security groups allow SSH from 0.0.0.0/0
• No security groups allow RDP from 0.0.0.0/0
• VPC Flow Logs enabled for all VPCs
• Default security group restricts all traffic

Compute

• EBS encryption enabled by default
• IMDSv2 required for EC2 instances
• Detailed monitoring enabled for production instances

Databases

• RDS instances encrypted
• RDS instances not publicly accessible
• Automated backups enabled
• Deletion protection enabled for production databases

KMS

• Key rotation enabled for customer-managed keys
• Key policies follow least privilege

Bastion helps companies achieve SOC 2, ISO 27001, and other compliance certifications while ensuring their cloud infrastructure is genuinely secure. If you're working on AWS security hardening or preparing for a compliance audit, reach out to us.