Gartner: Security Lessons Learned from Stuxnet

(This article was originally published on the Findings From the Field blog.) I had opportunity to read the Gartner Security Lessons Learned from Stuxnet research note a few days ago. The note was encouraging in one sense: Gartner has a lot of influence with corporate decision-makers and it is good to see them covering control system and operations issues. The bulk of the note was useful – advice to take operations security more seriously, to put strong operations security programs in place and so on. But in the end, none of the “lessons learned” seemed drawn from the Stuxnet worm. The lessons seemed drawn from run-of-the-mill botnet threats that most businesses face every day, rather than from recent targeted threats, or the worm many describe as “the most sophisticated malware ever.” On One Hand: Good Advice The report did contain a lot of good advice. Sites were encouraged to evaluate their basic security precautions “for gaps that put you below due diligence.” The “due diligence” term is one CIO’s and CSO’s have a deep understanding of, and gaps with respect to “due diligence” are something they take seriously. The note also pointed out that there are often operational issues which lead to poor security processes. Enterprises using control systems though, are required by “due diligence” standards to address those issues one way or another, so that proper control system security levels can be maintained. Any discussion of defenses and of Stuxnet as an advanced threat should point out that Stuxnet is only one example of an advanced threat, and the Gartner note does this. There are many defenses that can deter advanced threats. The more valuable your information or physical assets, or the more likely those assets are to be targeted, then the more thorough you need to be in defending those assets. No defense is perfect though, and a strong security program uses many techniques to fend off both advanced and mundane threats. The note mentioned very briefly that whitelisting / application control / Host Intrusion Prevention Systems could have prevented infection. HIPS technology has been proven to catch the Stuxnet worm even in the months the mature worm circulated undetected, before patches, AV signatures or IPS signatures were published for the worm. HIPS/Application control technologies are particularly well-suited to industrial control applications and I think deserved more than one passing sentence in the Gartner write-up. Our experimentation with the Industrial Defender HIPS and the live Stuxnet worm proves the HIPS product would have prevented infection during the key months the worm circulated undetected. Whitelisting technologies generally, like HIPS and like network anomaly detection on operations networks, are much more likely to detect zero-day and “under the radar” threats than are “black listing” technologies like IPS, AV and even strong patch programs. But: Stuxnet Lessons Learned? The real problem I have with the research note is that many of the “lessons learned from Stuxnet” didn’t seem to apply to Stuxnet at all. For example: The statement Stuxnet damage could easily have been avoided with a strong patch program is incorrect. A strong patch program would impair propagation of the worm NOW, yes, now that patches are available. From March through June of 2010, though, when the mature version of the worm circulated without detection and there was a patch available for only one of the six methods the worm used to propagate. A strong patch program would not have significantly impaired propagation of the worm in those key months. The report suggests that use of IP address and DNS entry “reputation servers” would also have “easily avoided” damage from the worm. To my knowledge, no such server had identified the Stuxnet C&C DNS entries or IP addresses as malicious in the 3-4 months the mature version of the worm circulated before detection. Nowadays such servers can protect users, because the malicious IP addresses and DNS entries are known, but they would have provided no protection before Symantec and others started studying the worm in July. The Gartner authors name a handful of small security vendors specifically recommended as helpful for advanced threats like Stuxnet. The list does seem useful for deterring botnets, but it is not at all clear these technologies would have caught the Stuxnet worm itself. Ie: the worm does not use fast-flux DNS, does not propagate over the open Internet, does not target the kinds of applications that are routinely deployed on virtual machines, and it communicates with its C&C server only very rarely, and exchanges very little information with it. The advice to “make sure all default passwords are changed” when installing new Siemens control systems needs qualification as well. Users changing the default password on SQLServer databases used by Siemens software will break the Siemens applications. Siemens has its “secret” password hard-coded into the source code of its applications. Readers should have been advised to consult their vendor before attempting to change any password for which the vendor has not documented a password-changing procedure. Looking Forward… In the end, I have mixed feelings on the note. It is disappointing to see this many problems in a report from a respected agency like the Gartner Group. I’ve worked on the Industrial Defender report for the Stuxnet worm, and an update to that report is just about to be published by the way. When we say something about the worm in our report, we try hard to ensure what we say is as accurate as possible. When we say that a particular technology would have prevented infection by the worm, it is because we have tested that technology against the worm. This does not seem to be the case with the information in the Gartner research note. Gartner’s emphasis on aligning IT and OT security programs is very much the right message to send, though. Gartner presents the case for such alignment in ways that IT people understand and find compelling. But the advice needs to add a few caveats – OT deployments tend to consist of a comparatively tiny number of machines, but they control disproportionately valuable and often dangerous physical resources. Further, control system applications and communications are frequently not at all like IT systems. OT security programs must take all that into account, and any changes to OT systems must follow the often very strict OT change control policies. Note: there were some technical errors in the report as well, but I’m not listing them here because the authors have indicated that they are correcting those errors in a new version of the research note.