CNCDP study materials
CNCDP study resources

Segmentation After Acquisition: The 90-Day CDE Enclave

CNCDP · Put your knowledge to work in context.

All case studies

Segmentation After Acquisition: The 90-Day CDE Enclave

RetailCo operates 240 stores and a headquarters data center. The cardholder data environment (CDE) is 14 servers and 2 payment gateways in VLAN 40, but VLAN 40 shares a pair of core switches with all corporate traffic, and the only enforcement point is a perimeter firewall; internal routing between the 10.0.0.0/8 campus, the store VPN concentrator, and the CDE is unrestricted. RetailCo has just acquired a 60-person online billing subsidiary whose entire estate is a flat 172.20.0.0/16 with no internal firewalls; the subsidiary reaches HQ over a site-to-site IPsec tunnel terminated on the core firewall. The board wants full integration within 90 days at minimal capital cost, and the QSA has already flagged “segmentation not demonstrated” in the last assessment. Two of the 14 CDE servers run an application the subsidiary’s billing platform will call directly in phase 2. Change windows are 4 hours, Sunday nights, and no store may be offline during trading hours.

1. Recommend a segmentation design and the order in which you would implement it. Justify the sequence rather than proposing a full network rebuild.

Read the worked answer

Design principle: segmentation is only a control when the enforcement point is independent of the traffic it protects and every alternate path is closed. VLANs on a shared core are not a boundary - any host that can reach the core can route into VLAN 40 today.

Target design: place the CDE behind a dedicated HA firewall pair, or a dedicated VRF on the existing pair if it has throughput headroom, forming a distinct enclave. Permitted flows only: store POS to payment gateway, CDE to named AD/update/file services, and management from a jump host on a management segment. Default-deny and log everything else.

Sequence and why: (1) CDE boundary first - it is the finding the QSA raised and the cheapest scope reduction; (2) a transit/DMZ zone for the subsidiary tunnel so its flat /16 is never routed into the HQ core; (3) campus and store segmentation afterwards. A full rebuild first would consume the 90 days, require capital, and delay the one control that actually shrinks cardholder scope. Enclave-first is reversible, fits the 4-hour Sunday windows, and requires no store downtime.

Subsidiary: treat as untrusted until assessed. Publish only the specific phase-2 service endpoints into a controlled zone rather than extending routing to a flat network whose internal controls you have not verified.

2. The subsidiary tunnel currently lands on the core firewall that protects the CDE. What risk does that create, and what would you change?

Read the worked answer

Risk: terminating an IPsec tunnel from a flat, unmanaged /16 on the firewall that protects the CDE collapses two trust zones into one enforcement point. Consequences:

  • One permissive rule or one policy mistake exposes the CDE.
  • The firewall's rule base, CPU, and failover state are shared, so a tunnel flood or crypto defect affects CDE availability.
  • A compromised subsidiary host inherits whatever the tunnel selectors permit - usually broad, because flat estates are joined with broad selectors.
  • Log attribution blurs, so during an investigation you cannot separate subsidiary traffic from HQ traffic.

Change: terminate the tunnel on a separate edge device or a dedicated transit VRF, not the CDE firewall. Publish only named services (the billing API endpoints) into a DMZ segment, block HQ-to-subsidiary inter-subnet routing, inspect the tunnel with IPS and log per rule, and prohibit mutual route redistribution between subsidiary and campus routes. Apply default-deny egress from the transit zone.

Then prove the negative: document a “no alternate path” check covering the store VPN concentrator, wireless, and out-of-band management networks. Segmentation fails most often through the path nobody drew on the diagram.

3. How would you demonstrate to the QSA, before the next assessment, that the segmentation is real and not just documented?

Read the worked answer

Assurance has to be reproducible, not asserted. Build a test plan and keep the results:

  • Positive test: from a store host, a subsidiary host, and a campus desktop, attempt the CDE ports (443, 1433, 3389). Expect a drop with a logged deny on the enclave firewall - that log entry is the evidence.
  • Alternate-path test: repeat from the wireless VLAN, the management network, and a host on the same core switch as the CDE. This catches the flat Layer-2 path that VLAN-only designs leave open.
  • Failover test: break one node of the HA pair, repeat the probes, confirm policy and session state follow. A segmentation claim that fails on failover is not a control.
  • Rule review: export the rule base showing default-deny plus a finite, owner-assigned allow-list, with a change ticket per rule.
  • Continuous evidence: 30 days of NetFlow from the enclave showing no unexpected talkers, plus an alert on any new flow.

Package it as a scope-and-segmentation document: diagrams, test cases, raw results, and dates. The QSA is assessing whether the boundary is enforced by a device that is not the traffic's own path - the documentation just proves it.