Failures of Common Wisdom

(This article was first published on the Digital Bond blog.) In preparing a paper on what steps sites can take to protect against sophisticated threats like the Stuxnet worm, it occurred to me that I had not recommended any of the steps that enterprise IT people consider “common wisdom.” I did not recommend these measures because they would have made little difference to the progress of the Stuxnet worm during the six months or so – January through July of 2010 – that the mature version of the worm circulated without detection. Patch programs: For months the Stuxnet worm circulated undetected, using six Windows and Siemens WinCC vulnerabilities to propagate. Only one of those six propagation techniques took advantage of a vulnerability for which a patch existed. Had a control system been fully patched for those six months, only one of the six propagation techniques would have been blocked and the progress of the worm through those patched control networks would have been slowed only somewhat. Patch programs were unable to protect against the five vulnerabilities for which no patch existed at the time. Anti-virus systems, with up-to-date signatures: Anti-virus signatures for Stuxnet were not issued until late July, after the mature version of the worm had circulated for about six months. Anti-virus systems have difficulty dealing with low-volume threats, and well-targeted threats. Anti-virus vendors tend to produce signatures for a version of malware only after the malware is discovered, and generally only after a critical mass of many hundreds of copies of the malware have infected the vendors’ honeypots. Encryption: The Siemens S7 PLC protocol is plain-text, but the worm did not make use of any of the usual sniffing or insertion attacks on plain text protocols. Instead, the worm compromised clients of the S7 protocol, and used the S7 communications libraries to interact with PLCs. Even if the S7 protocol had been encrypted, those libraries would have done the encryption and the worm’s commands would still have been sent to the PLCs. To be fair, some of these elements of IT “common wisdom” do help protect you against the Stuxnet worm today, now that there are patches for many vulnerabilities the worm used to propagate, and now that there are anti-virus signatures for the worm. Patch programs and AV technologies are useful to protect against older, wide-spread, and well-understood threats, but not against sophisticated, targeted threats. And encryption techniques, properly implemented, do protect you against attacks, like password sniffing, that some adversaries use, but Stuxnet didn’t need to. On the other hand, one of the tenets of control system “common wisdom” did not protect the control system either: Security by obscurity: The S7 protocol is not documented and is fairly complex. The authors of the worm did not reverse-engineer the protocol or try to emulate it. Instead, the worm simply compromised computers which were S7 clients and used the vendor’s own libraries to create S7 commands to manipulate the PLCs. One element of IT “common wisdom” which would have helped is improved application authentication and role-based access controls. If end users were challenged with passwords to access databases and PLCs, and those user names and passwords were tied to specific roles, the worm would have been significantly slowed. For example, plant operators and their HMIs need to read and write data from remote databases, but should not have permission to write stored procedures to those databases. Similarly, operators need to exchange data with PLCs, but should not be able to change function blocks in those PLCs. Controls like this would have limited the worm to using privileged accounts to propagate through databases and to inject function blocks into PLCs. This means role-based access control would have helped slow the worm, but would not have stopped the worm. Eventually, the worm would have found itself on a PLC programming workstation, logged into a PLC by a person authorized to change the PLC programming and would have had opportunity to inject the malicious function blocks into the PLC. There are technologies which would have helped protect against the Stuxnet worm, such as whitelisting, controls on the use of USB flash sticks, and vigorous electronic security perimeter controls, but even these technologies have their limits. The best protection against sophisticated threats is a strong defense-in-depth security program, with alternating layers of intrusion protection and intrusion detection. If you can slow down the attack and detect it, your response teams can shut the attack down.