Converting Thirty Days of Flow Monitor Data into an Enforceable Policy Set

Categorise first, then write policy. Policies bind to VM categories, so any VM without a category falls outside every policy and is governed only by the default policy - that is the most common cause of an enforcement change that silently breaks something.

Proposed allow-list:

• Web→App: AppTier:Web → AppTier:App, TCP 443 only.
• App→DB: AppTier:App → AppTier:DB, TCP 5432 only.
• Named infrastructure policies, separately owned: DB→AD 389/636, DB→backup 443, DNS/NTP, and patch egress.

Refused, deliberately:

• workstation→DB 3389. This is the exact flow the auditors are asking about, and it is more likely an operator workaround than a design. Redirect it to a controlled administrative path (jump host, Prism-based console access) and require a documented exception with an expiry if a genuine need exists.
• Any flow whose source is the decommissioned VM. Power it off, remove its category, and let it fall into an isolation/quarantine policy.

Why not bulk-approve the 30 stray flows: each approval is permanent technical debt written into the rule base, and you will never revisit it. Triage each one (owner, business justification, expiry) or it becomes the attacker's map of the environment. The same logic applies to app→internet 443: prefer an internal patch repository or an explicit egress policy over an incidental allow.

Week 1 - data quality. Category every VM, triage the 30 strays with owners, decommission the powered-on VM, and circulate the proposed rule set to the app and DB teams so enforcement is not a surprise during trading hours.

Week 2 - enforce the smallest blast radius first. Start with the DB tier: 4 VMs, two inbound ports, and the fewest dependencies. It is counterintuitive to start where the data is, but the risk of enforcement is proportional to the number of flows you might break, not the importance of the tier. It also delivers the auditor's requirement earliest. Then App, then Web, each after a Monitor pass confirming no legitimate flow is predicted to be blocked.

Week 3 - the default policy, the real decision.

• Default-Allow-All leaves every uncategorised VM fully open; it looks safe because nothing breaks.
• Default-Deny-All is genuine zero trust but will break anything not in a policy: new VMs from templates, DR boot-ups, and forgotten appliances.
• Recommended: run a monitor-only deny period to observe what would break, close the gaps in the infrastructure policies, then switch to default deny with an exception process and a defined owner.

Build the quarantine lever before you need it. Create an isolation policy bound to a category such as Quarantine:Yes that blocks all traffic except management access. During an incident, re-categorising a VM isolates it in seconds with no new policy authoring.

Rollback: every policy can be returned to Monitor individually, so the rollback unit is one policy, not the whole posture. Name who is authorised to flip each one, and watch for asymmetric return traffic plus infrastructure flows from AHV hosts, backup appliances and guest tools that monitor mode may have shown but a naive rule set omits.

Treat it as a risk decision with a clock, not a yes/no.

1. Ask what they actually need: interactive console to four VMs for break-fix, or something a console can't do. Frequently the answer is 'our tooling uses RDP and we never changed it', which is a tooling problem, not a security requirement.
2. Offer the safer equivalent: jump host inside the managed zone with session logging, or Prism-based VM console access which traverses the management plane rather than the data network.
3. If an exception is still needed: narrow it to source hosts (not the whole admin subnet), one port, a ticket reference, a named owner, and an expiry date - 90 days, renewable only with a fresh justification.
4. Record it in the exception register and review it at the next enforcement review.

Reasoning: an unsigned exception quietly becomes permanent policy, and the auditor's question ('show me no east-west RDP to the database tier') is then answered with a list of exceptions, which is a finding rather than a pass. A time-boxed, scoped exception with a compensating control is defensible; an open subnet rule is not.