Critical infrastructure cyber risks assessment: methodology and frameworks for OT/ICS

Depov

Moderator
Staff member
MODERATOR
ULTIMATE
SUPREME
PREMIUM
MEMBER
Joined
Feb 18, 2025
Messages
242
Reaction score
305
Deposit
0$
At risk assessment substation 110 kV we found a history server route directly to the corporate network. VLANs existed, ACL between Level 3 and Level 4 according to Purdue - none. CVSS has shown a single known vulnerability on this server to 6.5, Medium. In IT-context - a reasonable priority below critical, you can wait for the service window. In the OT-context, through this attacker, the attacker received a direct channel to RTU, control the switching equipment. Physical impact - de-energization of the area for 40 thousand residents and the risk of damage to power equipment.

Between the formal assessment of Medium and the real scenario of cascade shutdown is a methodological gap that standard IT frameworks are not closed. This article is about how to assess the cyber risks of critical infrastructure so that the result reflects real threats rather than being a ritual for the auditor.
Why IT-approaches to the evaluation of cyber risks break down in OT environments
In IT security, the priority is privacy (CIA triad with an emphasis on C). In OT, the availability and integrity of the physical process are primary. Recording of garbage in register holding PLC via Modbus FC16 (Write Multiple Registers) is more dangerous than a terabyte leakage of corporate documents. The attacker who sent the FC5 (Write Single Coil) to the discrete output of the controller, physically switches the relay state - opens the valve, disconnects the pump, changes the protection line. It's not where the data is leaking, where iron moves
Modbus TCP, DNP3, PROFINET, EtherNet/IP - protocols designed for reliability and determinancy are not for safety. Modbus does not have authentication: any node with network access to port 502 can send FC16 and re-register PLC registers. DNP3 Secure Authentication exists, but in practice it is rare - most RTU in operation it simply does not support it.

For a pentester accustomed to the IT infrastructure, the OT environment looks like a network without a single defense. In a sense, it is: CrowdStrike Falcon, SentinelOne, Elastic - none of these EDR-agents are installed on the PLC Siemens S7-1200 or Allen-Bradley ControlLogix. SIEM receives logs from the top levels of Purdue (Level 3-5), and traffic between HMI and controller at Level 1-2 often remains invisible. In the corporate network endpoint without EDR - nonsense. In OT, this is the norm.

The IT team is accustomed to regular patching. In OT, the firmware update on the Safety Instrumented System (SIS) may require a complete process stop for several days. At real objects, there are controllers from firmware ten years ago - not because no one knows about vulnerabilities, but because the stop costs tens of millions of rubles and requires coordination with technologists for six months. Try to explain this to the IT director who is used to the monthly Patch Tuesday.

Three real incidents show how these differences lead to disasters.

Old Mars Water Treatment Station, Florida (February 2021): according to the official version of the FBI/CISA (A21-042A), the unknown got access via TeamViewer with a common password on the Windows 7 system and tried to increase the concentration of sodium hydroxide to potentially lethal levels. There was no segmentation of the OT network, no monitoring of industrial protocols. The operator noticed the movement of the cursor on the screen - and this was the only means of detection. (Note: Alternative investigations by KrebsOneSecurity and Reuters (2023) point to a possible operating error, not an external invasion – attribution remains controversial.)

Industroyer2 (April 2022): the malware discovered by ESET and CERT-UA (alert #4435), designed to control substations switches via IEC-101/104, was aimed at a specific Ukrainian energy company. The attack was neutralized before the impact stage, but the incident showed how difficult it is to restore the baseline OT security posture after compromise.

Colonial Pipeline (2021): DarkSide ransomware has penetrated legacy through a VPN account without an MFA, the props of which leaked earlier. The attack hit the IT bilging, not OT; the pipeline stop was a preventive decision of the company due to the inability to invoice. That is, the pipeline was not stopped by hackers - it was stopped by accountants.

All three cases have one thing in common: the formal risk assessment did not reflect the real vectors of attacks. The inventory was incomplete, the threat model did not take into account the OT specifics, and the impact assessment was built on IT metrics.
Cybersecurity frameworks OT and industrial systems
NIST CSF 2.0 and NIST SP 800-82: OT industrial safety
NIST CSF 2.0, released in February 2024, for the first time expanded the coverage beyond critical infrastructure and added the sixth function - Govern (GV). To manage the cyber risks of industrial systems, this is essential: Govern formalizes the intersection of surgical and cyber risk - the same dialogue that historically stalled, because engineering and information commands speak different languages.

Six functions of CSF 2.0 in the industrial context:
• Govern (GV) - OT-specific cybersecurity policy taking into account the requirements of the accessibility of the process. According to CSF 2.0 (GV.OC-01), the organization’s mission must inform cyber risks management. For OT, this means that the permissible level of risk is determined through physical consequences, and not through the cost of data.
• Identify (ID) is an inventory of OT assets (ID.AM-01). The starting point in IT is Active Directory. In OT networks can sit devices that have never been documented: the task of RTU, installed ten years ago, engineering stations on Windows XP.
• Protect (PR) - Identification management (PR.AA-01). In OT, it is a fight against shared at the accounts of engineering stations, the introduction of MFA for remote access and jump servers in the DMZ between IT and OT.
• Detect (DE) - baseline network operations (DE.AE-01) for industrial protocols. Anomaly in OT is not a massive login fail, but an unfamiliar function code in Modbus traffic or a change in polling periodicity.
• Respond (RS) - a command (RS.AN-01) in OT differs in principle: it is possible to isolate the infected controller, but the physical process can stop. The choice between "losing the controller" and "losing the process" is non-trivial.
• Recover (RC) - Recovery (RC.CO-01) includes a return to the correct state of the physical process, not just the data.
NIST SP 800-82 Rev.3 - guide companion for CSF, adapted for ICS. He recognizes the limitations of the OT environment: the inability of inline inspection on some segments, restrictions on the reboot of controllers, the need to coordinate with technologists before any changes. In general, the spectacle that does not pretend that OT is "the same IT, only with sensors."
IEC 62443: Zones, Conduits and Risk Assessment
Where NIST CSF gives the organizational structure, the IEC 62443 descends to the level of a particular architecture. Key concept - zones and confudes:
• Zone is a group of assets with the same Security Level (SL). Each zone has an SL of 1 (base protection against accidental violations) to 4 (protection from state actors with unlimited resources).
• Conduit is a communication channel between controlled traffic zones.
In practice, zoning over IEC 62443 is different from IT segmentation. In the corporate network, segments are determined by business functions, in OT zones are determined by the physical process and the required Security Level. PLC, which controls the reactor, and PLC on the packing line are different zones, even if both at Level 1 Purdue. Because the consequences of compromise are a little different scale.
The real risk assessment projects use a combination: NIST CSF 2.0 as an organizational framework for cybersecurity OT, IEC 62443 for architecture and zoning, NIST SP 800-82 to detail control. Binding to the Russian standard (FZ-187 "On the safety of CII", the orders of FSTEC 235/239) are added on top - but in itself a compliance-appe without an OT-specific model of threats generates paper security. The category of CII was assigned, the tick was placed, and the historian sticks to the corporate network without a single ACL.
Asset inventory in an isolated OT network
The assessment of cyber risks of critical infrastructure begins with an inventory - and it is here that most projects stumble. In IT can be launched nmap and get a picture for hours. In OT, active scanning can cause fault state to PLC - Siemens S7-300/400 series controllers can switch to STOP with an active S7comm survey or fuzzing industrial protocols (Digital Bond Project Basecamp, ICS-CERT ICSA-15-202-01). Put the controller with a scanner - they got the process stop. Not the best way to start a project.

Solution - passive monitoring of traffic. The Claroty, Nozomi Networks, Dragos Platform tools connect to the SPAN port of the switch and analyze traffic without sending a single package to the network. They deal with industrial protocols (Modbus, DNP3, S7comm, EtherNet/IP) and build an asset card with firmware versions and literature communication.

In one documented case (Shieldworkz, 2024), a large North American energy company found more than 2,400 previously unaccounted OT assets at the first passive scan. Two and a half thousand devices that were not in any CMDB record. Most sat on the operating room and worked silently for years.

Adjustments to the environment for passive monitoring:
• SPAN/mirror port managed on OT-segment switch
• Server/laptop: minimum 16 GB RAM, 4 CPU cores (capture at 1 Gbps speed)
• Wireshark with Dissectors of Industrial Protocols or specialized OT-tool
• Coordination with OT engineers: connection points, capture time, technological regulations
Wireshark display filter modbus show Unit ID of each slave-devices, function code and registry data. This gives a starting card: who communicates with whom, according to what protocol, what operations are performed. Already at this stage, surprises often surface - devices that communicate with what should not communicate with.
Threats Modeling and Attack Path Analysis
After the inventory, a threat model is built. For the OT environment, a modified STRIDE works, where each category is rethought through the physical process:
• Spoothing - Substitution of commands to the controller (attacking sends a legitimate function code on behalf of SCADA)
• Tampering - change of settings, PLC logic, calibration of sensors
• Repudiation - logging is often absent at Level 1-2 (what happened - no one knows)
• Information Disclosure - leakage engineering diagrams, relay settings (according to BigID, this information is often stored on unprotected file balls outside the OT circuit)
• Denial of Service - stopping the process through overflow of the controller buffer
• Elevation of Privilege - from the corporate network (Level 4-5) to OT (Level 1-3) through a compromised hanger
Typical chain of attack on OT through the prism of MITRE AT&CK:
1. Reconnaissance : Vulnerability Scanning (T1595.002) - detection of HMI-interventions and SCADA-portals on the perimeter
2. Initial Access : Exploit Public-Facting Application (T1190) - the operation of the HMI web interface, or External Remote Services (T1133) - VPN/RDP to the engineering station, or Valid Accounts T1078(T1078) - default accounts by shared on accounts
3. Lateral Movement : from IT network via or history jump-server to OT segment
4. Impact : Service Stop (T1489) - Stopping critical services, Data Destruction T1485(T1485) - destruction of PLC, Data Encrypted for Impact (T1486T1486) - ransomware at Level 3, Impasser Defenses (T1685) - Logging Disabling
MITRE supports a separate ATT&CK for ICS Matrix Matrix with T0xxx series techniques specific to industrial systems - manipulation of I/O modules, substituting firmware, interference with physical process. In the simulation of threats for a particular object, both matrices are used together: Enterprise - for the IT part of the chain, ICS - for the final impact on the technological process.

A separate vector that is often missed: compromise through a legitimate engineering station. The engineer connects a laptop with Step7/TIA Portal to the Level 2 network to update the PLC project. The laptop is compromised through phishing or malicious USB. From the engineering environment, the attacker gets direct access to the controllers - with all the rights to record the project, changing logic, rebooting PLC. CVSS does not cover a separate vulnerability: the attack uses legitimate functions, not exploits. So try to explain to the auditor that Medium-Vulnerability is the gateway to a physical catastrophe.

[Applicable: Internal Pentscount OT, Grey Box (access to engineering station with validation data)]
Why CVSS Doesn't Work to Assess ICS SCADA Vulnerabilities
CVSS is designed for IT-context. Its metrics do not take into account:
• Safety: vulnerability with CVSS 4.0 on SIS controller can lead to injuries and deaths
• Cascade effects: failure of one controller causes a chain reaction in the technological process
• The cost of downtime: for the oil refining plant hour of downtime - losses of tens of millions of rubles
• Environmental Damage : Spills, Emissions, Pollution - Consequences That CVSS Doesn't Model
 
Top Bottom