The goal of Zero Trust is getting data securely across network, storage, and computing infrastructure you may not trust. The message is usually between two software entities that are trusted with human beings behind them.
But that’s not what happens in an Industrial Control System, such as a DCS or a PLC based plant system. SCADA systems are slightly different and I’ll get in to that next.
There is an element of implicit trust on the lower layers of an ICS network: One has to presume that it is suitable for real time performance. In other words, there is an implicit trust that the network will reliably deliver nearly all of the data within a certain window of time or your equipment will fault –as it is supposed to do.
As such, the Zero-Trust model on a real time network or a real time computing system such as a PLC is a non-starter. If you cannot trust a PLC to get its scan cycle complete or give you an alarm when it does not, then you have no basis for using that technology. Use some other technology that will give you the determinism and trust that you seek.
To be able to trust a device in the field, there needs to be an appropriate procurement method so that the device is from a trusted source and you have a complete chain of provenance documenting how it physically came to be where it is. Further, if there are any keys in the device, the person that installs or conveys the key also has to be trusted.
Ideally from there, there would be an even more detailed chain of data provenance. It would indicate not only where the PLC came from; but where the firmware came from and when it was installed, who configured and programmed it, what various software components it has (such as open source protocol stacks, libraries, etc.) and where they came from, right down to the physical instruments that measured the data, such as an RTD, or a pressure gauge.
That does not come from just one person. It comes from many. This is where identity management systems come in to play. And on a network that cannot tolerate a whole lot of extraneous traffic, this is not an easy thing to do.
As an aside, there are many who argue that the bandwidth of the network is far better today than ever before, so we should be able to afford a bit of “extraneous” traffic. Not so fast. In fact, bandwidth was not really an issue even in the past. The issue is latency. The mania from offices and security has always focused on bandwidth, often at the expense of latency. In a real-time system, the time from the measurement through all the network equipment and then to a device that can timestamp the value and sign it with some sort of provenance is the issue. That may not be a trivial piece of time.
Now consider SCADA: If you’re truly using an event oriented SCADA system, you have time to certify everything. You can hash, you can blockchain, you can gather up identity information, and so on and so forth. The reason you can is that the event is documented with a time stamp. It is already a fact; all you have to do is to document the provenance of how it got to the RTU.
Which brings me to my final conclusion about the architecture of the network and the point at which we can discuss issues such as Zero-Trust.
There cannot be Zero Trust in a Real Time system, but there can be Zero-Trust from an RTU in an event-oriented SCADA system. We need to consider how we design RTUs, SCADA protocols, and how we transmit the data across potentially hostile networks. However, the notion of using Zero-Trust for SCADA is valid and we should pursue it.
