IT/OT segmentation for pipeline environments

Almost no pipeline network starts out flat on purpose. It gets that way one connection at a time: a historian that needs to feed a corporate reporting dashboard, a remote-access tool a vendor asked for during a commissioning project and nobody removed afterward, an engineering workstation that’s easier to leave dual-homed than to lock down. Each connection made sense on its own. The accumulated result is a path from the corporate network into the control system that nobody signed off on as a single decision, because nobody made it as a single decision.

The zone-and-conduit model

IEC 62443 builds its segmentation approach around two ideas: zones and conduits. A zone is a group of assets that share a security level, everything inside it trusted to roughly the same degree. A conduit is a defined, justified communication path between zones, not an incidental one. The model doesn’t ask whether a network has firewalls in it. It asks whether every path between two zones was deliberately defined, and whether each conduit actually restricts traffic to what that specific communication requires, rather than acting as an open bridge because it was easier to build that way.

That second question is where most real environments fail, even ones that have functioning firewalls somewhere in the architecture. A firewall between IT and OT proves a boundary exists. It doesn’t prove the boundary matches the zone-and-conduit model unless someone has mapped what’s actually allowed through it against what actually needs to cross it, and those two lists frequently diverge once someone checks.

Where the gap usually shows up

The historian is the most common finding in pipeline environments specifically. It sits on the OT side because that’s where the data originates, and it needs to reach the corporate side because that’s who consumes the reports. Built correctly, that’s a narrow, one-directional conduit: process data flows out, nothing flows back in. Built the way time pressure usually produces, it’s a dual-homed server with broader access than the specific export function needs, because giving it broad access was faster than defining the narrow path and testing it.

Remote access for vendors and integrators is the second-most common. A jump host set up for a commissioning project, or an always-on VPN concentrator installed so a vendor could support their equipment without an on-site visit, both do exactly what they were built to do. The gap opens when the access stays broader or longer-lived than the original justification, which is the normal way a conduit stops matching the zone-and-conduit model without anyone deciding it should.

What a segmentation review actually checks

A review starts with an asset inventory and a data flow map, not with the network diagram someone drew when the system was first built. The diagram shows intent. The traffic shows what’s actually happening, and the two rarely match exactly after a few years of operational patches, vendor visits, and one-off exceptions granted under deadline pressure. From there, the review defines what the zones should be, checks every conduit between them against what it actually needs to carry, and produces a prioritized gap list rather than a single pass/fail verdict, since some gaps are a configuration change and others are a real project.

This is also, directly, the work SD Pipeline-2021-02G’s architecture design review requirement is built around: verification and validation of network traffic and log review, aimed at surfacing vulnerabilities in network design, configuration, and interconnectivity to internal and external systems, on a schedule that recurs at least once every two years. For operators managing that requirement, a segmentation review isn’t a separate initiative from the compliance obligation, it’s the same work, scoped and delivered as evidence for it.

Design, or review of a design already proposed

Not every operator is starting from zero. Some are planning a segmentation project from scratch, working toward a target zone-and-conduit architecture and a prioritized rollout. Others already have a systems integrator’s proposed design in hand and want an independent check before committing to build it, since a design a vendor is also going to implement carries an obvious incentive to make it look simpler and cheaper than the network actually requires. Both are the same underlying question, answered against the network as it actually operates rather than as the diagram says it does.

For what a target zone-and-conduit architecture looks like laid out end to end, see the IT/OT segmentation reference architecture diagram. For what that review looks like as an engagement, see IT/OT segmentation design and review. For the broader assessment this usually sits inside, see the OT/ICS security assessment page.