PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 1 / c1.2
Foundational 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.

c1.2 Limit network access to and from the CDE

Explicitly restrict inbound and outbound traffic of the cardholder data environment to the minimum required for business functions, applying a default-deny principle.

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

Requirement 1

Install and Maintain Network Security Controls

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.

1.3 Network access to and from the CDE is restricted
  • 1.3.1 Inbound traffic to the CDE is restricted to what is necessary Covered
  • 1.3.2 Outbound traffic from the CDE is restricted to what is necessary Covered
  • 1.3.3 NSCs installed between all wireless networks and the CDE Covered
1.4 Network connections between trusted and untrusted networks are controlled
  • 1.4.1 NSCs between trusted and untrusted networks Covered
  • 1.4.2 Inbound traffic from untrusted networks to trusted is restricted Covered
  • 1.4.3 Anti-spoofing measures detect and block forged source IPs Covered
  • 1.4.4 System components storing CHD not directly reachable from untrusted networks Covered
  • 1.4.5 Disclosure of internal IP/routing information is limited Covered

How to implement on AWS

Design dedicated subnets for the CDE with restrictive Network ACLs in addition to security groups. Document and justify every allowed rule. Use security groups with cross-group references instead of broad IP ranges. Restrict CDE outbound traffic to approved destinations.

Practical implementation

How this control is implemented in each reference architecture:

Wrap the CDE tiers in a default-deny posture: security groups for allow-listing, NACLs as a subnet-level backstop, and private egress to AWS services only.

  1. Place the data tier in its own private subnets and attach a Network ACL that allows only the database port from the app subnets and denies everything else (default-deny at the subnet boundary).
    Data tier (CDE) Amazon VPC
  2. Keep an authorized-flow matrix (source, destination, port, business justification) that exactly matches your security-group and NACL rules; treat it as the evidence artifact for 1.3/1.4.
    All CDE tiers Amazon VPC
  3. Restrict the CDE's outbound traffic to the specific AWS services it needs (e.g. Secrets Manager, KMS) using VPC endpoints, so that traffic never traverses the public internet.
    App tier (CDE) / Data tier (CDE) Amazon VPC Secrets Manager AWS KMS

How to validate: The NACL and security-group exports match the authorized-flow matrix line-for-line, and a connectivity test from the data tier to any non-approved destination is denied.

Avoid: Using wide CIDR ranges (e.g. 10.0.0.0/8) in rules 'to keep it simple'. Reference source security groups instead, so the allow-list stays tight as the network grows.

Single-account, 3-tier →

Force all CDE traffic through the central ingress/inspection path, reinforce default-deny with SCPs, and keep AWS-service traffic private via shared VPC endpoints.

  1. Route inbound to CDE workload accounts only through the central network account's ingress path; block direct internet ingress at the account VPCs.
    Network/inspection account → PCI OU Transit Gateway Amazon VPC
  2. Force east-west and egress traffic from every CDE account through the central inspection VPC so one policy governs all of them.
    Network/inspection account Transit Gateway Network Firewall
  3. Reinforce default-deny with SCPs on the PCI OU (e.g. deny creating internet gateways or public-facing resources in CDE accounts).
    PCI OU (guardrail) AWS Organizations
  4. Provide centralized VPC endpoints (in the shared network account) so CDE-to-AWS-service traffic stays off the public internet across all accounts.
    Network/inspection account Amazon VPC

How to validate: Transit Gateway route tables show CDE accounts can only reach the inspection path, and an attempt to attach an internet gateway in a CDE account is denied by SCP.

Avoid: Peering CDE accounts directly to each other for convenience. Keep all paths through the inspection VPC so segmentation and logging stay centralized and provable.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine NSC configuration standards and settings to verify that inbound traffic to the CDE is restricted to only what is necessary, with all other traffic specifically denied (1.3.1.a, 1.3.1.b).
  • Examine NSC configurations to verify that outbound traffic from the CDE is restricted to only what is necessary (1.3.2.a, 1.3.2.b).
  • Examine configuration standards and network diagrams to verify that NSCs are in place between trusted and untrusted networks (1.4.1.a, 1.4.1.b).

Evidence in AWS

  • Network diagram and authorized-flow matrix that matches the implemented security group and NACL rules.
  • Export of the CDE subnet Network ACLs showing default-deny rules.
  • Business-justification records for each allowed rule.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 1.3 — Unauthorized traffic cannot enter the CDE.
  • 1.4 — Unauthorized traffic cannot traverse network boundaries between trusted and untrusted networks.

AWS services

Amazon VPC Network ACLs Security Groups

Learning resources

References

  • AWS Security Maturity Model: Limit Network Access