Recent Breaches
Breaches
View All →
Control Module - FIRE

FV-Isolate. Separate, contain and limit reach.

Isolate divides systems and networks into controlled zones so a problem in one place cannot freely become a problem everywhere. Trust does not extend across a boundary unless the boundary is intentionally opened for a defined purpose.

Back to Control

Control Module - FIRE

Separation is a design decision. Without it, every incident has the run of the building.

Designed

Boundaries are explicit, not implied by network topology

Bounded

Lateral movement is constrained by the zone it starts in

No inherited trust

Cross-zone access is requested, not assumed

Continuously enforced

Separation holds during normal operations and during response

The Problem

Flat networks reward whoever reaches them first.

Lateral movement

Once an attacker is inside a flat or weakly segmented environment, the next system, the next share and the next credential are all one step away.

Trust by topology

Permissions that exist only because two systems sit on the same subnet are permissions nobody chose to grant.

Drift over time

Logical segmentation drifts as services are added, integrations are wired in and exceptions accumulate, until the original boundary is no longer the real boundary.

The Scenario

Scenario: containing a compromise to its zone

A workstation in a corporate zone is compromised through a credential reuse attack. Because the corporate zone is isolated from the operations zone and from the records zone, the attacker's reach is limited to what is intentionally exposed to corporate, which is little. Investigation, eradication and recovery proceed in the affected zone while the other zones continue to operate. Cross-zone access for the responders is requested explicitly rather than already being available by default.

"Isolate is the difference between an incident in one room and an incident in the whole building."

FV-Isolate in placement

Where Isolate holds the zone boundary.

Isolate enforces the zone and conduit model. Each protected zone is reachable only through a named conduit, and only when the conduit is authorised to be open.

Grounded in IEC 62443-3-3 SR 5.1, SR 5.2 and SR 5.3, NIST SP 800-82 zone guidance and the Purdue Enterprise Reference Architecture.

Inputs ─┐Telemetry ─┐

FV-Isolate

Control layer

┌─ Outputs┌─ Control
01SR 5.1

Enterprise zone boundary

Defines the perimeter of the enterprise zone. Cross-zone traffic must use a declared conduit.

02SR 5.2

Control system zone (Purdue L3 to L2)

Holds the boundary between supervisory and process control. Engineering reach is named, not implicit.

03IEC 61511

Safety instrumented system zone

Keeps the SIS separated from basic process control. A compromise of BPCS does not reach the safety layer.

04PR.IP-9

Recovery and forensic zone

Recovery infrastructure sits in its own zone, reachable only when a restore operation is authorised.

Relies on · prerequisites

  • An explicit zone and conduit inventory that is maintained, not assumed
  • Out-of-band approval to open a conduit
  • Continuous evidence that each boundary is intact

Pairs with · companion modules

FirebreakRelayLockValidate

Featured In

TechRadar ProSecurity BuyerYahoo FinanceSecurityBriefChannel Insider

Key Capabilities

Explicit zoning

Zones are designed against operational reality, not inherited from the way switches happened to be wired.

Default-deny crossings

Cross-zone traffic is not allowed unless a specific path, purpose and approval exist.

Reduced blast radius

A compromise in one zone is contained to the surface that zone exposes, rather than the whole estate.

Independent recovery

Each zone can be investigated, recovered and brought back online without waiting on the others.

Identity-aware boundaries

Zone membership accounts for the identity making the request, not just the address it came from.

Evidential record

Boundary changes and cross-zone approvals are recorded through Archive on physically separate storage.

Demo to Live

Adoption Guide

Step 1

Map the estate

Identify the systems, services, identities and data flows that should sit together and those that should not.

Step 2

Design the zones

Define zones around operational reality, with explicit ownership and explicit cross-zone rules.

Step 3

Validate the boundary

Test the boundary with realistic scenarios, including credential abuse and inherited trust paths.

Step 4

Operate and review

Run Isolate as part of normal change control and review crossings through Archive on a regular cadence.

Step 1

Map the estate

Identify the systems, services, identities and data flows that should sit together and those that should not.

Step 2

Design the zones

Define zones around operational reality, with explicit ownership and explicit cross-zone rules.

Step 3

Validate the boundary

Test the boundary with realistic scenarios, including credential abuse and inherited trust paths.

Step 4

Operate and review

Run Isolate as part of normal change control and review crossings through Archive on a regular cadence.

Questions

Frequently Asked

    Isolate

    Isolate enforces physical separation between zones at every site, with no shared paths between trusted and untrusted infrastructure.

    © 2026 Firevault Limited. Disconnect to Protect®