Recently I wrote about the dichotomy between the reports and experts annually citing a big increase in the cyber threat to OT systems and the year after year tiny actual impact of cyber attacks on OT. Outside of ransomware on IT, not reaching OT, affecting Operations, the impact could be characterized as infinitesimal as part of all cause impact in 2025 and most past years.
And yet most with experience in OT environments, including myself, believe that if an attacker had reached OT and had administrative privileges on a computer in OT they could cause a medium to catastrophic consequence in most Operations. Not all, but most. And on top of this, the vendors with the most visibility into the most systems say the level of attack tools and information gathering is growing. Many reports would have you believe we are already getting clobbered, not true by evidence of impact, but maybe forewarning we are about to.
Big Question: How do we better understand the real threat to our OT systems?
Possible Answer: Get stats on incidents that could have been a high or catastrophic consequence event if the attacker had the necessary skill and intended to cause the high or catastrophic consequence.
How? Let’s borrow from safety, which is so often the answer. Specifically take the API Recommended Practice 754 Process Safety Performance Indicators for the Refining and Petrochemical Industries approach. API 754 has a four-tier framework for measuring safety events.
It’s straightforward to modify this four-tier approach to events caused by an OT cyber incident.
Most of the incidents you read about in the hyperventilating media, albeit stoked by vendors and OT Security Pro’s, are Tier 3. We know it is hard to hide a Tier 1 incident. You can’t hide the consequence; you may be able to hide or don’t know the cause is an OT cyber attack.
The key to accurately portraying the threat level today is more information on Tier 2 OT security incidents. And the best people to provide this information are the vendors with the most visibility. Those with large cloud based OT monitoring systems. This is a plea to the Armis/ServiceNow, Claroty, Dragos, Nozomi/Mitsubishi, and the automation vendors and consulting organizations who also offer monitoring and incident response services to collect and publish Tier 2 incident data.
We don’t need the details. Sector and country/region would be nice, but even if you track and report the number of Tier 1 and Tier 2 incidents as a global total it would be a great piece of information.
Let me address two arguments I’m sure will come. First, all the vendors together are only monitoring a small percentage of the overall companies/facilities with OT. The data will undercount the incidents on the population of OT systems. Yes, this will be a sample, and it will a sample of the most mature OT security programs. The data still is hugely valuable and those caveats can be listed.
Second, it takes some analysis to determine the difference between Tier 2 and Tier 3 incidents. This is related to one of the common mistakes those new to OT and automation make … they forget that attackers are limited by physical I/O, equipment realities, scientific realities, and safety and protection systems. How many times have you heard someone say they could take down the grid, refinery, factory, etc. without knowing the things that could stop even the most skilled attacker?
Let’s pretend the Oldsmar Water Hack was real. An attacker gets admin access to a HMI, or even an EWS, and sends a command to increase the lye put into the system from 100ppm to 11,100ppm. It was stopped before anything dangerous happened, but what if it hadn’t been stopped. What if the HMI sent a message to a PLC to dump that much lye into the water treatment and no one noticed this rogue command?
Would it have been a Tier 2 or Tier 3 event? It depends.
- Was the PLC programmed to perform range checks / input validation that would have prevented the command from being sent to the pump? Yes: Tier 3, No: Possible Tier 2. WRONG! An attacker with that access and skills could potentially reprogram the PLC … if it was not in Run Mode. It still could be Tier 2 even if the PLC had input validation. (Note: this is a great example where an OT security pro can add value talking to engineers on how their safety / protection might not be bulletproof.)
- Is the pump’s flow rate capable of providing that much lye to the system? Yes: Possible Tier 2, No: Tier 3.
- Is the lye in the tank connected to pump enough to cause a safety incident if it’s all put into the water supply? Yes: Possible Tier 2, No: Tier 3.
- Is there a PH sensor with a signal to shut off the pump if that PH is too high? Is this PH sensor or shut off signal accessible to the attacker? Yes or No/Yes: Possible Tier 2, Yes/No: Tier 3.
- Is there a periodic human test of the PH level that would have identified the issue before it was a safety issue? Yes: Tier 3, No: Possible Tier 2
There are likely more of these considerations that the water expert in the plant would identify. All have to be answered Possible Tier 2, or it’s a Tier 3 attack. Of course the hope is that there would be at least two reasons the OT cyber incident could not be Tier 2, or Tier 1.
The vendors I’m asking to report this data may not have all the information to determine definitively whether an incident was Tier 2 or Tier 3. Incident responders will should know, but monitoring companies will need to use their judgment. I think the community can live with that. It’s much better what we have today.
