Designing an ICS Attack Platform
The vulnerabilities of ICS networks have been well-discussed. Still, most of the discussion has been focused on the damage to specific devices (as seen in the coverage of the Aurora demonstration, or in some PLC vendors’ public exploit demonstrations). In fact, ICS attacks are about much more than damaging a specific device. If executed wisely, they can create a much more dramatic effect.
In this post I will illustrate a model for an ICS attack campaign. The attacker’s goal, in this example, is very ambitious: to shut down the power in a small town named “Light City” at the very moment the ball drops on New Year’s Eve.
So how do you get Light City to go dark?
There are several ways, too many to be covered within the scope of this post, but the obvious targets would be either the generators or the transmission lines. The scenario of attacking the generators is described in Lloyd’s Emerging Risk Report – 2015. In this post I will describe the transmission lines scenario. To attack the transmission lines, our attacker would have to obtain information about Light City’s power grid design so he could disconnect Light City from its power generation stations, using the transmission substations’ switches. For the sake of simplicity, we’ll assume a simple (yet realistic) switching model for connecting the generation stations to the grid.
The figure below illustrates Light City’s power grid map:
In this illustration, each yellow box represents a circuit breaker (CB), which can be either on or off. If the CB is off, the current does not pass through it. In order for Light City to have power, there has to be at least one “On” route connecting the generation station to the city. Seems very easy – turn off just three switches and the entire city goes dark. But how do you turn off these switches?
To do so, our attacker would need access to the control network – the network that determines which switches are controlled by which controllers. The control network comprises of all the controllers and servers : SCADA servers, PLCs, RTU etc., and holds all the information about their addresses and values.
In order to execute a successful attack, the attacker must control all of these switches at the same time while hiding their actual state, i.e. each of the switches would be turned off but would report its status as “On”.
Why is it important to hide the exact state of the switches? Because hiding the status amplifies the attack effect, for several reasons:
First, regardless of hiding the attack, the effect of turning off the power in Light-City will be easily detected. If we assume that the attack will not shut down the generators (which is a reasonable assumption in large grids, when only a small portion of overall consumption is removed), it would be very easy to turn on the lights, simply by sending the correct commands from the control center. Thus, if the operator knows which switches were changed, their state can be easily corrected. If the switches falsely report a normal state, the operator would not know which switches need to be reprogrammed.
Second, many operators have recovery plans for such cyber-attacks. A recovery plan may include manual management of switches as well as using local SCADA servers at the sites. Hiding the exact location of the attacks, however, would increase the operator’s response time, since the operator would first need to identify the exact switches whose status was changed.
Let’s take a look at the impact of hiding the attack on the small network in this example.
Once the operator detects the power outage in Light City, he will immediately attempt to find the exact switches that caused the outage. Problem is, as seen in the above figure, there are numerous combinations of switches that may have been severed: (F,N,T), (N,D,E), (N,C,H), (N,C,G), (N,C,E), (A,P,H) and so on—too many to be manually checked.
In order to execute such a simultaneous stealth attack, the attacker will have to set up a malicious system with the following properties:
- Ability to control all relevant controllers, e.g. using embedded implants like Stuxnet.
- Ability to send commands to the controllers while reporting normal regular values to the control center. This can be done using implants on devices or by means of network attacks such as ARP poisoning or TCP hijacking (which is relatively easy in an ICS, and will be described in a future post).
- In case there is more than one instance of the malware, there would have to be a communication mechanism linking all malwares instances, so they could synchronize the attack.
These properties have nothing to do with the device the attacker chooses to compromise. It is irrelevant if the attacker chooses to plant his malware(s) on PCs, routers, controllers or even cameras and printers. In future posts I will explain in more detail how these features are implemented.
The mitigation of these attacks on ICSs requires an intrusion detection system, which provides several integrated security features such as a signature engine, anomaly detection and network learning. These features are enable the detection of attacks in real time.
If you’re concerned about the type of risk described, I invite you to schedule an ICS attack demo and to learn more about how to prevent such attacks.