I85PREP
⌘ K
CCNP Data Center study materials
CCNP Data Center study resources

PCI Zone Policy That Only Covers Part of the Zone

CCNP Data Center · Put your knowledge to work in context.

All case studies

PCI Zone Policy That Only Covers Part of the Zone

A PCI zone runs on a vPC pair of Nexus 93180s in a single VRF, using VLAN 210 (10.210.0.0/24) and VLAN 211 (10.211.0.0/24) with HSRP gateways on both SVIs. The only policy is one ACL applied inbound on SVI 210: it permits TCP/443 and TCP/1521 from 10.210.0.0/24 to the payment subnet and denies everything else. A penetration test reached TCP/22 on the payment application from 10.211.0.45 with no filtering at all, and also opened sessions from a compromised host in the payment subnet back into VLAN 210 hosts on high ports. Change records show the ACL has not been edited in nine months, and there is no firewall or service node in the path. Both peers run the same NX-OS release.

1. Both test findings trace to how the policy is attached rather than to what it says. Explain each finding.

Read the worked answer

Finding 1 - 10.211.0.45 unfiltered: the ACL is bound to one interface, not to the zone.

ip access-group on SVI 210 filters traffic entering that SVI. SVI 211 has no ACL binding, so a host in VLAN 211 routing to the payment subnet passes through an interface with no policy. The zone was defined in the requirement as two subnets; the implementation defined it as one interface. Nothing in the ACL is wrong - it never sees the packet.

Finding 2 - the payment host could initiate back into VLAN 210: filtering is unidirectional.

The ACL is inbound only on SVI 210, which covers traffic from the PCI hosts toward the payment tier. Traffic originating in the payment subnet enters via the payment-tier SVI, which has no inbound policy, and is routed into VLAN 210 unexamined. There is no stateful device to correlate the two directions, so the sessions are permitted on the return path as fresh flows.

The tell in both cases is the same: the engineer asked 'is the ACL correct?' and not 'what is the enforcement point?' A per-interface ACL is a per-interface guarantee.

2. Your manager asks whether the fix is to add the permit/deny lines for SSH and to copy the ACL onto SVI 211. Respond.

Read the worked answer

It closes the two reported holes and leaves the zone structurally unfiltered. Say so plainly.

Why the copy-the-ACL fix is insufficient:

  • It keeps policy tied to interfaces. The next subnet added to the zone will be unprotected until someone remembers to bind an ACL, and this zone already has the proof that this is how it fails. You need a design that fails closed.
  • Interface ACLs never see intra-VLAN traffic. Host-to-host traffic within VLAN 210 - a compromised host attacking a neighbouring cardholder host - is switched at Layer 2 and never touches the SVI ACL in either direction. For a PCI zone that is a material gap, not a theoretical one.
  • Two independent ACLs are not a stateful policy. Maintaining mirror-image inbound ACLs on the PCI SVIs and the payment-tier SVIs produces drift and unintended asymmetric rules; a single missing return rule can silently break a payment path during peak.

What to propose instead, in order of durability:

  1. A stateful enforcement point - firewall or service-node insertion (PBR-based redirection) at the zone boundary. Chosen if the PCI scope can bear a change window.
  2. If that is not fundable this quarter: VACLs on every VLAN in the zone to catch intra-VLAN flows, plus inbound ACLs on every SVI in the zone and on the payment-tier SVIs. Both directions explicitly configured, no reliance on return-path openness.
  3. Either way, automate an assertion: every SVI whose subnet is in the zone address list must have the policy attached, checked nightly and failed loudly. That is the control that would have caught finding 1 in month one.

3. You have one maintenance window and no budget for another pen test. How do you prove the zone is actually segmented after the change?

Read the worked answer

Prove it with per-pair bidirectional tests from the existing hosts, not with a config review.

A config review proves the ACL exists; it does not prove the path. Build the test matrix explicitly:

  • Sources: one host in VLAN 210, one in VLAN 211, one in the payment subnet, and - critically - two hosts in the same VLAN as each other.
  • Destinations: the payment application (443, 1521, 22, and a high port), a PCI host from the payment subnet, and a peer PCI host on the same VLAN.
  • Test types: a TCP connect test per open port, and a negative test for the ports that should now be denied. An allow test alone proves nothing about the deny path.

The same-VLAN pair is the one that catches the gap an interface ACL cannot address; run it after the VACL is in place and confirm it is denied.

Record the results with timestamps, source IP, destination IP, port, and result, and treat that table as the evidence artefact. Two further checks worth the time: confirm the counters on the new ACL entries increment during the allowed tests (proves the policy is on the forwarding path and not on a dormant SVI), and confirm on both vPC peers that the bindings exist - a policy present on one peer and missing on the other is the same probability-of-bypass bug that caused the first finding, one layer down.