Zones and Conduits: What OT Segmentation Actually Requires

Network segmentation gets discussed as though it were a firewall purchase. It is not. It is an exercise in writing down what talks to what, and the firewall is only the thing that enforces the list once the list exists. Every segmentation project that stalls, stalls at the list.

IEC 62443 gives the vocabulary worth borrowing. A zone is a grouping of assets that share security requirements — a control zone, a safety zone, a plant DMZ, the business network. A conduit is the communication path between two zones, together with the flows allowed to cross it. The value of the terminology is not taxonomic; it is that a conduit cannot be defined without enumerating what actually crosses it, and that enumeration is the work.

The Purdue model is where most people start, and it is a useful sketch rather than a specification. Real plants have skids that phone a vendor's cloud for support, an MES that reaches down into controllers to write recipes, engineering laptops that move between levels, and a historian that everyone in the business wants to query. A design that pretends those flows do not exist gets bypassed within a month by someone with a legitimate job to do.

So the first deliverable is an inventory, and the honest version of it. The UK's NCSC made this point directly in its recent OT guidance: do not assume your control systems are unreachable from the internet without verifying it, because exposure arises from misconfigurations, forgotten legacy connections and assets nobody has on a list. An asset inventory that covers devices but not communication paths and external connections is half an inventory.

It is also worth being clear that VLANs alone are not segmentation. Separating traffic into different broadcast domains is addressing hygiene. Segmentation happens when a policy enforcement point sits between two zones and drops what is not explicitly permitted. If the only thing between the business network and the control network is a layer 3 switch that routes freely between VLANs, the plant has a diagram, not a boundary.

Write each conduit as a table with six columns: source, destination, protocol and port, direction, which side initiates, and expected rate. Default deny, and then add rows until the plant runs. The initiator column earns its place repeatedly, because the direction of the TCP connection is often the entire security argument — the classic pattern being a historian inside the control zone that replicates outward into a DMZ, with nothing on the business side ever permitted to initiate inward.

That pattern is not theoretical. When a device manufacturer disclosed a cyber incident this week that stopped its ability to manufacture and ship, its own updates noted that cloud systems were unaffected and the damage was confined to certain on-premise systems. Whatever the initial access, the blast radius was decided by what was reachable from what. That is a segmentation outcome, and it is the strongest argument for the work there is.

Remote access is the standing exception that quietly consumes the design. Vendors need in, integrators need in, and the pressure to make that easy is constant and legitimate. Broker it rather than permitting it: one brokered path, multi-factor authentication, time-bounded sessions, an approval step, and recording. A permanent vendor VPN into a control zone is a conduit that nobody wrote down and nobody monitors.

While the conduits are being catalogued, the protocols crossing them deserve the same treatment, and here the NCSC guidance is unusually concrete. It names the migration path for each legacy protocol rather than talking in principles: DNP3 to DNP3-SAv5, CIP to CIP Security, Modbus to Modbus Security, OPC DA to OPC UA. It calls for removing Telnet and SNMP versions 1 and 2 outright, and for confining anything insecure with no secure alternative to isolated segments. The practical difficulty is that support for the secure variants is uneven across installed equipment, which means the migration list doubles as a replacement schedule.

Two operational details finish the design. Controllers should not be left in PROGRAM or maintenance modes, and logic needs write protection or an equivalent so that reachability alone does not equal authority to change the process. And the devices that make external connectivity possible — gateways, firewalls, routers, remote access appliances — need to stay within vendor support, get patched, be replaced before end of life, and be managed only from a segregated management network. An out-of-support firewall is not a boundary; it is a device with known vulnerabilities in the most sensitive position on the plant.

Then test it, which most projects skip. Verifying that permitted flows work proves nothing about the boundary. The test that matters is attempting the flows that should fail and confirming they do, then monitoring for connection attempts from unexpected sources — which is a genuine advantage of OT networks, because they are static enough that anything new is worth investigating.

Finally, treat the zone and conduit document as a live artefact tied to management of change. The design will be correct on the day it is signed and wrong within a quarter, because a new skid arrived and somebody needed it to reach the historian. Whether that flow becomes a documented row or an undocumented firewall exception is the whole difference between a segmented plant and a plant that used to be segmented.