PCI Segmentation on a Flat /16
Northwind Retail runs a flat 10.10.0.0/16 network across one headquarters and two stores. Its 24 payment terminals sit in VLAN 50 (10.10.50.0/24) and must reach an on-premises update server at 10.10.10.20, a payment processor at 198.51.100.0/28 over an IPsec tunnel, and DNS/NTP. The current core firewall permits all RFC1918 traffic between internal VLANs. A contractor proposes two rules: permit 10.10.0.0/16 to 10.10.50.0/24 on any protocol, and permit 10.10.50.0/24 to any IP on any port. The QSA will assess PCI DSS segmentation in three weeks. Store managers also use the same VLAN for a shared laptop that browses the internet and maps a drive to finance. The CIO wants no disruption to nightly terminal updates at 01:00.
1. Evaluate the contractor's two rules. Identify the two most serious risks and explain how each undermines PCI segmentation.
Read the worked answer
The first rule creates a wide east-west path from every internal host, including the shared browsing laptop and potentially compromised office PCs, to the cardholder data environment. PCI DSS segmentation depends on the PoS VLAN being isolated so that a compromise elsewhere cannot reach terminals; permitting all RFC1918 to VLAN 50 makes the segment only a routing boundary, not a security boundary. The second rule gives terminals direct internet access on any port. That violates least privilege, exposes the terminals to drive-by exploitation and command-and-control, and bypasses the processor path that should be restricted to the processor's /28 over IPsec. It also makes egress filtering and logging far harder.
Both rules are any-port and any-protocol, so they leave no useful control over SMB, RDP, or DNS tunneling. The shared laptop is especially damaging: it combines user browsing, a finance drive mapping, and adjacency to PoS, which is exactly the bridge segmentation is meant to remove. The correct conclusion is not to accept either rule with a caveat; reject them and replace them with explicit flows.
2. Design a minimal stateful rule set for VLAN 50. Specify source, destination, port, and direction for each permitted flow.
Read the worked answer
Default deny both directions on the VLAN 50 interface. Permit:
- 10.10.50.0/24 to 10.10.10.20 TCP 8530/8531, or 443 if the update product uses it, for updates; permit return traffic statefully. If updates are pull, this is the only direction needed. If the server pushes, add 10.10.10.20 to 10.10.50.0/24 TCP 8530/8531, not any.
- 10.10.50.0/24 to 198.51.100.0/28 TCP 443 only, over the IPsec tunnel; no other internet destinations.
- 10.10.50.0/24 to named internal DNS servers UDP/TCP 53 and NTP UDP 123.
- Management jump host 10.10.99.10 to 10.10.50.0/24 TCP 3389 only if vendor support requires RDP, with logging and MFA; prefer a remote-support appliance.
Deny all else, including VLAN 50 to VLAN 50 if terminals do not need peer-to-peer, and log denies. Remove the shared laptop from VLAN 50; put it in an office VLAN with no route to PoS. Apply ACLs on both core and store firewalls if traffic crosses them, and test with a terminal that has no cached sessions.
3. The post-change scan shows a PoS terminal can reach 10.10.10.20 on TCP 445 and 3389. The firewall rules look correct. Give three plausible causes and the first verification step for each.
Read the worked answer
- A rule is stateful or a second management rule permits 445/3389. The update-server rule may have been written as a bidirectional 'permit 10.10.10.20 to 10.10.50.0/24 any' plus a broader rule. First check: export the effective rule list in order and match the five-tuple for 10.10.50.x to 10.10.10.20:445, including NAT and any established-traffic rule.
- The ACL is applied to the wrong interface or direction, or not applied to the intra-VLAN path. First check: interface/VLAN binding and counters; test from the PoS default gateway and from another VLAN to see whether the path is routed or switched.
- A host firewall or endpoint agent blocks the scan, so the reachable result is a false positive from a proxy or management tool. First check: packet capture on both endpoints and the firewall, and verify the scanner's source IP.
Also check for a shadow rule from the contractor's earlier change that was not removed, and for asymmetric routing that bypasses the firewall. Fix by an explicit deny 445/3389 from VLAN 50 to the server VLAN, log, and retest.