How Stuxnet changes the security game

New attacks could cross the 'air gap' to systems not connected to the Internet

By (ISC)2 Government Advisory Council Executive Writers Bureau

Mar 21, 2011

In November 1988, the first computer worm indiscriminately propagated through 6,000 Unix systems, or roughly 10 percent of the computer systems on the Internet. Although developed with innocuous intent, this worm had the ability to duplicate itself repeatedly in a given environment, ultimately causing the affected system to fail.

Roughly 22 years later, the Stuxnet worm emerged as a technological advancement with the potential to cause an unimaginable impact. Many have heralded it as a paradigm shift in the cyber threat landscape because of its precision targeting, as opposed to indiscriminate destruction. Instead of attacking every system it enters, Stuxnet is designed to only subvert specific Supervisory Control and Data Acquisition systems.

While using common operating systems and networking components, SCADA systems have traditionally been air-gapped from the Internet to pre-empt such attacks. In the case of Stuxnet, the worm was able to bridge this gap through targeting specific systems and using removable media.

Given the potential damage this malware advancement is capable of causing, security professionals need to re-evaluate their perceptions of risk and challenge their preconceived notions regarding segmented networks and critical infrastructure.

In order to stay on the cutting edge of threat advancement, security practitioners traditionally have sought the newest tools and techniques that would provide greater insight into how to build and manage secure networks. Tools employed in recent years to maintain that edge include Intrusion Prevention Systems and Data Loss Prevention suites.

However, it is important to consider that a shift in focus from basic security practices to more sophisticated implementations such as IPS or DLP can often allow the “urgent” to overshadow the “fundamental,” from both a security posture and budgetary standpoint. There is evidence that, although Stuxnet was designed to circumvent our industry’s leading security technology, it might not have been as far-reaching if certain fundamental security controls had been in place.

In order to gain a foothold in targeted networks, Stuxnet used multiple zero-day vulnerabilities and advanced targeting techniques, along with the more traditional methods such as the “USB autorun” feature, “known” and “patched” system vulnerabilities and default passwords in commercial-off-the-shelf (COTS) products.

Although simple mitigation solutions, such as a recently issued Microsoft patch, can turn off the USB autorun feature, this patch might never have been applied to the systems that were affected by Stuxnet.

Critical control systems and those that are not connected to the Internet are often left unpatched, either because it is difficult to fully test the patch and ensure that it will not affect normal operations, or, in the case of systems not connected to the Internet, because it’s assumed that those systems are not subject to outside influence and are therefore protected.

In either case, CIOs should work with their chief information security officers, system architects and operators to ensure that best practices are employed to protect their systems.

Additionally, after it was discovered that Stuxnet was exploiting default passwords, the SCADA system vendor issued guidance to its customers requesting that they refrain from changing default passwords because they were hard-coded into the products and could cause their systems to fail if changed. This recommendation contradicted the traditional practice of changing default passwords upon installation of commercial products.

Security practitioners found themselves in the challenging position of having to decide which risk was greater, knowing that either option could cause significant service outages to critical systems. The use of hard-coded passwords in network or SCADA components can harm a system’s security and may not be easily remediated.

In some instances, if a weakness of this nature is identified in a COTS product used on a network, the product vendor can update the system or develop an alternative method to meet the immediate security needs. In other cases, the "fix" is offered as part of the next system update.

The issues highlighted above represent only a few of the considerations that security practitioners should take into account in light of the Stuxnet attack. Moving into the future, organizations will need to re-evaluate baseline controls and reconsider assumptions about computers not connected to the Internet and the potential consequences of an attack that can traverse the air gap to segmented networks.

Yet another consideration that is not easily remedied is how Stuxnet undermines our underlying trust in sensors for critical systems. Once Stuxnet infects a target system and is operational, it has the ability to intercept and modify sensor signals that would otherwise notify the system operator that an error had occurred.

Without this insight into system anomalies, and with operators effectively blinded, Stuxnet is able to wreak havoc on critical control systems. If this same tactic were employed by other malware in a major enterprise, which data source could be trusted? Would intrusion detection and prevention systems be immune, or would they actually create a false sense of security?

While not comforting for officials charged with deploying and securing information systems, these are the realities that must be addressed in the wake of Stuxnet.

About the Author

Members of the (ISC)2 U.S. Government Advisory Council Executive Writers Bureau include federal IT security experts from government and industry.

inside gcn

Reader Comments

Fri, Mar 25, 2011
Eric Byres
Vancouver Canada

First , I would like to say that I agree with the premises in this article. As ICS security professional, former Siemens rep and someone who has spent much of the last year dissecting the Stuxnet threat, it is a game changer. The techniques that the worm's authors used are interesting and clearly designed not to be easily detected using normal techniques. For example, Stuxnet used RPC for all of its P2P comms and many of its exploits. RPC is also an essential protocol for the Siemens WinCC and PCS 7 systems to operate.
This was probably deliberate on the part of the worm’s designers – they knew they could count on this protocol run on their victim’s Siemens system. They could then piggyback on it without suspicion. Even if a user was suspicious, they wouldn’t dare block the RPC protocol because blocking it could shut down their entire control system.
For anyone interested, we discussed these techniques in some detail in the paper "How Stuxnet Spreads - A Study of Infection Paths in Best Practice Systems" at http://www.tofinosecurity.com/how-stuxnet-spreads. Note that you will have to register to download this paper.
Now I do have two minor issues with the paper. First, from March 2010, Stuxnet did not use the AutoRun technique to exploit USB keys. It used the *.lnk vulnerability, which would could not be addressed by normal USB management practises.
Second, calling the Siemens passwords issues "default passwords" is misleading. These passwords are hidden from the user and hardcoded into the Siemens systems. Siemens' error was to assume that no one would be able to discover these passwords and for 99.99% of their customers, this was correct. Unfortunately for Siemens, Stuxnet's designers were not normal users. To this day, these password issues are present and the end-user can do nothing to address them.
Other than these two minor issues, this is a good article.