The Journal of Strategic Studies published my article Offensive Cyber Weapons: Construction, Development and Employment, and it is now available for free download. Thanks to Thomas Rid for inviting me to write this and organizing the five articles on this topic.
I had two main purposes to writing this article. First, to address the ease or difficulty in creating a cyber weapon to attack a critical infrastructure control system; and second to highlight the importance of deploying the cyber weapons before you need them and maintaining communication with the weapon.
Who Can Create An ICS Cyber Weapon?
Stuxnet has greatly confused this discussion because the delivery mechanism was terribly over-designed (belt, suspenders and another belt, and maybe a rope) and the modification to PLC logic was long, complex and clever.
In the article I give three examples of simple, moderate and complex cyber weapons. The distinction is based on how much skill and effort the attacker places on modifying the process. It is a days work or so to create a cyber weapon to stop the process or brick the PLC. The level of effort and sophistication of the cyber weapon increases from there based on what changes to the process are required.
What seems to be lost in most discussions is that the key participants in developing a cyber weapon aimed at the critical infrastructure are not security experts, researchers or hackers; the key participants are subject matter or process engineers and automation professionals. A moderately skilled security professional with access to the PLC can figure out how to upload whatever he wants to the PLC. Reverese engineering the process and deciding the best way to cause difficult to recover damage or stealthy damage to the process is more difficult.
Deploying And Maintaining Communication With An ICS Cyber Weapon
Now that the potential of a cyber weapon is known thanks to Stuxnet, there are a growing number of people and organizations responsible for offensive cyber capabilities. For the paper I imagined I was tasked with ICS offensive cyber operations for a government.
A government or other organization has a list of likely enemies and is now developing a list of critical infrastructure systems they would like to take out if the situation warrants. This list gets handed to the group(s) responsible for offensive ICS cyber operations. There are two tasks that are not being publicly discussed that are critical to success:
1. Deploy Before Needed – An offensive organization often cannot wait until the weapon is needed to develop and deploy it. Developing and pre-staging weapons is common. If you want to take out an enemies fuel supply, water or electricity when hostilities start, it is necessary to have the offensive weapon in place for that possible conflict. Based on leaks and releases from the Obama administration it is clear that deploying a cyber weapon is an option, and some analysis of international law indicates that deployment on an enemies ICS without causing harm is not an act of war (another future article topic).
Like most weapons produced and deployed, the number of ICS cyber weapons used is likely to be a small percentage of what is deployed and ready to be used. One of my predictions is that there is a major effort to create and deploy ICS cyber weapons, and that some of these will be accidentally discovered.
2. Communications Persistence – If you agree with the strategy prediction that ICS cyber weapons will be deployed in potential future target ICS, then the offensive entity needs a way to activate the ICS cyber weapon. They may also want to update or modify the attack code prior or during the attack. This requires the ability to communicate with the cyber weapon.
Communication could take place through the target’s communication networks and compromised computers, but this is risky. During an attack, external network connections are often removed as the first response. An attacker would prefer to have a communication channel they control, and the Power Pwn is a great commercial example of this.
One of the remaining mysteries of Stuxnet is how it was deployed and how the creators communicated with it. David Sanger’s book provided some clues, but also added confusion. He mentions the Stuxnet PLC attack code was updated many times, and some indication that Siemens’ personnel were the vehicle. Yet Siemens publicly denies any activity with the Iranian nuclear program during that time period. Even if Mr. Sanger is correct, an external communication capability would fit in with the over-designed nature of Stuxnet.
This part of the article was edited down to meet a word count, but it is the most important part for loyal blog readers who likely have known much of the rest of the article.