Yesterday I guest blogged at Control Global about remediation steps for process automation networks and I've been thinking some more about the topic.

I suspect that while this particular attack seems to have been deliberately designed to attack specific Siemens infrastructure using known Siemens weaknesses (hard coded passwords, inappropriate admin rights etc.) there is absolutely nothing about this that means that it applies only to Siemens - indeed recent news indicates that a new payload is being delivered that may do different things.

The key here is that the payload, and new variants of the worm spread because the worm can "call home" so while the initial attack seems to have done nothing to systems that were not Siemens WinCC devices apart from spread, there is no reason to assume that this will continue. Thus, as I said in that post, and as we say repeatedly on this blog, it is critical that organizations reconsider the "default allow" rule for outbound traffic that is in probably the majority of firewalls. Sure some firewalls block traffic out except on certain ports (e.g. HTTP), force traffic to pass through proxies, or block traffic from certain core data center servers/networks but very few actually look at the destination of traffic leaving the network.

There is an argument that says that SCADA devices should never be able to connect to the Internet and this is in many cases true. However the way that buildings have been wired up and ip networks/addresses configured it can be almost impossible to tell whether the computer trying to connect to something on the Internet is in fact a piece of automation equipment or, say, the laptop of a technician who needs to download a product manual to do maintenance on the automation equipment. Best practice for IT departments is of course to separate networks for general use from those for specific critical functions and to not allow traffic from the critical networks to leave the building. However, unless these networks are blocked from communication with anything else - the "airgap" firewall - there remains the risk that these devices can be controlled by external hackers. If, for example, an engineer remotely logs into a device and controls it from his desk - something that I know happens in a number of places - then if that engineer's desktop computer becomes controlled by the hacker the hacker has access to the devices as well, albeit indirectly.

Hence, also, another reason why relying on the fact that the current versions of a worm are specific to certain industrial devices is to allow one to be lulled into a false sense of security.

On a slightly different note. In a number of cases people have wondered why Siemens uses known default passwords. Partly this is down to the fact that the products, and the product mindset, were for a closed, secure environment without access to the Internet. Partly it is down to the fact that even the slightest change could cause something to go wrong. This also explains why patching industrial devices is something that is not done frequently. If, for example, you are controlling a process in a chemical plant, then you probably cannot reboot the computer except after a laborious shutdown sequence that takes place once a year because doing so costs millions of dollars. Moreover if the patch turns out to have (say) a memory leak that manifests itself after 200 days, you are in big trouble because on day 201 you lose control of the chemical process and that may well cause a leak, explosion, fire etc. If a system is tested with user "X" password "Y" and runs successfully without falling over for a year then why take the risk that user "Xx" or password "Zz" will work too. What happens if there is a garbage collection failure that causes a few Kb to be lost each time the device remotely logs in and which is partially dependent on password length? if your new password is longer then that might be just enough to mean that the system runs out of memory in 340 days instead of 370, and thus that it crashes on December 15th instead of making through to the scheduled reboot on Dec 27..

Putting all this together, the simplest way to minimize the risk for the current network is to stop all computers in the network from "calling home" when infected rather than just concentrating on the SCADA ones. This gives you the breathing space to consider re-engineering your network so that critical devices are more effectively isolated.