Network Isolation During Active Compromise: Designing for the Worst Day

Thu, 09 Apr 2026 00:00:00 +1100

Finding an attacker in your environment isn’t like spotting someone rattling the front door.
It’s like hearing footsteps upstairs.

At that point, the question isn’t how did they get in?
It’s how far can they go next and how fast can you stop that from getting worse?

In an assume‑breach model, network isolation is not an emergency manoeuvre.
It’s a downgrade path the network already understands.

The Mental Model

The common assumption

“If something gets compromised, we’ll isolate it.”

Isolation is treated as an action something responders do.

Why it breaks

During an active compromise:

You don’t know what’s already hostile
You don’t have time to redesign trust
You can’t safely assume the control plane is clean

If isolation requires:

New VNets
New peerings
Rule surgery across shared infrastructure

…then you don’t have isolation.

You have hope.

How It Really Works

Isolation that works under pressure is a structural property, not a procedural one.

The network must already encode:

Where trust is allowed
Where trust is explicitly not allowed
How a workload can be downgraded into a less‑trusted state

This is not about perfect segmentation.
It’s about pre‑authorised damage containment.

The key shift:
Isolation is not “blocking traffic”.
Isolation is forcing a workload into a smaller, poorer, deliberately constrained network world.

Real‑World Impact

Design

You stop grouping networks by:

Application name
Team ownership
Environment labels

And start grouping them by:

Blast radius tolerance
Containment requirements
What you are willing to lose without collapsing everything else

This almost always means:

Fewer fully‑meshed networks
More intentional asymmetry
Shared services treated as amplification risks, not conveniences

Reliability

Isolation‑capable designs fail unevenly, not catastrophically.

You trade some steady‑state elegance for:

Predictable degradation
Fewer “everything is on fire” incidents
Clear containment boundaries under stress

Availability becomes graduated, not binary.

Security

Once credentials or a workload are compromised:

East‑west movement is constrained by structure, not rules
Shared services don’t become free pivot points
Containment actions are coarse, fast, and reversible

Cost

Yes, this often costs more:

More VNets
More thought
More architectural discipline

It costs far less than rebuilding trust after full lateral spread.

Implementation Examples

This is not about NSGs, firewalls, or playbooks.
This is about what the network makes possible and impossible by design.

Designed isolation as a downgrade path

flowchart LR subgraph Prod VNet A[App Tier] B[Data Tier] end subgraph Shared Services VNet C[Identity & Control] D[Observability] end subgraph Isolation VNet E[Quarantine] end %% Normal operations A --> B A --> C B --> C A --> D B --> D %% Containment downgrade A -. isolate .-> E B -. isolate .-> E %% Explicitly impossible paths E -.-x C E -.-x B

What this diagram deliberately shows:

Isolation is a downgrade, not an alternative steady state
Workloads can move into quarantine, not back into shared trust
Quarantine has no path to identity or control services
Some connections are structurally absent, not “normally blocked”

If your design cannot express these absences, isolation will be fragile.

Structural artefact: isolation that exists before you need it

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


resource isolationVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
 name: 'vnet-isolation'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.240.0.0/16'
 ]
 }
 }
}

resource prodVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
 name: 'vnet-prod'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.10.0.0/16'
 ]
 }
 }
}

resource prodToIsolationPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
 name: '${prodVnet.name}/prod-to-isolation'
 properties: {
 remoteVirtualNetwork: {
 id: isolationVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: false
 allowGatewayTransit: false
 }
}

What matters here is not configuration detail, but intent:

The isolation VNet exists independently of any incident
A downgrade path is pre‑authorised
There is no equivalent peering to shared services
Containment does not require new infrastructure

If isolation requires new peerings, you are already too late.

Designed Isolation vs Wishful Containment

This distinction is non‑negotiable.

Designed isolation

Downgrade paths exist ahead of time
Shared services are not universally reachable
Containment changes routing, not architecture
Isolation is fast, coarse, and survivable

Wishful containment

Flat or fully‑meshed VNets
Shared services reachable from everywhere
Isolation requires redesign or mass rule changes
“We’ll block it when it happens”

Only one of these survives an active compromise.

Gotchas & Edge Cases

Shared services are blast‑radius multipliers
If everything depends on them, nothing can be isolated safely.
Fully‑meshed peering kills partial containment
You either isolate everything or nothing.
Late isolation is usually ineffective
Lateral movement is measured in minutes, not hours.
Over‑isolation can blind responders
If quarantine breaks logging or telemetry, you lose visibility when it matters most.

Best Practices

Treat isolation as a network state, not an action
Design explicit downgrade paths and only a few
Group networks by failure tolerance, not org charts
Assume shared services are hostile by default
If isolation requires design changes, it doesn’t exist

🍺

Brewed Insight: If your network can’t force a compromised workload into a smaller, poorer world without redesign, you didn’t design for isolation, you designed for optimism.

Cloud Security Architecture on Brewed in the Cloud by Chris Hailes