Stuxnet Innovation Masquerade

With more than three decades experience programming calculators and computers, and three years experience as a Sr. System Engineer programming industrial PC-based real-time controllers, Programmable Logic Controllers (PLCs), and other SCADA systems, I would propose that Stuxnet was not particularly innovative.

To be more precise, Stuxnet was innovative, but the computer technology used by Stuxnet was not. This is an important distinction as our Nation and military services grapple with how to invest toward Cyber excellence.

Here is an inventory of the major components of Stuxnet:

1. Delivery Vector – The air gap was crossed not with high technology, but with patience, relying human procedural fax paux. Someone simply used a USB drive with an active delivery vector and payload package in an inffected computer and then the target computers on the other side of the air gap.  Technology was around for nearly 10 years before being used.
2. Environmentally Aware Code – a.k.a. the program was aware that code was running in proximity to hardware that responds in certain manners that give away it’s identity, model number, and possibly even serial number. This technology has been resident in commercial consumer grade products since approximately the early 1990s in the form of “device drivers” that automatically configure to “work with any printer” or “work with any network card”. The Linux programming community has formally recruited this type of programming since the 1980s for various projects such as video device drivers and the CUPS printer libraries. This technology has has been used by Microsoft ever since they began binding authentication to certain CPUs.
3. Modifying data streams – this is standard behavior of any scan-based data collector with asynchronous sources into and subscribers from the accumulated database. If one knows the addressable location of the buffers, it’s reasonably simple to serendipitously read and rescale or offset data such as rotation rates or temperature readings. I first did this in the late 1970s using a Texas Instrument Sinclair computer to create a video game.  This technique is commercially used to make non-similar modular hardware fulfill Interface Control Document (ICD) requirements. For example, a Celsius temperature sensing IC chip being retrofit into a software library that was written to accept Fahrenheit. The simplicity of PLC memory structures makes this possible for industrial software field technicians whereas a PC controller uses much more dynamic memory allocation, and requires a higher level of software module integration.
4. Knowledge of the Hardware – this is not so much a Cyber issue as simple HUMINT or otherwise gaining insights into an enemy’s supply chain – not very different than knowing which ball-bearing plants were supplying the manufactures of trucks and tanks in Hitler’s Germany.

What made Stuxnet powerful and innovative was the creative synthesis of different technologies – each on the open market and common. It was the sequence and aggregation of operational steps that made Stuxnet worthy of note.

If the significance of synthesizing simple “boring” technology into innovative operational sequences demonstrating powerful effect-based attacks escapes you, consider the destruction of the New York city trade towers in 2001. Nothing about those events were difficult or technically challenging (flying, aiming, energy density, security, etc). Yet the effect was huge at a National security level, even beyond military. Here is the sound-bit to remember: architecture-wise, Stuxnet was a Cyber version of 9/11.

Stuxnet was possible because of the interest and dedication to bundle capability with intended functionality with no purpose other than to corrupt a SCADA controller. The key point is that this is not hard to do, but it had not been done, nor was anybody interested in doing it prior to that time.

Because there is no commercial utility or market for aggregate capability such as Stuxnet, it had not been done. (The corollary is necessarily implied: if it was commercially viable, it would have been on the market years prior.) Only a hacker entity on the offense would have motive to do this and no organization has the overhead to choreograph the sequence if they are an individual, a nonprofit, or a for profit entity. The only entities capable and willing are hobbyist where it is pure entertainment and enjoyment, or organizations that can sink an inordinate amount of time for an important 1-off accomplishment. With Stuxnet we witnessed the second.

The implication of this train of thought is that to excel in the area of Cyber defense and weaponry, we do not need high dollar hardware or super software. Instead, we need people capable of synthesizing and integrating technology across disciplines and domains of expertise. I am reminded of the 1966-1973 Mission Impossible TV series.  “As the series was originally conceived, they would form teams made up of part-time agents who came from a variety of professions, choosing their operatives based on the particular skills necessary for the mission.”

If I were putting together a Stuxnet team, I would need someone capable of programming USB-auto-run logic (which was and still is available commercially with the U3 OS and was the installation default for Windows XP), an industrial PLC programmer, a warehouser or logistician familiar with different vendors’ hardware, a hardware technician good with data tracing and an oscilloscope, and a Windows-OS programmer. These communities and technical cultures typically do not talk with each other.

Cyber greatness is not dependent on new or exceedingly narrow PhD-level computer or network skills. It is more about interested parties integrating across disciplines and having reasonable amount (10-20%) of creative “what if” time in close proximity to other technical communities. Perhaps Google should become a Cyber weapon defense contractor.