Just to be clear, this is Walt Boyes here.
I have a friend named Francis Turner who is a security expert and Director of Sales for ThreatSTOP. He made some very good points about the Siemens vulnerability. You know, we really ought to stop calling it the Siemens vulnerability-- it could happen to any other vendor just as easily, because it is a Microsoft vulnerability.
Francis sent me a short post that I think is worthy of a guest blog spot.
“A Network Security Expert’s View of The Siemens Exploit”
The Siemens SCADA exploit demonstrates a number of critical weaknesses in the current deployment of network enabled automation systems. To put it bluntly people have seen the massive advantages of connecting tools and systems without thinking of the downside. It probably says good things about the human nature of the engineers involved that they assumed that most things could be trusted but, from a security point of view, it's also rather naïve. Not that they are alone in this delusion, IT vendors have persistently put cool new communication features ahead of security concerns.
The standard way that people have protected their automation systems from outside interference is via a firewall. Firewalls are great for stopping unauthorized traffic coming in - though to be honest a simple Network Address Translation (NAT) enabled router, like the one used by millions of ADSL subscribers, stops the vast majority of traffic. What NAT routers certainly do not do, and what firewalls rarely do well, is stop the outgoing traffic. Essentially firewalls assume that since it is almost impossible to identify malicious IP addresses they will block known bad applications, look for a few well known signatures of misbehavior and otherwise let the traffic pass through unimpeded.
Beyond the technical challenge, the other main reason why people have been somewhat lax about securing outbound traffic is that they did not think they had anything particularly valuable to lose. It simply did not occur to people outside of certain environments (e.g. Healthcare) that data from the average computer or automation system would be worth purloining. Hence while limits were put on servers talking to the outside world - or even to users internally - the rest of the computers on the network could talk with whomever they pleased, so long as they initiated the communication.
This is not a good idea, as the current exploit shows. What the malware is doing is "calling home" to the Command and Control (C&C) hosts of the cyber-criminals who deployed it. These criminals can then issue new commands (for example to get the compromised system to download a new piece of malware) and also analyze the data that the malware has sent them. This data analysis is almost certainly not a random shot in the dark as one might think. All the evidence suggests that this worm was deliberately coded to target specific systems and one would assume that it was initially introduced very specifically into its primary target location - apparently an enterprise in Germany. If the criminals knew what the factory made, which seems logical, then what would be sent is likely to be of great use in copying that factory and its output somewhere else. The fact that the worm now seems to have spread to other enterprises is merely serendipitous for the crooks in that they now have more information which they may, later, find to be of interest too.
The good news, however, is that it is possible to block the call home relatively simply because there are a limited number of criminal C&C hosts on the Internet and, while these hosts do change over time as older ones are shut down and new ones compromised, security researchers such as Shadow Server, SANS ISC or Dshield learn of the new ones very quickly because the hosts are not just used for industrial espionage. In fact these C&C hosts are clearly a valuable commodity and are used by their commanders to control many different sorts of cybercrime on what seems like a contract basis. So a host that one day is used to distribute spam, may next be used as a producer of "Fake anti-virus" software and then a week later used as the dropbox for industrial espionage.
Thus if a firewall blocks just these known addresses, and this list is updated frequently, then the computers inside the firewall are protected not just against industrial espionage but also against all sorts of other attacks. This can be done manually by employing a security administrator to monitor the output of the various security teams but this is tedious repetitive work that is better automated. The company I work for, ThreatSTOP, has a product that works with most firewalls to keep them updated against these threats automatically. We integrate the data produced by Dshield, Shadow server and so one into lists of IP anddress and networks that are known to be bad and which is updated every two hours. Subscribers to our service can update their firewalls frequently with a list of IP addresses and networks which are known to be bad. The list of bad addresses is fairly small - depending on which list a subscriber chooses and whether or not he adds some custom lists - the number of entries can be between a few hundred to about 20,000.
Clearly, much as I would like people to deploy my company's product, it is not a universal panacea, in fact it can only be a part of the defense which should have many layers. There are a number of other obvious security measures to be taken, the most critical of which is to address the distribution methods. This means securing (e.g. gluing shut) USB ports, drastically limiting NetBIOS and WebDAV shares and possibly separating certain critical systems onto their own dedicated and isolated network. The addition of network proxy servers that only support HTTP may also reduce infection as will the enforcement of far tighter external access rules in the firewall for automation systems.
Francis J.M. Turner
Director of Sales, Europe, Asia and Africa
ThreatSTOP™ Inc - http://www.threatstop.com/
