PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 2 / c2.1
Quick Wins Infrastructure ProtectionSecurity 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.1 Remove default credentials and configurations

Change or remove all vendor-default passwords, accounts, and settings on system components before placing them into production. This is a direct quick win against well-known attack vectors.

Quick Wins
Foundational
Efficient
Optimized
Effort: Low 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

Use hardened base images (golden AMIs) built with EC2 Image Builder that contain no default credentials. Disable unused default accounts. Manage any required secrets in AWS Secrets Manager instead of embedded default values. Prohibit the use of default passwords through configuration controls.

Practical implementation

How this control is implemented in each reference architecture:

Start every CDE instance from a hardened image that carries no vendor-default accounts, passwords, or settings, and keep any required secrets out of the image.

  1. Build the app- and data-tier AMIs with an EC2 Image Builder hardening pipeline that removes or disables vendor-default OS accounts and applies your configuration standard.
    Account baseline (golden AMIs) EC2 Image Builder
  2. Store any bootstrap secrets the instance needs in Secrets Manager and inject them at launch, instead of baking default values into the image or user data.
    App tier (CDE) / Data tier (CDE) Secrets Manager
  3. Confirm unused default accounts are disabled before the instance joins the CDE subnets.
    App tier (CDE) / Data tier (CDE) Amazon EC2 Systems Manager

How to validate: The Image Builder recipe shows the hardening/account-removal components, and an inventory of the running instances shows no active vendor-default accounts.

Avoid: Hardening instances by hand after launch. Manual steps drift and get skipped; bake the no-default baseline into the image so every instance starts compliant.

Single-account, 3-tier →

Produce one golden-AMI baseline centrally and distribute it to every CDE account, so no account can start from an unhardened or default-laden image.

  1. Run the golden-AMI hardening pipeline in the shared services account so there is a single, reviewed source of hardened images.
    Shared services account EC2 Image Builder
  2. Share the approved AMIs to the CDE accounts with AWS RAM so every PCI OU account starts from the same no-default baseline.
    Shared services account → PCI OU AWS RAM AWS Organizations
  3. Add an SCP on the PCI OU that denies launching instances from images outside the approved shared catalog.
    PCI OU (guardrail) AWS Organizations

How to validate: RAM shows the hardened AMIs shared to the PCI OU, and an attempt to launch an unapproved public AMI in a CDE account is denied by SCP.

Avoid: Letting each team build its own base image. Divergent images reintroduce defaults; centralize the pipeline and share one catalog.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineinterviewobserve

Testing procedures

  • Examine system configuration standards to verify they include managing vendor-default accounts, and examine vendor documentation and observe an admin logging on with vendor-default accounts (2.2.2.a, 2.2.2.b).
  • Examine configuration files and interview personnel to verify that all unused vendor-default accounts are removed or disabled (2.2.2.c).

Evidence in AWS

  • EC2 Image Builder recipes and hardening components with no default credentials.
  • System account inventory showing default accounts disabled or removed.
  • Documented configuration standards applied to the base AMIs.

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

EC2 Image Builder AWS Secrets Manager AWS Systems Manager AWS Config

Learning resources

References

  • AWS Security Maturity Model: Standard hardened images