The Segmentation Project You Never Finished

Ask a room of security people whether the network should be segmented and every hand goes up. Ask how many have finished, and the answer is a specific kind of silence.

I have never met anybody who disagreed with the principle. I have met a great many organizations where the project started, produced a diagram, ran in monitoring mode for eight months, and quietly stopped being mentioned in status updates.

That pattern is worth understanding, because the failure is not one of conviction and it repeats in organizations that do everything else well. Something about the shape of the work defeats teams who finish harder things routinely.

What Flat Actually Costs

The zero trust conversation has largely been about the front door. Who is this, what device are they on, should they be let in. We covered the version of that argument that works on the estate you actually have, including the equipment that cannot present an identity to anything.

The inside is where the gap is. In most environments, an endpoint that has been compromised can reach an enormous amount of the network directly, because east-west traffic was never restricted and there was never a reason to restrict it. The workstation can talk to the file server, the database, the hypervisor management interface, the badge system, and the printer that shares a subnet with all of them.

That reachability is the entire basis of the incident economics. A ransomware operator’s dwell time is spent moving from the first machine to the ones that matter, and every hop is only possible because nothing between them said no. When we wrote about the week a company lost even though its backups were fine, the reason the restore was so large was that the encryption reached so far.

Segmentation is the control that changes the shape of a bad day rather than the probability of one. It does not stop the initial compromise. It determines whether the compromise is a laptop or the estate.

Why It Stalls

Three reasons, and none of them is that somebody stopped caring. Each one is a property of the work rather than of the people doing it.

The dependencies are undocumented

Nobody knows what talks to what. The diagram in the wiki describes an intended architecture from four years ago, and the actual traffic includes a reporting server that queries production directly because somebody needed a number in 2022, a build agent that reaches a database it should not, and a monitoring tool with credentials to everything.

You cannot write a rule set against a system you cannot describe, and the discovery work is genuinely large. This is the same problem as the API endpoints nobody has inventoried, at a different layer and with more sharp edges.

The failure mode is somebody else’s outage

When a segmentation rule is wrong, the security team does not experience the consequence. A finance batch job fails at 2 AM, an integration stops, a clinician cannot reach a scanner. The person who gets paged is not the person who wrote the rule.

That asymmetry sets the political cost of the project. After the second unexplained outage, enforcement gets paused “until we understand the traffic better,” and understanding the traffic better has no completion criterion.

The scope is set by the tool

Buy a microsegmentation platform and it will show you every workload and invite you to write policy for all of them. That framing makes the project the size of the estate, which makes it a multi-year program, which means it competes with everything else on a multi-year horizon and loses.

The Version That Finishes

The projects I have seen complete all did the same thing, which is refuse the version that covers everything. They picked a small piece, finished it, and left the rest alone.

Start from three things, not from the network

Name the three assets whose compromise would actually hurt. Not a list of critical systems from a spreadsheet, three things, the way you would answer if somebody asked you in a corridor. The customer database, the payment system, and the domain controllers is a realistic answer for a lot of organizations.

Now ask a narrower question than the platform asks: what legitimately needs to reach each of these, and from where? That question has an answer in about a week, where mapping the whole estate has no answer at all on any timescale anybody will fund.

Ring-fence in, before you segment out

The first rules should restrict what can reach your three things, not what those three things can reach. Inbound restriction is lower risk because the traffic is easier to enumerate and the blast radius of a wrong rule is narrower.

Outbound restriction from a critical system is more valuable and considerably more dangerous to get wrong, so it comes second, once you have learned how your own change process handles this kind of rule.

Monitor first, and set a date

Every rule runs in monitoring mode before it enforces, and that part everybody does. The part that gets skipped is putting a date on when monitoring ends.

Without a date, monitoring is the permanent state of the project, because there is always more traffic to understand and no moment where somebody declares it understood. Pick four weeks, publish it, and enforce on that day with an agreed rollback. The rollback is what makes the date acceptable to the people who own the systems.

Bring the owners in before the rule, not after

The team that runs the affected system should see the traffic list and confirm what belongs on it. This is slower than writing rules from observation and it is the difference between a project that survives its first outage and one that does not.

An outage from a rule the system owner agreed to is a shared problem. An outage from a rule the security team wrote alone is a reason to stop the project.

Accept partial

Three segments that are enforced and stable are worth more than a complete design sitting in monitoring mode. If you ring-fence the three things that matter and never touch the rest of the estate, you have materially changed what a bad day looks like, and you have done it in a quarter.

The instinct to finish properly is the thing that keeps this from being finished at all. I would rather review three enforced segments than a beautiful design nobody has switched on.

What to Tell the People Funding It

The honest pitch is not that segmentation prevents breaches, because it does not, and anybody senior enough to fund it has heard that claim before and discounted it.

The pitch is about the size of the incident. A compromised endpoint in a flat network is an enterprise event with a disclosure question attached. The same compromise inside a segmented one is a rebuild of one machine. The control does not change how often you get hit, it changes what gets hit, and that is the number that appears in the recovery cost and the notification scope.

CISA’s guidance this week on planting decoys inside networks makes the same assumption from a different angle, which is that the attacker is already past the perimeter and the useful question is what they encounter next.

If you want help scoping a segmentation effort that ends, or working out what your three things actually are, contact Grab The Axe. You can also take our free Human Attack Surface Score to see where the people-shaped gaps sit.

Chris Armour is Director of Information Security at Grab The Axe.

Director of Information Security

Chris Armour

The Breaker & Builder.

Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.

View Author Page →