Intrusion Detection in PLC-Based Industrial Control Systems Using Formal Verification Approach in Conjunction with Graphs



Vulnerability in industrial control systems (ICS) has increased radically in the past few decades. This can be accounted to reasons including accessibility of ICS through Internet, development of sophisticated attack methods, and advancement in Internet of Things (IoT). The damage that can be caused by attackers on insecure ICS could cost hundreds of human lives and a huge state economy. Therefore, having such systems every where around us makes the concern for security nothing but a priority. Programmable logic controllers (PLCs) are the central devices of ICS and also a target to attacks which aim at gaining access and privilege to the control logic of the controller. A successful alteration or intrusion of the control logic by attackers can have a catastrophic effect on the plant. In this paper, control logic intrusion detection methodology for PLC-based control systems is proposed. The methodology implements the detection process by comparing a potentially intruded PLC program with a trusted version of the program. In order to achieve this goal, a scheme is proposed that operates in sequence of stages by first translating the PLC program to formal models (based on previous research work), then translating the formal models to graphs followed by performing a comparison between a trusted system model graph and a potentially intruded system graph. In the last stage of the methodology, graph discrepancy analysis is made in order to identify any intrusions. For demonstration purposes, a water level control system is presented as a case study, which is modeled using UPPAAL toolbox. We have verified our methodology by developing an in-house software. Our test results prove the concept that intrusions can be shown as discrepancies in the graphs generated from the UPPAAL-based formal modeling, which can be detected utilizing the proposed graph comparison approach. The premise of our study is that logic intrusions in PLC based ICS can be identified by the changes in the PLC code, and the methodology we proposed can successfully detect those changes by observing the code’s graph model.


PLC programming Formal verification PLC code security Graph comparison UPPAAL 

1 Introduction

For years, industrial control systems (ICS) were physically isolated from any external network or they are only connected to trusted hardware or communication link [1, 2]. Hence, security was not in the picture of ICS world. But as the information technology (IT) advances and devices become more connected, securing the ICS network by air gapping (connection isolation) was not practical. Compelled by Internet of Things (IoT) revolution, today almost every ICS network is part of the global network. This has increased the productivity of ICS by providing a means to monitor and control the actual plant from anywhere in the world. On the flip side, it has caused serious security concerns since unauthorized individuals might gain access to the network and perform tasks that can have catastro- phic effect on the ICS. Recent research works show that vulnerabilities in ICS have been on the rise in the past few years [3]. Figure 1 shows this trend for ICS from 2009 to 2013. The sophistication of attacks has also been amplified. Taking Stuxnet as an example, in June 2010, its first version was released; the attack was planned through plugging an infected USB sticks into the employees computer. Then shortly around March and April 2010, a second and third variant was made with a capability of replicating itself and propagating through shared networked devices and printers [4]. Therefore, having such systems everywhere around us has increased the concern for their security. The damage that can be caused by attackers on insecure ICS could cost hundreds of human lives and a huge state economy.
Fig. 1

Attack incidents in industrial control systems from 2009 to 2013 [5]

A typical ICS system is composed of a management layer, supervision layer, real-time control layer, and a physical layer. A general architecture of ICS is shown in Fig. 2. The management layer and the supervision layers are network of computer systems collecting information from the plant and displaying the whole process of the system. These layers are also responsible for system configuration and passing commands to the controllers. The real-time layer is where the controller devices reside. The controller devices are electronic devices that execute the control logic of the process. At the real-time control layer, programmable logic controllers (PLCs) are the most dominating controller device in almost every ICS to this date [10]. The physical layer of ICS is the actual process plant consisting of components such as electromechanical relays, sensors, and actuators, which are usual part of any industrial unit.
Fig. 2

Industrial control system architecture [8]

All the layers of ICS, the supervisory and the management network layers, the real-time control layer, and even the physical plant, can be used as an entry point by attackers to damage the system [6]. As the task and makeup of each layer are different from one another, attacks targeting different layers will not utilize the same technique [7]. In [8], common attacks for each layer of ICS have been summarized. In supervisory and management layer, traditional IT attacks and deception (manipulating the right information) and denial of services (DoS) attacks (jamming communication channels to disturb information availability [9]) are common. Attacks can also be instantiated at the physical layer by intentionally altering the setup or configuration of the components of the plant. In the real-time layer, the most common attacks are response injection and command injection, which are the focuses of this paper.

Using this real-time layer as an entry point, attackers aim at getting access to the PLCs and compromising them. Firmware modification, control logic injection, and networking feature attacks are common against PLC-based control systems [5]. Firmware modification is an attempt to fully change the firmware of the PLC and get full control of it. Such attacks can be successful due to lack of frequent firmware updates and weak authentication features while updating [10]. Most vendors allow a network based including internetwork access-based firmware update mechanism, which can easily be compromised on security if proper measures are not taken. Control logic injection is a technique of seamlessly putting harmful instructions to the PLC and commanding it to do a specific task [11]. In this approach, once attackers get the control logic code of the PLC, they will inject their own PLC code that will run in parallel with the authentic PLC code after uploading it to the PLC. The PLC executes its normal logic and the injected code in a way that the operators will not notice. The injected PLC code can accomplish variety of tasks based on the application, for example learning about devices in the network, learning about the communication protocol the devices are using, learning system configuration values, learning the input and output ports, and so on. Any combination of this information can later be used to malfunction the normal operation of the plant.

Attacks targeting PLCs aim also at compromising them and getting full control of the whole ICS network to cause the intended damage. Once a single PLC is compromised, it is also possible to get access to the rest of the network. In [12], Berlin Secure Identity Research Group team from Freie Universität has demonstrated the possibility of compromising a PLC device as a gateway to reach the rest of the devices in the network. They implemented an automated code injection scheme where they first do SNMP (Simple Network Management Protocol) scanning to learn about the system (IP address and subnet learning to know the possible address and range of devices available in the network) and then they injected a light proxy socket code (undetectable due to its insignificant execution time) on compromised PLC to make it act as a gateway and allow access to other devices.

As can be seen from the above discussion, most of the researchers have been studying the possible breach of security in PLC-based ICS for network or further higher layer of abstraction. Some researchers in the past addressed the issue of possible PLC safety violation at the real-time control layer [13, 14, 15]. In this paper, we address possible security issues in real-time control layer of PLC-based ICS, i.e., malicious alterations of PLC codes. The methodology proposed in this paper implements the detection process by comparing a potentially intruded PLC program with a trusted version of the program. In order to achieve that, our scheme starts by translating the PLC program to formal models (based on other research works). After that, the formal models are transformed into graphs. Graphs have a virtuous property of representing formal models in a more efficient and comprehensive way. This process is followed by performing a comparison between a trusted system model graph and a potentially intruded system graph. We used a tool that can model, validate, and verify real-time systems, UPPAAL model checker, as it not only support time-based automata but it also provide an excellent graphical depiction of the states. Finally, using UPPAAL, graph discrepancy analysis is made in order to identify any intrusions. For the sake of demonstrating this methodology, we modeled an industrial water level control system in UPPAAL as a case study. Our results prove the viability of the proposed infrastructure. To the best of our knowledge, this is the first work in which PLC code intrusions have been studied and a formal verification and graph-based solution is provided.

2 Preliminaries

One of the main prior works we based our methodology on is a research done at CERN (Conseil Européen pour la Recherche Nucléaire/European Organization for Nuclear Research) [16]. Adiego et al. performed the research to apply formal verification on PLC program to make sure that the program is in accordance with its specification [16].

The overall methodology followed in [16] crafts formal models from PLC programs that are mainly written in Structured Control Language (SCL). The work in [16] can also translate other PLC languages, like Sequential Function Chart (SFC) and Structured Text (ST). Adiego et al. has also mentioned that their work focuses on Siemens PLCs but can be extended to PLCs from different vendors [16]. Usually, the difference between PLCs from different vendors carries only a slight syntactic difference. It is observed that such slight syntactic differences have very little or no effect on the transformation technique of reference [16]. Since we took [16]’s finding as the basis of our work, therefore, our proposed methodology also targets Siemens’ PLC and the same PLC languages as in [16]. One of the limitations of [16] is state explosion problem. State explosion problem is an exponential growth of state representation of the system for N number of variables in the system withk possible values [17]. It is specially a problem for model checking-based computation as it puts a challenge in model checking tools to check a very large number of states which is impossible at times. Different reduction and abstraction methods have been applied in order to overcome the state explosion problem in the methodology presented in [16]. However, it has been mentioned that the results obtained after all the transformations, from PLC code to IM (intermediate model) and then to UPPAAL and other model checking tools, were reasonably good.

The methodology is shown in Fig. 3. In the first stage, the PLC program is translated to IM, which can be thought of as a network of automata, synchronized with each other. In the second stage, the formal models are generated from the IM. During these transformations, formal models are input models for different formal verification tools like BIP [18], nuXmv [19], and UPPAAL [20]. An example transformation from PLC to UPPAAL is shown in Figs. 4 and 5. Figure 4 shows an example of a counter program in STL transformed into IM (intermediate language) and Fig. 5 shows its transformation to UPPAAL model.
Fig. 3

Fernandez’s methodology [16]

Fig. 4

ST PLC code for a simple counter (left) and its transformation to IM (right) [16]

Fig. 5

Transformed UPPAAL model for the counter example in Fig. 4 [16]

The following also added another example that models a simple communication protocol (we called it wait-busy) for control processes. Figure 6 shows the protocol’s ST code and Fig. 7 shows its transformed IM. In the protocol, there are two states (wait and busy) and three signals (listen, request, and done). Listen is to make the unit running this protocol in listening mode for incoming requests; otherwise, it will ignore any request. Request is to request a service from the unit and done is a signal that confirms the job that was being processed by unit is completed. The unit starts on wait state. If there is no request coming, it will keep itself in the wait state and keep listening. While in a wait state, if a request comes, the request will be served. While processing this request, the unit will not be listening to any incoming requests until it completes the current one. A completion of a request will be signaled by done flag where the unit starts to listen to incoming requests again and transition tothe wait state. Here, we have presented the design and transformation of such protocol using the methodology proposed in [16]. Figure 6 shows ST code and Fig. 7 shows its transformation to IM. Figure 8 shows the protocol’s UPPAAL model transformed from the IM.
Fig. 6

ST code for wait-busy communication protocol

Fig. 7

Transformed wait-busy communication protocol into IM

Fig. 8

Transformed UPPAAL model of wait-busy protocol

Our work adds a security feature to this methodology by applying graph-based comparison once the formal model is generated, which is also a reason why we choose UPPAAL among other choices of formal verification tools. The main idea is to perform security analysis on PLC codes via model checkers, for which we first need to transform PLC code into model checker, as such a work already exists; therefore, we utilized Fernandez’s methodology. Our methodology, which we named it UBIS (UPPAAL-based ICS security), applies the comparison between a trusted model and a potentially intruded model (both are UPPAAL-based models). This will be done in sequence of stages as shown in Fig. 9. UPPAAL is a toolbox for verification of real-time system represented by network of timed automata extended with integer variables, structured data types, and channel synchronization [20].
Fig. 9

UPPAAL-based ICS security (UBIS) methodology

2.1 UPPAAL System Model

UPPAAL is jointly developed by Uppsala University and Aalborg University. It is based on a theory of timed automata, which is a finite state machine extended with clock variables counting synchronously. A typical UPPAAL model contains a number of networked timed automata operating at the same time [20].

A UPPAAL model consists of declarations, automata templates, and system definition. A template is an entity consisting of Locations and edges. Locations are represented in circle and can be thought of as vertices for directed graphs. Locations are connected by edges. Each Location has Name, Invariant, and type (Initial, Urgent, and Committed). The Name field is a label for that Location. The Invariant field is an expression on clocks, differences between clocks, and Boolean expressions that specifies a constraint on the system. For instance, an invariant expression
$$ x<3 $$

in a particular Location, wherex is clock, constrains the system to stay in this location for clock count of 0 to 2. States which violate the Invariant are undefined. An Initial type of location is the starting state of a system. There can only be one Initial location in a single template. Based on their behavior in time, Locations can be Urgent or Committed. An Urgent location is a state where time is not allowed to pass. A transition has to occur with no time count once in Urgent location. Committed locations also freeze time similar to Urgent locations with additional priority of committed nodes; if the process is in a Committed location, the next transition must involve one of the Committed locations.

Edges in UPPAAL connect Locations and they are characterized by Selections, Guards, synchronizations, and Updates fields. The select field binds a system variable to a specific range. For instance, an edge with select field
$$ i : int[0,3] $$
binds the variable i between 0 and 3. The implication is any event that will fire this edge can only be active if i is in this range. The Guard field specifies a condition that must be evaluated to true in order to fire the edge. An example can be
$$ x >= 1 \&\& x <= 2 $$
which says an edge with this guard can be fired whenever this expression is true which is when clock x is between 1 and 2. UPPAAL allows synchronization of two processes when an enabled edges is annotated with complementary synchronization labels, for instance
$$ A? \mathbf{and} A! $$
When two processes synchronize, both edges are fired at the same time where an edge with A! being the emitter of the synchronization on channel A and an edge with A? being the receiver. The Update field is an expression that will update system variables after the current edge is fired. The next edge will take the updated system variable. For instance, if one wants to reset the clock once the current edge is fired can set an
$$ x := 0 $$
on the Update field. For further details on UPPAAL tool, we refer to reference [20].

2.2 Graph Terminologies

UBIS uses graph in order to capture the information in a given UPPAAL model and thereafter to apply a comparison algorithm. For the purpose of fully capturing the information contained in a UPPAAL model, we have used attributed graphs.

Let G(N,E) be a graph with a set of nodes (vertices) N and a set of edges (links) E. An attributed graph AG is a graph whose nodes and edges are kind of objects assigned a single value or vector of values as attributes. In our attributed graph, the attributes are different types of expressions similar to UPPAAL.

Let AG (Object N, Object E) be our attributed graph with a set of object nodes N and a set of object edges E. A node object N is an object having Name, Invariant, and Type as attributes. An edge object E is an object having Start, End Select,Guard, Sync, and Update as its attributes. As can be understood from our attributed graph definition, this graph can capture all the information fields of a UPPAAL model.

3 UBIS Methodology

Figure 9 shows our proposed UBIS methodology. It has three stages of computation shown as steps (generate UPPAAL model, generate graph, and compare graphs) in the figure. Our methodology starts from both the Golden model and the Current model as UPPAAL-based models. The Golden model is a UPPAAL-based model extracted from a trusted (intrusion-free) PLC program. The model we called Current model is also a UPPAAL-based model generated from the currently executing and potentially intruded PLC program. Both versions of the PLC codes are the basic inputs to UBIS. The PLC codes can be extracted in different ways from the running system. This work assumes the case where the defender has the access to the actual real-time pre-compiled PLC-source code. We assume that the intruder may intrude the PLC’s source code by accessing it physically from a machine or via a network. In such a case, a defender may log in into the machine that contains the existing source code, locally or remotely, to look for the currently running source code, and transform it into UPPAAL model to detect for the possibility of intrusions. Other possibilities, which were not the focus of this work, include extraction of the binary codes running on the PLC and transforming it into a format that can be analyzed (reference [14] has proposed such a solution) or, even better, if the binary code can be decompiled into PLC-source code. Other techniques can also be integrated with our methodology as long as the PLC code can be retrieved. Since the goal of this work is not the retrieval of PLC-source code from binary information, therefore, it is not further discussed in this paper. However, it is worth mentioning that it is doable and reference [14] has provided some results in this direction.

The premise of the work is that if we can capture all the details of UPPAAL model into a graph then any discrepancy in the two codes can be identified through a comprehensive comparison of the two graphs. Therefore, any discrepancy of the Current model with the Golden model confirms any possible intrusion in the code. It is important to mention that transforming the original PLC code to UPPAAL model faces a state space explosion problem. As mentioned earlier, in [16], the researchers have applied different reduction and abstraction methods to alleviate this problem. The UPPAAL model we get from this methodology is a model that has been generated after reduction and abstraction are applied which means that some details of the original PLC code can be lost there. Implicitly, this is one of the limitation of our proposed work as well. However, it has been shown that results obtained from such methodology were satisfying when applied to real-life PLC programs [16].

The main argument of our solution is any code injected into the original PLC code will manifest itself by some properties of the graph generated from the intruded PLC code. The manifestation can be difference in number of nodes, number of edges, and difference in transitions and conditions of transitions between the graph generated from the Golden model and the Current model generated from the system under investigation. To illustrate UBIS methodology and its computational steps, we are explaining an example using a small UPPAAL model, shown in Fig. 10.
Fig. 10

Two synchronized processes (templates)

3.1 Step 1—Generating UPPAAL Model

The UPPAAL model shown in Fig. 10 shows two synchronized UPPAAL models with five states in total. The first model (left side) has three states A, B, and C with A being Initial location, B having Invariant x < 3, and C being an Urgent location. The second process has two states M and N. In the first model, the edge AB (from A to B) has Guard field y >= 5, Update field x := 0, and Select and Sync field null or empty. Edge BC has Guard field z == 0 and the other fields null. Edge CA is characterized by Synchronization S! which is synchronized with edge NM in the second process. Hence, edge CA and NM can fire simultaneously, if the condition y > 3 is satisfied. Similarly, edge MN has Guard y >= 5 and Update field x := 0 with other edge fields empty.

The next step in UBIS methodology is capturing the system model as graph. This will be applied for both the Golden and Current UPPAAL models as indicated in our proposed methodology, shown in Fig. 9.

3.2 Step 2—Graph Generation

UBIS’s graph generation stage translates UPPAAL model into attributed graphs. To automate the process, we exploit parsing of the UPPAAL models’ XML format. Figure 11 shows an attributed graph depicting the node translation. As shown in the figure, each node will be assigned vector of values derived from the corresponding UPPAAL model. The figure shows the two graphs separately for the sake of clarifying the graph generation step; however, they will be merged into one attributed graph as will be described next.
Fig. 11

Node translated-attributed graphs. Each node on the graph are assigned vector of values

By the same token, edge translation for the UPPAAL model, shown in Fig. 10, is shown in Fig. 12. The edge object contains six fields capturing all UPPAAL’s edge information.
Fig. 12

Edge translated-attributed graphs. Each edge is assigned vector of values

After node and edge generation of the UPPAAL model, the next step will be merging graphs into one attributed graph if there are more than one, as we considered in the example shown in Fig. 10. Since we are only concerned about the information captured in the node and edge objects, merging together will not change the model property in anyway.

Consequently, the final attributed graph generated will be a single graph containing the node table of Fig. 13 and edge table of Fig. 14. It is important to note here that the whole translation and graph generation process will be done for both Golden model and Current model. At this stage, all the input information we need to make a comparison is available.
Fig. 13

Node table. Every node object is summarized in one node table

Fig. 14

Edge table. Every edge object is summarized in one edge table

3.3 Step 3—Graph Comparison

Once we captured graph information of the corresponding Golden model and the Current model, the next step is making a graph comparison. As already noted, all the information in the model are collected in two tables of the attributed graph namely the node table and the edge table. Our graph comparison algorithm basically compares each entry of the node table of the Golden model with the corresponding entry of node table of the Current model. The same procedure will also be computed on the edge tables.

The algorithm we developed is shown in Fig. 15. First, the algorithm will check if there is a difference in number of nodes and number of edges between the Golden graph (GG) and the Current graph (CG). If there is, it will output the difference in number and also the additional nodes that caused this difference and it will return (code lines 1 to 11 in Fig. 15). If there is no difference, the comparison starts to compare node fields one by one. Starting from the first tuple of the node table, it will compare if the name of the node, the Invariant field of the node, and the type of the node are the same with its counter part in CG node table. If all of the fields are the same, the algorithm will signal their matching; if not, it will provide the information on the respective discrepancy. This will be done for all the nodes in the graphs (code lines 12 to 24 in Fig. 15). Likewise, comparison for edge vector will follow by comparing each tuple of the GG edge table with its counter CG edge table. If all the fields in the edge vector matches the algorithm will signal so, other wise, it will show the fields in which the two graphs do not match (lines 25 to 49 in Fig. 15).
Fig. 15

Graph comparison algorithm

As discussed above, UBIS perform tuple by tuple comparison on each field of the Golden and the Current graph. Another way of comparison can be done by computing text comparison between the XML code of the Golden and the Current UPPAAL models. However, the result from such comparison will be too crude to pinpoint the discrepancies and relate them to the actual system. For instance, such text comparison can signal a discrepancy for space character difference or for some random symbol difference in the UPPAAL XML, which does not have an implication to the actual control system. On the other hand, UBIS carry out the comparison only on fields that are representations of the control system states which are extracted as graphs from the UPPAAL XML. A comparison done on such graphs will then help us make a direct relation between the discrepancies and the actual system’s states or behaviors.

So, at this stage of UBIS methodology, we have found vector of values where the trusted model is not matching with the current model. What to do with these vectors very much depends on the application and the way the control engineers would like to be notified about it. The information can be sent to operators for further analysis and investigation in case of discrepancies. It is important to mention that the frequency of checking discrepancy and reporting to operators depends on the application. For high-risk applications and PLCs with excessive computing roles, the proposed methodology can be applied more frequently with a worst case scenario of applying it every clock cycle before the controller sends a control signal to the actual plant. Whereas for low-risk applications and PLCs involving lower computation roles, even less frequent monitoring would serve the purpose. However, the optimum frequency can be set up by the system designers. Finding out such optimum values is beyond the scope of this paper.

Since our methodology applies a content-based comparison, therefore, it supports scalability. Content (node and edge content)-based comparison between the Golden and Current graph for a finite size system for even a very large system can easily be done. That is, the comparison algorithm compares the contents or the entries of each node and edge of the two graphs. Therefore, unless there is a performance limitation on the machine running the comparing algorithm (which can easily be solved by running the program on a machine with a good performance), the algorithm can execute on systems with any size. If our methodology was similar to model checking, where every state and every variable range has to be checked over time, scalability of the methodology would be a concern. However, our methodology unlike model checking abstracts many details into the graphs, and therefore, for both small and large systems, we need to only analyze the set of nodes and their respective edges.

On the other hand, our methodology can be extended to perform some form of alarm by making risk analysis on the vectors found from our methodology. The vectors we found from our graph comparison algorithm are simple values but their implication on the actual system might be devastating. The next section discuss this in detail. A risk assessment, a method that can identify the magnitude of the intrusion and its effect on the actual system, can be co-joined with our methodology for further understanding of the attack and its impact on the system, which will be subject of future study.

4 Case Study: Water Level Control System

In order to emulate a real-life control system and help us analyze our methodology, an industrial water level control system is implemented. The water level control system, shown in Fig. 16, has three main units, water tank, water reservoir, and a controller controlling the pump. The tank takes the water discharged by the pump and passes it to the other systems at some rate. The reservoir keeps the water for the pump to discharge it to the water tank. The tank and the reservoir have sensors installed to detect when the water level in the tank is high and when the water in the reservoir is empty (when the water gets below some low threshold), respectively.
Fig. 16

Water level control system [21]

The two main goals of this water level control system are:
  1. 1.

    To protect the water tank from overflowing and

  2. 2.

    To protect the pump from running while the reservoir is empty

Step 1:
We modeled the system using UPPAAL into three timed automatas (TA) synchronized to each other: a tank automata, reservoir automata, and controller automata. The water tank automata, shown in Fig. 17, has two states (High and notHigh). As the name implies, High is a state where the water level hits the high threshold and notHigh is any level below this threshold. The water tank stays in notHigh state till the water level hits the high threshold (in this case tankHigh) where it will make transition to state High. During this transition, we updated the variable waterLevelTank (which would be the sensor in the real system) to tankHigh. When the water level is reduced to a threshold low, the system makes a transition to notHigh updating the water level to tankLow. Here, it is important to notice also the synchronization label, tankLessFull!. As already discussed in Section 2.1, two different automatas in UPPAAL can synchronize each other in synchronization enabled edges annotated with complementary synchronization labels (A? and A!, for instance). Therefore, in our model, the water tank synchronizes with the controller unit via tankLessFull! signal. The water tank unit is the sender unit and controller is the receiver unit.
Fig. 17

Water tank (left) and water reservoir (right) UPPAAL models for the water level control system

Similarly, the water reservoir automata has two states (Empty and notEmpty), shown in Fig. 17. Empty represents a state where the water level in the reservoir is less than some low threshold (resLow) and notEmpty represents any water level above this low threshold. Under normal operation, the reservoir stays in notEmpty state until the water level drops to low, then it will make a transition to Empty state also updating the waterLevelRes to resLow. After the reservoir gets full, the system will make transition to notEmpty state, updating the current water level to resHigh and emitting a synchronization signal fullRes!.

The controller model has six states (Start, pumpOFF, pumpON, waitForWater, waitForTankLessFull, and Check), shown in Fig. 18. The states represent the following scenarios: Start—controller gets turned on, pumpOFF—pump off state, pumpON—pump on state, waitForWater—wait state for the reservior to get full after it gets empty, waitForTankLessFull—wait state for water level of the tank to get reduced to low after the tank hits high water level. Once the controller is on (Start), it will make a transition to pumpON if waterLevelTank, which indicates the amount of water in the tank is less or equal to high threshold of the water tank. If the waterLevelRes is low then pumpOFF state turns water pump off. In order to differentiate which event caused the pumpOFF state (low water in reservoir or high water in tank), we introduced a variable, case, which will be used to make a transition to either waitForWater or waitForTankLessFull. After waitForWater state, before the pump is turned on a check for tank water level is performed at the Check state in case both unwanted events happen at the same time. Similarly, after waitForTankLessFull, a check is made if reservoir is empty before turning the pump on. The edges from waitForWater and waitForTankLessFull to Check are synchronized with reservoir and tank processes respectively. It is important to notice that, for instance, if the reservoir is empty, the pump is off and then after waiting for water in the reservoir in the next state, before the pump is on, there should not be another transition in the reservoir process (since we already know that there is enough water after the waitForWater state and pump was not on after the last time pump turned off). To account for this scenario, we introduced a variable, noResAction. For similar reason in the waitForTankLessFull path, we introduced noTankAction.
Fig. 18

Controller model in UPPAAL for the water level control system

Step 2:
This step implements UBIS’s graph generation stage for the water level control system discussed above. Since this step is discussed in detail in the methodology section, we only have shown the node and edge table of the attributed graph here. Figures 19 and 20 list the translated nodes and edges of the water control system from the designed UPPAAL model into an attributed graph, respectively.
Fig. 19

Node table for the water level control attributed graph

Fig. 20

Edge table for the water level control attributed graph

Step 3:

As we have the information on the nodes and edges, the next step is to compare the two graphs. Every node and edge in the Golden graph are compared to its counter Current graph. A single node comparison (a single tuple in the node table) compares every attribute (field in that specific row) of the two model graphs and an edge comparison does the same. For instance, let us assume there is an intrusion that is shown in the Current graph as alteration of the Guard condition when making a transition from pump on state (pumpON) to pump off state (pumpOFF). This intrusion can also be intelligent enough to make this change only when the Tank is full since we have two possibilities (Tank full and Reservoir empty) to make this transition. Let the change made to Guard be w a t e r L e v e l T a n k >= t a n k H i g h + Δ, while the correct Guard in the Golden graph is w a t e r L e v e l T a n k >= t a n k H i g h. This condition shows that the intruder has changed the water level threshold by Δ for turning off the pump. The physical significance of this intrusion is clear; the pump will keep discharging water into the Tank and the water will overflow, assuming Δ is high enough. This Guard information is represented in the 11th row of the edge table, Fig. 20. A comparison between the 11th row of the Golden graph edge table and the 11th row of the Current graph edge table will be able to reveal this discrepancy Δ.

We would like to point out that comparing graph information is a more convenient way for interpreting the comparison output and also from the implementation perspective. Moreover, the great advantage of our graph-based methodology is observed in our ongoing extension of this work which is applying machine learning techniques that can predict if intrusions has happened by learning previous state of the system over time while the system is operating in its normal conditions. In our ongoing work, a dataset will be created that has each state of the translated graph as one data point. By collecting several datasets over a long period of time, we anticipate to learn a pattern of the normal operation of the system. It is, therefore, possible to observe any abnormal pattern (which can be due to the effect of an intrusion) after learning the normal behavior of the system using existing machine learning techniques. We strongly believe that moving forward in ICS security, adopting machine learning-based decision-making will be more efficient and accurate even compared to existing security methodology. While other forms of comparison like signature comparison or equivalence checking tools can be adopted, we believe none of the existing tools provide such flexibility and scalability for our methodology to adopt learning-based algorithms.

The limitations of our methodology are the duration it needs to pinpoint a discrepancy and its memory requirement when the system gets large. When a system is large, the number of nodes and edges and the information carried by both are also large which requires large memory to store all the information. As discussed in the above sections, the comparison algorithm in our methodology works by traversing and comparing each node, edge of the Current graph, and the entries each carry with their corresponding entries in the Golden graph. Therefore, executing such comparison for large graphs will have some limitation on the time it takes. However, this also depends on the performance of the machine the program is running. A test run on UPPAAL-modeled water level control system has confirmed this. Hence, to apply UBIS to large industry size system models, a high performance machine would make the detection time faster.

5 Comparison with the State-of-the-Art Methodologies

This section compares our methodology with other research works. In [22], a work that detects anomalies in data represented as graphs has been proposed. The researchers have shown the effectiveness of their approach for varying graph sizes with random anomalous insertions and they reported some percentage of false positives. However, in our methodology, we can detect 100% discrepancies as long as the intrusions are visible in the translated graphs. This is because the graph comparison algorithm performs literal comparison on the two graphs’ respective fields; therefore, it is not possible for the algorithm to return false discrepancies. In [12], researchers developed an attack that takes an execution time around 1.35 ms on a PLC with scan cycle of 150 ms. They argued that their injection is undetectable since it has small execution time compared to the scan cycle. However, in our methodology the time an attack takes will not hinder the accuracy of the detection process. UBIS works on the content of the currently running program and checks if there are any changes from its original version. This processes are not affected by the inserted code execution time and size. Therefore, [12]’s attack will be detected as long as it can be observed on the graph. In [23], researchers utilized formal verification and model checking techniques in order to detect intrusions in PLC codes that will violate safety requirements. The work in [23] applies model checking on a model generated from PLC code using a negated safety requirements (unsafety requirements) as a specification formula. They searched for a witness path that satisfies the negated safety specification in the model. If there is no witness path, then the code is considered safe to be executed. This method will not detect intrusions that will not violate the system’s safety requirements. However, in our methodology, any intrusion even those that do not violate the safety requirement can be captured as discrepancies since our methodology applies content-based comparison on the two graphs. Example of such intrusions can be stealthy code insertion that aim at learning about the system rather than causing system malfunction (violating safety requirement).

6 Conclusions

Security of ICS is a great concern today. In this paper, an intrusion attack detection methodology, UBIS, has been proposed. The methodology applies graph-based comparison between graph generated from trusted PLC program (Golden graph) and graph generated from currently running PLC program (Current graph).

The proposed scheme assumes having a UPPAAL system model generated from a PLC program. The generated UPPAAL models are then translated to attributed graph structures which will capture the formal models (UPPAAL model) in an efficient and comprehensive way. Following a thorough graph comparison is performed between a trusted and potentially intruded graph for all node and edge attribute fields. Any discrepancy while comparing the two graphs signifies a possible intrusion. The graph-based comparison provides an advantage of understanding the discrepancies in light of the actual system characteristics while other methods, for instance a direct string comparison of the XML code of two UPPAAL models, would just give an incomprehensible string difference. Our methodology is able to detect any discrepancy between the two models in a reasonable amount of time. Test runs on the UPPAAL-modeled water level control system confirms the efficiency of the proposed intrusion detection methodology. To the best of our knowledge this is the first work that utilizes graph-based theory and formal verification techniques to identify security threats in PLC codes of ICS.

Even though the case studied here considered small size model of industrial control systems, the idea can be extended to large industrial control systems.


  1. 1.
    Schwartz M et al (2014) Emerging techniques for field device security. IEEE Secur Priv 6:24–31CrossRefGoogle Scholar
  2. 2.
    Krotofil M, Dieter G (2013) Industrial control systems security: what is happening?. In: 2013 11th IEEE international conference on industrial informatics (INDIN). IEEEGoogle Scholar
  3. 3.
    Cardenas A, Amin S, Sinopoli B, Giani A, Perrig A, Sastry S et al (2009) Challenges for securing cyber physical systems. In: Workshop on future directions in cyber-physical systems security, vol 5Google Scholar
  4. 4.
    Loukas G (2015) Cyber-physical attacks: a growing invisible threat. Butterworth-Heinemann.
  5. 5.
    Yang W, Qianchuan Z (2014) Cyber security issues of critical components for industrial control system. In: 2014 IEEE Chinese guidance, navigation and control conference (CGNCC). IEEE, pp 2698–2703.
  6. 6.
    Valentine SE (2013) PLC code vulnerabilities through SCADA systems. Diss. University of South CarolinaGoogle Scholar
  7. 7.
    Drias Z, Serhrouchni A, Olivier V (2015) Analysis of cyber security for industrial control systems. In: 2015 international conference on cyber security of smart cities, industrial control system and communications (SSIC). IEEE, p 18.
  8. 8.
    Huang S et al (2015) Cyber-physical system security for networked industrial processes. Inte J Autom Comput 12.6:567–578CrossRefGoogle Scholar
  9. 9.
    Lu T et al (2015) Towards a framework for assuring cyber physical system security. Int J Secur Appl 9.3:25–40Google Scholar
  10. 10.
    Gjendemsjø M (2013) Creating a weapon of mass disruption: attacking programmable logic controllers. MS thesis. Institutt for datateknikk og informasjonsvitenskapGoogle Scholar
  11. 11.
    Hadziosmanovic D et al (2013) Through the eye of the PLC: towards semantic security monitoring for industrial control systems. International Computer Science Institute, BerkeleyGoogle Scholar
  12. 12.
    Klick J, Lau S, Marzin D, Malchow J-O, Roth V Internet-facing PLCs—a new back orificeGoogle Scholar
  13. 13.
    Lee EA (2008) Cyber physical systems: design challenges. In: 2008 11th IEEE international symposium on object oriented real-time distributed computing (ISORC). IEEE, pp 363–369.
  14. 14.
    McLaughlin SE et al (2014) A trusted safety verifier for process controller code, vol 14. NDSSGoogle Scholar
  15. 15.
    McLaughlin S (2015) Blocking unsafe behaviors in control systems through static and dynamic policy enforcement. In: 2015 52nd ACM/EDAC/IEEE design automation conference (DAC). IEEE, pp 1–6.
  16. 16.
    Adiego BF et al (2014) Bringing automated model checking to PLC program development—a CERN case study—. IFAC Proceedings 47.2:394–399CrossRefGoogle Scholar
  17. 17.
    Baier C, Katoen J-P, Larsen KG (2008) Principles of model checking. MIT Press. ISBN: 9780262026499
  18. 18.
    VERIMAG, Accessed October 2017
  19. 19.
    Fondazione Bruno Kessler, Accessed October 2017
  20. 20.
    Department of Information Technology at Uppsala University, Sweden and the Department of Computer Science at Aalborg University in Denmark, Accessed October 2017
  21. 21.
  22. 22.
    Eberle W, Holder L (2007) Anomaly detection in data represented as graphs. Intell Data Anal 11.6:663–689Google Scholar
  23. 23.
    Zonouz S, Rrushi J, Steve M (2014) Detecting industrial control malware using automated PLC code analytics. Secur Priv IEEE 12.6:40–47CrossRefGoogle Scholar

Copyright information

© Springer International Publishing AG 2017

Authors and Affiliations

  1. 1.Electrical and Computer EngineeringTennessee Technological UniversityCookevilleUSA

Personalised recommendations