STUXNET fallout

Via my friends at Control Global, I’ve found and started to read the summary analysis of the STUXNET worm by Ralph Langner. Langner shows what looks like fairly strong circumstantial evidence that STUXNET was a deliberate cyberwar attack – presumably on the Iranian nuclear program, with possible spin offs to also affect nuclear research in other countries as well. Politically, this is fascinating stuff, but as this blog is about cyber security I prefer to look at some of the security issues it raises.

The first is that cyber warfare is no longer fiction. Anyone who is in charge of security for a piece of infrastructure (power station, railroad, pipeline etc.) has now had a warning that that infrastructure is a potential target from a hostile power.

The second is that it is quite clear that, as I blogged during the initial STUXNET coverage, there probably isn’t any simple way to harden the process automation equipment itself. There are just too many embedded default passwords etc. etc. and this applies to all such equipment from pretty much all vendors and in multiple markets from biotech to industrial control. I have no doubt that vendors and resellers are investigating fixes but the risk of introducing bugs by changing things is high enough that deployment of updates will be a slow process.

Thirdly, now that the exploit is out there other people can use it for other purposes – blackmail from criminal organizations for example. It would be, for example, a relatively trivial modification of ZeuS to make it perform specific actions if it detects the existence of certain device drivers etc. ZeuS already has the ability to call home and let the botmaster destroy the OS on demand, it could also clearly do other things too.

Fourthly – and related to three – the initial STUXNET attack seems to have been very carefully crafted to a specific target controller and not cause widespread harm on other systems. However, there is no reason to assume that a criminal created derivative will be as discriminating. Even if it is done by accident, if it trashes the wrong controller the wrong way huge damage could be done.

Probably the best way to ensure that critical infrastucture is protected is to err on the side of paranoia and block traffic out to all locations except for a few specific ones from the control networks. However since it is quite possible that a host in an adjacent network will act as a relay, it is not as simple as just blocking access from the control networks to the outside world. Other additional steps probably need to be performed such as the banning of non approved devices (smartphones for example) on the organization’s networks and probably serious consideration of the disabling of all USB drives – as has in fact been implemented by the US military and some financial institutions.

Finally it is key to note that no matter whether this is cyber warfare or cyber criminality the infiltration is highly unlikely to do anything until it has been in contact with it’s controllers because widespread devastation in the wrong place just allows people to figure out the signatures and start blocking. This is where a tool like ThreatSTOP – which blocks access to known C&C hosts is key as it will help in mitigating the strategy. We will also, shortly, be adding explicit country lists so that it will be possible to only permit access to sites in, say, the USA. The combination of a geographic list and the standard block list will provide protection while still allowing legitimate traffic to remain.