PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 1 / c1.4
Efficient 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.4 Traffic inspection with AWS Network Firewall at the CDE perimeter

Deploy stateful network security controls with deep packet inspection at the CDE boundaries to filter traffic by application and domain rules, beyond what security groups and NACLs offer.

Quick Wins
Foundational
Efficient
Optimized
Effort: High Impact: Medium 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

Implement AWS Network Firewall in dedicated inspection subnets, with Suricata rules for domain (FQDN) filtering and threat signatures. Turn on Route 53 resolved IP validation so the FQDN allow-list cannot be bypassed: the firewall checks that each outbound connection's destination IP was actually returned by the VPC Resolver, which blocks direct-to-IP connections and spoofed SNI/Host headers and extends domain filtering to protocols such as SSH and SFTP. Scope it with a Route 53 Resolver DNS Firewall rule group associated only with the CDE VPCs. Centralize inspection in an inspection VPC connected via Transit Gateway. Log allowed and blocked traffic to CloudWatch Logs or S3 for evidence.

Practical implementation

How this control is implemented in each reference architecture:

Add stateful, deep-packet inspection at the CDE boundary with AWS Network Firewall, going beyond what security groups and NACLs can express (FQDN and signature rules), and make the FQDN allow-list impossible to bypass with resolved IP validation.

  1. Deploy AWS Network Firewall into dedicated inspection subnets in the VPC and update route tables so the CDE subnets' egress passes through the firewall endpoints.
    Inspection subnets (in VPC) Network Firewall Amazon VPC
  2. Author a policy with FQDN allow-lists for the destinations the CDE legitimately needs, plus Suricata threat signatures and anti-spoofing rules.
    CDE egress path Network Firewall
  3. Turn on Route 53 resolved IP validation on the firewall policy, referencing a DNS Firewall rule group associated only with the CDE VPC, so a connection to an IP the VPC Resolver did not return (direct-to-IP, or a spoofed SNI/Host) fails the allow-list. Start in ALERT mode (it requires firewall logging), review the flagged flows, then switch to DROP or REJECT. Route each CDE subnet to the firewall endpoint in its own Availability Zone, because resolutions are recorded per zone and cross-zone connections fail validation.
    CDE egress path Network Firewall Route 53 DNS Firewall
  4. Send firewall alert and flow logs to CloudWatch Logs or S3 so allowed and blocked traffic is retained as evidence.
    Account logging Network Firewall CloudWatch Amazon S3

How to validate: Route tables show CDE egress traversing the firewall, the firewall logs show traffic to non-allow-listed FQDNs being dropped, and a test connection from the CDE to an unrelated IP while claiming an allowed domain is blocked by resolved IP validation.

Avoid: Deploying the firewall but not changing the route tables, so traffic bypasses it, or relying on an FQDN allow-list alone. Inspection only works if routing forces every flow through the firewall endpoints, and a domain rule only holds if the destination IP is validated against what the VPC Resolver returned.

Single-account, 3-tier →

Run one centrally managed AWS Network Firewall in the network account's inspection VPC so a single, consistent policy protects every CDE account, with resolved IP validation scoped to the CDE VPCs.

  1. Deploy AWS Network Firewall in the inspection VPC of the central network account.
    Network/inspection account Network Firewall
  2. Use Transit Gateway routing to send all CDE east-west and egress traffic through the inspection VPC, so no CDE account needs its own firewall.
    Network/inspection account Transit Gateway
  3. Turn on resolved IP validation on the central policy with a DNS Firewall rule group associated only with the CDE VPCs, and set its source IP ranges to the CDE VPC CIDRs. By default only the firewall VPC's own CIDR is validated, so without this the CDE traffic arriving over Transit Gateway is never checked. Use a Transit Gateway-attached firewall, which carries the client's Availability Zone with the traffic. Keep non-CDE VPCs out of the rule group: every associated VPC contributes to one shared pool of resolved IPs.
    Network/inspection account Network Firewall Route 53 DNS Firewall Transit Gateway
  4. Optionally distribute and enforce the Network Firewall policy across accounts with Firewall Manager, and deliver firewall logs to the central log-archive account.
    Security tooling account → Log archive account Firewall Manager Amazon S3

How to validate: Transit Gateway routes prove all CDE traffic transits the inspection VPC, Firewall Manager reports the Network Firewall policy applied to every CDE account, and the policy's resolved IP validation lists the CDE VPC CIDRs as source ranges with a DNS Firewall rule group associated only with CDE VPCs.

Avoid: Standing up a separate firewall per CDE account, or enabling resolved IP validation centrally without setting the CDE source ranges. The first multiplies cost and policy drift; the second silently validates nothing that arrives from the CDE spokes.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine vendor documentation and NSC configurations to verify that inbound traffic from untrusted networks to trusted networks is restricted (1.4.2).
  • Examine NSC configurations to verify that outbound traffic from the CDE is restricted to only what is necessary (1.3.2.b).
  • Examine the firewall policy to verify that domain-based egress restrictions cannot be bypassed by connecting directly to an IP address or spoofing the SNI/Host (resolved IP validation in DROP or REJECT), and that any bypass destination ranges are documented and justified (1.3.2.b).
  • Examine NSC configurations to verify that anti-spoofing measures detect and block forged source IP addresses (1.4.3).

Evidence in AWS

  • AWS Network Firewall rule groups (policy) showing domain filtering and signatures.
  • Firewall policy resolved IP validation settings: action, DNS Firewall rule group scoped to CDE VPCs, source IP ranges, and documented bypass ranges.
  • Firewall flow logs in CloudWatch/S3 evidencing allowed and denied traffic, including connections that failed resolved IP validation.
  • Inspection-VPC architecture with routes that force traffic through the firewall.

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

AWS Network Firewall Amazon Route 53 Resolver DNS Firewall AWS Transit Gateway Amazon CloudWatch Logs

Learning resources

References

  • AWS Security Maturity Model: Outbound Traffic Control