Mar 30, 2021
Part 1: Awareness of Purdue Level 0 and 1 (In)Security
Part 2: Properly Prioritizing Level 0 and Level 1 Security
In this third and final article in my Level 0 / Level 1 security series the focus is on the appropriate security controls.
The security concern with sensors is that the sensor data will be incorrect and lead to incorrect control decisions. Sensors fail for a variety of reasons unrelated to a cyber attack, so this is not a new issue. However, an attacker with engineering skills and automation skills is more likely to know what type of false data could lead to high consequence control decision errors. A simple example would be spoofing the data so the Operator and logic thinks everything is operating normally, when in fact the process is entering a bad state.
Bad sensor data could be injected at the sensor itself (Level 0), communication networks between sensor and PLC (Level 1), at the PLC, communications between the PLC and the Level 2 computers, or in the ICS applications at Level 2. As noted in Part 2, the exposure to a cyber attack is greatest where the device or network has an IP stack.
Ideally we would like to have authentication of the source and sensor data integrity along each step of this communication path, and hopefully we will eventually get to having this. In the meantime, the solution where the risk of false Level 0 sensor data is unacceptable is process variable anomaly detection (PVAD) on reported sensor data.
The best example to date of this is GE's Digital Ghost, originally shown at S4x19. GE had a digital twin of a GE turbine and the control system. After training the twin with data from operations, GE was able to identify when specific sensor data did not make sense based on the state of the process reported by other sensors. Digital Ghost then calculated what the nonsensical sensor value should be and sent that to the actual control system where it could be considered by the Operator or automatically corrected in the HMI and system.
Importantly this solution deals with bad sensor data regardless of the cause, sensor failure, cyber attack or other.
The GE example is in some ways the simplest one. GE makes the physical product, the control system, often deploys the solution, and has a somewhat standard deployment. It's why they had digital twins for these turbines before the term digital twin existed. The growing benefits of digital twins is leading to exponential growth in their deployments across vendors and integrators, and the ability for this data to be used for PVAD is another benefit.
The other method for detecting sensor data errors today is to have a separate Level 0 monitoring network and compare the sensor data reported up to Level 2 with the data received on the Level 0 monitoring network. Vendors such as SIGA OT Solutions, Cynalytica, Fortiphyd, Mission Secure and others are offering this. Importantly, some are also touting PVAD capabilities which obviates the need for this new monitoring.
The cost of deploying and monitoring a second network for something with the lowest exposure to cyber attackers is difficult to justify from an efficient risk reduction criterion. I have been interested in the possibility of monitoring only a small percentage, perhaps 5% or less, of the Level 0 sensors through a separate network. Could machine learning identify what 5% of the sensors could detect a Level 0 cyber attack? It likely wouldn't be as simple as selecting the most critical 5% of the sensors. I imagine it would be sensors distributed over the process and with certain correlation results related to high consequence events. This is a good research project.
As noted in Part 2, new sensors with an IP stack should have the same security controls as listed in the actuators below.
Actuators are the end point that demonstrates the insecure by design problem. They will do whatever they are told to do, within their operationally deployed capabilities, regardless of the source of the command.
There is no authentication of the source of the command. There is no authentication of the integrity of the command. This is what the security controls need to change.
(Remember from Part 2, adding security controls to new or legacy serial interfaced actuators is deferred, look at it again in 3 to 5 years.) These recommendations apply to new actuators with an IP stack and are the minimal set.
The wrap-it-in-TLS decision does add complexity to the Level 0 security problem. If Level 1 is doing anything more than forwarding packets, it will need to decrypt the wrapped packet, and then potentially encrypt it again to send on to Level 2 or other Level 1 devices.
Of course there are many more security controls that could be specified and could be helpful. Others who leap from insecure by design to secure by design lean heavily on the importance of security development lifecycle (SDL) requirements. The fuzz testing of the protocol stack's that began in the '00 decade helped a great deal with protocol stack robustness and will only help the vendor with the product lifecycle. This list of three security controls is the bare minimum in terms of addressing the insecure by design problem.
New PLC's are Priority 1 in the Level 0 / Level 1 security decision tree for adding security. Upgrades to high and medium consequence legacy PLC's are Priorities 2 and 3. The security controls listed for actuators are required for PLC's as well. In addition, they should have security event logs and the ability to store and forward these event logs.
Nice to have, premium options for these devices include:
This three part article series can be summarized as follows:
Subscribe to my ICS Security: Friday News & Notes email.