IEC 62443 zones and conduits for firewall rules

ISA/IEC 62443 is the international series of standards for securing industrial automation and control systems. It was written by the ISA99 committee and is published by both ISA and the IEC. For anyone reviewing OT firewalls, two parts matter most: IEC 62443-3-2, which describes how to split a system into zones and conduits, and IEC 62443-3-3, which lists the system security requirements those zones must meet.

Zones and conduits in IEC 62443-3-2

A zone is a group of assets that share the same security requirements. A conduit is the group of communication channels between zones, with its own security requirements. IEC 62443-3-2 asks the asset owner to partition the system under consideration into zones and conduits, then assess the risk of each and set a target security level.

In a firewall review the mapping is direct:

• Each firewall zone or interface group is a candidate zone.
• Each zone pair the firewall allows traffic between is a conduit.
• Each allow rule is a statement about what that conduit may carry.

The standard does not tell you to use Purdue levels, but many sites draw their zones along them. The Purdue model guide covers that view.

Target security levels (SL-T)

IEC 62443 defines four security levels. SL 1 is about casual or accidental misuse; each level above it assumes a more capable and better-resourced attacker, up to SL 4 for a sophisticated, well-funded one. SL 2 is the first level that assumes someone is trying on purpose. Strictly, a security level is a vector across the seven foundational requirements, not one number, though many programs set one value per zone.

The asset owner assigns each zone a target level (SL-T) from its risk assessment. The level is the owner’s decision, not the auditor’s, and a review should say which value it used. A firewall review never establishes the achieved level (SL-A); that needs the countermeasures in place and assessed.

IEC 62443-3-3 requirements a firewall can show

IEC 62443-3-3 groups its system requirements (SRs) under seven foundational requirements. A firewall configuration and its traffic log can speak to a handful of them. The core three for segmentation are:

• SR 5.1 Network segmentation. Control system networks are segmented from other networks, and critical networks from each other.
• SR 5.2 Zone boundary protection. Communication at zone boundaries is monitored and controlled. Its first requirement enhancement, deny by default and allow by exception, applies from SL 2 upward.
• SR 5.3 General purpose person-to-person communication restrictions. Person-to-person messages from outside the control system, such as email and instant messages, are restricted.

Others where firewall evidence helps:

• SR 1.13 Access via untrusted networks. Remote access is monitored and controlled. The IDMZ guide covers how this usually lands.
• SR 7.7 Least functionality. Unneeded functions, ports, protocols and services are removed or restricted.
• SR 2.8 Auditable events and SR 6.2 Continuous monitoring, through what the firewall logs at each boundary.
• SR 4.1 Information confidentiality, where cleartext protocols cross a boundary.
• SR 7.8 Control system component inventory, from the hosts the traffic shows.

None of these is met by the firewall alone. Most also need process and documentation evidence that a rulebase cannot provide, which is why a firewall-based assessment marks a control partial whenever it cannot see the whole picture.

What a zone-and-conduit review looks for

• Conduits nobody designed. Zone pairs carrying traffic that the zone model has no conduit for.
• Boundaries that default to allow. Any-any rules, or rules naming whole zones and “any” application, at a boundary that SR 5.2 asks to deny by default.
• General-purpose applications on OT conduits. Web, RDP, SMB, SSH, file transfer and remote-support tools crossing into OT, where SR 5.2 and SR 7.7 point to a short list of named applications.
• Remote access that skips the IDMZ. Sessions from the internet, a VPN pool or the office landing straight in OT (SR 1.13).
• Higher-SL zones reached from lower-SL zones without a broker in between.

How SegAudit reports IEC 62443

SegAudit builds an IEC 62443-3-2 zone and conduit worksheet with one row per conduit observed in the traffic: the two zones, their levels and SL-T, the sessions and applications, the allowing rule, a proposed drop rule, and notes against SR 5.1 and SR 5.2. SL-T is set by you on Evidence setup; SL-T 2 is assumed until you set one. The worksheet exports as CSV or markdown. It is a work product for the assessor, not a certification.

The compliance crosswalk judges nine IEC 62443-3-3 controls (SR 1.13, 2.8, 4.1, 5.1, 5.2, 5.3, 6.2, 7.7 and 7.8) as supported, partial or gap from the same evidence, and shows the status after the change package is in place.

In the Northline sample, findings cite SR 5.1, SR 5.2 or both, for example “Any-any allow “allow-any-temp” is matching traffic” (critical) and “IT L4 talking straight into L2 · 38 sessions” (critical). When a path between IT and OT reaches a zone with a higher SL-T than its source without an IDMZ broker, the finding’s severity is raised one step and the worksheet says why.

See Frameworks for the full list of frameworks SegAudit maps to.

Common questions

Is IEC 62443 the same as ISA 62443? Yes. ISA publishes the series as ANSI/ISA-62443 and the IEC as IEC 62443; the content is aligned. People often write ISA/IEC 62443.

Does a firewall review make a site IEC 62443 compliant? No. It gives evidence for some system requirements. Certification and a full IEC 62443-3-2 risk assessment are separate work.

What SL-T should we use? The one your risk assessment set for each zone. Where none is set yet, say which value the review assumed.