The need to train control system engineers and monitor process sensors for possible cyber attacks

Control systems consist of Operational Technology (OT) which includes networks and HMIs and control system engineering field devices which includes process sensors, actuators, and drives along with their low level sensor networks. It was evident at the 2019 RSA Conference (and other ICS Cyber Security Conferences) the focus of control system cyber security is on OT networks not the engineering devices such as sensors and actuators. This focus included not just the vendors, end-users, and legislators, but also government organizations. It was also evident at this year’s ICS Village where there was no cyber monitoring of the only sensor in the display panel (same as last year).

My recent blogs at deal with lack of cyber security in process sensors, the culture gap between IT/OT and the engineers, the lack of being able to discriminate between a malfunction versus a cyber attack, particularly from physics issues. These subjects are related and directly contribute to the lack of control system cyber security in all infrastructures.

The lack of being able to identify a cyber attack gets more interesting when you consider the 2017 Triconix safety system cyber attack in Saudi Arabia known as Trisis. The plant engineers had no training to identify unexpected events as possibly being cyber-related. Consequently, the first time the plant tripped, it was simply considered a malfunction and the plant restarted without cyber security considerations. The cyber attack was not identified until the the plant tripped again. If the plant didn’t trip again, the malware may not have been found until too late.

Can you prevent a sophisticated ICS cyber attack? I am skeptical. Can you at least be able to detect if the grid or other infrastructures are operating in an unexpected manner – cyber attack or not? That is possible but several issues need to be addressed. The first is to train the control system engineers to recognize when process upset conditions may be cyber-related. This did not occur in Saudi Arabia with the first plant trip. I developed what was called scenario-based training for the International Atomic Energy Agency. The purpose was to train the control system engineers to question when upset conditions may possibly be cyber-related and then to work with the cyber security organizations on those incidents. The training was based on actual nuclear plant control system cyber incidents that were not Internet Protocol network-related so were not visible to OT network cyber security monitoring. Another need is to monitor the process sensors at the raw signal level in real time (this information is “physics”, cannot be hacked, and needs to be out-of-band with the existing Windows networks). The raw process sensors  provide a clear indication if a safety situation is occurring as the raw sensor signals would indicate reality- is the process dangerously changing or not. This type of approach would have identified the conditions in the Stuxnet  attack. When the centrifuges were sped up or slowed down, the raw sensor signals would have changed despite the man-in-the-middle attack that replayed the “good” conditions on the Windows HMI as the sensor monitoring is out-of-band from the Windows network.

Whether it is correct or not, there have been claims the nation-wide power outage in Venezuela this past week was a cyber attack. Several years ago, a similar situation arose when Turkey had its grid shut down. Were they cyber attacks, equipment malfunctions, or cyber attacks meant to look like equipment malfunctions? The need to train the engineers and to monitor the sensors is crucial as some of the most critical information to answer these questions may not be available to OT networks.

Joe Weiss

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • 'Consequently, the first time the plant tripped, it was simply considered a malfunction and the plant restarted without cyber security considerations.' Hi Joe, this rings true with your prior discussions about logging facilities built into ICS devices and the need for training goes beyond control system engineers. Root cause analysis generally involves subject matter experts from the supplier as was part of the Trisis incident/near-miss. Perhaps system logs were inadequate or not persisted. Indication of a core dump could still be enough for a supplier to suspect cyber related causes but even that might not have been available. ISA/IEC 62443-4-2 has provisions to address adequacy of logs. Like other shared responsibilities It's less clear where and how to address training needs related to cyber root cause analysis. -Bryan Owen PE


RSS feed for comments on this page | RSS feed for all comments