An Overview of the Security of Programmable Logic Controllers in Industrial Control Systems

Abstract

One key role in industrial control systems (ICSs) is known as Programmable Logic Controller (PLC). However, with the development of the Internet of Things (IoT), PLCs have become exposed to an increasing number of attacks, which may cause malfunctions of the whole ICS. Thus, it is necessary to identify potential attacks on PLCs and propose effective solutions to mitigate them. Unfortunately, to date, there have not been significant efforts made to provide a detailed overview of existing works on PLC security. With such a concern in mind, in this paper, we focus on summarising PLC security from different components running at different layers of a PLC architecture. We first review the framework of PLCs; then, we discuss several models when considering PLC security. After that, we provide an overview of existing attacks on PLCs and general solutions to those issues from different perspectives. Lastly, we conclude this paper with an overview of future research areas in PLC security.

1. Introduction

In recent decades, Industrial Control Systems (ICSs) have been widely deployed to control and monitor operations of critical infrastructures, including transportation, power grids, and water treatment units [1,2]. In recent decades, due to the trend of connecting ICSs to the Internet, the security of ICSs has received significant attention. It has been estimated that the global ICS market will grow to $23.5 billion by 2026 [3]. While ICSs are transformed by smart Internet of Things (IoT) devices with increasing usability, efficiency, and productivity, Internet of Things (IoT) devices also significantly impact ICS security [4,5].

Programmable Logic Controllers (PLCs), along with sensors and actuators, are key components of ICSs, as ICSs are monitored and operated via PLCs. Traditionally, it is believed that PLCs are isolated from outside network connections, and thus, PLCs should not be infected by computer viruses. However, several incidents indicate that PLCs are at a significant risk despite them being separated from the core network. For example, a former employee hacked the Queensland computerized waste management system in 2000, which caused a large amount of sewage to be dumped into different areas of the city [6]. A malfunction caused by worms inside computers was detected in monitoring systems in the Ohio Davis-Besse nuclear plant in 2003 [7]. Nevertheless, these earlier incidents did not raise the scientific community’s interest. It was not until recent years that security concerns in PLC-based automated systems started to attract public attention. In 2010, the Stuxnet virus was discovered in Iran’s nuclear facilities [8]. After that, PLC producers and users began to identify vulnerabilities and explore countermeasures to these threats. In the past decade, there has been a large number of papers either focusing on potential attacks that can be launched against PLC-related systems or different prevention mechanisms to mitigate various security issues in PLC-based systems. However, there has been little effort devoted to providing a complete overview covering all aspects of PLC security. In this paper, our focus is on providing an overview of existing security issues in PLCs and relevant techniques that can be applied to mitigate or prevent those potential attacks.

1.1. Related Works

There have been several papers focused on presenting a summary of PLC vulnerabilities and countermeasures. Basnight et al. [9] discussed the vulnerability of PLCs in terms of intentional firmware modifications to understand the feasibility of firmware modification attacks caused by threats in PLC firmware. Sandaruwan, Ranaweera, and Oleshchuk [10] presented several PLC vulnerabilities via various types of attack vectors affecting the critical infrastructure. Wardak, Zhioua, and Almulhem [11] conducted an investigation into PLC access control problems, especially with regard to the password-based access control. Ghaleb, Zhioua, and Almulhem [12] provided a security analysis over network communications between stations responsible for setup and configuration and PLCs. Serhane et al. [13] provided suggestions on policies, recommendations, and countermeasures to secure PLC-based systems. Wu et al. [14] summarized PLC security from perspectives including firmware security, operation security, and program security. Pan, Wang, and Sun [15] reviewed PLC security in terms of code security, firmware security, network attack, and MODBUS protocol security, as well as certain protection mechanisms.

Contributions in this paper are different from other existing review papers about PLCs in several aspects. Firstly, the majority of previous survey papers focus only on one issue in PLC-based systems rather than providing a complete picture of all problem types. Secondly, some survey papers which provide an overview of PLC security from different aspects fail to cover relevant papers discussing those specific issues. Thirdly, existing survey papers do not include threat models of PLC security. Considering the incompleteness of existing overviews of PLC security, in this paper, our focus is on summarizing the security of PLCs from a wider perspective to cover all aspects related to PLCs.

1.2. Organization

This paper’s remaining sections are organized as follows. In Section 2, we briefly describe an overview of PLC architecture. In Section 3, we discuss different threat models of PLC security. In Section 4, we summarize different types of attacks on PLCs. In Section 5, we present several techniques to mitigate PLC threats. In Section 6, we predict future research areas in PLC security. Lastly, this paper is concluded in Section 7.

2. Background

PLCs are extensively used as field devices in ICSs. A PLC provides a user-programmable interface between physical inputs and outputs to support customized control of ICS components. In this section, we present an overview of the components of PLCs.

2.1. PLC Architecture

An ICS is composed of a plant that describes the physical process under control, a group of sensors that read the plant’s states (e.g., pressure, temperature), convert the states into electrical signals and deliver these signals to the controller; one or more PLCs monitoring and controlling the plant’s states, which read sensor signals, execute control methodologies, and send actuators the corresponding signals; and a set of actuators receiving signals from PLCs and change the plant’s states. ICSs are managed in a centralized control manner, and thus, PLCs are connected to a human–machine interface (HMI) which is a central control terminal operated by a human operator to manage the system (together with Supervisory Control and Data Acquisition (SCADA) [16]) as in Figure 1. The operator is able to remotely supervise the PLCs as well as applications running on PLCs. Every application’s information can be loaded from a PLC, including the source code and the metadata information.

PLCs are increasingly connected to the Internet. As a result, PLCs are expected to support various network protocols. A variety of protocols are used by PLCs to communicate with other devices in ICSs, including Ethernet/IP [17], MODBUS [18], Distributed Network Protocol (DNP3) [19], Message Queuing Telemetry Transport (MQTT) [20], Open Platform Communications Unified Architecture (OPCUA) [21], and so on. Unfortunately, these protocols were not designed with security properties because security was not a concern when these protocols were first introduced to ICSs.

Following the work in [22], PLCs can be described as having three operational layers: the programming layer, the firmware layer, and the hardware layer.

2.2. Hardware Layer

The hardware layer in PLCs comprised electronic elements and microchips. Its key components include non-volatile storage, volatile memory, and microprocessors. The hardware layer is subject to attacks ranging from the physical control of the hardware, hardware design flaws bringing the software exploitation to the compromise of the supply chain. For the physical manipulation, it requires the attacker to have access to the device, and thus it is a least likely attack and probably involves a malicious insider. Software exploitation of hardware flaws relates to exploits to the layer of the firmware or the programming. A supply chain compromise indicates that the attacker is able to compromise the manufacturing process itself to create vulnerabilities or any backdoor. It is challenging to detect such a supply chain compromise, and it is necessary to maintain strict quality and security manipulation during all stages of the supply chain [9].

2.3. Programming Layer

The interaction between a PLC and operators is enabled by the programming layer. The programming layer provides the logic (which are used to execute control operations) to the device. There are a variety of languages supported by PLCs, which encompasses traditional languages, such as C, and popular languages, such as Ladder Logic, Structured Text, and Function Block Diagrams [23]. Ladder Logic (LL) is a graphical sequential programming language that provides an intuitive interface to controllers for those who may not be familiar with traditional programming languages. In addition to LL, Function Block Diagram (FBD) is another graphical programming language. FBD provides an intuitive way to program with blocks. Simple routines expressed as state machines are generally programmed using Structured Text (ST).

Programming languages in PLCs enable programmers to define access rights to each controller’s variable. “External” entities can be assigned privileges to remotely access variables, namely, Read/Write, Read Only, or None. Each variable is assigned Read/Write privilege by default [24]. The PLC may receive a Read or Write request with a variable from an external device. In this case, the PLC will look up the external request’s variable to determine whether the Read or Write privilege should be granted. If so, the PLC will then return the value in a Read message or update the variable’s value.

2.4. Firmware Layer

The programming layer and the hardware layer are connected together by the firmware layer and is referred to as the operating system, which encompasses lower-level functionalities, e.g., boot-loader code to initialize and load the operating system. It handles the basic behaviors of a device. The firmware controls the interactions (including physical inputs and outputs) between the operator and the device hardware. An attacker may attempt to gain access to the firmware on a PLC, thereby obtaining potentially unlimited control of the device. If the attacker is successful, the attacker has the capability to stealthily modify the device’s behavior. The requirements of programming languages and system operations that needed to be complied by PLC products are defined in the IEC 61131-3 standard [23], which is followed by PLC vendors to program and compile the source code of control logic.

Traditionally, since it is the factory that installs the firmware and operators cannot reprogram devices, the PLC firmware is relatively secure against modification attacks. However, the firmware updating feature of PLCs to patch bugs and upgrade the firmware can be used by attackers to upload malicious firmware to the device. Checksum algorithms are commonly used to validate firmware updates before any installation and execution. A robust checksum algorithm plays an important role in preventing attackers from uploading malicious updates.

2.5. Scan Cycle and Control Logic

PLCs operate cyclically by repeating the same process, which is known as a scan cycle. Each scan cycle repeatedly execute the control logic program. In each scan cycle, network messages are uploaded from the network to local buffers and vice versa. In addition, the PLC reads information from sensors and locally stores their values, updates output signals from local values (to actuators), operates the control logic, and performs safety checks.

The control logic can be divided into several blocks: configuration blocks, data blocks, code blocks, and information blocks [25]. The configuration block covers other blocks’ data such as a block’s size and address, the PLC’s IP address, and others. The data block contains variables (including inputs, outputs, timers, counters, etc., used in the code block) in the PLC. The Code block describes the compiled control logic code run by a PLC. When the control logic is retrieved from a PLC, information blocks will be used to recover it from the de-compiled source code.

2.6. PLC Vendors

Most large brands in industrial automation produce their own PLCs. These giant PLC manufacturers include Schneider Electric (Rueil-Malmaison, France), Mitsubishi Electric (Tokyo, Japan), Hitachi (Tokyo Japan), Siemens (Munich, Germany), Fuji Electric (Tokyo, Japan), and Panasonic (Osaka, Japan). There are also other PLC brand names such as Rockwell Automation (Milwaukee, WI, USA), Omron (Kyoto, Japan), Keyence (Osaka, Japan), Unitronics (Tel Aviv, Israel), Fatek (Taipei, Taiwan), Idec (Osaka, Japan), and Yokagawa (Tokyo, Japan) that have retained their focus on the production of PLCs and other industrial automation equipment.

2.7. Simulation Tools

Considering that vendors do not make the hardware and firmware information of their PLC products available, it is very difficult to conduct the research on PLCs’ security. To address such an issue, there have been efforts to produce open-source PLC technologies. The first open-source PLC was put forth by Souza [26] called MatPLC. This initial effort has several limitations. Firstly, it does not provide an interface with a programming integrated development environment (IDE). Secondly, it lacks a hardware platform to run the built-in physical Input/Output. Thirdly, it does not support the ladder logic. Tisserant, Bessard, and Sousa [27] developed an IDE for the IEC 61131–3 standards called PLCOpen Editor. Alves and Morris [28] developed an open-source PLC as OpenPLC by integrating the PLCOpen Editor with a compiler to build a comprehensive PLC package. The OpenPLC has an open source HMI editor, supports popular ICS protocols such as MODBUS [18] and DNP3 [19] and the open-source hardware.

There are several PLC simulation tools available. These can be divided into PLC System Simulators, PLC Core Simulators, and PLC Network Simulators [28]. PLC System Simulators (e.g., S7-PLCSIM [29], and RSLogix Emulate [30]) can simulate an entire PLC system, ranging from internal behaviors, the programming to network communications. PLC manufacturers usually provide PLC System Simulators. PLC Core Simulators (e.g., Common Open Research Emulator (CORE) [31], and AMICI [32]) normally simulate the PLC control logic program and the network behavior via the scripting language. PLC Network Simulators such as the Modbus Slave [33] focus on simulating the application layer of ICS network protocols. Thus, they are able to respond to network queries in the same way as regular PLCs, but they do not have any control over the built-in logic.

3. Adversarial Model

Depending on the goals of attackers, different assumptions have been made in the development of the threat model of PLCs.

3.1. Stealthiness

Some threat models assume that attackers target remaining stealthy from ICS operators such that the view of the HMI in the system does not indicate any effect caused by attacks. If an attack does not incur unintentionally observable effects, then it is a stealthy attack. For example, sensor readings should remain consistent with their expected values. To achieve such a goal, the attacker can compromise the HMI itself or launch attacks on the PLCs. Considering that the HMI is usually equipped with various security-enhancing techniques, the PLC becomes a more attractive target to attackers [34].

3.2. Control Logic

Some efforts focus on the symbolic execution for PLCs by assuming that attackers are able to update the control logic of the PLC [35]. Nevertheless, the modification of the PLC program is a challenging task in the real world. Usually, PLCs are armed with hardware-based mechanisms to protect them, which switch the PLC’s status between “run” and “program” modes. The key of the PLC becomes unavailable when the PLC is in the “run” mode, and the PLC rejects any software modification. Therefore, unless the attacker is physically located in the plant and has access to the key, the attacker is unable to reprogram the PLC to change the PLC operation [36].

It is practical to assume that a remote attacker can break into the PLC network and forward the concrete information to the PLC, thereby changing the PLC’s execution logic without physically modifying the PLC software.

3.3. Firmware

In terms of firmware attacks in PLCs, it is assumed that attackers have the access to the controller’s program and can analyze the program [37]. Under this assumption, an attacker should be able to read any network message. Thus, attackers may attempt to read the internal variables from the Write variables (via network messages). However, if PLCs are equipped with hardware-based protections and there exist attestation methodologies [35], the attacker can neither update programs running in the PLC device nor modify PLC signals to actuators [36]. In this case, the attacker’s aim changes to utilize attack strategies to “force” a system’s state to a critical state via an indirect operation of actuator states. For instance, the attacker may attempt to modify the controller’s output variables (i.e., the signals sent to the actuators), and then change the physical state of the plant.

4. Different Types of Attacks

In this section, we first summarize existing control logic attacks on PLCs into control logic injection attacks and firmware modification attacks; then, we present an overview of network attacks on communication protocols running between PLCs (please note that we do not consider attacks such as behavioral anomalies on PLC-based systems (e.g., [38,39])).

4.1. Code Vulnerabilities

There might be “code errors”, also known as code mistakes or flaws, in the logic implemented within the PLC program. These errors can lead to unintended behavior or malfunctioning of the control system. Following the summary in [40], several code-related vulnerabilities are summarized in

Table 1. Code issues in PLCs.

Types	Descriptions
Logic	Errors that could cause state transition, timing, control,
Errors	and data flow issues.
Linkage	Errors that handle the failure to or the deletion of the
and Scope	installation of a communication session between
Errors	separate ladders.
Syntax	Errors that were problematic in the compilation (not restricted).
Errors	Such codes can be downloaded to the processor with at most
	one warning comparing to the individual downloading to the device.
Duplicate	Objects such as timers and counters that have been defined
Objects	more than once.
Unused	Objects that were never used in the ladder logic but defined
Objects	in the initial database which can be used for random functions.
Hidden	Software jumpers that avoid some parts of a rung
jumpers	in a ladder logic routine. They are not searchable and can be
	easily hidden from the untrained eye.

. Code errors can be mitigated via debugging techniques.

4.2. Control Logic Injection Attacks

Control logic injection attacks involve injecting malicious control logic into the PLC program to control the behavior of the industrial process or system being controlled. Such a type of attacks can modify the original control logic running on the PLC. Stunex [8] is one type of control logic injection attacks; it downloads the malicious control logic to the targeted PLC (i.e., Siemens S7-300) via the compromised engineering software. Langner [41] described how to inject rogue logic code into PLCs in 2011. McLaughlin presented [42] a malware that can automatically generate malicious payloads against a process control system and then designed SABOT [43] to automatically match control specifications in a PLC to adversarial instructions of the targeted control system’s behavior, which enables an attacker to recover sufficient information of the PLC’s internal structure, and thus, the attacker can compile and upload malicious payloads to the PLC to compromise the system. After a network scan, PLC-Blaster worm [44] can inject a malicious control logic to vulnerable PLCs (typically Siemens S7-1200), thereby causing the crash of the HMI software once the operator attempts to retrieve information from an infected PLC. Ghost in the PLC [45] demonstrated a PLC rootkit which breaks of the availability and integrity of an embedded system by exploiting certain Input/Output pin control operations to. Given that the PLC control logic could be interfered with normal engineering operations by the attacker, Senthivel et al. [46] launched the denial of engineering operation (DEO) attacks against PLCs such that the software cannot work but the PLC continues execution. Yoo and Ahmed [25] achieved stealthiness in manipulating the control logic packet without making changes to the PLC firmware, which yielding the obfuscation functionality via data execution and fragmentation and noise padding control logic injection attacks. In 2022, two vulnerabilities were discovered in Rockwell Automation’s PLCs that allow attackers to run malicious code on a PLC without triggering any obviously unusual behavior [47].

False data injection attacks [48] can be directly launched against PLCs allowing the attacker to learn partial information about the targeted subsystem and creating malicious results. However, if attackers do not take the operators’ control commands into consideration when launching false data injection attacks, the forged system state may fail to meet the operators’ expectations, and the attacks can be easily detected.

4.3. Firmware Modification Attacks

Firmware modification attacks involve unauthorized alterations to the firmware or software running on the PLC device itself, and they infect a PLC at the firmware level [25]. Beresford [49] explained how credentials can be extracted from remote memory dumps and how to power on and off PLCs via replay attacks against communication protocols running in Siemens S7 series PLCs. Meixell and Forner [50] released different methods to exploit PLCs by removing safety checks from the logic code. Basnight et al. [9] investigated the firmware update validation method and created a fake firmware sample to be uploaded and executed on a PLC that can cause an insecure checksum validation during the update process. Klick et al. [51] explored whether attackers can make use of exposed PLCs to extend their access to more PLCs. The rootkit HARVEY [34] is able to replace benign control commands with malicious commands to cause large-scale failures of the system. Bytes and Zhou [2] analyzed the software internals of WAGO PFC200 Series PLCs, and presented several potentially practical methods for the attack payload persistence executing on the firmware components. It has been notified in February 2022 that an unauthenticated and remote attacker has successfully launched denial-of-service (DoS) attacks to several Siemens PLCs [52]. In January 2023, a critical memory security detour vulnerability was identified within Siemens PLCs (SIMATIC S7-1200 and S7-1500) [53] that could disable access protection and give an attacker the ability to remotely execute malicious (or read and write) code everywhere on such PLC.

4.4. Attacks against Communication Protocols

Gao et al. [54] identified a series of data and command injection attacks and denial of service attacks in communication protocols applied by the PLC network that are caused by the lack of authentication. Fovino et al. [55] found several vulnerabilities in the MODBUS protocol due to its lack of security-enhancing techniques. Morris and Gao [56] described several attacks on MODBUS, including replay attacks, response and command injections, and denial of service attacks. Rahman et al. [57] launched denial of service attacks against MODBUS/TCP (which is a modified protocol of MODBUS applied over TCP/IP networks). Polge, Robert, and Traon [58] highlighted the impact of message flooding and eavesdropping attacks on an OPCUA application. Mathur and Tippenhauer [59] were successful in running a Man-In-The-Middle (MITM) attack between two PLCs capturing the data information and commands and re-writing them in addition to manipulating remote firmware and logic updates to each PLC. Wardak, Zhioua, and Almulhem [11] showed how password-based mechanisms can be compromised in a realistic scenario in recent versions of PLCs (since 2016). Cheng, Li, and Ma [60] demonstrated the vulnerabilities in the S7CommPlus protocols adopted by Siemens PLCs via the reverse debugging technique. Ghaleb, Zhioua, and Almulhem [12] launched three network attacks that could interfere with PLC communications and send arbitrary commands to the PLC. Ylmaz et al. [61] studied denial of service (DoS) attacks on the PLC and found that the delayed network traffic could lead to a slowdown in PLC operations and disable control over the PLC control software. Robles-Durazno et al. [62] targeted network attacks against the PLC memory to interfere with system operations. Sandaruwan, Ranaweera, and Oleshchuk [10] analyzed several attacks, including brute-force attacks, replay attacks, MITM attacks, and authentication bypass attacks, which can be launched to affect the operations of PLCs.

4.5. Memory Attacks

While the majority of works focus on network traffic as a detection feature set [25], Cook, Marnerides, and Pezaros [63] were the first to propose a vendor-independent fingerprinting approach to detect memory attacks, which is a fingerprinting framework for PLC attack detection and classification. Based on the correlation between the dynamic and static behaviors in PLC registers (PLC registers are individual variables about concrete register areas (e.g., inputs, outputs, etc.)), they achieved the real-time composition of memory fingerprints in the PLC.

5. Countermeasures

In this section, we cover the existing efforts that mitigate threats and risks in the PLC network.

5.1. Firmware Integrity

Adelstein, Stillerman, and Kozen [64] introduced a detection method based on signature testing the integrity and execution flow using the detector when it was running. Symbolic execution (SE) [65] has been explored to identify whether there are attacks contained in PLC code. Canet et al. [66] proposed a framework for the automatic verification of PLC programs for conditional branches without implementing numerical instructions; however, this approach can cause state space explosion. McMinn and Butts [22] presented a verification tool for PLC firmware that can capture data during both the upload and download phases of the firmware without any modifications to the ICS system. Garcia [67] proposed an analysis method to perform static differential analysis of suspected changed PLC firmware via a variety of testing techniques comparing firmware models, firmware versions, and code differences. McLaughlin et al. [35] addressed attacks in which the malicious codes can be uploaded to the PLC through Trusted Safety Verifier (TSV) that combines SE and the model checking to verify whether the safety properties are satisfied by PLC programs.

5.2. Secure PLC Programs

The analysis on PLC binaries and source codes focuses on disassembly, i.e., de-compilation, to find vulnerabilities and ensure the security of payload design, core codes, and general-purpose reconnaissance of controllers [68]. The PNF Software (refer to https://github.com/pnfsoftware) posted the closed-source JEB decompiler to run reverse engineering analyses on PLCs but only for Siemens S7 PLCs [69]. Keliris and Maniatakos [70] designed an open-source framework to enable binary analysis of general-purpose PLCs based on automated reverse engineering. Guo, Wu, and Wang [71] put forward SymPLC to automatically test whether PLC software written in programming languages are free of programming errors; however, this approach did not consider the timing parameter as a key component.

5.3. Defence Detection

Yao and Chow [72] introduced a methodology for defining detection rules to detect logic-changing attacks for PLC control logic that utilizes the control program logic change detector to detect the intentionally changed control logic. Abbasi et al. [73] effectively detected control flow hijacking attacks via a control flow integrity check tool, thereby guaranteeing the real-time availability of PLCs. Zonouz, Rrushi, and McLaughlin [74] put forward a way of detecting malicious code utilizing PLC code symbols. Feng et al. [75] evaluated the security of PLCs through applying the fuzzy analytic hierarchy process, as well as the attack tree model.

5.4. Network Protocol Security

Communication protocols used by the PLC network are not designed with encryption, authentication, and authorization functions and, thus, cannot provide confidentiality, authentication, or integrity, and they are vulnerable to all kinds of network attacks. Majdalawieh, Parisi-Presicce, and Wijesekera [76] proposed a security framework for DNP3 by adding integrity, confidentiality, and authenticity to the original DNP3 where the encryption is applied to prevent eavesdropping attacks. Fovino et al. [55] enhanced the security of the MODBUS protocol by incorporating mechanisms to achieve integrity, authentication, non-repudiation, and anti-replay attacks. Sandaruwan, Ranaweera, and Oleshchuk [10] suggested several security measures to protect PLCs including authentication, timestamps, and intrusion detection systems. Voyiatzis, Katsigiannis, and Koubias [77] analyzed vulnerabilities in the MODBUS network protocol using the MODBUS/TCP Fuzzer to address the vulnerabilities in the MODBUS/TCP environment. Modbus.org published the MODBUS security protocol in 2018 to provide strong protection which is a combination of the Transport Layer Security (TLS) protocol and the traditional MODBUS protocol [78]. Malchow et al. [79] implemented a prototype called PLC Guard as a security solution for mitigating false network packets generated by communications between the PLC and other ICS components. Cheng, Li, and Ma [60] recommended solutions at the code level, design level, and protocol level to prevent replay attacks from the encryption algorithm applied by Siemens PLCs. Akpinar and Özçelik [80] modeled behaviors of field devices connected to the PLC and converted the model into ladder diagrams to mitigate PLC attacks. Zhang et al. [81] implemented a deep packet inspection (DPI) system to protect PLCs against from malicious network packet payloads.

5.5. Encryption

Heo et al. [82] demonstrated that the PLC communication network could be encrypted to achieve the data authenticity. Halas [83] revealed the need to identify encryption algorithms that are suitable for PLC devices. Zonouz, Rrushi, and McLaughlin [74] suggested the application of encyrption algorithms in PLC networks to reduce the possibility of reverse analysis on communication protocols.

To support the encryption running on PLCs, Alves, Morris, and Yoo [84] extended the open-source PLC OpenPLC [28] by adding AES-256 encryption and decryption capabilities. Later, Alves, Das, and Morris [85] modified the OpenPLC platform [28] to encrypt all data sent over the network [28].

6. Future Works

Security protection for PLCs should be considered for all ICSs. Existing research efforts on PLC security, which focus only on certain aspects of PLCs, cannot completely prevent vulnerabilities in PLCs. Key research directions for PLC security in the future can be summarized as follows.

6.1. Attacks

With the advancement of hacking skills, all components in ICSs need to be taken into consideration to evaluate the security of the PLCs. A simple study of one aspect–the PLC itself–cannot address all existing issues. Though some research papers may only address attacks on the PLC itself, many security incidents in ICSs target several vulnerabilities in different sectors of the ICS rather than PLC-only attacks. Therefore, it is necessary to conduct a systematic analysis of PLC attacks in combination with other components in ICSs. For example, future research can focus on attacking PLCs from the HMI or via the operation workstations in a stealthy way and corresponding solutions to prevent those attacks. In addition, there has been little attention paid to the security of PLC products such as PLCnext [86]. It would be of interest to conduct a comprehensive security assessment of the PLCnext (or other small PLC brands) ecosystem, including the PLC hardware, firmware, software development environment, and communication protocols, to identify potential vulnerabilities and weaknesses.

6.2. Defense

In terms of defense, future research can emphasize the development of a protection framework for the comprehensive PLC network to prevent PLCs from being compromised with consideration to both the costs and functionalities. In addition, innovations can be conducted in the following areas.

• There are no common frameworks to conduct the formal validation of PLC code, and thus, a unified and effective approach for PLC code auditing is yet to be proposed.
• Considering that PLC programs are different from traditional computer programs, contributions to accurate detection and overhead mitigation are still expected.
• Encryption has been considered as an approach to enchance the security of communication protocols for PLC-based systems; however, applying encryption algorithms to the whole large-scale ICS network without affecting the normal operation of the service network is still a challenge.

7. Conclusions

In recent decades, several attacks have been successfully launched against PLC-based ICSs, which has caused significant damage to critical infrastructure. Since 2010, the security of PLCs has been seen as an increasing concern. Previous papers on PLC security either focus on attacks against PLCs or mitigation techniques to PLC vulnerabilities, but there have not been desirable efforts made to provide a comprehensive summary of PLC security. In this paper, we aim to bridge this gap by presenting an overview of PLC security based on the architectures and threat models of PLCs. We explored the fundamental components and communication protocols commonly used in PLC-based ICSs, highlighting the potential attack routes and vulnerabilities inherent in these systems. Finally, we concluded several future research areas in terms of PLC attacks and PLC defensive solutions.