# A Digital Twin-Based Approach for Detecting Cyber-Physical Attacks in ICS Using Knowledge Discovery
## 5 Methodology
### 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.  
Figure 6: A screenshot of the process model extracted by Heuristics Miner from the baseline event log.  
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)=\frac{|\{t\in L\mid M(t)\}|}{|L|}\]  
where \(M(t)\) 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\max_{M}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^{*}\):  
\[\
eg M^{*}(t^{\prime}).\]  
Then, the set of anomalous traces in the log \(L\) is  
\[\{t^{\prime}\in L\mid\
eg M^{*}(t^{\prime})\}.\]  
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.