The lack of process sensor cyber security has real consequences with minimal warning or forensics

If you can’t trust your measurements, you’re in trouble!  This seemingly obvious conclusion comes from:

- Neither network anomaly detection or threat hunting (detection) can detect malicious or unintentional sensor issues that occur before the sensor values become Ethernet packets;

- Detailed failure modes and affects analysis (FMEAs) of process sensors identified non-detectable failure modes that directly affected plant operations;

- Risk assessments identified potential safety impacts from sensor vulnerabilities that could impact the design basis;

- Plant testing demonstrated the lack of integrity of process sensors (process sensor drift within 30 days of calibration);

- The compromise of Serial-to-Ethernet convertors in the US and Ukraine provided a direct path into the sensors;

- Lack of process sensor cyber forensics and training precludes specifically identifying process sensor cyber events;

- Lack of process sensor cyber security is public knowledge and nation states such as Russia  and Iran are aware; and

- Multiple malicious and unintentional process sensor (analog and digital) cyber-related incidents have caused catastrophic failures (though not identified as being cyber-related – no forensics or training).

Process sensor cyber security is an ENGINEERING problem not a network issue that crosses all engineering applications. Even the design of state-of-the-art process sensors often do not address cyber considerations (my next blog). Consequently, I have brought this issue up to up to numerous engineering societies, the National Society of Professional Engineers (NSPE), and the National Academy of Engineering. I will be providing a presentation on this subject at the ISA Water/Wastewater Conference in Bethesda August 8th and am scheduled to present at the DHS ICSJWG meeting in Cincinnati later in August.

Dale Peterson asked questions about the risk of potential sensor vulnerabilities and I provided a response at Honeywell’s Sinclair Komenji provided an independent response to Dale Peterson’s questions.

According to Sinclair:

”This discussion misses one very common mistake that makes also sensors that are not directly network connected very vulnerable. This issue has to do with the management of the field devices. Asset management solutions need to communicate with sensors for calibration purposes, changes and asset inventories.

Modern process controllers and safety controllers support HART pull through, HART transmitters being the most used communication. With HART pull through the asset management application access the transmitters communicating with the controllers. Often changes in those systems can only be made when the transmitter is put in maintenance mode. So relatively secure. But the majority of controllers in the field doesn’t support HART pull through resulting in a need to connect the asset management solution to the IOMUX board where the transmitters are connected / marshaled. This requires typically a serial (RS 232 / RS 485) type of connection, but because of the distance restrictions of the serial connections often Ethernet to serial protocol converters are used to bridge longer distances.

Here we have the problem if this connection is not properly secured. In our assessments we often encountered connections that were not secured, no authentication, no encryption. So all transmitters connected to the IOMUX become exposed for HART IP messages over Ethernet. This allows for a wide set of possibilities to attack control and safety sensors. Modifying transmitter ranges, indirectly influencing a safety loops trip point, basically disturbing many elements of the plant’s observability.

This is not a rare problem, we encountered the issue in many different plants – including critical infrastructure – impacting hundreds of process transmitters in a plant. The question here becomes can we allow a single asset management application to manage both safety and control sensors, creating a point where independence of safety from control is no longer guaranteed. Also can we allow in these cases safety and control transmitters to be connected to the same IOMUX. There are a series of issues not covered by the TR 84 report from ISA which focuses primarily on network architecture but misses various attack scenarios that are relevant in today’s plants.

In the example I provide the issue results from bad implementation of the asset management solution, but the vulnerability is independent from this solution, even if the asset management system is powered down the sensors would be fully exposed by the serial to Ethernet convertor.”

The validity and integrity of process sensors is critical to the reliability, safety, and quality of all processes. Addressing the cyber security of the sensors, not the Ethernet packets, has not been adequately addressed by any industrial or DOD cyber security or safety standard. In fact, process sensors are out-of-scope for the electric industry cyber security standards (NERC CIP) and nuclear plant cyber security standards (NEI-0809 and Regulatory Guide 5.71). It may not be possible to identify sensor integrity issues as to cause (malicious or unintentional). Consequently, the approach I have been suggesting is to monitor the electrical characteristics (the physics) of the sensor in real time as those characteristics are agnostic to why the sensor/process is changing. Monitoring of the electrical characteristics can’t prevent sensor integrity issues (hacking or unintentional impacts) but can identify changes which is more than we can do today.

Joe Weiss