Armor PLC A Platform for Cyber Security Threats

Armor. PLC: A Platform for Cyber Security Threats Assessments for PLCs Wenhui Zhang*, Yizheng Jiao**, Dazhong Wu***, Srivatsa Srinivasa*, Asmit De*, Swaroop Ghosh*, Peng Liu* *Pennsylvania State University, State College, PA, 16803 **The University of North Carolina at Chapel Hill, NC, 27599 *** University of Central Florida, Orlando, FL, 32816

Armor. PLC --- A cyberattack-induced error detection, isolation, and mitigation system that can be retrofitted to legacy PLCs making them more resilient to contemporary cyberattacks. Overview: Our Approach: Ladder Logic Validation • a stateless network based Deep Packet Inspection (DPI) system, for threat assessment. This system could detect zero-day attacks. • an overlay network with record & replay mechanism for PLCs. • it captures pin values with a sensitivity of 50 microseconds. The false positive rate is 1% along with a latency of 25 milliseconds in our abnormal detection. Source code : https: //github. com/wenhuizhang/Armor. PLC

1. Vulnerabilities in PLC Ecosystem ● ● Vulnerabilities in configuration. [Plaintext conf] Vulnerabilities in network. [Connected Industry 4. 0] Vulnerabilities in operating system. [e. g. Stuxnet] Vulnerabilities in Pin I/O. [No sanitization]

2. Threats in PLC Ecosystem ● ● ● Hacking PLC Configuration. Hacking OS. Modifying the User Space Programs. Monitoring Pin/Data/Configuration. Return Oriented Programming Attack.

3. Ladder Logic Ladder logic to represent logic of PLCs. ● ● ● Monitoring manufacturing process approach requires excessive resources. Qo. S standards should be tested is still a challenge. In classical Qo. S validation and verification focus on verification of control logic [8], control flow [9], data flow [10], computation [11] and memory I/O activities [12]. Furthermore, PLCs have a specific control logic pattern and are programmed in the language of ladder logic. Existing techniques to protect computer systems, such as control flow [9], data flow [10] and memory I/O activities [12] verification are too expensive for the protection of PLCs.

4. Threat Model There are five main components involved in PLC execution process: (1) Virtual PLC logic wrote in ST file format; (2) Open. PLC software stack; (3) Jessie OS which is a Linux distribution; (4) Raspberry Pi board; (5) Network communication with Cloud. Where (1) network communication with Cloud is malicious; (2) Raspberry Pi 3 (RPi 3) board is secure; (3) Jessie OS is benign; (4) Open. PLC software stack is benign; and (5) Virtual PLC is vulnerable. Figure 4. System and Threat Model of Virtual PLCs Virtual PLC logic relies on Open. PLC Software Stack to realize its functionality in ladder diagrams and communicate with Network through TCP requests. Virtual PLC logic is translated into system calls, which could be recognized by Jessie OS. This translation is done through Open. PLC Software Stack. In this way, virtual PLC logic is able to materialize its logic to the physical world, such as Wi. Fi and USB shield.

5. Armor. PLC Architecture Figure 5. Virtual PLC cluster in Open. PLC for attack detection and mitigation 5. 1 Capturing Stage: Pin Status Recording. 5. 2 Communication Stage: Multi-Layer Management. 5. 3 Control Stage: Pin Status Replay. Figure. 6. Communication protocol of Record and Replay of Open. PLC on Raspberry Pi

5. Armor. PLC Architecture （Continued） 5. 1. 1 Output Value Configuration Comparison. Infected PLCs produce unexpected command, control functionalities and affect the output pin status. We can detect whether PLCs are infected by comparing the pin status of infected PLCs and non-infected ones. 5. 1. 2 Use Known Input/Output to Validate Control Logic. Because we know the expected logic and expected input/output values, compare and monitor pin values with expected ones to validate control logic. 5. 1. 3 Timing Comparison. Because infected PLCs introduce more functionalities than healthy ones, the computation time they consume for one routine task are higher than healthy PLCs. Figure 7. Secure PLC network architecture with Raspberry Pi running Open. PLC

6. Evaluation • correctness of the defense mechanism; • sensitivity of the implemented methodology in terms of time and input/output frequency; • robustness of the developed isolation and mitigation strategy. This program is running on a real gas pipeline testbed. The program has one analog input (from a pressure sensor) and two digital outputs (one pump and one valve). The PLC must read the current pressure and decide to turn the pump on or off based on the pressure value. If the pressure is too high, the pump should be turned off. If the pressure is too low, the pump should be turned on. The limits high and low are defined by the user. Figure 8. Gas Pipeline Testbed

7. Results and Discussion PLC num status PLC 0 malfunction PLC 1 good PLC 2 good PLC 3 good PLC 4 redundant input 0 11 11 31 input 1 13 13 33 input 2 15 15 35 input 3 29 29 37 output 1 12 18 32 38 8 output 2 16 22 36 40 10 Table 1. Virtual PLC Layout According to quorum system tolerant of Byzantine failures, we need a minimum of 2 n+1 Open. PLC for identifying the faulty or suspiciously behaving out of n good Open. PLC instances. We evaluate two metrics: (1) abnormal detection system in terms of false positive rate; (2) record and replay mitigation system in terms of sensitivity and latency. Our experiment setup is comprised of two classes of servers. For traffic generation (via Open. PLC) and experiments requiring a single NIC port, we use Raspberry Pi 3 Model B with a 1. 2 GHz 64 -bit quad-core ARMv 7, with a Broadcom BCM 2835. We also use a Mac. Book Pro machine with an Intel Core i 5 @ 2. 00 GHz (2 cores), 8 GB memory, and Air. Port Extreme (0 x 14 E 4, 0 x 159) wireless NIC card with firmware version Broadcom BCM 43 xx 1. 0 (7. 21. 171. 130. 1 a 1). RPI servers run Raspbian GNU/Linux 9. 1 (kernel 4. 9. 41) and the Mac Server runs Mac. OS Sierra (kernel 10. 12. 6). In this evaluation, for the efficient use of Raspberry Pi, we split and map 5 virtual PLCs on one board using the following scheme as is shown in Table I.

7. Results and Discussion (Continued) Figure. 9. ROC result comparison of various ST settings across various attack rates. Figure. 10. Summary of mitigation and detection techniques against attacks scenarios.

8. Summary Armor. PLC: Ladder Logic Validation • a stateless network based Deep Packet Inspection (DPI) system, for threat assessment. This system could detect zero-day attacks. • an overlay network with record & replay mechanism for PLCs. • it captures pin values with a sensitivity of 50 microseconds. The false positive rate is 1% along with a latency of 25 milliseconds in our abnormal detection. Source code : https: //github. com/wenhuizhang/Armor. PLC

References [1] A. Gilchrist, Industry 4. 0: the industrial internet of things. Apress, 2016. [2] I. Ungurean, N. -C. Gaitan, and V. G. Gaitan, “An iot architecture for things from industrial environment, ” in 2014 10 th International Conference on Communications (COMM), pp. 1– 4, IEEE, 2014. [3] A. -R. Sadeghi, C. Wachsmann, and M. Waidner, “Security and privacy challenges in industrial internet of things, ” in 2015 52 nd ACM/EDAC/IEEE Design Automation Conference (DAC), pp. 1– 6, IEEE, 2015. [4] N. Jain and R. Miao, “Detecting attacks on data centers, ” Feb. 4 2016. US Patent App. 14/450, 954. [5] T. H. Morris, R. B. Vaughn, and Y. S. Dandass, “A testbed for scada control system cybersecurity research and pedagogy. , ” in CSIIRW, p. 27, 2011. [6] S. A. Boyer, SCADA: supervisory control and data acquisition. International Society of Automation, 2009. [7] T. D. Culbertson and T. W. Simpson, “Using shape grammars to identify salient features in support of product family design, ” in ASME 2014 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, pp. V 007 T 07 A 036, American Society of Mechanical Engineers, 2014. [8] S. Kim and A. K. Somani, “On-line integrity monitoring of microprocessor control logic, ” in Proceedings 2001 IEEE International Conference on Computer Design: VLSI in Computers and Processors. ICCD 2001, pp. 314– 319, IEEE, 2001. [9] X. Delord and G. Saucier, “Formalizing signature analysis for control flow checking of pipelined risc microprocessors, ” in 1991, Proceedings of International Test Conference, p. 936, IEEE, 1991. [10] A. Meixner and D. J. Sorin, “Error detection using dynamic dataflow verification, ” in Proceedings of the 16 th International Conference on Parallel Architecture and Compilation Techniques, pp. 104– 118, IEEE Computer Society, 2007. [11] T. M. Austin, “Diva: A dynamic approach to microprocessor verification, ” Journal of Instruction-Level Parallelism , vol. 2, no. 5, pp. 1– 6, 2000. [12] A. Mahmood and E. J. Mc. Cluskey, “Concurrent error detection using watchdog processors-a survey. ” IEEE Transactions on Computers, vol. 37, no. 2, pp. 160– 174, 1988. [13] T. R. Alves, M. Buratto, F. M. de Souza, and T. V. Rodrigues, “Openplc: An open source alternative to automation, ” in IEEE Global Humanitarian Technology Conference (GHTC 2014), pp. 585– 589, IEEE, 2014.

Thanks！