A VPC Peering That Quietly Reconnects the CDE to Corporate
Vantage Grocers operates 600 stores and an e-commerce platform. The CDE sits in AWS account A: a production VPC at 10.20.0.0/16 containing an Aurora cluster with PAN, 40 EC2 application servers and an ELB. The corporate VPC at 10.10.0.0/16 in the same region holds Active Directory domain controllers used to authenticate CDE administrators, Splunk forwarders that receive CDE logs, and a shared jump host used by infrastructure staff. Eight months ago the network team opened a VPC peering connection “to simplify AD integration”, and the CDE-side security groups now allow 10.10.0.0/16 on all ports. No NACLs are used. Last month's penetration test compromised a developer workstation in the corporate VPC and from it reached the Aurora writer on port 3306, querying a table containing PAN. The security manager argues the CDE is segmented because “it is a separate VPC”, and points out that no store network ranges appear in the CDE route table.
1. Is segmentation effective here? What does PCI DSS require, and what does the penetration test result mean for scope?
Read the worked answer
Segmentation is not effective. PCI DSS does not award credit for network constructs; it asks whether network security controls restrict traffic between the CDE and out-of-scope networks (1.2, 1.3, 1.4), whether rulesets are reviewed at least every six months (1.4.5), and whether the controls are tested (11.4.5, at least annually; every six months where a service provider relies on segmentation).
On the facts, three things fail at once. A peering plus an allow-all-from-10.10.0.0/16 rule is not a restriction. The penetration test demonstrated a working path from a developer workstation to a PAN table, which is direct evidence the control does not operate. And the rule survived eight months, so the six-month review either did not happen or did not act.
The scope consequence is the important judgement: once a path exists, the corporate VPC and everything routable from it must be treated as connected to the CDE unless segmentation is rebuilt and re-tested. That pulls in AD, the jump host, the Splunk infrastructure and any corporate endpoint that can reach those systems. If the corporate VPC routes to store networks or VPN clients, scope can grow to most of the estate. The assessor should record the finding, expand scope in the interim, and require a re-test before accepting a narrower boundary.
2. The business still needs AD authentication and centralised logging. Design controls that restore segmentation without breaking those services.
Read the worked answer
Shared services can be retained if the traffic is one-way, purpose-specific, documented and tested.
- Directory: deploy read-only domain controllers or a dedicated AD site inside the CDE account, or permit only CDE subnets to reach named DC IPs on the specific ports required (88, 389/636, 3268). Replace the /16 rule with host-level rules; no rule should ever reference the whole corporate range.
- Logging: forwarders initiate outbound connections to the SIEM on a single TLS port; there should be no inbound rule from the SIEM network into the CDE. If the SIEM needs to pull, use an agent-initiated model instead.
- Administration: retire the shared jump host. Use brokered, session-logged administrative access with MFA (8.4.2, 8.4.3), restricted to named administrators, with session recordings shipped to the CDE log pipeline (10.2).
- Enforcement layers: separate accounts with service control policies that block peering creation, security groups referencing prefix lists rather than CIDRs, NACLs as a secondary control, and AWS Network Firewall or Transit Gateway route-table separation so the route itself does not exist.
- Governance: maintain a traffic matrix, review rulesets every six months with evidence, and make any new connectivity a change that triggers a scope review.
Finish with a segmentation penetration test (11.4.5) that explicitly attempts corporate-to-CDE traversal, and keep the expanded scope until it passes.