I spent an hour yesterday listening to Dale Peterson’s podcast with Ralph Langner about the Stuxnet worm. I’ve complained in the past that Ralph jumps to conclusions and that his terminology tends to lead others to jump as well. So I was surprised to find the podcast to be a thoughtful discussion of issues surrounding the worm. I still differ with Ralph on several topics, especially speculation as to who will author the next advanced threat targeting control systems. Overall though, the podcast really is worth listening to, especially so for people considering where Stuxnet fits in their risk models. Details follow…
Part of Ralph’s terminology I dislike is his use of the term “reuse.” Ralph worries that various classes of adversary will “reuse” Stuxnet for their own purposes. I never felt this was credible – a group that spent as much on Stuxnet as its authors evidently did will not just let their source code slip out on the internet. It turns out Ralph and I agree on this. About 12 minutes into the podcast and in response to Dale’s questions on the topic, Ralph clarifies: by “reuse” he means “reuse the concepts,” not “reuse the source code.” The “reuse” Ralph talks about is accomplished by reading and understanding the Symantec Stuxnet dossier. I still don’t like term “reuse”, since I think it means “source code reuse” to most readers and listeners, but I agree that the concepts we saw employed in Stuxnet will recur in new attacks.
Another bit of terminology that bothers me is “unpatchable.” Ralph applies the term to aspects of the design of Siemens Step7 components. He uses the term for designs which are hard to change without introducing incompatibilities into new versions of the control system product line. I agree with him, but I think the term tends towards sensationalism. Take for example the Windows operating system. There are many aspects of operating system that are fundamental designs. When malware uses those features, nobody calls them “unpatchable.” Eg: privileged Windows processes can completely control other processes, even to the extent that the privileged processes can load DLL’s into those other processes, or otherwise change the code they execute. Is this “unpatchable?” By Ralph’s definition yes, but nobody else uses the term.
The good information in the podcast comes to a head for me when about 47 minutes into things, Ralph says that before Stuxnet, the industrial security community really had not seriously considered advanced threats in their risk models. I have to agree. The most sophisticated customers I spoke to before Stuxnet had thought about adding advanced threats to their risk models. However, they could not make a business case for the change because there had never been a confirmed, advanced threat designed to sabotage an industrial process. This has obviously changed.
Where I disagree most with Ralph is his description of what kind of adversary he thinks will craft the next advanced threat to control systems. Ralph a couple of times mentions “hackers, organized crime and terrorists” as the agents he worries most about. Myself, I rank the spectrum of possible sources of advanced threats this way:
- Boasting-rights hackers: don’t have the resources to produce advanced threats.
- Disgruntled insiders: don’t have the resources to produce advanced threats. They have credentials though, which is an entirely different problem.
- Organized crime: can’t reliably make money with a weapon targeting critical infrastructure. In the control system space, extortion is unreliable as a source of illicit revenues, and so is every other scheme I’ve heard proposed.
- Terrorists: to date prefer spectacular attacks over silent sabotage of industrial processes. In addition, it is not clear that any terrorist group has the means to pull together a large team of experts in so many diverse fields, with supporting hardware and software, long enough to produce an advanced threat.
- Nation-states: appear to have been behind the Stuxnet worm. Many nations have admitted to substantial funding for cyber-warfare capabilities. I think it is these actors who will be behind the next advanced threat targeting industrial sites.
That said, I do take Ralph’s point that industrial exploits will migrate into malware-generating toolkits over time, and that less-skilled actors will be able to use these tools. My point is that nobody using cookie-cutter tools is going to produce something advanced. Conventional security precautions should be enough to detect and frustrate cookie-cutter threats. Of course that assumes that more industrial sites start deploying conventional security precautions.
Ralph did include a plug for his new PLC programming consistency checker, but he was candid about limits of the tool when Dale pressed him on it. The tool is not perfect, but it has value as part of a defense-in-depth posture, as do many other kinds of technologies. As I’ve written in the past, I think new HIPS technologies in particular hold a lot of promise, as does greater use of a variety of kinds of network and host intrusion detection tools.
I very much agree with Dale’s observations on PLC authentication mechanisms. Ralph observed that better controls on access to PLC programming mechanisms would likely not have deterred the authors of the Stuxnet worm. They could have found the required credentials and used them, or intercepted legitimate programming access and subverted it. Dale responded by pointing out that better controls would have slowed down the authors of the advanced threat – every layer of defense is one more thing malware authors have to overcome.
Looking forward, I think Dale’s last few observations are sobering. He pointed out that we have a fighting chance of protecting industrial sites against boasting-rights copy-cats. The real question is whether any security program can expect to protect a site against a concerted attack by military and/or intelligence agencies, especially when those agencies use a combination of malware and conventional intelligence techniques. Protecting a site indefinitely against a patient, resourceful and determined adversary is a real challenge.
The bad news is that it seems only a matter of time before new advanced threats target control systems. Security teams at sites important enough to be targeted by advanced threats need to exercise due diligence. Such teams need to seriously consider bolstering HIPS, IPS and IDS technologies, as well as security programs overall. Yes, protecting against advanced threats is not easy, but in the face of advanced threats, due diligence demands much better security than is the current state-of-the-practice at most industrial sites. In addition, security teams at less critical sites should anticipate that control-system exploits will become part of malware-toolkits. We will start to see more conventional viruses and worms with the ability to disrupt industrial systems. Security programs at most sites will need to improve to prevent disruptions to production.