In the days and hours leading up to the afternoon of 19 March 2011, air force planners in France, Britain, and several other NATO countries were frantically preparing an imminent bombing campaign against military targets in Libya. In Washington on that same March weekend an unusual discussion took place between the Department of Defense and the White House. Should America deploy its cyber arsenal against Libya’s air defense system?1 After the Pentagon’s generals and geeks had briefed the president on the options, he ultimately decided that the time was not ripe for cyber weapons.
This behind-the-scenes episode is part of a much larger debate about offensive cyber weapons. In September 2011, William Lynn, the US Deputy Secretary of Defense, warned, “If a terrorist group does obtain destructive cyberweapons, it could strike with little hesitation.”2 In January 2012, the Department of Defense announced its plans to equip America’s armed forces for “conducting a combined arms campaign across all domains—land, air, maritime, space, and cyberspace.”3 To counter a novel arms race, China and Russia, among others, have suggested discussing forms of “cyber arms control” to restrict new forms of military conflict in cyberspace.
But the debate and those trying to turn it into policy are getting ahead of themselves. Some fundamental questions on the use of force in cyberspace are still unanswered; worse, they are still unexplored: what are cyber “weapons” in the first place? How is weaponized code different from physical weapons? What are the differences between various cyber attack tools? And do the same dynamics and norms that govern the use of weapons on the conventional battlefield apply in cyberspace?
Cyber weapons span a wide spectrum. That spectrum, this chapter argues, reaches from generic but low-potential tools to specific but high-potential weaponry. A didactically useful comparison helps illustrate this polarity. Low-potential “cyber weapons” resemble paintball pistols: they may be mistaken for real weapons, they are easily and commercially available, used by many to “play,” and getting hit is highly visible—but at closer inspection these “weapons” will lose some of their threatening character. High-potential cyber weapons could be compared with sophisticated fire-and-forget weapon systems such as modern anti-radar missiles: they require specific target intelligence that is programmed into the weapon system itself, notable investments for R&D, significant lead-time, and while they open up entirely new tactics they also create novel limitations. This distinction brings into relief a two-pronged hypothesis that stands in stark contrast to some of the debate’s received wisdoms. Maximizing the destructive potential of a cyber weapon is likely to come with a double effect: it will significantly increase the resources, intelligence, and time required to build and to deploy it—and increasing a cyber weapon’s potential is likely to decrease significantly the number of targets, the risk of collateral damage, and the coercive utility of cyber weapons.
The chapter’s argument is presented in three steps. The chapter begins by outlining what cyber weapons are in conceptual terms. Then I suggest a way to class cyber attack tools by discussing the most important empirical cases on record. Thirdly the chapter explores why even some sophisticated and effective instruments of electronic attack cannot sensibly be called a cyber weapon. The chapter closes by pointing out how cyber weapons confront us with three problems. These three problems will largely define the future development and use of weaponized code.
Weapons are, simply put, instruments of harm. Since the dawn of time, humans have used weapons to hunt prey and each other. Weapons range from the nuclear warhead to the bare human body trained in martial arts, their utility ranging from destroying an entire city to protecting one single person. Yet practitioners as well as scholars often seem to take the meaning of the term “weapon” for granted. Remarkably, even the US Department of Defense Dictionary of Military and Associated Terms, an authoritative 550-page compendium that defines anything from abort to Zulu time, has no definition for weapon, let alone for cyber weapon.4 For the purposes of this book, a weapon can be defined as a tool that is used, or designed to be used, with the aim of threatening or causing physical, functional, or mental harm to structures, systems, or living things. This general definition is an essential building block for developing a more precise understanding of cyber weapons.
The term cyber weapon is much broader than cyber war. Cyber war is a highly problematic, even a dangerous, concept. An act of war must be instrumental, political, and potentially lethal, whether in cyberspace or not.5 No stand-alone cyber offense on record meets these criteria, so “cyber war” remains a metaphor for the time being. Not so in the case of cyber weapons. Weapons are not just used in war. Arms are used for a wide range of purposes: to threaten others, for self-defense, to steal, to protect, to blackmail, to police, to break into buildings, to enforce the law, to flee, to destroy things, and even to train, to hunt, and for sports and play. Weapons, of course, may also be used to make war, and some more complex weapons systems are exclusively developed for that purpose, for instance warships or anti-aircraft guns. But most weapons are neither designed for warfare nor used in wars. This is true also for cyber weapons. Therefore, while it is counterproductive and distracting to speak about cyber war, it can be productive and clarifying to speak about cyber weapons. Yet conceptual precision remains a problem—“There is currently no international consensus regarding the definition of a ‘cyber weapon’,” lamented the Pentagon in November 2011, elegantly distracting from the problem that there is no consensus inside the DoD either.6 For the purposes of this book, a cyber weapon is seen as a subset of weapons more generally: as computer code that is used, or designed to be used, with the aim of threatening or causing physical, functional, or mental harm to structures, systems, or living beings.
A psychological dimension is a crucial element in the use of any weapon, but especially so in the case of a cyber weapon, in two ways: the first psychological dimension is the offender’s intention to threaten harm or cause harm to a target. An instrument may be expressly designed as a weapon, like a rifle, or repurposed for use as a weapon, as in using a hammer to threaten or hit somebody.7 Simple as well as complex products can be used both for peaceful purposes and as arms. In the case of sole-purpose weapon systems as well as in the case of repurposed items, a tool is actually used as a weapon when an actor is intending to use it as such; whether harm is successfully inflicted or not is of secondary concern. A rifle, for instance, may be used to threaten; it may malfunction; or the bullet may miss the target. But in all cases the arm has been used because an attacker was intending to use it as such in a given situation.
The same logic applies to cyber weapons. An illustration of this is a remarkable event that took place at the Sayano-Shushenskaya hydroelectric plant in Russia. Keith Alexander, a general at the head of America’s National Security Agency as well as of US Cyber Command, used the incident in a speech to highlight the potential risks of cyber attacks.8 With a height of 245 meters and a span of 1 kilometer, the Shushenskaya dam is the largest in Russia, holding back the mighty Yenisei River in Khakassia in south-central Siberia.9 Shortly after midnight GMT on 17 August 2009, a 940-ton turbine, one of ten 640 megawatt turbines at the plant, was ripped out of its seat by a so-called water hammer, a sudden surge in water pressure, which then caused a transformer explosion. The turbine’s unusually high vibrations had eventually worn down the bolts that kept its cover in place. Seventy-five people died in the accident, energy prices in Russia rose, and rebuilding the plant will cost $1.3bn. The ill-fated turbine 2 had been malfunctioning for some time and the plant’s management was poor, but the key event that ultimately triggered the catastrophe seems to have been a fire at Bratsk power station, about 500 miles away. Because the energy supply from Bratsk dropped, the authorities remotely increased the burden on the Shushenskaya plant. The sudden spike overwhelmed turbine 2, which at twenty-nine years and ten months had nearly reached the end of its predicted lifecycle of thirty years.10 The incident would have been a powerful example of the use of a cyber weapon if intruders had intentionally caused the plant’s crash through a remote command (although to plan such an attack they would have required remarkably detailed advance knowledge of the plant’s long-standing maintenance deficiencies). But such an intention was absent. Intention may be the only line separating the attack from an accident.
A second psychological dimension comes into play if a weapon is used as a threat, or if its use is announced or anticipated: the target’s perception of the weapon’s potential to cause actual harm. It is important to note that the attacker may use a weapon as a threat, which may achieve the objective without actually inflicting physical harm; or the attacker may use the weapon to cause harm instantly, without threatening to do so first. Furthermore, a victim’s estimation of a weapon’s potential to harm is different from a victim’s estimation of an attacker’s potential to harm. To illustrate all this, a fictional scenario is useful: suppose an armed robber enters a bank and threatens the clerk with a paintball pistol; both the clerk and the robber assume that the paintball pistol is real and loaded with live bullets; money is handed over; the robber flees. Has a weapon been used? Arguably the answer is yes. This fictitious scenario is less anomalous than it may seem; it merely affords starker contrasts. The history of domestic and international armed confrontations offers plenty of examples where the aggressor’s power to cause injury was vastly overestimated, both by the defender as well as by the aggressor.11 The paintball pistol scenario inevitably leads to a seeming paradox: suppose the bank clerk noticed that the robber’s pistol could only shoot paintballs. Would it still be a weapon? The answer is no. The fake firearm would have lost its threatening character and have thus ceased to be a weapon, even if the robber still believed it to be real. The conclusion: a weapon’s utility critically depends on the perception of the threatened party. In every real armed confrontation, both the victim and the aggressor will hold crude theories of an arm’s capability to inflict harm and their own ability to withstand or absorb this harm. These subjective estimates will necessarily vary in their accuracy when put to a violent test. The actual weapon may be more or less powerful than assumed. In the case of cyber weapons, this discrepancy is especially large: publicly known cyber weapons have far less firepower than is commonly assumed.
Cyber weapons can be grouped along a spectrum: on the generic, low-potential end of the spectrum is malicious software—malware—that is able to influence a system merely from the outside but which is technically incapable of penetrating that system and creating direct harm—resembling the proverbial paintball pistol. On the specific, highpotential end of the spectrum is malware able to act as an intelligent agent—capable of penetrating even protected and physically isolated systems and autonomously influencing output processes in order to inflict direct harm, thus resembling the proverbial fire-and-forget smart-bomb. In between are malicious intrusions that include generic system penetrations incapable of identifying and influencing a targeted process, but also targeted and specific intrusions capable of creating functional and even physical damage.
On the low-potential end of the spectrum is the paintball pistol effect. Software used to generate traffic to overload a server, for instance, is not strictly speaking physically or functionally damaging a living being, a structure, or a system; it is only temporarily slowing down or shutting down a system, without damaging it directly and immediately. Denial of service (DoS) attacks are easy to mount and relatively easy to defend against, but they are also highly visible—and for those who find themselves for the first time at the receiving end of an attack that is distributed for better effect across multiple attacking machines the experience can be distressing, and it may well create mental harm and even second-order damage: a persistent high-volume Distributed Denial of Service (DDoS) attack which may bring down a bank’s website for an extended period of time; defaced websites which may seriously damage an organization’s reputation; and espionage or intellectual property theft that can put a company in a less advantageous market position. But these forms of damage are second-order effects, not direct damage inflicted by a cyber weapon.12 At closer inspection, the “weapon” ceases to be a weapon.
One example is Estonia’s reaction to a large DDoS attack in late April 2007, which was discussed earlier. The real-life effect of the Russian-coordinated online protests on business, government, and society was noticeable, but ultimately it remained relatively minor. Yet at the time, Estonian officials and citizens were genuinely scared by the attack.
At the opposite, high-potential end of the spectrum is the proverbial fire-and-forget missile. A useful military analogy is the high-speed antiradar missile, usually shortened to HARM, initially produced by Texas Instruments, and which is one of the most widely deployed anti-radar weapons worldwide. The missile’s critical innovation is a seeker that includes an intelligent, programmable video processor, designed to recognize characteristic pulse repetition frequencies of enemy radars. This means that the weapon can be launched into a certain area where it then searches for suitable target radars, discriminating between friendly and hostile radar by band. Once an emitter is identified as hostile, the missile software’s decision logic will allow it to select the highest value target and home to impact. The missile can be seen as an intelligent agent. In computer science, intelligent agents are autonomous software entities that are able to assess the environment they find themselves in, and which are capable of reacting autonomously in order to achieve a predefined goal. Such a quality is necessary to attack the most highly prized targets.
The proverbial HARM missile contrasts with proverbial paintball pistols in at least five important ways. Firstly, its objective is not just interrupting traffic at a system’s ports facing the public, but getting inside and penetrating a system. Secondly, its objective is not just penetrating any system that happens to be vulnerable (“low-hanging fruit” in geek jargon) but specific systems of particular interest. Thirdly, these systems are likely to be better protected. For any cyber attacker with the goal of causing physical damage, the prime targets are likely to be industrial processes, public utilities, and civilian as well as military telecommunication networks. The computerized control systems in such installations tend to be better secured than less critical systems. Fourthly, if the goal of a stand-alone cyber attack is physical damage, rather than just enabling a conventional strike, then the target itself has to come equipped with a built-in potential for physical harm. Weaponized code, quite simply, doesn’t come with an explosive charge, as chapter two explored in detail. Potential physical damage will have to be created by the targeted system itself, by changing or stopping ongoing processes. Finally, an attack agent’s objective is likely to be not just shutting down a penetrated system, but subtly influencing ongoing processes in order to achieve a specific malicious goal. Merely forcing the shutdown of one industrial control system may have the undesirable effect that a fail-safe mechanism or a backup system kicks in, or operators start looking for the bug. To work as an effective weapon, the attack software may have to influence an active process in a malicious way, and if the malicious activity extends over a certain period of time this should be done in a stealthy way as well. But stealthily or overtly influencing an active process is far more complicated than just hitting the virtual off-button. Three real-world examples of weaponized code illustrate this.
In a first, contested13 example, the CIA may have rigged the control system of a Soviet pipeline in order to cause a major explosion. The powerful 1982 explosion was not caused by a system shutdown, but by deliberately creating overpressure in a gas pipeline by manipulating pressure-control valves in an active control process. A second example is the Israeli cyber attack that was designed to blind the Syrian air defense system. The goal was not just to shut down the entire air-defense radar station—this would have been suspicious and could have triggered an alarm or investigation—but to trick the active system to display no approaching airplanes to its operators for a limited time. Thirdly, and most famously, the worm that sabotaged Iran’s nuclear program didn’t just shut down the centrifuges at Natanz. Before Stuxnet started sabotaging ongoing processes, it intercepted input values from sensors, for instance the state of a valve or operating temperatures, recorded these data, and then provided the legitimate controller code with prerecorded fake input signals, while the actual processes in the hidden background were manipulated.
The two latter examples need to be examined in some detail (the pipeline explosion was already covered in chapter one). The use of weaponized code may happen in conjunction with conventional military force or may be stand-alone. One of the most spectacular examples of a combined strike is Operation Orchard, Israel’s bombing raid on a nuclear reactor site at Dayr ez-Zor in Northern Syria on 6 September 2007. It appears that the Israeli Air Force prepared for the main attack by taking out a single Syrian radar site at Tall al-Abuad close to the Turkish border. The Israeli attackers combined electronic warfare with precision strikes. The Syrian electrical grid was not affected. Syria’s air-defense system, one of the most capable in the world, went blind and failed to detect an entire Israeli squadron of F-15I and F-16I warplanes entering Syrian airspace, raiding the site, and leaving again.14 Before-and-after satellite pictures of the targeted site on the Euphrates were made public by the US government. They show that the nascent nuclear facility and its suspected reactor building, which were located about 145 kilometers from Iraq, had been reduced to rubble. The coding work for the operation was probably done by Unit 8200, the largest unit in the IDF and Israel’s equivalent of the NSA.15 The technicians may have used a so-called “kill switch” embedded in the air-defense system by a contractor to render it useless.16 The details of the operation remain classified, and therefore unconfirmed. But one thing should be highlighted here: the network attack component of Operation Orchard was probably critical for the success of the Israeli raid, and although the cyber attack did not physically destroy anything in its own right, it should be seen as an integrated part of a larger military operation. While the cyber attack on its own—without the military component—would have constituted neither an act of war nor an armed attack, it was nevertheless an enabler for a successful military strike. That was different in another, even more spectacular recent incident.
Stuxnet is by far the most sophisticated known cyber attack to date. It was a highly directed attack against specific targets, Iran’s nuclear enrichment program at Natanz. The worm was an act of cyber-enabled standalone sabotage that was not connected to a conventional military operation. The US government’s internal codename for the operation was “Olympic Games.” But that name became known only after independent researchers had discovered and analyzed the malware’s code for many months, usually discussing the threat under the name Stuxnet. Stuxnet caught on, and therefore this book sticks to the unofficial but publicly better-established name (it is also more elegant). There is reason to believe that Olympic Games was the codename for a larger program that included more than just the Stuxnet attack. It was probably part of a bigger operation that included at least one other publicly known intrusion software. What is certain is that Stuxnet was a multi-year campaign. The program appears to span nearly seven years, from November 2005 to June 2012.17 It is likely that the main attack had been executed between June 2009 and June 2010, when IT security companies first publicly mentioned the worm. Stuxnet recorded a timestamp and other system information. Therefore engineers were able, in months of hard work, to outline the worm’s infection history as well as to reverse-engineer the threat and to understand its purpose. The following paragraphs are intended to provide a glimpse into Stuxnet’s complexity and sophistication.
The sabotage software was specifically written for industrial control systems. These control systems are box-shaped stacks of hardware without keyboards or screens. A Programmable Logic Controller, or PLC, runs the control system. An industrial plant’s operators have to program the controllers by temporarily hooking them up to a laptop, most likely a so-called Field PG, a special industrial notebook sold by Siemens. These Field PGs, unlike the control system and the controller itself, run Microsoft Windows and were most likely not connected to the Internet or even to an internal network.18
The first complication for the attackers was therefore a feasible infection strategy. Stuxnet had to be introduced into the target environment and spread there in order to reach its precise target, which was protected by an “air gap,” in not being connected to the insecure Internet and even internal networks. As a result, it is highly likely that the infection occurred through the use of a removable drive, such as a USB stick. The attack vehicle was coded in a way that allowed its handlers to connect to the worm through a command-and-control server. But because the final target was not networked, “all the functionality required to sabotage a system was embedded directly in the Stuxnet executable,” Symantec observed in the updated W32.Stuxnet Dossier, an authoritative analysis of the worm’s code.19 The worm’s injection mechanism, at least in a later version, had an aggressive design. The number of collateral and inconsequential infections was large: by the end of 2010, the worm had infected approximately 100,000 hosts in dozens of countries, 60 per cent of which were in Iran. It is possible that the worm’s aggressive infection mechanism was intended to maximize the likelihood that it would end up on a Field PG used to program the PLCs in Natanz. Human agents may also have helped infiltrate the target, willingly as well as unwillingly.20
A second complexity was Stuxnet’s “sabotage strategy,” in Symantec’s words. The worm specifically targeted two models of Siemens logic controllers, 6ES7–315–2 and 6ES7–417, known as code 315 and code 417. The likely targets were the K–1000–60/3000–3 steam turbine in the Bushehr nuclear power plant for code 417 and the gas centrifuges in Natanz for code 315.21 If the worm was able to connect to such controllers, it proceeded to check their configurations in order to identify the target; if Stuxnet didn’t find the right configuration, it did nothing. But if it found what it was looking for, the worm started a sequence to inject one of three payloads. These payloads were coded to change the output frequencies of specific drivers that run motors. Stuxnet was thus set up to cause industrial processes to malfunction, physically damaging rotors, turbines, and centrifuges. The attack’s goal was to damage the centrifuges slowly, thereby tricking the plant’s operators. The rationale was probably that damaging hardware would delay Iran’s enrichment program for a significant period of time, as the requisite components cannot easily be bought on open markets.
This method relates to a third complexity, the worm’s stealthiness. Before Stuxnet started sabotaging processes, it intercepted input values from sensors, such as the state of a valve or operating temperatures, recorded these data, and then provided the legitimate controller code with prerecorded fake input signals, while the actual processes in the hidden background were manipulated. The objective was not just to fool operators in a control room, but to circumvent and compromise digital safety systems. Stuxnet also hid the modifications it made to the controller code. And even before launching a payload, Stuxnet operated stealthily: it had mechanisms to evade anti-virus software, it was able to hide copies of its files on removable drives and hide its own program blocks when an enumeration was enforced on a controller, and it erased itself from machines that did not lead to the target.
The resources and investment that went into Stuxnet could only be mustered by a “cyber superpower,” argued Ralph Langner, a German control system security consultant who first extracted and decompiled the attack code.22 The Obama administration later admitted that it co-developed the sabotage malware together with Israeli experts in computer attacks. The operation’s first challenge was getting the intelligence right. Each single control system is a unique configuration, so the attackers needed superb information about the specific system’s schematics. “They probably even knew the shoe size of the operators,” said Langner. The designs of the target system were probably stolen or even exfiltrated from Iran by an earlier piece of espionage software related to the final Stuxnet, known as the beacon. Another aspect is the threat’s design itself: the code was so specific that it is likely that the attackers had to set up a mirrored environment to refine their attack vehicle, which could have included a mock enrichment facility.23 Stuxnet also had network infection routines; it was equipped with peer-to-peer update mechanisms that seem to have been capable of communicating even with infected equipment without an Internet connection, and injecting code into industrial control systems while hiding the code from the operator. Programming such a complex agent required time, resources, and an entire team of core developers as well as quality assurance and management.24 The threat also combined expensive and hard-to-get items: four zero-day exploits (i.e. previously unknown and hence highly valuable vulnerabilities); two stolen digital certificates; a Windows rootkit (software granting hidden privileged access); and even the first-ever Programmable Logic Controller rootkit.25 For the time being it remains unclear how successful the Stuxnet attack against Iran’s nuclear program actually was. But it is clear that the operation has taken computer sabotage to an entirely new level.
Stuxnet is also noteworthy in several other respects. One observation concerns the high amount of intelligence programmed into the weapon itself. The attack vehicle was coded in a way that allowed its handlers in Washington to connect to the worm through a command-and-control server. But because the final target was not networked, “all the functionality required to sabotage a system was embedded directly in the Stuxnet executable,” Symantec observed in the W32.Stuxnet Dossier.26 Another observation is that it did not create collateral damage. Cyber weapons with aggressive infection strategies built in, a popular argument goes, are bound to create uncontrollable collateral damage.27 The underlying image is that of a virus escaping from the lab to cause an unwanted pandemic. But this comparison is misleading. Stuxnet infected a very large number of hosts—but the worm did not create any damage on these computers. In the known cases of sophisticated cyber weapons, collateral infections did not mean inadvertent collateral damage.
Another illustrative demonstration of a cyber weapon took place a few years later “on range.” On range means that it happened in a testing and training environment. In an experiment in 2006, the Idaho National Laboratory tested the so-called “Aurora” vulnerability that left some North American power stations exposed to electronic attack. The test target was a $1m, 27-ton industrial diesel generator. The goal: permanently disabling the enormous machine in a controlled environment through an Internet-based cyber attack from 100 miles away. In the test, the generator started shuddering, shaking, and smoke came puffing out, ultimately disabling the green machine. The lab reportedly came up with twenty-one lines of code that “caused the generator to blow up.”28 The malicious code caused the machine’s circuit breakers to cycle on-and-off in rapid succession, causing permanent damage through vibration.29
The line between what is a cyber weapon and what is not a cyber weapon is subtle. But drawing this line is extraordinarily important. For one it has security consequences: if a tool has no potential to be used as a weapon and to do harm to one or many, it is simply less dangerous. Secondly, drawing this line has political consequences: an unarmed intrusion is politically less explosive than an armed one that has the potential to damage buildings and injure and kill people. Thirdly, the line has legal consequences: identifying something as a weapon means, at least in principle, that it may be outlawed and its development, possession, or use made punishable. It follows that the line between a weapon and non-weapon is conceptually significant: identifying something as not a weapon is an important first step towards properly understanding the problem at hand and to developing appropriate responses. The most common and probably the most costly form of cyber attack aims to spy. But even a highly sophisticated piece of malware that is developed and used for the sole purpose of covertly exfiltrating data from a network or machine is not a weapon. Consequently, the law of armed conflict does not deem espionage an armed attack. Three noteworthy cases that may be confused with cyber weapons help make the concept more precise.
The first example of what does not constitute a cyber weapon is the weaponization of gadgets, rather than code. Technically sophisticated operations are well known in the world of espionage, for instance tiny listening bugs or exploding pens and cigars. Such cases figure more prominently in fiction than in reality, but occasionally they do happen. One of the best-known James Bond-style examples is the assassination of Yahya Abd-al-Latif Ayyash, aka “the engineer.” Ayyash, an important bomb-maker for Hamas and Islamic Jihad, built the improvised explosive devices used in numerous suicide bombings and terrorist attacks. He had been one of Israel’s most-wanted enemies. On 5 January 1999, the Shin Bet, Israel’s domestic intelligence service, assassinated him by placing 15 grams of RDX, an explosive nitroamine, into the cellphone of one of Ayyash’s trusted friends. Israeli agents tricked that friend’s uncle and his wife, who unknowingly helped place the deadly phone at the engineer’s ear, assuming they would help the Israelis eavesdrop on Ayyash, not execute him.30
Lesser known is the fact that Hezbollah had pulled off a similar if less sophisticated stunt in the same year, penetrating one of the IDF’s most secretive and technologically sophisticated entities, Unit 8200, which allegedly helped to build Stuxnet a decade later. In early 1999, a Hezbollah cellphone with a depleted battery was found in a raid in Southern Lebanon. A military intelligence officer turned over the device to the signal intelligence unit and it was brought to the headquarters of Unit 8200 close to Glilot junction north of Tel Aviv. When two officers tried to connect the device to an appropriate charger, it detonated, severely injuring both. One lost his hand.31 Previously harmless devices may indeed be turned into deadly weapons by secretly (or overtly) adding explosives or other harmful functions. But such militant gadgetry belongs more to the category of improvised explosive devices, IEDs, than to that of weaponized code.
The second non-weapon discussed here is intellectually more interesting: the ILOVEYOU worm, perhaps the most costly generic intrusion to date. On 4 May 2000, a new malware rapidly spread by exploiting a generic scripting engine. A 24-year-old undergraduate student in the Philippines, Onel De Guzman, had programmed the worm. Originating in Manila, it spread across the globe in one day, infecting around 45 million Windows PCs. The worm spread by sending emails to entire address books, thus pretending to be a love letter from a known and trusted person. The “Love Bug,” as the media called the work, was capable of overwriting audio and picture files, replacing them with malicious code. In Britain, 30 per cent of all email servers in private companies were brought down by the volume of requests. The estimated worldwide damage exceeded $10bn. Among the infected targets were governments and defense establishments. Britain’s House of Commons saw its internal communication system immobilized. The virus infected four classified internal systems in the Pentagon, according to Kenneth Bacon, then the DoD spokesperson,32 and it was also found on around a dozen CIA computers.33 ILOVEYOU, it is very important to note, did not exfiltrate any data to external servers. The small software did not even have a command-and-control infrastructure, but was acting in a primitively autonomous way. Yet there are instances when such generic pieces of malware could lead to physical damage. This almost happened in early 2003 in Ohio.
A third example that may be mistaken for a cyber weapon is the so-called Slammer Worm. On 25 January 2003, this highly effective worm led to a so-far unique incident at the Davis-Besse nuclear power plant in Oak Harbor, Ohio, about 80 miles west of Cleveland. The plant operated a single light water reactor. Ten months earlier, in March 2002, the station had already suffered one of America’s most serious nuclear safety incidents, this one entirely unrelated to a computer flaw. Maintenance workers had discovered that borated water which had leaked from a cracked rod had eaten a football-sized hole into the reactor head. As a result, the reactor was shut down for repair works that took two years. So Davis-Besse was offline when the Slammer worm hit. The Slammer worm entered the plant through an unnamed contractor, via a simple T1 telephone line that connected the contractor’s computers to the business network of FirstEnergy, the utility company that operated the plant. This T1 line, according to a later investigation, bypassed the plant’s firewall. Dale Wuokko of FirstEnergy explained the bypassed firewall to the Nuclear Regulatory Commission after the incident: “This is in essence a backdoor from the Internet to the Corporate internal network that was not monitored by Corporate personnel,” Wuokko wrote, “some people in Corporate’s Network Services department were aware of this T1 connection and some were not.”
SQL Slammer, as the worm is known, started to spread like an Internet wildfire on the early morning of Saturday, 25 January 2003, at 05:30 Greenwich Mean Time. The worm exploited a buffer overflow flaw in a widely used Microsoft SQL server. The small piece of code generates random IP addresses and then copies itself to those addresses. If the program gets lucky, and one of these addresses leads to a host that happens to be running an unpatched version of Microsoft’s SQL Server, then this machine becomes infected and begins randomly spraying the web with more worms. The vulnerability used by the worm had in fact been known for half a year, and Microsoft had made a security update available six months before Slammer went viral—and to Microsoft’s credit even before the vulnerability became public. But not everybody had installed the patch, including many at Microsoft and, as it turned out, the operators at Davis-Besse. In fact the plant operators didn’t even know there was a patch for the vulnerability.
A few things are noteworthy about Slammer. The worm itself was tiny; its code had a mere 376 bytes and fitted inside a single Internet packet (this means the worm’s code was smaller than an empty email without any text and subject line). Additionally, the worm used a specific Internet protocol that allows a computer to send a message to another computer without requiring prior communications to set up special transmission channels, other than email or browser data. An attack consisted of a single packet sent to UDP port 1434. The worm was therefore able to broadcast scans without the need for a prior response from its potential victims. This meant that each infected host blasted out single yet effective “fire-and-forget” packets that contained the worm. An infected machine with a normal Internet connection speed of 100-Mbps could realistically produce 26,000 scans per second. As a result, Slammer was the fastest worm in the history of computing.34 When Slammer’s rapid spread slowed down Internet traffic globally that morning, many computers lost all legitimate traffic yet they were still able to send and receive the worm because it was so small and so versatile. Analysis estimated that the worm infected more than 75,000 hosts, spraying the Internet with scans from each of those. The resulting slowdown caused computer network outages, cancelled airline flights, failures in ATM machines, and even interference with elections.35 Davis-Besse’s corporate network was affected by that global flood of confused packets and slowed down as well. The plant’s business network, it soon turned out, was connected to the plant’s industrial control network, which is not supposed to be the case (such connections make it easier for the plant’s operators to access real-time data, but ideally these connections should be read-only). At 16:00 local time, the operators of the power plant itself noticed that the network was slowing down. Fifty minutes later, the Safety Parameter Display Unit System crashed. This system is designed to monitor a plant’s safety indicators, such as coolant systems, core temperatures, and external radiation sensors.36 Twenty-three minutes later, at 17:13, the less critical Plant Process Computer also crashed. Both systems, it should be noted, had analogue backups in place which were not affected by the rummaging worm.37 After six hours the plant’s engineers had reinstated both systems.
Three things should be noted about the Davis-Besse incident. First, Slammer’s nuclear attack was concerning, but it was a miss: even if Davis-Besse had not been “in a safely defueled condition,” as the NRC’s chairman said in response to a concerned letter from a congressman, the backup systems would likely have prevented a more serious incident.38 Second, Slammer was the precise opposite of a targeted attack. The worm’s impact on Davis-Besse was entirely random, and partly the result of bad systems administration at the nuclear plant. Predicting and planning with such a unique set of coincidences would be a significant challenge for an attacker focused on a specific target or set of targets. Yet, thirdly, it should also be noted that the incident, despite these limitations, demonstrates the real risk of a catastrophic cyber attack, even the risk of an accidental cyber attack of major proportions.
So far this chapter has discussed a number of different cyber attacks, including targeted ones like Stuxnet and generic ones like Slammer. These cases bring to light a conceptual tension between highly generic and untargeted malware and highly specific and targeted malware. At closer examination, this tension gives rise to three problems that are probably unique to the offensive use of cyber weapons.
The first problem will be called the problem of generics here. The generic-specific tension probably has no useful equivalent in the conventional use of force. On one end of the spectrum is the highly targeted use of force, for instance by a sniper: there’s only one target, one bullet, either hit or miss. On the other end of the spectrum is a highly infectious and virulent biological agent: once released, the killer virus may spread beyond the initial attacker’s and anybody else’s control. These comparisons are highly imperfect. But they help illustrate the problem of generics for architects of cyber weapons. In most if not all circumstances, those seeking to deploy code for political purposes would want to avoid both extremes: developing a weapon that is so specific that it may only be able to hit one specific target system. Such a one-off attack is impossible to repeat, thus limiting its threatening utility. Alternatively they would want to avoid developing a weapon that is so generic that it could spin out of control once released, threatening to create uncontrollable collateral damage. Based on the available empirical evidence, the first scenario is significantly more realistic than the second one. Yet the risks need to be properly understood.
Computer security experts of various strains do not necessarily have a good understanding of the full potential of generic intrusions. This lack of such knowledge arises from the complexity and uniqueness of most computer installations, with a bespoke mix of hardware types, networks, and software systems, including in most cases software applications that can be many years old, so-called “legacy systems.” Components of these large-scale systems may be updated and exchanged on a case-by-case basis, so that the larger system and its processes are continually changing. Different parts of such a complex system may be owned, designed, operated, maintained, and administered by different organizations. This dynamic applies to modern commercial, governmental, and military installations. In fact the problem is so large that it has become a subject for research in computer science. American and European governments and other funders have sponsored research on large-scale complex IT systems. Industrial control systems fall into this category. In SCADA networks and their programmable field devices, attack vectors and configurations tend to be rather specific, so that a widely generic attack seems to be unlikely.
Yet the problem of generics remains empirically unexplored. Dale Peterson, one of the world’s leading SCADA security experts, has distinguished three types of attack against industrial control systems: simple attacks that merely crash systems or interrupt their correct operation, for instance by exploiting a widespread lack of authentification in those systems; moderate attacks where attackers have intelligence on a process and learn how to damage a physical component or subsystem; and complex attacks, where attackers modify a process in a stealthy manner over an extended period of time. Simple attacks require less process intelligence than a complex attack. To illustrate the point, Peterson offers an example of how rogue firmware could be loaded onto the Rockwell Automation ControlLogix PLC:
An attacker could develop and load a set of actions into the rogue firmware which could reboot the PLC, report a percentage of wrong values, issue random write commands, etc. The rogue firmware would use a pseudo-random number generator to select both the type and timing of a series of attacks, producing intermittent PLC failures. The rogue firmware could also easily be spread with a worm, making for a variety of intermittent failures across all PLCs that would be very difficult to diagnose. This is a simple attack that would require little process knowledge.39
Simple generic attacks against a specific set of machine configurations are possible, at least in theory. The 64,000-dollar question is where the limits are of generic higher-order attacks. Stuxnet, the most sophisticated attack on record, was extremely specific and highly targeted—the worm’s collateral infections on seemingly random machines did not have any real consequences for the owners and users of those computers. But it is unclear whether the next generation of high-powered cyber weapons will be equally specific in design, although this will probably be the case. The future will likely bring the answer, either through experience or through research.
The second unique and difficult problem of cyber weapons is the problem of intentionality. This problem arises in unexpected ways in the context of weaponized code. The core question is when a specific attack on a specific target ceases to be—or begins to be—an instrument of a specific attacker. To answer this question, the notion of a “cyber attack” requires clarification. Cyber attack includes both non-violent events, like denial of service attacks or indeed most malware incidents that illegitimately affect a computer or a network of computers, and those attacks that can cause a violent outcome. Even (and especially) relatively short and simple malware, like the SQL Slammer worm, may propagate itself and reach targets in a generic rather than in a specific fashion. Malware, simply put, may identify potential hosts through generic scans, propagate itself through built-in infection mechanisms, infiltrate a new host, execute itself on that host (or get executed by an unknowing user), and then repeat this cycle. Such malware qualifies, in the language of agent theory, as an autonomous agent.40 Autonomous agents act autonomously. The actions of such autonomous agents can therefore be seen as a form of attack, not merely as an accident.
But the autonomy of software agents has a problematic flipside. The Slammer Worm could indeed be compared to a biological virus, or even to a wildfire: once the worm began to spread on its own, it was literally out of control in the sense that the software was not, like other more sophisticated malware, at the leash of a command-and-control server. Even its author could not stop or contain it any longer. It spread randomly. But weapons are instruments of harm. If the author of an attack is unable to control the instrument of harm, then the tool’s instrumentality gets progressively lost. Instrumentality means shaping an opponent’s or a victim’s behavior—but if the attacker has lost the ability to react to an opponent’s change of behavior by adapting the use of the instrument, for instance by increasing the level of pain or by ceasing an attack, then it would be irrational for the opponent to attempt such a moderating change of behavior. It is therefore necessary to distinguish between a violent cyber attack and a cyber weapon—to qualify as a cyber attack, an incident does not necessarily have to be intentional and instrumental. ILOVEYOU’s effects on the CIA and SQL Slammer’s effects on Davis-Besse may qualify as cyber attacks: but although such incidents could in theory have violent effects, they have lost their instrumental character. As a result, they cannot be regarded as cyber weapons.
Taken together, the problem of generics and the problem of intentionality lead to a third problem: the problem of learning agents. Stuxnet is noteworthy for something it didn’t do. Stuxnet was an intelligent agent, able to make simple decisions based on environmental data, but it was not a learning intelligent agent. One confidential study by America’s national laboratories estimated that the worm set Iran’s nuclear program back by one to two years. “There were a lot of mistakes made the first time,” one senior US official was quoted as saying in The New York Times. “This was a first generation product. Think of Edison’s initial lightbulbs, or the Apple II.”41 A next generation product could be able to learn. Learning software agents and machine learning generally have been the focus of much research attention and funding in computer science of the past decade. The defense and intelligence establishments in the United States, Britain, and Israel have traditionally been well ahead of general trends in computer science research, for instance in cryptography or distributed systems. It would be surprising if an intelligent coded weapon capable of learning had not yet been developed. A learning weapon could be able to observe and evaluate the specifics of an isolated environment autonomously, analyze available courses of action, and then take action. By doing so, learning malicious software agents would redefine both the problem of generics and the problem of intentionality in entirely unprecedented ways.