Segmentation is the control that decides whether a single compromised machine is an incident or a catastrophe. Its whole purpose is blast-radius containment: carve the network so that owning one host does not grant the attacker free movement to everything else. It is the defensive counterpart to almost every lateral-movement technique in the AD attack-path map.
The problem it solves is the flat network: historically, once you were “inside,” you could reach almost anything. Modern attacks — and modern ransomware especially — turn that flatness into domain-wide encryption in hours. Segmentation makes the interior hostile to movement.
North-south vs east-west
The single most useful lens. North-south traffic crosses the perimeter (in/out of the org) and has always been inspected by firewalls and proxies. East-west traffic moves laterally between internal systems — and in a flat network it is almost entirely uninspected. East-west is where attackers live after the first foothold, so it is the modern battleground.
NORTH-SOUTH (always inspected) EAST-WEST (the real battle)
Internet app01 ---- app02
| | \ / |
[ perimeter FW / proxy / WAF ] | \ / |
| db01 -- file01 -- dc01
internal (flat = attacker moves freely;
segmented = each hop is a wall)Granularities of segmentation
| Level | Mechanism | Granularity |
|---|---|---|
| Physical / air-gap | Separate hardware/networks | Coarsest; for OT, crown-jewel, or classified |
| VLAN / subnet + firewall | Layer-2/3 zones with inter-zone rules | Per subnet/zone |
| Security zones | DMZ / internal / restricted / management | Per trust tier |
| Micro-segmentation | Per-workload allow policy (host- or fabric-based) | Per workload / process |
| Identity-based | ZTNA / identity-aware proxy | Per user+app session (see Zero Trust) |
Security zones (the macro layout)
| Zone | Purpose | Typical controls |
|---|---|---|
| DMZ | Internet-facing / proxied services | WAF, reverse proxy, no inbound to internal |
| Internal | General corporate & app tiers | Default-deny between tiers, NAC on access |
| Restricted | Crown jewels — PCI CDE, PII, payments, Tier-0 identity | Micro-segmented, strict allowlist, heavy logging |
| Management / OOB | Out-of-band device management (iLO/iDRAC, jump hosts) | Physically/logically isolated; never reachable from user space |
A dedicated out-of-band management network is the control attackers hate most: it means a foothold on the user LAN cannot reach the management plane of the infrastructure — the firewalls, hypervisors, and domain controllers that own everything.
Micro-segmentation: approaches & tooling
| Approach | Leading tools | Notes & trade-offs |
|---|---|---|
| Host/agent-based | Illumio, Akamai Guardicore | Workload-aware, cloud-portable, no re-IP — best for brownfield. Burden is policy authoring; start in visualise-only mode. |
| Fabric/network-based | Cisco Secure Workload / ACI, VMware NSX | Powerful in a homogeneous DC; vendor lock-in and cost are the downsides. |
| Cloud-native | Security groups / NSGs, service mesh mTLS (Istio/Linkerd) | Native and cheap, but policy sprawls across accounts — govern with CNAPP. |
Rolling it out without causing outages
The number-one way micro-segmentation projects fail is going straight to enforce and breaking a business-critical flow nobody documented. The safe sequence:
- Map & visualise — run the tool in observe mode for weeks to learn the real traffic graph (you will be surprised what talks to what).
- Ring-fence the crown jewels first — the CDE, payments, Tier-0 — rather than boiling the ocean.
- Model policies & test in alert-only before enforcing.
- Default-deny, then enforce zone by zone, with a fast rollback path.
- Keep it alive — segmentation drifts as apps change; treat policy as code and review it.
A high-value side effect: PCI scope reduction
For a card-handling business, segmentation isn't only security — it shrinks the cardholder-data environment (CDE), and therefore the PCI DSS audit scope, to the smallest possible set of systems. Everything provably isolated from the CDE falls out of scope. That audit-cost reduction is often what finally funds a segmentation programme.
Red team ↔ blue team: segmentation vs lateral movement
| Attacker technique | How segmentation blunts it |
|---|---|
| Pass-the-hash to neighbouring hosts | East-west allowlist: the stolen hash has nowhere to go — the peer ports are blocked |
| Coercion & relay / poisoning | Smaller broadcast/segment domains shrink the set of coerce-able and relay-able targets |
| Ransomware worming | Default-deny east-west caps encryption to one segment instead of the estate |
| Reaching a domain controller | DCs in a restricted zone, reachable only from PAWs via jump hosts, not from user space |
Trade-offs & failure modes
- Operational friction. Every new app needs policy; without automation this becomes a ticket queue that teams route around.
- Over-segmentation. Micro-segmenting everything is rarely worth it — target the crown jewels, accept coarser control elsewhere.
- Stale policy. Segmentation that isn't maintained silently rots into either outages or quiet allow-all exceptions.
- Visibility gaps. You can only segment what you can see — asset discovery is a prerequisite.
Key takeaways
- Segmentation = blast-radius containment; the point is to make lateral movement expensive.
- North-south has always been inspected; east-west is the modern battle.
- Micro-segment the crown jewels, observe before you enforce, and treat policy as code.
- It is the direct defensive answer to the lateral-movement half of nearly every AD attack.