## 2 Cyber-Weapons
First, the authors of Stuxnet, seeing its success and having developed knowledge, skills, and tools for attacking a complex ICS, could build on their work in order to develop and deploy new cyber-weapons against control systems. Indeed, this outcome seems likely. Stuxnet provided not only a means of disrupting Iran's nuclear program, but an investment in the future and building block for future cyber-attacks against ICS devices. Moreover, Stuxnet seems to be but one of several tools developed by the United States and Israel. Another computer worm, nicknamed Flame, reportedly contains some of Stuxnet's code, although it was used to secretly map and monitor Iranian networks rather than cause damage [9]. A third worm, Duqu, which was also used for information collection rather than sabotage, was said to be \"nearly identical to Stuxnet, but with a completely different purpose\" [10] and possibly built on the same platform [11]. Second, observers of Stuxnet's success could be inspired to develop similar cyber-weapons of their own. They might do this in order to attack a particular ICS device in support of a specific goal, or simply to keep up with what they see is a \"cyber-arms race.\" This avenue also seems likely, in part because humans are naturally competitive and inclined to borrow useful ideas and techniques from others, but also because Stuxnet is now \"out there\"--at least its object code is available. Although its source code was not released, analysts have been able to decompile or reverse engineer the object code to discern Stuxnet's functionality, making it easier to develop new cyber-attack tools against control systems. Code developers need not start from scratch. Besides studying Stuxnet, security researchers have been independently examining ICS security, the objective being to identify vulnerabilities that could be exploited. Ideally, product manufacturers would release patches (fixes) for the vulnerabilities, which customers would then install, rendering any cyber-weapons that attempted to exploit them ineffective. In practice, however, vulnerabilities are not always fixed or patches installed, and exploit software is developed to take advantage of them. Researchers often develop these exploits to underscore the seriousness of the problem, push vendors into fixing them, and provide a mechanism for testing whether a particular system is vulnerable. But once published, the exploit code can also be used to facilitate harmful cyber-attacks. I started seeing reports of ICS vulnerabilities in 2007 and the release of exploits a few years later. In March 2011, the Moscow security firm Gleg announced the availability of Agora SCADA+, a package with 22 exploits, including exploits for 11 \"zero-day\" vulnerabilities. Six days later, security researcher [PERSON] released proof-of-concept exploit code against 34 SCADA vulnerabilities in software from four vendors [12]. Then in January 2012, researchers released information describing security flaws in widely-used PLCs from five vendors [13]. They provided exploit code for some of the flaws in the popular Metasploit framework, making it easier for security professionals to test their systems for the vulnerabilities--or their adversaries to attack them. Additional tools can be used to find Internet-connected ICS devices, which might then be attacked. Using the Shodan search facility, for example, [PERSON] found 7500 such devices. By fusing this data with exploit information from Metasploit and ExploitDB plus geolocation data, he showed how someone could identify ICS devices vulnerable to a cyber-attack [14]. Software developers often build on the work of others, and this general principle applies to the development of cyber-attack code. Most viruses, worms, Trojans, and other types of malware are not developed from scratch.