An Adversarial Model for Expressing Attacks on Control Protocols

Abstract

In this paper we present a model for expressing attacks on control protocols that involve the exchange of messages. Attacks are modeled using the notion of an attacker who can block and/or fabricate messages. These two attack mechanisms cover a variety of scenarios ranging from power grid failures to cyber attacks on oil pipelines. The model provides a method to syntactically express communication systems and attacks, which supports the development of attack and defense strategies. For demonstration purposes, an attack instance is modeled that shows how a targeted messaging attack can result in the rupture of a gas pipeline.

Keywords

attack modeling control systems cyber attack

1 Introduction

The electric power grid, oil and gas pipelines, railways and other critical infrastructures are viable military targets. Attacks on these systems disrupt communications, hinder logistical support, create confusion, and achieve psychological effects. The majority of systems that comprise critical infrastructures rely on control protocols to command, direct and monitor operations. Inherent vulnerabilities in these protocols enable an attacker to exploit message transactions in order to manipulate control system operations. As demonstrated by the recent Stuxnet virus, non-kinetic means have the ability to achieve direct kinetic effects. Indeed, manipulation of operations can result in devastating consequences.

This research presents a model for expressing attacks on control protocols that involve the exchange of messages. Attacks are modeled using the notion of an adversary who can block and/or fabricate messages. These two attack mechanisms cover a variety of scenarios ranging from power grid failures to cyber attacks on oil pipelines.

The model, which is defined using a process calculus, helps conceptualize attacks in one control protocol and translate them to similar attacks in another protocol. It also assists in targeting specific control protocol and system implementations. In particular, the model helps identify the information requirements, articulate possible outcomes and examine the feasibility of attacks based on the available information. The comprehensive understanding of attacks can facilitate risk analysis and risk management, the implementation of defensive postures, and the design of robust protocols.

2 Discussion of related work

The majority of attack models for computer systems are founded on the notion of an attack tree.¹ The root node of an attack tree denotes the goal of the attacker. The steps for completing the attack are decomposed using parent–child relations such that a path from a leaf node to the root node expresses one instance of the attack. The possible attacks correspond to the different branches of the attack tree. Attack trees have been shown to capture a variety of computer system attack scenarios.^2,3

Attack tree models are attractive because of their simplicity and ease of analysis. However, certain ambiguities and the lack of expressiveness of attack tree models hinder quantitative reasoning and comparison. Precise analysis is difficult because an attack tree node represents both the current system state and the specific attack action.⁴ Also, attack trees are susceptible to state explosion, they do not represent the temporal aspects of dependent attacks, and lack the ability to generalize beyond the modeled scenario.⁵

An alternative model to attack trees⁵ views attacks as a series of capabilities instead of a sequence of events. It provides constructs for defining intrusion signatures and automating the discovery of attacks. Other researchers have proposed taxonomies for classifying attacks,⁶ ontology-based models,⁷ and attack models using simulations of cyber attacks.⁸ These models describe complex scenarios involving multiple attacks; however, they lack formalisms for analyzing causality and sequential events. Analysis focuses on generalized structures associated with an adversary’s perceived actions. The methodology has some advantages for defining signatures of attacks for intrusion detection. However, the ability to define system specific scenarios and conceptualize variants of attacks is limited.

Little, if any, research has specifically focused on modeling attacks on control system protocols. Current work has tended to focus on modeling intrusion and anomaly signatures, identifying attributes for system resilience and evaluating system vulnerabilities for risk analysis. The US Department of Energy,⁹ National Institute of Standards and Technology,¹⁰ and other entities¹¹ have developed models for predicting, reacting to, and understanding failures in control systems. Several failure analysis models¹² demonstrate the conditions that can lead to failures in control systems. Our model does not directly focus on failure analysis. However, a failure analysis model can be used to determine the conditions under which physical damage can occur. The conditions can then be analyzed using our model to determine how a control protocol may be attacked to cause physical damage.

Byres et al.¹³ used attack trees to identify vulnerabilities inherent in the specification and typical deployment of the Modbus control protocol. Similarly, other works^14,15 have presented taxonomies of vulnerabilities that are specific to Modbus and DNP3. Their research is intended primarily to identify generalized attack scenarios.

Cheung et al.¹⁶ described a language for modeling attacks on process control systems. Because control systems are relatively static, models can be constructed to characterize the expected system behavior. Traffic that does not conform to normal traffic patterns is identified as a potential attack. The concept focuses on a purely defensive posture that assumes attackers will not use legitimate traffic in an attack. Our model is attack-centered and incorporates the use of legitimate messages in attack scenarios. Moreover, our model expresses temporal aspects and causal effects while lending itself to formal analysis.

Other models leverage finite state machines and automata theory. Ye et al.¹⁷ and Carlson et al.¹⁸ presented models using Markov chains to represent a profile of computer-event transitions. Activities are observed to profile normal traffic through sequential ordering of events. Similarly, several finite state machine models based on Petri nets^19,4,20 have been used to express common computer attacks. Petri nets use graphs and set theory to model concurrency, synchronization, resource allocation, and randomness. Petri net models explicitly specify consequences of attack states and provide a means for formal analysis. However, Petri nets leverage a purely concurrent construct that randomly transitions to different states.²¹ Although the non-determinism is adequate for analyzing the safeness of a system, it introduces complexity when defining specific attack sequences. In addition, Petri nets are limited by an inability to use one instance to model similar attacks.

3 Modeling control systems

Control systems use central monitoring stations, typically with a human–machine interface for an operator in the loop, to control and monitor remote processes. Remote terminal units (RTUs) or programmable logic controllers (PLCs) are field devices that communicate with the monitoring stations and convert digital messaging into physical actions such as opening and closing valves and breakers, collecting data from sensor systems, and monitoring the local environment for alarm conditions.

Control systems use a request–response communication paradigm for message transmission between a master control device and edge field devices.²² The control device sends request messages to outlying edge devices to gather monitoring data or to specify control actions. The edge devices collect discrete and analog sensor data and maintain actuator settings specified by the control device. Response messages are generated by edge devices after direct requests from the control device. In addition, when alarm conditions are detected the edge device may notify the control device.

A control system architecture comprises control devices, edge devices and communication links. Note that communication links may include myriad devices (e.g. gateways, repeaters, and modems). For purposes of this discussion, communication links refers to the infrastructure that facilitates message exchange between control and edge devices.

The control system architecture is specified in the model with control devices/edge devices $V$ and communication links $U$ divided into two disjoint sets. Functionally, this representation requires a communication link between two devices to exchange messages; this mirrors real-world control system architectures. A process calculus is used to model the communication paradigm and specifies the syntax for message exchange between devices. Analysis of device interaction and message transactions demonstrates how the communication paradigm can be exploited by an adversary to manipulate control system operations.

4 Process calculus representation

This section introduces a simple, yet expressive, process calculus for modeling communication paradigms in control systems.

Process calculi are a diverse family of mathematical formalisms for describing and analyzing properties of concurrent computations.²³ Process calculi provide a tool for the high-level description of process interaction, communication, and synchronization. System attributes are observed and manipulated to permit formal reasoning about process behavior and system characteristics.^24,25 The control system processes that enable data exchange and concurrent interaction are readily modeled using a process calculus. The ability to express hierarchical communications, logical sequences of events, concurrency, and system-wide situational awareness enable the modeling of control system message transactions that the formalisms described in Section 2 do not afford.

4.1 Basic concepts

In a process calculus, primitive constructs are used to build equations that define system behavior. Table 1 lists the primitive constructs used in this research, which are based on Milner’s work on communication and concurrency ²⁴.

Table 1.

Primitive process calculus constructs.

Construct	Meaning
$P_{1}, P_{2}, \dots$	Processes
$\bar{x} 〈 y 〉$	Output
$x (z)$	Input
$P_{1} \| P_{2}$	Concurrency
$x . C$	Sequential
new	New
$\emptyset$	Terminate

A process is an autonomous entity that uses channels to communicate and interact with other processes. Communication is specified as the directed flow of messages.

The output construct $\bar{x} 〈 y 〉$ and input construct $x (z)$ specify that the common channel $x$ is used for communication. Message exchange flows from the output process to the input process. The output construct specifies the data that is sent; the term $\bar{x} 〈 y 〉$ expresses the fact that data $y$ is output on channel $x$ . The input construct $x (z)$ receives the data on channel $x$ and binds the received data $y$ to variable $z$ for local use.

Concurrency, specified as $P_{1} | P_{2}$ , is the key construct that distinguishes process calculi from pure sequential models of computation.²⁶ The concurrency construct allows computation in $P_{1}$ and $P_{2}$ to proceed simultaneously and independently. Note that interaction is still possible through synchronization and message flow from $P_{1}$ to $P_{2}$ (or vice versa) via a shared channel.

The sequential construct allows interactions to be ordered temporally. In general, the sequential construct is associated with the output and input constructs to model a process sending a message or a process expecting a message. The output prefixing $\bar{x} 〈 y 〉 . E$ specifies that $y$ is emitted on channel $x$ before process $E$ is activated. The input prefixing $x (z) . C$ specifies a process waiting for a message on channel $x$ . After the input is received, the data is bound to $z$ and the process $C$ is activated.

The new construct specifies the instantiation of new system attributes. For example, a process invoked to facilitate a message exchange may be declared as $P_{1}$ . Subsequently, a new instance of the same process declared as $P_{2}$ may be initiated. Thus, the new construct allows each instance of a process to be uniquely identified. The terminate construct, $\emptyset$ , represents the successful termination of a process.

4.2 Message transactions

A communication paradigm $M$ incorporates various message transactions. A message transaction specifies the syntax for message exchange between control system devices.

The communication channels for message flow and synchronization are derived from the functional control system architecture. The symbol $Γ$ specifies a message channel such that $Γ_{v_{i} u_{k} v_{j}}$ represents a message channel from device $v_{i}$ to device $v_{j}$ using communication link $u_{k}$ .

Definition 4.1 The new instantiation of a message channel $Γ_{v_{i} u_{k} v_{j}}$ is valid if and only if a communication link $u_{k}$ that enables message exchange from $v_{i}$ to $v_{j}$ exists.

Control systems employ three types of message transactions: (i) request-only; (ii) unsolicited-reply; and (iii) request-reply. The request-only message transaction consists of a control device sending a request message to an edge device. A typical example is a broadcast sent from a control device that does not solicit a response message from receiving edge devices. The request-only message transaction is expressed as

\begin{matrix} Request - Only \\ P_{a} (Rqst) = (new Γ_{v_{i} u_{k} v_{j}}) (C 〈 Rqst 〉 | E) \\ C (Rqst) = \bar{Γ_{v_{i} u_{k} v_{j}}} 〈 Rqst 〉 . ∅ \\ E = Γ_{v_{i} u_{k} v_{j}} (x) . ∅ \end{matrix}

(1)

Note that $v_{i} \in V$ specifies a control device, $v_{j} \in V$ specifies an edge device, and $u_{k} \in U$ specifies a communication link. The variable $P_{a}$ represents a process that expresses one of the three types of message transactions. The subscript denotes a particular message transaction instance. The variables $C$ and $E$ denote control device and edge device (sub)processes, respectively.

In Equation (1), the process $P_{a}$ is invoked with a request ( $Rqst$ ) data parameter. The execution instantiates a new message channel and invokes the concurrent processes $C$ and $E$ . Note that $Rqst$ is an argument for the control device process $C$ . The control device process $C$ sends the $Rqst$ argument using the channel $Γ_{v_{i} u_{k} v_{j}}$ , upon which $C$ successfully terminates. The edge device process $E$ initially waits for a message on the channel $Γ_{v_{i} u_{k} v_{j}}$ . After the message is received, the edge device process $E$ binds the data to $x$ , and terminates successfully; the instance of $P_{a}$ is now complete.

The unsolicited-reply message transaction consists of an edge device sending a reply message to a control device. This message transaction is used primarily to alert control devices to alarm conditions. The unsolicited-reply message transaction is expressed as

\begin{matrix} Unsolicited - Reply \\ P_{a} (Rply) = (new Γ_{v_{j} u_{k} v_{i}}) (C | E 〈 Rply 〉) \\ C = Γ_{v_{j} u_{k} v_{i}} (y) . \emptyset \\ E (Rply) = \bar{Γ_{v_{j} u_{k} v_{i}}} 〈 Rply 〉 . \emptyset \end{matrix}

(2)

The unsolicited-reply message transaction is similar in execution to the request-only message transaction. The primary difference is that a message is sent from the edge device process $E$ to the control device process $C$ using reply ( $Rply$ ) as an output argument and a message channel from the edge device to the control device.

The request-reply message transaction consists of a control device sending a request message to an edge device, prompting the edge device to send a reply message to the control device in response. The request-reply message transaction constitutes the majority of communications in control systems. Typically, control systems employ these message transactions for round-robin polling. The request-reply message transaction is expressed as

\begin{matrix} Request - Reply \\ P_{a} (Rqst, s Rply) = (new Γ_{v_{i} u_{k 1} v_{j}}) (new Γ_{v_{j} u_{k 2} v_{i}}) \\ (C 〈 Rqst 〉 | E 〈 Rply 〉) \\ C (Rqst) = \bar{Γ_{v_{i} u_{k 1} v_{j}}} 〈 Rqst 〉 . Γ_{v_{j} u_{k 2} v_{i}} (y) . \emptyset \\ E (Rply) = Γ_{v_{i} u_{k 1} v_{j}} (x) . \bar{Γ_{v_{j} u_{k 2} v_{i}}} 〈 Rply 〉 . \emptyset \end{matrix}

(3)

The request-reply message transaction involves two-way synchronization between a control device and an edge device. Two message channels $Γ_{v_{i} u_{k 1} v_{j}}$ and $Γ_{v_{j} u_{k 2} v_{i}}$ are instantiated to facilitate directed communication flow. Note that it is possible for $u_{k 1}$ to equal $u_{k 2}$ if a common communication link is used for both request and reply message exchange. After the control device process $C$ sends the initial $Rqst$ message, it sequences to wait for an input on $Γ_{v_{j} u_{k 2} v_{i}}$ . The edge device process $E$ receives the $Rqst$ on $Γ_{v_{i} u_{k 1} v_{j}}$ and outputs the $Rply$ using $Γ_{v_{j} u_{k 2} v_{i}}$ . Control device process $C$ subsequently receives the $Rply$ on $Γ_{v_{j} u_{k 2} v_{i}}$ and with the successful termination of $C$ and $E$ , the instance of $P_{a}$ is complete.

4.3 Control protocol classification

Communication paradigms are categorized according to the types of message transactions they incorporate. The Venn diagram in Figure 1 shows the seven communication paradigms. Class 1 incorporates request-only, unsolicited-reply, and request-reply message transactions. Class 5 incorporates request-reply message transactions.

For example, the DNP3 protocol used in the electric power grid belongs to Class 1. On the other hand, Modbus incorporates request-only and request-reply message transactions and belongs to Class 2.

Figure 1.

Communication paradigms.

For descriptive purposes, the seven communication paradigms are labeled as follows:

Class 1 – Unrestricted Paradigm;

Class 2 – Request Paradigm;

Class 3 – Notify Paradigm;

Class 4 – Asynchronous Paradigm;

Class 5 – Synchronous Paradigm;

Class 6 – Nagging Paradigm;

Class 7 – Chatterbox Paradigm.

The unrestricted paradigm expresses a range of functional operations as it incorporates all three types of message transactions. The request and notify paradigms are slightly more restrictive; both offer one-way message transactions as well as request-reply message transactions. The more restrictive asynchronous paradigm only supports one-way message transactions from control devices to edge devices or from edge devices to control devices. The synchronous paradigm only supports two-way synchronized message transactions between control devices and edge devices.

The nagging and chatterbox paradigms are an interesting set of degenerate paradigms. The paradigms are strictly one way and have limited utility in normal operations. However, an adversary may attempt to transition a control protocol to a degenerate paradigm. Interestingly, the communication paradigm determines the susceptibility of a control system to messaging attacks.

4.4 Modeling communication paradigms

This section describes the formalisms associated with modeling communication paradigms.

Definition 4.2 A communication paradigm $M = (m_{1} | m_{2} | \dots | m_{7})$ incorporates message transactions that are employed by a control system.

The following equations define the seven communication paradigms:

m_{1} = new Rqst, s Rply (P_{a} 〈 Rqst 〉 | P_{b} 〈 Rply 〉 | P_{c} 〈 Rqst, s Rply 〉)

(4)

m_{2} = new Rqst, s Rply (P_{a} 〈 Rqst 〉 | P_{c} 〈 Rqst, s Rply 〉)

(5)

m_{3} = new Rqst, s Rply (P_{b} 〈 Rply 〉 | P_{c} 〈 Rqst, s Rply 〉)

(6)

m_{4} = new Rqst, s Rply (P_{a} 〈 Rqst 〉 | P_{b} 〈 Rply 〉)

(7)

m_{5} = new Rqst, s Rply (P_{c} 〈 Rqst, s Rply 〉)

(8)

m_{6} = new Rqst (P_{a} 〈 Rqst 〉)

(9)

m_{7} = new Rply (P_{b} 〈 Rply 〉)

(10)

Note that the subscript identifies the specific paradigm.

A communication paradigm may invoke the message transactions that are specified in the corresponding equation. For example, the unrestricted paradigm defined by Equation (4) incorporates the request-only, unsolicited-reply, and request-reply message transactions.

Note that $P_{a}$ in Equations (4)–(10) references the request-only message transaction (Equation (1)); $P_{b}$ references the unsolicited-reply message transaction (Equation (2)); and $P_{c}$ references the request-reply message transaction (Equation (3)). The instantiation of new $Rqst$ and/or $Rply$ messages are passed as arguments to the appropriate message transaction $P_{a}$ , $P_{b}$ or $P_{c}$ . Based on the concurrency primitive, invoking a new instance of a $Rqst$ and/or $Rply$ message permits multiple processes to proceed independently.

Equations (1)–(3) define the syntax for valid message transactions in a control system. If a process is initiated but is unable to proceed and terminate (e.g. sequencing to wait for an input message from another process that does not exist), the corresponding message transaction results in a state of deadlock.

Definition 4.3 A message transaction is valid if and only if the processes that are initiated within the message transaction result in successful termination.

Note that message transactions are modeled as independent, unique instances. Consider a broadcast message sent from control device $v_{1}$ to edge devices $v_{2}$ , $v_{3}$ , $v_{4}$ , and $v_{5}$ . To specify the broadcast, the process $P_{a}$ is invoked four times, once for each transaction between $v_{1}$ and the specific edge device, thus providing four distinct process instances.

5 Modeling attacks on control systems

Process calculi provide a means for studying complex, concurrent systems. Equational reasoning allows the verification of correctness and safe operations of a system (e.g. determining whether a system can reach a deadlock state).²⁷ The analysis, however, primarily focuses on implementation behavior with respect to system design; the possibility of an adversary intentionally altering system processes is not considered.

This section introduces the notion of an adversary whose goal is to use messaging attacks to achieve a desired effect. An adversary has three entry points or avenues for launching attacks: (i) control device(s); (ii) edge device(s); and (iii) communication link(s). Control device compromise provides access between functional control system operations and the human controller. Edge device compromise provides access between the physical operations and the control system. Gaining access to the control system through a communication link provides specific man-in-the-middle access.

Depending on the level of access, an adversary may block and/or fabricate messages from the compromised device or link. The primitive operations of block and fabricate enable an adversary to launch a variety of attacks.

5.1 Extending the process calculus

The process calculus defines the valid message transactions for a control system. As such, the adversary’s actions must coincide with message transactions for an attack to be successful.

Consider the following POLL message transaction with respect to the compromise of an edge device $v_{3}$ .

POLL:

for $(n = 2; n < 4; n + +)$

$new Rqst, s Rply (P_{a} 〈 Rqst, s Rply 〉)$

$P_{a + +} (Rqst, s Rply) = (new Γ_{v_{1} u_{1} v_{n}}) (new Γ_{v_{n} u_{1} v_{1}}) (C 〈 Rqst 〉 | E 〈 Rply 〉)$

$C (Rqst) = \bar{Γ_{v_{1} u_{1} v_{n}}} 〈 Rqst 〉 . Γ_{v_{n} u_{1} v_{1}} (y) . \emptyset$

$E (Rply) = Γ_{v_{1} u_{1} v_{n}} (x) . \bar{Γ_{v_{n} u_{1} v_{1}}} 〈 Rply 〉 . \emptyset$

end for

The message transaction supports $Rqst$ messages from $v_{1}$ to $v_{2}$ and $v_{1}$ to $v_{3}$ . However, no message channel is defined from $v_{3}$ to $v_{2}$ . Thus, to coincide with a message transaction, the adversary must masquerade as a device within the message channel (i.e. spoof the message source). In this example, the only defined message channel to $v_{2}$ is $Γ_{v_{1} u_{1} v_{2}}$ so the message source must reflect $v_{1}$ . From a real-world perspective, this mirrors an edge device discarding any $Rqst$ message that does not appear to originate from the control device.

To extend the process calculus equations to specify adversary actions, the variable $X$ is introduced to represent an attack process. An attack process incorporates the block and/or fabricate primitive operators.

Definition 5.1 The block operator is specified as $Γ_{v_{i} u_{k} v_{j}} (ψ' \cdot NULL)$ with $ψ'$ representing the compromised device or link such that $ψ' = v_{i}'$ , $u_{k}'$ or $v_{j}'$ .

As a result of the block operator, the intended recipient $v_{j}$ does not receive the message. Block is always associated with the input construct.

Definition 5.2 The fabricate operator is specified as: (i) $\bar{Γ_{v_{i} u_{k} v_{j}}} 〈 ψ' \cdot Rqst 〉$ with $ψ'$ representing the compromised device or link such that a message channel exists from $ψ'$ to $v_{j}$ ; or (ii) $\bar{Γ_{v_{i} u_{k} v_{j}}} 〈 ψ' \cdot Rply 〉$ with $ψ'$ representing the compromised device or link such that a message channel exists from $ψ'$ to $v_{j}$ .

Note that in an attack process that spoofs the message source, $ψ' \neq v_{i}$ . Fabricate is always associated with the output construct.

Attack processes are inserted into message transactions in conjunction with control device processes ( $C$ ) and edge device processes ( $E$ ). The execution of message transactions is unchanged, with the exception that attack processes have precedence over system processes.

Consider the previous POLL message transaction. An attack process that spoofs a message from $v_{1}$ to $v_{2}$ (from the compromised edge device $v_{3}$ ) is represented as follows.

POLL:

for $(n = 2; n < 4; n + +)$

$new Rqst, s Rply (P_{a} 〈 Rqst, s Rply 〉)$

$P_{a + +} (Rqst, s Rply) = (new Γ_{v_{1} u_{1} v_{n}}) (new Γ_{v_{n} u_{1} v_{1}}) (C 〈 Rqst 〉 | E 〈 Rply 〉)$

$X (Rqst) = \bar{Γ_{v_{1} u_{1} v_{2}}} 〈 v_{3}' \cdot Rqst 〉 . \emptyset$

$C (Rqst) = \bar{Γ_{v_{1} u_{1} v_{n}}} 〈 Rqst 〉 . Γ_{v_{n} u_{1} v_{1}} (y) . \emptyset$

$E (Rply) = Γ_{v_{1} u_{1} v_{n}} (x) . \bar{Γ_{v_{n} u_{1} v_{1}}} 〈 Rply 〉 . \emptyset$

end for

Note that per Definition 5.2, the attack process message transaction is only valid if a message channel exists from $v_{3}$ to $v_{2}$ .

An alternative attack process includes compromise of control device $v_{1}$ and blocking any received messages from $v_{2}$ .

POLL:

for $(n = 2; n < 4; n + +)$

$new Rqst, s Rply (P_{a} 〈 Rqst, s Rply 〉)$

$P_{a + +} (Rqst, s Rply) = (new Γ_{v_{1} u_{1} v_{n}}) (new Γ_{v_{n} u_{1} v_{1}}) (C 〈 Rqst 〉 | E 〈 Rply 〉)$

$X = Γ_{v_{2} u_{1} v_{1}} (v_{1}' \cdot NULL) . \emptyset$

$C (Rqst) = \bar{Γ_{v_{1} u_{1} v_{n}}} 〈 Rqst 〉 . Γ_{v_{n} u_{1} v_{1}} (y) . \emptyset$

$E (Rply) = Γ_{v_{1} u_{1} v_{n}} (x) . \bar{Γ_{v_{n} u_{1} v_{1}}} 〈 Rply 〉 . \emptyset$

end for

This specification represents a denial-of-service attack on the system.

5.2 Attack considerations

As mentioned previously, the communication paradigm determines the susceptibility of a control system to messaging attacks. For analysis, this enables an adversary to abstract physical system attributes and characteristics in order to define generic attacks.

As an example, consider an adversary that desires to attack a specific system. The adversary first determines the communication paradigm (e.g. synchronous paradigm). The adversary may then apply messaging attacks that have been pre-defined via the process calculus for that paradigm. In essence, attack templates can be created that conform to system classes, much like a weapons cache. Indeed, as demonstrated in the next section, the ability to create a physical effect on an oil pipeline can be decomposed to abstract messaging attacks that are defined through the process calculus.

6 Modeling an attack on an oil pipeline

This section describes and models a pipeline rupture incident that occurred at Fork Shoals, South Carolina on 26 June 1996. The rupture released 957,600 gallons of fuel oil and caused damage estimated at US$20.5 million. According to the National Transportation Safety Board (NTSB) Pipeline Accident Report,²⁸ the incident occurred as a result of failures in system components and improper operator actions. However, as we show in this section, the same results can be produced by a targeted cyber attack. For brevity, only the critical events that led to the pipeline rupture are discussed.

6.1 Pipeline rupture incident

The Fork Shoals pipeline transports fuel oil from Atlanta, GA, to Greensboro, NC. Figure 2 shows the pipeline section of interest, which contains four pump stations ( $v_{2}$ – $v_{5}$ ), a delivery facility with breakout tankage and a control center ( $v_{1}$ ) located in a central office north of the pipeline. Control Center $v_{1}$ houses operators that remotely monitor and control the pipeline using communication links ( $u_{2}$ – $u_{5}$ ). The remote pump stations ( $v_{2}$ – $v_{5}$ ) each have one RTU that controls actuators and reads pipeline sensors. The delivery facility is monitored by the control center, but the communication link is not shown because it is not pertinent to the analysis.

Figure 2.

Pipeline layout.

The pipeline rupture was due to two primary factors: (i) increase in pressure flow beyond the maximum allowable pipeline pressure, and (ii) failure of operator to realize and correct the conditions before structural failure occurred. The control failures that resulted in the pressure increase occurred in the following chronological order:

Increase in Pumping Capacity (Control Failure 1): Pumping capacity is increased by starting additional pumps and/or turning on larger pumps and shutting down smaller ones. After a transfer to the delivery facility was completed, pumping capacity at downstream pumping facilities was sequentially increased to accommodate the additional fuel oil in the pipeline. In particular, Pump Stations $v_{2}$ and $v_{3}$ each started a second pump. Also, Pump Station $v_{4}$ started a larger pump and shut down a smaller one.

Failure to Start a Second Pump at Pump Station $v_{5}$ (Control Failure 2): The operator attempted to start a larger pump at Pump Station $v_{5}$ to increase capacity. The operator noted that a green light appeared on the console to indicate that the pump had started, but, for some reason, the pump did not start.

Stoppage of the Active Pump at Pump Station $v_{5}$ (Control Failure 3): Believing that two pumps at Pump Station $v_{5}$ were running, the operator stopped the smaller (and only operating) pump. Shutting down the only pump at Pump Station $v_{5}$ created a pressure surge that traveled upstream to Pump Station $v_{4}$ , causing its only operating pump to shut down due to high discharge pressure. The resulting second pressure surge caused the two pumps at Pump Station $v_{3}$ to shut down. The continued high fuel oil flow rate caused the pipeline pressure to grow rapidly, resulting in a rupture between Pump Stations $v_{2}$ and $v_{3}$ .

Meanwhile, the pipeline operator at Control Center $v_{1}$ ignored, misinterpreted, or did not receive alarm notifications. The following control failure hindered the pipeline operator’s situational awareness:

Failure to Receive and React to Alert Notifications (Control Failure 4): A pressure alarm was triggered shortly after the pump at Pump Station $v_{3}$ shut down; however, the operator took no action. In addition, low suction pressure alarms were triggered intermittently for readings at Pump Station $v_{3}$ , but the operator did not react because the alarms were behaving erratically and he assumed that the pressure readings were inaccurate. Moreover, the control system did not report the failure of the pump to start at Pump Station $v_{5}$ .

6.2 Oil pipeline system specification

The oil pipeline is modeled using the unrestricted paradigm with request-only, unsolicited-reply, and request-reply message transactions. Figure 3 presents the process calculus specification of the oil pipeline system.

Figure 3.

Process calculus specification of the oil pipeline system.

The conditions denote events that invoke system functions. The ConditionA event invokes POLL to facilitate normal round-robin communication; once initiated, the polling continues until it is specifically stopped. Likewise, the ConditionB event is invoked to send request-only messages from the control device $v_{1}$ to an edge device $v_{ψ}$ (e.g. for a broadcast message). The ConditionC event is invoked to send unsolicited-reply messages to $v_{1}$ from an edge device $v_{ψ}$ (e.g. in response to an alarm condition). Note that $ψ$ represents the device associated with the event that invokes the process.

POLL incorporates a request-reply message transaction between two system devices. Each iteration of the for loop in POLL instantiates a new process $P_{a}$ . Message channels exist only between the control device and subordinate edge devices. As such, an edge device (e.g. $v_{2}$ , $v_{3}$ , $v_{4}$ , or $v_{5}$ ) is not capable of invoking process $C$ within POLL because no message channel exists.

Finally, the implications of message payloads are abstracted to focus the analysis on control message interactions. For example, process $E$ in POLL binds the received $Rqst$ to variable $x$ before proceeding with the $Rply$ output. The edge device performs internal functions based on $x$ to generate the payload for the subsequent $Rply$ message.

6.3 Cyber attack on the oil pipeline

This section uses cyber attacks to recreate the control system failures that led to the pipeline rupture. The notion of an adversary using messaging attacks to create the control failures is now introduced in the model. The attack described below involves compromising the Control Device $v_{1}$ . Essentially, the attacker has ‘root’ access to $v_{1}$ , and can block and fabricate messages. The attack processes have been introduced into the system as demonstrated in Figure 4.

Figure 4.

Introduction of attack processes in the oil pipeline system.

The events Attack1a, Attack1b, and Attack1c invoke the functions that implement the adversary’s actions in Control Failure 1. Similarly, Attack2, Attack3, and Attack4 correspond to Control Failure 2, Control Failure 3, and Control Failure 4, respectively. Note that Attack4 is performed continuously to block alerts generated during the ongoing polling cycle. The other attack events are inserted into the polling cycle and executed once.

Figure 5 details three of the specific attack processes. Note the insertion of the attack process $X$ ; the remaining processes are unchanged because they define the message transactions employed by the control system.

Figure 5.

Attack processes for oil pipeline rupture incident.

For brevity, the for loop is considered unrolled for Attack1a and Attack2. That is, the Attack1a event is only executed for $n = 2$ . Likewise, the Attack2 event is only executed for $n = 4$ ; the other instances for n proceed normally. The Attack4 event blocks normal polling responses, as such, it executes for $n = 2$ –5.

In the Attack1a event, $X$ fabricates a $Rqst$ message from $v'_{1}$ to $v_{2}$ using the message channel from $v_{1}$ to $v_{2}$ : $\bar{Γ_{v_{1} u_{2} v_{2}}} 〈 v_{1}' \cdot Rqst 〉$ . Process $X$ then sequences to wait for an input. The edge device $v_{2}$ receives the message, binds the data to variable $x$ (turning on Pump #2 at Pump Station $v_{2}$ ), and sends the $Rply$ . The attack process $X$ discards the $Rply$ via block: $Γ_{v_{2} u_{2} v_{1}} (v_{1}' \cdot NULL)$ . Process $X$ and process $E$ both terminate and the attack instance is complete. The Attack1b, Attack1c and Attack3 events execute similarly.

The Attack2 event blocks a message from the Control Center $v_{1}$ to start Pump #3 at Pump Station $v_{5}$ and fabricates an acknowledgment that the pump has started. The $Rqst$ from $v_{1}$ to $v_{4}$ to start the pump is blocked by $v'_{1}$ : $Γ_{v_{1} u_{4} v_{4}} (v_{1}' \cdot NULL)$ . Subsequently, a $Rply$ message is fabricated to indicate the pump has started (when in reality it is still off): $\bar{Γ_{v_{4} u_{4} v_{1}}} 〈 v_{1}' \cdot Rply 〉$ . Both processes terminate and the attack instance is complete. Recall that attack processes have precedence over system processes (e.g. the input for $X$ is executed as opposed to the input for $E$ ).

The Attack4 event modifies the round-robin polling cycle in order to mask any alerts on the system. For each pump station, the $Rqst$ message from the control device is blocked and a fabricated $Rply$ message is sent to indicate normal operating conditions.

In the attack events, the ability to block a message is dependent on the message channel containing the compromised control device $v_{1}'$ . Similarly, as demonstrated in Attack1a, the fabrication of a $Rqst$ message is possible because a message channel exists from $v_{1}$ to $v_{2}$ . The Attack4 event is possible because the compromise of $v_{1}$ provides the adversary a message channel to/from each edge device. Finally, the attack events coincide with the process calculus specification of the oil pipeline system.

7 Discussion

In this section we discuss attributes of the model and the applicability to defining attack and defense strategies.

The model provides the ability to define attacks for control protocols despite differences in the implementation details (e.g. message format and payload characteristics). The specific protocol can be abstracted to focus on desired effects and attack strategies. After the attack processes are defined and the attack strategy is determined, the appropriate message format and payloads for the targeted protocol can be specified.

Consider a control protocol that belongs to the synchronous paradigm and an attack that closes a control valve and prevents the update. The attack involves fabricating a $Rqst$ message and blocking the $Rply$ message. The message transactions and attack processes are the same for any control protocol that belongs to the synchronous paradigm; unique protocols merely involve different message formats with different payloads.

For example, consider Modbus and Fisher ROC implementations that belong to the request paradigm. In the Modbus protocol, assume an attack process fabricates a $Rqst$ message that specifies a write action with opcode 05 for address 01 containing data value FF to close the control valve. The attacker then blocks the $Rply$ message that contains opcode 05 and address 01. In the Fisher ROC protocol, the same attack process may require fabricating a $Rqst$ message with opcode 181, a data offset of 6 and destination address 220; the $Rply$ message that is blocked contains opcode 181 and address 220.

The model provides a powerful mechanism for conceptualizing attacks in one control protocol and translating them to similar attacks in another protocol. The operation associated with rupturing a pipeline is very similar to an operation that turns off a section of the electric power grid or shuts down telephone service. The physical attributes (pumping stations, generators, and service switching/transfer points) and protocols (Modbus, DNP3, and SS7) for pipelines, power grids, and telecommunications infrastructures are different, but the underlying attack processes and sequences of attacks are practically identical.

For example, the masking operation on the Fork Shoals polling mechanism is applicable to numerous protocols in the oil and gas sector (e.g. Modbus and Fisher ROC) and to protocols in other sectors such as the electric power grid (DNP3) and manufacturing (Profibus). The actions require blocking $Rqst$ polling messages and fabricating normal $Rply$ messages within request-reply message transactions to mask alert conditions.

Similarly, attacks specified using the model can be categorized according to the communication paradigms. Attacks that contain attack processes for request-reply and request-only message transactions are effective for control protocols belonging to the asynchronous paradigm; attacks containing attack processes for request-reply message transactions are effective for control protocols that belong to the synchronous paradigm. Categorizing attacks in such a manner provides an easy way to determine whether an attack can be successful for a given protocol. It also provides the ability to retrofit attacks to other protocols that belong to the same communication paradigm.

An attack process is applicable to any communication paradigm that incorporates the message transaction containing the attack process. For example, an attack process for a request-reply message transaction is applicable to the unrestricted, request, notify, and synchronous paradigms. The applicability across communication paradigms helps determine the necessary modifications (i.e. addition or subtraction of attack processes) when translating an attack to a different paradigm.

Attacks devised for the unrestricted paradigm (e.g. DNP3) disregard attack processes for request-only and unsolicited-reply message transactions when translating to the synchronous paradigm. Alternatively, attacks devised for the synchronous paradigm must account for request-only and unsolicited-reply message transactions when translating them to the unrestricted paradigm.

8 Conclusions

The model presented in this research provides a mechanism for expressing attacks on control protocols. The model helps provide a comprehensive understanding of attacks that target control systems, which supports the development of attack and defense strategies.

The model defines system characteristics and message transactions using a process calculus. The formalisms associated with the process calculus provides an abstraction method for determining the attack and defense categories via the messaging paradigms. The model offers a powerful mechanism for conceptualizing attacks in one control protocol and translating them to similar attacks in another protocol. In fact, the model is capable of expressing attacks in diverse protocols that involve the exchange of messages.

In addition to conceptualizing common attacks and attack strategies for different protocols, the formal model assists in targeting specific protocol and system implementations. In particular, the model helps identify the intelligence requirements, articulate possible outcomes, and examine the feasibility of attacks based on the available information. Novel features of the model include the ability to analyze the complexity of attacks, demonstrate common vulnerabilities in control protocols, and classify attacks.

Future work involves attack automation and protocol simulation and verification. Efforts in this area support risk analysis, risk management, and the design of robust control protocols.

Footnotes

Disclaimer

Note that the views expressed in this article are those of the authors and do not reflect the official policy or position of the United States Air Force, Department of Defense, or the US Government.

Funding

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors.

Author Biographies

Jonathan Butts is an assistant professor of computer science at the Air Force Institute of Technology, Wright-Patterson AFB, Ohio, USA. He is also an active duty Captain in the United States Air Force. His research interests include critical infrastructure protection, malware analysis, protocol verification, and operationalizing military actions in cyberspace.

Mason Rice is an active duty Major in the United States Army. He received his PhD from the University of Tulsa, USA. His research interests include network and telecommunication security, and cyberspace deterrence strategies.

Sujeet Shenoi is the F.P. Walter Professor of Computer Science at the University of Tulsa, Tulsa, OK, USA. His research interests include information assurance, digital forensics, critical infrastructure protection, reverse engineering, and intelligent control.

References

Schneier

. Attack trees. Dr. Dobb’s Journal 1999; 24: 21–29.

Moore

Ellison

Linger

. Attack Modeling for Information Security and Survivability. Technical Note CMU/SEI-2001-TN-001, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2001.

Ten

Liu

Govindarasu

. Vulnerability assessment of cybersecurity for SCADA systems using attack trees. In: Proceedings of the IEEE Power Engineering Society General Meeting, 2007, pp. 1–8.

Huang

. An attack modeling based on hierarchical colored Petri nets. In: Proceedings of the Second International Conference on Computer and Electrical Engineering, 2008, pp. 918–921.

Templeton

Levitt

. A requires/provides model for computer attacks. In: Proceedings of the New Security Paradigms Workshop, 2000, pp. 31–38.

Neumann

Parker

. A summary of computer misuse techniques. In: Proceedings of the Twelfth National Computer Security Conference, 1989, pp. 396–407.

Undercoffer

Pinkston

Joshi

Finin

. A target-centric ontology for intrusion detection. In: Proceedings of the IJCAI Workshop on Ontologies and Distributed Systems, 2004, pp. 47–58.

Kuhl

Kistner

Costantini

Sudit

. Cyber attack modeling and simulation for network security analysis. In: Proceedings of the 2007 Winter Simulation Conference, 2007, pp. 1180–1188.

North American Electric Reliability Corporation. Reliability Functional Model, Function Definitions and Functional Entities, Version 5. Princeton, NJ: North American Electric Reliability Corporation, 2009.

10.

Stouffer

Falco

Scarfone

. Guide to Industrial Control Systems Security, Final Public Draft. NIST Special Publication 800-82, National Institute of Standards and Technology, Gaithersburg, MD, 2008.

11.

Stamp

Berg

Baca

. Reference Model for Control and Automation Systems in Electrical Power, Version 1.2. Albuquerque, NM: Sandia National Laboratories, 2005.

12.

Decker

. A risk assessment model for pipeline facility operations. Pipeline and Gas Journal 2009; 236: 38–44.

13.

Byres

Franz

Miller

. The use of attack trees in assessing vulnerabilities in SCADA systems. In: Proceedings of the International Infrastructure Survivability Workshop, 2004.

14.

East

Butts

Papa

Shenoi

. A taxonomy of attacks on the DNP3 protocol. In: Palmer

Shenoi

(eds), Proceedings of the Third Annual IFIP WG 11.10 International Conference on Critical Infrastructure Protection, 2009, pp. 67–81.

15.

Huitsing

Chandia

Papa

Shenoi

. Attack taxonomies for the Modbus protocols. International Journal of Critical Infrastructure Protection 2008; 1: 37–44.

16.

Cheung

Lindqvist

Fong

. Modeling multistep cyber attacks for scenario recognition. In: Proceedings of the Third DARPA Information Survivability Conference and Exposition, 2003, pp. 284–292.

17.

Zhang

Borror

. Robustness of the Markov-chain model for cyber-attack detection. IEEE Transactions on Reliability 2004; 53: 116–123.

18.

Carlson

Turnquist

Nozick

. Expected Losses, Insurability, and Benefits from Reducing Vulnerability to Attacks. Technical Report SAND2004-0742, Sandia National Laboratories, Albuquerque, NM, 2004.

19.

McDermott

. Attack net penetration testing. In: Proceedings of the New Security Paradigms Workshop, 2000, pp. 15–21.

20.

Henry

Layer

Zaret

. Coupled Petri nets for computer network risk analysis. International Journal of Critical Infrastructure Protection 2010; to appear.

21.

Peterson

. Petri Net Theory and the Modeling of Systems. Englewood Cliffs, NJ: Prentice-Hall, 1981.

22.

Boyer

. SCADA: Supervisory Control and Data Acquisition. Research Triangle Park, NC: The Instrumentation, Systems, and Automation Society, 2004.

23.

Baeten

. A Brief History of Process Algebra. Technical Report CSR 04-02, Technische Universiteit Eindhoven, The Netherlands, 2004.

24.

Milner

. Communication and Concurrency. Englewood Cliffs, NJ: Prentice-Hall, 1989.

25.

Fokkink

. Introduction to Process Algebra. Berlin: Springer-Verlag, 2000.

26.

Baeten

Bravetti

. A generic process algebra. In: Aceto

Gordon

(eds), Algebraic Process Calculi: The First Twenty Five Years and Beyond (BRICS Notes Series NS-05-3). Bertinoro, Italy: BICS, August 2005, pp. 24–29.

27.

Knottenbelt

Bradley

. Tackling large state spaces in performance modelling. In: Bernardo

Hillston

(eds), Formal Methods for Performance Evaluation (Lecture Notes in Computer Science, Vol. 4486). Berlin: Springer, 2007, pp. 318–370.

28.

National Transportation Safety Board. Pipeline Rupture and Release of Fuel Oil into the Reedy River at Fork Shoals, South Carolina. Pipeline Accident Report PB98-916502/NTSB/PAR-98/01, National Transportation Safety Board, Washington, DC, 1996.