OT/SCADA Network Segmentation and the Purdue Model

Industrial networks are now connected to enterprise IT for reporting and remote support, which means a compromised office laptop is one hop away from a PLC. The standard answer is segmentation by the Purdue model: separate levels for field devices, control, plant operations, DMZ and enterprise, with a small number of documented conduits between them. This article describes the levels, the conduits that actually carry traffic, and the firewall rules that cut east-west movement without breaking the plant.

The Purdue Levels in Practice

• Level 0 - sensors and actuators: hard-wired or fieldbus, mostly without IP.
• Level 1 - controllers: PLCs, RTUs, safety systems. Never routed to directly from IT.
• Level 2 - supervisory: HMI, SCADA servers, engineering workstations. Most OT traffic lives here.
• Level 3 - site operations: historian, patch and asset management, plant domain services.
• Level 3.5 - industrial DMZ: the only place where traffic crosses between OT and IT, and it holds replicated data rather than live control traffic.
• Levels 4-5 - enterprise IT and cloud.

The single most important architectural rule is that Levels 0-2 are not addressed from Levels 4-5. Anything that needs to cross goes through replicated data in the DMZ.

Zones and Conduits

Model each Purdue level as a zone with a defined security policy, and define conduits as the specific, documented, authenticated paths between zones. Two conduits carry most of the legitimate traffic: historian replication from Level 3 to the DMZ, and remote access for vendors.

# plant edge firewall - illustrative policy for the OT/IT boundary
zone OT-L2 { interface ethernet1/3 }
zone OT-L3 { interface ethernet1/4 }
zone IDMZ  { interface ethernet1/5 }
zone IT    { interface ethernet1/6 }

# OT L2 never talks to IT
rule OT-L2 to IT { action deny }

# L2 talks to L3 only for the protocols the plant needs
rule OT-L2 to OT-L3 {
  source any
  application [ opc-ua modbus sip-plant ]
  action allow
  log-end yes
}

# Historian replication crosses to the DMZ, initiated by the OT side only
rule OT-L3 to IDMZ {
  application [ opc-ua ssl sql ]
  action allow
}

# IT pulls from the DMZ only
rule IT to IDMZ { application [ ssl http-8080 ] action allow }

Rules like this are intentionally narrow: only the protocols the plant genuinely uses, and only in the direction that makes sense. If your firewall cannot classify OT protocols, fall back to explicit TCP/UDP port lists and document that they are an approximation of the protocol set.

Remote Vendor Access Without Opening the Plant

• Terminate vendor sessions in the DMZ on a jump host, authenticate with MFA and a named account per engineer.
• Broker the session through a proxy so the vendor never gets a routable path to Level 2 - see the pattern in ZTNA vs VPN for remote access.
• Record the sessions and keep the recordings for the retention period your regulators require; this is what makes an incident review possible weeks later.
• Disable local accounts on engineering workstations once central identity works, and audit them quarterly.

Monitoring and Detection

# passive asset tracking and anomaly detection on a SPAN port
# example: Zeek in promiscuous mode on the Level 2 span
docker run --net=host -d --name zeek-ot \
  -v /opt/zeek/logs:/usr/local/zeek/logs \
  zeek/zeek:latest zeek -i eth1

# what to alert on
# 1. any new MAC/IP pair on a Level 2 segment
# 2. PLC programming traffic from an unexpected source
# 3. outbound DNS from a PLC subnet
# 4. SMB or RDP from OT to IT, ever

A passive sensor on Level 2 is safe - it does not participate in plant traffic - and it is the only way to learn what the plant actually talks to before you tighten rules.

Implementation Order

• Diagram the current plant network and label each device with its Purdue level. Expect gaps; undocumented flat networks are the norm.
• Deploy passive monitoring for two to four weeks and export a traffic matrix: who talks to whom, on which ports.
• Build the DMZ, then move replication and remote access into it before tightening anything else.
• Tighten Level 2 to Level 3 rules in monitoring mode first, then enforce during a planned outage window.
• Document the conduits, and treat any new one as a change requiring review.

References and related reading: NIST SP 800-82r3 for the security programme itself, plus the firewall hygiene principles in VDOM partitioning on FortiGate and zone-based firewall policy on Cisco IOS for the platforms commonly used at the OT/IT boundary.

原文链接：https://csrc.nist.gov/pubs/sp/800/82/r3/final