CIS AWS Benchmark v1.2.0

Deprecated Framework

This framework has been superseded by CIS AWS Benchmark v1.4.0 and later versions. Organizations should migrate to newer versions for updated security controls and best practices.

Best for: Organizations that adopted CIS AWS Foundations Benchmark v1.2.0 before v3.0.0 superseded it, and still carry audit evidence or compliance tracking tied to this version. Some internal security teams and GRC platforms reference v1.2.0 controls in legacy risk registers. If your auditor or customer contract explicitly specifies v1.2.0, you need this. Otherwise, migrate to CIS AWS Foundations Benchmark v3.0.0 or later.

Mandatory?	Voluntary security baseline
Who validates?	Self-assessment or third-party
Renewal	No fixed cycle
Scope	AWS cloud environments; two levels (L1/L2)

🏛 Center for Internet Security (CIS) · CIS AWS Benchmark v1.2.0 (superseded) Official source →

Get Started

module "..." {
  source  = "cisv120.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

What Compliance.tf automates

IAM User Management: Runs the iam_user_in_group control to verify that all IAM users have at least one group membership. Flags orphaned users with no group association.
CloudTrail and Audit Log Integrity: Checks that CloudTrail trail S3 buckets have MFA delete enabled via the cloudtrail_trail_bucket_mfa_enabled control.
Secrets Rotation and Lifecycle: Runs four Secrets Manager controls covering automatic rotation Lambda configuration, 90-day rotation compliance, schedule adherence, and unused secret detection.
WAF Logging and Configuration: Validates that WAF and WAFv2 web ACLs have logging enabled, that WAFv2 rule groups emit CloudWatch metrics, and that regional web ACLs have at least one rule attached.
S3 Bucket Protection: Checks s3_bucket_mfa_delete_enabled to confirm MFA delete is active on S3 buckets.

What you handle

IAM User Management: Defining group permission boundaries, reviewing group policy documents, and removing users who no longer need access.
CloudTrail and Audit Log Integrity: Configuring MFA devices for the root account (required to enable MFA delete on S3), establishing log retention policies, and monitoring for log tampering through external SIEM integration.
Secrets Rotation and Lifecycle: Writing and testing rotation Lambda functions, defining rotation schedules appropriate for each secret type, and coordinating rotation with dependent applications to avoid outages.
WAF Logging and Configuration: Defining WAF rule logic, tuning rules to reduce false positives, configuring log destinations (S3, CloudWatch Logs, Kinesis), and reviewing WAF logs for threat patterns.
S3 Bucket Protection: MFA delete requires root account credentials and cannot be enabled through Terraform alone. You must complete this step manually via the AWS CLI using root credentials.

Controls by Category

Data Protection (1 control)

MFA delete on S3 and rotation discipline in Secrets Manager are the two areas assessors focus on here. For Secrets Manager, they want evidence of Lambda-based rotation configured, actual rotation within the past 90 days, adherence to defined schedules, and cleanup of unused secrets. Stale or unrotated secrets come up in nearly every AWS environment assessment.

S3 buckets should have MFA delete enabled

compliance.tf module

Logging (1 control)

CloudTrail trail S3 buckets should require MFA for delete operations to prevent log tampering, and auditors will check this directly. WAF logging is a frequent gap: teams enable WAF rules but skip the logging configuration, so assessors specifically ask to see evidence that both regional and global web ACLs emit logs and that WAFv2 rule groups produce CloudWatch metrics.

WAFv2 rules should have CloudWatch metrics enabled

Monitoring (1 control)

An alarm with no action is effectively silent, and that is exactly what auditors look for here. Each CloudWatch alarm must have at least one configured action (SNS topic, Auto Scaling action, or EC2 action). Alarms stuck in INSUFFICIENT_DATA state or alarms that have never triggered are flagged as configuration failures, not just informational findings.

CloudWatch alarms should have an action configured

compliance.tf module

CIS AWS Benchmark v3.0.0 — 🟡 Medium overlap (45%)

CIS AWS Foundations Benchmark v3.0.0 is the current version and the direct successor. Many v1.2.0 controls were restructured, tightened, or replaced. v3.0.0 adds controls for AWS Organizations, account-level security defaults, and newer services. Migrate to v3.0.0 unless a contractual obligation pins you to v1.2.0.

AWS Foundational Security Best Practices — 🟡 Medium overlap (35%)

AWS Foundational Security Best Practices (FSBP) covers similar ground on IAM, logging, S3, and WAF but is organized around AWS service categories rather than CIS's four-section structure. FSBP includes automated Security Hub checks that partially overlap with many CIS v1.2.0 controls.

NIST 800-53 Rev 5 — ⚪ Low overlap (20%)

NIST 800-53 Rev 5 is far broader in scope, covering organizational, physical, and technical controls. The CIS v1.2.0 controls map loosely to NIST families like AC (Access Control), AU (Audit and Accountability), and SC (System and Communications Protection), but CIS provides only AWS-specific technical checks, not the full policy and procedure requirements NIST demands.

Frequently Asked Questions

CIS v1.2.0 is deprecated. Should I still use it?

Only if an auditor, customer contract, or internal policy explicitly requires v1.2.0. CIS published v3.0.0 in 2024, which reflects current AWS services and security guidance. Running v1.2.0 checks gives you a partial view of your security posture but misses controls for services and features that did not exist in 2018. Plan a migration to v3.0.0.

Why does this benchmark only have 13 controls when the full CIS v1.2.0 document has far more recommendations?

This mapping covers Level 1 controls that can be evaluated through automated Terraform and API-based checks. Many CIS v1.2.0 recommendations (like 'Ensure a support role has been created to manage incidents' or 'Avoid the use of the root account') require procedural or manual verification that falls outside automated policy-as-code scanning. The 13 controls here are the subset amenable to automated compliance checking.

Can I use CIS v1.2.0 results to satisfy an auditor asking for CIS v3.0.0?

No. Control numbering, scope, and requirements differ between versions. An auditor expecting v3.0.0 evidence will reject v1.2.0 scan results. You would need to run the v3.0.0 benchmark separately and address any controls introduced since v1.2.0.

Why does MFA delete appear in two separate controls (CloudTrail bucket and S3 bucket)?

cloudtrail_trail_bucket_mfa_enabled specifically targets the S3 bucket used to store CloudTrail logs, reflecting CIS's emphasis on protecting audit trail integrity. s3_bucket_mfa_delete_enabled applies to S3 buckets more broadly. Both check the same underlying S3 MFA delete setting, but the risk context differs: tampering with audit logs is treated separately from general data deletion, so CIS modeled them as distinct controls.

How long does it take to remediate a typical CIS v1.2.0 assessment?

For 13 controls in a single AWS account, initial remediation typically takes one to three days of engineering effort. MFA delete is the main bottleneck because it requires root account credentials and CLI access. Secrets Manager rotation remediation depends on whether rotation Lambda functions already exist for your secret types. WAF logging can usually be enabled in minutes per ACL.