PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom

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.

c1.1 Close risky open ports in security groups

Identify and remove security group rules that expose administrative or sensitive ports (e.g. SSH 22, RDP 3389, databases) to 0.0.0.0/0. This is the highest-impact, lowest-effort control to reduce the CDE attack surface.

Quick Wins
Foundational
Efficient
Optimized
Effort: Low 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.2 NSCs are configured and maintained
  • 1.2.1 NSC config standards defined and applied Covered
  • 1.2.2 Changes to network connections and NSCs are approved and managed Your responsibility
  • 1.2.3 Accurate network diagram(s) maintained Your responsibility
  • 1.2.4 Accurate data-flow diagram(s) maintained Your responsibility
  • 1.2.5 All services, protocols, and ports allowed are identified and justified Covered
  • 1.2.6 Security features for insecure services/protocols are defined Covered
  • 1.2.7 NSC configurations reviewed at least every 6 months Your responsibility
  • 1.2.8 NSC configuration files are secured and consistent with active settings Covered
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

Use AWS Config with the managed rules restricted-ssh and restricted-common-ports to detect exposures. Review Security Hub findings (controls EC2.13/EC2.14). Replace 0.0.0.0/0 rules with specific CIDR ranges or references to other security groups. For administrative access, prefer AWS Systems Manager Session Manager instead of opening inbound ports.

Practical implementation

How this control is implemented in each reference architecture:

Lock down the security groups in your single VPC so no administrative or database port is reachable from the internet, and remove the need for inbound admin ports entirely.

  1. Inventory every security group and flag inbound rules that allow 0.0.0.0/0 (or ::/0) on SSH (22), RDP (3389), or database ports (e.g. 3306, 5432, 1433).
    All tiers Amazon VPC AWS Config
  2. For the public entry point, keep only the ports the ALB needs (443, and 80 to redirect) open from the internet; terminate TLS at the ALB with an ACM certificate.
    Public subnet Elastic Load Balancing Certificate Manager AWS WAF
  3. Replace inter-tier 0.0.0.0/0 rules with source-security-group references: the app-tier SG allows only the ALB SG on the app port; the data-tier SG allows only the app-tier SG on the database port.
    App tier (CDE) → Data tier (CDE) Amazon VPC Amazon EC2 Amazon RDS
  4. Remove all inbound SSH/RDP rules and use Systems Manager Session Manager for administrative access, so no admin port is exposed at all.
    App tier (CDE) Systems Manager

How to validate: AWS Config rules restricted-ssh and restricted-common-ports report COMPLIANT, and Security Hub controls EC2.13/EC2.14 show no failed findings.

Avoid: Leaving a 'temporary' 0.0.0.0/0 SSH rule for troubleshooting. Use Session Manager instead; temporary open ports are the most common CDE exposure.

Single-account, 3-tier →

Enforce the control across every CDE account under the PCI OU with a preventive-first stack: Firewall Manager to apply and remediate security-group policies org-wide, an SCP to block the misconfiguration at authorization time, and Config/Security Hub for centralized detection.

  1. Use AWS Firewall Manager (from the security tooling account as delegated admin) to apply a security-group content/audit policy across the PCI OU that automatically flags and remediates rules allowing 0.0.0.0/0 on administrative or database ports.
    Security tooling account → PCI OU Firewall Manager AWS Organizations
  2. Attach an SCP to the PCI OU that denies authorizing 0.0.0.0/0 ingress on administrative ports, preventing the misconfiguration regardless of local IAM permissions.
    PCI OU (guardrail) AWS Organizations
  3. Deploy the AWS Config managed rules (restricted-ssh, restricted-common-ports) org-wide via a conformance pack and aggregate findings in the delegated-administrator Security Hub, so residual exposures surface in one place.
    Security tooling account AWS Config Security Hub
  4. Standardize administrative access through Session Manager, with inter-VPC routing and egress inspection handled by the central network account.
    Network/inspection account Systems Manager Transit Gateway Network Firewall

How to validate: Firewall Manager reports the security-group policy compliant (no non-compliant resources) across the PCI OU, the SCP denies a test attempt to open 0.0.0.0/0 on port 22, and restricted-ssh / restricted-common-ports are COMPLIANT in Config.

Avoid: Relying only on detective Config rules. Detection alone lets the exposure exist until someone reacts; Firewall Manager remediates automatically and the SCP stops it at authorization time.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine NSC configuration standards and settings to verify that only approved services, protocols, and ports are in use, each with business justification (1.2.5.a, 1.2.5.b).
  • Examine NSC configurations to verify that inbound traffic to the CDE is restricted to only what is necessary and all other traffic is denied (1.3.1.b).
  • Examine NSC configurations to verify that connections between trusted and untrusted networks are restricted (1.4.1.b).

Evidence in AWS

  • AWS Config compliance report for the restricted-ssh and restricted-common-ports rules (all resources COMPLIANT).
  • Resolved Security Hub findings EC2.13 and EC2.14.
  • Export of security group rules showing no 0.0.0.0/0 on administrative ports.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 1.2 — The way that NSCs are configured and operate is defined and consistently applied.
  • 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 Security Groups AWS Config AWS Security Hub AWS Systems Manager

Learning resources

References

  • AWS Security Hub: EC2.13, EC2.14
  • AWS Security Maturity Model: Cleanup risky open ports