A Digital Twin-Based Approach for Detecting Cyber–Physical Attacks in ICS Using Knowledge Discovery

Abstract

The integration and automation of industrial processes has brought significant gains in efficiency and productivity but also elevated cybersecurity risks, especially in the process industry. This paper introduces a methodology utilizing process mining and digital twins to enhance anomaly detection in Industrial Control Systems (ICS). By converting raw device logs into event logs, we uncover patterns and anomalies indicative of cyberattacks even when such attacks are masked by normal operational data. We present a detailed case study replicating an industrial process to demonstrate the practical application of our approach. Experimental results confirm the effectiveness of our method in identifying cyber–physical attacks within a realistic industrial setting.

1. Introduction

The rapid digitalization and interconnection of industrial processes has significantly boosted efficiency and productivity. However, such advancement also introduces increased cybersecurity risks, particularly in the process industry, which is crucial to global supply chains and public health.

To mitigate these risks, industry standards such as ISO/IEC 27001 [1] and frameworks such as the NIST Cybersecurity Framework [2] emphasize the importance of a multilayered strategy [3,4] involving continuous monitoring and responsive actions.

Despite these guidelines, current cybersecurity and reliability techniques often lack the flexibility to adapt to new and emerging threats [5]. These techniques can struggle with early detection, especially in complex systems, where software bugs, device malfunctions [6], flawed security policies [7], and human error introduce significant vulnerabilities [8,9].

This paper addresses these challenges by exploring the application of process mining techniques to monitor ICS event logs and detect anomalies even when such attacks are masked by normal operational data. We propose a novel methodology that leverages digital twins and process mining to uncover cyberattacks, providing a robust tool for security operators to understand and prevent potential impacts on industrial assets. Our approach not only enhances existing cybersecurity measures but also introduces a practical solution for real-time threat detection in industrial environments.

1.1. Contributions

The main contributions of this work can be summarized as follows:

• We provide a novel methodology for structuring the data produced by the digital twin into an event log suitable for process mining activities. This methodology includes a sequence-based formalization that facilitates the conversion of raw device logs into event logs, enabling the discovery of normal behavioral patterns and anomalies indicative of cyberattacks targeting ICS devices.
• We present a realistic case study that replicates an industrial process through the use of digital twins to create a controlled and monitored environment for safely executing and analyzing cyberattacks without impacting real-world systems. By integrating process mining techniques, we generate event logs from these simulated attacks, allowing for systematic anomaly detection.
• We conduct an experimental assessment of our proposed approach. The results show that our method effectively detects anomalies associated with cyber–physical attacks while maintaining a high detection rate in spite of attempts to mask attacks with benign data, thereby validating its robustness and effectiveness in a realistic industrial setting.

1.2. Outline

The remainder of this paper is organized as follows: Section 2 provides background relevant to this work; Section 3 discusses related work; Section 4 describes the case study which serves as a running example throughout the paper; Section 5 presents our methodology; and Section 6 reports our experimental evaluation. Finally, we present our conclusions in Section 7.

2. Background

In this section, we recall the relevant concepts necessary to correctly understand this paper.

2.1. Digital Twins in Cybersecurity

A digital twins is a virtual representation of any real-world asset (e.g., system or process) [10]. Historically, the idea behind the development of digital twins has been to monitor and manage the performance of physical systems in the context of Industry 4.0 and smart manufacturing. Construction of a digital twin for a physical item involves three key aspects: (1) identifying the components and parameters of the physical product in its real environment; (2) establishing a link between the physical and virtual versions of the product; and (3) integrating data and information to bridge the virtual and real worlds [11].

In the context of cybersecurity, digital twin applications have become increasingly significant [12]. For instance, they can be integrated with cyber ranges to analyze system behavior under different cyberattack scenarios. Indeed, digital twins can be used in attack emulations and simulations to evaluate resilience metrics, ultimately aiding in the design of security and safety mechanisms for cyber (physical) systems. This aspect is crucial for testing and refining security measures in a controlled risk-free environment before deploying them in real-world systems.

Notably, digital twins can also act effectively as honeypots, providing an early detection system for uncovering external and internal attack vectors within a network [3]. The advantage of using a digital twin as a honeypot is its ability to enhance both the level of interaction and the attraction of the “twin” [4].

In this work, we leverage the concept of digital twins to safely execute and study known attacks as well as to develop and test variants without impacting actual operational systems. This not only preserves the integrity and availability of the real system but also provides a more comprehensive understanding of potential vulnerabilities and attack vectors.

2.2. Programmable Logic Controllers and Operational Cycles

Programmable Logic Controllers (PLCs) are specialized digital systems designed for use in industrial environments. PLCs must conform to the IEC 61131 standard [13]. Central to a PLC is the CPU, which executes the user-defined logic program, manages the system’s operational cycle, and interfaces with peripheral devices.

The operational cycle of a PLC is a repetitive sequence controlled by the CPU. This cycle begins with scanning and interpreting input data, processing the data according to the user-defined program, and then updating outputs to control the industrial process. The user program is stored in programmable memory, while temporary data are held during execution. This three-phase cycle, known as the scan cycle, comprises the following steps: (1) reading inputs, (2) processing the inputs, and (3) writing outputs.

2.3. Modbus

Modbus [14] is an industrial protocol used to operate across various communication platforms, including satellite, telephone, and radio technologies, and is not restricted to the proprietary technology of any single manufacturer. It supports two fundamental modes of communication: (i) a query/response mode facilitating interactions between a master and a slave device, and (ii) a broadcast mode enabling a master device to communicate with all slave devices simultaneously. Modbus assigns temporary storage in PLC programs to four distinct register types: discrete output coils, discrete input contacts, analog input registers, and analog output holding registers. Both coils and discrete inputs utilize single-bit registers, whereas input and holding registers employ 16-bit registers. The latter can also be aggregated to form larger memory registers such as 32- or 64-bit registers. Operations involving these registers are controlled by function codes, which define read/write capabilities for coil and holding registers while limiting discrete and input registers to read-only activities. A Modbus operation comprises a single query, response, or broadcast message. The structure of a Modbus message includes the recipient’s address, the instructions to be executed, and the necessary data for execution. In the context of Modbus/TCP [15], a Modbus message is encapsulated within a TCP packet, with Modbus TCP/IP devices monitoring and accepting data through port 502. It should be noted that the Modbus/TCP protocol does not include any cybersecurity protection mechanisms.

2.4. Process Mining

Process mining is a data mining technique that allows organizations to improve their business processes by analyzing data from event logs that are made available by today’s information systems [16]. Event logs are records of all the activities that have been carried out within a system. By analyzing these event logs, traditional industries, organizations, and companies specialized in the production of software can identify bottlenecks and inefficiencies in their processes and take steps to improve them.

Process discovery is a prominent task in process mining involving the derivation of process models from data captured during the execution of real-world processes. The main of process discovery goal is to analyze event logs in order to extract structures, control flows, and characteristic paths that accurately represent the actual processes. These event logs are crucial, as they provide the concrete evidence necessary to map the real-world process executions to the theoretical models originally conceived for these processes.

Numerous techniques for process model discovery can be found in the literature, mainly differing in terms of their modeling language. For example, in [17,18,19] a simple directed graph was used to model the process; other works have adopted much more expressive specification languages, ranging from the use of tree-structured [20] or block-structured workflow models [21,22] to the use of special classes of Petri nets [23,24]. Despite the considerable variety and differences among process discovery approaches, they share a common denominator in the definition of techniques for discovering causal relationships between process activities, known as the problem of dependency-graph mining.

2.5. Process Logs and Models

Below, we introduce foundational definitions and notation related to process logs and models.

Definition 1.

Let $\mathcal{A}$ be an alphabet of symbols that uniquely identifies the activities of some underlying process. An activity $a\in \mathcal{A}$ is characterized as a discrete action or task that constitutes a single identifiable component of the process under investigation.

Definition 2.

A trace (or process instance) is a finite sequence of activities $a_1,a_2,\dots ,a_n\in \mathcal{A}$ (where $n\ge 1$) that captures the execution path of a single enactment of the process from start to end. The sequence reflects the order in which activities are executed; it embodies the process flow, including the dependencies and sequence of activities. Each trace represents a unique instance of the process execution.

Definition 3.

An event log is a collection of traces, denoted as $\mathcal{L}$, over the alphabet $\mathcal{A}$. Each trace in the event log records the sequence of activities for a single execution of the process. The event log is structured to include essential attributes such as timestamps, trace identifiers, and activity names, all of which are vital for identifying normal or anomalous behaviors within the system.

2.5.1. Petri Nets

A Petri net is a mathematical modeling language used for describing distributed systems and their processes. Petri nets are composed of two types of nodes, namely, places and transitions. Places represent conditions or states, while transitions represent events that may change the state. Directed arcs connect places to transitions (and vice versa), dictating the flow of control in the system.

Definition 4.

Formally, a Petri net is a tuple $PN=(P,T,F)$, where:

• P is a finite set of places,
• T is a finite set of transitions (disjoint from P),
• $F\subseteq (P\times T)\cup (T\times P)$ is the set of directed arcs, indicating how places and transitions are connected.

Petri nets are particularly well suited for modeling concurrent, parallel, and synchronized activities within a workflow process. They allow for the discovery of causal relationships and control flows that can be derived from event logs.

2.5.2. Workflow Net (WF-Net)

A workflow net (WF-net) is a specialized form of Petri net tailored specifically for representing workflow processes. Workflow nets have a defined start place (source) and end place (sink), ensuring that every process has a clearly defined beginning and end. A key property of WF-nets is their ability to represent complex business processes that follow a structured and often hierarchical flow, making them useful for business process analysis and improvement.

Definition 5.

Formally, a WF-net is a Petri net $WF=(P,T,F)$ with the following additional properties:

• There is a single source place $i\in P$ such that for any transition $t\in T$ there is a directed path from i to t.
• There is a single sink place $o\in P$ such that for any transition $t\in T$ there is a directed path from t to o.
• Every node (place or transition) is on a path from i to o.

2.5.3. Dependency Graphs

Definition 6.

A dependency graph is a directed graph $\mathcal{G}=(V,E)$ over the set of activities $\mathcal{A}$, where $V\subseteq \mathcal{A}$ and $E\subseteq V\times V$ are edges that encode causal relationships between the activities. The set V includes two distinguished activities: the initial activity $a_{\perp }$, and the final activity $a_{\top }$, such that every other activity in V is reachable from $a_{\perp }$, and $a_{\top }$ is reachable from every other activity. Each activity $a\in V\setminus \{a_{\perp },a_{\top }\}$ must occur along some path from $a_{\perp }$ to $a_{\top }$. Additionally, for all edges $(a_x,a_y)\in E$ it must hold that $a_x\ne a_{\top }$ and $a_y\ne a_{\perp }$.

2.5.4. Process Discovery and Background Knowledge

Because many dependency graphs can in principle be associated with a given log by process mining algorithms, expert background knowledge plays an essential role in identifying the particular graph among those graphs modeling the data that best fits the needs and specifications of the process. Given the focus of this paper, a hybrid approach to process mining is particularly useful when the log in question is incomplete, i.e., when not all possible behaviors of a process have been recorded. In such cases, expert background knowledge can compensate for a lack of data during mining activities. This knowledge can be expressed in the form of precedence constraints over the graph topology. Precedence constraints define the order in which activities should occur in a process, and can be either positive or negative. Positive constraints take one of two forms: an arc constraint $S\to a$, indicating that a set of activities S must directly precede activity a, or a path constraint $S⇝a$, indicating that a set of activities S must precede activity a, though not necessarily directly. A negative constraint is the negation of a positive constraint, meaning that certain activities or paths must not precede others.

3. Related Work

Recent advancements in intrusion detection systems for ICS have increasingly leveraged knowledge discovery techniques to identify physics-aware attacks, which exploit the physical processes governing these networks [25,26]. Although several IDS solutions targeting industrial protocols have been proposed, including those targeting Modbus/TCP in particular [27,28], their real-world implementation remains limited. This is primarily due to their false positive rates, which compel users to lower their security posture in order to cope with the overwhelming number of alarms. Research in this domain can be broadly categorized into three main approaches for intrusion detection: behavior-based, machine learning-based, and process mining-based systems.

(a) Behavior-based: The approach proposed in [29,30,31] focuses on the typical patterns and behaviors of ICS networks to detect anomalies and potential attacks. By establishing a baseline of normal operations, deviations from this baseline can indicate malicious activities. This approach primarily focuses on detecting out-of-bound values or deviations from historical behavior. However, it falls short of capturing the full sequence of events and interactions within the process, providing only a limited perspective on such incidents.

(b) Machine learning-based: Machine learning techniques such as those in [32,33,34] can be employed to enhance the detection capabilities of IDS by learning from historical data and identifying complex patterns that may indicate an attack. The major advantage of these systems is their potential to detect previously unseen attacks and address zero-day vulnerabilities. Nonetheless, these systems frequently produce a significant number of false positives and false negatives, reducing their practical reliability.

(c) Process mining-based: There have been several examples of the use of process mining within a security context [35,36]. The first documented application of process mining in the field of security was introduced by [35], who proposed the use of process mining to detect anomalous process executions. Recent research has begun to explore the potential of process mining for enhancing the security of ICS. As proposed by [37,38], process mining involves understanding the sequence and dependencies of events within the system through logs and conformance checking analysis. This detailed examination allows for anomaly detection via process mining-based IDS by identifying inconsistencies between the expected process model and actual system behavior. However, unlike our methodology these approaches do not incorporate background knowledge to reduce issues arising from noisy logs, which may impact the anomaly detection task. In addition to process mining-based techniques, process-oriented methods have also been explored for intrusion detection. In [26,39], these methods were discussed in the context of monitoring critical process variables. Colbert et al. [39] focused on leveraging the expertise of control system operators to generate alerts based on critical sensor readings such as device temperatures. Similarly, Nivethan and Papa [26] applied process-oriented techniques in SCADA networks, utilizing process semantics to identify anomalies in process variables. However, directly implementing these methodologies in real systems may unintentionally disrupt normal operations, trigger false alarms, or even create vulnerabilities if not carefully managed. These risks highlight the need for extensive testing and validation of such approaches in controlled environments such as those provided by digital twins.

4. Case Study

To accurately replicate the environment of the industrial food processing plant within our digital twin, we have developed a system that mirrors real-world operations in a virtual space, as showcased in Figure 1.

The digital twin is a virtual model of the food processing plant, with all containerized PLCs connected to a simulation of the physical processes. Each PLC in the physical plant was replicated in a Docker container by cloning the PLC logic into Python scripts, which were then interconnected using the pyModbus library [40]. This containerization allowed for isolation and portability, facilitating the replication of the PLC’s behaviour in the virtual environment. The containers were configured to expose their Modbus interfaces to enable communication with the different components. These PLCs were connected to a virtual model of the food processing plant developed in Python by modeling physical components such as the mixing tank, sensors, and actuators. The model was designed to accurately replicate the behavior and interactions of these components, ensuring that the digital twin’s operations closely mirrored those of the real plant. This simulation environment was continuously synchronized with the actual plant through a proxy system. The proxy was positioned between the real hardware PLCs and the physical plant, transparently forwarding all Modbus traffic from the PLCs to the real plant. When a write operation is detected, the corresponding command is transmitted by the proxy to the replicated physical container connected to the digital twin, ensuring that both the virtual and physical systems remain in a consistent state. This setup allows an accurate model of the real plant to be maintained without directly interfering in its operations.

Our case study explores an industrial food processing plant for preparing and bottling pesto sauce. The process is divided into three stages: (a) a loading phase (Figure 2a) in which all the ingredients are loaded into the mixer according to specific dosages; (b) a mixing phase (Figure 2b) during which the heating element and blade are turned on to properly mix the ingredients; and (c) a bottling and packaging phase (Figure 2c) in which the product is inserted into bottles, packaged into boxes, labeled, and set aside to be shipped. For the sake of simplicity, we focus on stages (a) and (b).

In the first phase, the ingredients are initially prepared and weighed. Portioning takes place via three weighing funnels for olive oil, garlic, and basil, each fed by a speed-controllable screw valve (for the liquids) or a belt (for the garlic). Each funnel is controlled by a PLC and includes a load cell to sense the current amount of ingredients held within.

The second phase is overlooked by the mixing-PLC; the system comprises a mixing tank that blends and processes the pesto sauce. This mixer is equipped with sensors monitoring its level and temperature as well as controls for adjusting the temperature. Another setpoint commands the drainage of the tank contents towards the bottling and packaging zone.

The packaging phase features a controllable speed belt that is loaded with pesto containers at regular intervals.

The measurements and setpoints are exposed via Modbus over port 502/TCP.

Table 1. Modbus registers of the different PLCs.

PLC	Register Address	Description
oil-PLC	IW0	Speed of the screw valve (measurements in m/s).
	IW1	Load cell (measurements in kg).
	QX00	Valve actuator that allows the content of the funnel to flow into the mixer (ON/OFF).
garlic-PLC	IW0	Speed of the screw valve (measurements in m/s).
	IW1	Load cell (measurements in kg).
	QX00	Valve actuator that allows the content of the funnel to flow into the mixer (ON/OFF).
basil-PLC	IW0	Speed of the screw valve (measurements in m/s).
	IW1	Load cell (measurements in kg).
	QX00	Valve actuator that allows the content of the funnel to flow into the mixer (ON/OFF).
mixer-PLC	IW0	Level content of the mixing tank (measurements in litres).
	IW1	Speed of the stirring blade (measurements in rpm).
	IW2	Temperature (measurements in °C).
	MW0	Target RPM (measurements in rpm).
	QX00	Valve actuator that opens the drain of the mixing tank to allow the content to flow into the bottling bay (ON/OFF).
	QX01	Heater actuator that energizes the heating elements to cook the mixture (ON/OFF).

summarizes the PLCs and their corresponding registers, detailing the type, address, and kind along with a short explanation for each entry.

The production cycle for pesto lasts approximately 17 min and is composed of nine distinct steps. This process begins with the loading and grinding of basil, followed by the incorporation of garlic and olive oil, and concluding with mixing, cooling, and packaging. Each step from ingredient loading to the final bottling is meticulously controlled by the corresponding PLC to ensure the highest quality of the final product.

• Basil loading. The screw pump linked to the basil funnel activates and runs until the funnel load cell detects a minimum of 100 kg of basil. Upon reaching this threshold, the screw pump stops and the funnel opens, adding its contents to the mixer.
• Initial grinding. The mixer begins to stir the mixture at 20 rpm while simultaneously grinding the basil into a fine paste. This process is maintained until the mixture reaches a consistency suitable for pesto, typically around 5 min.
• Garlic loading. The mixer temperature is adjusted to 50 °C and its speed is reduced to 2.5 rpm. Simultaneously, the garlic belt feeder is engaged until its weight sensor indicates it has reached 50 kg of garlic, which is then added to the mixture.
• Basil and garlic grinding. The mixer temperature is raised to 64 °C and its speed is further reduced to 1.5 rpm. The mixture is stirred for 6 min to ensure thorough incorporation of the basil and garlic.
• Olive oil loading. The olive oil pump is activated until the funnel measures 50 kg, then the additional oil is added to the mixture.
• Final mixing. The mixture is cooled to 20 °C and slowly stirred at 1.5 rpm for 5 min to ensure a uniform consistency.
• Cooldown. The mixer heating element is turned off until the mixture temperature has settled at 20 °C or below.
• Draining to bottling zone. The mixing tank drain valve is opened, and its contents are transferred into the filling machine funnel.
• Packaging. The packaging zone belt is started and runs at a constant speed. As soon as a container reaches the start of the sanitation area photocell, the coordinator activates the sanitizing steam jets and deactivates them when the container triggers the photocell’s end. A similar process occurs for the filling tube, with its entry and exit photocells initiating and concluding the procedure. This process repeats until the funnel load cell indicates sufficient container material.

5. Methodology

In this section, we present our method for identifying physics-aware attacks on ICSs, inspired by the approach proposed in [41]. The methodology comprises four stages: (i) information gathering, (ii) data preprocessing, (iii) model discovery, and (iv) anomaly detection. Figure 3 illustrates the various phases of our approach, delineating the tasks undertaken at each stage.

5.1. Information Gathering

5.1.1. Register Identification and Data Types

The initial step involves enumerating registers to identify (i) discrete input contacts and analog input registers (which may contain current measurements of physical variables) and (ii) discrete output coils and analog output holding registers (which may contain actuator commands). This task aims to compile a list of actively utilized registers and their corresponding data types (Boolean or numerical values). By scanning the Modbus address range, we map out the registers in use and identify those that respond to queries. It should be noted that certain registers may appear active even if their values never change; these are filtered out in subsequent stages. It should be noted that the underlying principle of our solution is based on querying the system for process-related data, regardless of the specific communication protocol used; for example, whether the system employs Modbus, DNP3, OPC UA, or another protocol, the critical aspect is the ability to access the PLCs and collect data from them. Figure 4 illustrates the values recorded over six hours for each register of the mixer PLC. This task ends by discovering the data type of the different registers (see Table 1).

5.1.2. Data Collection

Device logs are collected from the identified registers within the SCADA system, which is configured to operate in a cyclic acquisition mode. This configuration logs data at regular intervals, providing detailed monitoring of the system’s state changes and capturing all relevant activities, even those not directly observable as events.

Each log entry is timestamped and includes the current values of all identified registers. These entries capture the state of the system at each time point, providing a detailed view of the system’s operation.

5.2. Data Preprocessing

In this stage, we convert the raw device logs into an event log suitable for process mining analysis. This transformation is necessary in order to derive meaningful insights into the system’s behavior and detect anomalies through the process traces. The following sections provide the theoretical foundations and design specifications of our framework, which is aimed at the detection and analysis of anomalous traces within process event logs.

We represent the behavior of a SCADA device using sequences of state transitions driven by changes in register values. Instead of focusing on individual entries, our approach emphasizes state transitions to identify significant events.

A state s is defined as a vector of register values at a specific timestamp. Let $\mathcal{R}$ denote the set of all registers. A state at time t is represented as

$$s\left(t\right)=\{(r_i,v_i\left(t\right))\mid r_i\in \mathcal{R},v_i\left(t\right)\in {\mathcal{W}}_{r_i}\},$$

where $r_i$ is the register and $v_i\left(t\right)$ is the value of the register $r_i$ at time t.

A state transition occurs when there is a change in the value of one or more registers between two consecutive timestamps. To account for insignificant changes, we introduce a threshold ${\delta }_{r_i}$ for each numerical register $r_i$. Formally, a state transition from time $t_1$ to $t_2$ is defined as

$$\Delta s(t_1,t_2)=\{(r_i,v_i\left(t_1\right),v_i\left(t_2\right))\mid r_i\in \mathcal{R},|v_i\left(t_1\right)-v_i\left(t_2\right)|>{\delta }_{r_i}\},$$

where ${\delta }_{r_i}$ is a predefined threshold for the register $r_i$. This guarantees that only significant changes are taken into account as state transitions.

Events are derived from significant state transitions. A transition is considered significant if it involves a change in key registers identified through domain knowledge.

Table 2. Example of state transitions in the event log.

Timestamp	Register	Previous Value	Current Value
$t_1$	$r_1$	$v_1\left(t_0\right)$	$v_1\left(t_1\right)$
$t_2$	$r_2$	$v_2\left(t_1\right)$	$v_2\left(t_2\right)$
…	…	…	…

illustrates an example of a state transitions device log.

Data Filtering and Event Log Generation

In process mining, event logs are organized into traces, each representing a sequence of tasks performed over several enactments of a process [42]. However, a device log from an ICS/SCADA system typically lacks direct information about trace identification [37]. Therefore, it is crucial to establish what constitutes a trace.

To convert the raw device log into an event log, we apply the following steps:

• Transition Analysis: For each identified register $r_i$, we monitor changes in its value over time. An event is generated whenever $v_i\left(t\right)$ changes significantly, i.e., $|v_i\left(t_1\right)-v_i\left(t_2\right)|>{\delta }_{r_i}$, capturing the nature of the change (increase, decrease, on, off, etc.). An event is represented as a tuple $e=(t,r_i,v_i\left(t_1\right),v_i\left(t_2\right))$, where t is the timestamp of the transition. The set of all possible events is denoted as E.
• Operational Cycle Detection: A cycle-start condition is defined based on specific register values. A new cycle begins when a particular register $r_s$ changes to a predefined value $v_s$. This condition is derived from domain knowledge and splits data into operational cycles.
• Trace Grouping: Events are organized into traces based on detected operational cycles. Formally, each trace $T_i$ is defined as a sequence of events $\{e_{\mathrm{start}},e_1,e_2,\dots ,e_n,e_{\mathrm{end}}\}$, where $e_{\mathrm{start}}$ and $e_{\mathrm{end}}$ are special marker events indicating the start and end of the cycle, respectively. The start of a trace is marked by the cycle-start condition, while the end of a trace is marked by the start of the next cycle or a predefined cycle-end condition.

The final event log is built by aggregating all detected traces. Each record in the event log includes attributes such as timestamp, trace identifier, and activity name (which is derived from the register name and the nature of the state transition); for instance:

• If a numerical register $r_i$ increases from $v_i\left(t_1\right)$ to $v_i\left(t_2\right)$, the activity name is $r_i\_Ascending$.
• Else, if a numerical register $r_i$ decreases from $v_i\left(t_1\right)$ to $v_i\left(t_2\right)$, the activity name is $r_i\_Descending$.
• Else, if a Boolean register $r_i$ changes from True to False, the activity name is $r_i\_True\to False$.
• Else, a Boolean register $r_i$ changes from False to True, the activity name is $r_i\_False\to True$.

Starting from the initial raw data in

Table 3. A portion of the initial raw device log.

Timestamp	Register	Previous Value	Current Value
18:30:30	IW0	0.0	5.0
18:30:30	IW1	0.0	10.0
18:30:30	IW2	20.0	15.0
18:30:30	MW0	0.0	3.0
18:30:30	QX00	True	False
18:30:30	QX01	True	False

, we apply the definitions and procedures described above to generate an event log that captures the behavior of the mixer PLC under standard operational conditions. An excerpt of this log is shown in

Table 4. Excerpt of the final event log derived from the initial raw data.

Timestamp	Trace ID	Activity
18:30:30	1	IW0_Ascending
18:30:30	1	IW1_Ascending
18:30:30	1	IW2_Descending
18:30:30	1	MW0_Ascending
18:30:30	1	QX00_True→False
18:30:30	1	QX01_True→False

.

5.3. Process Discovery

As discussed in Section 2, a fundamental process mining task is process discovery; given a log L, the aim is to construct a process model that supports its traces. Computing a process model which satisfies precedence constraints defined by the expert is a problem that has been shown to be intractable in general.

Theorem 1

(cf. [42]). If $\notin S$, then computing a dependency graph for a log L that satisfies the constraints in S is in $\mathrm{P}$; otherwise, the problem is $\mathrm{NP}$-hard.

Figure 5 illustrates the a priori known process model for our case study using Business Process Modeling Notation (BPMN). This model is constructed by leveraging available a priori domain knowledge on interactivity dependencies.

The process begins when the ingredients are added to the mixing tank, causing the level register value (IW0) to rise. This increase triggers an adjustment in the stirring blade speed (IW1) and activates the heating element (QX00), resulting in a rise in the temperature (IW2). Subsequently, the valve actuator (QX00) is engaged to drain the tank into the bottling bay. As the process progresses, the system transitions to a descending phase, characterized by a reduction in both temperature and stirring speed.

In contrast, Figure 6 depicts the process model generated by Heuristics Miner algorithm [43] directly from the data generated in our case study.

Although the model can derive a (conceptual) process model representing how the data “flow” over the registers, it fails to capture a comprehensive representation of certain events, such as the change in the QX00 actuator. Additionally, the model includes wrong edges, i.e., connecting states that should not be linked, which further complicates the accurate depiction of the process

We finish this section by pointing out that a properly refined process model describing the expected behavior is crucial in specific application contexts, including anomaly detection.

5.4. Anomaly Detection

There are various interpretations of what constitutes an anomaly. An anomaly may manifest as an exceptional execution, noise in the log (potentially due to system failures or data input errors), or a cyberattack. An exception denotes an abnormal or atypical execution that can be tolerated by the system; in contrast, cyberattacks or operational errors represent irregular executions that result in undesirable outcomes from a system perspective. Despite these differing interpretations, common generic definitions of an anomaly include (i) a rare event, (ii) a deviation from a standard form or rule, (iii) an unexpected outcome, or (iv) a state beyond the usual range of variations.

To formalize the detection of anomalies in the context of ICS/SCADA systems, we adopt a model-based approach inspired by [44]. We first define the necessary concepts of logs, models, and support, then utilize these to formalize the identification of anomalous traces.

A log L is a collection of traces, where each trace $T_i$ represents a sequence of events within an operational cycle. A model M is constructed to represent the normal behavior of the system, capturing the typical sequences of events.

We select a model $M^{*}$ from the set of models that support the log; the chosen model should have the best fitness for the baseline log, i.e., the log capturing the normal behavior of the process. The fitness function considers factors such as the number of traces that conform to the model and the deviations observed, providing a quantitative measure of the model’s accuracy in representing the system’s normal operation. The fitness function f for a model M and log L is defined as follows:

$$f(M,L)={\displaystyle \frac{\left|\right\{t\in L\mid M\left(t\right)\left\}\right|}{\left|L\right|}}$$

where $M\left(t\right)$ indicates that the trace t is supported by the model M. The model $M^{*}$ is then defined as the model that maximizes the fitness function

$$M^{*}=arg\underset{M}{max}f(M,L).$$

Given this model $M^{*}$, we define an anomalous trace $t^{\prime }\in L$ as a trace that is not supported by $M^{*}$:

$$\neg M^{*}\left(t^{\prime }\right).$$

Then, the set of anomalous traces in the log L is

$$\{t^{\prime }\in L\mid \neg M^{*}\left(t^{\prime }\right)\}.$$

This formalization allows us to systematically identify traces that deviate from the established model of normal behavior, which can then be further analyzed for potential anomalies such as cyberattacks or operational errors.

To further clarify the anomaly detection task, we note that the detection process follows a model-based approach that leverages conformance checking to identify deviations. Specifically, we compare event logs generated during the system’s operation against the expected behavior represented by the process model. The detection process systematically flags traces that deviate from this model as anomalies. For additional clarity, the detection process can be outlined as follows:

• Generate the event log from system operations.
• Construct or select a process model $M^{*}$ representing normal behavior, ensuring high fitness for the baseline log.
• For each trace t in the log, verify whether $M^{*}$ supports t.
• If $M^{*}$ does not support t, then the trace is flagged as anomalous.

6. Experimental Evaluation

This section presents the experimental evaluation of our proposed process mining-based methodology for detecting physics-aware attacks on ICS, specifically focusing on the case study presented in Section 4. The evaluation was designed to assess the effectiveness of our approach in detecting anomalous behavior due to cyberattacks. For simplicity’s sake, only the data from the mixer PLC were taken into account, although the entire system was deployed and operational. While our attacks had consequences on the connected PLCs, these effects are in this evaluation.

6.1. Experiment Settings

To support the experimental environment, a dedicated Lenovo ThinkPad T480 laptop configured with an Intel Core i5 processor, 16 GB RAM, and a 256 GB SSD was provisioned. The system was equipped with Podman, a daemonless containerization platform, to manage the four Python-based PLC containers and the Python-based physics simulation, which also ran in a dedicated container.

As shown in Figure 7, all the PLCs were free to communicate with one another over the Modbus protocol on the network, while the physical plant fed data directly into the PLC, remaining transparent to the attacker.

6.2. Dataset

The dataset was collected over 2 h during four operation cycles, and was compiled into an event log by applying the methodology described above. In particular, we obtained a log over 11 activities and 2909 traces. The total number of events recorded in the logs was 10,782.

6.3. Results

In our experimental evaluation, we drew inspiration from the work of Lupia et al. [45]. Specifically, we benchmarked several state-of-the-art process discovery algorithms against the resulting baseline event log in order to assess the behavior of the Mixer PLC contained in the log and determine how well it matches the models produced by different methods. The considered methods were Heuristics Miner, Inductive Miner [46], ILP Miner [47], and DGMining with background knowledge [45]. We leveraged the PM4Py [48] library for their implementation. To ensure consistency, default configurations were applied across all methods.

6.3.1. Comparative Analysis

To compare the quality of the models produced by these methods, we focused on the fitness [49] “log-conformance” metric, as it primarily influences the anomaly detection task. Note that this metric spans the interval $[0,1]$ and is traditionally defined for Petri net models.

Table 5. Comparison between different process mining models used in the paper.

Model	Fitness
IM	1.0
ILP	1.0
HM	0.85
DG-Mining	1.0

summarizes the performance of each method concerning the fitness metric.

Eventually, we selected the DGMining [45] algorithm due to its good performance in terms of computation time and capability to incorporate domain knowledge in the form of precedence constraints over the activities. This capability is particularly useful in scenarios where log noise is a challenge; refer to the work by Greco et al. [42] for a detailed discussion on this topic.

Figure 8 illustrates the (true) model derived by DGMining using background knowledge extracted from the as-is model (see also Figure 5).

6.3.2. Anomaly Detection Analysis

In this section, we turn our attention to the anomaly detection task. The anomaly data were produced by executing two distinct attacks, both targeting the mixer PLC. For simplicity, we assume that in each scenario the attacker is on the same network as the PLC and has direct access to it, enabling unrestricted traffic flow across the network.

Attack 1: DoS Attack on Heating Coil

In this scenario, the attacker’s goal is to sabotage the pesto sauce production process by overheating the sauce, thereby ruining the entire batch. The pesto sauce is normally heated to 64.0 °C. When register IW2, which holds the temperature value, reaches this set point, the heating element is turned off by setting coil QX01 to false. The temperature is then maintained at 64.0 °C for approximately 10 min by toggling the coil to true as needed. After this period, coil QX01 is set to false definitively, allowing the temperature to drop. The attacker monitors register IW2 and initiates the attack when the temperature reaches 64 °C. The attacker continuously sends Modbus packets with function code to write a single discrete output coil QX05 on port 502/TCP, instructing the mixer PLC to keep the heating element on (setting QX01 to true). As shown in Figure 9, the temperature exceeds 100 °C. Consequently, this elevated temperature leads to the production being ruined.

Attack 2: Production Diversion through Coil Manipulation

Here, the attacker’s objective is to inflict damage to reputation by sending an excess of uncooked and improperly prepared sauce to the bottling phase. The attack begins as soon as the attacker gains access to the network. The attacker then continuously sends Modbus packets with function code to a single discrete output coil QX05 on port 502/TCP, instructing the mixer PLC to keep the drainage valve actuated by coil QX00 open. As shown in Figure 10, the ingredient funnels continually attempt to refill the mixing tank; however, because the drainage valve remains open, all the ingredients are directly routed to the bottling area. Consequently, the bottling area continuously receives raw unprocessed ingredients.

The complete event log produced by the digital twin during the first attack consists of nine activities, 216 traces, and 406 events. Similarly, for Attack 2 the event log comprises five activities, one trace, and 375 events.

Further tests were carried out to more deeply and systematically assess the capability of our method to detect even ‘stealth’ attacks, i.e., a small number of malicious events hidden in a large benign log. In particular, we added varying amounts of benign events to the same attack scenarios; specifically, we increased the size of the two attack logs by different percentages, namely, 50%, 100%, 150%, and 200%. This resulted in attack logs with +50%, +100%, +150%, and +200% additional benign events, respectively.

Table 6. Fitness scores obtained by DGMining for different percentages of events for both cases.

Event %	Attack 1		Attack 2
	Log Size	Fitness	Log Size	Fitness
Initial Log (0)	406	0.549	375	0.0
+50 (benign events)	609	0.563	562	0.369
+100 (benign events)	811	0.579	750	0.385
+150 (benign events)	1014	0.608	937	0.386
+200 (benign events)	1218	0.614	1125	0.396
Avg	811.6	0.582	749.8	0.307

reports the fitness scores obtained by our method against different percentages of benign events added to the attack logs. The fitness score reflects how well the model supports the given log, with higher scores indicating better support.

6.3.3. Discussion

The results demonstrate that our method maintains relatively low fitness scores even as the amount of benign data increases, indicating that the model effectively detects anomalies associated with cyber–physical attacks.

For Attack 1, the gradual increase in fitness scores with added benign events suggests that the method can identify anomalies despite attempts to mask them. Specifically, the fitness score for the initial attack log with no benign events is 0.549, as shown in the third column of Table 6. This score indicates a moderate deviation from normal behavior, reflecting the presence of anomalies due to the attack. When 50% benign events are added, the log size increases to 609 and the fitness score slightly improves to 0.563. The score remains relatively low, suggesting that anomalies are still detectable despite the added benign data. At 200% additional benign events, the log size is 1218 and the fitness score is 0.614. This score suggests that while the model predominantly fits the normal behavior, the anomalies from the attack still impact the overall fitness.

For Attack 2, the fitness score for the initial attack log is 0.0, highlighting the significant deviation caused by the attack, as seen in the last column of Table 6. With 50% benign events added, the log size increases to 562 and the fitness score jumps to 0.369. This significant increase indicates that while the model captures some normal behavior, the anomalies remain prominent. At 200% additional benign events, the log size is 1125 and the fitness score is 0.396. This score indicates that although the model increasingly fits the normal data, the anomalies remain highly detectable.

7. Conclusions and Future Work

In this paper, we have addressed the cybersecurity challenges introduced by the rapid digitalization and interconnection of industrial processes. While recent works have focused on various aspects of cybersecurity in cyber–physical systems, including advances in intrusion detection and response mechanisms, there remains a need to continuously update and refine our approaches to address the evolving threat landscape. Despite industry standards and frameworks advocating for a multilayered strategy, current cybersecurity techniques often fall short in adapting to new and emerging threats. Notable advancements include the integration of machine learning algorithms for predictive threat modeling [50,51] and innovations in anomaly detection methodologies [52]. Incorporating these recent developments into our approach could provide additional layers of security and improve detection accuracy.

We proposed a novel methodology leveraging digital twins and process mining to monitor ICS event logs and detect anomalies even when attacks are masked by normal operational data. Through a realistic case study, we have demonstrated how our solution can effectively detect and analyze potential attacks.

Moreover, we have presented a case study that replicates a realistic industrial process and shown how malicious activities can be detected using our approach. Our experimental assessment confirms the effectiveness of the proposed method, which is able to maintain a high detection rate despite attempts to mask attacks with benign data. The obtained results validate our method’s robustness and effectiveness in a realistic industrial setting.

Our current work focuses primarily on specific types of cyber–physical attacks; however, as cyber threats continue to evolve, it is crucial to consider a broader range of attack vectors. Future research should explore additional types of cyberattacks, including but not limited to the following: (i) Advanced Persistent Threats [53] (APTs) are long-term targeted attacks that can be challenging to detect and may require more sophisticated monitoring and detection techniques; (ii) insider threats consist of attacks or sabotage initiated by individuals with authorized access, and as such can be particularly insidious, requiring strategies tailored to monitor and manage internal risks; (iii) zero-day exploits are unpatched vulnerabilities that attackers can exploit before a fix is available, requiring real-time detection mechanisms to counter; finally (iv) ransomware and malware targeting ICS systems are becoming increasingly sophisticated, necessitating enhanced detection and response strategies. Examples of such attacks include those that study the physical evolution of the system and subtly manipulate it for malicious purposes as well as those that conceal their presence by executing man-in-the-middle attacks and replaying outdated data to present a healthy system state to the human–machine interface (HMI) while covertly damaging the physical process [3]. Additionally, we aim to explore the integration of advanced machine learning techniques and game theory frameworks [54,55] to further enhance the detection and prevention capabilities of our proposed solution.