2) Asset inventory is one of the first steps towards OT security – we cannot protect what we don’t know we have.

Here is an example of how misinterpreting the asset bites us. If we are to prevent theft or leakage of that information, it is vital that we know what and where that information is. We cannot prevent theft or leakage of information if (a) we do not know it exists or (b) we do not know where it is. An asset / information inventory is therefore one of the very first steps we must carry out if we are to design mechanisms to protect our information assets.

Biba, however, teaches us that information is the threat. This means that one of the very first things we must do is not inventory where our information lives, but rather inventory all of the ways attack information can reach our vulnerable OT systems. We need an inventory of data flows, most importantly those data flows that enter our OT systems from the “outside” – from potentially compromised sources. Understanding our perimeter and data flows that cross the perimeter is much more important than enumerating all of the countless “information assets” inside that perimeter.

Technical note: these perimeter-crossing data flows can be online or offline. Offline means the attack information lives in physical media, like USB thumb drives, laptops, or new computers arriving from our suppliers. We physically carry offline information into contact with our OT systems. Online information is more ephemeral – it is communicated into our systems with the movement of electrons, photons, electric or magnetic fields, or event sound waves – vibrations and quantum “things” rather than the movement of macroscopic physical objects.

Yes, eventually we will probably also benefit from an inventory of computer & information assets, but for most of us, our first priority is to prevent or control the movement of attack information into our systems – not protect that information, for example by encrypting that attack information.

3) If only we could wave a magic wand and patch everything and zero-trust everything, just like we do our IT networks, then our OT networks would be “secure.”

In most OT networks, the worst credible consequences of compromise are completely unacceptable: things blow up and people die. Or long-lead-time physical equipment is destroyed, and production / infrastructure is down for months or years, not hours or days. In most IT networks, the worst credible consequences are undesirable, and sometimes material, but will not put us out of business. This is the essential difference between most IT and OT networks: we cannot “restore” human lives nor damaged equipment from backups.

This means that even if we could wave our magic wand and secure OT networks exactly as we secure our IT networks, then our OT security program would still be woefully inadequate. The worst credible consequences (credible = reasonable to expect) define the required strength of our security program. When consequences are unacceptable, we need to protect our OT networks much more thoroughly than we protect our IT networks. Our postulated “magic wand” is not nearly enough.

Summing Up

Don’t get me wrong – I’m not saying information is never an asset (robotic programs in discrete manufacturing can be very valuable), nor that asset inventory is useless, nor that IT-style security mechanisms, where we can manage to apply them in OT, are pointless. What we’re talking about here is priorities. If we apply the world’s very best “protect the information assets” IT security program to OT systems, we might, accidentally, prevent material sabotage of physical operations. And we’ll probably spend an enormous amount of money doing that.

Moreover, no security program is complete until it has all the pillars of the NIST CSF: govern, identify, protect, detect, respond and recover. I’m not saying to ignore any of those pillars. To one extent or another, we most often need to “do it all,” but in which order, and where should the funding / implementation priorities lie?

What I am saying is that if we understand our priorities and constraints more accurately, then we can do a much more effective job of all of the above, for far less money.

What is IT-grade protection? Imagine a long suspension bridge has dangerous harmonic frequencies – people simply walking over the bridge risk setting up oscillations that build up, eventually to the point of tearing the bridge apart. See the 1940 Tacoma Narrows disaster for an example. Imagine that a bridge you cross every day on the way to work has this problem, and so is stabilized by hydraulic dampers – multiply redundant dampers, redundant power supplies and “secure” control systems. How happy would you be driving across that bridge every day if you knew the design engineer HOPED that, if there was a cyber attack on the control system, HOPED we could detect the attack before the bridge tore itself apart. How happy would you be knowing the design engineer HOPED that, if we detected the attack in time, HOPED we could scramble an incident response team fast enough to prevent disaster?

Hope is not what we expect of design engineers. we expect bridges to carry a specified load, in a specified operating environment, for a specified number of decades, with a large margin for error. Engineering-grade solutions, like over-pressure relief valves and unidirectional gateways, behave deterministically, no matter how sophisticated a cyber attack is launched at them.