How Stuxnet changes the security game

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.

Related coverage:

Stuxnet is not Superworm, researcher says

Stuxnet story is high-profile but still out of reach

Listen to an (ISC)2 podcast on Stuxnet here.

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.