Bryan Owen

All Industrial Software is Toxic?

Blog Post created by Bryan Owen on Dec 12, 2017

The trend of describing malware in terms of a ‘virus’ has been credited to Fred Cohen’s ‘Computer Viruses - Theory and Experiments’ paper circa 1984. The virus analogy is still with us today and has generally fostered better awareness of malware even for novices.

Given industrial workforces are more familiar with process hazard analysis and associated chemical toxicity concepts, it seems plausible to describe malware as an industrial hazard. Examples of toxin categories and malware include:

  • Biological – Stuxnet, Crashoverride/Industroyer
  • Corrosive – Shamoon, Brickerbot, WannaCry
  • Physical – Carna, Havex, Mirai,
  • Radiation – BadBios, Blueborne, WPA2 Krack


Why stop with malware? We should consider abuse of legitimate software by miscreants as the hazard it truly is. In this context, industrial software connected to physical systems is especially toxic!


Oh my, does that sound an alarmist or extreme idea to you?  Perhaps not if you consider lifesaving medicines are also toxic when abused. Heck, even water is toxic if you drink too much. Chemicals are toxic too. Yet, chemicals are essential for sustaining our way of life and need to be handled properly. Why should industrial software be any different?


Still interested, great! What comes next is exploring chemical safety program hazmat concepts for potential application to industrial software.  NFPA diamonds are one of the most familiar hazmat awareness schemes. Could ‘hazard diamonds’ applied to industrial software be useful?




Here are few illustrative examples to tease imaginations and gather feedback. The idea can accommodate a number of security schemes. My favorite is based on the OSSTMM 3 defined elements of porosity: Visibility, Access, and Trust.

“Special Hazards” can accommodate warnings such as ‘badness-o-meter’ program scans or or more in depth security research findings like Digital Bond ‘Project Basecamp’.



Cyber hazards can be invisible to the observer as are many chemical hazards. Information about the special hazards and severity of the standard hazards are key details for constructing the diamond. While there is an extensive library of Material Safety Data Sheets for chemicals, little exists in the way of published data sheets for industrial software.


That is until now. Thanks to a coalition tasked with protecting nuclear power plants, EPRI has released a formal threat assessment methodology (TAM). First, in the four step TAM methodology, is generation of cyber security data sheets. TAM exhibits the kind of rigor expected in nuclear engineering but also delivers efficiencies.


EPRI allows those using TAM to generate and publish a reference CSDS. For example, OSIsoft can provide a reference CSDS for the PI System which jump starts the assessment. Entities then use TAM to expose and mitigate exploit pathways.  As a result, defenses are optimized and ‘chasing vulnerabilities’ can be avoided.


EPRI has been hosting workshops to refine TAM and increase the pool of contributors. TAM is applicable in all sectors. For example, the AFPM cyber security subcommittee was briefed earlier this month. The stage is set for an industrial library of CSDS. An early look at the CSDS in progress for our PI Data Archive is planned for Digital Bond S4x18. That's yet another reason you might want to join us at S4x18 for a deep dive on PI System security!

I urge EPRI members to request the report and become familiar with TAM. Interested non-members should order the report (~$300USD).



Acknowledgements and expression of gratitude for helping spread the word about Cyber Security Data Sheets:

Michael Thow, Matt Gibson, Brad Geddes – Electric Power Research Institute; Harry Paul – OSIsoft, LLC; Mike Lennon – SecurityWeek; Dan Strachan – American Fuel & Petrochemical Manufactures; Lori Ross-O’Neil, Scott Mix – Cyber Resilient Energy Delivery Consortium (