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.
Sensors and Sensor Data
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
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.
- Signed Firmware / Secure Boot – This is to prevent simple DoS / brick attacks with a corrupted firmware upload, as well as more sophisticated attacks that actually put attack code or hooks in the firmware. The beauty of this control is it requires no user action. (And no this would not have stopped the SolarWinds incident or anything else that has compromised the vendor’s firmware creation and issuing process).
- An administrator role and login capability where over the network actuator administration is possible.
- Authentication of any control commands – Until recently this would have required a vendor to come up with a proprietary solution. Now there is CIP Secure, Modbus/TCP Security, and other ICS and IIoT protocol security. For better or worse, most of the security consists of wrapping the protocol in TLS. This does require some PKI / key management to be effective. At a minimum the vendors should start with something simple, and less than perfect, where part of the commissioning is to put an asset owner signed certificate on each actuator.
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.
PLC’s (and Other Level 1 Devices) That Communicate With Actuators
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:
- A deep packet inspection firewall to restrict access to the device from Levels 1 and 2. This is the Tofino, M-Guard, OTfuse or similar integrated into the Ethernet card or somewhere else on the PLC. The only thing stopping this option is the business case.
- PLC endpoint protection – this is an area ripe for research. What is the equivalent of anti-virus for a Level 1 device. We have had proposed sessions for S4, that were pulled back, that would look at the logic / program upload for attack code before loading it.
Conclusions
This three part article series can be summarized as follows:
- The ICS Security Community understands that Level 0 and almost all Level 1 devices lack authentication. Access sensor data can be modified, and control commands that reach the device will be accepted.
- The risk of the lack of authentication varies at Level 0 and Level 1 based on the exposure and capabilities of the device. While we would like to have cyber security throughout the entire ICS, it is important to prioritize efforts where we will achieve the most efficient risk reduction.
- Process variable anomaly detection (PVAD) is the most effective way in the short and medium term to detect and address bad sensor data.
- Authentication of the firmware, administrative actions, and control commands are the most important security controls to add to the Level 1 and Level 0 devices in the decision tree specified priority order.
Subscribe to my ICS Security: Friday News & Notes email.