Each week seems to present a newly discovered strain of malicious code targeting a high-profiled corporation or system vulnerability. This week is a malware program targeting Siemens WinCC SCADA systems, which hides on USB storage devices and uses a Microsoft security breach before activating a Trojan. While Siemens is taking necessary precautions to inform customers about the potential risks of the virus, its recommendation to use traditional virus scan programs from companies like Trend Micro, McAfee, and Symantec makes me wonder whether this is really an effective solution at all.
First, while Siemens says these security solutions can detect the Trojan, then why wasn’t it stopped by customers using such antivirus software in the first place? Since there has not been an example of malware targeting control systems to this point, in all likelihood even if the antivirus was fully updated the Trojan would have got there anyway.
Second, if their customers weren’t using such security solutions, then why in the world not? In our interactions with customers in the energy space, the answer is that many process control systems — which this particular malware targets — can’t handle the weight of antivirus solutions or be online to get regular signature updates because of the impact they have on system performance. This point was reiterated by our friend, Dale Peterson, who recently wrote in his article, “Trojan Targeting Siemens and APT Thoughts,” that:
“… many control systems today have little patching, minimal security configuration, shared and default user accounts, … So it is likely that the attacker has compromised multiple systems in multiple ways if they wanted persistence.
This begs the question that once targeted malware has been detected and removed, how do we know that an attacker’s presence has been entirely eradicated from the system? With antivirus software, we don’t. As I mentioned in the recent post, “U.S. proactive cybersecurity measures lack proactive solutions,” reactive solutions cannot stop persistent attacks. Unfortunately, this is yet another example of a reactive approach to a proactive problem.
The bottom line is the recommended virus scan programs are the same ones that have caused the problem either by missing it in the first place, or the fact that control systems simply can’t use it to protect their environments. Either way, antivirus is not a viable solution for stopping exploits that can maintain a stealth-like presence in a system. Until a network can completely stop the payload from executing, malware variants will continue to penetrate systems and gather information that is of the most value to them.
Let me preface my remarks by saying that Siemens made a very bad mistake here by installing a backdoor account and password. They must have known better and I guess for whatever reason they chose not to deal with the problem. However, the problem exists, and we need to consider a tactical solution that is minimally invasive that still gets the job done.
I need to remind everyone that we are not dealing with an office application. Different security policies apply; Remember that there are high energy processes that these machines control, and we need to make damned sure that nothing else goes wrong with whatever changes are made. THAT’S why patches are so infrequent. They have to be tested. The testing involves physical processes, windshield time, and the logistics of configuring processes or distribution systems in to an appropriate condition where testing can be conducted safely.
Strategically, Siemens made a very foolish mistake. The problem is that we have an immediate tactical need to get some kind of defense in to the field. The obvious first step is to isolate the network. It wasn’t so long ago that we used to put the data a clipboard with paper and re-enter it on the office computers. The volume of data the office NEEDS isn’t that high. Most could survive with going back to the old ways of handling the data if they needed to. Second, for those applications that simply can not work without constant real time data (Who thought THAT was a good idea?), there is that security bulletin from Microsoft that explains how to edit the registry so that shortcut icons are not read and instead display as a default. It makes for an ugly desktop and menu system, but it still works. This is an appropriate first step. There will have to be others to follow up on this issue, but for right now, this is sufficient.
In a control system pushing patches and hoping for the best will get you fired. Perhaps one might get away with that in an office and if anything goes wrong, revert to backups. The difference here is that physical processes are attached to this computer. Physical things will go wrong if the patch doesn’t work right. If you spray a patch on a control system computer and cause it to crash, people could get hurt or killed. THERE IS NO BACKUP TO RESTORE A LIFE or LIMB lost to an accident of this sort. Even if you’re 99.9% certain that “this ought to work” you still need to test.
Siemens knows their customers. They’re taking a tactical approach to the STUXNET virus. While I can’t speak for them, nor do I know their plans, I’m almost certain that they will have other updates coming later to address the strategic issue of that back door user account and password.
Remember, this is not an office application. This is real life. There are no backups.
Automation systems will continue to be vulnerable for the many of the reasons in Jake’s post.
Policy that fails to prevent use of ‘dirty’ USB drives in the first place seems just as important. Was there an awareness program, was policy ignored? Or this is just another example of persistent human weakness.
Whilelisting can certainly help enforce a good change management regiment. However it’s likely packaging for STUXNET was good enough to fool many administrators into allowing the code to execute.
I’d like to see more analysis of opportunities in software supply chain assurance.
The exploit propagated by malformed .LNK files and .TMP files on the drive. An administrator may not notice these files on the USB device. However, all decent whitelisting solutions would be able to easy stop this attack because the binaries are not on the whitelist.
If the purpose of attaching the drive was part of a normal update process it seems fair to suggest the admin would allow the update (from what appears as a reputable source) to run.
Of course not all procedures involving USB devices are part of a change management workflow (eg. incremental backup).
Siemen’s mistake here was not in installing a backdoor. Based on discussions with engineers there I’m pretty confident that the backdoor was similar to those you can find in RSView, Wonderware or any other system you’d like to name. Their mistake was in not locking the door after the username and password were released into the wild back in 2008. After that it was just a matter of time until someone did something like this. Their other mistake was in not seeing that release would lead.
And patching is not as hard as you might think. I work at a facility owned by the government and we are required by law to maintain our systems at as close to current as possible. Once faced with that requirement it was a relatively simple matter of creating a testbed environment where patches can be subjected to maximum abuse before releasing them to a production environment. Can we test for every conceivable condition? No, but I can manipulate the systems through every critical function thousands of times much faster than I could in the real world. The remaining functions can be compared to the details of the changes and given a very high confidence rating. At least as high of a confidence rating as when I make changes to the application code myself. Was it cheap? No, but it is a lot cheaper than allowing someone the opportunity to take control of my systems and do damage. Am I confident that after our testing, and the vendor’s testing, that the patches I deploy won’t break my systems? Not 100% but I can say that I’m more confident than if I didn’t do the testing. When I read the early reports of this malware I was able to make the workarounds recommended by Microsoft, test the changes and deploy them to the production environment within 24 hours. No need to compromise what my customers want or worry that I was vulnerable.
It’s a new world out there that the automation industry has managed to ignore for quite a long time but, as this event has shown, we are not immune to the threats and we have to adapt. The first shot in the battle was pretty benign if you look at all the details of what it does but the next one will likely not be so easy to catch and block. The next attack might be to take a vulnerable system hostage and not release it until a ransom is paid. That’s already been done with database systems. If you think we can just pull in all of our network connections and isolate ourselves the way it was 10 years ago then you don’t know your customers. They want the real-time data on their desktops and web applications and if you can’t or won’t give it to them they will find someone who will. Take a look at the publicly available documentation from NIST, DOD and DOE on securing SCADA systems. It could save your career and possibly someone’s life.
Great blog – I especially agree with “This begs the question that once targeted malware has been detected and removed, how do we know that an attacker’s presence has been entirely eradicated from the system?”
Whitelisting is an option – and a good one – but this also highlights the need for better monitoring within control systems networks, in general, so that we can correlate everything together to find the clues needed to spot these types of threats. There will be other zero days, and any single defense can be compromised: it’s why defense-in-depth is still touted as a security best practice today. You can read more about that at http://bit.ly/dfofN3
[...] I’m still a fan. CoreTrace, maker of the Bouncer application, has a blog related to Stuxnet here. They continue to make inroads to the control system world. I know it’s not a cure-all but [...]
[...] I’m still a fan. CoreTrace, maker of the Bouncer application, has a blog related to Stuxnet here. They continue to make inroads to the control system world. I know it’s not a cure-all but [...]