Intrusion Detection in PLC-Based Industrial Control Systems Using Formal Verification Approach in Conjunction with Graphs
- 454 Downloads
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.
KeywordsPLC programming Formal verification PLC code security Graph comparison UPPAAL
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 . As the task and makeup of each layer are different from one another, attacks targeting different layers will not utilize the same technique . In , 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 ) 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 . 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 . 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 . 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 , 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.
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) . 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 .
The overall methodology followed in  crafts formal models from PLC programs that are mainly written in Structured Control Language (SCL). The work in  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 . 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 . Since we took ’s finding as the basis of our work, therefore, our proposed methodology also targets Siemens’ PLC and the same PLC languages as in . One of the limitations of  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 . 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 . 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.
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 .
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.
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  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  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 , 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 .
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
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.
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.
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
To protect the water tank from overflowing and
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.
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!.
- 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.
- 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 , 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 , 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, ’s attack will be detected as long as it can be observed on the graph. In , researchers utilized formal verification and model checking techniques in order to detect intrusions in PLC codes that will violate safety requirements. The work in  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).
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.
- 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.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.Loukas G (2015) Cyber-physical attacks: a growing invisible threat. Butterworth-Heinemann. https://www.elsevier.com/books/cyber-physical-attacks/loukas/978-0-12-801290
- 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. http://www.ieee.org/conferences_events/conferences/conferencedetails/index.html?Conf_ID=32799
- 6.Valentine SE (2013) PLC code vulnerabilities through SCADA systems. Diss. University of South CarolinaGoogle Scholar
- 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. http://www.ssic-conf.org/2015/quickstart/
- 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.Gjendemsjø M (2013) Creating a weapon of mass disruption: attacking programmable logic controllers. MS thesis. Institutt for datateknikk og informasjonsvitenskapGoogle Scholar
- 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.Klick J, Lau S, Marzin D, Malchow J-O, Roth V Internet-facing PLCs—a new back orificeGoogle Scholar
- 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. http://www.ieee.org/conferences_events/conferences/conferencedetails/index.html?Conf_ID=13730
- 14.McLaughlin SE et al (2014) A trusted safety verifier for process controller code, vol 14. NDSSGoogle Scholar
- 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. https://www.arm.com/about/events/design-automation-conference-2015.php
- 17.Baier C, Katoen J-P, Larsen KG (2008) Principles of model checking. MIT Press. https://mitpress.mit.edu/books/principles-model-checking. ISBN: 9780262026499
- 18.VERIMAG, http://www-verimag.imag.fr/BIP-Tools-93. Accessed October 2017
- 19.Fondazione Bruno Kessler, https://nuxmv.fbk.eu/. Accessed October 2017
- 20.Department of Information Technology at Uppsala University, Sweden and the Department of Computer Science at Aalborg University in Denmark, http://uppaal.org/. Accessed October 2017
- 21.http://www.iwote.com/arts/crafts/build-a-simple-water-level-control.html. Accessed October 2017
- 22.Eberle W, Holder L (2007) Anomaly detection in data represented as graphs. Intell Data Anal 11.6:663–689Google Scholar