Microsegmentation: Map, Then Deny

What segmentation is for, said plainly

Everything so far gates the front doors. Segmentation exists for the day a door fails anyway — tenet 5’s assume-breach, applied to the network: when workload A is compromised, what can it reach? In a flat network the answer is “everything, on every port,” and that answer is how one phished workstation becomes a domain-wide incident. Microsegmentation makes the answer “exactly what its function requires, and the SOC hears about attempts at anything else.”

The federal how-to guidance for this is CISA’s Microsegmentation in Zero Trust, Part One: Introduction and Planning (version 1.0, 29 July 2025) — planning guidance any organization may apply, not a mandate. It sets out four phases: identify candidate resources; identify their dependencies; determine appropriate segmentation policies; deploy them. This lesson compresses those into the two moves they amount to, because the order is what people get wrong:

STEP ONE: MAP    - CISA phases 1-2: identify the candidate resource and
                   everything it depends on. House practice adds a flow
                   baseline over weeks - CISA sets no duration - because
                   segmentation is dynamic POLICY about real traffic, not
                   an architecture diagram from 2019.
STEP TWO: DENY   - CISA phases 3-4: determine the policies, then deploy
                   them. Default-deny east-west, explicit allows derived
                   from the observed baseline, enforced tier by tier.

Skipping step one is Lesson 1.3’s killer #1 with a blast radius: the undocumented flow you deny is always something like the storm-day dispatch failover path, discovered at the worst possible time, and the emergency rollback (“just allow any-any until we sort it out”) quietly repeals the program.

Prompt first: the two-step, executed

STEP ONE - build the flow baseline for the dispatch protect surface:
Ingest 3 weeks of flow logs for these subnets/workloads. Output: (1) the
observed flow matrix - source, destination, port/protocol, frequency; (2)
each flow classified: EXPECTED (matches documented function) / EXPLAINABLE
(makes sense, undocumented - draft the doc) / UNKNOWN (investigate before
any enforcement); (3) the proposed segment boundaries - one security group
per application tier, not per subnet.

STEP TWO - only after UNKNOWNs are dispositioned:
Generate the default-deny ruleset: explicit allows from the classified
matrix (app-tier => db-tier:1433, nothing else reaches db-tier), deny-all
with LOGGING as the final rule, rollout order least-critical-tier-first,
and the rollback per tier. Flag every rule that grants a broad range or
any-port - each needs a justification or a narrower rewrite.

Design points the ruleset should embody:

• Boundaries follow application tiers, not network geography. “The web tier may reach the app tier on 443” survives re-IPs and migrations; “10.20.4.0/24 may reach 10.20.5.0/24” is archaeology waiting to mislead. Use grouping constructs (application security groups, tags, labels) so rules reference roles.
• Where the platform supports it, rules reference identity. Cloud-native segmentation can allow by workload identity — the Module 2 investment paying network dividends. Kubernetes network policies scope by label + namespace (Meridian’s fenced Oracle cluster gets default-deny with exactly one ingress: the API’s identity, on 1521 — closing the gap its own manifest review flagged last year).
• The deny rule logs. Denied east-west attempts are premium detection signal — a workstation probing the historian is an incident announcing itself (Lesson 5.1 consumes this feed).
• Legacy datacenter honesty. Full default-deny inside an aging on-prem estate is the most-deferred milestone in real programs — agent-based microsegmentation or enclave-level boundaries may be the achievable increment. Score it honestly on the ZTMM rather than claiming the optimal stage from a slide.

The gotcha paragraph (read twice)

Cloud platforms hide a segmentation trap that has burned enough teams to earn its own heading. Private endpoints — the PaaS-into-your-VNet pattern — bypass network security groups by default. The platform’s PE traffic doesn’t consult NSG rules until you explicitly enable private-endpoint network policies on the subnet. The failure looks like this: team builds default-deny, pentests the VMs, declares victory — while every private endpoint in the subnet (the SQL server, the storage account, the key vault) accepts connections from anywhere in the VNet, invisible to the ruleset. One subnet property flips it. Check it first, because it falsifies the mental model everything else is built on. (Generalize: every platform has one of these — the setting that makes your enforcement actually apply. Find it before the pentest does.)

Key takeaway

Map, then deny: weeks of observed flows classified into expected/explainable/unknown, unknowns dispositioned like the leads they are, then default-deny built from evidence — boundaries on application tiers, rules referencing identity where possible, denials logged as detection signal, and the private-endpoint policy flag checked before anything else is believed. One estate remains where none of this applies as written: the one that runs the pumps.