Labels before rules: why microsegmentation projects stall
In plain words: Before you can build walls between rooms, you have to know what each room is for, so name things first and the rules get simple. Network and segmentation, explained simply
In short
- Microsegmentation limits how far an intruder can move once inside. Most projects agree on that and then stall.
- They stall at the same point: the team starts writing rules before it can say what each workload is, who owns it and what it talks to.
- Labels come first. A few plain labels per workload, such as application, environment and role, turn thousands of address-based rules into a handful of readable ones.
Why segmentation matters
Most serious intrusions are not one step. Someone gets a foothold on one machine and then moves sideways until they reach something worth having. A flat network makes that easy. Segmentation is the brake: if a compromised web server can only talk to the two systems it needs, the damage stops there.
CISA's 2025 guidance on microsegmentation describes it as reducing the attack surface, limiting lateral movement and improving visibility. It also sets out the order of work: identify candidate resources, identify their dependencies, then decide the policies, then test and deploy them.
Where it stalls
The policy step is the one everyone wants to start with, because it looks like progress. But a rule written against an address is a guess. Addresses change when workloads move to the cloud, scale out or get rebuilt. The rule set grows with every exception, nobody dares remove a line, and the project ends up as a long list of allow-anything rules with a segmentation label on the cover.
The real blocker is that nobody can answer simple questions. Which application is this server part of? Is it production or test? Who owns it? What does it legitimately talk to? If the configuration database cannot answer, no rule written on top of it can be right.
Labels first
The fix is dull and it works. Give every workload a small set of labels that describe what it is, not where it sits:
- Application: the business service it belongs to.
- Environment: production, test, development.
- Role: web, application, database, management.
- Location, where it genuinely matters: a region or a data centre.
Then write rules in the same words. "Production payments web may talk to production payments database on its database port" is one rule, it survives a rebuild, and anyone can read it. Add a new server with the same labels and the rule already covers it.
Labelling also surfaces the surprises before any rule is enforced: the test server that talks to production, the database nobody owns, the management tool that reaches everything. Those are the findings that justify the project.
How to start
My own view: pick one application that matters, label everything it touches, watch its traffic for a few weeks in a mode that only reports, and only then enforce. CISA recommends the same kind of permissive testing, so that missed dependencies show up as alerts rather than outages. Then do the next application. Estates are segmented one service at a time, not in one big switch-over.
LabelSim on this site lets you try a labelling scheme and see the blast radius before you touch a real policy.
What to do on Monday
- Choose the label set: four keys at most, with a short list of allowed values for each.
- Pick one important application and label every workload it uses.
- Turn on reporting-only mode and collect a few weeks of real flows.
- Write the first rules in label terms, review them with the application owner, then enforce.
Sources
- CISA, Microsegmentation in Zero Trust, Part One: Introduction and Planning (July 2025).
- NIST, SP 800-207: Zero Trust Architecture (2020).
- LabelSim, on this site.
Personal work and my own view, not my employer's. Sources are public.