OT Network Segmentation: Implementing Zones and Conduits for Industrial Security

Introduction

Network segmentation is consistently ranked as the single most effective security control for operational technology environments. It limits an attacker's ability to move laterally, constrains the blast radius of a compromise, and creates enforcement points where traffic can be inspected and controlled. Yet many industrial organizations still operate flat networks where an engineering workstation, a historian server, and a safety controller all share the same broadcast domain.

This guide provides a detailed, practical framework for implementing OT network segmentation based on the Purdue Enterprise Reference Architecture and the IEC 62443 zones and conduits model. It is written for OT security architects, network engineers, and CISOs responsible for protecting industrial operations.

The Purdue Model as a Segmentation Blueprint

The Purdue Enterprise Reference Architecture (PERA) remains the most widely used conceptual framework for organizing OT networks into hierarchical layers. While originally developed for manufacturing, it applies across all industrial sectors with minor adaptation.

Applying the Purdue Levels

Each Purdue level represents a functional layer of the industrial architecture. Segmentation boundaries should align with these levels:

The critical principle: no traffic should ever bypass a level. A Level 4 business application must never communicate directly with a Level 1 controller. All data flows must traverse the appropriate boundaries and pass through enforcement points at each transition.

Where the Purdue Model Falls Short

The traditional Purdue model was designed for a single-site, hierarchical architecture. Modern OT environments present challenges it does not fully address:

• Cloud connectivity: Vendor-hosted analytics, remote monitoring platforms, and cloud historians introduce traffic patterns that do not fit the hierarchical model cleanly.
• Wireless field networks: WirelessHART, ISA100.11a, and industrial Wi-Fi blur the boundary between Levels 0, 1, and 2.
• Multi-site architectures: Centralized SCADA or DCS architectures that manage multiple remote sites require lateral communication paths the original model did not anticipate.

In these cases, the Purdue model should be used as a starting framework, with IEC 62443 zones and conduits providing the additional flexibility needed to model the actual environment.

IEC 62443 Zones and Conduits

IEC 62443-3-2 formalizes the concept of security zones and conduits, providing a rigorous methodology for segmentation design.

Defining Zones

A security zone is a logical or physical grouping of assets that share the same security requirements. Zone definition should consider:

• Common Security Level Target (SL-T): Assets within a zone should require the same level of protection. A safety instrumented system (SL-T 3 or 4) should never share a zone with a low-criticality monitoring system (SL-T 1).
• Functional grouping: Assets that participate in the same process or control function naturally form a zone. Grouping by process unit, production line, or geographic area is common.
• Trust boundaries: Assets managed by different teams, vendors, or organizations should be in separate zones. A vendor-managed system and an internally managed system have different trust profiles.
• Risk tolerance: Assets with significantly different risk profiles should not share a zone, because the zone's security controls will be designed for a single target level.

Defining Conduits

A conduit is the controlled communication path between zones. Every conduit must be explicitly defined, documented, and enforced. For each conduit, specify:

• Source zone and destination zone: Which zones does this conduit connect?
• Permitted traffic flows: Specific protocols, ports, source addresses, and destination addresses allowed through the conduit.
• Direction of initiation: Which zone initiates the connection? In most OT architectures, connections should be initiated from higher-trust zones toward lower-trust zones, not the reverse.
• Security controls applied: Firewalling, protocol inspection, encryption, authentication, and logging requirements for the conduit.
• Data flow justification: A documented business or operational reason for each permitted flow. If no one can explain why a flow exists, it should be blocked.

Zone and Conduit Documentation

Maintain a zone and conduit diagram as a living document. This diagram should map every zone boundary, every conduit, and the security controls applied at each point. It serves as the authoritative reference for firewall rule reviews, change management, and audit activities.

Designing the IT/OT DMZ

The DMZ between IT (Level 4) and OT (Level 3) is the most critical segmentation boundary in the architecture. A well-designed DMZ prevents direct communication between IT and OT while enabling the data exchange that the business requires.

DMZ Architecture Components

A properly designed industrial DMZ includes:

Dual-firewall topology: An IT-facing firewall and an OT-facing firewall create a screened subnet. Traffic from the IT network terminates at the DMZ; traffic from the OT network terminates at the DMZ. No single firewall rule set permits traffic to traverse from IT to OT directly.

Jump servers: All interactive access from IT users or remote users into the OT network must pass through a jump server in the DMZ. The jump server enforces multi-factor authentication, session recording, and time-limited access.

Data transfer servers: Operational data (historian data, production reports) moves from OT into the DMZ, where business systems can retrieve it. This "push from OT, pull from IT" model ensures that IT systems never reach into the OT network.

Unidirectional gateways (data diodes): For the highest-security environments, hardware-enforced unidirectional gateways guarantee that data can flow out of the OT network but nothing can flow back in. These are particularly valuable for safety-critical zones.

File transfer and scanning stations: Files moving between IT and OT (patches, configuration files, reports) pass through an automated scanning station in the DMZ that checks for malware before delivery.

DMZ Design Principles

• No system in the DMZ should store OT credentials or have persistent connections into the OT network.
• DMZ systems should be hardened, monitored, and patched on an aggressive schedule, as they are high-value targets.
• DNS, NTP, and authentication services for the OT network should be independent of IT infrastructure, with OT-dedicated instances hosted in the DMZ or within the OT network itself.
• All DMZ access should be logged, and logs should be forwarded to both IT and OT security monitoring platforms.

Firewall Rule Design for OT Protocols

OT environments use industrial protocols that require specialized firewall capabilities. Standard IT firewalls that operate only at the TCP/UDP port level provide insufficient protection.

Protocol-Aware Firewalling

Industrial-grade firewalls from vendors such as Fortinet, Palo Alto Networks, Cisco, and purpose-built OT firewalls from vendors like Tofino and Waterfall can inspect OT protocol content. This enables rules far more granular than simple port-based filtering:

Firewall Rule Management Practices

Default deny: Every OT firewall should start with a deny-all policy. Rules are added only for explicitly documented and justified communication requirements.

Specificity: Rules should specify source IP, destination IP, destination port, and protocol. Broad rules that allow "any" in any field should be flagged for review and tightened.

Regular review: Conduct firewall rule reviews at least quarterly. Compare active rules against the zone and conduit documentation. Remove rules that no longer correspond to active operational requirements.

Change control: All firewall rule changes must follow a formal change management process with documented justification, risk assessment, and approval.

Logging and alerting: Log all denied traffic and all permitted traffic on critical conduits. Alert on denied traffic patterns that may indicate reconnaissance or attempted lateral movement.

Practical Segmentation Strategies

Starting from a Flat Network

Many organizations inherit flat OT networks with no segmentation. Implementing full segmentation in a brownfield environment requires a phased approach:

Phase 1: Visibility. Deploy passive network monitoring to discover all assets, map communication flows, and build a baseline. You cannot segment effectively without understanding what is communicating with what.

Phase 2: IT/OT boundary. Implement the DMZ between IT and OT. This single step provides the highest risk reduction per unit of effort. Eliminate all direct connections between business systems and OT devices.

Phase 3: Safety system isolation. Separate safety instrumented systems onto dedicated network segments with the strictest access controls. Safety systems should communicate only with the specific controllers and HMIs that require their data.

Phase 4: Zone segmentation within OT. Divide the OT network into zones by process area, criticality, or function. Deploy firewalls at zone boundaries with protocol-aware rules.

Phase 5: Micro-segmentation. For the most critical assets, implement per-device or per-function segmentation. This is the most granular level and is typically reserved for the highest-risk systems.

Segmentation Without Downtime

A common objection to segmentation is that it requires process downtime. In practice, segmentation can often be implemented with minimal or no operational disruption:

• Deploy new firewall infrastructure in parallel with existing network paths, initially in monitor-only mode.
• Use monitor-only mode to validate that firewall rules are correct and that no legitimate traffic will be blocked.
• Cut over to enforced mode during a planned maintenance window, with rollback procedures ready.
• For zones that cannot tolerate any downtime risk, implement segmentation during scheduled turnarounds or annual shutdowns.

Common Segmentation Pitfalls

Even well-intentioned segmentation efforts can fail. These are the most common mistakes:

Segmenting the network but not the services. Placing a firewall between IT and OT is ineffective if both networks share the same Active Directory, DNS, or NTP infrastructure. A compromise of the shared AD server gives an attacker credentials that work on both sides of the firewall. OT should have independent or highly isolated service infrastructure.

Overly broad firewall rules. Rules that allow "any" source or "any" port defeat the purpose of segmentation. Every rule must be specific and justified. "We need it to work" is not a sufficient justification; the specific communication requirement must be documented.

Forgotten pathways. Segmentation must account for all communication paths, including vendor VPN connections, cellular modems on field devices, serial-to-Ethernet converters, and USB-based data transfers. A single uncontrolled pathway can bypass an otherwise well-designed segmentation architecture.

Treating segmentation as a one-time project. Networks change. New devices are added, applications are upgraded, and communication requirements evolve. Without ongoing maintenance, firewall rules become stale, new connections bypass intended boundaries, and segmentation degrades over time. Segmentation must be continuously monitored and maintained.

Ignoring east-west traffic within OT. Many segmentation efforts focus entirely on the north-south boundary between IT and OT while ignoring lateral movement within the OT network. An attacker who compromises a single OT workstation in a flat OT network can reach every controller and safety system. Internal OT segmentation is essential.

No monitoring at enforcement points. Firewalls without logging and monitoring are walls without guards. If no one reviews firewall logs or investigates denied traffic, segmentation provides only passive protection. Active monitoring at every zone boundary transforms segmentation from a barrier into a detection capability.

Measuring Segmentation Effectiveness

Track these metrics to assess whether your segmentation is delivering its intended security value:

• Zone boundary coverage: Percentage of defined zone boundaries with enforced firewall rules and active monitoring.
• Rule specificity score: Percentage of firewall rules that specify all five elements (source IP, destination IP, port, protocol, and direction).
• Stale rule count: Number of firewall rules that have not matched traffic in 90 days, indicating potential candidates for removal.
• Unauthorized flow detection rate: Number of communication flows detected by monitoring that were not documented in the zone and conduit model.
• Mean time to rule implementation: Average time from a new communication requirement being identified to the firewall rule being implemented through the change control process.

Conclusion

Network segmentation is not a single control; it is an architectural strategy that underpins nearly every other OT security measure. Monitoring is more effective when the network is segmented into observable zones. Access control is more enforceable when zone boundaries restrict lateral movement. Incident response is more manageable when a compromise is contained within a single zone.

The path from a flat network to a fully segmented architecture is incremental. Start with the IT/OT boundary, isolate safety systems, and progressively refine zone definitions based on risk. The key is to start, maintain momentum, and treat segmentation as a continuous discipline rather than a one-time project.

Beacon Security provides OT network segmentation design, IEC 62443 zone and conduit assessments, and implementation support for industrial environments. Contact us to evaluate your current segmentation posture and develop a practical roadmap for improvement.