PCI audit finding: flat branch VLAN and guest breakout
Community Health runs 45 clinics on a hub-and-spoke IPsec VPN to a pair of SRX4600 firewalls in its primary data center. Each clinic has one SRX345 that terminates the tunnel and carries POS, clinical workstation, guest Wi-Fi, and IP cameras on a single /24 VLAN. A PCI assessor found that guest devices can reach the POS subnet and that the clinic firewall passes all inter-VLAN traffic to the hub for inspection. Microsoft Teams traffic from clinics is also backhauled, adding 60–80 ms round trip and causing call complaints. The clinic uplink is 200/50 Mbps cable with a 1 Gbps LAN. The security team wants local internet breakout for SaaS, IDP inspection for inbound and outbound traffic, and PCI segmentation, but the SRX345 CPU is already at 70% during clinic hours. Central logging uses syslog over the tunnel.
1. Design the segmentation and security enforcement points for a clinic. State which zones/VLANs you create, where policy is enforced, and how traffic flows for POS, guest, cameras, and Teams.
Read the worked answer
Create separate VLANs and SRX zones: POS (PCI CDE), clinical workstations, guest Wi-Fi, cameras/NVR, and management. The SRX345 becomes the branch enforcement point for zone-to-zone policy; the hub SRX4600 remains the enforcement point for data-center-bound and inter-clinic traffic.
Traffic flows:
- Guest terminates on the branch SRX in an untrusted guest zone. Its only policy is to the local internet breakout; deny RFC1918 and deny any route to POS or clinical. No inter-VLAN routing on the switch.
- POS has a permit only to the specific payment application IPs and ports in the data center over the IPsec tunnel, with logging. No internet path. The CDE is the POS VLAN plus the payment segment in the data center, so guest and cameras must not share an L2 domain with it.
- Cameras stay local to the NVR; if remote viewing is required, permit only the NVR to a cloud service, not camera-to-camera or camera-to-POS.
- Teams uses local internet breakout from the branch SRX with application-based policy and NAT, avoiding the hub hairpin. Keep clinical and POS on the tunnel.
Enforce default-deny between zones on the SRX, not on the access switch. This keeps policy in one place and gives stateful inspection and logging. For PCI, document that guest has no route to the CDE and that the branch firewall controls all CDE ingress and egress.
2. The SRX345 is at 70% CPU. Evaluate options: add IDP at the branch, inspect at the hub, or use a cloud security service. Recommend one and justify with performance and PCI-scope reasoning.
Read the worked answer
Start by measuring what the 70% represents: throughput, session count, or inspection. IDP is CPU-intensive and the SRX345’s IDP throughput is far below its firewall throughput, so enabling full IDP on all branch traffic risks saturation and latency for POS.
Option A, full IDP at every branch, gives local enforcement but is the worst fit for the current CPU headroom and adds cost at 45 sites.
Option B, inspect everything at the hub, preserves SRX4600 capacity but reintroduces latency for Teams and internet traffic, and expands the hub inspection domain to all clinic traffic. It also wastes WAN bandwidth.
Option C, cloud-delivered security for internet-bound traffic, is best for guest and Teams: the branch SRX only routes and NATs, while the cloud service performs web filtering and IPS. Keep POS and clinical traffic on the hub, but apply targeted IDP only to POS-to-payment flows where the SRX4600 has capacity. This limits PCI inspection to the CDE and avoids inspecting guest traffic in the PCI scope.
Recommended design: branch SRX does segmentation, IPsec, and NAT; internet breakout goes to the cloud security service; hub SRX4600 runs targeted IPS/IDP for POS and clinical flows. Re-baseline CPU after moving guest and Teams off the tunnel. If local IDP is mandated for inbound traffic, add a dedicated security device or upgrade the branch platform rather than enabling every signature on a busy SRX345.