“Gentlemen Do Not Read Each Others’ Mail”
There is a famous historical event in signals intelligence and cryptanalysis where the new and early successful US efforts in these areas were shut down, as covered by this article in the Atlantic.
The Cipher Bureau was shuttered in 1929, shortly after the arrival of Henry Stimson as the new Secretary of State. Apparently, Stimson thought this type of surveillance was unethical, and he issued what is perhaps one of the best foreign policy statements ever:
“Gentlemen do not read each others’ mail.
History also shows this gentlemanly standard was shortly after obviated when collecting and decrypting German and Japanese communications proved to be extremely helpful to the Allied Forces in WWII.
Last Saturday Sanger and Perlroth of the NYTimes wrote US Escalates Online Attacks on Russia’s Power Grid. A lot of the discussion of this article has focused on the accuracy and sourcing of the reporting, but what is more interesting to me are the discussions on whether this should be done at all. While not falling back to the gentlemen line, many are making a similar argument: Ethical and responsible governments do not intrude on other countries’ civilian serving critical infrastructure systems (power, water, etc.). In the future this will be viewed to be as naive as Secretary Stimson’s quote, although it is doubtful you will hear any high ranking government official make this statement.
In 2012 and 2013, I looked at the almost certain questions and related tasking that would take place in governments around the world after Stuxnet. This included a paper Construction, Deployment and Use of Offensive SCADA and DCS Cyber Weapons, reprinted in full below, and a session at S4 on Preparation and Persistence that was not recorded.
Imagine you are in a government that has a list of potential adversaries, as all do. In a post-Stuxnet world it is almost certain that someone at the highest levels is asking for the ability to shut off the power or affect another process in adversary X, Y and Z as an offensive option. As this requirement is tasked to the appropriate departments and agencies, there is no way they can achieve this goal without having detailed information on the system (preparation) and a presence on the ICS (persistence).
Step 2, deployment and persistence, is the key to the ICS cyber weapon and where most of the effort will be placed and risk taken. Those responsible for offensive capabilities will keep tallies of how many adversaries’ critical infrastructure systems have ICS cyber weapons staged and ready to cause damage.
To meet the tasking, government organizations will need to not only access the ICS to gather information to prepare the attack. They will also need to create and deploy the attack and be in a position to initiate the attack if requested. While I don’t know if the Sanger/Perlroth specific information is accurate, I would be shocked if the US is not in Russian, China and many more countries’ critical infrastructure ICS, and vice versa. Having written about this in 2012, substantial progress has almost surely been made in the past seven years.
So why aren’t we seeing widespread critical infrastructure outages due to cyber weapons? For the same reasons most offensive kinetic weapons are not used. There are large numbers of books and studies on this, and while cyber weapons are new, a lot of the existing strategy and theory on the creation, deployment and use of kinetic weapons is applicable to cyber weapons.
Those in opposition to this intrusion and staging activity correctly state there is a risk of the activity to pre-stage ICS cyber weapons could unintentionally cause a cyber incident. The rumor mill believes this was the case in the incident that caused physical damage to a German steel mill. It will happen elsewhere. The Triton caused outage in Saudi Arabia appears to be unintentional. The attacker’s modifications to the safety system didn’t operate properly and caused the shut down. It is believed they were working towards having the capability, whether it would be used or not, to have a much greater impact, including causing explosions and loss of life.
Every country must assume ICS cyber weapons are being created for and deployed on their critical infrastructure and are awaiting commands to activate. A country can opt out on the offensive side, but it is unlikely the country’s adversaries will.
————–
Construction, Deployment and Use of Offensive SCADA and DCS Cyber Weapons
by Dale Peterson on 17 October 2012
Stuxnet has opened the eyes of high-level officials in governments and non-government organizations who are responsible for offensive warfare capabilities. It has gone from engineers and security types trying to convince decision makers of the merits of a cyber attack to the decision makers seeking out offensive cyber weapons.
In this article, I’ll address how offensive cyber weapons that attack the SCADA and DCS, which run power plants, electric grids, refineries and pipelines, transportation, water treatment and distribution and other physical processes, are likely to be developed, deployed and used.
SCADA and DCS are two different types of industrial control systems (ICS) with many of the similar components and protocols. In simplistic terms, SCADA systems run processes over a large geographic area, such as electric transmission/distribution and oil or gas pipelines, while DCS run processes in a local area such as a power plant, factory or refinery.
Step 1: Developing the Exploit / Cyber Weapon
The first step in a cyber attack on a critical infrastructure ICS is developing the cyber weapon. Unfortunately this is very simple because ICS are insecure by design. They have less security than the four digit PIN used in bank cash cards.
Consider Stuxnet. The real purpose of Stuxnet was to load a program on the programmable logic controller (PLC) that controlled the centrifuges in Natanz Fuel Enrichment Plant’s. The attackers developed a variety of Windows exploits to gain access to the network the PLC’s were on, but once on the ICS network there was no attack code required to load the cyber weapon on the PLC. The Siemens S7 PLC has no source or data authentication so any attacker or malware with access to the S7 PLC can load their own program, or tell the process to stop, or reboot the PLC, or whatever else the attacker desires to do.
Most people believe that the PLC vulnerabilities that Stuxnet exploited have been fixed. They have not. There still is no authentication. Access to the S7 PLC allows total control of the PLC. The Siemens insecure by design problem exists in most, but not all, SCADA and DCS vendor systems.
An organization wanting to develop a cyber attack on a potential adversary’s critical infrastructure first needs to learn what system the adversary has. This is often found in open source information, but it could require intelligence activity to learn the vendor and systems that run the power plant, chemical plant, refinery or whatever else is the attack target.
Once the vendor and product information is known. The attacker needs to gain access to this hardware and software. This is not as difficult as it sounds. The US led the way by developing a National SCADA Test Bed with ICS vendors actually donating the equipment. Other countries are emulating this approach, ostensibly for defensive reasons, but the equipment can be used for any number of purposes including developing offensive ICS cyber weapons.
The critical infrastructure in many countries is controlled or tightly regulated by the government. There are a limited number of popular systems in each critical infrastructure so there is a strong chance that the adversaries system is already owned or accessible by the offensive cyber team. For example, an organization wanting to attack refineries would cover most by having access to Emerson, Honeywell and Yokogawa systems.
Of course the final option is the ICS can simply be purchased. It may be US$100,000 or more to get a small representative system, but this is small compared to the price of physical offensive weapons.
With access to the system, developing an ICS cyber attack can range from simple to complex:
- Simple – An attacker uses the lack of authentication to cause the system to crash or operate incorrectly. This would take the critical infrastructure offline for a short time, but the attacker could get lucky and cause long term damage.
- Moderate – An attacker learns about the process and determines how to destroy a physical component or subsystem that will take time to replace. Operators and engineers are incredibly clever at figuring out how to break things even when there are purportedly safety systems in place to prevent this.
- Complex – An attacker modifies the process in a stealthy manner so a cyber attack is not suspected, such as the centrifuge failures in Stuxnet.
The simple ICS cyber attacks actually require little or no ICS experience. Dillon Beresford and a number of other researchers have proved this. The moderate and complex attacks require process and automation talent in addition to IT security capabilities. For example, Stuxnet likely required nuclear engineers and automation engineers trained on the Siemens products in addition to the IT security experts.
There can be combination ICS cyber weapons that defy easy categorization. In 2009 at Digital Bond’s S4 conference, a paper was presented showing how rogue firmware could be loaded on the Rockwell Automation ControlLogix PLC. One of the attack scenarios was intermittent failure, an attacker could develop and load a set of actions in the rogue firmware such as reboot the PLC, crash 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 the time interval to the next attack and the next attack from the list. The intermittent and variety of failures across all the PLC’s, because the rogue firmware is easily spread with a worm, would be very difficult to diagnose. This is a simple attack that would require little process knowledge.
In summary, developing an ICS cyber weapon is simple given a small team and access to the ICS product that is to be attacked. The complexity and difficulty in developing the ICS cyber weapon increases on how sophisticated the process is and how clever the process modification is.
Step 2 – Deployment and Persistence
Most critical infrastructure ICS are behind multiple layers of firewalls and other security perimeter devices and are not easy to access. There are physical and cyber methods to gain access to these ICS, and deploying the ICS cyber weapon is difficult but possible. There are a number of ways to deploy an ICS cyber weapon but they can be summarized in two categories:
1. Physical Access to the ICS – An attacker who can connect to the ICS network can deploy the cyber weapon because the ICS is insecure by design. There is no hacking involved, except for perhaps reconnaissance if the network topology is unknown.
Note – A multi-stage effort to design the ICS cyber weapon is possible or even likely. Step one would be for the attacker to gain access to download all of the process logic needed to develop the moderate or complex attack. Step two would be to upload the attack logic.
2. Logical Access to the ICS – An attacker would compromise a system that connects to the ICS. This could be a vendor support computer, a engineer laptop, a USB drive, or an engineer system on the corporate network allowed to access the ICS. The last example is interesting in light of the ICS targeted spear phishing attacks in recent years.
If developing the ICS cyber weapon was easy and deploying the cyber weapon was difficult but possible, the real challenge is maintaining contact with the deployed ICS cyber weapon. In fact, the author believes that the real challenge of offensive ICS cyber war activities will be maintaining the communication or persistence with deployed ICS cyber weapons.
There will be instances where adversaries want to launch an attack immediately upon deployment of a cyber weapon. However this deployment is likely to be difficult to achieve at an instant notice, unless there is full time physical access. Additionally when hostilities are underway or known to be imminent, security measures will be increased. For this reason, organizations responsible for offensive cyber operations will want to have the ICS cyber weapons developed and deployed and waiting for the signal to begin the attack. The signal may not be given for many years or ever, but the preparation and capability will be in place.
Botnets and other deployed exploit code often communicate over the compromised company’s Internet connection back to a command and control server. This is possible in many critical infrastructure ICS as the majority still do not restrict outbound communications, communication from the ICS to the corporate network to the Internet.
There is a danger in using the target’s network to maintain communications with the ICS cyber weapon. First, the target can improve their security and block outbound communication and the ability to activate the ICS cyber weapon. The second is the target can look at the security perimeter logs and identify the unauthorized communication. There is little authorized outbound communication in an ICS, so the cyber weapon’s communication could be detected and provide evidence of compromise.
Therefore to maintain this persistence an attacker would like a separate, hard to identify channel they control. This may sound difficult, but it is becoming easier and cheaper every day. Consider the Power Pwn from Pwnie Experss in Figure 1. This device looks like and is an innocuous power strip. It also is a computer fully loaded with hacking tools and designed to circumvent LAN security measures. All an attacker needs to do is to plug in an Ethernet cable into the Power Pwn – deployment time of what looks likes a power strip is less than a minute.
Figure 1 – Power Pwn by Pwnie Express
The Power Pwn and other form factors, such as one that looks like a plugin air freshner, also have separate communication channels such as 802.11 wireless or a wireless mobile data connection from the local mobile phone company. Once an attacker has found a way to deploy this in a plant or remote SCADA station he can connect, securely over SSH, to the Power Pwn and the supposedly isolated ICS network from anywhere in the world. (This is another method to deploy the ICS cyber weapon.)
There are even more clever ways to deploy this mobile data channel to maintain communication with the ICS attack weapon. PLC’s and other devices come with chassis and cards that plug in to the chassis. A motivated attacker could develop a board that added the mobile data connection and insert it in the PLC or other device in the rack.
The best news for the attacker trying to maintain communication with his deployed ICS cyber weapon is most critical infrastructure installations have mobile phone coverage. In fact, those plants and installations in remote areas often pay the mobile carrier to deploy antennas so there is a strong signal. The ICS cyber weapon communication will be intermixed with all the mobile phone calls and mobile data access coming from the plant.
Getting onto most plants is not difficult. There are typically guards at the main gate, but once through the main gate visitors can walk around the plant freely if they have a hard hat, safety shoes and the other required safety equipment. In fact, people tend to be very friendly and will answer questions on what is where if you have reasonable social engineering skills.
Like most ICS cyber networks, the physical security perimeter of a plant is hardened but the inside is insecure by design. There are all sorts of maintenance and new project activities going on in a plant that require access to all parts of the plant. Rooms where the network connections are also contain equipment that many people need to access.
SCADA networks are often easier to physically access and deploy a special communications channel to the ICS cyber weapon. They are geographically dispersed, often over hundreds of miles, and many of the field sites with SCADA network access are unmanned.
The focus in this section has been on public mobile data networks, but there are other channels that could be deployed. Many radio channels are well known and others are likely classified or theoretical at this point.
Step 2, deployment and persistence, is the key to the ICS cyber weapon and where most of the effort will be placed and risk taken. Those responsible for offensive capabilities will keep tallies of how many adversaries’ critical infrastructure systems have ICS cyber weapons staged and ready to cause damage.
Inevitably some of these deployed offensive weapons will be detected, and the international law and practical discussions will take place if a staged ICS cyber weapon that has not been activated is an attack or an act of war.
Step 3 – Using the ICS Cyber Weapon
The rules and strategy related to the use of any cyber weapon are still being determined. This is still a new area of study as the people who make these decisions are beginning to better understand the capabilities of ICS and other cyber weapons. Will it follow the rules and strategies of an existing class of weapon, be something completely new, or a hybrid of new and old?
The people who make the decision to use the ICS cyber weapon are likely different than the people who develop, deploy and maintain communication with the cyber weapon. The author has only one insight or prediction on how ICS cyber weapons will be used. Many more weapons are developed and deployed than are ever used, and this is likely to be the case with offensive ICS cyber weapons.