Segmenting IT from OT with the Purdue model and IEC 62443

Most industrial networks were built for availability and determinism, not for separation from the business network. Over time, historians, remote support links, reporting tools and patch servers created paths between the two. Segmentation is the work of finding those paths, deciding which are needed, and forcing the ones that remain through controlled points.

The Purdue levels

The Purdue model comes from the Purdue Enterprise Reference Architecture and was carried into ISA-95, published internationally as IEC 62264. It is a functional hierarchy, not a network design, but it gives IT and OT teams a shared vocabulary for where a system belongs.

Level	Function	Typical systems
5	Enterprise network	Corporate IT, email, internet access
4	Site business planning and logistics	ERP, site file and print, business reporting
3.5	Industrial DMZ	Replica historian, jump hosts, patch and file transfer servers
3	Site operations	Plant historian, MES, OT domain services
2	Area supervisory control	HMIs, SCADA servers, engineering workstations
1	Basic control	PLCs, RTUs, DCS controllers, safety controllers
0	Physical process	Sensors, actuators, drives

Level 3.5 is a widely used convention for the buffer between enterprise and operations. It is not part of the original model.

The model has limits. Cloud-connected sensors, vendor telemetry devices and cellular gateways can connect a Level 1 device directly to the internet, skipping every level above. Treat Purdue as a way to classify systems, and use IEC 62443 to decide how to separate them.

IEC 62443 zones and conduits

IEC 62443 is the international series of standards for the security of industrial automation and control systems. Part 3-2 covers security risk assessment for system design, including partitioning the system into zones and conduits. Part 3-3 defines system security requirements and security levels.

A zone is a grouping of logical or physical assets that share common security requirements. A conduit is a grouping of communication channels that connects zones. A zone is not the same thing as a VLAN or a Purdue level. One level may hold several zones, and a zone is defined by risk and consequence, not by topology.

Part 3-2 expects business systems and control systems to sit in separate zones. It also calls for safety-related assets, wireless devices, temporarily connected devices such as maintenance laptops, and devices reached over external networks to be separated from the rest.

Each zone is given a target security level, from SL 1 to SL 4. The levels describe the adversary the zone should withstand, from casual or coincidental violation up to intentional attack using sophisticated means, extended resources and control system skills. The gap between the target level and the achieved level drives the countermeasures.

The industrial DMZ

The DMZ enforces one rule: no traffic passes directly between the enterprise zones and the control zones. Every session terminates on a host in the DMZ, such as a replica historian, a jump host or a file transfer server, and a separate session continues from there.

Design points that are often missed:

• Deny by default on both sides of the DMZ, with rules specific to source, destination and port. Avoid rules that allow "any" to the historian.
• Prefer connections initiated from the OT side toward the DMZ, so that data export needs no inbound rule into Level 3.
• Do not extend the enterprise directory into OT. Use separate OT identity services, with no shared credentials.
• Remove dual-homed hosts. A workstation with one interface in IT and one in OT is an unmanaged conduit.
• For high-consequence zones, consider a unidirectional gateway, so that data can leave but nothing can return.

Remote access

Remote access by vendors and integrators commonly bypasses segmentation. A pattern that works:

1. All remote sessions terminate in the DMZ, never on a Level 2 or Level 1 asset.
2. Users authenticate as named individuals with multi-factor authentication. Shared vendor accounts are removed.
3. Access is requested, approved by operations for a time window, and disabled outside it.
4. Sessions pass through a jump host or access broker that limits the reachable targets and records the session.
5. File transfer is separated from the interactive session and scanned.

During discovery, look for what is already there: always-on vendor VPN devices, remote desktop tools on engineering workstations, and cellular modems in control cabinets.

Monitoring

Segmentation creates the points where monitoring is most useful. Collect firewall logs from every conduit, and alert on denied traffic from control zones.

Inside OT, monitor passively. Mirror traffic from Level 3 and Level 2 switches through SPAN ports or network taps into a sensor that understands industrial protocols such as Modbus, DNP3, EtherNet/IP, PROFINET and OPC UA.

Useful detections include new devices, new communication pairs, controller program downloads, firmware changes, controller mode changes and engineering protocols arriving from outside the zone. MITRE ATT&CK for ICS gives a common language for describing them.

Why passive discovery comes first

Zones cannot be drawn around assets nobody has listed, and firewall rules cannot be written for flows nobody has seen. Network drawings are often out of date. The first deliverable of a segmentation project is therefore an asset inventory and a communication matrix.

Build them passively. Some older controllers and embedded devices have fragile network stacks, and an ordinary IT scan can cause them to fault or stop communicating. In a running process, that is a safety and production risk. Passive sources include:

• traffic captured from SPAN ports or taps, over a period long enough to include batch, shift and maintenance cycles
• switch, firewall and router configurations, MAC address tables and ARP tables
• controller project files and engineering workstation configurations
• physical walkdowns of cabinets and network panels

Active queries have a place later. Use native industrial protocols, run them selectively against device types that have been tested, and schedule them in maintenance windows with operations present.

A sequence for the work

1. Discover assets and flows passively. Produce the inventory and the communication matrix.
2. Define zones and conduits, and set target security levels through a risk assessment with operations and safety staff.
3. Build the DMZ and move cross-boundary flows into it one at a time, starting with the historian.
4. Run new firewall rules in log-only mode, review the results against the matrix, then enforce.
5. Bring remote access under the brokered model and remove the paths found in discovery.
6. Segment inside OT by line, cell or area, and isolate safety systems.
7. Deploy monitoring at the conduits and inside the zones.

Every change goes through the plant's management of change process.

Onion Infosec carries out this work within its OT service line.