Microsegmentation Rollout for a PCI-Scoped Claims Application
Regional health insurer runs a claims adjudication application on a 4-node AHV cluster managed by Prism Central. The application has three tiers: 26 web VMs on VLAN 120 (10.20.12.0/24), 12 app VMs on VLAN 130 (10.20.13.0/24), and 8 database VMs on VLAN 140 (10.20.14.0/24), including two read replicas. PCI DSS scope covers the app and database tiers but not the web tier. Two weeks ago the team enabled Flow Network Security in monitor mode and created VM categories AppTier:Web, AppTier:App, and AppTier:DB. The security team wants enforcement before an audit in 10 days. During a pilot enforcement on one app VM, backups from 10.20.99.25 and Nagios monitoring from 10.20.99.30 were blocked, causing alerts. The team needs a controlled enforcement plan that preserves PCI isolation and avoids another outage.
1. Design the Flow Network Security policy model and the enforcement sequence for the PCI-scoped tiers. Explain how you would avoid blocking required infrastructure traffic while keeping a default-deny posture.
Read the worked answer
Use categories to separate PCI scope from non-PCI and infrastructure. Put the 12 app VMs and 8 DB VMs in PCI_Zone (plus AppTier:App/AppTier:DB if you need finer rules); keep the 26 web VMs in Web_Zone; create Infra_Services for the backup and monitoring appliances. Policy intent:
- Allow
Web_Zone->PCI_Zoneonly TCP 443 to app VMs; no web-to-DB. - Allow app -> DB on the database listener (for example TCP 1521/5432) and DB replicas to each other on the replication port.
- Allow
Infra_Services->PCI_Zoneonly on the ports actually observed for backup and monitoring. - Default deny all other ingress/egress for
PCI_Zone; log denies.
Enforcement sequence: keep monitor mode for 7–14 days and export flows; build allow rules from observed flows, not guesswork. Apply the policy to a canary group containing one app VM first, still in monitor, then enforce that canary for 24–48 hours. Use hit counts and deny logs to catch missing flows. Expand to remaining app VMs, then DB VMs, in change windows. Only after a clean 7-day period set default deny for the full PCI_Zone. Rollback is to set the policy back to monitor, not delete it, so you retain evidence.
2. The pilot blocked backups and Nagios. Diagnose the likely missing rules and write the rule changes, including source scope and logging, without opening PCI VMs to the whole 10.20.99.0/24 subnet.
Read the worked answer
First confirm the denied flows in Flow monitor/deny logs: source 10.20.99.25 and 10.20.99.30, destination app VMs, and exact ports. Do not open 10.20.99.0/24. Create a category Infra_Services and add only the two appliances as members, or use IP address groups with /32 entries. Add an allow rule from Infra_Services to PCI_Zone for the minimum ports: for example backup TCP 10000–10010 if that is what the logs show, monitoring TCP 5666 and ICMP echo if Nagios uses them. If backup uses SMB/NFS, allow TCP 445 or 2049 only to the DB/app VMs that host the share, not all PCI VMs. Enable logging on the allow rule and keep default deny logging on.
Put the new rule in monitor first, rerun the backup and a Nagios check, and confirm hit counts increment. Then enforce the canary again. This preserves PCI isolation because the source is restricted to two IPs and the destination/ports are explicit; it also gives the auditor evidence that infrastructure access is exception-based and logged. If the backup appliance stores PCI data, flag it as in-scope or require encryption.
3. What evidence would you present to the auditor, and what residual risk or operational risk remains after enforcement?
Read the worked answer
Evidence: Flow policy export and version history; monitor-to-enforce timeline; allow/deny hit counts; sample deny logs showing no unauthorized egress from PCI_Zone; Prism Central audit logs of policy changes; backup job success and restore test; Nagios alert history; change tickets; and a network diagram showing web outside PCI scope, app/DB inside. Also show that DB replicas communicate only on the replication port.
Residual risk: the web tier is not PCI-scoped, so a compromised web VM can still reach app on 443; that is the intended trust boundary, but it must be hardened and monitored. The backup and monitoring appliances are non-PCI and may store or expose PCI data; require encryption, restricted login, and logging. Operational risk: legitimate emergency traffic may be denied. Define a break-glass process, review denies weekly, and re-certify rules quarterly. If Prism Central is unavailable, existing Flow rules remain enforced, but changes cannot be made; document that and keep a rollback window.