PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom

Foundational Security GovernanceSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c2.2 Define and enforce secure configuration standards (hardening)

Establish secure configuration standards for all system components, aligned with recognized industry hardening standards (e.g. CIS Benchmarks), and apply them consistently.

Quick Wins
Foundational
Efficient
Optimized
Effort: Medium Impact: High Applies to CDE: Yes

Requirement 2

Apply Secure Configurations to All System Components

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

2.2 System components are configured and managed securely
  • 2.2.1 Configuration standards developed, implemented, and maintained Covered
  • 2.2.2 Vendor default accounts managed (removed/disabled or secured) Covered
  • 2.2.3 Primary functions with different security levels isolated Covered
  • 2.2.4 Only necessary services, protocols, daemons, and functions enabled Covered
  • 2.2.5 Insecure services/protocols: business justification and mitigations Covered
  • 2.2.6 System security parameters configured to prevent misuse Covered
  • 2.2.7 All non-console administrative access is encrypted Covered

How to implement on AWS

Adopt CIS Benchmarks and enforce them with AWS Systems Manager (State Manager and Compliance). Distribute secure configurations via golden AMIs and SSM documents. Define a single primary function per server where applicable and disable insecure services/protocols. Verify compliance with AWS Config and Security Hub (CIS AWS Foundations Benchmark standard).

Practical implementation

How this control is implemented in each reference architecture:

Adopt a recognized hardening standard (e.g. CIS Benchmark), apply it continuously to your instances, and watch for drift, all within the one account.

  1. Apply a CIS Benchmark to the app- and data-tier EC2 instances with SSM State Manager so the configuration is enforced on a schedule, not just at launch.
    App tier (CDE) / Data tier (CDE) Systems Manager Amazon EC2
  2. Enable the CIS AWS Foundations Benchmark standard in Security Hub for the account to score account-level hardening.
    Account-wide Security Hub
  3. Track configuration drift with AWS Config and record the standard in your documented configuration baseline.
    Account-wide detection AWS Config

How to validate: SSM State Manager / Config report the instances compliant with the CIS baseline, and the Security Hub CIS standard shows passing controls.

Avoid: Applying the benchmark once at build time and never re-checking. Configuration drifts; enforce on a schedule with State Manager and monitor with Config.

Single-account, 3-tier →

Define the hardening standard once and hold every CDE account to it from the security tooling account, so the whole PCI OU meets the same benchmark.

  1. Enable the CIS Security Hub standard org-wide from the security tooling account as delegated administrator.
    Security tooling account → PCI OU Security Hub AWS Organizations
  2. Distribute the hardening baseline (SSM State Manager associations / documents) to all CDE accounts so instances self-apply the standard.
    PCI OU (all CDE accounts) Systems Manager
  3. Enforce and monitor with an AWS Config conformance pack across the PCI OU so every account is scored against the same rules.
    PCI OU (all CDE accounts) AWS Config

How to validate: The conformance pack and Security Hub CIS standard show passing results across all PCI OU accounts from the delegated-admin view.

Avoid: Each account enabling its own, slightly different standard. Centralize the standard and conformance pack so the baseline is identical and comparable across accounts.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine system configuration standards to verify they define processes covering all elements of the requirement and are updated as new vulnerabilities are identified (2.2.1.a, 2.2.1.b).
  • Examine configuration settings and interview personnel to verify the standards are applied when new system components are configured and before or immediately after connection to production (2.2.1.c).
  • Examine system configurations to verify that only required functionality is enabled and unnecessary functionality is removed or disabled (2.2.4.b).

Evidence in AWS

  • Documented configuration standards referencing CIS Benchmarks.
  • SSM State Manager / AWS Config compliance report for in-scope components.
  • CIS AWS Foundations Benchmark standard enabled in Security Hub.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 2.2 — All system components are configured securely and consistently and in accordance with industry-accepted hardening standards or vendor recommendations.

AWS services

AWS Systems Manager AWS Config AWS Security Hub EC2 Image Builder

Learning resources

References

  • AWS Security Maturity Model: Configuration management
  • CIS AWS Foundations Benchmark