Friday and Saturday July 28-29, 2017, I attended (and spoke) at my first Defcon Conference (I still have not attended BlackHat). Defcon was a zoo - people everywhere. It almost looked like Halloween with the different dress. As a novice to Defcon, I found it incredible the number of different sessions and people involved in things from lock picking to just about every form of hacking. I ran into a number of people I knew, or at least knew me, particularly at the ICS Village. In a surprise to me, Congressman Langevin visited the ICS Village and got a better idea of the different aspects of hacking control systems. There was one sensor in the ICS wall in the ICS Village. When I asked, what was being done about monitoring or securing the sensor, I was told it was just a 4-20 milli-amp sensor, why bother.
There were several very good talks at the ICS Village including Chris Sistrunk’s talk about ICS forensics. This was of great interest to me as Chris reinforced the lack of existing ICS cyber forensics. There was also several training sessions.
On Saturday I gave a presentation on the lack of authenticated, secure process sensing. There was very little understanding of sensor issues - the focus was on hacking controllers. Network-based anomaly detection systems start from the time the sensor readings are converted into IP packets in the serial-to-Ethernet convertors. There is currently an assumption by many that network anomalies equate to process anomalies – this is not true. There was little understanding sensors could be compromised before the convertor, and therefore, little question of the validity of the results from the network anomaly detection systems.
My presentation focused on the physics issues. I had not seen Marina Krotofil’s presentation at Black Hat of hacking a “non-critical” valve to cause pump cavitation https://www.wired.com/story/evil-bubbles-industrial-pump-hack. Consequently, it was interesting how my presentation dovetailed so closely with her presentation. Cyber threats are now (actually started with Stuxnet and Aurora 10 years ago) morphing to compromise of plant equipment functionality. With Aurora, engineers have known for many years you do not restart AC equipment out-of-phase with the grid. Yet this is what Aurora does. Engineers have identified operating regions as being “out-of-bounds” for operation because you could be operating on a resonance frequency, cause cavitation, or create a water hammer, etc. Pump curves specifically tell you where to avoid operation. What Marina did was to operate where there would be a known problem. Variable frequency drives explicitly identify frequencies to avoid (and they have no authentication or security). Network anomaly detection cannot find these operating conditions as it is not malware. One of my examples of sensor issues was a power plant I recently visited where the plant tripped after the pressure sensor inadvertently reached its setpoint because the sensing line was clogged. In this case, it was not possible for network monitoring to detect the degradation in sensor performance because the packets did not contain the relevant information. Several years ago, a safety relief valve in a nuclear plant not lift because the sensor could not reach its setpoint. These cases are similar to Marina’s presentation as network anomaly detection generally cannot identify plant issues such as pump cavitation until it is too late. The same can be said of piping issues such as water hammer. The Sayano Shushenskaya Russian dam failure was a non-malicious failure caused by physics – running on a resonant frequency. This event also could have been caused maliciously. Without sensor monitoring, it is NOT possible to see the precursor to these kinds of conditions until it is too late. As these examples include both unintentional incidents as well as cyber attacks, the impacts are the same but you cannot tell the difference!
One question that arose at my talk was the use of historian data as a back-up. However, the historian data is comprised of sensor data. Consequently, if the sensors are compromised, the historian data is also compromised. I did not address specific solutions, but there are some companies working on sensor monitoring before the sensor data becomes an Ethernet packet.
As an aside, Dale Peterson had asked me to participate in a panel at S4 2018 on an Aurora retrospective. Aurora is a physics problem. When I offered to address the sensor issues, Dale said it was not necessary as his S4 attendees were well aware. From my personal interactions including at Defcon, this is not true.
The examples show that ICS cyber threats are morphing from malware/insecure-by-design issues that can be found by network monitoring to compromise of system or component functionality which can be very difficult to detect, can cause significant physical damage and injuries, and probably cannot be found by network monitoring.
Joe Weiss
