Flow Segmentation for a Three-Tier Portal with No CMDB

Scope with categories, not names. Create categories such as AppTier:Web|App|DB|Reporting and Env:Prod in Prism Central and assign them to VMs. Names are unreliable here; categories make the policy survive rebuilds and clones, and they are the unit Flow policies target.

Sequence:

1. Inventory by traffic, not by spreadsheet. Enable Flow visibility / monitor mode for the VMs and collect flows for at least one full business cycle - including month-end and the nightly batch that broke things last time. Hit counters and flow logs will expose the reporting VM's 5432 connection before enforcement does it for you.
2. Write application policies as an allow-list: App → DB on 5432, LB subnet → Web on 443, Jump host → DB on 22. Anything not listed is denied for VMs in the secured categories, so every dependency must be found in step 1.
3. Add an isolation policy for the DB category. Isolation takes precedence over application policies, so it wins on conflicts - useful for pinning the database to only its intended partners.
4. Enforce tier by tier, DB last, in a change window, with the reporting VM either recategorised and given an explicit rule or moved off VLAN 30.

Keep a quarantine isolation policy ready to cut a VM off instantly during an incident.

Not true, and saying so is how projects get rolled back. Flow Network Security enforces at the guest vNIC of VMs on clusters registered to Prism Central. It complements the physical network; it does not replace perimeter firewalling or routing.

Outside Flow's enforcement point:

• Bare-metal servers, SAN-attached appliances, and physical load balancers - including a hardware DB replica or an F5 VIP that never touches a managed vNIC.
• VMs on hypervisors or clusters not registered to this Prism Central, or clusters where Flow is not enabled; also any workload in the other two clusters this PC manages if you scope the rollout to one cluster.
• North-south and internet-edge traffic: Flow can restrict it at the vNIC, but it is not a NAT/edge device and should not become the internet firewall.
• Traffic that never leaves the guest (intra-VM, loopback) and encrypted payload inspection - Flow is L3/L4 allow-listing, not deep packet inspection.

Practical split: keep the core switch ACLs as a coarse perimeter and for the physical estate, use Flow for east-west VM-to-VM control where the network team cannot move quickly, and document that a VM live-migrated to an unregistered cluster falls outside the policy - that is the gap an auditor will find.

Apply a quarantine isolation policy. Quarantine is a special isolation policy that blocks all traffic to and from VMs in the quarantined category except explicitly permitted flows (typically management/jump-host access and the Flow/PC control path). Because isolation policies take precedence over application policies, the DB stops talking to the app tier and to the reporting VM immediately, while the VM stays powered on for forensic capture.

Preconditions that decide whether this works at 02:00:

• A Quarantine category exists and the DB VM can be added to it from Prism Central in seconds - this must be designed and rehearsed before the incident, not invented during one.
• The management path (jump host on VLAN 10) is included as an allowed flow, or responders cannot reach the VM to collect evidence.
• Someone on the on-call rota has Prism Central rights to change category membership and policy; a read-only account turns this into a 30-minute escalation.
• Snapshot the VM before any remediation so the evidence is preserved, and note that quarantine does not stop a compromised guest from attacking anything reachable through an allowed flow.

After containment, review Flow traffic logs for lateral movement to the app tier, then rebuild rather than trust an in-place clean-up.