How the response to incidents of ICS SCADA differs from IT
Responding to incidents in industrial networks is based on another model of priorities. In the IT classic - CIA (Confidentiality, Integrity, Availability). In OT - Safety, Availability, Integrity, and only then Confidentiality. It does not theoretically differ - it determines each decision during the incident.
Protocols without authentication
Modbus TCP Originally from 1979. There is no built-in authentication. Any node in the segment capable of sending a TCP pack to port 502 can record arbitrary values in the PLC registers. FC 0x05 (Write Single Coil) switches discrete output - valve, pump, speaker. FC 0x06 (Write Single Register) changes the numerical value - temperature string, speed drive. EDR and antivirus do not see these teams: a legitimate TCP connection between legitimate hosts, what else is needed.
DNP3 in the energy sector formally supports Secure Authentication (SA). In practice, most installations work without it - the inclusion of SA requires re-shouldering RTU, and this is a planned stoppage. According to the documents, you can include. In practice, no one includes.
Why standard EDR and SIEM are blind in the SCADA environment
On the PLC Siemens S7-300/400, there is no operating system in the usual sense - agent CrowdStrike Falcon or SentinelOne will not physically stand there. Allen-Bradley ControlLogix works on a proprietary OS, third-party processes do not support. RTU based on the Modbus RTU (RS-485) is a microcontroller with a firmware of tens of kilobytes. What an EDR.
SIEM receives events from the IT segment: Windows, NetFlow, DNS-queries. Traffic between HMI and PLC level 2 Purdue models does not fall into the corporate SIEM unless a specialized collection is configured - through Zeek with plugins for industrial protocols, Nozomi Networks or Claroty. Without it, the OT segment for SOC is a black box.
Pattage restrictions
According to IBM X-Force, the average time between the publication of CVE and elimination in organizations is 29 months. For OT, that number is even worse. In many productions, PLCs work on firmware ten to fifteen years ago. Updating the firmware of the Schneider Modicer M340 controller is the stop of the managed site, transfer to manual control, verification after reboot. Planned window - once a year with overhaul. Once a year, Carl.
Forenzika PLC and RTU in industrial systems
Flanek PLC in industrial systems is not the same as working with a Windows host. You can not remove the image of the disk - there is no disc. You can not run Volatility - the memory format is proprietary. Each step of collecting artifacts carries the risk of disruption of the technological process.
What to collect and in what order
The procedure for collecting volatile data in OT - from the least invasive actions to the most:
1. Network traffic (passive grip). Mirror of the port on a controlled level 2 switch (SPAN/mirror port) and pcap recording via tcpdumpor Zeek. PLC does not affect, the additional load on the industrial network does not create. We always start with this.
2. The story-server logs. OSIsoft PI, Wonderware InSQL, GE Proficy Historian keep historical values of tags (process) with time labels. Changing the setting, mode switching, emergency stop - everything is reflected in the historian. To establish a timeline incident, this is gold.
3. The Condition of the PLC Program. Unloading of the current program (ladder logic, structured text, FBD) through engineering software - TIA Portal for Siemens, RSlogix/Studio 5000 for Allen-Bradley, Unity Pro for Schneider. Next is a comparison with a reference copy from the change management system.
4. Configuration of network equipment. MAC addresses tables, ARP-cache, ACL rules on industrial switches (Hirschmann, Moxa, Cisco IE). Here you can find unauthorized devices that should not be.
Verification of PLC logic
A key and unique step for OT is to check the integrity of the management program. The attacker who has access to the engineering station can modify the logic of the PLC so that the operator on HMI will not see changes - the values on the screen will be replaced by the Transmitted Data Manipulation, T1565.002, impact). This is how TRITON worked - the malware modified the logic of the Schneider Triconex security controller, while the engineering software showed a "clean" program. A beautiful wrappy, and inside - overpromailed logic.
Verification - a byte comparison of the unloaded program with the reference. For Siemens S7, this is a comparison of the OB, FC, FB, DB blocks with saved copies. For Allen-Bradley - comparison. ACD files via the RSLogix diff-utility. If there are no reference copies (and they are not more often than we would like) - you can restore the fact of modification by the lists-server, analyzing abnormal deviations of process values from baseline.
Analysis of network traffic of industrial protocols
The pcap with industrial traffic is the main method of forensic RTU and industrial controllers that do not support local collection of artifacts. Zeek (formerly Bro) with modules for Modbus, DNP3 and S7comm gives structured logs of each transaction.
Filter in tshark to identify the Modbus write-commensions that should not be normally:
Bash:
tshark -r ot_capture.pcap -Y "modbus.func_code == 5 || modbus.func_code == 6 || modbus.func_code == 15 || modbus.func_code == 16" \
-T fields -e frame.time -e ip.src -e ip.dst -e modbus.func_code -e modbus.reference_num
We pull out all the write-operations (FC 5, 6, 15, 16) with time stamps, source/purpose addresses and register numbers. In the normal mode, write-commands are generated only from engineering stations and only during routine work. Any write from the new IP is analt.
Detection-checklist: Correlation Rules for OT SOC
Reaction to incidents in the OT environment begins long before the incident - with the construction of a baseline and the rules of correlation. Below is a checklist that can be adapted for a specific SIEM-sweet.
Basic rules for Modbus TCP
Building a baseline for industrial protocols
Baseline in OT is not “average traffic per week”. The industrial process is cyclical: morning line start, daytime mode, night simple. Baseline is built according to several parameters:
• List of pairs "initiator - PLC" with reference to function codes. HMI interviews through FC 0x03 every 500 ms - this is the norm. The engineering station is connected for programming once a quarter.
• The ranges of values of process variables. Temperature in reactor 180-220°C, pressure 2.5-3.2 bar. The way out of range without the operator's command is an anomaly.
• Schedule of routine works. Each connection of the engineering station to the PLC off-schedule is an event for the investigation.
Scale: in medium chemical production - 3000-5000 tags in history. Building baseline takes 2-4 weeks of observing a “clean” environment. Without this investment, the detection in OT does not work. At all.
Scenario: cyber incident at an industrial enterprise through a compromised engineering station
Typical kill running attacks on an OT-segment with a TTPs-linked - this is exactly what most of the incidents I have seen in the investigations look like.
Kill chain from DMZ to PLC
Step 1. Initial Access - IT-segment. Phishing letter with attachment, sent to the engineer of the ACS TP. According to Verizon DBIR 2025, phishing is a vector of initial access in 36% of incidents. Malvar is assigned to the work station of the engineer in the corporate network. It's banal, but it works.
Step 2. Lateral Movement - Move to DMZ. The attacker exploits vulnerability in the jump server between IT and OT (T1210, Exploitation of Remote Services) According to CrowdStrike, the average time of the lateral movement after the initial access is 62 minutes. In the OT-context of the jump-server, often the only transition point, and its compromising opens access to the entire industrial segment.
Step 3. Credential Access in OT. At the engineering station in the OT segment, the attacker finds the saved passwords to TIA Portal, RSLogix, VNC-sessions to HMI (T1078.001, Default Accounts). Accounts to PLC are often linked in open-ended project files or protected by default passwords. admin/admin - not a joke, but a reality on half of the objects.
Step 4. Impact - modification of logic. The attacker uses legitimate engineering software to download the modified program in PLC. In terms of network traffic is a standard programming operation. From the point of view of the process - changing the settings, disconnecting locks, changes in values to HMI (T1565.002).
Where to Detect Each Step
Not every step of this chain can be detected in OT – and the Blue Team should understand this. Steps 1-2 are detected by standard IT tools: EDR (CrowdStrike Falcon, SentinelOne) on workstations, SIEM-rules on abnormal connections to the jump server. Step 3 requires the audit of logs at engineering stations (Windows Security Event Log, Event ID 4624/4625) and monitoring of the launch of engineering software off schedule. Step 4 - only through OT traffic analysis: detection of write/upload commands in industrial protocols.
That is why the engineering station is the most critical asset. This is the only host in the OT segment that an EDR agent can be installed and from which you collect logs in SIEM. Compromise of the engineering station = SOC blindness in OT.
Responding to incidents in industrial networks is based on another model of priorities. In the IT classic - CIA (Confidentiality, Integrity, Availability). In OT - Safety, Availability, Integrity, and only then Confidentiality. It does not theoretically differ - it determines each decision during the incident.
Protocols without authentication
Modbus TCP Originally from 1979. There is no built-in authentication. Any node in the segment capable of sending a TCP pack to port 502 can record arbitrary values in the PLC registers. FC 0x05 (Write Single Coil) switches discrete output - valve, pump, speaker. FC 0x06 (Write Single Register) changes the numerical value - temperature string, speed drive. EDR and antivirus do not see these teams: a legitimate TCP connection between legitimate hosts, what else is needed.
DNP3 in the energy sector formally supports Secure Authentication (SA). In practice, most installations work without it - the inclusion of SA requires re-shouldering RTU, and this is a planned stoppage. According to the documents, you can include. In practice, no one includes.
Why standard EDR and SIEM are blind in the SCADA environment
On the PLC Siemens S7-300/400, there is no operating system in the usual sense - agent CrowdStrike Falcon or SentinelOne will not physically stand there. Allen-Bradley ControlLogix works on a proprietary OS, third-party processes do not support. RTU based on the Modbus RTU (RS-485) is a microcontroller with a firmware of tens of kilobytes. What an EDR.
SIEM receives events from the IT segment: Windows, NetFlow, DNS-queries. Traffic between HMI and PLC level 2 Purdue models does not fall into the corporate SIEM unless a specialized collection is configured - through Zeek with plugins for industrial protocols, Nozomi Networks or Claroty. Without it, the OT segment for SOC is a black box.
Pattage restrictions
According to IBM X-Force, the average time between the publication of CVE and elimination in organizations is 29 months. For OT, that number is even worse. In many productions, PLCs work on firmware ten to fifteen years ago. Updating the firmware of the Schneider Modicer M340 controller is the stop of the managed site, transfer to manual control, verification after reboot. Planned window - once a year with overhaul. Once a year, Carl.
Forenzika PLC and RTU in industrial systems
Flanek PLC in industrial systems is not the same as working with a Windows host. You can not remove the image of the disk - there is no disc. You can not run Volatility - the memory format is proprietary. Each step of collecting artifacts carries the risk of disruption of the technological process.
What to collect and in what order
The procedure for collecting volatile data in OT - from the least invasive actions to the most:
1. Network traffic (passive grip). Mirror of the port on a controlled level 2 switch (SPAN/mirror port) and pcap recording via tcpdumpor Zeek. PLC does not affect, the additional load on the industrial network does not create. We always start with this.
2. The story-server logs. OSIsoft PI, Wonderware InSQL, GE Proficy Historian keep historical values of tags (process) with time labels. Changing the setting, mode switching, emergency stop - everything is reflected in the historian. To establish a timeline incident, this is gold.
3. The Condition of the PLC Program. Unloading of the current program (ladder logic, structured text, FBD) through engineering software - TIA Portal for Siemens, RSlogix/Studio 5000 for Allen-Bradley, Unity Pro for Schneider. Next is a comparison with a reference copy from the change management system.
4. Configuration of network equipment. MAC addresses tables, ARP-cache, ACL rules on industrial switches (Hirschmann, Moxa, Cisco IE). Here you can find unauthorized devices that should not be.
Verification of PLC logic
A key and unique step for OT is to check the integrity of the management program. The attacker who has access to the engineering station can modify the logic of the PLC so that the operator on HMI will not see changes - the values on the screen will be replaced by the Transmitted Data Manipulation, T1565.002, impact). This is how TRITON worked - the malware modified the logic of the Schneider Triconex security controller, while the engineering software showed a "clean" program. A beautiful wrappy, and inside - overpromailed logic.
Verification - a byte comparison of the unloaded program with the reference. For Siemens S7, this is a comparison of the OB, FC, FB, DB blocks with saved copies. For Allen-Bradley - comparison. ACD files via the RSLogix diff-utility. If there are no reference copies (and they are not more often than we would like) - you can restore the fact of modification by the lists-server, analyzing abnormal deviations of process values from baseline.
Analysis of network traffic of industrial protocols
The pcap with industrial traffic is the main method of forensic RTU and industrial controllers that do not support local collection of artifacts. Zeek (formerly Bro) with modules for Modbus, DNP3 and S7comm gives structured logs of each transaction.
Filter in tshark to identify the Modbus write-commensions that should not be normally:
Bash:
tshark -r ot_capture.pcap -Y "modbus.func_code == 5 || modbus.func_code == 6 || modbus.func_code == 15 || modbus.func_code == 16" \
-T fields -e frame.time -e ip.src -e ip.dst -e modbus.func_code -e modbus.reference_num
We pull out all the write-operations (FC 5, 6, 15, 16) with time stamps, source/purpose addresses and register numbers. In the normal mode, write-commands are generated only from engineering stations and only during routine work. Any write from the new IP is analt.
Detection-checklist: Correlation Rules for OT SOC
Reaction to incidents in the OT environment begins long before the incident - with the construction of a baseline and the rules of correlation. Below is a checklist that can be adapted for a specific SIEM-sweet.
Basic rules for Modbus TCP
Building a baseline for industrial protocols
Baseline in OT is not “average traffic per week”. The industrial process is cyclical: morning line start, daytime mode, night simple. Baseline is built according to several parameters:
• List of pairs "initiator - PLC" with reference to function codes. HMI interviews through FC 0x03 every 500 ms - this is the norm. The engineering station is connected for programming once a quarter.
• The ranges of values of process variables. Temperature in reactor 180-220°C, pressure 2.5-3.2 bar. The way out of range without the operator's command is an anomaly.
• Schedule of routine works. Each connection of the engineering station to the PLC off-schedule is an event for the investigation.
Scale: in medium chemical production - 3000-5000 tags in history. Building baseline takes 2-4 weeks of observing a “clean” environment. Without this investment, the detection in OT does not work. At all.
Scenario: cyber incident at an industrial enterprise through a compromised engineering station
Typical kill running attacks on an OT-segment with a TTPs-linked - this is exactly what most of the incidents I have seen in the investigations look like.
Kill chain from DMZ to PLC
Step 1. Initial Access - IT-segment. Phishing letter with attachment, sent to the engineer of the ACS TP. According to Verizon DBIR 2025, phishing is a vector of initial access in 36% of incidents. Malvar is assigned to the work station of the engineer in the corporate network. It's banal, but it works.
Step 2. Lateral Movement - Move to DMZ. The attacker exploits vulnerability in the jump server between IT and OT (T1210, Exploitation of Remote Services) According to CrowdStrike, the average time of the lateral movement after the initial access is 62 minutes. In the OT-context of the jump-server, often the only transition point, and its compromising opens access to the entire industrial segment.
Step 3. Credential Access in OT. At the engineering station in the OT segment, the attacker finds the saved passwords to TIA Portal, RSLogix, VNC-sessions to HMI (T1078.001, Default Accounts). Accounts to PLC are often linked in open-ended project files or protected by default passwords. admin/admin - not a joke, but a reality on half of the objects.
Step 4. Impact - modification of logic. The attacker uses legitimate engineering software to download the modified program in PLC. In terms of network traffic is a standard programming operation. From the point of view of the process - changing the settings, disconnecting locks, changes in values to HMI (T1565.002).
Where to Detect Each Step
Not every step of this chain can be detected in OT – and the Blue Team should understand this. Steps 1-2 are detected by standard IT tools: EDR (CrowdStrike Falcon, SentinelOne) on workstations, SIEM-rules on abnormal connections to the jump server. Step 3 requires the audit of logs at engineering stations (Windows Security Event Log, Event ID 4624/4625) and monitoring of the launch of engineering software off schedule. Step 4 - only through OT traffic analysis: detection of write/upload commands in industrial protocols.
That is why the engineering station is the most critical asset. This is the only host in the OT segment that an EDR agent can be installed and from which you collect logs in SIEM. Compromise of the engineering station = SOC blindness in OT.
