AWS CIS Benchmark Foundations v3.0 Hardening Guide

What the CIS AWS Foundations Benchmark Actually Covers

The CIS Amazon Web Services Foundations Benchmark is the authoritative configuration baseline for the AWS control plane. Where CIS benchmarks for operating systems target individual host configurations, the AWS Foundations benchmark targets the account-level configuration of AWS itself: how IAM is configured, what logging is enabled, how networking is structured, how storage is protected, and how the management plane is monitored.

The benchmark is one of the most heavily used CIS benchmarks because AWS misconfiguration is one of the most common sources of cloud security incidents. Public S3 buckets, overly permissive IAM policies, disabled CloudTrail logging, root account misuse, and unencrypted EBS volumes have driven a large share of publicly reported cloud breaches over the past decade. The Foundations benchmark directly addresses these failure modes.

Version 3.0 (released in 2024) is the current major version. It contains approximately 200 controls split across Level 1 and Level 2 profiles, organized into sections covering Identity and Access Management, Storage, Logging, Monitoring, and Networking.

Section 1: Identity and Access Management

The IAM section is the largest section of the benchmark by far. AWS security failures disproportionately originate in IAM misconfiguration, so the benchmark concentrates significant attention here.

Critical controls in this section include:

Avoid using the "root" user. The root user has unconstrained access. Daily operations should never use root. Root access should be required only for specific account-management actions (changing the account email, closing the account) and the credentials should be stored in a way that creates an audit trail when used.

Ensure MFA is enabled for the "root" user account. Hardware MFA is strongly preferred for the root account because phishing-resistant authentication is essential for the most privileged credential in the account.

Ensure no root user account access key exists. Root access keys should not exist. They are not needed for normal operations and create a credential that, if exposed, gives full account access.

Ensure MFA is enabled for all IAM users with a console password. Every interactive user must use MFA. Service principals and machine identities use IAM roles and short-lived credentials, not console access.

Ensure access keys are rotated every 90 days or less. Long-lived access keys are a common breach vector. Rotation is the mitigation.

Ensure IAM policies are attached only to groups or roles. Direct user-to-policy attachment creates inconsistent permissions and complicates access reviews. Groups and roles are the right scope for policies.

Ensure a support role has been created to manage incidents with AWS Support. AWS Support actions require permissions; creating a dedicated role separates support access from general administration.

Ensure IAM users with console access have password policies enforced. Account password policy requires complexity, minimum length, rotation, and reuse prevention.

The pattern across these controls: minimize root use, enforce strong authentication, avoid long-lived credentials, structure permissions through groups and roles, and review regularly.

Section 2: Storage

The storage section addresses S3, EBS, and RDS configuration. The most consequential controls:

Ensure all S3 buckets employ encryption at rest. Server-side encryption (SSE-S3 or SSE-KMS) prevents data exposure if the underlying storage layer is somehow accessed directly.

Ensure S3 bucket policy is set to deny HTTP requests. S3 must require TLS for data transmission. The bucket policy condition is a one-line addition.

Ensure MFA Delete is enabled on S3 buckets. For buckets containing critical data, MFA Delete prevents accidental or malicious bulk deletion.

Ensure access logging is enabled on the CloudTrail S3 bucket. The bucket holding CloudTrail logs must itself log access events, creating a verifiable trail of access to audit data.

Ensure that EBS volumes are encrypted by default. The account-level EBS encryption default ensures new volumes are encrypted without requiring per-volume configuration.

Ensure RDS instances are encrypted. RDS snapshot and storage encryption protects database content at rest.

Ensure RDS instances are not publicly accessible. Database instances should not be reachable from the public internet under normal architecture patterns.

The S3 controls deserve specific attention because public S3 exposure has been the single most reported cloud breach root cause. Blocking public access at the account level via S3 Block Public Access is the central control.

Section 3: Logging

The logging section governs CloudTrail and other audit data sources. CloudTrail is the AWS audit log: it records every API call against the account. Without CloudTrail, security event reconstruction is impossible.

Critical controls:

Ensure CloudTrail is enabled in all regions. The benchmark explicitly requires a multi-region trail. Regional gaps are common findings and create blind spots.

Ensure CloudTrail log file validation is enabled. Log file validation produces cryptographic hashes of log files, allowing detection of tampering.

Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible. The audit log itself becomes a target. Public access controls and bucket policies must protect it.

Ensure CloudTrail trails are integrated with CloudWatch Logs. CloudWatch Logs integration enables alerting on log events and supports the monitoring controls in Section 4.

Ensure AWS Config is enabled in all regions. AWS Config provides a separate inventory and configuration history that complements CloudTrail.

Ensure S3 bucket access logging is enabled on the CloudTrail bucket. Layered audit: who accessed the audit logs themselves.

Ensure CloudTrail logs are encrypted at rest using KMS keys. KMS-encrypted CloudTrail data is protected even if the storage layer is exposed.

Ensure rotation for customer-created KMS keys is enabled. KMS key rotation reduces the impact of key compromise.

The Logging section is foundational. Many other controls assume CloudTrail is operating; without it, the rest of the benchmark cannot be enforced or evidenced.

Section 4: Monitoring

The monitoring section establishes alarms on security-relevant events. Each control specifies a CloudWatch metric filter and alarm that detects a specific event type. Implementation is straightforward (the patterns are well-documented) but operationally consequential — the alarms drive incident response.

Key alarms the benchmark requires:

Unauthorized API calls: any API call that returned AccessDenied

Console sign-in without MFA: console access by an account without MFA

Root account use: any root account API call

IAM policy changes: changes to IAM policies, especially permissive ones

CloudTrail configuration changes: any modification to CloudTrail configuration

AWS Config configuration changes: any modification to AWS Config recording

Security group changes: changes to security group rules

Network ACL changes: changes to network ACLs

Network gateway changes: changes to internet gateways, NAT gateways, VPN connections

Route table changes: changes to routing

VPC changes: changes to VPC configuration

KMS customer-managed key disable or deletion: changes to keys that protect data

The alarms route to SNS topics that integrate with the organization's incident response tooling. Without the alarms, security-relevant changes occur silently and are detected only at the next manual review.

Section 5: Networking

The networking section addresses VPC, security group, and egress configuration:

Ensure no security groups allow ingress from 0.0.0.0/0 to port 22 (SSH): SSH from the public internet should never be permitted on production resources. Use bastion hosts or SSM Session Manager.

Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389 (RDP): same principle for Windows.

Ensure the default security group restricts all traffic: the default security group, created automatically with every VPC, should explicitly deny all traffic. Resources should be placed in purpose-specific security groups.

Ensure VPC flow logging is enabled in all VPCs: VPC Flow Logs capture network metadata for forensic and detection purposes.

Ensure no Network ACLs allow ingress from 0.0.0.0/0 to port 22 or 3389: same restriction at the network ACL layer.

Ensure routing tables for VPC peering are "least access": VPC peering routes should specify exactly the destination CIDR blocks needed, not broad ranges.

The 0.0.0.0/0 ingress controls are the most consistently violated in real-world AWS accounts. The fix is mechanical (security group rule modification) but the operational discipline to maintain the constraint requires ongoing scanning.

Level 1 vs Level 2 in the AWS Benchmark

The AWS Foundations benchmark uses the standard CIS L1/L2 split:

Level 1 controls are intended for the general-purpose AWS account. They reduce attack surface meaningfully without breaking common patterns.

Level 2 controls add stricter requirements that may impose constraints on application patterns or operational practices.

Examples of L2-specific controls:

Hardware MFA on the root account (L1 requires MFA; L2 specifies hardware MFA)

Stricter password policy parameters

Specific KMS rotation cadences

Additional logging detail

Stricter network restrictions

For most production AWS accounts handling regulated data, L2 is appropriate. For development accounts and non-sensitive workloads, L1 may be sufficient. The choice should be deliberate and documented.

Common AWS Configuration Drift Patterns

Across AWS environments, certain drift patterns recur consistently:

S3 bucket policies opened for troubleshooting and never closed. A bucket is made publicly accessible to enable a partner integration, the integration is decommissioned, and the public access remains.

Security groups opened to broader CIDR ranges than needed. A developer adds 0.0.0.0/0 ingress to debug a connectivity issue and forgets to revert.

CloudTrail disabled in non-production regions. Account expansion into a new region without enabling CloudTrail in that region.

IAM users created with broad permissions. New IAM users created with AdministratorAccess for convenience, with policy refinement deferred.

Access keys created and not rotated. Service integration requires an access key, the key is generated and stored, and rotation never happens.

KMS key rotation disabled. Key created with rotation disabled, and the default is never reversed.

VPC flow logging not enabled on new VPCs. New VPC created via console or template that does not enable flow logging.

Each pattern is a finding when assessed against the benchmark. Continuous scanning catches each within minutes; periodic scanning catches them at the next audit cycle, after they have lived in the account for weeks or months.

Integrating the Benchmark with AWS Security Services

AWS provides several services that complement CIS benchmark scanning:

AWS Security Hub aggregates findings from many sources, including a built-in CIS AWS Foundations Benchmark check. Security Hub is useful but not a substitute for purpose-built compliance tooling: its findings are point-in-time, its remediation tracking is limited, and its multi-framework mapping is narrower than purpose-built tools.

AWS Config records configuration history and can evaluate resources against rules. Custom Config rules can implement specific benchmark checks. AWS Config is foundational and should be enabled regardless of other tooling.

AWS GuardDuty detects threats based on log analysis. GuardDuty complements benchmark scanning by detecting active exploitation; the benchmark addresses configuration hygiene.

AWS Inspector evaluates workload vulnerabilities. Inspector addresses CVE-level vulnerabilities; benchmarks address configuration controls.

The full security posture combines benchmark scanning (configuration), Inspector (vulnerabilities), GuardDuty (active threats), and Security Hub (aggregation). No single tool covers all four domains.

How Continuous Compliance Operationalizes the AWS Benchmark

Manual benchmark assessment against AWS accounts is impractical at any meaningful scale. With dozens to thousands of accounts, hundreds to thousands of resources per account, and continuous change driven by IaC deployments and operational activity, configuration drift cannot be controlled by quarterly audits.

Continuous compliance scanning provides:

Per-account, per-day compliance assessment against the full benchmark

Real-time drift detection when controls degrade

Per-resource detail showing the specific resource and the specific control violated

Remediation tracking with named owner, target date, and compensating control

Multi-account rollup across organizations and OUs

Multi-framework mapping showing how each control maps to NIST 800-53, ISO 27001, SOC 2, HIPAA, PCI DSS

The shift from periodic audit to continuous monitoring eliminates the most common AWS security failures as a class.

How CISGuard Supports AWS CIS Benchmark Compliance

CISGuard's AWS scanner evaluates the full CIS AWS Foundations Benchmark v3.0 with the operational patterns AWS environments require:

Multi-account scanning across an organization with rollup reporting

Per-region evaluation with regional gap visibility

Continuous scanning at configurable cadence

Drift detection with timestamped baseline comparisons

Multi-framework mapping showing how each AWS control satisfies NIST 800-53, ISO 27001, SOC 2, FedRAMP, CMMC, HIPAA, PCI DSS, and other frameworks

AWS GovCloud support for FedRAMP and CMMC environments

Immutable audit trail for assessor and continuous monitoring evidence

See AWS CIS Benchmark coverage in CISGuard or request an AWS compliance assessment.