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 .