Motley Moose – Archive

Since 2008 – Progress Through Politics

Flying Blind in Critical Infrastructure

Crossposted from Infosec Island

[Note: “SCADA” and “ICS” are essentially interchangeable terms for “Critical Infrastructure”. ICS is “Industrial Control Systems” and it doesn’t really matter what SCADA means for our purposes here.]

The root problem with SCADA security is that control systems have been built on the concept that devices can be trusted.

Since everything else about SCADA is based on the concept that devices can never be trusted (“Sure, the temperature in the boiler should stay at such-and-such, but I would like to monitor the hell out of it, anyway.”), once you get your head around the idea that you cannot trust your cyber devices either you find that it fits with existing industrial ideology quite well.

The solution to industrial cyber security is to do your best to build a reliable cyber system – just as you do with the physical assets in the industrial process – then monitor it like a convicted criminal in solitary confinement.

Unlike physical assets which need to have monitoring bolted onto them, cyber assets inherently produce masses of telemetry. Ironically given the context, virtually none of this data provided freely by control system devices is ever looked at.

Imagine taking 99% of the data about the state of your industrial process and choosing not to make it available to your operators. Under normal conditions everything functions as it is supposed to, so concluding that you are in control might be understandable.

Only in the post-disaster analysis would you discover that (for example) there had been continuous out-of-spec pressures that led to the initial failure and subsequent catastrophic chain-reaction.

This is precisely what is done with cyber assets today. If you operate a control system network today the security of your ICS is almost definitely in a Rumsfeldian “Known Unknown” state: you know that you do not know if your ICS is under attack right now.

That probability waveform can only empirically collapse in one direction – only one of two “Known Known” states can be determined – and that can only at the moment bad things happen to your industrial process.

Lots of attacks (like the much-referenced Stuxnet, and most attacks today in IT) seek to hide themselves. On control system networks that is trivial: any first-year hacker that actually got caught on almost any ICS network deserves to have their keyboard taken away.

Illiterate tundra farmers with bilateral frostbite could learn how to lurk undetected on your ICS network in less time than it took to write this article.

All of the efforts to secure devices attached to ICS networks are good and necessary. But we have to get away from the idea that we have secured any device and can therefore trust it. Monitoring can be done in many places in many ways that will not have a negative impact on the industrial process itself.

It is interesting how the cyber component evolved in industrial environments in a way that flew under the radar for so long. A pump would not be installed without monitoring in these facilities, but the system to monitor and control the entire process is, itself, entirely unmonitored.

I’m an old SIEM guy so I think like this all the time, but the parallel between SIEM and control systems struck me very early on. They are effectively the same thing: systems for monitoring and managing complex environments.

SIEM is about “Knowing what you have and what it is doing” and being able to do something about it. Control systems are essentially the same animals.

Basic monitoring of almost any type would catch Stuxnet (“Hey, when did we allow peer-to-peer networking on our ICS?”). Event messages (syslog, SNMP, …) from devices between HMIs and PLCs will show the traffic across the network. A SIEM sensor on a span port will do the same.

Combine those with some IDS and you can now do protocol analysis. Do something with host security (HIDS, WMI,…) and now you can see what is going on at the server/HMI level.

For remote access, add access device telemetry (from the VPN terminator on the ICS network, for example) and you will be able to see when folks come inbound and, depending how you do it, what they are up to. Gather telemetry from the remote device (smartphone, laptop,…) and you again have a deeper view into what is happening.

Most attacks today are not brilliant and will be visible to anyone who looks for them. We need to drain the swamp, at the very least, so we can stop worrying about every fifteen-year-old with spare time. Just securing devices won’t do that for us (fifteen-year-olds will know about vulnerabilities before you do) but simply paying attention will.

Gathering and processing telemetry as a practice finds itself deeper into the operational stack than just detecting and stopping rogue access, though. Policies can be implemented as rules in the monitoring system.

Cause and effect and the sequence of events can be verified and if need be enforced (“Person with Role A can only perform Task B from Location C, but never in Scenario D.”). The ability for facility operators to gain back the control of their controls is easily within reach using existing technologies and methods.

I understand how and why we got to the place we are today – and it was not anyone’s ‘fault’ as such – but it is nonetheless unacceptable and needs to stop. Now.

The only thing left to blind fate in industrial processes are the systems that control them.