If we don’t want to be like the Iranians and get Stuxnetted, take these 4 steps

If we don’t want to be like the Iranians and get Stuxnetted, take these 4 steps

By John Scott

Best Defense guest columnist

It’s Wednesday, and that means another story about the looming threat of cyberattack, how vulnerable the United States and its infrastructure is, how bad the Chinese are, how to retaliate, etc. But what seems to be left out of the discussion is what can practically be done about it (beyond scolding bad people). 

The first thing that should be done is to shrink surface area for attack. What does this mean? Right now the U.S. government and industry runs a pretty homogenous set of operating systems and applications that have shown to be a big part of the problem; specifically, Microsoft and Adobe are two companies whose wares have become amazing attack vectors. Why? For a few reasons: 1) if you want to create a virus/exploit weapon you tailor one for largest adoption, 2) attack large morphing code bases that give rise to known-unknown software vulnerabilities, and 3) updates don’t always filter out in time once new vulnerabilities are detected and patched.

A great example is how Stuxnet is reported to have entered the Iranian nuclear program: 

The main (and initial) infection vector is the transmission of the Stuxnet malware via USB devices: if an infected USB device is inserted into a clean PC and later accessed with the Windows Explorer, then the infection of that PC is triggered. This is due to either a malicious ‘Autorun.inf’ file present on the USB device (for the oldest variants of Stuxnet) or to the usage of the ‘LNK’ Windows vulnerability (MS10-046,CERT-IST/AV-2010.313 advisory) for the variants found in June 2010.

The Iranians were probably running older versions of Microsoft operating system software that wasn’t updated (and was probably pirated to boot). Further, the Iranians were a victim of Microsoft’s business model of stitching together source code to lock-in users and conversely lock-out other software, which allowed the virus carte blanche access to anything. 

So what should we, the government, or private companies for that matter, do? First thing, we’ve got to get our own house in order to limit our vulnerabilities (or "know thyself," to paraphrase Sun Tzu).

  • First, get rid of software for which we have to continually make excuses. Just as the U.S. military doesn’t promote smugglers (Han Solo) and farm boys (Luke Skywalker) to general, stop deploying software that requires additional fixes and comes stitched together. Microsoft and Adobe might be less expensive software, but if it leaves a backdoor open, is it really "cheaper"?
  • Second, only install operating systems and applications where the source code is available for widespread public inspection. Keeping source code secret increases its widespread vulnerability to exploitation when a defect is detected.
  • Third, increase heterogeneity of operating systems and applications to create gaps so that a virus/exploit can’t transverse between different systems.
  • Fourth, fund research into more secure operating systems and make the fruits of that investment public: A rising tide lifts all (security) boats. A small investment in maturing source code can have a large impact. 

John Scott is a senior system engineer for Radiant Blue Technologies and was a co-author of Open Technology Development: Lessons Learned and Best Practices for Military Software (Department of Defense, 2011). He occasionally blogs at Powdermonkey.