Security of Programmable Logic Controllers and Related Systems: Today and Tomorrow

Programmable logic controllers (PLCs) are indispensable in critical infrastructures and industrial control systems. The increasing demand for enhanced cost-effectiveness and production efficiency has driven automation manufacturers to integrate PLC-based applications and systems with external networks, such as Internet. Unfortunately, this connectivity has exposed systems to potential malicious attacks from motivated adversaries. Addressing this pressing issue necessitates a comprehensive summary of ongoing research related to PLCs and their related systems. This summary should classify these systems based on disclosed vulnerabilities, potential threats, and proposed security solutions, catering to both scientists and industrial engineers. While several recent surveys have reviewed and discussed PLC security and related topics, they often fell short of covering all essential aspects comprehensively. Furthermore, prior surveys tended to focus on analyzing vulnerabilities at the system level, overlooking the vulnerabilities specific to PLCs themselves. Consequently, their findings failed to effectively secure current operational systems or propose improved solutions for future PLC designs. In this article, we bridge this research gap by providing a detailed review of all aspects concerning the security of PLCs and related systems. This includes vulnerabilities, potential attacks, and security solutions including digital forensics. We aim to offer a precise analysis, addressing the shortcomings of previous studies. Finally, we conclude this article by presenting our recommendations tailored for PLC manufacturers, researchers, and engineers. We hope that these recommendations will contribute to the development of more secure PLCs in the future.


I. INTRODUCTION
Industrial control systems (ICSs) face a wide range of threats that target the physical processes controlled by programmable logic controllers (PLCs), as shown in many incidents like Stuxnet [1], Havex [3], TRITON [4], Black Energy [5], German Steel Mill [6], and others.PLCs serve as the last defense line of any ICS system.Consequently, if a PLC is compromised, it also compromises the entire physical process it controls, potentially leading to catastrophic incidents [38].Each year, security experts identify and report vulnerabilities concerning PLCs and their related systems to the Common Vulnerabilities and Exposures (CVE 1 ) database. 1 [Online].Available: https://cve.mitre.org/These vulnerabilities undergo meticulous evaluation before specialists release advisories to inform the public about the potential threats.The responsibility of publishing these advisories lies with the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT2 ).To analyze the data effectively, we utilized the ICS-CERT website's research engine to specifically filter advisories related to PLCs.Subsequently, we extracted and compiled the number of PLCrelated advisories reported annually, enabling us to generate a statistical report spanning from 2010 (the year of the first reported PLC-based system attack) to the end of 2022, as shown in Fig. 1.The data presented in our report indicate a significant and continuous increase in the interest surrounding the security of PLCs and their systems.Furthermore, the report shows clearly that the more identification of vulnerabilities, the more malicious attacks occur.Note that ICS-CERT advisories are only published when potential harm from attackers is detected, and most advisories contain multiple related vulnerabilities.As can be seen in Fig. 1, in 2022, there were almost 376 reported advisories, which is over 50 more than the previous year's 328 advisories and over 200 more than the number reported in 2012.
A deeper analysis to the reported vulnerabilities reveals that many of the weaknesses/entry points the attacker exploited were not novel, e.g., stack-based overflows, improper input validation, improper access control, etc.In addition, PLCs themselves often have, by default, vulnerabilities in program verification, firmware, and memory.We noticed that when adversaries gain access to a system's network, or the devices connected over the comprised network, they can exploit their vulnerabilities to conduct severe attacks such as command injection, control logic injection, firmware modification, memory corruption, replay attacks, and many others.The reported advisories showed also a notable increase in the sophistication of attack scenarios conducted, which have become more stealthy and complex.Consequently, there is an urgent need to develop a comprehensive defense mechanism against different cyberattacks.This holds true not only at the system level, like most of the other research works focused, but also directly at the PLC level.However, security measures like code verifying, firmware investigating, traffic monitoring, suspicious state checking, and more should be reconsidered as they could not yet entirely prevent the attacks.Note that applying any security solution to an ICS must meet the system's requirements it tries to protect.For instance, PLC-based systems that operate physical processes requiring real-time responses, processing continuously, interacting frequently, high availability, etc., should have security means that take those requirements into consideration .For all that, there are different challenges that engineers and research community encounter when it comes to implement security measures, which also need to be discussed and highlighted.
The digital forensic approach has recently introduced itself as a promising approach toward enhancing the security of PLCs and their related systems.Applying security schemes using digital forensic techniques can significantly increase the opportunities of disclosing exposed industrial devices, revealing ongoing attacks and detecting them at very early stage.Based on our study and findings, significant security recommendations were derived and suggested in hope to protect PLCs effectively in the future, ensuring the security of critical infrastructures (CIs) and ICSs.
In the following sections, we spotlight the differences between our survey and the previous ones.

1) INVESTIGATING THE SECURITY AT PLC LEVEL
The security of PLC-based systems has been primarily studied from two perspectives: the system level and the PLC level.After reviewing previous surveys, we found that most research papers focused on the overall system security, particularly the security of the supervisor control layer (see Fig. 4).The authors of most published surveys primarily concentrated on network security, with a specific emphasis on communication protocols [12], [18], [19].In contrast, only seven papers delved into the security of the automatic layer and investigated the security of the PLC itself [10], [15], [17], [20], [26], [32].However, these studies have not offered a comprehensive overview addressing all the aspects of the PLC security theme.In this article, we aim to shed light on critical security issues existing within the PLC itself, including areas like control logic, memory, firmware, input/output (I/O) pins, and more.

2) ADDRESSING ALL SECURITY ASPECTS
The surveys mentioned in Table 1 did not fully cover the prime four security aspects: vulnerabilities, attack scenarios, security solutions, and digital forensics.Furthermore, they did not include detailed discussions about the existing vulnerabilities in PLCs and their related protocols as well as systems.For instance, the attack classifications provided in previous studies like [26] and [32] were not fully elaborated upon, and some detection methods were only partially covered in one or a few papers, as done in [13], [16], and [22].

3) DEALING WITH ATTACKS AGAINST PRESENT PLC-BASED SYSTEMS
It is not secret that running industrial systems have vulnerabilities and exposed to different cyberattacks.These vulnerabilities can be attributed to either inadequate security considerations during the initial design of industrial components or improper configurations of application hardware and software.Previous works have not thoroughly addressed how existing systems can effectively deal with cyberattacks, particularly when it comes to analyzing security measures, which is one of the main issues we focus on in this article.

4) PROPOSING FUTURE PLC DESIGNS
Engineers face significant challenges when attempting to incorporate security measures into existing operational systems, particularly in the case of older PLCs that possess limited computational power, storage capacity, and bandwidth.As a result, it becomes imperative to introduce more sophisticated security strategies while designing future PLC devices to improve their overall security [29].However, existing surveys on this subject have largely overlooked this aspect and failed to provide a foundational concept of how these future PLCs might look like.In contrast, our study delves into the ongoing research on digital forensic theme.Furthermore, we analyze also the development of security solutions and approaches.Through this exploration, we aim to offer valuable insights and directions for the forthcoming generation of PLC  the latest vulnerabilities that the authors have identified and exploited to inflict damage on the target systems.To ensure precision, we excluded the works with fewer than 20 citations, unless they introduce novel attack methodologies or reveal new vulnerabilities.

3) STUDY DISCOVERS A NEW DIRECTION FOR FORTHCOMING RESEARCH
We take into consideration the papers that suggest new paths for further research or potential detection schemes or directions to be considered.

D. CONTRIBUTION
The primary contributions we introduce in this work are as follows.

1) COMPREHENSIVE REVIEW
In comparison to the already published surveys that are related to the security of PLCs, our work demonstrates a comprehensive review, encompassing four aspects: vulnerabilities, threats, security solutions, and digital forensic.Based on our findings, we suggests security recommendations that help in strengthening the overall security of our PLC-based systems.

2) DUAL INVESTIGATIONS ON PLCS
Our analysis to the weak/entry points takes a dual perspective, examining both the PLC itself and its entire system.When considering the PLC, we primarily address the program, memory, and firmware aspects.For the system as a whole, we concentrate on specific-vendor software and protocols, as well as other components connected to the controller.

3) SECURITY APPROACHES FOR DEPLOYED PLCS
In relation to currently running PLC systems, this article introduces various security approaches that are categorized based on the detection object, i.e., program, firmware, fingerprint, intrusion, and honeypot-based detection.

4) DIGITAL FORENSIC APPROACHES ARE INCLUDED
We delve into the methodologies, challenges, and implementations of digital forensic approaches, specifically those are dedicated to protect PLC-based systems.

5) CLASSIFYING SECURITY SOLUTIONS CHALLENGES
Besides that our article provides a deep analysis to vulnerabilities, attacks, and security solutions related to PLCs, it reviews the challenges that implementing each security approach encounters, classifying them based on the security solutions introduced in this work.

6) FUTURE SECURITY DIRECTIONS
Looking ahead to more secure future systems, we suggest our six security recommendations summarizing our findings in this article.
The rest of this article is organized as follows (see also Fig. 2).Section II introduces the basic background of PLCs and their related protocols and security requirements.An intensive vulnerabilities analysis is conducted in Section III, while the attack scenarios are discussed in Section IV.We review the existing security solutions in Section V and discuss the security solutions challenges in Section VI.Six future security directions are suggested in Section VII.Finally, Section VIII concludes this article.

II. BACKGROUND
In this section, we provide an overview of a typical PLC architecture, its operational environment, communication protocols, related systems, and the security demands specific to PLC-based systems.

A. PLC ARCHITECTURE
Fig. 3 depicts the typical architecture of a standard PLC.It is a digital device designed to control machines, industries, and plants through programmed instructions.In its simplest form, a PLC consists of various components.These include a power supply, input and output modules, an operating system (OS), and memory components like random access memory (RAM) and electrically erasable programmable read only memory (EEPROM).The PLC also features an interface for uploading and downloading user programs to and from the engineering workstation (EWS).The OS and the user-specific program are stored in the EEPROM.Input devices, such as sensors and switches, provide real-time data about the physical process to the PLC.The PLC processes this information through its control logic and drives the physical process accordingly using output devices like motors and valves.To program the PLC, control logic programs are used.These programs perform specific tasks based on the input readings and output conditions.There are five PLC programming languages defined in IEC-61131 [7]: ladder diagram (LD), structured text (ST), sequential function chart (SFC), instruction list (IL), and function block diagram (FBD) .The firmware in the PLC serves as the OS, facilitating the exchange of interactive data between the physical world and the device.

B. PLC RUNTIME OS
PLCs operate on a real-time OS, specifically designed to execute certain tasks through cyclic repetition of command sequences in extremely short intervals, typically in milliseconds.Each execution cycle, known as a scan cycle, consists of four main steps.In the first step, the central processing unit (CPU) reads data from connected sensors and stores the obtained values in a data table or an input image.Next, the logic execution updates the inputs of the running program with the newly acquired sensor values.Following that, the control logic is executed, and the output statuses are updated accordingly [32].The fourth step deals with communication tasks, facilitating data exchange with devices connected to the PLC.After completing the communication scan, the PLC enters a maintenance phase.During this phase, various internal tasks are performed e.g., updating internal clocks, managing memory, and other essential system maintenance activities.Although the user is not informed about this maintenance sequence, it regularly runs in the background as a crucial part of the PLC's functioning.

C. COMMUNICATION PROTOCOLS
A protocol refers to a collection of rules governing how devices in a network communicate with each other.In the context of PLCs, communication protocols are essential for establishing connections with remote I/O devices, remote control devices, and engineering software.PLC communication protocols are mostly proprietary, i.e., each manufacturer has his own protocols.However, these proprietary protocols have undergone scrutiny and reverse engineering by both academic researchers and industry experts.This is due to the fact that these protocols allow programming software to access the physical memory of PLCs [219].As a result, efforts have been made to understand and study these protocols in more detail.

D. PLC-BASED SYSTEMS
In the context of PLC systems, a prime example we can give is the SCADA system.In this regard, we present the architecture of a SCADA system, along with an overview of industrial communication protocols commonly utilized in current PLCs.Fig. 4 depicts a contemporary SCADA system, which is structured into the following three layers.
1) Supervisory control layer: It is responsible for overseeing and managing monitoring operations.Its primary function is to collect data from various sources.2) Automatic control layer: This layer aims at regulating physical processes.Thus, it operates with the help of control commands.It is where PLC devices are situated, handling the execution of control instructions.3) Physical layer: At the lowest level, this layer contains the physical devices that run the machinery.It is under the control and interacts with the upper layers.Fig. 4 clearly shows that PLCs control actuators/motors and sensors/switches.Simultaneously, other devices are connected with the PLCs, e.g., human-machine interface (HMI), EWS, historian, and control servers.The HMI communicates with the PLC using certain ports, allowing it to read/write data directly from/to the connected PLC.On the other hand, the EWS is responsible for reading and writing programs and configurations from/to the PLC.

E. SECURITY REQUIREMENTS FOR PLC-BASED SYSTEMS
In contrast to typical information technology (IT) system security, PLC-based systems and ICSs have distinct priorities, focusing on availability, integrity, and confidentiality.Addressing security concerns in PLC-based systems requires considering specific requirements, which are as follows [9]: 1) ensuring high availability for each layer within the system; 2) maintaining the integrity of industrial processes; 3) sustaining continuous operations over an extended operational life span; 4) managing complex interactions and cooperation between the layers and with the physical world; 5) providing hard real-time responses; 6) managing different and wide-distributed components; 7) supporting multiproprietary communication protocols; 8) utilizing significant numbers of legacy subsystems.

III. PLC-BASED SYSTEMS VULNERABILITIES
This section analyzes and discusses the vulnerabilities affecting both the PLC individually and its related systems.It is worth mentioning that the comprehensive list of vulnerabilities is extracted from the 235 papers that we reviewed.These vulnerabilities are classified into two levels, i.e., the PLC level and the system level, as illustrated in Fig. 5.
At the PLC level, vulnerabilities primarily exist in programs, firmware, and memory.On the other hand, at the system level, vulnerabilities are mostly found in industrial application software, communication protocols used in the industrial environment, and connected devices.Moving forward, we analyze the vulnerabilities in each level.

A. VULNERABILITIES IN PLC LEVEL
The widespread knowledge is that the original design of PLCs did not adequately consider security aspects [38], [99].Since PLCs are extensively used in various infrastructure sectors, replacing the existing legacy PLCs would be extremely challenging and almost unfeasible.As a result, these factors have given rise to numerous attacks specifically aimed at exploiting various vulnerabilities in the design of those legacy PLCs.

1) VULNERABILITIES IN PLC PROGRAMS
Control logic programs are typically written using one of the five programming languages mentioned earlier.However, these programs often contain critical flaws due to the way they are designed.Such vulnerabilities can compromise the integrity and availability of PLCs, either intentionally or accidentally.Programmers may unknowingly create backdoors for potential adversaries or inherit PLC programs with dormant threats due to a lack of professional knowledge and skills.Some common issues include the use of duplicated instructions, snooping, missing certain coils or outputs, and bypassing or denial of service (DoS) [40], [41].For instance, the ladder logic program itself is susceptible to malware insertion because it lacks proper authentication before being downloaded into PLCs.This makes it possible for malware, such as Ladder Logic Bombs demonstrated in [42] to be embedded in LD code with a dormant state that can be activated at any time, posing a significant threat.Serhane et al. [41] further explored vulnerabilities and bad code practices in LD programming that may lead to bugs and potential exploitation by attackers.Furthermore, Valentine [43] illustrated how adversaries can install a jump to a subroutine function and manipulate the intercommunication between different ladders in an LD code.All these factors contribute to the security risks associated with LD programming in PLCs.

2) VULNERABILITIES IN PLC FIRMWARE
PLCs rely on firmware, which acts as an embedded OS, such as Microware OS-9, VxWorks, and Microsoft Windows, to achieve their computing objectives.Despite their complexity, the current firmware used in PLCs suffers from security weaknesses and susceptibility to attacks, much like the original OSs.An example is the Backhoff CX5020 utilizing Windows CE 6.0 Plus, which possesses exploitable flaws [44].Surprisingly, many similar vulnerabilities were discovered in typical microprocessor-based devices.Consequently, attacking PLCs may not require exploiting specific vulnerabilities, but rather getting access to the controller and manipulating its regular operation.Such vulnerabilities could lead to firmware modification attacks and other disruptive actions that impact the normal functioning of PLCs.For instance, Basnight et al. [51] scrutinized Allen-Bradley ControlLogix PLCs, specifically the Control-Logix 161 PLC firmware, and uncovered weaknesses in the firmware update validation that facilitated firmware counterfeiting.Another research group [52] found security issues with source and data authentication in firmware uploads for both Koyo and Rockwell Automation PLCs.Schuett et al. [53] conducted research involving the extraction and analysis of firmware images to identify execution paths.The findings allowed the repackaging of firmware with a malicious attack, triggering a DoS attack by combining control commands.

3) VULNERABILITIES IN PLC MEMORY
PLCs are comprised of two types of memories: main and register memory.The first stores the control logics, while the latter serves as a temporary memory for processing the control logics, refreshed by the CPU in each scan cycle.Sandaruwan et al. [45] found out that critical variables influencing the main logic are stored in the register memory.Surprisingly, certain personal computers within the PLC network might have permission to access the register memory of a PLC, allowing adversaries to write malicious instructions, as if they were legitimate ICS operators.As a result, a potential attack scenario arises: if an attacker gains entry to a PLC and injects malicious values into the register memory, memory corruption attacks become feasible.Rais et al. [46] conducted forensic analysis on Allen-Bradley PLCs at the hardware level, and they found that stolen information caused the PLC to crash.Furthermore, the authors exposed memory dumps of the tested PLCs, which could potentially be exploited in firmware modification attacks.

B. VULNERABILITIES IN SYSTEM LEVEL
To effectively manage and oversee the physical processes of an ICS, seamless coordination among all components and layers is essential.For instance, the PLCs engage with the industrial application software through communication protocols, enabling data transfer and control commands among various ICS devices across different layers.However, from a security perspective, there are risks wherein attackers could commandeer a running PLC by exploiting potential vulnerabilities.These vulnerabilities include manipulating the communication protocols, compromising the integrity of the industrial application software, and infecting connected devices.In the following subsections, we elaborate on each type of those vulnerabilities in more detail.

1) VULNERABILITIES IN COMMUNICATION PROTOCOLS
Although the current network protocols effectively facilitate communication between PLCs and other industrial devices, they suffer from critical security shortcomings that leave them vulnerable to malicious manipulations.Our assessment has identified three prevalent vulnerabilities in industrial communication protocols, outlined as follows.
1) Absence of authentication: This allows malicious users to gain unauthorized privileges and manipulate protocol packets without any identification mechanism in place.2) Absence of authorization: Adversaries are capable of exploiting the order of executing PLC code to send packets to others, potentially leading to harmful consequences.3) Absence of encryption: This exposes transparent data, enabling malevolent users to capture and misuse it for their harmful endeavors.For instance, the S7 protocol has been found to lack authentication, leading to attacks on Siemens PLCs, as highlighted by Alsabbagh and Langendörfer [38], [39], [48], [49], [50].Moreover, these vulnerabilities can be exploited to execute replay attacks, man-in-the-middle (MitM) attacks, control logic injection attacks, and many others.

2) VULNERABILITIES IN APPLICATION SOFTWARE
Any PLC specific-vendor software is primarily comprised of three components: a software to program PLCs, a software to configure the network, and a software to manage SCADA systems.When these software are exploited, the devices that use them also become vulnerable.Attackers gain the ability to upload malicious code, alter PLC settings, and access critical data, among other actions.An illustrative case of industrial application software compromise is seen in the Stuxnet malware [1].Notably, the Stuxnet attackers targeted the Iranian nuclear plant and leveraged at least four zero-day vulnerabilities, making it a unique and sophisticated attack [1].Furthermore, Leverett and Wightman [47] demonstrated that CoDeSys, a third-party programming software, could modify PLC code.The software the author used ensured the integrity of executing the control process, which potentially opened the door for further malicious exploits, e.g., injection attacks.

3) VULNERABILITIES IN CONNECTED DEVICES
The proper functioning and dependability of PLC operations might be compromised by incorrect statuses and fraudulent I/O from connected devices, such as communication processors, I/O modules, and HMIs.Serhane et al. [41] highlighted that HMIs and historians have become more susceptible to security breaches due to the rise in remote access, particularly Internet-facing systems.Consequently, this increased vulnerability has attracted numerous adversaries seeking to exploit exposed connected devices that possess vulnerable initial access, thereby infecting networks.As a result, PLC programs are adversely affected by receiving false commands and deceptive I/O values from these compromised devices [78].

IV. ATTACK SCENARIOS
In this section, we delve into the attack scenarios used by adversaries once they exploit the vulnerabilities mentioned in Section III.Through our study to the prior research, we have identified 15 distinct types of attacks.To better organize these attacks, we have classified them into three categories based on the confidentiality integrity availability (CIA) security model's properties [155]: attacks against availability, integrity, and confidentiality.
In Table 2, we provide a summary of our analysis to the previous studies that discussed different attack scenarios aimed at PLC-based systems.

A. ATTACKS AGAINST AVAILABILITY
These attacks target the obstruction of authorized users' access to data or their ability to utilize specific resources when required.The group comprises five distinct attack scenarios, which are as follows: firmware modification, memory corruption, DoS, delayed, and HMI-exploited attack.In the following subsections, we overview each attack scenario, providing a more comprehensive review of their characteristics.This type of attack involves the adversaries downloading a re-signed firmware containing the malicious code and then injecting it into the PLC to create a hidden backdoor.The consequences of such attacks can be catastrophic, leading to significant failures and severe consequences.To exploit PLC firmware vulnerabilities, attackers typically employ reverse engineering techniques to infer the firmware update validation method.They analyze this method to find weaknesses that facilitate firmware modification and counterfeiting.By exploiting these weaknesses, attackers create a counterfeit firmware sample with malicious code, which they upload and execute on the target PLC.
Basnight et al. [51] noted that to modify a firmware, attackers need to apply reverse engineering techniques on the binary firmware to obtain certain functions through disassembly.Detecting and verifying a malicious firmware running on PLCs proved challenging, making PLC firmware modification a stealthy and hard-to-detect threat.Garcia et al. [54] developed a PLC rootkit, called Harvey, designed to exploit power grid systems.This rootkit infected the firmware of PLCs, allowing it to tamper with all the inputs and outputs of the PLCs in an arbitrary manner.Another research group [52] investigated the functionality of firmware upgrades and updates supported by PLCs.They demonstrated a firmware modification attack scenario against Koyo and Rockwell Automation PLCs, showing how malicious firmware could be uploaded into the Ethernet cards of these field devices.

2) MEMORY CORRUPTION ATTACK
PLC memory attacks involve unauthorized manipulation of critical memory data in PLCs, as shown in Fig. 7.
Our analysis to these attacks has revealed multiple vulnerabilities e.g., buffer overflows, incorrect mappings between memory addresses and protocol elements, etc.Thus, once attackers get access to a target network, they can maliciously manipulate different types of data stored in the compromised PLC memory, e.g., control, configuration, and decisionmaking data.Those manipulations can be done by overwriting specific memory locations relevant to I/O operations, thus tampering with set-point variables.In their research, Robles-Durazno et al. [55], [56] focused on attacking the PLC input memory.The authors devised an attack approach that pushes carefully crafted packets to the input memory.To this end, the authors assumed that the attackers already had control network access.Afterward, three PLC memory corruption attacks were proposed.All targeted different locations of the PLC memory.
The first attack involved overwriting bytes of memory allocated to external sensors.Similarly, the second attack affected the memory associated with outputs.The third attack targeted the working memory to modify set-point variables, including high or low alarms, and values in control systems.Furthermore, Zubair et al. [57] were successful in injecting a malicious program that modified a table entry in the RAM memory, effectively redirecting a built-in call to a malicious function.Notably, they managed to conceal their attack by erasing any traces from the protocol mapped space after its execution.

3) DOS ATTACK
A major security vulnerability in most PLCs lies in their design, where they accept requests from any Internet Protocol (IP) or media access control (MAC) address.Consequently, one of the primary attacks to ICS systems is a DoS attack.A DoS attack is technically not a specific attack type but rather a goal that involves various attack methods.The objective of a DoS attack is to disrupt the availability of a service or resource, hindering legitimate access to authorized resources and interfering with their intended utilization.
Tacliad et al. [58] identified a particular scenario of DoS attack conducted through the Ethernet/Industrial Protocol Fuzz, targeting the Programmable Controller Communication Command (PCCC) service.They found that using an invalid data file type caused data reading failures.Moreover, DoS attacks are often IP-oriented attacks.Another research [59] demonstrated different DoS attack scenarios by spoofing IP addresses between both S7 PLCs and their software i.e., Total Integrated Automation (TIA) Portal.In the same way, Sayegh et al. [60] performed IP packet flooding on the PLC's ports; precisely, they launched DoS attacks between two connected devices (PLCs and HMIs) using four different methods.Furthermore, the DoS attack presented in [61] showcased that an

4) HMI-EXPLOITED ATTACK
The HMI device helps human operators to observe and control industrial processes.It allows them to monitor the process state, adjust control settings, and intervene manually during emergencies.In addition, operators can configure control algorithms and parameters in the connected PLCs.Unfortunately, these functionalities also make the HMI an attractive target for potential attackers who seek to exploit vulnerabilities in both the HMI's software and hardware components (see Fig. 8).
Common vulnerabilities include memory corruption, weak credential management, lack of proper authentication/authorization, code injection bugs, etc.Researchers like Kleinmann et al. [91], Rosa et al. [90], Hu et al. [92], and Alsabbagh et al. [75] have investigated various attack scenarios against real HMIs.Kleinmann et al. [91] demonstrated attacks by hijacking the communication channels between the HMI and PLCs.By manipulating the traffic, they were able to present a fake view of the industrial process to the operator, leading to potential damage to the system.Rosa et al. [90] crafted deceptive Modbus frames transmitted between PLCs and an HMI, creating a false view for the SCADA operator.Hu et al. [92] presented a sophisticated multistage semantic attack against ICS, which could bypass existing intrusion detection systems (IDSs).By hijacking the communication channels between the HMI and the remote PLC, they manipulated measurement data and control instructions while presenting a fake view of the data to the HMI to conceal the malicious activity.Alsabbagh et al. [75] introduced a stealthy false command injection attack using a database containing real Modbus request-response pairs between PLC and HMI devices.By skillfully managing communication flows, they tricked the SCADA operator, showing them fake views, while the PLC processed malicious commands from the attacker.These studies highlight the importance of strengthening the security measures around HMIs to protect CI from potential cyber-physical attacks.

5) TIME-DELAY INJECTION ATTACK
This type of attack primarily focuses on exploiting weaknesses within the communication links of the targeted system, resulting in the loss of critical information and potentially leading to unstable operating conditions [95].In a PLC-based system, delays in packet transmission across the control network can cause a degradation in system performance and stability.Larsen [96] termed this attack as a "stale data attack," where the attacker manipulates the timing of encrypted packets on the associated network to create a discrepancy between the physical and logical states of the process.As a consequence, the PLC may be forced into an arbitrary state.To illustrate, Lou et al. [97] conducted a time-delay injection attack on a power plant control system, successfully introducing delays in the transfer of control commands over the control network.Similarly, Korkmaz et al. [94] executed a successful time-delay injection attack on a SCADA system.They first exploited a network vulnerability and then employed a traffic shaping tool to intentionally introduce random delays within the targeted control network.

B. ATTACKS AGAINST INTEGRITY
In this category, we elaborate five different attack scenarios as follows: payload, injection, I/O pin control, control flow, and configuration modification attack.The following subsections provide a detailed explanation of each attack scenario.

1) PAYLOAD ATTACK
PLCs interact with various hardware components and offer firmware support for executing control logic programs, often referred to as "payload" programs.Lately, there has been a growing interest among attackers in targeting these payload programs (see Fig. 9).
The reason behind this is that they can directly inject harmful payload programs into PLCs.Once they acquire the necessary privileges, attackers can even modify alerts related to payload changes, effectively concealing their actions [62].Consequently, engineers are unable to identify malicious payload programs through real-time integrity inspection using specific-vendor PLC software.As a result, such attacks can be seen as alterations to control logic or the direct insertion of malicious code into the PLC system.To explore the capacity of generating malevolent payloads, McLaughlin et al. [63] delved into the challenge of developing PLC malware capable of creating dynamic payloads based on insights gained from observing processes within the control system.The researchers successfully crafted a dynamic payload that triggered unsafe behaviors within the PLC.In a subsequent study, McLaughlin and McDaniel [64] introduced a tool called SABOT.This tool automatically maps control instructions within a PLC to a specification of the desired behavior of the target control system, provided by an adversary.This mapping process reconstructs enough internal layout semantics of the PLC to instantiate arbitrary malicious PLC code.

2) CONTROL FLOW ATTACK
This class of attacks involves exploiting a vulnerability related to memory corruption, like buffer overflow.This vulnerability allows attackers to execute code of their choice (see Fig. 10).
Initially, they evade critical security checks such as secure boot or authentication methods.Once that is done, they proceed to execute malicious code segments without any conditions.Serhane et al. [41] demonstrated how attackers can compromise functions, manipulating specific values of operands, or introducing empty branches and jumps.They discussed the potential of using infinite loops through jumps and utilizing timers to trigger a branch with malicious instructions at a time chosen by the attacker.Valentine [43] outlined an attack scenario where an adversary inserts a jump to a subroutine function and alters communication between two or more ladder components in LD code.The author illustrated that an attacker who gains access to the engineering station could implant their malicious code at a wrongly labeled location.This would lead to multiple errors before the code reaches its intended destination upon the return command.Beresford [74] identified various protocol vulnerabilities in Siemens PLCs that could be exploited by an adversary to execute remote code attacks.Schuster et al. [156] conducted experiments revealing an attacker's ability to elude detection methods for control flow attacks by manipulating executable module code sequences within the target program.Davi et al. [157] introduced several techniques for control flow attacks that can bypass conventional detection mechanisms.Specifically, they demonstrated that attackers can capitalize on vulnerabilities in a program's binary code to create extensive chains of gadgets.This approach effectively undermines detection mechanisms designed to counter control flow attacks.

3) INJECTION ATTACK
The majority of PLCs tend to accept messages without restrictions when received over networks that use insecure communication protocols, such as S7Comm for Siemens S7-300 and S7-400 PLCs, and PCCC for Allen-Bradley MicroLogix 1400 PLCs.Moreover, some PLC vendors provide open-source function libraries that help in establishing TCP/UDP communications that eventually bring a significant risk of exploitation by malicious attackers.This creates a scenario where unauthorized individuals who gain access to the control network can insert harmful data or code into PLCs, thereby gaining complete control over the targeted PLC(s) and causing severe disruptions to the entire control system.A good example of such an attack is the "denial of engineering operations" (DEO) [101].The authors introduced three attack injection scenarios.The first two attack scenarios utilized a MitM approach to manipulate network traffic during attempts to retrieve control logic from an infected PLC.In the first attack, the adversary removed the infected code from the packets to conceal the infection, while in the second attack, the attacker replaced specific control logic instructions in the packets with irrelevant data.In the third attack, the attacker crafted a malicious control logic that could run on a PLC but caused the software to crash when attempting to obtain the control logic from the PLC.Alsabbagh and Langendörfer [38], [39], [48], [49], [50], [81], [82] presented various injection attack scenarios targeting SIMATIC S7 PLCs.They demonstrated the feasibility of exploiting vulnerabilities in S7Comm and S7CommPlus protocols, allowing for the modification of control logic programs in S7 PLCs from different families.Furthermore, the authors managed to hide their ongoing attacks from the ICS operators using various techniques, including employing fake PLCs, manipulating certain blocks, and crafting specific packets.The compromised PLCs caused unsafe states within the systems they targeted.Qasim et al. [66] introduced an automated framework called Similo for control logic forensics in ICSs.As part of their experiments, they conducted DEO attacks similar to those in [101] and managed to hide malicious control logic within Allen-Bradley MicroLogix 1100 and 1400 PLCs.Klick et al. [99] demonstrated that a knowledgeable adversary with access to a PLC, specifically S7-300 PLCs, could download and upload native code to it, provided that the code was composed of MC7 bytecode.The authors developed an attacking tool named PLCinject, designed to inject malicious MC7 bytecode into PLCs.Using PLCinject, Spenneberg et al. [100] introduced a worm called PLC-Blaster, capable of spreading from one PLC to another by copying itself and adapting the next targeted PLC to execute the worm alongside the active control logic program.The worm was designed to execute appropriate code at the start of each execution cycle and incorporated various antidetection mechanisms to intensify its impact.Another form of injection attack pertains to false data.McLaughlin and Zonouz [68] performed an injection attack, precisely a false-data scenario against individual PLCs.Their attack tool first analyzed I/O traces to internally build a logic model of the target devices and then performed a sequence of false input data to achieve desired outputs.Another work [69] introduced a false-data attack that involved constructing a certain model by collecting a so-called faultfree I/O traces.The achieved model was then used to generate false sequences for injecting into exploitable sensors.Fritz et al. [70] used Petri nets (PNs) to model a false-data attack in order to maliciously change sensor measurements in a discreet manner to alter state variables.Employing stealthy techniques for injection attacks, Yoo and Ahmed [71] suggested a falsedata attack through two scenarios: fragmentation and noise padding attack.Both the scenarios aimed at using certain network packets to manipulate the logic of the target PLC.

4) I/O PIN CONTROL ATTACK
Fig. 11 represents a high overview of this attack scenario.The control of pins within embedded devices is governed by specific electrical logic that corresponds to unique physical addresses known as registers.To illustrate, the "Input Enabled" logic designates a pin's function as an input.In the context of PLCs, their logical registers are also linked to mapped registers, all of which are overseen by the OS.This process of managing the mapped registers through software is referred to as pin control.From a security perspective, malicious attackers have the potential to carry out I/O pin control attacks, compromising the legitimacy of authorized operations and manipulating interactions with the physical environment.An illustrative instance of such attacks was presented by Abbasi et al. [73].The authors assumed that they had obtained root access and necessary preliminary knowledge.They devised an I/O manipulation attack with a discreet approach.Their method involved using the debug registers of the PLC to interrupt specific packets, e.g., read and write.Notably, they emphasized that their attack would go undetected by the PLC's runtime software.Building upon prior investigations, Abbasi et al. [72] further demonstrated in a subsequent study how an attacker could disrupt the integrity and accessibility of PLCs' I/O by exploiting specific pin control operations.This attack allowed the perpetrator to gain control over the physical processes typically managed by the PLC, all while evading detection by both the PLC runtime and monitoring personnel such as HMI operators.Importantly, this approach did not necessitate altering the PLC control logic as suggested in previous works [63], [64], which would typically be supervised by a host-based IDS.

5) CONFIGURATION MODIFICATION ATTACK
These attacks enable an adversary to change crucial settings or files of a PLC, such as control logic and network communication setups, in order to manipulate the process being controlled.Fig. 12 shows this attack scenario.
These malicious actions can be executed through network communication or interactions with hardware and software components.For instance, in PLCs using protocols like DNP3 or Profinet, configuration parameters play a key role.These parameters determine whether the PLC operates as a slave or a master, the allocation of protocol addresses, and the data points involved, including the extent of communication with additional slave or master devices.If an adversary gains control over a workstation within a CI network and gains access to configuration files related to the target PLC, he can modify these files and replaces them with altered versions.This manipulation grants the attacker control over the PLC, potentially resulting in harmful activities affecting the entire system.Furthermore, the attacker can load his customized configuration onto both master and slave PLCs.Depending on the device, configuration files might be uploaded via Ethernet or serial connections.Sometimes, the attacker can even upload the original configuration previously installed by an engineer.This scenario allows adversaries to analyze the uploaded configuration, make modifications, and subsequently upload the altered configuration back into the control process.A good example of such an attack scenario is Stuxnet.Falliere et al. [2] reported that the Stuxnet malware was utilized to tamper with the programming of PLCs, specifically impacting a portion of the uranium enrichment process.

C. ATTACKS AGAINST CONFIDENTIALITY
In this group, we categorize five types of attacks: MitM, replay, eavesdropping, bypass, and brute-force attack.In the following, we provide a more elaborate depiction of each attack scenario.

1) MITM ATTACK
In MitM attacks, malicious adversaries position themselves between two devices, e.g., PLC and PLC, PLC and HMI, etc., or between devices and control centers.These attacks exploit the lack of encryption and or authentication mechanism in the existing communication protocols, allowing the two ends of the communication to interact legitimately.More concerning, the attacker can manipulate messages to compromise data confidentiality.The Address Resolution Protocol (ARP) poisoning technique is commonly employed in MitM attacks.This method involves associating the victim IP addresses with attacker's MAC address in the ARP tables.The MitM approach was used against different S7 PLC families [38], [39], [45], [48], [49], [50], [74], [76], [77], [81], [84], [85], [86], [88], [102], intercepting all data packets exchanged between the engineering station and the PLC.In another instance, Lim et al. [103] utilized an MitM scenario in order to exploit TRICON PLCs.The authors interrupted and altered certain configuration setting packets, rerouting the traffic through the victim controllers.Furthermore, Grandgenett et al. [102] developed an MitM attack to selectively manipulate Common Industrial Protocol data and commands transmitted between PLCs (RSLogix 5000) and Web server (EtherNet/IP) module.

2) REPLAY ATTACK
This kind of attacks involves taking advantage of a system's operation by resending certain valid messages (see Fig. 13).
These messages are typically contained within packets that are recorded by attackers from a prior communication session using an MitM approach.The goal of this attack is first to bypass successfully any authentication mechanism applied, even if attackers do not fully understand the communication protocols.Beresford [74] was among the first researchers who demonstrated a replay attack against S7 PLCs (S7-1200).His work sparked interest among researchers focused on PLC security [38], [45], [77], [81], [83], [89].Following vulnerabilities in the S7Comm protocol, a new protocol called S7CommPlus was developed with a built-in protection mechanism against replay attacks.However, several research works [49], [50], [82], [84], [85], [86], [88] revealed that the S7CommPlus protocol still have exploitable weaknesses.Researchers managed to break the encryption algorithms, allowing them to successfully carry out replay attacks against S7 PLCs.

3) EAVESDROPPING ATTACK
An eavesdropping attack takes place when an attacker intercepts, deletes, or alters data being transmitted between two or more endpoints within a system.This technique, also referred to as sniffing or snooping, exploits insecure network communication to gain unauthorized access to data in transit among devices.In a study by Ayub et al. [87], an eavesdropping attack was executed as part of their investigations into the authentication methods employed by different PLCs.The researchers demonstrated that attackers who have access to the control network can not only read but also manipulate any messages being exchanged over the network.Similarly, Alsabbagh et al. [75] intercepted packets exchanged between a PLC and HMI, modifying these packets to hide their ongoing attack from the operator of the ICS.In another instance, Sushma et al. [83] substituted control packets in the network with crafted packets as a component of their control logic injection attack.Consequently, the ICS operator was deceived into receiving a false control logic program, while the PLC executed a modified program.Hui et al. [86], [88] also adopted the eavesdropping attack strategy to pilfer an S7 session from the ICS operator and successfully establish communication with the targeted S7 PLC.The researchers deliberately dropped specific S7 packets from the network, preventing the intended destination from receiving accurate data.This facilitated the authors' ability to carry out more severe attacks against the targeted device.

4) RECONNAISSANCE ATTACK
Reconnaissance attacks have the primary objective of collecting information related to control systems and devices.These attacks involve activities such as mapping the network structure and identifying specific characteristics of the devices.These characteristics encompass details like the manufacturer, model number, network protocols, system addresses, memory layout, and so on.Previous studies, such as [39], [74], [81], and [99], have introduced specialized tools for scanning industrial environments.These tools are designed to extract vital information about PLCs and the systems they are associated with.For example, Alsabbagh and Langendörfer [81] introduced a tool called a PNIO scanner.This scanner is capable of exploring industrial networks and detecting any devices that support the Profinet protocol.The authors also devised an S7 scanner, specifically for compromised S7 PLCs, e.g., S7-300 and S7-400.This scanner gathers crucial data from these PLCs, including software and hardware blocks, block counts, program sizes, and more.In a similar vein, Beresford [74] conducted an eavesdropping attack using Wireshark (network protocol analyzer).By capturing specific packets, he managed to uncover important data, which he then leveraged for subsequent attacks, such as replay attacks.Another contribution comes from Klick et al. [99], who presented a scanner based on the Simple Network Management Protocol.This scanner focuses on revealing significant details about exposed S7 PLCs, including information like product type, model number, hardware and software firmware versions, and other pertinent data.

5) BRUTE-FORCE ATTACK
A brute-force attack involves attempting to deduce login details, credentials, and encryption keys by systematically trying out every conceivable combination of characters or numbers until the correct one is identified.This approach is primarily employed to uncover passwords for PLCs or HMIs, as shown in [38], [74], [81], [83], [87], and [89].In a study by Alsabbagh and Langendörfer [81], a brute-force attack was employed to extract plaintext passwords securing S7-300 PLCs.The authors managed successfully to eliminate the password protection, denoted by setting the protection level to "0." Consequently, this enabled the attacker to access the compromised PLC for reading and writing operations without undergoing any authentication procedure.In another instance, Ayub et al. [87] delved into the task of deciphering passwords from various PLC manufacturers.They achieved this by intercepting authentication packets exchanged within the network communication between PLCs and their respective engineering software.Subsequently, these researchers scrutinized the authentication algorithms employed by different PLCs.Employing brute-force techniques, they managed to uncover the actual passwords utilized in the tested PLCs.Furthermore, Ward et al. [89] intercepted authentication packets transmitted between S7-400 PLCs and TIA Portal software.This interception led to the revelation of the encoding mechanism used for password protection.Building upon this knowledge, the authors then executed various replay attacks, enabling them to manipulate the passwords associated with the evaluated PLCs.

V. SECURITY SOLUTIONS
In this section, we investigate existing security methods that are employed to safeguard PLC-based systems.It is important to emphasize that these methods have been sourced from prior research works.We categorize these security methods into six groups as follows: 1) PLC program detection; 2) PLC firmware detection; 3) PLC side-channel detection; 4) intrusion detection; 5) honeypot-based detection; and 6) digital forensics, as shown in Fig. 14.In the following, we provide a more comprehensive exploration of each category of these security approaches.

A. PLC PROGRAM DETECTION
The operational status of active PLCs ultimately impacts the overall state of the entire system.As a result, adversaries focus on compromising PLC control logic programs in order to directly inflict significant damage on the physical processes controlled by the compromised PLCs.Several research works have employed formal verification to ensure the safety and security of PLC programs, as shown in Table 3.In this article, we categorize the existing research efforts according to the following criteria.

1) BEHAVIOR MODELING
The objective of behavior modeling is to create a structured portrayal of the behavior exhibited by a PLC program.This depiction enables a formal verification framework to comprehend and confirm it when provided with a specification.In the following, we group behavior modeling into three tiers: program level, binary code level, and program runtime level.
a) PLC program level: At the level of software design, prior research works, such as [171], [172], [173], and [174], have delved into the structured representation of general program actions.Those studies mentioned transformed programs into automata [164] and PNs [165], as these forms were well supported by already existing formal verification frameworks [171].These transformations typically viewed each component of the program as an automaton, encompassing the main program, functions, and instances of function blocks.Corresponding variables within the program unit were converted into variables in the automaton.Inputs were assigned in a nondeterministic manner at the outset of each cycle of the PLC.The entire program was depicted as an interconnected set of automata, wherein transitions captured alterations in variable values across different execution cycles, and synchronization pairs indicated coordinated transitions involving function calls.In a similar approach, Newell et al. [174] translated FBD programs into models using the prototype verification system (PVS), as certain nuclear power plants specifically supported this representation.Kottler et al. [113] dedicated their efforts to assessing the reliability of PLC programs written in LD and ST languages, aiming to identify specific vulnerabilities related to security.Hailesellasie and Hasan [114] introduced a methodology based on the attributed graph between both manipulated programs and original ones.Such graphs are basically produced through formal modeling based on the Uppsala Timed Automata Analyzer (UPPAAL) framework.All the previously mentioned studies were successful in formally representing a wide range of PLC behaviors, particularly the internal logic embedded in the PLC code.However, due to the limited availability of only the source code, these behavior models lack integration with the physical PLC hardware and the real-world processes.This limitation increases the possibility of unsafe or malicious behaviors going unnoticed during subsequent formal verification processes.
(b) PLC binary program level: Only few works have discussed behavior modeling at the binary code level, particularly focusing on the challenges of reverse engineering.Previous studies like [110] and [111] highlighted that various features of PLCs are not fully supported by standard instruction sets.PLCs employ a hierarchical system to address input and output buffers, and use function blocks with fixed entry and exit points along with specialized timers that behave differently for bit/logic and arithmetic instructions.Several researchers [110], [111], [112], [175] have delved into the modeling of Siemens binary programs.For instance, McLaughlin et al. [110] utilized an instruction list (IL) derived from the statement list (STL) program to enhance instruction modeling comprehensiveness.They employed a throughsilicon via (TSV) tool to extract information flow from PLC registers and memory.By executing multiple scan cycles, they constructed a temporal execution graph to represent controller code states.Zonouz et al. [111] adopted a similar modeling approach, while Chang et al. [112] developed control flow graphs (CFGs) highlighting executable paths.These authors inferred timer output states based on existing output state transition relationships.Xie et al. [175] took a constraintbased approach for program modeling.Lv et al. [115] introduced a decompiler suited for control logic programs, utilizing instruction or operand templates.Similarly, Keliris and Maniatakos [116] introduced a reverse engineering framework designed to deal with PLC machine codes that are compiled with CODESYS.Another work [117] decompiled programs from machine codes into STL code and subsequently constructed a CFG to establish input-output mappings.Abbasi et al. [118] performed a so-called embedded control flow integrity approach to address binary program concerns.

C) PLC PROGRAM RUNTIME LEVEL
Utilizing real-time data, prior research works [107], [176], [177], [178], [179] focused on the conceptualization of software programs in conjunction with their interactions within physical processes, supervisory systems, and operator tasks.This approach facilitated the creation of more lifelike models capable of accommodating time-sensitive instructions and domain-specific behavioral characteristics.Several automated frameworks [107], [180] were introduced to capture PLC behaviors encompassing interrupt scheduling, function invocations, and I/O traces.In a study by Zhou et al. [179], an environment module was integrated to handle inputs and outputs, an interruption module was incorporated for time-dependent instructions, and a coordinator module was devised to orchestrate these two modules alongside the main program logic.

TABLE 3. Existing Works Related to PLC Program Detection
Wang et al. [180] automated a framework known as behavior interaction priority (BIP), which formalized the scanning mode, interrupt scheduling, and function calls within the PLC.Another work [180] presented a component-based approach to model the entire control command sequence, with each component being described as a timed automaton.For the automation of domain-specific event behaviors, VetPLC [107] generated timed event causality graphs (TECGs) derived from the program itself and the dynamic runtime data traces.The TECG maintained temporal dependencies constrained by machine operations.These investigations effectively eliminated obstacles associated with modeling event-driven and domainspecific behaviors.Furthermore, these methodologies proved capable of mitigating security and safety breaches by identifying and countering anomalous logic sequences.

2) STATE REDUCTION
The aim of state reduction is to enhance the scalability and intricacy of formalizing PLC programs.This process comprises two primary phases.Initially, it is crucial to identify significant states associated with safety and security attributes.Subsequently, we categorize behavioral modeling into three tiers: program level, binary code level, and program runtime level.

A) PLC PROGRAM LEVEL
At the level of source code, prior works like [182], [183], [184], and [185] focused on state reduction techniques.Gourcuff et al. [184] emphasized meaningful states as those linked to input and output variables, which directly govern the behavior of physical processes.They employed static code analysis to establish dependency relations among these variables within an ST program.This analysis revealed numerous irrelevant states.However, this method, while considerably reducing the search space for states, omitted portions of the original code necessary for subsequent verification.To enhance the formalization's code coverage, Pavlovic and Ehrich [185] proposed a comprehensive solution tailored for FBD programs.Their approach involved transforming graphical programs into textual statements in textFBD and then substituting circuit variables with tFBD.This procedure eliminated redundant assignments connecting continuous statements and consolidated them.Building upon this approach, Darvas et al. [182], [183] fine-tuned reduction heuristics by providing a more comprehensive representation.In addition to eliminating unnecessary variables and logic, these heuristics integrated cone of influence (COI)-based reduction and rule-based reduction.The COI-based reduction initially removed unconditional states that all possible executions passed through.Subsequently, it eliminated variables with no impact on specification evaluation.The rule-based reduction was changeable based on the safety requirements of the application domain.Moreover, mathematical models were employed to abstract distinct components.Newell et al. [174] introduced supplementary structures, such as attribute maps, graphs, and block groups, to diminish the state space of their PVS code.
These previous efforts effectively minimized program state sizes.However, they were confined to rudimentary Boolean representation reduction.For programs featuring intricate time-related variables, function blocks, or multitasking elements, these studies fell short.Furthermore, it remained unclear whether these reduction techniques could compromise program security.

B) PLC BINARY PROGRAM LEVEL
Research focusing on the binary level has primarily utilized a combination of symbolic execution and flow-based representation.This approach has illustrated that significant states generate distinct symbolic output vectors.The TSV [110] method consolidated input states that could potentially result in identical output values.In addition, it abstracted temporal execution graphs by eliminating symbolic variables in relation to their alignment with the valuations of linear temporal logic (LTL) properties.To enhance the elimination of irrelevant states, Chang et al. [117] minimized the overlap among output states within the same scan cycle.They also discarded output states that had undergone analysis in prior cycles.In order to streamline timer modeling overhead, the authors employed a deduction technique for timer output states.This technique involved scrutinizing existing relationships governing output state transitions.Importantly, these reduction strategies did not compromise the primary objective of detecting malicious behaviors spanning multiple cycles.

C) PLC PROGRAM RUNTIME LEVEL
By utilizing runtime information, a more comprehensive grasp of genuinely significant conditions can be attained.These encompass insights derived from event arrangement concerning subroutines and interrupts, along with the authentic inputs and outputs originating from processes specific to the given domain.Prior papers such as [107], [177], [178], and [179] have showcased diverse strategies for condensing states.To minimize the model's scope, Zhou et al. [179] integrated timers directly into the primary program instead of employing a distinct automaton.This choice was guided by their incorporation of genuine environmental traces, interruptions, and the coordination between them within their model.In a parallel vein, Wang et al. [142] merged segments devoid of jump and call instructions into singular transitions.Furthermore, alongside consolidating extraneous states, incorporating actual inputs and domain-focused insights can narrow down the scope when modeling numerical and floating-point variables.In Zhang et al.'s methodology [107], continuous timing behaviors were discretized into multiple time slices, each with a consistent interval.Given the accessibility of applicationspecific I/O traces, the time intervals were refined within a range that strikes a balance between efficiency and precision.

3) SPECIFICATION GENERATION
The objective of this research here is to formulate precise safety and security specifications using formal semantics.Prior investigations have concentrated on two key areas: 1) process-independent attributes that outline the fundamental prerequisites for a control system based on PLCs and 2) domain-specific attributes that necessitate expertise within a particular field.

A) PLC PROGRAM LEVEL
In the PLC programming theme, several research works, such as [173], [186], [187], [188], and [189], have delved into the realm of specification generation through the lens of processindependent attributes.These attributes encompass elements like the avoidance of variable locks, prevention of reaching unreachable operating modes, establishment of mutually exclusive operating modes, and the elimination of inconsequential logic [190].Prior investigations, like [171], [190], [191], [192], and [193], adopted the utilization of formulas based on computation tree logic (CTL) or LTL to articulate these attributes.LTL pertains to the future progression of pathways, signifying conditions that will eventually hold true or conditions that will endure until another fact becomes valid.In contrast, CTL is concerned with variance and reachability, encompassing concepts such as the perpetual confinement within a set of states or the capability to attain a specific set of states.Variations in this approach include the application of the universal fragment of CTL (ACTL), as demonstrated by Rawlings et al. [190], and the adoption of past time linear temporal logic (ptLTL), as explored by Biallas et al. [194].Apart from employing CTL-and LTL-based formulas, an investigation to facilitate the formal development of proofs was taken.For the meticulous delineation of syntax and semantics, Mesli-Kesraoui et al. [181] harnessed a proof assistant rooted in type theory-Coq.This was instrumental in defining safety properties for IL programs.The focus of semantics was centered around the rigorous formalization of on-delay timers, utilizing discrete time with fixed intervals.Alongside Coq, the KST framework [189] was embraced, offering a formal operational semantics platform for ST programs.KST operates on a rewriting-based semantic framework, previously employed to define semantics for programming languages such as C and Java.In comparison to Coq, KST offers a less stringent formality, resulting in a more accessible and comprehensible framework.However, this is balanced by the necessity for manual oversight to maintain the formal integrity of definitions.It is noteworthy that prior studies confined the process of specification generation to specific program models.Addressing this limitation, Darvas et al. [187] introduced PLCspecif, a solution that enables formal semantics for a variety of program models, encompassing state-based, data-flow-oriented, and time-dependent paradigms.These various works have opened up avenues for engineers without a deep-seated formalism background to generate precise and formal requirements.The inclusion of proof assistant frameworks even facilitated the generation of directly executable programs, such as those in the C programming language.Nevertheless, the automation of these processes was primarily confined to process-independent attributes.The subsequent discourse delves into the exploration of specification generation incorporating a more comprehensive array of information.

B) PLC BINARY PROGRAM LEVEL
As previously noted, the utilization of symbolic execution in the studies facilitated the incorporation of numeric and floating-point variables into program modeling.This inclusion of variables expanded the capacity for defining properties within the specifications.For instance, in the work by TSV [110], properties were established to limit the ranges of numerical device parameters, encompassing factors like maximum drive velocity and acceleration.Similarly, other researchers [111], [112], [175] formulated properties geared toward identifying instances of malicious code injection and parameter tampering attacks.Notably, Xie et al. [175] extended these properties even further to encompass the detection of subtle attacks such as stealthy incursions and DoS attacks.

C) PLC PROGRAM RUNTIME LEVEL
Utilizing real-time operational data, the focus of specification generation shifted toward domain-specific attributes.Within the context of a wastewater treatment plant, Luccarini et al. [178] employed artificial neural networks to distill qualitative patterns from continuous signals in the water, including metrics like pH and dissolved oxygen levels.These qualitative patterns were subsequently correlated with control events within the physical processes.This mapping was recorded using XML and then translated into formal rules to define specifications.This approach leveraged the captured input and output traces as reliable indicators of security and safety properties, diminishing the reliance on domain expertise.However, it is worth noting that actual runtime traces could potentially be contaminated or lack complete properties suitable for verification.To ensure the accuracy and comprehensiveness of domain-specific rules, previous research works [162], [195] also explored semiautomated methodologies that combined automated data mining with manual domain expertise.VetPLC [162] established safety properties through a combination of automatic data mining and event extraction, complemented by domain knowledge in formulating safety specifications.VetPLC adopted timed propositional temporal logic (TPTL), a more suitable framework for quantitatively expressing safety specifications.Apart from semiautomated approaches to specification generation, Mesli-Kesraoui et al. [181] manually established a set of rules governing interactions among each component along the control chain.The requirements were formulated using CTL temporal logic.To aid domain experts in devising formal rules, Wang et al. [142] formalized the semantics of a BIP model encompassing various types of PLC programs.This automated the generation of process-independent rules for interrupts, such as adhering to the first-come first-served principle.
Overall, these studies facilitated the creation of specifications by integrating domain-specific expertise.As a result, they extended the realm of security research, with a heightened emphasis on safety prerequisites.

4) VERIFICATION
Various studies such as [190], [191], [192], [193], [196], [197], [198], [199], [200], and [201] employed model checking and theorem proving to establish the safety and security of software programs.Each of the aforementioned studies has engaged multiple formal verification frameworks.Notably, a predominant choice among these frameworks has been the utilization of UPPAAL and Cadence SMV.UPPAAL has been primarily employed for real-time verification, adeptly representing intricate networks of timed automata, further extended to encompass integer variables, structured data types, and channel synchronization.On the other hand, Cadence SMV has been favored for nontimed verification tasks.In the subsequent sections, we delve into the specifics of each of these studies, categorized according to our established criteria.

A) PLC PROGRAM LEVEL
At the program level, formal verification investigations are conducted to detect vulnerabilities and enhance defenses against broad safety issues.This approach has been employed across various industries.For instance, Bender et al. [191] utilized model checking to assess LD programs represented as timed PNs.Using the Tina toolkit's model checkers, they verified LTL properties.Bauer et al. [196] opted for Cadence SMV and UPPAAL to, respectively, validate nontimed and timed models of SFC programs, successfully identifying errors across three reactors.Similarly, Niang et al. [199] employed UPPAAL to verify an SFC-based circuit breaker program.Hailesellasie and Hasan [114] employed UPPAAL, comparing two formally generated attribute graphs: 1) the Golden Model with properties and 2) a random model formalized from a PLC program.Their verification process centered around node and edge comparisons within the graphs, revealing instances of covert code injections.
In addition to utilizing existing tools, certain studies designed their own frameworks for verification.For example, Arcade.PLC [194] introduced support for model checking with CTL-and LTL-based properties applicable to various types of PLC programs.PLCverif [188] accommodated programs from all five Siemens PLC languages.NuDE 2.0 [202] provided a formal method-based approach for software development, verification, and safety analysis within nuclear industries.Rawlings et al. [190] employed symbolic model checking tools, specifically st2smv and SynthSMV, to validate and invalidate an ST program controlling batch reactor systems.This process automatically confirmed processindependent properties.Beyond model checking, certain studies [174] also incorporated PVS theorem proving to verify safety properties as described in tabular expressions for a railway interlocking system.However, it is important to note that these investigations primarily focus on verifying general safety requirements.

B) PLC BINARY PROGRAM LEVEL
Many research works [110], [111], [112], [175], [180] have contributed to the identification of binary injection attacks.TSV [110] adopted a hybrid approach, combining symbolic execution and model checking.It supplied the model checker with an abstracted temporal execution graph, along with a manually formulated safety property using LTL.However, TSV encountered limitations due to its compatibility with time-related operations within a single cycle, leading to challenges related to code verification and state explosion.To address these limitations, Xie et al. [175] employed constraints to validate random input signals and mitigate the aforementioned issues.They leveraged the nuXmv model checker for this purpose.Alternatively, Chang et al. [117] pursued a less formal verification methodology based on state count.These investigations effectively uncovered instances of malicious parameter tampering attacks.These instances were demonstrated through sample programs controlling diverse systems such as traffic lights, elevators, water tanks, stirrers, and sewage injectors.

C) PLC PROGRAM RUNTIME LEVEL
Using real-time data, prior research has been able to confirm safety and security concerns specific to certain domains.In the work by Carlsson et al. [203], NuSMV was employed to validate the interaction between the Open Platform Communications (OPC) interface and the program.This was achieved by defining properties as server/client states.Various issues such as synchronization problems-including delays, race conditions, and slow sampling arising from the OPC interface-were identified.In a similar vein, Mesli-Kesraoui et al. [181] utilized UPPAAL to analyze multilayer timed automata.They established a collection of safety and usability properties written in CTL and pinpointed synchronization errors between control programs and supervision interfaces.Incorporating insights from physical processes, VetPLC [162] amalgamated runtime traces and employed BUILDTSEQS to validate security properties expressed in TPTL.Contrasting VetPLC's approach, HyPLC [204] adopted the KeYmaera theorem to validate properties defined in differential dynamic logic.However, HyPLC pursued a two-way validation between physical processes and the PLC program, aiming to detect safety breaches.
The previously mentioned studies were inclined toward either offline verification or provided vague references to employing a supervisory component for online verification.To introduce an online verification framework, Garcia et al. [205] introduced an on-device real-time solution designed to detect control logic corruption.They capitalized on an embedded hypervisor within the PLC, endowed with enhanced computational capabilities and direct library function call integration.The hypervisor effectively addressed challenges related to stringent timing requirements and limited resources, enabling enforcement of verification within each scan cycle.

B. PLC FIRMWARE DETECTION
The firmware of a PLC serves as a bridge connecting the software to the hardware components.Many studies revealed that PLCs lack the ability to undergo firmware audits, as discussed in Section III-A2.In cases where the firmware is exploited by adversaries, they can eventually gain control over other physical components of the system through the compromised PLCs.Therefore, the detection of firmware modifications holds paramount significance in any control system based on PLCs.McMinn and Butts [119] introduced a tool for verifying firmware authenticity during an ongoing serial data upload process.This tool can be deployed across diverse platforms without necessitating alterations in the configurations of PLCs or their related systems.Furthermore, Basnight et al. [51] proposed an approach to deducing the validation of firmware updates.Through the utilization of reverse engineering techniques, they could uncover inconspicuous modifications to firmware, such as the HARVEY attack.Furthermore, Garcia et al. [54] offered insights into detecting firmware attacks.They put forth a method enabling the assessment of PLC firmware integrity and the monitoring of data exchanges in both directions: from input devices to PLCs and from PLCs to output devices.

C. PLC SIDE-CHANNEL DETECTION
In prior research, it has been demonstrated that unintended information can be exposed from PLCs.This exposure includes various forms like radio frequency (RF) emissions, power consumption patterns, electromagnetic (EM) emanations, and the duration of operations.These unintentional disclosures are usually gathered through physical measurements obtained from what is known as a side channel.Consequently, the analysis of side channels has emerged as a widespread approach for uncovering malicious attacks or unintended activities affecting PLCs.This article studies the current methods employed for detecting and understanding the effects stemming from side channels.

1) RATIO-FREQUENCY-BASED DETECTION
In 2012, Stone and Temple [120] introduced an RF-based approach to identify anomalous operations within PLCs.Subsequently, the authors enhanced the anomaly detection capabilities by employing sequences of unintentional timedomain emissions from PLCs, transformed using the Hilbert transform [121].Notably, this RF-based analysis scheme operates independently of network-based cyberattacks, relying solely on physical layer information from the isolated PLCs.

2) POWER FINGERPRINTING DETECTION
Gonzalez and Hinton [122] devised a method for monitoring PLCs and detecting malicious software execution using power fingerprinting.However, real-time monitoring posed challenges due to the need for sensors closely interacting with PLCs.To address this, Xiao et al. [123] proposed a noninvasive real-time detection method that utilizes a resistor to collect power consumption traces, alleviating the burden on PLCs caused by sensors and high-frequency data acquisition.

3) TIME-BASED DETECTION
The aforementioned techniques, such as RF-based detection and power fingerprinting detection, necessitate additional hardware integration into PLC-based systems, which can make the proposed methods intricate.Alternatively, some researchers have focused on simpler detection mechanisms, like utilizing timing-based side channels.For instance, Dunlap et al. [124] introduced a method for detecting unauthorized PLC manipulation based on measuring the execution time.
McDonald and Mueller [170] presented a monitoring technique for intrusion detection that involves inserting time checks along code paths.Their approach offers comprehensive protection throughout the entire execution path.

4) EM EMANATION-BASED DETECTION
A research group [125] investigated the possibility of using EM techniques for detecting code execution in PLC systems.The authors employed a signal cliff detection method, which allowed them to monitor regular and irregular activities independently.Likewise, another group led by Van Aubel et al. [126] leveraged EM side-channel measurements to spot alterations in behavior during the execution of industrial software.Their proposed approach involved a two-tier verification process: the initial tier evaluated the runtime of the user program, while the subsequent tier involved a comparison of its EM trace with a baseline version.

D. INTRUSION DETECTION
Given the presence of vulnerable industrial components and unsecured communication protocols, PLC-based systems face a broad spectrum of potential cyber threats.However, intrusion detection stands out as a prevalent remedy for identifying and thwarting cyberattacks.In terms of data origins, the field of intrusion detection can be categorized into two types: 1) network-centric detection; and 2) host-centric detection.This section delves into various intrusion techniques that have undergone testing and integration within ICSs.For a concise overview of our primary discoveries, see Table 4.

1) NETWORK-BASED INTRUSION DETECTION
In the realm of cybersecurity, the deployment of networkbased IDSs has become imperative due to the concealment of cyberattack vectors within the stream of network commands.Nonetheless, a distinct type of attack exists, characterized by the presence of multiple control commands.These commands appear valid when scrutinized on a per-packet basis; however, when observed collectively, they hold the potential to compromise the proper functioning of PLCs.To effectively identify such attacks, a novel approach involving critical state analysis has been introduced.This approach entails the monitoring of a sequence of packets that induce changes in the states of PLCs.Furthermore, the application of deterministic finite automata (DFA) has emerged as a prevalent technique for constructing a comprehensive traffic model conducive to intrusion detection.Investigating scenarios that involve periodic Modbus/TCP traffic between HMIs and PLCs, Goldenberg, and Woo [127] devised individual DFA models for each communication channel.These models were adept at sensitively detecting anomalies.Building upon this foundation, another work [129] introduced a strategy that amalgamates DFA with configuration-level specifications to monitor communication sessions.This amalgamation notably addresses the challenge of retraining the model following configuration alterations, circumventing the need for extensive retraining data.Markman et al. [130] identified a notable characteristic within the HMI-PLC communication channel: bursts of packets with semantic significance.This realization led to the proposition of a novel burst DFA model, which significantly improved anomaly detection accuracy compared to prior methodologies.Concurrently, other researchers [128] inspected the intricacies of PLC applications through the identification of semantic attacks.Such threats were categorized into three subtypes: reconnaissance, direct control, indirect control.This categorization paved the way for the development of a semantic network intrusion detection approach that encompasses various behavioral models, encompassing constants, attributes, and continuous series.To establish baseline expectations for constant and attribute data, a set of anticipated values was formulated.Techniques such as autoregression and control limits were harnessed to model continuous data.This multifaceted approach collectively contributes to enhancing the capabilities of network intrusion detection in PLC-based systems.

2) HOST-BASED INTRUSION DETECTION
To develop an effective IDS, cybersecurity researchers employ various techniques, including modeling state values such as relevant PLC memory addresses and control system state transitions.Previous studies extensively utilized supervised and semisupervised machine learning methods to detect anomalies or abnormal behaviors [131], [132].The authors of these research works capitalized on relevant memory address values alongside time stamps to create a model capable of distinguishing abnormal operations within PLCs.In pursuit of this objective, they introduced two anomaly detection strategies based on PN, focusing on experimental validation.Initially, they manually constructed a white list that mirrored field device characteristics using PN modeling.This white list was subsequently converted into an LD format, incorporating PN-based constraint conditions.This conversion empowered the PLC to identify and respond to abnormal behaviors [133].However, this white-listing approach had limitations, particularly in cases where the system displayed complexity.To address this issue, researchers enhanced the white-listing method by introducing an automatic generation technique [134].Here, the authors employed the SFC programming language instead of LD.Moreover, self-parameters were integrated to detect various malicious attacks.Krishnamurthy et al. [135] focused on modeling baseline behaviors within PLC-based systems and subsequently identifying anomalies.Their approach is appropriate for both multithreaded as well as interrupt-driven processes across different PLCs.Building upon this foundation, Chatterjee et al. [136] developed a (k, l) threshold signature scheme using a finite-state machine.This approach had the capability to detect both patched devices and manipulated states, demonstrating efficacy particularly for legacy PLCs.

E. HONEYPOT-BASED DETECTION
In contrast to the passive techniques mentioned earlier (see Sections V-A-V-D), the method of honeypot detection involves actively monitoring network conditions, gathering data, and analyzing potential threats.When it comes to safeguarding PLC-based systems, there are several features associated with honeypots, including obfuscation, high-fidelity emulation, secure storage of malware samples, and the redirection of network traffic.The utilization of honeypot-based detection systems has demonstrated their effectiveness in identifying malicious intrusions and potential vulnerabilities before they can result in severe attacks.As a result, certain researchers have turned their attention to examining honeypots as a promising approach for enhancing the security of systems.
When categorizing existing honeypots designed for PLCs based on their level of interaction, we can identify two main categories.The first category consists of low-interaction honeypots, with Conpot [137] as an example.The second category encompasses high-interaction honeypots like Cry-PLH [138], [139], XPOT [140], and S7COMMTrace [141].When applying honeypots to ICSs, researchers take into account important attributes such as performance, authenticity, scalability, cost, and risk.Conpot, falling into the low-interaction class, supports multiple protocols and offers limited function codes.However, it has a drawback in that attackers can often detect its presence due to its distinctive fingerprint.To enhance authenticity, CryPLH has developed improved interaction capabilities and introduced more original PLC implementations.This has proven highly effective in real-world control network deployments, allowing CryPLH to gather valuable data.In contrast, S7COMMTrace boasts a more extensive range of subfunction codes within the protocol, leading to a more accurate simulation of PLC behavior.

VOLUME 4, 2023
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

F. DIGITAL FORENSICS
Security strategies are meticulously crafted not solely to shield PLC applications from malicious threats, but also to possess the capability of preemptive measures and the ability to trace back to the origin of any issues.Consequently, the role of digital forensics becomes paramount in addressing the latter concern.While a multitude of frameworks, methodologies, and tools have been devised for IT system forensics, only a fraction of these are directly applicable to PLC environments due to the pronounced distinctions in the specific requirements of ICSs, as elaborated in Section II-E.
The continuous availability of PLC-based systems around the clock has granted researchers profound insights into real-time data acquisition from operational instances.This encompasses the extraction of volatile memory data and data stored on hard disks.The concept of live forensics is progressively emerging as a practical solution for instantaneous digital investigations.Moreover, an effective strategy to bolster digital evidence analysis involves the enhancement of logging capabilities.Concurrently, akin to digital forensics, the realm of incident response research is dedicated to addressing and recovering from incidents in ICSs, aiming to reinstate normal operations.This convergence of methodologies, along with the development of tools and corresponding case studies, has captivated researchers, leading them to adapt digital forensics techniques for legacy PLC-based systems.See Table 5 for a more comprehensive breakdown of details.
Table 5 presents the utilization of cutting-edge methodologies at both the device and network levels.Concerning network strategies, the prevalent approach involves the parsing of proprietary industrial protocols and data extraction.This practice has gained prominence in analyzing interdevice communication, as seen in [65], [146], [152], and [153].At the device level, ongoing research is focused on monitoring the data within multiple memory addresses of PLCs, as indicated in [147] and [148].It is important to note, however, that these efforts have predominantly catered to vendor-specific PLCs, such as those produced by Siemens, General Electric, Rockwell Allen-Bradley, among others.The primary objective remains the expansion of the applicability of these proposed methods to a wide range of devices and protocols.For instance, Choi et al. [149] illustrates this goal.They achieved that by utilizing a web interface provided by a PLC to develop a monitoring system that is not tied to any particular vendor.A significant aspect of this system is its collection of security logs, which play a vital role in the context of digital forensics investigations.

VI. SECURITY SOLUTIONS CHALLENGES
As PLC-based systems continue to evolve, so do the threats posed by malicious attackers.Security measures designed for PLCs encounter significant hurdles when applied.The enduring prevalence of legacy systems, characterized by outdated hardware and software, hampers seamless integration of contemporary security protocols.Interoperability issues among diverse devices and communication protocols further complicate the establishment of consistent security measures.Moreover, the limited computing resources inherent to PLCs necessitate a delicate balance between robust security implementations and optimal system performance [229], [230].Real-time monitoring difficulties, human errors, and stringent regulatory compliance demands further amplify the complexity of securing PLCs.However, in the following, we list the most common challenges for the currently detection approaches, as shown in Fig. 15.

A. PROGRAM DETECTION CHALLENGES 1) FALSE POSITIVES/NEGATIVES
Detection systems for programs commonly utilize pattern matching and heuristics to spot malicious code.However, this approach can result in false positives, where legitimate code is mistakenly flagged as malicious, and false negatives, allowing malicious code to slip through undetected.Simply refining the system to minimize these errors does not make the security solution completely effective.

2) DYNAMIC ENVIRONMENT
Program detection methods encounter significant challenges due to the constantly changing nature of industrial environments.In these settings, replacing devices, removing/adding hardware or software, maintenance processes, etc., by ICS operators are standard practice.However, these changes can lead to false alarms or make existing detection mechanisms ineffective if they are not promptly adapted and updated.

3) ENCRYPTED CODE
Cybercriminals employ encryption techniques to evade detection, making it challenging for conventional program detection methods to identify malicious payloads concealed within encrypted code.

4) COMPLEX NETWORK ARCHITECTURE
Complex network architectures are common in ICSs, where numerous devices interact with each other, as illustrated in Fig. 4. Implementing program detection methods in these intricate setups poses significant challenges.Modern systems demand uninterrupted communication, making it difficult to seamlessly integrate detection methods without disruptions.

5) LIMITED UNDERSTANDING OF PROCESS CONTEXT
Conventional methods for detecting programs are limited in their ability to grasp the specific context of industrial processes.What might appear as a regular occurrence in one context could signify a potential security threat in another.It is crucial to comprehend the unique context of the process to accurately assess and identify potential threats.

B. FIRMWARE DETECTION CHALLENGES 1) LIMITED SIGNATURE DATABASES
Detecting firmware manipulations relies on recognizing specific patterns to identify malicious codes.Yet, maintaining an extensive and current database of these patterns is challenging.The constant emergence of new malicious code variants makes it hard to ensure the database remains both comprehensive and efficient.

2) ZERO-DAY EXPLOITS
Detecting zero-day exploits proves challenging for firmware detection systems as these exploits target vulnerabilities unknown to both the vendor and the security community.Since no signatures exist for zero-day exploits, they can effortlessly evade detection methods designed to identify firmware vulnerabilities.

3) LIMITED VISIBILITY
Methods for detecting firmware often concentrate exclusively on the firmware layer, disregarding other potential attack vectors like network-based assaults.A robust security strategy should encompass various layers of defense, as depending solely on firmware detection neglects these additional threats.

4) REGULATORY COMPLIANCE
Ensuring regulatory compliance in industrial sectors necessitates a strong security foundation.Relying solely on firmware detection may not be adequate to fulfill these compliance standards.

5) LACK OF STANDARDIZATION
In the realm of firmware detection, a striking absence of standardized methods is evident, spanning various vendors and systems.This absence of uniformity poses a significant challenge, hindering the implementation of a consistent and cohesive security strategy within diverse industrial settings.

C. INTRUSION DETECTION CHALLENGES 1) INSIDER THREATS
Conventional intrusion detection techniques may face challenges in identifying insider threats or attacks emanating from within an organization.This is because the patterns of such attacks often diverge significantly from those of external threats, making them harder to detect.

2) SECURITY POLICY VIOLATIONS
Recent intrusion detection methods face a significant hurdle: identifying subtle policy violations or deviations from security protocols is exceptionally complex.It is essential to recognize that not all policy breaches are necessarily malicious; some might inadvertently expose PLCs to threats.

3) INTEGRATION CHALLENGES
Incorporating IDSs smoothly into current PLC-based systems without causing any disruptions to their physical operations poses a notable challenge in this security strategy.

4) MAINTENANCE AND UPDATES
Ensuring the effectiveness of IDSs requires consistent maintenance, updates, and tuning.This is particularly crucial in environments utilizing PLCs, where operational downtime can incur significant costs.Implementing updates in PLCbased setups without interrupting ongoing operations poses a complex challenge.

5) ENCRYPTED TRAFFIC
Identifying malicious activities within encrypted traffic without decryption poses a significant challenge for IDSs due to the growing prevalence of encryption technologies.

6) LIMITED FORENSIC CAPABILITIES
Industrial IDSs may lack sophisticated forensic features, posing challenges in conducting comprehensive incident investigations and grasping the full scope of a security breach.

D. SIDE-CHANNEL DETECTION CHALLENGES 1) SENSITIVITY TO PHYSICAL CHANGES
Side-channel attacks exploit physical parameters like power consumption, EM emissions, and timing variations.These measurements are susceptible to environmental influences and can fluctuate due to system aging or physical changes.This sensitivity undermines the long-term reliability of existing side-channel detection methods.

2) VULNERABILITIES TO ADVANCED ATTACKS
As methods for detecting side-channel attacks become more advanced, attackers are also evolving their techniques.Skilled attackers can now use intricate strategies to bypass or manipulate these detection methods, making them ineffective against increasingly complex and novel attack approaches.

3) ETHICAL AND LEGAL CONCERNS
Side-channel attacks frequently entail the monitoring of physical signals, giving rise to ethical and legal dilemmas, particularly in sensitive contexts.Concerns related to privacy and legal constraints could restrict the implementation of specific side-channel detection techniques.

4) LIMITED SCOPE
Detection techniques for side-channel attacks often target particular attack types, offering effectiveness against specific classes of threats.However, these methods might not offer complete protection against all potential side-channel attack vectors.This leaves PLCs susceptible to new or unforeseen attacks, highlighting the need for more comprehensive security measures.

E. HONEYPOT-BASED DETECTION CHALLENGES 1) LIMITED APPLICABILITY
Honeypots prove to be highly efficient in conventional IT settings; however, their effectiveness diminishes in industrial systems such as PLCs.Industrial networks employ specialized architectures and communication protocols, making it challenging for standard honeypots to accurately mimic these environments.Consequently, their applicability and utility are limited in such contexts.

2) LIMITED ATTACK SURFACE COVERAGE
Honeypots are limited to detecting only certain vulnerabilities and attack methods within their predefined scope.If an attacker exploits a vulnerability not within the honeypot's coverage, the intrusion will remain unnoticed.

3) DEPENDENCY ON SIGNATURE-BASED DETECTION
Numerous honeypot strategies hinge on signature-based detection techniques, which are susceptible to evasion by attackers employing innovative methods or exploiting zero-day vulnerabilities.

4) LIMITED INSIGHT INTO INTENTIONS
Methods relying on honeypots offer insights into attack techniques but might not uncover attackers' true motives.Grasping the motive behind an attack is essential for a proactive incident response strategy.

F. DIGITAL FORENSICS CHALLENGES 1) HARDWARE CHALLENGES
a) Constrained resources: Applications that rely on PLCs have inherent limitations in their ability to handle data due to their restricted CPU, memory, and I/O resources.This constraint is particularly noticeable in the case of older or legacy PLCs.When it comes to forensic investigation, researchers might face challenges in obtaining and analyzing data from these systems.b) Local access: Due to the remote placement of field devices, accessing compromised devices poses a challenge for forensic tools that depend on close physical proximity.c) Proprietary Devices, protocols, and software: Devices produced by individual manufacturers utilize proprietary protocols, unique OSs, and at times specialized hardware.These factors create challenges for all-encompassing forensic tools to be effective in industrial control environments.In most cases, specific manufacturers do provide a restricted range of compatible interfaces to aid in enabling digital forensic functionalities.d) Insufficient logging: Because the main objectives of utilizing PLCs involve overseeing and managing physical processes, the logging mechanisms associated with this function do not adequately facilitate comprehensive security inquiries.Furthermore, the storage of logging data also imposes an additional load on the memory of PLCs, which is constrained by its limited size.e) Huge data to be processed: Several sensors or actuators produce a substantial volume of data related to lower level control processes.This abundance of data adds complexity to the tasks of filtering and analyzing the pertinent information.
2) RESEARCH CHALLENGES a) Constrained resources: Using simulators, the replication of intricate industrial situations remains challenging for the purpose of conducting digital forensic research experiments.Regrettably, simulations conducted without meticulous deliberation can occasionally lead investigators astray, ultimately leading to erroneous conclusions.b) Small-scale testbeds: Creating testbeds comprising actual physical equipment is a prudent decision on the part of researchers.Regrettably, this approach faces scalability challenges due to the substantial costs associated with real industrial hardware.c) Research for specific control processes: Unlike digital forensics in IT systems, the particular disparity lies in the focused control procedure.However, insufficient exploration in this domain results in the inability to retroactively trace occurrences stemming from semantic attacks.
3) HUMAN FACTORS CHALLENGES a) Lack of background knowledge: Frequently, ICS operators find themselves without the essential foundational comprehension.This includes a comprehensive grasp of intricate control protocols, detailed knowledge regarding vulnerable devices, an awareness of how forensic tools affect system performance, and various other related aspects.b) Industry collaboration: Due to concerns about data leakage, most industrial enterprises are hesitant to collaborate with the research community.This reluctance could potentially impede the progress of practical advancements in digital forensic tools and methodologies.

VII. FUTURE SECURITY DIRECTIONS
Nevertheless, all security solutions presented so far couldn't sufficiently address the evolving threat landscape.Upon scrutinizing the available body of work, it becomes obvious that industrial vendors and engineers must undertake secure upgrades or updates of control systems and their components, precisely PLCs.To fulfill this goal, it is essential to employ secure embedded systems and communication protocols.Moreover, acknowledging the vital need for thorough testing and analysis, PLC applications require validation techniques known for their exceptional precision.This level of precision can be attained by incorporating virtualization and utilizing open-source industrial control units.Furthermore, we contend that the integration of existing systems with cloud-based, fog-based, and dynamic network strategies opens up new avenues for ICS operators to bolster their defenses against a multitude of attacks and surmount prevailing security challenges.In the ensuing discourse, we outline six pivotal directions that underscore our approach to cybersecurity in the pursuit of conceiving considerably more fortified PLC-based systems.

A. SECURE EMBEDDED SYSTEMS
In the upcoming years, there will be a growing requirement to incorporate advanced security features into embedded systems, commonly known as "secure embedded systems."The vulnerabilities identified in current PLCs mainly originate from weaknesses within their firmware and control logics, as detailed in Section IV.To enhance the security level of PLCs, it is crucial to consider supplementary security measures such as secure boot processes, reliable program updates, and efficient embedded management.As a solution, we propose that manufacturers and industrial engineers explore inventive methods to develop resilient controllers.These methods could encompass integrating embedded hypervisors [214], employing CPUs with security processors, adopting frameworks for secure firmware updates, and incorporating secure boot mechanisms, either through software or hardware, in the next iteration of PLC applications.Moreover, we suggest embracing the principles outlined in the "Design Life-cycle of Secure Embedded Devices" methodology [215].It is important to acknowledge that these solutions might necessitate greater computational resources.Consequently, a key challenge for future research lies in discovering approaches to ensure security without compromising system functionality.

B. SECURE COMMUNICATION PROTOCOLS
The vulnerabilities present in outdated communication protocols compromise the security of the existing PLC-based systems.These protocols exhibit weaknesses like nonencrypted transmission, lack of user authentication, and absence of integrity verification mechanisms.As explained in Section IV, these systems are open to various types of attacks, including DoS, injection, replay, and MitM attacks.In response, manufacturers of industrial equipment have taken measures to bolster the security of their communication protocols.They have incorporated features such as encryption, antireplay protections, authorization mechanisms, and integrity checks.Nonetheless, ensuring the compatibility of these upgraded protocol versions with the existing array of PLCs poses a significant challenge.An example is the latest version of the S7CommPlus protocol, which cannot be used with older S7 PLC models like S7-300 and S7-400.However, despite the advancements in protocol versions, our investigations revealed that these versions still contain vulnerabilities exploitable by sophisticated attackers.For instance, the most recent iteration of the S7CommPlus protocol employs complex encryption algorithms to secure communication between S7 PLCs and their associated TIA portal against replay attacks.Despite this effort, several studies [49], [82], [84], [85], [86], [88] highlighted that malicious attackers can orchestrate attacks targeting these protocols.As a consequence, it remains crucial to persist in research aimed at enhancing industrial communication protocols.This involves both refining existing protocols and developing novel protocols incorporating advanced security measures.

C. VIRTUALIZATING PLC-BASED SYSTEMS
Given the financial implications and prevailing norms in the industry, the task of scrutinizing experiments or affirming the effectiveness of security solutions in real industrial settings is immensely challenging.Consequently, there exists a pressing need for controlled testing environments, commonly referred to as testbeds.These testbeds can be categorized into four distinct groups: those grounded in practical implementations [221], [222], simulations integrating tangible devices [220], solitary simulations, and collaborative simulations [223].With the advent of virtualization technologies, virtual federated simulations offer distinct advantages in terms of cost efficiency and scalability, particularly in the realm of ICSs.The central focus of ongoing research revolves around the virtualization of industrial components, such as virtual PLCs, and the creation of decoy systems using virtual hosts within the control network.
It is imperative to address concerns surrounding the accuracy of virtual components.For instance, if attackers were to identify disparities between the characteristics of virtual devices in the decoy system and their real-world counterparts, they might refrain from advancing their nefarious activities in the virtual environment.In essence, the value of the decoy system could be compromised due to the inability to faithfully replicate the characteristics of real devices.In a broader context, the future direction of PLC-based system virtualization goes beyond the mere establishment of an efficient performance testing platform, e.g., testing platforms against cyberattacks similar to what Verma et al. introduced in [224].It also aims to develop an exceptional and manageable alternative to the existing industrial devices, one that is both reliable and capable of meeting industrial demands.

D. OPEN-SOURCE UNITS
Simulating PLCs in virtual environments presents a notable challenge.This arises due to potential gaps in comprehending their internal behaviors, which can be further compounded when attempting to directly port PLC source codes onto general-purpose OSs.In the context of simulated attack experiments aimed at uncovering system vulnerabilities, a significant hurdle emerges: researchers must utilize PLCs as part of a "hardware-in-the-loop" setup.However, the progress of such endeavors is impeded by the constraints imposed by vendors' proprietary software and hardware.These limitations restrict the exploration of the embedded system's various facets, including operational logic and internal mechanisms.To surmount this predicament, a solution comes in the form of the OpenPLC project [154].This initiative was conceptualized with the objective of creating a standardized open-source framework that not only offers the complete source code but also encompasses an IDE and a range of available hardware configurations.Notably, this project caters to platforms such as Raspberry Pi, Arduino, and ESP8266.At the heart of the OpenPLC project lies a modular framework, granting researchers the freedom to construct tailored testbeds.This adaptability extends to incorporating virtualization techniques, allowing for the implementation of specific features as required.For instance, the integration of an encryption layer directly into PLCs, thereby bolstering the security of communication channels, can be seamlessly realized.As we look ahead, the emergence of open-source PLCs signals a promising trajectory as Mellado and Núñez introduced in their IoT-PLC project [225].Their new project provides not only regulatory control capabilities but also fog-computing functionalities as filtering and field data storage.Nevertheless, the evolution should not be limited to these entities alone.It is imperative that a broader array of open-source industrial control units be cultivated.This expansion is vital for the research community to undertake meticulous cybersecurity analyses targeting each pivotal component within PLC applications.

E. COMPUTING BASED ON CLOUD
In the realm of the Industrial Internet of Things (IIoT), the integration of cloud-based computing has facilitated the transition from conventional PLC-based control systems to cloud environments [213].This transition showcases a dynamic and flexible approach to treating PLCs as a service.However, this shift has also led to an expansion of potential vulnerabilities due to the intricate nature of large-scale frameworks, resulting in increased points of entry from diverse sources [226], [227].Addressing the future security concerns associated with safeguarding these control systems involves the utilization of security platforms hosted in the cloud [228].To illustrate, consider innovative platforms that exemplify this approach: Cloud PLC Prototype: A cutting-edge concept known as the "cloud PLC" 3 employs the substantial analytical capabilities of cloud computing resources.This prototype executes thorough security assessments, enabling a final validation of commands before they are executed on actual controlled devices.Security Cloud Platform for Service-Oriented Architectures is another approach that involves the creation of a security-focused cloud platform tailored for service-oriented architecture systems.This platform serves as a comprehensive "tool-box" equipped with essential functionalities such as service planning, end-to-end security, monitoring, and enforcement.By providing these tools, the platform ensures data integrity and effectively mitigates potential attacks.Furthermore, this adaptable "tool-box" approach extends its utility to bolstering security and privacy at the fog layer.This augmentation is particularly important in countering cyber threats like compromised fog node attacks, thereby enhancing the overall resilience of the system.In conclusion, the emergence of cloud-based computing within the IIoT landscape has led to a paradigm shift in control systems.While presenting novel opportunities, it has also necessitated the implementation of robust security measures.The proposed innovative platforms, such as the cloud PLC prototype and the security cloud platform for service-oriented architectures, exemplify the strides being taken to fortify these systems against evolving cybersecurity challenges.

F. MOVING TARGET DEFENSE (MTD)
Regarding the prerequisites for PLC-based systems outlined in Section II, the task of frequently updating or patching these systems proves to be a significant challenge, particularly in the case of systems engaged in continuous processing operations.An approach that holds promise as an active defense technique is MTD.This approach involves deliberately allowing a portion of vulnerabilities that have not been patched to persist 3 [Online].Available: http://cloudplc.org/within the foundational systems.The intention is to introduce supplementary mechanisms that complicate the efforts of adversaries attempting to launch attacks.Up to this point, a handful of notable MTD research efforts have been conducted for control systems, as shown in [216], [217], and [218].These efforts encompass the implementation of dynamic IP and the utilization of randomly configured parameters.The employment of dynamic IP techniques serves to obscure the identification of peer hosts during the reconnaissance phase and hinders seamless communication between them.On the other hand, the incorporation of random configuration parameters imparts a time-varying and stochastic nature to the systems, limiting attackers' foreknowledge of the control process.
It is important to acknowledge that MTD is not an independent and comprehensive solution by itself; rather, it operates as a redundant and harmonized security augmentation.Consequently, MTD stands as a promising avenue to enhance the security and resilience of PLC-based systems, thereby contributing to a more secure future for such systems.

VIII. CONCLUSION
In this article, we conducted an in-depth review of the literature focusing on the security aspects of PLCs and related systems.This comprehensive survey encompassed various dimensions, including vulnerabilities, attack scenarios, security detection methodologies, digital forensic investigations, and prospects for future developments.The review examined these aspects from two perspectives: the fundamental component level, i.e., PLC level, and the overarching system level.Our investigation not only delved into the existing security landscape of control systems but also proffered proactive recommendations for fortifying forthcoming control systems.Diverging from prior surveys, our work introduced precise classifications for vulnerabilities, attack types, and security detection strategies.Regarding vulnerabilities in PLCs, our analysis scrutinized facets such as programming, memory management, and firmware integrity.Furthermore, we analyzed application software, communication protocols, and interconnected industrial devices.Categorically classifying attacks, we identified three major domains: attacks aimed at compromising system availability, tampering with data integrity, and breaching data confidentiality.Subsequently, we presented a range of security detection methods, each offering distinctive detection capabilities.These methods were broadly categorized as program detection, firmware analysis, device fingerprint-based identification, intrusion detection, and honeypot-based monitoring.Overall, our work concludes with actionable recommendations directed toward the research and industry community, aimed at enhancing the security posture of future control systems built upon PLC foundations.

FIGURE 1 .
FIGURE 1. Number of advisories reported to ICS-CERT by year.

FIGURE 2 .
FIGURE 2. Article structure diagram: Boxes in blue refer to main sections, boxes in gray refer to topics discussed in previous surveys, and boxes in orange refer to our contributions in this article.

FIGURE 5 .
FIGURE 5. Classification of PLC-and system-level vulnerabilities.

Fig. 6
Fig.6depicts this attack scenario.The validation process for firmware updates lacks robust security measures, making it susceptible to unauthorized adversaries who can modify the firmware with malicious code.This type of attack involves the adversaries downloading a re-signed firmware containing the malicious code and then injecting it into the PLC to create a hidden backdoor.The consequences of such attacks can be catastrophic, leading to significant failures and severe consequences.To exploit PLC firmware vulnerabilities, attackers typically employ reverse engineering techniques to infer the firmware update validation method.They analyze this method to find weaknesses that facilitate firmware modification and counterfeiting.By exploiting these weaknesses, attackers create a counterfeit firmware sample with malicious code, which they upload and execute on the target PLC.Basnight et al.[51] noted that to modify a firmware, attackers need to apply reverse engineering techniques on the binary firmware to obtain certain functions through disassembly.Detecting and verifying a malicious firmware running on PLCs proved challenging, making PLC firmware modification a stealthy and hard-to-detect threat.Garcia et al.[54] developed a PLC rootkit, called Harvey, designed to exploit power grid systems.This rootkit infected the firmware of PLCs, allowing it to tamper with all the inputs and outputs of the PLCs in an arbitrary manner.Another research group[52] investigated the functionality of firmware upgrades and updates supported by PLCs.They demonstrated a firmware modification attack scenario against Koyo and Rockwell Automation PLCs, showing how malicious firmware could be uploaded into the Ethernet cards of these field devices.

FIGURE 14 .
FIGURE 14. Classification of existing security solutions for PLC-based systems.

FIGURE 15 .
FIGURE 15.Classification the security solutions challenges for PLC-based systems.