Many people feel an incident must be malicious to count as a cyber incident. That is not the case, but incident response is usually organized as if every incident identified as cyber-related is a deliberate attack.
Colonel Herman Haupt, a U.S. Army civil engineer, served as chief of railroads for the Army of the Potomac during the Civil War. Haupt's mission was to keep the trains moving so the Army retained its operational mobility and clean-functioning supply lines. One of Haupt's ideas holds lessons for us today, even with respect to such current concerns as cybersecurity. From Haupt's point of view, it didn't matter whether a railroad bridge was downed by a flash flood or a Confederate cavalry regiment. The bridge was out and needed to be fixed as soon as possible, and that's what Haupt organized his engineering troops to do. As far as Haupt was concerned, a Pennsylvania thunderstorm and Jeb Stuart's troops were essentially equivalent: they both broke bridges. It wasn't the intention; it was the outcome that mattered.
It should be evident but cyber incident response programs are not initiated until an incident is identified as being cyber-related. Stuxnet demonstrated that a sophisticated attacker could make a cyberattack look like an equipment malfunction. Moreover, the impact of a cyber incident may be the same, whether it’s malicious or unintentional (see Colonel Haupt).
The Government Accounting Office (GAO) 21-477 defines of a cyber incident as “an event that jeopardizes the cybersecurity of an information system or the information the system processes, stores, or transmits; or an event that violates security policies, procedures, or acceptable use policies, whether resulting from malicious activity or not”. The Securities and Exchange Commission (SEC) cyber reporting requirements apply to any control system cyber incidents that can have a material impact on a business. Control system cyber incidents can cause material impacts requiring reporting. Finally, an unintentional cyber incident can be used as a template for hackers because they know the incident caused damage.
A lesson from nuclear power plant safety
I first started documenting incidents not for cybersecurity, but for work I was doing at EPRI on nuclear plant safety. We were trying to justify eliminating some nuclear plant safety instrumentation testing requirements to reduce radiation exposure to field technicians and develop sensor health monitoring to improve plant maintenance. We found a nuclear safety pressure sensor with a failure mode we couldn’t explain (NRC had issued an Information Notice on this sensor failure). We found out later the failure was caused by a manufacturing flaw at the vendor (a hardware supply chain issue).
In this case, it involved a loss of fill oil within the capacitive-based sensor, resulting in a common-cause, non-detectable failure in pressure, level and flow. Commercial nuclear power is unique in that all abnormal incidents are public (or were at that time) and so one would expect that identifying failures would be easy.
However, there was no category for “oil loss,” which meant I had to “read between the lines” to identify sensors that experienced oil loss. This was not a trivial exercise. I found more than 200 oil loss incidents where nuclear safety sensors experienced abnormal operation, yet none of the NRC or plant documentation directly mentioned the words “oil loss”. Two of the most significant oil loss cases (neither identified as such) were a safety relief valve that did not lift after a forced outage because the pressure sensor never reached a setpoint, and, of course, the well-known Three Mile Island accident, where a pressure sensor with oil loss misled the operator during the accident.
Genesis of identifying control system cyber incidents
When I helped start the EPRI control system cybersecurity program in 2000, I wanted to do the same – understand the scope of the problem, and so I started collecting cases. Most cases were unintentional or network malware incidents such as the Slammer or Conficker worms. Early on, the only case that was publicly identified as a control system cyber incident was the Maroochy wastewater hack in Australia, as the hacker was convicted and sentenced to prison (it is still relevant today). Other control system cyber incidents until Stuxnet were identified as mechanical or electrical failures, not cyber incidents (and that continues to happen).
Network cyber incidents are identified
As mentioned, many operational facilities have been impacted by non-targeted cyberattacks such as Slammer, Conficker and now ransomware. Ransomware and other data-driven cyber incidents that have affected “operational” facilities were identified as OT cyber incidents when operational systems were shut down under an abundance of caution or loss of view not because of damage to equipment or injuries.
On the other hand, physics-based control system cyber incidents that have caused damage or injuries have been categorized as mechanical or electrical failures. The lack of identifying control system incidents as being cyber-related is evident from my Nov. 18, 2022 blog, “More than 17 million control system cyber incidents are hidden in plain sight” as it takes specialized knowledge to identify these incidents as being cyber-related. The lack of networking personnel identifying control system cyber incidents was also evident when I held the Control System Cybersecurity Conference from 2002-2017. The attendees that discussed control system cyber incidents were the engineers while the network security attendees often didn’t consider those incidents to be cyber incidents.
Government not identifying control system incidents as cyber-related
Government and industry organizations, including the National Transportation Safety Board (NTSB), Nuclear Regulatory Commission (NRC), Department of Energy (DOE), Environmental Protection Agency, Transportation Security Agency, Food and Drug Administration and North American Electric Reliability Corporation (NERC), have not addressed many actual control system incidents as being cyber-related.
I have written numerous blogs to that effect. Identifying control system incidents as cyber-related is complicated by the tendency of government and industry organizations to rush to judgement as they state that incidents weren’t cyberattacks without knowing the incidents’ actual cause. This rush to judgment occurred when NTSB stated the Dali wasn’t a cyberattack after less than 12 hours into the accident and NERC stated an incident was not a cyber incident, but it would take time to determine what happened.
In other cases, the government has not identified the incident as being cyber-related even though they were clearly cyber events. Examples are the Davis Besse and Browns Ferry Unit 3 nuclear plants. The Davis Besse nuclear plant was affected by the Slammer worm, yet the NRC Information Notice did not mention the word “cyber”. In fact, Davis-Besse was not required to report the virus attack to the NRC because the Safety Parameter Display Systems (SPDS) was not lost for more than eight hours. The Browns Ferry Unit 3 broadcast storm (too much data on the network) did not need to be reported because the broadcast storm did not affect a safety system.
This is like DOE’s Operating Experience (OE)-417 reporting for loss of view and control in the main control room where the incident has to be for more than 30 contiguous minutes. Hence, incidents that do not meet government threshold reporting requirements are not reported. It is difficult to identify trends when the government reporting requirements exclude so many real cases. Moreover, control system cyber incidents have occurred in multiple sectors with similar causes and similar equipment, but there has been no “connecting the dots”.
Financial significance
Identifying control system cyber incidents takes on extra significance given the Jun. 4, 2024, Moody’s report, “Not all cyberattacks are created equal.” The report states:
“Cyberattacks can undermine the creditworthiness of companies, organizations and governments, hitting revenues and increasing costs. Worse, they can disrupt operations for days, sometimes weeks or months. The credit impact may manifest immediately or some years later. In general, though, the severity of the credit impact depends on the attacked party itself, in particular its financial health and the diversity of its revenue streams and customers.”
The report did not address control systems, but business disruption and other physical impacts are especially characteristic of control system cyber incidents. Additionally, insurance companies and the SEC expect control system cyber incidents to be identified expeditiously.
Summary
Control system cyber incidents continue to occur with potential or actual catastrophic consequences in every sector. The training to recognize control system incidents as being cyber-related is missing. Identifying control system incidents as being cyber-related is complicated when government and industry organizations rush to judgement by stating that incidents weren’t cyberattacks without knowing the actual cause or set reporting thresholds that exclude many actual incidents.
