Until mid-July, malware attacks on the SCADA control systems – such as those that power grids use – was just considered to be one of many HILFs, such as EMP, nuclear war, or "Acts of God," such as wildfires and earthquakes.
Not anymore. While experts such as ESET's Randy Abrams discuss the questionable intent of the involved parties, there are some immediate lessons which can be put into action items for CIOs to consider.
Lessons learned from Stuxnet
Let's turn this around and see how a CIO or IT manager could defend against a similar, sophisticated threat.
Threat vector: USB and other removable media
Stuxnet was designed to breach security through a USB drive. Malware's use of autorun is well documented and many AV solutions have long provided methods to disable this throughout a network. Unfortunately, aside from writing a password down on a sticky note, removable media remains the single most fallible human element, and is often infected directly from the manufacturer.
People love their removable media and unless autorun is turned off, your systems will remain vulnerable. That's a fix any IT manager or CIO can do today – most quality AV solutions allow disabling autorun network-wide through the administrator console. This isn't enough, says ESET's David Harley.
Research indicates this is not much of a mitigation. The code will still be executed without any action on the part of the user once that folder is opened to access whatever legitimate files are on the device.
Your fix: Aside from disabling autorun, restrict user permissions and block SMB connections on the perimeter firewall to lessen risk from file shares as a defense in depth.
Article: Learn Seven Ways To Keep HILFS From Crashing Your Party
Target: Siemens and SCADA control software
There is a default password within the targeted software and Stuxnet was built to keylog this password. This old-school security violation may be considered lax, but the worst part was that changing that default admin password could completely disable the control software.
The SCADA manufacturer Siemens listed a workaround of logging in with Power User rights to avoid the Stuxnet keylogging portion until their security update was made available here.
My assessment is that had the malware been written to simply use the default password instead of keylogging it first, this would have been an entirely different and much worse story to write. I think the malware author was smart by half; they built the malware to address the inevitable change of admin password instead of capitalizing on the speed of the attack.
Your fix: Kill all default passwords, period. Make a list, server by server, and make sure they're all regularly changed. For vendors who recommend not to change the default password, address with the vendor directly.
Exploit: Microsoft zero-day
With an operating system zero-day exploit known as CVE-2010-2568, there were concerns.
Often there are only days between the initial release of information regarding a critical vulnerability, and the discovery of its exploitation being executed in the wild by malware authors. It is safe to assume that more malware operators will start using this exploit code in order to infect host systems and increase their revenues.
This exploit now has a patch available from Microsoft. The threat remains, as Eric Knapp points out:
The hard cold truth is that vulnerabilities will always exist, and the nature of zero-day threats are that we often donít know about the vulnerability until itís been exploited, and that exploit has been detected.
Your fix: Zero-day attacks are inevitable, and are vendor agnostic. The best defense is a layered one with a top heuristic scanning product. (Shameless plug for NOD32).
Social engineering: VeriSign digital certificate
The organization which created Stuxnet also took pains to either steal or falsify a certificate which has since been revoked by VeriSign. Context of this comes directly from ESET's Pierre-Marc Bureau:
We rarely see such professional operations. They either stole the certificates from at least two companies or purchased them from someone who stole them. At this point, it isn't clear whether the attackers are changing their certificate because the first one was exposed or if they are using different certificates in different attacks, but this shows that they have significant resources.
Your fix: This is a tough one, as tough as detecting a forged ID card for a bartender or detecting a forged signature for a bank teller. I would welcome comments from the community on how you would not trust what we've all been trained to trust.
Post your thoughts!