Zones, Conduits, and Security Levels

Draw the Picture Before You Buy the Hardware

The most common failure pattern in ICS security architecture is buying controls before drawing the design. A firewall is ordered, rules are configured, and the result is called network segmentation. Then an auditor arrives and asks for the zone model. The documented list of what goes inside each security boundary, what is permitted to cross them, and how protection levels were determined. The answer, in most environments, is silence. Security controls without a documented architecture are guesses in hardware. They may protect something. They rarely protect the right things, in the right proportions, for demonstrable reasons. The zone and conduit model from IEC 62443 is the architecture that makes every control decision defensible. It follows a fixed sequence: build the asset model first (covered in Chapter 5), map those assets to a reference architecture showing how they interconnect, then apply zone and conduit design to organize them by security requirement. None of those steps can be skipped and none can be reversed. You cannot draw a reference architecture for assets you have not inventoried. You cannot apply zone boundaries to a network you have not mapped. This chapter covers each step in turn, works through a complete SCADA example, and examines the Colonial Pipeline incident to show what proper zone and conduit design would have changed about one of the most consequential infrastructure incidents in recent memory.

Security Zones: Grouping Assets by Consequence

A security zone is not a VLAN. It is not a building wing or a control room. IEC 62443-1-1 defines a security zone as a logical grouping of assets that share common security requirements. That definition points to the only criterion that matters for zone assignment: consequence of compromise. If a breach of Device A would have the same operational, safety, and regulatory consequences as a breach of Device B, they belong in the same zone. If one device requires significantly more protection than the other, they must be in separate zones. A PLC controlling a safety-critical process and a historian serving reports to the business network do not belong in the same zone, even if they share a physical cabinet or the same floor of a plant. Their breach consequences are different, their access profiles are different, and their acceptable downtime windows are different. Three questions drive every zone assignment decision: What does the device do? What happens if it is compromised? Who legitimately communicates with it? Zone boundaries have two important properties. First, each zone has its own policy, independent of every other zone. Tightening the controls in a safety system zone does not force the same controls onto every other zone. This makes proportional investment possible -- you apply resources where the consequences of failure are highest. Second, zone boundaries must be documented. IEC 62443-3-2 specifies what each zone record must contain: a unique identifier, the accountable organization, logical and physical boundaries, all access points, documented data flows, the assets inside with their criticality ratings, and the target security level. If any of those fields is missing, the zone exists on paper in name only. Zone design is complete when every device in the network is assigned to a zone, every zone has a complete record, and no device sits outside a defined boundary.

Conduits: The Door Policy for Every Zone Boundary

A zone boundary without a documented conduit policy is a wall with no door policy. The SCADA server needs to poll PLCs. The historian needs to push data to the business network. A maintenance vendor needs to connect for an emergency repair. All of those crossings must happen, and all of them must be controlled. A conduit is the controlled path through a zone boundary, defined by IEC 62443-1-1 as a logical grouping of communication channels connecting two or more zones. The conduit does not protect the zone. It defines what is permitted to move between zones, in which direction, using which protocol, from which source. If the zone is the room and the boundary is the wall, the conduit is the door policy: who can open it, when, carrying what, going in which direction. Three categories of conduit exist. Network conduits carry traffic over Ethernet, Wi-Fi, or WAN links and are enforced by firewall rules. Non-network conduits move data through USB devices, removable media, or serial cable connections -- these require physical and procedural controls, not just firewall rules. Out-of-band conduits use cellular modems, serial dial-up links, or maintenance channels that bypass the primary network path. All three categories must be identified and documented. Attackers do not distinguish between network and non-network paths. A USB port with no policy is an uncontrolled conduit. The critical implementation rule distinguishes ICS conduit design from IT firewall configuration: OT conduits use allow-listing, not deny-listing. IT firewalls typically block known bad traffic and permit everything else. OT conduits permit only explicitly authorized communications and block everything else by default. An attacker probing a deny-list has to find one gap in the ruleset. An attacker hitting a properly constructed OT conduit has no default path. The conduit record is the source specification for the firewall rule. The rule implements the conduit policy -- it does not create it. Design the conduit by answering what must flow, in which direction, authenticated by what mechanism. Then write the firewall rule that enforces exactly that. Every gap in the conduit design becomes an uncontrolled path in the firewall configuration.

Security Levels: Matching Protection to Attacker Capability

Every zone in a zone model needs a target security level: a specific answer to the question "how secure is secure enough?" "As secure as possible" is not an answer -- it sets an uncapped investment target and provides nothing to audit against. IEC 62443 defines four security levels, each calibrated to a category of attacker capability, and each zone in the model is assigned one target level based on the consequence of its compromise and the plausibility of each attacker tier targeting it. Security Level 1 addresses casual and accidental exposure: an untrained person who stumbles onto a system, an employee who makes an honest configuration mistake. Basic authentication, minimal access restrictions, and separation sufficient to prevent accidental interference. This is the baseline floor for any IACS zone. Security Level 2 addresses intentional attacks using limited resources and commonly available tools: opportunistic attackers scanning for exposed systems, script-based exploitation of known vulnerabilities. Controls at this level add role-based access control, basic network segmentation, and audit logging. Any OT zone accessible via remote access or connected to a corporate network should target at least Level 2. Security Level 3 addresses sophisticated, deliberate attacks from organized groups with ICS-specific knowledge -- adversaries who conduct extended reconnaissance and execute multi-stage intrusions. Controls add strong multi-factor authentication, network-based intrusion detection, formal change management, and independent security assessment requirements. Most critical infrastructure control system zones target Level 3. Safety instrumented systems, national grid control centers, and infrastructure where the consequence of failure is catastrophic target Security Level 4: state-sponsored actors with substantial funding, custom tooling, and campaigns measured in months or years. Very few zones require a Level 4 designation. Security levels are cumulative: Level 3 requires everything in Levels 1 and 2, plus its own controls. Different zones in the same facility carry different target levels based on their specific risk profile -- the jump server may be Level 2, the SCADA zone Level 3, the SIS zone Level 3 to 4. IEC 62443-3-2 defines the methodology for determining target levels through the risk assessment process. IEC 62443-3-3 and 4-2 define what system-level and component-level controls each level requires.

Designing the Model: A SCADA Example

Applied to a real architecture: a SCADA system with primary and backup control centers connected by WAN, four remote field sites communicating via WAN links, and an enterprise network above the operational layer. The starting point is grouping assets by function and consequence before drawing any boundary. Enterprise IT assets -- business workstations, file servers, ERP systems -- belong in an Enterprise Zone at Level 4 of the ISA99 hierarchy. SCADA system assets -- control center workstations, SCADA servers, historians, and engineering workstations -- belong in the SCADA System Zone at Level 3. Remote site assets at each of the four field locations -- RTUs, PLCs, local HMIs, and I/O devices -- each form a Remote Control Zone at Levels 1-2. The Industrial DMZ, as introduced in Chapter 2, sits at Level 3.5 as a buffer zone between the Enterprise Zone and the SCADA System Zone. Its purpose is to eliminate every direct crossing between IT and OT. The Industrial DMZ holds four components: a historian replica that receives data from Level 3 so enterprise users query a copy and never the live system; a jump server that terminates all inbound remote sessions before they reach SCADA; a patch management server; and an AV update server. Any path from the enterprise network into the SCADA zone that bypasses the DMZ is a violation of the model. Three conduit policies govern the boundaries. The Enterprise-to-DMZ conduit permits historian replica queries (read-only from enterprise) and jump server sessions (authenticated, logged, time-limited) only -- nothing else from the enterprise network enters the DMZ. The DMZ-to-SCADA conduit permits historian data pushed outbound and patch and AV updates inbound, with jump server sessions limited to named SCADA assets only. The SCADA-to-Remote Sites conduit carries ICS protocol traffic with explicit allow-listing by source and destination IP and protocol. For Modbus TCP on this conduit, only read function codes are permitted -- FC01, FC02, FC03, FC04. Write codes FC05, FC06, FC15, and FC16 are blocked at the boundary. An attacker who reaches the conduit boundary can read process data but cannot issue control commands. EtherNet/IP is blocked entirely from all enterprise and DMZ segments.

Four Failures That Appear in Every Audit

Four failure patterns appear consistently in real ICS security audits. The first is dual-homed devices: laptops or workstations with one network interface in the OT zone and another in the IT zone. As Chapter 5 documented in the Industroyer case, any such device bypasses every firewall rule in the zone model. The crossing exists at the device level, below every network control. The second is any-any firewall rules inherited from legacy IT migrations that were never narrowed down for OT. These rules permit all traffic between specific zone pairs, negating the allow-list design entirely. The third is VPN sessions terminating inside the SCADA zone rather than at the DMZ jump server. When credentials are the only barrier between the outside world and the control network -- with no monitored hop at the boundary -- the architecture cannot detect or contain a credential compromise before it reaches operational systems. Colonial Pipeline demonstrated the operational consequence of this configuration. The fourth is a historian with a direct database connection from the corporate network rather than through a DMZ replica. Without the replica, the historian becomes a direct crossing between enterprise IT and the OT data layer, and a compromised corporate system with database access has an unmediated path to operational data. Check your design against all four before submitting it to an assessor. Each one is verifiable in the conduit record: if the permitted traffic specification allows any of these paths, the zone model is incomplete regardless of what the firewall configuration says.

What's Next

Chapter 6 has built the architectural model: zones organized by consequence, conduits governed by allow-lists, security levels matched to attacker capability. Chapter 7 moves up one level of abstraction to the security program itself -- the IEC 62443-2-1 Cyber Security Management System, the lifecycle phases, the maturity model, and how supply chain risk fits into the program structure.

Reflect

• Zone assignment is consequence-driven, not geography-driven. Take the three most critical assets in your environment. Do they sit in their own zones, or do they share a zone boundary with assets that would require significantly less protection -- and what does that mixing do to the controls applied to the critical assets?
• The conduit section states that OT conduit design requires allow-listing rather than deny-listing. Review one firewall enforcing a zone boundary in your environment. Is the default rule "deny all"? Are rules stated in terms of what is explicitly permitted, or in terms of what is blocked?
• Colonial Pipeline was brought down not by OT compromise but by billing failure and uncertainty about OT exposure. Your organization likely has IT-OT dependencies beyond the data historians -- billing, remote access, vendor connectivity. Which of those dependencies would force an OT shutdown if the IT side failed?
• The SCADA example blocks Modbus write function codes at the SCADA-to-remote sites conduit boundary. For the most critical conduit in your zone model, have the permitted protocol function codes been explicitly specified and restricted -- or is protocol traffic allowed at the port level without function code filtering?