At the audit of the petrochemical plant last year, we found Modbus/TCP traffic from the Siemens S7-1200 and HMI panels in the same VLAN with an enterprise file server. From the compromised laptop of the contractor in the IT segment to the recording of the held values in the controller-registers - 47 minutes, two leaky ACE rules on the transit firewall and not a single ailet in SIEM. It's not an anomaly. This is a typical state of OT infrastructure, where segmentation of industrial networks is drawn in Visio, and in practice Level 2 and Level 3 Purdue Model merged into one flat subnet.
Purdue Model Industrial Networks: Areas of Trust and Where They Collapse
Purdue Enterprise Reference Architecture (PERA) divides the infrastructure of an industrial enterprise into levels of 0 to 5. According to Palo Alto Networks, the levels 0-3 are OT-side (physical processes, controllers, SCADA), 4–5 are IT-side (ERP, mail, internet). Between them - DMZ at level 3.5, added later as a buffer zone.
The model defines zones and conduits - communication channels between zones. Conduit should be protected at the level of the most critical zone it connects. Po IEC 62443 Each zone receives its own security policy, and conduit receives a set of filtering rules. It's beautiful on paper. On the set, it's different.
Levels 0–3: OT-territories
Level 0 - physical process: temperature sensors, pressure, flow, actuators (valov, pumps). Operate on an analog signal of 4-20 mA or digital tyres (HART, Foundation Fieldbus). There is usually no direct IP connection, but the attacker with access to Level 1 controls them through the controller.
Level 1 - controllers: PLC (Siemens S7, Rockwell ControlLogix, Schneider Modicon), RTU. Most PLCs work on firmware ten years ago, do not support encryption and do not have an authentication mechanism. Modbus/TCP on port 502 receive commands from any IP address without verification. Just accepts - and performs.
Level 2 - SCADA/HMI: operator stations, local SCADA servers. The operator sees the mnemonic scheme of the process and makes the settings. On the real facilities Level 2 and Level 3 regularly find themselves in the same subnet - it is easier for engineers when the hanger stands next to the HMI without an additional firewall between them. “Temporary” for three years.
Level 3 - site management: MES, plant-wide historians (OSIsoft PI, Wonderware Historian), alerates servers. According to Dragos, the history server on Level 3 is the most frequent vector of bypassing the boundary between IT and OT. Corporate users connect to it to unload reports via SMB, OPC DA/UA or proprietary protocols, creating direct conduit bypassing DMZ.
Level 3.5: DMZ for ICS systems
Level 3.5 was not part of the original Purdue Model, but according to Palo Alto Networks is now considered mandatory. DMZ works like a buffer: data flow between IT and OT, but with filtering and monitoring.
Proper implementation of DMZ for ICS systems:
• In DMZ there is a mirror-horicer server (replica), not the original
• Traffic from IT goes only to replica in DMZ, not directly to OT-hisonic
• Single-directed gateways (data diodes) - Waterfall Security, Owl Cyber Defense - transmit data from OT to DMZ at the hardware level without the possibility of a return channel
• The firewall between Level 3 and Level 3.5 allows outgoing from history replica, but blocks OT members
In practice, I see another thing: the historian is in the same segment with HMI, analysts go to it on the RDP from the corporate network, and "DMZ" - VLAN-tag on a common switch without ACL. Formally, there is a DMZ. In fact, no.
Levels 4–5: IT-territory and entry points
Level 4 - business systems: ERP, CRM, AD, corporate mail. Standard IT threats: phishing, credential stuffing, AD-attacks.
Level 5 - Internet, cloud services, VPN gateways for contractors.
The error I meet regularly: the contractor’s VPN lands immediately on Level 2 – to the engineering station, bypassing the DMZ. According to MITRE ATT&CK is Trusted Relationship (T1199, Initial Access): the attacker compromises the contractor and receives a direct route to the OT segment. The same way is used by External Remote Services (T1133, Initial Access/Persistence) - RDP or SSH to industrial hosts through a tunneled VPN.
How OT Threats Differ from IT at the level of protective measures
Standard IT-stove - EDR on endpoints, SIEM for correlation, NGFW on the perimeter - in the OT environment either irreplaceable or creates new risks. The difference is not in the scale of threats, but in the fundamental properties of the environment.
Protocols without authentication and encryption
Modbus/TCP The 1979 protocol. No authentication, no encryption, no integrity check. The record command in the register - FC6 (Write Single Register), FC16 (Write Multiple Registers) - is performed by the controller without questions. Any host in one segment with PLC sends FC5 (Write Single Coil) and switches a discrete exit - opens the valve, turns on the pump. FC3 (Read Holding Registers) - reading, for the process is harmless, but gives the attacker a full map of the settings.
DNP3 - Protocol for energy and water. Supports Secure Authentication since the SA v5 version, but the vast majority of installations work without it. Because “and works like that.”
IEC 60870-5-104 - Telemechanics protocol, the standard in European and Russian energy, operates on top of TCP/IP. This is the protocol that used Industroyer/CrashOverride malvar to disable power substations - the attackers sent legitimate commands, and the equipment performed them, because the protocol does not distinguish between the operator and the attacker. The team is a team.
TRITON (TRISIS) - the only publicly known malware aimed at Safety Instrumented Systems (SIS). The goal was Schneider Electric Triconex controllers. The attacker reached the SIS controller through the network because the SIS segment was not isolated from DCS. The lesson is rigid: segmentation between safety systems and DCS is a separate requirement, not a “pleasant addition.”
Why standard EDR and SIEM are blind in the SCADA network
To monitor OT networks, specialized solutions are needed: Claroty, Nozomi Networks, Dragos. They work passively - listen to the SPAN port or TAP, dismantle industrial protocols to the level of individual functions codes and tags without generating traffic to the network. They build a baseline normal behavior and alerate to deviations: a new IP sent the Modbus-team, there was a FC16 from the host, which used only FC3.
Kill chain with binding to MITRE ATT&CK
[Applicable: Internal Pentest, Grey Box with Access to IT Segment]
Step 1. Initial access. Phishing Letter or Stolen Contractor's VPN Account - Valid Accounts (T1078, Initial Access) The attacker receives the RDP to the workstation at Level 4/5.
Step 2. Discovery. From the IT segment is found - history is visible through DNS or AD, often with the characteristic hostname (PI-HISTORIAN, HIST-01). Network Service Discovery (T1046, Discovery) If the hanger uses OPC UA on the port 4840 or PI Web API at 443, it is in seconds.
Step 3. Lateral movement through the hangarch. Historian on Level 3 / Level 3.5 is available from IT for unloading reports. The attacker connects via SMB, OPC UA or RDP - Exploitation of Remote ServicesT1210, Lateral Movement) Service accounts of the historian with passwords that have not changed for years are a standard find. On one object, the password from the PI-server was pi_admin2016. 2016 year. Audit 2024.
Step 4. Pivot in OT. The history servers are visible to HMI and SCADA at Level 2. If Level 2 and Level 3 are not separated by a firewall (typical situation - "slip" levels), the object movement is trivial. Often enough ARP query to see the entire network. Adversary-in-the-Middle (T1557, Credential Access) allows you to intercept OPC-sessions.
Step 5. Impact on the process. With HMI or directly from the Level 1-2 network, the attacker sends Modbus teams to the PLC. One TCP-package pack with FC6 is enough to change the setting.
Fingerprinting OT assets from IT segment
Adjustments to the environment:
• OS: Kali Linux or any OS with nmap ≥7.80 and installed NSE scripts
• RAM: minimum 2 GB
• Network: access to the OT segment via jump host in DMZ or direct route (if DMZ is missing)
• Coordination: written permission from the owner of the ACS TP, the presence of the engineer on the site, readiness for manual reboot PLC
Key restriction: An active scan can disable legacy-PLC. On one project, the scanning of the port 102 (S7comm) on the Siemens S7-300 led to the Flue of the CPU - the controller was rebooted manually, 20 minutes of downtime of the site. The AIJ engineer was, to put it mildly, dissatisfied.
# 44818 - EtherNet/IP (Rockwell)
When the technique is NOT working: even a polite scan is risky for Siemens S7-300 and Schneider Quantum series devices manufactured before 2010. During an OT network penetration test, each scan must be agreed upon with the ACS engineer in advance. Do not proceed without approval.
After detecting Modbus devices—identification without modifying conditions:
FC43 sub-function 14 (Read Device Identification) - a standard Modbus diagnostic function, does not change registers and does not affect the control logic. It's reading, not a record.
According to ON2IT, the classic Purdue Model relies on wide horizontal levels - all PLCs in Level 1, all HMI in Level 2. There is no insulation inside. The attacker caught on Level 2, sees all HMI and SCADA servers of this level. Zero Trust offers segmentation by protect surfaces - vertical columns tied to specific business processes.
Protect surfaces instead of horizontal layers
Instead of grouping all PLCs into one Level 1, highlight the support for each critical process:
• Reactor circuit : temperature sensors + PLC + HMI reactor - separate microsegment
• Water treatment contour : its sensors, controller, HMI - insulated segment
• BAS (Building Automation): HVAC, Lighting, Energy Management - Physically Separately from Production Network
According to ON2IT, HMI for temperature monitoring should not have a network connectivity to the PLC that controls the robotic line. With Purdue-approach, both devices on Level 2 - in one segment. With Zero Trust - in different protect surfaces with separate politicians.
According to Zscaler, it is the granularity at the level of individual assets, and not the network segments, that distinguishes Zero Trust from the classic Purdue segmentation.
Where Zero Trust breaks down in OT
According to GuidePoint Security, Purdue 2.0 does not replace the Purdue Model with Zero Trust, but complements: horizontal levels are stored as a frame, inside them - granular microsegmentation and continuous monitoring.
Compensating measures for legacy-environment
When Zero Trust is not possible (and in OT it is almost always possible), there is a set of measures that compensate for the lack of authentication and encryption at the protocol level.
Microsegmentation at the network level. Each PLC or PLC group of one process - in a separate VLAN with an industrial firewall. Fortinet FortiGate with OT profiles and Cisco ISA 3000 are able to inspect Modbus/TCP to function codes: allow FC3 (Read) from SCADA, block FC5/FC6/FC16 (Write) from any host except for an authorized engineering station. Settings are not fast, but it works.
Unidirectional locks. Waterfall Security, Owl Cyber Defense - hardware guarantee of a one-way data stream from OT to IT. Reverse traffic is physically impossible. Closes the vector of the lateral movement through the historicalplica.
Passive monitoring. Claroty, Nozomi, Dragos on SPAN/TAP: baseline normal behavior + alerates for deviations (new Modbus client, FC16 from an atypical source, firmware loading into PLC). Doesn’t generate traffic to the industry network, and that’s fundamental.
Control of engineering stations. Engineering workstations are the only hosts to load firmware in PLC. Physical insulation, OT connection only for the duration of work, blocked USB ports, monitoring sessions. Disable or Modify System FirewallT1686, Defense Evasion) at the engineering station - red flag, level P1. If someone turned off the firewall on engineering worktation, it's either a mulby engineer or an attacker. In both cases, deal immediately.
Purdue Model Industrial Networks: Areas of Trust and Where They Collapse
Purdue Enterprise Reference Architecture (PERA) divides the infrastructure of an industrial enterprise into levels of 0 to 5. According to Palo Alto Networks, the levels 0-3 are OT-side (physical processes, controllers, SCADA), 4–5 are IT-side (ERP, mail, internet). Between them - DMZ at level 3.5, added later as a buffer zone.
The model defines zones and conduits - communication channels between zones. Conduit should be protected at the level of the most critical zone it connects. Po IEC 62443 Each zone receives its own security policy, and conduit receives a set of filtering rules. It's beautiful on paper. On the set, it's different.
Levels 0–3: OT-territories
Level 0 - physical process: temperature sensors, pressure, flow, actuators (valov, pumps). Operate on an analog signal of 4-20 mA or digital tyres (HART, Foundation Fieldbus). There is usually no direct IP connection, but the attacker with access to Level 1 controls them through the controller.
Level 1 - controllers: PLC (Siemens S7, Rockwell ControlLogix, Schneider Modicon), RTU. Most PLCs work on firmware ten years ago, do not support encryption and do not have an authentication mechanism. Modbus/TCP on port 502 receive commands from any IP address without verification. Just accepts - and performs.
Level 2 - SCADA/HMI: operator stations, local SCADA servers. The operator sees the mnemonic scheme of the process and makes the settings. On the real facilities Level 2 and Level 3 regularly find themselves in the same subnet - it is easier for engineers when the hanger stands next to the HMI without an additional firewall between them. “Temporary” for three years.
Level 3 - site management: MES, plant-wide historians (OSIsoft PI, Wonderware Historian), alerates servers. According to Dragos, the history server on Level 3 is the most frequent vector of bypassing the boundary between IT and OT. Corporate users connect to it to unload reports via SMB, OPC DA/UA or proprietary protocols, creating direct conduit bypassing DMZ.
Level 3.5: DMZ for ICS systems
Level 3.5 was not part of the original Purdue Model, but according to Palo Alto Networks is now considered mandatory. DMZ works like a buffer: data flow between IT and OT, but with filtering and monitoring.
Proper implementation of DMZ for ICS systems:
• In DMZ there is a mirror-horicer server (replica), not the original
• Traffic from IT goes only to replica in DMZ, not directly to OT-hisonic
• Single-directed gateways (data diodes) - Waterfall Security, Owl Cyber Defense - transmit data from OT to DMZ at the hardware level without the possibility of a return channel
• The firewall between Level 3 and Level 3.5 allows outgoing from history replica, but blocks OT members
In practice, I see another thing: the historian is in the same segment with HMI, analysts go to it on the RDP from the corporate network, and "DMZ" - VLAN-tag on a common switch without ACL. Formally, there is a DMZ. In fact, no.
Levels 4–5: IT-territory and entry points
Level 4 - business systems: ERP, CRM, AD, corporate mail. Standard IT threats: phishing, credential stuffing, AD-attacks.
Level 5 - Internet, cloud services, VPN gateways for contractors.
The error I meet regularly: the contractor’s VPN lands immediately on Level 2 – to the engineering station, bypassing the DMZ. According to MITRE ATT&CK is Trusted Relationship (T1199, Initial Access): the attacker compromises the contractor and receives a direct route to the OT segment. The same way is used by External Remote Services (T1133, Initial Access/Persistence) - RDP or SSH to industrial hosts through a tunneled VPN.
How OT Threats Differ from IT at the level of protective measures
Standard IT-stove - EDR on endpoints, SIEM for correlation, NGFW on the perimeter - in the OT environment either irreplaceable or creates new risks. The difference is not in the scale of threats, but in the fundamental properties of the environment.
Protocols without authentication and encryption
Modbus/TCP The 1979 protocol. No authentication, no encryption, no integrity check. The record command in the register - FC6 (Write Single Register), FC16 (Write Multiple Registers) - is performed by the controller without questions. Any host in one segment with PLC sends FC5 (Write Single Coil) and switches a discrete exit - opens the valve, turns on the pump. FC3 (Read Holding Registers) - reading, for the process is harmless, but gives the attacker a full map of the settings.
DNP3 - Protocol for energy and water. Supports Secure Authentication since the SA v5 version, but the vast majority of installations work without it. Because “and works like that.”
IEC 60870-5-104 - Telemechanics protocol, the standard in European and Russian energy, operates on top of TCP/IP. This is the protocol that used Industroyer/CrashOverride malvar to disable power substations - the attackers sent legitimate commands, and the equipment performed them, because the protocol does not distinguish between the operator and the attacker. The team is a team.
TRITON (TRISIS) - the only publicly known malware aimed at Safety Instrumented Systems (SIS). The goal was Schneider Electric Triconex controllers. The attacker reached the SIS controller through the network because the SIS segment was not isolated from DCS. The lesson is rigid: segmentation between safety systems and DCS is a separate requirement, not a “pleasant addition.”
Why standard EDR and SIEM are blind in the SCADA network
To monitor OT networks, specialized solutions are needed: Claroty, Nozomi Networks, Dragos. They work passively - listen to the SPAN port or TAP, dismantle industrial protocols to the level of individual functions codes and tags without generating traffic to the network. They build a baseline normal behavior and alerate to deviations: a new IP sent the Modbus-team, there was a FC16 from the host, which used only FC3.
Kill chain with binding to MITRE ATT&CK
[Applicable: Internal Pentest, Grey Box with Access to IT Segment]
Step 1. Initial access. Phishing Letter or Stolen Contractor's VPN Account - Valid Accounts (T1078, Initial Access) The attacker receives the RDP to the workstation at Level 4/5.
Step 2. Discovery. From the IT segment is found - history is visible through DNS or AD, often with the characteristic hostname (PI-HISTORIAN, HIST-01). Network Service Discovery (T1046, Discovery) If the hanger uses OPC UA on the port 4840 or PI Web API at 443, it is in seconds.
Step 3. Lateral movement through the hangarch. Historian on Level 3 / Level 3.5 is available from IT for unloading reports. The attacker connects via SMB, OPC UA or RDP - Exploitation of Remote ServicesT1210, Lateral Movement) Service accounts of the historian with passwords that have not changed for years are a standard find. On one object, the password from the PI-server was pi_admin2016. 2016 year. Audit 2024.
Step 4. Pivot in OT. The history servers are visible to HMI and SCADA at Level 2. If Level 2 and Level 3 are not separated by a firewall (typical situation - "slip" levels), the object movement is trivial. Often enough ARP query to see the entire network. Adversary-in-the-Middle (T1557, Credential Access) allows you to intercept OPC-sessions.
Step 5. Impact on the process. With HMI or directly from the Level 1-2 network, the attacker sends Modbus teams to the PLC. One TCP-package pack with FC6 is enough to change the setting.
Fingerprinting OT assets from IT segment
Adjustments to the environment:
• OS: Kali Linux or any OS with nmap ≥7.80 and installed NSE scripts
• RAM: minimum 2 GB
• Network: access to the OT segment via jump host in DMZ or direct route (if DMZ is missing)
• Coordination: written permission from the owner of the ACS TP, the presence of the engineer on the site, readiness for manual reboot PLC
Key restriction: An active scan can disable legacy-PLC. On one project, the scanning of the port 102 (S7comm) on the Siemens S7-300 led to the Flue of the CPU - the controller was rebooted manually, 20 minutes of downtime of the site. The AIJ engineer was, to put it mildly, dissatisfied.
# 20000 - DNP3
# 44818 - EtherNet/IP (Rockwell)
When the technique is NOT working: even a polite scan is risky for Siemens S7-300 and Schneider Quantum series devices manufactured before 2010. During an OT network penetration test, each scan must be agreed upon with the ACS engineer in advance. Do not proceed without approval.
After detecting Modbus devices—identification without modifying conditions:
FC43 sub-function 14 (Read Device Identification) - a standard Modbus diagnostic function, does not change registers and does not affect the control logic. It's reading, not a record.
According to ON2IT, the classic Purdue Model relies on wide horizontal levels - all PLCs in Level 1, all HMI in Level 2. There is no insulation inside. The attacker caught on Level 2, sees all HMI and SCADA servers of this level. Zero Trust offers segmentation by protect surfaces - vertical columns tied to specific business processes.
Protect surfaces instead of horizontal layers
Instead of grouping all PLCs into one Level 1, highlight the support for each critical process:
• Reactor circuit : temperature sensors + PLC + HMI reactor - separate microsegment
• Water treatment contour : its sensors, controller, HMI - insulated segment
• BAS (Building Automation): HVAC, Lighting, Energy Management - Physically Separately from Production Network
According to ON2IT, HMI for temperature monitoring should not have a network connectivity to the PLC that controls the robotic line. With Purdue-approach, both devices on Level 2 - in one segment. With Zero Trust - in different protect surfaces with separate politicians.
According to Zscaler, it is the granularity at the level of individual assets, and not the network segments, that distinguishes Zero Trust from the classic Purdue segmentation.
Where Zero Trust breaks down in OT
According to GuidePoint Security, Purdue 2.0 does not replace the Purdue Model with Zero Trust, but complements: horizontal levels are stored as a frame, inside them - granular microsegmentation and continuous monitoring.
Compensating measures for legacy-environment
When Zero Trust is not possible (and in OT it is almost always possible), there is a set of measures that compensate for the lack of authentication and encryption at the protocol level.
Microsegmentation at the network level. Each PLC or PLC group of one process - in a separate VLAN with an industrial firewall. Fortinet FortiGate with OT profiles and Cisco ISA 3000 are able to inspect Modbus/TCP to function codes: allow FC3 (Read) from SCADA, block FC5/FC6/FC16 (Write) from any host except for an authorized engineering station. Settings are not fast, but it works.
Unidirectional locks. Waterfall Security, Owl Cyber Defense - hardware guarantee of a one-way data stream from OT to IT. Reverse traffic is physically impossible. Closes the vector of the lateral movement through the historicalplica.
Passive monitoring. Claroty, Nozomi, Dragos on SPAN/TAP: baseline normal behavior + alerates for deviations (new Modbus client, FC16 from an atypical source, firmware loading into PLC). Doesn’t generate traffic to the industry network, and that’s fundamental.
Control of engineering stations. Engineering workstations are the only hosts to load firmware in PLC. Physical insulation, OT connection only for the duration of work, blocked USB ports, monitoring sessions. Disable or Modify System FirewallT1686, Defense Evasion) at the engineering station - red flag, level P1. If someone turned off the firewall on engineering worktation, it's either a mulby engineer or an attacker. In both cases, deal immediately.