Back to Intelligence

Measuring the Unmeasurable: Standardizing OT Impact with a Cyber 'Richter Scale'

SA
Security Arsenal Team
February 26, 2026
5 min read

Measuring the Unmeasurable: Standardizing OT Impact with a Cyber 'Richter Scale'

In the world of Information Technology (IT), we have become accustomed to relatively standardized metrics for success and failure. We track Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), and utilize the Common Vulnerability Scoring System (CVSS) to rank software bugs. But when a cyberattack crosses the air gap into Operational Technology (OT)—the realm of power grids, water treatment plants, and manufacturing lines—these metrics often fall flat.

A logic lock on a database server is an inconvenience; a logic lock on a centrifuge is a physical catastrophe. For too long, the industry has lacked a universal language to describe the severity of these kinetic outcomes. That is finally changing.

The Gap Between CVSS and Kinetic Consequences

The recent proposal by ICS/OT experts to establish a “Richter Scale” model for cyber incidents addresses a critical blind spot in industrial security. Traditional vulnerability scoring focuses on the exploitability of code—how easy it is to hack a controller. It does not inherently measure the magnitude of the disaster if that controller is compromised.

Consider a scenario where two different facilities suffer a breach of the same programmable logic controller (PLC). In Facility A, the PLC controls a redundant fan in a data center HVAC system. The impact is a temperature spike and a failover. In Facility B, the same PLC manages the pressure release valves at a chemical refinery. The result is an explosion and environmental contamination.

Under CVSS, both vulnerabilities are scored identically. Under the proposed Richter model, the “seismic” impact of the incident at Facility B would register significantly higher, accounting for safety implications, environmental damage, and loss of life.

Executive Takeaways: Why Magnitude Matters

For CISOs and CIOs managing converged IT/OT environments, this shift in thinking is not just academic; it is essential for business continuity and risk management.

1. Translating Risk for the Board Boards of Directors do not understand CVSS vectors, but they understand earthquakes. By adopting a magnitude-based scoring system, security leaders can articulate the potential business impact of an OT compromise in terms that resonate with executive leadership. It moves the conversation from “we have unpatched vulnerabilities” to “we face a Level 5 seismic risk to our primary production line.”

2. Prioritizing Investment based on Impact Not all assets are created equal. A magnitude-based model forces organizations to move away from flat vulnerability management and toward risk-based asset management. Security spend can be directed toward the sensors and controllers that, if disrupted, would cause the highest magnitude event, regardless of how many CVEs they possess.

3. Insurance and Liability As cyber insurance policies become more stringent regarding act of war and infrastructure attacks, a standardized magnitude scale provides the objective data needed to validate claims and adjust premiums. It creates a common ground between the insured, the insurer, and the incident responders.

Operationalizing the Scale: The SOC's Role

While the Richter model describes the aftermath, the Security Operations Center (SOC) is responsible for preventing that magnitude from being reached. To do this, SOCs monitoring OT environments must move beyond simple signature detection and focus on anomaly detection that precedes kinetic impact.

We need to hunt for the precursors of high-magnitude events: rapid changes in setpoints, unauthorized firmware writes, or abnormal communication patterns between Human Machine Interfaces (HMIs) and PLCs.

Below is a KQL query designed for Microsoft Sentinel or similar SIEM platforms to detect a potential precursor to a high-magnitude OT event: High-Frequency Write Operations to OT Controllers. This pattern often indicates an attacker attempting to brute-force a logic change or prepare a payload for physical disruption.

Script / Code
// Look for high frequency write operations to ICS/OT devices within a short window
let TimeWindow = 5m; // 5 minute window
let Threshold = 50;  // Threshold for write operations
let OTDevicePrefix = "PLC-"; // Customize based on asset naming convention
let ICSVendor = "Siemens"; // Example vendor, adjust as needed

DeviceProcessEvents
| where Timestamp > ago(TimeWindow)
| where DeviceName has OTDevicePrefix 
// 'InitiatingProcessFileName' represents the actor/script, 'FileName' the target logic
| where ActionType in ("Write", "Modify", "Upload", "ProgramDownload") 
| summarize count() by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, bin(Timestamp, TimeWindow)
| where count_ > Threshold
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, WriteCount=count_
| order by WriteCount desc

Mitigation: Reducing the Seismic Risk

Adopting a new scoring model is only effective if it drives action. To prevent a high-magnitude OT cyber incident, organizations must take the following steps:

  1. Implement Strict Segmentation: Ensure your OT network is logically and, where possible, physically separated from the IT network. A Richter Scale 5 event in the IT network should not be able to propagate to the OT network.

  2. **Deploy Industrial Anomaly Detection (IDS/IPS):n Traditional IT firewalls often miss OT-specific protocols (Modbus, DNP3, S7Comm). Deploy passive monitoring solutions that understand the “process” baseline—what is normal operation for a valve or a conveyor belt—and alert on deviations.

  3. Conduct Kinetic Tabletop Exercises: Move beyond data breach simulations. Run exercises that simulate the loss of control over physical machinery. Involve facilities engineers and safety officers in these discussions to accurately calculate the potential “magnitude” of various cyberattack vectors.

  4. Enforce Read-Only Integrity: For safety-critical configurations and logic files, utilize hardware-protected storage or change management systems that enforce read-only access unless a specific, multi-person approval workflow is executed.

The introduction of a Richter Scale for OT incidents is a maturing moment for the industry. It acknowledges that in our hyper-connected world, cybersecurity is no longer just about protecting data—it is about protecting reality.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

socthreat-intelmanaged-socot-securityicsrisk-assessmentindustrial-controlcritical-infrastructure

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.