Blog

Safety Demo at This Week’s ACS Conference in Chicago

If you are familiar with safety and SIL as defined in ISA-84 and IEC61508, then you are also aware that when a process engineers considers the “safety” of a given component, they are usually considering only the potential for random hardware faults in such a component, and the reliability or likelihood of the safety components to be able to maintain a safe state of the operating equipment. They do not address, explicitly, systematic faults related to software, security issues, etc., as these were generally considered to be too difficult to predict. It is a generally well known and accepted position within the industry.

Given, however, that most cyber security issues in a SCADA or process control environment have potential safety related impacts associated with them, many have attempted in the past to reconcile safety and security into a single discipline for process control. There have been a number of efforts such as the creation of Security Assurance Levels (SAL), but these have often met head on with two fairly significant challenges:
  1. IT personnel consider security as more of a network based issue in the classic Confidentiality, Integrity, and Availability models. Most do not understand that we unite physical and logical in process control, and physical safety is a paramount concern. I have on more than one occasion been told by IT people that they didn’t “buy” the safety argument, but they obviously have spent very little time in a plant.
  2. Engineers often see the safety and physical, but they don’t understand the network based components, and that it certainly is possible to affect the reliability of a safety component or possibly jeopardize safe operation from a computer terminal.
The dilemna is that as we continue to drive Ethernet and wireless further into the shop floor, including safety systems, we are introducing risk at an increasing pace as well. Dr. Nate Kube and myself had the opportunity to present at Dale Peterson’s S4 conference in 2008 in Miami on this very topic, and it was largely driven by a paper that he and I both wrote on the challenges of SIL versus SAL. A copy of this paper is available by emailing Steve Kim at skim@wurldtech.com.

This week at Joe Weiss’ Applied Control Solutions Cyber Security Conference in Burr Ridge, IL (Near Argonne National Laboratory), Dr. Kube and I will have the opportunity to showcase a compromise of an Ethernet based security controller as part of a live demonstration…. the first to be done by a private company and not a National Lab at this conference.

During this demonstration, we set up a train set with two trains running, where a safety system is configured to ensure that no two trains can occupy the same space at the same time on a crossover switch. Before the comments like, “that’s not a real safety system!” or “who cares about playing with trains!” come into play, this selection was made on purpose:
  1. The showcase item is demonstrating a cyber compromise where we will show the I/O channel failure on the safety system. This will mean a lot to IT people and to others that understand digital communications
  2. To those that understand the physical process better or without a deep knowledge of digital communications, showing the moving lines on a screen will make little impact… the trains satisfy the more visual thinkers by correlating the failure on the I/O channel to a physical event
  3. Using the trains helps us to not show a vulnerability in a known controller or vendor product, and provides a simple mechanism for communication. They also help prevent distraction by looking at actual equipment, helping us to focus on the issue of compromising the safety controller.
We will then show how specific firewall rulesets learned through testing and a firewall device prevent the very compromise we are showcasing, demonstrating that even simple design decisions can mitigate such risks effectively.

We certainly look forward to this opportunity, and will be putting together demonstrations of the event and later papers based upon the response and feedback obtained. A video will also be placed up on Wurldtech Live for those that are not able to see the demonstration in person.

Just to be clear: We are NOT going to show a vulnerability this week, disclosing any particular vendor product. As we have often stated, that is not our business or motivation, we instead seek to challenge the industry that what we THINK is safe may well not be, and to demonstrate the need for continued improvement.