Segmentation and microsegmentation, and the difference that matters

Why this matters

Segmentation is the control that decides what an attacker gets after the first success. Prevention fails eventually — a phishing message works, a vulnerability is exploited, a credential leaks — and at that point the only question that matters is how far the compromise reaches. Everything else in security is about reducing the probability of that first event; segmentation is about bounding its consequence.

It is also the control most often present in name and absent in effect. Estates have VLANs, subnets and security groups, and an attacker who lands on a user workstation can still reach the database server, the backup system and the hypervisor management interface, because the segments were drawn around locations rather than around trust.

CAS-005 tests three things here: whether you segment by the right property, whether you understand what microsegmentation adds and where the boundary between the two lies, and whether you can migrate an existing flat network without causing an outage — which is a real constraint that rules out most theoretically correct answers.

The lesson

Segmentation by function, sensitivity and blast radius rather than by subnet convenience

The default segmentation in most estates follows physical or organisational convenience: a subnet per floor, per site, per team, per project. That is addressing, not security, and it produces segments whose members have nothing in common except where they were plugged in.

Segment instead by the properties that decide who should reach what:

• Function. Systems performing the same role with the same exposure profile — user workstations, internet-facing application servers, internal application servers, databases, management infrastructure.
• Sensitivity. The classification from lesson seven. Restricted data lives in a segment with explicit, enumerated entry paths.
• Blast radius. What an attacker gains from compromising anything in the segment. This is the test that catches the others: if compromising any member yields access to materially different assets than compromising another, they do not belong in the same segment.
• Environment. Production, test, development and sandbox. These are different trust levels because the controls and the people differ, and lesson seven established that the data frequently does not.

Three segments that deserve to exist in almost every estate, because their absence causes disproportionate damage:

• Management and administrative infrastructure — hypervisor management, orchestrator control planes, backup systems, identity infrastructure, monitoring. Compromise here exceeds compromise of anything they manage, and they are routinely reachable from the general user network.
• Backup and recovery, separately, because an attacker who reaches backups removes your recovery option and converts an incident into an extortion.
• Operational technology and embedded devices, where they exist, since they frequently cannot be patched and must be compensated for by isolation.

The examinable framing: segmentation is a statement about what an attacker gets, not about how the network is addressed. A scenario describing lateral movement from a workstation to a backup server is describing a segmentation failure regardless of how many VLANs exist.

Microsegmentation: identity-based policy between workloads, not between networks

Microsegmentation narrows the unit of policy from a network segment to an individual workload, and the important change is not granularity but what the policy is written about.

Conventional segmentation writes rules about addresses: this subnet may reach that subnet on this port. Microsegmentation writes rules about identity and attributes: this application may reach that database, wherever either is running, whatever address it currently holds.

That shift matters for three reasons:

• Addresses are no longer stable. Containers, autoscaling and serverless mean an address identifies nothing durable, so address-based policy is either too broad or constantly out of date.
• Policy becomes readable and reviewable. "The payments service may reach the payments database" is a statement someone can check against intent. A rule allowing a /24 to reach a /24 on 1433 is not.
• It survives the estate changing. A workload that moves from one host, cluster or provider to another carries its policy, because the policy names what it is.

The practical goal is default deny between workloads, with allowed flows enumerated. That is achievable in a way it never was on flat networks, because the policy can be generated from observed traffic and then tightened.

Where the boundary with ordinary segmentation falls is a fair question and a practical one. Microsegmentation costs enforcement infrastructure, policy authoring and ongoing maintenance, and it is worth it where east-west movement between similar workloads is the risk. Coarse segmentation remains the right tool for separating fundamentally different trust levels — management from production, production from development — because there the boundary is stable, the rule set is small, and a simpler mechanism is more reliable.

A common exam distractor treats microsegmentation as a replacement for segmentation. It is a refinement inside segments, and an estate that implements it without fixing the coarse boundaries has done the expensive half.

East-west traffic as the movement segmentation is actually there to stop

North-south traffic crosses the perimeter; east-west moves between systems inside it. Historically almost all inspection was north-south, because that is where the appliance was, and the consequence is that the traffic an attacker generates after initial access is the traffic nobody sees.

What lateral movement looks like, and why it is hard to spot without policy:

• Authentication attempts from a workstation to servers it has no business reaching — which look like ordinary authentication.
• Administrative protocol connections between peers, using legitimate tools and valid credentials.
• Reconnaissance: directory queries, service enumeration, share listing — all of which are also normal behaviour for management tooling.
• Data staged to an internal host before exfiltration, so the eventual north-south transfer comes from a system that legitimately transfers data.

Almost none of that is distinguishable by content, because the attacker is using sanctioned protocols with valid credentials. What distinguishes it is that the connection happened at all — which is a policy question, not an inspection one.

This is why segmentation is a detection control as well as a preventative one. In a default-deny estate, a denied connection between two workloads that have no declared relationship is a high-quality signal with almost no false positives — far better than anything content inspection produces. Scenarios that describe "legitimate credentials used from an unexpected system" are pointing at this, and the control that both prevents and detects it is enumerated east-west policy.

Two supporting measures: enumerate and reduce administrative protocol exposure, since remote administration is the dominant lateral movement mechanism; and log the denies, because a default-deny policy whose denials go nowhere has thrown away its best output.

Enforcement points: host agents, hypervisor, service mesh and cloud security groups

Where policy is enforced decides what it can express and how it fails.

Host-based agents. Enforcement in the operating system of each workload. Sees process and user context, works identically across on-premises and any cloud, and follows the workload. Requires an agent on everything — so it misses appliances, unmanaged devices and platforms that do not accept agents — and the agent is itself privileged software to manage and patch.

Hypervisor or virtual network enforcement. Policy applied in the virtualisation layer, outside the guest. No agent needed and the workload cannot disable it, which is a real advantage when the workload is the thing that gets compromised. Limited to virtualised workloads on that platform, and has less context about what is running inside.

Service mesh. A proxy alongside each service handles all traffic, giving identity-based policy with mutual TLS and rich application-layer control, plus observability of every call. Strongest identity model of the four, and it applies only to traffic that goes through the mesh — so anything outside it, including most infrastructure traffic, needs a different mechanism.

Cloud security groups and network policy. The platform's native controls. Free, always present, and enforced by the platform, but typically coarse and scoped to one provider's network constructs.

The practical answer for a real estate is layered, with the layers chosen so their blind spots do not coincide: platform-native controls as the baseline everywhere, mesh or host-based policy for the workloads that need identity-based rules, and hypervisor enforcement where agents cannot be deployed. A scenario naming a workload type — an appliance that takes no agent, a managed service with no host — is usually asking which enforcement point still applies.

One operational property matters more than any comparison: policy must be managed centrally and expressed once, whatever enforces it. An estate with four enforcement mechanisms and four policy sources has four versions of the truth, and the gaps between them are exactly where lateral movement happens.

Migrating an existing flat network without an outage, in stages you can reverse

This is the part that decides whether segmentation ever happens, and it is where scenarios place the realistic constraint.

A flat network cannot be segmented by writing the target policy and applying it. Nobody knows what talks to what, the documentation is wrong, and the first outage caused by a security change ends the programme politically.

The sequence that works:

1. Observe before enforcing. Deploy the enforcement mechanism in monitoring mode and collect flows for a period long enough to include month-end, backups, batch jobs and disaster-recovery tests. Weeks, not days — the flow that only occurs quarterly is the one that will break.
2. Build the intended model from function and sensitivity, not from the observed flows. Observation tells you what is; the model says what should be. Using observation as the design ratifies whatever the attacker would have exploited.
3. Compare, and triage the differences. Every observed flow that the model does not permit is either a missing requirement, a system in the wrong segment, or something that should stop. That triage is the actual work.
4. Enforce coarse boundaries first, starting with the segments whose absence hurts most — management, backup, and the highest-classification data. These have the smallest legitimate flow sets and the largest benefit.
5. Enforce in alert-only mode first, then block, one segment at a time, with a tested rollback and a defined window.
6. Then microsegment inside segments where the risk justifies it.

Two rules that keep it reversible. Every change is one segment, so a problem has one obvious cause. And rollback must be a single action, rehearsed — because the pressure during an outage will otherwise produce a broad exception that never gets removed, and the programme ends with a policy full of holes that is harder to defend than the flat network was.