I attended my first S4 Conference and it was quite the sight. When I started the ICS Cyber Security Conference in 2002, I never dreamed there would be multiple ICS conferences world-wide or that an ICS Cyber Security Conference would have over 500 attendees (S4X19 did).
The S4 Conference, like all of the other ICS cyber security conferences including the revised version of my old conference (now the SecurityWeek Conference), are heavily focused on OT networks and IT/OT convergence. A recurrent theme throughout SIGA's Amir Samoiloff and my presentation on process sensor monitoring was that addressing the OT networks and the IT/OT convergence was necessary but not sufficient. As usual, this was the only presentation addressing the raw sensor data at the field device level – the origin of the measurements and where the measurements can’t be hacked as it is at the physics level.
Addressing the field device level requires engineering expertise and is what makes control system cyber security different than IT/OT cyber security. Automation/process/relay engineers, field instrument/relay technicians, etc. are not OT but Engineering whereas OT is the network engineers and network technicians. Consequently, the real culture gap is between Engineering and IT/OT. From my direct experience analyzing sensor health and field equipment diagnostics to detect unintentional incidents or malicious attacks, the analysis needs to be done at the raw sensor level as that is where the noise content indicative of sensor/process health lie (it was the sensor/forensic work, not cyber security, that made me an ISA Fellow). Analyzing process/sensor health at the Ethernet packet level is too late as the key data, the noise, has been filtered out. An OT network can NOT be secure nor can you have adequate situational awareness if you can’t trust your measurements, not to mention the lack of safety. This is why some of the most disastrous events such the Three Mile Island core melt, the Texas City Refinery explosion, and the Buncefield tank farm explosions would not have been detected at the network level as they were engineering device anomalies (as well as human error). Consequently, the real gap is what I call “before (Engineering) and after the Ethernet packet (IT/OT)”.
The case histories presented by SIGA provided a number of very important insights about the value of monitoring process sensors at the raw electric signal level:
- A combustion turbine couldn’t restart because of an UNDETECTED sensor problem by the Windows-based HMI (lack of adequate situational awareness). This is because the HMI does not have the resolution to identify subtle sensor problems. DARPA’s Plum Island test would have failed if the diesel generator providing the black start was unable to start because of a sensor failure similar to the combustion turbine case.
- While monitoring the sensors at a water company, the Windows-based HMI became unresponsive (it wasn’t hacked but could have been). What was critically important was the sensor monitoring system continued to operate even with the Windows-based SCADA out-of-service as this is an out-of-band system not affected by Windows/IP network vulnerabilities. Additionally, a failing pump was detected by the SIGA system that was not identified by the Windows SCADA HMI equipment monitoring system.
- The SIGA monitoring system is being used in power, water, chemical, and building controls applications as it is independent of the type of sensor and the type of process. It is also being tested for use in electric transmission and distribution applications.
I believe monitoring of the raw sensor signals can make OT network monitoring, which currently is intractable, into a solvable engineering problem in addition to reducing supply chain and network threats. This is also an approach that REQUIRES the engineers to be part of the solution which really hasn’t happened with the current OT network monitoring approach.
As there was no Q&A session following our presentation, I was not able to get immediate presentation feedback. However, from my discussions with attendees before and after the presentation, the device level topics at the raw sensor level were new to most which has been consistent with every conference I have attended.
There was another session that I feel needs to be addressed which was on the Critical Vulnerability Scoring System. Without going into the intricacies of the scoring system which was well laid out by the panel, my problem was the vulnerabilities generally had no connection to physical impact. If a vulnerability can cause harm to equipment and/or people and it can be exploited, it is critical. If not, it isn’t. Often the most critical “vulnerabilities” for control systems are process or control system design features not network vulnerabilities (e.g., Aurora, Stuxnet, etc.). For control systems the focus should be on the health of the process rather than on network vulnerabilities which is why sensor health monitoring is so critical.
I am hoping that future conferences will discuss the critical (until now mostly unaddressed) raw sensor level and Engineering-IT/OT culture issues. Simply addressing sensors, if they are not at the raw sensor level, is not sufficient. As best as I can tell, the SANS ICS Cyber Security Conference, ARCForum, RSA Security Conference, and the Kaspersky Analyst Summit are not addressing the sensors at the raw sensor level which are lost opportunities. I will be giving a paper on sensor cyber security at the Texas A&M Instrumentation and Automation Symposium January 22nd. Dr. Juan Lopez from the Oak Ridge National Laboratory (ORNL) and myself are scheduled to give a presentation on sensor monitoring for nuclear plants at the 11th American Nuclear Society’s Nuclear Plant Instrumentation, Control, and Human-Machine Interface Technologies Conference. I have also been asked to prepare a white paper on these technical/culture issues for the National Academy of Engineering.
Joe Weiss
