When reading about the NIST (National Institute of Standards and Technology) directive by Executive Order 13636 to improve critical infrastructure cybersecurity, many, if not most, Control System Engineers and System Integrators just glaze over and turn the page in order to get to a more interesting topic. They may not think it’s their job, or even that learning about the subject might be in their best interest. The current thinking about Control System Security from the point of view of some engineers is to “not think about it” and it will go away… or to “give it to IT” and not worry about it again, or “the customer didn’t pay for it, so I am not going to address it because it is outside the project scope”.
Any short-sighted people who fall into this trap will definitely get burned one day, which will at minimum, involve lawyers and lawsuits, ruined reputations, and accusations of incompetence in the face of a hacked or broken control system, possible hacked or damaged processes gone out of control causing food or drinking water poisoning or contamination, cascade failures in the electrical grid, interruption of gas or oil pipelines or processing plants, automated sewage spills into waterways, and interrupted or damaged manufacturing facilities, and perhaps even fatalities.
I have visited facilities doing food processing and seen the damage that a single control system computer connected to the Internet and getting a non-targeted virus did to the production facility… or when the IT department in another company decided to force an Operating System update and shut down their 13 networked food processing plants for 24 hours, requiring a cold-restart of all of them. I have colleagues who have told me stories of chemical batch plants very nearly exploding, saved only by some quick-thinking process engineer, all because of an unauthorized entry into the control system computers. Another incident involved a gas turbine manufacturing facility completely coming to a halt for an entire shift when the IT department scheduled an automated anti-virus update at midnight, leaving no personnel available on-site to repair the damage. Yet another involved a breached control system using manager credentials by an untrained maintenance person causing a medical sterilization facility in Fontana California to explode, destroying the plant and killing 2 people; simply because 2 batch processes that should never be linked were manually overridden. Or how about the incident where several $10 Million batches of raw materials by a drug manufacturer had to be destroyed, simply because someone who should have known better upgraded the historian software without testing or documentation; which was not previously qualified to work with an older version of the SCADA package being used?
Every one of these incidents actually happened and many more related incidents continue to occur at startling intervals nearly every day, which are never reported to mainstream media or caught by regulatory agencies. These are not malicious targeted attacks. They are simply screw-ups because holes were left in the security systems that someone decided “was not their problem”. You don’t have to be in the Automation and Process Control Engineering business too long not to hear similar stories at conferences or other gatherings of peers about companies that they work for.
These incidents are not acts of “international terrorism”, though that may be the buzzphrase in mainstream media at this point in time. They are, however, failures in internal security processes creating cascading failures or incidents which could, each of them, have been prevented by proper security measures and procedures. Are agents with a malicious intent a factor or something to be concerned about in your facility or control system? Absolutely. But by-in-large, the incidents discussed here are the most common breaches of security that routinely occur, and rarely is anyone held accountable.
But that is about to change. Having attended the final three of the working groups of the NIST Cybersecurity Framework discussed in the Executive Order 13636, I can tell you with some confidence that the insurance industry was well represented at these conferences and has a keen interest in using the Framework as a way to provide a benchmark to measure or create a security index for a control system that they may be insuring. Although it hasn’t happened yet, there may be a day soon when an insurance claim for an “industrial accident” will not be paid because of “demonstrated insecure control system processes” which could have been prevented, had the process control engineer simply considered adequate, risk-based control system security as a primary design goal in the original project.
It possibly could become standard practice for an insurance company to evaluate a control system using the NIST Cybersecurity Framework toolset and find that they simply cannot provide industrial insurance coverage to a newly constructed water plant or gas pipeline simply because it does not meet minimum risk-based security requirements. Or how about a control system network being co-mingled on the same subnet as the business network with no internal protections such as a Tofino System because the risk of an internal company IT incident disrupting production or creating a shutdown incident will be too great to insure against? Or how about this scenario: A company negotiating to get greatly lowered insurance premiums because they have installed adequate and demonstrable risk-based security safeguards for their control systems, which covered the cost of the enhanced security measures and lowered their insurance premiums.
As stated in the NIST Cybersecurity Framework:
“The Framework is a risk-based approach to managing cybersecurity risk, and is composed of three parts: the Framework Core, the Framework Implementation Tiers, and the Framework Profiles.”
The Framework is not a box of tools and tests to see how secure your control systems are and tell you what to do. It is instead, as the name suggests, a framework for you to develop the tools and methodology that you need to uncover breaches in your security processes and evaluate how to improve what you already have in place. What you do with it and how you finally use it is completely up to you and your situation. In some cases, some government regulated or operated infrastructure may be required to follow NIST guidelines based on this Cybersecurity Framework, however, at this point in time, the Framework use is voluntary and unregulated.
InduSoft has partnered with Eastern New Mexico University-Riudoso and Dr. Stephen Miller, Associate Professor of Information Systems/Cyber Security Center of Excellence. We are jointly creating a book which can be used as a Classroom Manual for training and certification on how to use the NIST Cybersecurity Framework within your organization or on any project that you may be working on or evaluating. Our intent at InduSoft is to be able to provide this manual as an eBook to our customers, and it should be available sometime this summer. Additionally, we are going to follow up with a Webinar conducted by Dr. Miller to explain the concepts contained within the book and the classes and certification that his institution is offering.