I like to call ICS security legend Joe Weiss the Paul Revere of the community. In the five years after the Sept 11th attacks, he was the most effective advocate and loudly carried the message that we have a huge risk that was not being addressed. He didn’t stop in 2006, but it has been less lonely as the community’s chorus has grown.
Since late 2016, Joe’s message has been focused on the security of process sensors, actuators and drives. Almost every presentation he gives or article he writes comes down to the need to address this issue. (He often refers to these as Level 0/1 devices, but I’m going to avoid that term because Joe is not talking about a lack of security on Ethernet connected PLC’s, RTU’s and other controllers. Project Basecamp back in 2012, and many other efforts have finally resulted in PLC’s with signed firmware, secure boot and even authenticated ICS protocols for logic upload, control and more.)
I’ve had a number of conversations about this issue with Joe, and he consistently and enthusiastically explains the problem that sensors and actuators lack even the most basic security. In my words, they are insecure by design, just like PLC’s until recently. To me, and I contend ICSsec professionals and S4 attendees, this is well known and not disputed. It’s a shoulder shrug … sure, we all know that.
There are, however, two questions that the ICSsec community should revisit and grapple with:
1. What cyber related risk is being tacitly accepted by the insecure by design nature of sensors and actuators?
This is a complex question worthy of a podcast and a number of articles. The vast majority of these sensors and actuators today are deep in the ICS with serial i/o connected to a PLC/RTU/controller. If someone can access the sensor or actuator over the OT network, would they need to bother to attack the sensor or actuator? If they have physical access to the sensor or actuator, would a secure sensor or actuator even make a difference in risk?
When these sensors and actuators have IP addresses, and the features that tend to come with this, the cyber related risk increases. There are surely other sensor and actuator model and process use issues that also affect the risk. Any look at cyber risk would need to break the sensor and actuators into categories.
The ICSsec community has largely ignored the security of sensors and actuators, but not because there was any believe they were secure. Rather it was due to a belief that the cyber related risk to an attack on the sensors and actuators is very low compared to the cyber related risk of other areas, such as the cyber security perimeters (ICS/corporate, ICS/safety), computers, ICS applications, PLC’s, network infrastructure, …
Joe is challenging this belief, and I’m interested in a discussion on whether the belief remains true given the progress made in the last 5 years. I’m inclined to believe the sensor / actuator security is still far down the prioritized list for efficient ICS cyber related risk reduction and would not be prudent risk management, and I’m happy to listen, look at the proponents threat model, and be proven wrong.
2. What solution is possible to reduce these sensor/actuator cyber risks, and what risk reduction is achieved at what cost?
If the answer to question 1 is that we need to prioritize addressing cyber risk for sensors / actuators, or even a subset of these devices, then how do we do it?
If we were starting over, many of the features in the Secure PLC would be migrated to the Secure Sensor or Secure Actuator. And my guess is this is how we will first see security in new, high end, Ethernet connected sensors / actuators with signed firmware, secure boot, and eventually authenticated config commands. I
Securing the huge legacy installed base and even new lower cost sensors / actuators makes the Secure PLC challenge seem simple. I’m very interested in proponents for securing legacy and low cost sensors / actuators to explain a technical solution, the cost, and the risk reduction achieved. Again I’m skeptical that this will make sense (and this comes from a lonely voice saying upgrading to Secure PLC’s should be moved up in priority over monthly internal patching), and again I’m willing to consider info on why I’m wrong.
If the issue is false sensor data, for whatever reason, I’m much more optimistic about machine learning on process variable data detecting when some sensor values or system state does not make sense. We’ve seen two great examples of this at S4 presentations.