# Self-Reconfiguration of Industrial Control Systems as a Response to Cyberattacks

Jolahn Vaudey, Stephane Mocanu, Eric Rutten, Gwenaël Delaval

► To cite this version:

Jolahn Vaudey, Stephane Mocanu, Eric Rutten, Gwenaël Delaval. Self-Reconfiguration of Industrial Control Systems as a Response to Cyberattacks. Journal of Network and Systems Management, 34 (1), pp.1-27, 2025, 10.1007/s10922-025-09979-0. http://05299028

HAL Id: hal-05299028

https://inria.hal.science/hal-05299028v1

Submitted on 6 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Self-Reconfiguration of Industrial Control Systems as
a Response to Cyberattacks

Jolahn Vaudey ID 1, Stephane Mocanu ID 1, Eric Rutten ID 1, and Gwenaël Delaval ID 1

¹Univ. Grenoble Alpes, CNRS, Inria, Grenoble INP*, LIG, 38000 Grenoble, France
{firstname.lastname}@inria.fr

October 6, 2025
As industrial control systems become increasingly connected, the threat of cyberattacks grows accordingly. Classical IT reactions that prioritize confidentiality, such as device shutdown or network isolation, cannot be directly applied as they compromise availability, which is critical to keep the system safe. This paper explores the concept of self-reconfiguration in Industrial Control Systems (ICS) as a proactive and reactive defense mechanism against cyberattacks. Recognizing the critical importance of availability in OT environments, we propose a system that, upon detection of a compromised component, dynamically reconfigures itself to maintain functionality. Our approach leverages the increasing virtualization of ICS to migrate tasks from compromised devices to healthy ones, ensuring continued operation while containing the attack. We model the reconfiguration problem using the IEC 62443 standard, representing ICS as a network of zones linked by conduits. We present a system model incorporating security levels, device capacities, application dependencies, and communication constraints. Then, we formulate the task migration as an optimization problem solved via constraint programming. We detail several variations of the base reconfiguration program, including the activation of countermeasures or conduits, and the preemptive allocations of applications instances to host devices with memory size constraints. Our approach is evaluated through a combination of a physical training factory use case and generated problem instances with arbitrary sizes. This evaluation concerns the execution time of the reconfiguration process, as well as the resilience, measured in number of devices attacked before a critical application must be stopped.

# 1 Introduction

## 1.1 Cybersecurity concerns in Industrial Control Systems

Industrial control systems (ICS) consist of an interconnection of hardware and software components controlling a physical industrial process. This is usually orchestrated by a network of Programmable Logic Controllers (PLCs), rugged computers commonly used in the industry. For historical reasons, these systems communicate internally using mostly insecure protocols, such as Modbus, and for a long time this was not an issue as accessing the system required physical on-site presence. However, ICS nowadays are increasingly connected, and this has led to the rise of security concerns and cyberattacks [1]. In turn, due to high profile attacks, especially Stuxnet [2], awareness of these issues has spread, and attack detection, prevention or reaction in ICS are active fields of research. Compared to traditional Information Technologies (IT) systems, Operational technology (OT) ones have different security priorities. Using the terms of the CIA (Confidentiality, Integrity, Availability) triad, while traditional information systems focus on confidentiality, ICS put availability of the system above everything else. Indeed, as a physical process is involved, a lapse in its control can cause dramatic results, causing both financial losses, if the attacker manages to break key components, and potentially ecological or life threatening consequences. To avoid such loss of control, upon attack detection, the system should contain the attack and restore the affected functions.

## 1.2 Reconfiguration

In this paper, we focus on the reaction to attacks on ICS. Specifically, we design systems able to reconfigure themselves while under attack. Traditionally, the first reaction to a compromised component would be to isolate it. For ICS, this would cause major safety issues, as a part of the process would become uncontrolled. Capitalizing on the increased virtualization of ICS [3], we propose to migrate tasks running on compromised components to healthy ones. Thus, our goal is to design a reconfiguration controller, started whenever an intrusion is detected, able to find a new configuration by migrating tasks while maintaining as much functionality as possible. As ICS host machines are mostly PLCs, for which control programs are not programmatically editable without heavy retro-engineering, migrating a program entails :

* Deactivating the program version running on the previous device. Until control is taken over on the next execution location, the corresponding physical process is put into an inactive mode, as outputs fall back to safe values.

* Transferring the state of the program from a pre-intrusion snapshot to the new host PLC.

* Activating the program version on this PLC.

Importantly, the application's code itself must already be stored on the new host PLC. As these devices' memory is limited, allocating these program instances will be discussed later in Section 3.3.
## 1.3 Zone/Conduit model and IEC 62443 standard

The IEC 62443 standard was recently developed to create a security oriented technical specification for industrial automation and control systems. We will only present the first part, which is relevant for this paper [4]. This first document contains the definitions of terms and abbreviations used in the rest of the standard, a description of the current situation in ICS and overall trends, OT cybersecurity concepts, and several models used to represent industrial control systems. We are mostly interested in the Zone/Conduit model, as we will use it to describe instances of ICS.

In this standard's system model, the plant is divided in *zones*. The components within a zone can be physical devices, informational assets, or applications. Applications need to be run on a compatible device, present in the same zone. Components within a zone are assumed to hold similar security requirements. A zone can be physical if the assets share a physical location, or it can be a purely virtual construct. A zone can be considered trusted or untrusted (if it connects to the outside, typically). We will assume that components sharing a zone can communicate freely within the zone's bounds. Each communication between two zones must pass through *conduits*. Zones may be divided in sub-zones, for which security requirements must be at least as strict.

The mentioned security requirements are a vector of seven numbers, ranging each from 0 (no protection) to 4 (protection against attackers with extensive resources and knowledge) and corresponding to *foundational requirements*: Access Control, Use Control, Data Integrity, Data Confidentiality, Restricted Data Flow, Timely Response and Resource Availability. This can be understood as a refinement of the CIA triad for ICS. These security requirements apply to zones, which have a target security level vector, and apply to components (devices and applications), which have a capability security level vector. Zones also have an achieved security level, computed based on the capability of its components (the element-wise minimum), which should always remain above the target. This target security level is decided by conducting a risk assessment on the plant.

Conduits are technically zones, being sets of components sharing a needed security level vector, only wholly dedicated to communications. They are defined by the zones they link. They can be contained within a zone, and cannot contain sub-zones. A conduit typically includes a set of channels, indicating the specific communication links between components. They are compared to cables (channels) within a pipe (conduit) in the standard. Channels are defined by the set of components they link. Conduits can be considered trusted/untrusted by the zones they connect, if their security level is sufficient/insufficient compared to the zone's target level. For now, this has no bearing on the reconfiguration problem.

For zones and conduits to reach their target security level, the passive capability of their components may not be enough. In this case, countermeasures are added to raise the achieved security level. Those can be technical (devices or software), administrative (usage policies) or physical (locked areas). Taking these countermeasures into account, the achieved security level vector of a zone is the element-wise maximum of:

* The element-wise minimum of capabilities of the zone's components (applications and devices).

* The element-wise maximum of capabilities of the zone's countermeasures.

This calculation is illustrated in Figure 1.

<figure><img src="image_2.png" /><figcaption>Figure 1: Achieved security level vector computation.</figcaption></figure>
An example of an Industrial Control System organized following the Zone/Conduit model is illustrated in Figure 2.

<figure><img src="image_3.png" /><figcaption>Figure 2: Example of an ICS following the Zone/Conduit organizational model. This schema is taken from the Cisco Blog.</figcaption></figure>

# 2 Related works

## 2.1 Reaction to attacks or faults

While reconfiguration is not commonly used specifically in ICS security, numerous works apply such techniques to attain specific goals in cyberphysical systems. We will give an overview in increasing order of similarity with our subject. Systems can be repeatedly switched between multiple configurations as a moving target defense ([5, 6, 7]), aiming to prevent attackers from gaining and exploiting knowledge about the control scheme topology. We will discuss these further in a dedicated section, as this is usually more of a preemptive defense technique, but bears heavy similarities with our approach. Reconfiguration is also used to recover from faults in smart grids, for instance by advising new power lines to deploy in [8]. Here, the problem is modeled as a variant of the knapsack problem, and uses Mixed integer linear program solvers. Another paper redistributes control functions over the system to deal with perturbations [9] using constraint programming. This is similar to our approach, but the studied problem is specific to smart grids, and the constraint program only chooses among predetermined configurations.

Another classical answer to compromised components is to isolate them from the network [10], by rerouting the communication flows. Do note that each functionality running on the system must still be maintained. Finally, control reconfiguration in response to attacks has been studied on car systems [7], using predefined backup controllers.

In our case, finding new configuration is modeled as an integer linear programming (ILP) problem, which can also be seen as a constraint programming (CP) problem, with our main decision variables being the
task/device allocations. This is a natural way of expressing optimal resource placement under constraints
in general. These methods have been employed recently to distribute control functions to servers in a smart
grid [9], or in a completely different context to allocate legends to digital highway signs, regulating traffic
in response to an accident [11].

## 2.2 Moving target defense

As briefly stated before, another field of study that relies on system reconfiguration is moving target defense (MTD). MTD is mostly attack prevention, maintaining an active defense at all times to reduce the system's attack surface. This security enhancement is achieved by regularly switching between different system configurations, in a way that is as unpredictable as possible for attackers. The variable elements changing between configurations are different across studies. In [12], an article presenting moving target defense, three main categories of MTD approaches are defined depending on how diversity is obtained. The first approach alters the software implementation, to obtain variations with different vulnerabilities. The second type modifies the execution environment, by migrating tasks across heterogeneous machines or virtual machines (VMs), or by changing their parameters. Finally, network address shuffling can also be employed, to obfuscate / modify the network layout.

In the literature, MTD is scarcely applied to ICS. While the aim of these techniques is to enhance system resilience, ICS needs guarantees regarding availability. Usual industrial installations are heavily tested in this regard, and the same level of rigor may not be applicable to the large array of different configurations needed by MTD. Still, some research papers will try in spite of these obstacles. In [6], MTD is implemented on a cyberphysical system managing a physical process, by changing the controller's parameters over time. In [13], Software Defined Networking (SDN) elements in an ICS are used to rewrite data flows, randomizing addresses to prevent an observer from gaining knowledge about the system's inner working. Using additional networking components allows for compatibility with the numerous legacy components commonly found in ICS, which do not implement these security capabilities themselves. For cyberphysical systems (CPS), which possess similar constraints regarding system availability, [7] proposes to randomize instruction sets, and gives a method to recover from attacks: keeping predefined backup controllers in a waiting state, switching them on if the main controller is attacked. Another paper concerning cyberphysical systems, [5], continuously modifies the system's parameters, and also tries to react to attacks, though it focuses on detecting them.

Our method, migrating tasks away from compromise devices, has very similar requirements with MTD techniques. Application migration is already used in some studies, as seen in [14], where VMs are migrated across physical hosts, and similarly in [7]. In truth, the main difference lies with timing: while MTD's focus is on preemptive defense, we only launch reconfiguration whenever an attack is detected. This mitigates the reliability issue: we only intervene once the installation's integrity is already compromised. Taking advantage of these similarities, we will also present how our method can be adapted for moving target defense in section 3.3.

## 2.3 ICS specific cybersecurity

As seen in the previous two sections and due to the availability constraints of ICS, it is difficult to find
papers concerning automatic reaction to attacks, as it is a relatively new field of research. However, most
mechanisms employed in our reconfiguration method have similar implementations within the literature.
For application migration to be possible, we need a way to generate backups / checkpoints. In [15], the
creation of such backups is discussed for PLCs, here to apply a rollback in the event of a fault.

On another hand, the approach of changing the execution location of an application within an ICS
to ensure the system's resilience has been explored in some other works. In [16], way before modern
cybersecurity concerns arose, switching to a predetermined backup PLC in response to a fault was discussed.
In [17], this approach was extended to include three backup locations, as well as software diversity in the
implementations, and we aim to go a step further in increasing the number of possible locations. Note
that a redundant approach is typically applied to other parts of ICS, where, for instance, having redundant
physical interconnections prevents systems from malfunctioning when a single wire is severed. This can be
seen in [18] which reviews different implementations of such redundancy.

Finally, this research topic was also touched upon in [19], a paper that used discrete controller synthesis (DCS) to create a similar reconfiguration controller, able to react to device compromise by redistributing applications to the remaining ones. To summarize the approach, a formal model of the system is defined in Heptagon, a synchronous dataflow language derived from Lustre. Then, formal properties corresponding to the reconfiguration problem are added, and a DCS tool is run to create a controller that ensures these
properties are always met. The method we employ to create the reconfiguration controller is different : As the decision process is completely defined by the current state, we can use constraint programming instead, our system model seen in section 3.1 allows for more constraints to be defined, and corresponds to the IEC 62443 standard.

# 3 Resilience via reconfiguration

## 3.1 IEC 62443 Configuration model

The first step in our approach is to develop a model for security of the ICS, relying on the Zone/Conduit model defined in the IEC 62443 standard.

### Reconfiguration problem and assumptions

We assume that the system under control is compliant with IEC 62443, and thus organized in zones that contains applications and devices. We suppose that the attacker will try to compromise host devices or applications, thus components like remote Input/Output units that do not execute arbitrary code will not be considered for attacks. Whenever a device or application is compromised, it will be isolated and the remaining applications will be redistributed on the rest of the system to maintain as much availability as possible.

In our current set of assumptions, if we stop an application, it cannot be restarted later by the reconfiguration process. Restarting with default values is not always applicable and could lead to hazardous situations. Do note that, in this context, stopping an application implies putting its controlled physical process in an inactive, but safe mode. This safe mode may be achieved through safe fallback values on the RTUs, applied whenever no connection is active.

We also assume that, for now, devices cannot be moved to a different zone by the controller. In a case where VMs are described as devices executing applications, and the actual hardware is technically part of multiple zones, these assumptions could be relaxed.

The reconfiguration controller should take as input the compromised component, as well as the previous state of the system under control (see Section 3.1). The output should be, for each application, its execution location in the new configuration: either a device, or none, in which case it is stopped. The system model will be updated based on this output, and a mechanism should be in place to migrate / stop every application whose location changed, whichever is applicable.

We consider that the initial alert will be raised by an intrusion detection system (IDS). In our concrete use case, the mechanism employed to apply the new configuration consists of a set of backup controllers, one for each application. These regularly take snapshots of their corresponding application's states in their current execution location, and are capable of writing this state to another PLC, and of activating / deactivating instances of their application on compatible devices.

We also assume that multiple devices may be compromised in a row, which the system should detect, then react to. As such, we can model the reconfiguration system as a MAPE-K (Monitor-Analyze-Plan-Execute over a shared Knowledge) feedback loop [20], with a cycle started each time a device is compromised. This feedback loop is represented in Figure 3.

### System model Zone-Application-Device

We developed a model that describes the parts of IEC-62443 compliant plants that are relevant to the task migration.

The model consists of a set of zones Z, a set of applications A and a set of devices D. To express meaningful constraints to the reconfiguration, several properties were added to applications and devices. Applications have a size property while devices have a capacity, the maximum total size of applications it can run. This represents a limitation, CPU time needed/available for instance. Applications also have a score formula, that determine how the application contributes to the overall system availability and performance when executed, taking into account which device it runs on. They also have set of other components (devices and applications) they need to communicate with in order to be executed, and this communication may only pass through, at most, one conduit. In a formal manner, an instance of our model consists of a tuple of three sets (Z, A, D), along with the following functions:

* **adj**: Z → 2^Z, with **adj(z)** the set of all zones adjacent to z, meaning z itself and any zone connected with z through one conduit. As a reminder, conduits also counts as zones, and therefore a zone is
<figure><img src="image_4.png" /><figcaption>Figure 3: Representation of the reconfiguration problem as a feedback loop.</figcaption></figure>

adjacent to all conduits that connect to it, and a conduit is adjacent to all zones it connects.

* dep : $A \to 2^A$, with dep(a) the set of all applications that a needs to communicate with (dependencies).

* dev : $Z \to 2^D$, with dev(z) the set of all devices in zone z.

* size : $A \to \mathbb{N}$, with size(a) the size of application a.

* cap : $D \to \mathbb{N}$, with cap(d) the capacity of device d.

* loc : $D \to Z$, with loc(d) the zone where d is located.

* comp : $A \to 2^D$, with comp(a) the set of all devices that can run application a, taking every static constraint into account. These entail security level constraints, dependencies towards devices, and application-device compatibility, for instance.

* score : $A \times D \to \mathbb{N}$, with score(a, d) the score obtained by application a running on device d.

Let us now describe how the **comp** is derived from the plant model. If a given device *d* is compatible with a given application *a* (i.e., *d* ∈ **comp**(*a*)), then the following properties must hold:

* The device must hold in memory an instance of the application (technical constraint).

* The application must be able to access all its device dependencies from the device, with communications passing through at most one conduit. Let us call depDev(a) the list of devices application a must be able to access that way, an information present in the plant model. The following must be true:

$$ \forall d_2 \in \text{depDev}(a), (\text{loc}(d_2) \in \text{adj}(\text{loc}(d))) $$

* The application meets the security level constraints of the zone: either its capability is above the zone target's for each value in the vector, or a countermeasure is in place within the zone to reach the target level. Let us call capability(x, i) the $i^{th}$ security level in component x capability security level, x being either an application or a countermeasure. Similarly, target(z, i) the $i^{th}$ security level in zone z's target security level. The set of countermeasures within a zone z will be denoted ctm(z). With these notations in mind, the following must always be true:

$$ \forall i \in [1..7], \text{capability}(a, i) < \text{target}(\text{loc}(d), i) \Rightarrow \\ \exists m \in \text{ctm}(\text{loc}(d)), \text{capability}(m, i) \geq \text{target}(\text{loc}(d), i) $$
* The plant model, including attributes for devices and constraints for applications. The former are String-value associations, and the latter boolean formulas that take into account the execution location's attributes. For a device to be compatible with a given application, all of the application's constraints must evaluate to true.

The applications' compatible device sets can be further restrained. This is done by marking all devices that cannot access some of their application dependencies, removing them, and repeating this process until a fixed point is reached (no device removed from any application compatibility set for a whole iteration). The process can be seen as follows:

$$ \begin{array}{l} \text{if } \left( \bigvee_{d_2 \in \text{comp}(a_2)} \text{loc}(d_2) \notin \text{adj}(\text{loc}(d_2)) \right) \rightarrow \text{remove } d \text{ from } \text{comp}(a) \\ \forall a \in A, \forall d \in \text{comp}(a), \forall a_2 \in \text{dep}(a) \end{array} $$

In addition to these static values, we also need to define the current state of the system, which can change whenever a reconfiguration occurs. This current state is defined by a function named **on**:

* **on**: $A \rightarrow D \cup \{\text{None}\}$, with **on**(a) the device application a is currently running on (None if it stopped).

As an example, we will give the tuple corresponding to the Zone/Conduit system illustrated in Figure 4. Scores, size and capacity are not defined in the illustration. We will suppose that each application has a size of 1, each device a capacity of 2, except $d_4$ which has a capacity of 0. Applications get a score of 3 on their original device, 2 on others.

* $Z = \{z_1, z_2, z_3, z_4, z_5\}$

* $D = \{d_1, d_2, d_3, d_4\}$

* $A = \{a_1, a_2\}$

We will also give the functions' graphs for this instance:

* **adj** = $\{z_1 \mapsto \{z_1, z_2, z_3, z_4, z_5\}, z_2 \mapsto \{z_1, z_2, z_4\}, z_3 \mapsto \{z_1, z_3, z_5\}, z_4 \mapsto \{z_1, z_2, z_4\}, z_5 \mapsto \{z_1, z_3, z_5\}\}$

* **dep** = $\{a_2 \mapsto a_1\}$

* **dev** = $\{z_1 \mapsto \{d_1\}, \dots, z_4 \mapsto \{d_4\}, z_5 \mapsto \emptyset\}$

* **size** = $\{a_1 \mapsto 1, a_2 \mapsto 1\}$

* **cap** = $\{d_1 \mapsto 2, d_2 \mapsto 2, d_3 \mapsto 2, d_4 \mapsto 0\}$

* **loc** = $\{d_1 \mapsto z_1, d_2 \mapsto z_2, d_3 \mapsto z_3, d_4 \mapsto z_4\}$

* **score** = $\{(a_1, d_1), 3, ((a_1, d \neq d_1), 2), ((a_2, d_2), 3), ((a_2, d \neq d_2), 2)\}$

* **comp** = $\{(a_1, \{d_1, d_3\}), (a_2, \{d_1, d_2, d_3\})\}$

* **on** = $\{a_1 \mapsto d_1, a_2 \mapsto d_2\}$

Such models are used as input in the reconfiguration process, representing the initial configuration. It is modified whenever an intrusion is detected. Here, we will assume that being attacked means either a zone, a device or an application is compromised. If the compromised component is a device or application, it is removed from D or A respectively. Then, any application that had the removed element as a dependency (or another application removed this way, recursively) is removed from A. We understand compromising a zone as compromising all devices within the zone, therefore applying the corresponding rule for each. In the remainder of the paper, in particular in the evaluation, only devices will be attacked.

Note that, each time removal from the model is mentioned, we could instead add the removed applications and devices to "out-of-service" sets, keeping their description within the model. This is functionally identical, as these removed components will not be of interest for the reconfiguration controller. Once an operator intervenes following the intrusion, the system will probably go back to the initial state, as described in the corresponding DSL instance. Afterwards, the reconfiguration in itself takes place, derived from the current model.
<figure><img src="image_5.png" /><figcaption>Figure 4: Simple example of a system divided in zones. Arrows represent dependencies, dotted lines represent current execution location.</figcaption></figure>

## 3.2 Optimization problem

### Base reconfiguration Program

The reconfiguration process is modeled as an optimization problem, and managed by an integer linear program (ILP) / constraint program (CP) (the equations can be expressed in both paradigms). The goal is to find a new valid configuration, maximizing the overall application scores.

A set of boolean decision variables run are created for the program, with run$_{a,d}$ being set to 1 if and only if application a should now be run on device d. Note that, in constraint programming, boolean variables take the usual truth values (true and false), and can be alternatively understood as integer variables, mapping true to 1 and false to 0. Both will be used in the constraints equations.

Additionally, two sets of intermediate variables, derived from these decision variables, are also defined and used within the constraints.

* none$_{a}$ : True if application a is not running on any device.

* in$_{a,z}$ : True if the application a is within zone z.

These variables, alongside others defined in the extended version of the constraint program, are recapped in Appendix 2.

The objective of this optimization problem is to maximize the sum of all applications' scores.

$$ \text{Maximize} \left( \sum_{a \in A} \sum_{d \in D} \text{score}(a, d) \cdot \text{run}_{a,d} \right) \qquad (0.1) $$

This objective is maximized under the constraints that will follow, which will be presented both in a manner similar to the constraint program (weighted sum of variables compared to a constant) and, when necessary, as equivalent expressions designed to be more easily understandable. In these cases, we will first present the intuitive expression, followed by the one actually employed within the constraint programs.

A given application a may only run on at most one compatible device, and if it is not allocated, none$_{a}$ is set to true.

$$ \begin{aligned} none_a = & \bigwedge_{d \in \text{comp}(a)} \neg run_{a,d} & \forall a \in A \\ & \sum_{d \in \text{comp}(a)} run_{a,d} \le 1 & \forall a \in A \end{aligned} $$

In the constraint program, this is rewritten as a single constraint both defining none$_{a}$ and enforcing the “at most one execution location” rule:

$$ none_a + \sum_{d \in \text{comp}(a)} run_{a,d} = 1 \quad \forall a \in A $$
Devices cannot run more applications than their capacity allows.

$$ \sum_{a \in A} (run_{a,d} \cdot \mathbf{size}(a)) \leq \mathbf{cap}(d) \quad \forall d \in D $$

An application is in a zone, if it is executed on a device that is within the zone.

$$ in_{a,z} = \bigvee_{d \in \mathbf{dev}(z)} (run_{a,d} = 1) \quad \forall a \in A, \forall z \in Z $$

This can be rewritten, within the constraint program, as:

$$ \left( in_{a,z} - \sum_{d \in \mathbf{dev}(z)} run_{a,d} \right) = 0 \quad \forall a \in A, \forall z \in Z $$

Applications that needs to communicate can only be assigned to adjacent zones:

$$ \begin{gathered} (in_{a_1,z_1} \land in_{a_2,z_2}) \implies z_2 \in \mathbf{adj}(z_1) \\ \forall a_1 \in A, \forall a_2 \in \mathbf{dep}(a), \forall z_1 \in Z, \forall z_2 \in Z \end{gathered} $$

This can be rewritten from the opposite angle: Two applications that need to communicate cannot be allocated to zones that are not adjacent.

$$ \begin{gathered} in_{a_1,z_1} + in_{a_2,z_2} \le 1 \quad \forall a_1 \in A, \forall a_2 \in \mathbf{dep}(a), \\ \forall z_1 \in Z, \forall z_2 \in (Z \setminus \mathbf{adj}(z)) \end{gathered} $$

For a given application $a$, if any of its dependency $a_2$ is stopped, it needs to be stopped as well.

$$ \left( \bigvee_{a_2 \in \mathbf{dep}(a)} none_{a_2} \right) \implies none_a \quad \forall a \in A $$

This can be rewritten as:

$$ |\mathbf{dep}(a_1)| \cdot none_{a_1} - \sum_{a_2 \in \mathbf{dep}(a_1)} none_{a_2} \ge 0 \quad \forall a_1 \in A, \forall a_2 \in \mathbf{dep}(a_1) $$

If we note $n$ the number of applications, $m$ the number of devices and $p$ the number of zones in the studied system, the program will contain at most $1+n+m+np+p^2n^2+n^2$ constraints (with each of these 6 numbers the maximum amount of constraints corresponding to the respective equation), so creating this program has a complexity of $O(m+n^2p^2)$.

Once this program is solved, the model is updated again based on the resulting decision variable values. We will also use the $none_a$ variables, whose value can be deduced from the decision variable set. For each application $a$, if $none_a$ is true, $a$ is removed from the set of applications $A$. If $none_a$ is false, $\mathbf{on}(a)$ is set to $d$, with $d$ the only device for which $run_{a,d}$ is true.

Note that, in the new configurations, target security levels for zones are always met. While security levels do not appear within the constraint program explicitly, they are taken into account in the definition of the $\mathbf{comp}$ function. An application being added to a zone may only reduce the achieved security level, therefore they cannot be attributed to zones with a higher target security level than their capability, except if appropriate countermeasures are in place. See 1.3 for the achieved security level computation.

As an additional remark, $\mathbf{on}(a)$ is never used in the current constraint program. As it stores the current location of applications before reconfiguration, it can be employed to determine whether an application moved or not: an application $a$ moved, if $\mathbf{on}(a) \ne \mathbf{None} \land (run_{a,\mathbf{on}(a)} = 0)$. Knowing which application moved has at least two uses.

* First, once the constraint program outputs its results, only the applications that moved / were stopped cause an action on the physical system, as shown in Figure 3.
* It can also be used to add “minimizing the number of application migration” as a subgoal of the reconfiguration. As these movements imply a brief interruption of nominal control over the system minimizing them can be a secondary objective used to decide between multiple configurations that achieve the same maximal score. This minimization objective can be expressed as:

$$ \text{Minimize} \left( \sum_{a \in A} \sum_{D \setminus \mathbf{on}(a)} run_{a,d} \right) $$

We now need to define a new maximization objective, taking this secondary goal into account. To ensure that maximizing score is prioritized over minimizing application movements, the total application score is multiplied by a constant higher than the number of application, while the number of moved applications is subtracted from the total. The optimization objective (see (0.1)) therefore becomes:

$$ \text{Maximize} \left( ((card(A) + 1) \cdot \left( \sum_{a \in A} \sum_{d \in D} \mathbf{score}(a, d) \cdot run_{a,d} \right) - \sum_{a \in A} \sum_{D \setminus \mathbf{on}(a)} run_{a,d}) \right) $$

## 3.3 Generalization and Variants

### Additions to the constraint program

The reconfiguration model presented in the previous section used application execution location as the sole decision variable. While migrating applications is the crux of our reaction framework, other parts of the system may be changed as a response to attacks. In a virtualized installation, even devices could be migrated to another zone, for instance. We will not consider this further, as the computational cost increase would certainly make constraint programs impractical, and the applicability to real ICS very uncertain. On the other hand, two parts found in the IEC 62443 zone/conduit model are not modified in the reconfiguration process as of now: countermeasures and conduits.

When trying to migrate applications to other security zones, most candidate for execution location could have one the following issues: either the application's security level is too low for the zone, or the application cannot access its dependencies. This could be solved by activating, respectively, a countermeasure or a conduit. Thus, these activations/deactivations are new decision variables of the reconfiguration process: $active_c \forall c \in C$ and $active_m \forall m \in M$, with C the set of conduits and M the set of countermeasures. They are presented in a symbol table in Appendix 2. This has a few implications:

* Conduits must be split, separating their behaviour as a zone and their communication role. For instance, the Zone/Conduit model shown in Figure 4 is equivalent to the one shown in Figure 5 for the new model.

* The meaning of the compatibility relation between applications and devices changes slightly: it now gives a maximal list of devices that are compatible, assuming that all possible countermeasures and conduits are active.

* The meaning of the adjacent relation between zones also changes: it now gives the maximal set of adjacent zones, assuming that all conduits are active.

* In order to make activating a conduit or countermeasure a decision rather than the default behaviour, this activation now has a cost, subtracted from the overall score. This represents the impact on system performance associated with keeping them active for countermeasures, and is a deterrent to keeping too many conduits active.

These modifications change our model, from the ZAD tuple (Zone application Device) to the ZC²AD (Zone Conduit (C) Countermeasure (M) Application Device) tuple. While security level constraints were previously statically resolved in ZAD models (and modelled as compatibility relations, as seen in Section 3.1), the addition of dynamic countermeasure activation means they have to be part of the new model. As stated in the IEC 62443 standard's presentation; applications, devices and countermeasures have a capability security level, while zones have a target security level. As a reminder, security levels are presented as vectors of size 7, containing numbers between 0 and 4 included. They will be translated here as functions taking as input a component and index in the security level vector (between 1 and 7), and outputting the corresponding security level (between 0 and 4). Additional attributes and relations needs to be defined in this new model:

* loc: $M \to Z$. As for devices, countermeasures are located within a zone.
* **capability**: $(A \cup D \cup M) \times [1..7] \to [0..4]$. **capability**($x, i$) gives the $i^{th}$ value of the capability security level vector of component $x$.

* **target**: $Z \times [1..7] \to [0..4]$. **target**($z, i$) gives the $i^{th}$ value of the target security level vector of zone $z$.

* **cost**: $(C \cup M) \to \mathbb{N}$, with **cost**($x$) the cost, as in negative impact on the score, when $x$ (a conduit or countermeasure) is active.

* **active**: $(C \cup M) \to \mathbb{B}$, with **active**($x$) true if $x$ is active in the current configuration. This function serves a similar purpose to the **on** function in reconfiguration.

* **fitM**: $Z \times [1..7] \to 2^M$, with **fitM**($z, i$) the list of countermeasures in zone $z$ that can reach the target security level $i$.

* **links**: $C \to 2^Z$, with **links**($c$) the set of all zones connected by conduit $c$.

* **depDev**: $A \to 2^D$, with **depDev**($a$) the set of all devices application $a$ needs to communicate with. This was previously statically solved and hidden in the **comp** relation, but cannot now that conduits' status can change.

* **between**: $Z \times Z \to 2^C$, with **between**($z1, z2$) the set of all conduits that links both zones $z1$ and $z2$.

* **critical**: $A \to \mathbb{B}$, with **critical**($a$) true if application $a$ is critical. This criticality implies that the concerned applications cannot be stopped by the reconfiguration process.

With these modifications, the previously defined program found in Section 3.2 needs additional constraints. While the previous constraints used in the ZAD model could have been written within a linear program, the new ones will employ non-linear operators specific to constraint programming (atLeastOne, implications, ...).

The objective is changed: the sum of all active countermeasures and conduits costs is subtracted (Equation (0.2)).

$$ \text{Maximize} \left( \sum_{a \in A} \sum_{d \in D} \text{score}(a, d) \cdot \text{run}_{a,d} - \sum_{c \in C} \text{cost}(c) \cdot \text{active}_c - \sum_{m \in M} \text{cost}(m) \cdot \text{active}_m \right) \quad (0.2) $$

If an application needs to communicate with an application dependency outside of the assigned zone, a relevant conduit must be active.

$$ \begin{aligned} & in_{a_1,z_1} + in_{a_2,z_2} - \left( \sum_{c \in \text{between}(z_1,z_2)} active_c \right) \le 1 \quad \forall a_1 \in A, \forall a_2 \in \text{dep}(a_1), \\ & \qquad \forall z_1 \in Z, \forall z_2 \in (Z \setminus z) \end{aligned} $$

This is equivalent to:

$$ \begin{aligned} (in_{a_1,z} \land in_{a_1,z_2}) &\implies atLeastOne(c \in between(z1, z2)|active_c) \\ &\qquad \forall a_1 \in A, \forall a_2 \in \text{dep}(a_1) \\ &\qquad \forall z_1 \in Z, \forall z_2 \in (Z \setminus z) \end{aligned} $$

We will prefer the latter formalism in this document, using CP-specific operators, as it is easier to read.

If an application has a capability inferior to a zone's target, a relevant countermeasure must be active.

$$ \begin{aligned} (in_{a,z} \land (\text{capability}(a, i) < \text{target}(z, i))) &\implies atLeastOne(m \in fitM(z, i)|active_m) \\ &\qquad \forall a \in A, \forall z \in Z, \forall i \in [1..7] \end{aligned} $$

If an application needs to communicate with a device dependency outside of the assigned zone, a relevant conduit must be active.

$$ \begin{aligned} (\text{loc}(d) \neq z_1 \land in_{a,z_1}) &\implies atLeastOne(c \in between(z_1, loc(d)|active_c) \\ &\qquad \forall a \in A, \forall d \in \text{comp}(a), \\ &\qquad \forall z_1 \in Z \end{aligned} $$
We can also consider that some applications may not be turned off without compromising the entire system. These will be referred to as critical applications. The reconfiguration constraint program will never output a solution with a critical application (or one of its dependencies) stopped. The other applications will still be allocated as usual, in a best effort manner. This translates as the following constraint:

$$ \forall a \in A, \mathbf{critical}(a) \implies \neg none_a $$

<figure><img src="image_6.png" /><figcaption>Figure 5: Modified system, following the Zone-Conduit-Application-Device (ZCAD) transformation : the z₄ conduit is split into a zone and a conduit.</figcaption></figure>

## Optimization and heuristics

As we will see in Section 4.2, solving the constraint program has a cost that increases dramatically as system size grows. This is expected, as the worst case execution time (WCET) scales with the state space, which is exponential with regards to the model's size. Thankfully, the observed results are far from the WCET, thanks to the solver's optimizations and heuristics in part, and probably to the studied problems' shapes as well. The observed solving time went up to ~100s for programs with 40 zones, 80 devices and 160 applications, the largest generated problems we tried to solve. This is an unacceptable amount of time for an automatic reaction within the feedback loop featured in Figure 3. Multiple approaches can be taken to mitigate this issue.

The “easiest” one is to not apply the method on **homogeneous** systems of such scale. This is an important first point to make, as while we do not have access to large scale ICS to model, we can safely tell that most current industrial control systems do not consists of 40 security zones and contain much less than 80 homogeneous devices. If such a large system were to be modeled, there is a case to be made that a given application would still only be able to be migrated to a small part of it. In this case, it would be wise to try to divide the system in “independent” subsystems, as in: disjoint parts of the system that can be individually reconfigured without taking into account the remainder of the system. The caveat lies in the degree of complexity employed within the constraint program: the basic reconfiguration presented in Section 3.2 leads to less interdependence than taking conduits and countermeasures into account, thus to an easier subdivision. In any case, while this is not a fully satisfactory solution to the complexity issue, this is an easy optimization to try first.

Another way of mitigating the online computation cost is to compute the reconfiguration controller offline. While a hundred seconds is unacceptable as a response time, it is tractable in this new paradigm. However, this is only the computation time for one reconfiguration: we obviously can not compute all possible system configurations for the whole system. If the plant contains 80 devices for instance, which could be attacked in any order, we may have to compute configurations for each element in the power set, so $2^{80}$. A one step controller, reacting only to the first device compromised, is easily computed, as can n step ones, as long as n is kept reasonably low. This solution only entails storing the configurations (application allocations, conduits and countermeasures states) in a table, indexed by the set of compromised devices (with set size up to n for a n step controller).

Finally, while the constraint programming method guarantees an optimal total score, heuristics can also be employed to get an approximation in a time bound manner. In the remainder of this paper, this time limit will be 100ms, but the duration could be set to any other value. What matters is that the chosen value is adequate with regards to the controlled physical process, and allows for a reaction in due time.
Conversely, heuristics should be employed when exact methods are too slow, letting the system remain in a compromised state long enough to be dangerous. As the solving time depends on system size, this can be inferred or tested when the reconfiguration controller is in the implementation phase. The heuristic could also be run concurrently, and its solution applied if the constraint program is not solved by the deadline. The main issue immediately encountered when following this trail of thoughts, is that generating random solutions to this heavily constrained assignment problem is also costly: random execution locations almost never fit the constraints, while constructing the configuration from scratch, in a manner that guarantees the resulting system is valid, typically leads to abysmal scores. Knowing this, the applicable heuristics narrow to the local search based ones. Among them, a tabu search based heuristic search was implemented, with the following pseudo-code:

Input: starting configuration c

Output: configuration res

Code:

bestConfig = c

bestFitness = c. fitness

currentConfig = c

Tabu : empty configuration list

While less than 100ms is elapsed:

for each neighbour of currentConfig not in Tabu ordered by fitness:

if neighbour is valid:

currentConfig = neighbour

if (currentConfig. fitness > bestFitness):

bestFitness = currentConfig. fitness

break

else:

Add neighbour to Tabu

add currentConfig to Tabu

return bestConfig

With this pseudo code in mind, some parts needs further clarification. The tabu list approach allows us to explore the most promising candidates that have not been explored before, and avoids checking invalid configurations multiple times, as the operation is costly. Fitness is the score achieved by the new configuration. The neighbourhood is defined in two manners:

* First, a close neighborhood: configurations where an application that was stopped is now running, or a conduit/countermeasure is now inactive. These modifications, if they lead to a valid configuration, may only have a positive influence on the score.

* Secondly, an extended neighbourhood, employing application swaps, or activating a countermeasure/- conduit.

To define these neighbourhood in a formal manner, we need a reminder on the configuration model employed in the reconfiguration process. A configuration, linked to a certain ZCAD system model, is completely defined by the following boolean decision variables:

* $run_{a,d}$, for all applications $a$ and devices $d$ in $comp(a)$, true if application $a$ is running on device $d$

* $active_c$, for all conduits $c$, true if the conduit is active.

* $active_m$, for all countermeasures $m$, true if the countermeasure is active.

A neighbor is understood as a different configuration, with most of the aforementioned variables in the same state as the original. The neighbor configurations do not have to be valid, as checking it preemptively is too expensive computation-wise. We first define a close neighborhood, whose members only have one modification compared to the base configuration. These are:

* for all applications $a$ such that $\forall d \in comp(a), run_{a,d} = false$; for each device $d \in comp(a)$, one configuration with $run_{a,d}$ set to true.

* for each active conduit $c$, with $active_c = true$, one configuration with $active_c$ to false.
* for each active countermeasure $m$, with $active_m = true$, one configuration with $active_m$ to $false$.

These modification have, by construction, a purely positive influence on the score (by activating an application, or removing the cost of a conduit / countermeasure). An *extended* neighborhood is explored when none of the configurations in the *close* neighborhood are valid. The goal is still to explore inherently neutral or positive modifications, by mixing a change with a positive effect on the score with a lesser negative one.

* First, $\forall a \in A, \forall d \in \textbf{comp}(a) : \textbf{score}(a, d) > \textbf{score}(a, on_a)$, ($on_a$ the current device $d$ such that $run_{a,d}$ is true in the initial configuration, or none if it was “stopped”, in which case the score is 0), a corresponding neighbour is added to the reconfiguration, with $run_{a,d}$ set to true. Let us call $s$ the score increase, $s = \textbf{score}(a, d) - \textbf{score}(a, on_a)$. This type of configuration will be used as a base, all following ones will add another action with a negative effect on score to it.

* for each application $a_2, \forall d_2 \in \textbf{comp}(a_2) : \textbf{score}(a_2, d_2) < \textbf{score}(a_2, on_{a_2}) \land \textbf{score}(a_2, d_2) \le s$, one configuration with $run_{a,d}$ and $run_{a_2,d_2}$ set to true.

* for each inactive conduit $c$, with $active_c = false$ and $cost(c) <= s$, one configuration with $run_{a,d}$ and $active_c$ to true.

* for each inactive countermeasure $m$, with $active_m = false$ and $cost(m) <= s$, one configuration with $run_{a,d}$ and $active_m$ to true.

The *close* neighborhood is explored first, and if no valid configurations are found, the *extended* one is too. The research is time bound by design, as the algorithm will only run for up to 100 ms and will, in the worst case, return the initial configuration. This initial configuration is the one that would naturally occur without application migration capabilities: applications running on the compromised device are stopped, as well as all applications that depend on them, recursively. This is by far the best candidate, both because it is very easy to compute, and as it is the closest valid configuration to the previously optimal one. In loosely constrained problems, this allows finding a good or even the optimal solution, as will be showcased in Section 4.2 later.

## Preemptive instance assignment

Up until now, we considered that an application compatible with a host device could be migrated to it. However, PLCs typically have a very limited memory size, and in large systems they cannot store a version of every application that could run on them. This means that for our reconfiguration process to make sense, whenever a device fits all requirements for an application in the model, it should contain a corresponding instance. This can be taken into account when manually describing the model, but we will also propose an automatic computation, aiming to distribute application instances to maximize the effectiveness of subsequent reconfigurations. This is done by changing the plant model, adding attributes to host devices indicating the instances they hold, and a constraint to applications, ensuring they are only executed on devices that contain their code. The ZCAD model and the reconfiguration constraint program do not need to be changed. To this end, we will need more information on the system: for each application, a size occupied in memory, and for each device a memory capacity.

Once again, we will solve a constraint program. The main differences are as follows:

* We are not assigning running applications, but instances. The objective is to maximize the total score obtained across all instances.

* The computation time "size" and capacity constraints are replaced with memory ones.

* If a device is an original execution location for a given application, it needs to have a corresponding instance.

* A minimum number of instances that each application must have can be set. Setting it to a high value increases computation time, and setting it too high may make the constraint program unsolvable.

* It is ensured that instances assignments are relevant: an instance can only be assigned to a given device if each of the application's dependencies also have a reachable instance assigned nearby.
On top of these, if a threat model that can predict which device is more likely to be attacked first is available, it can be taken into account, penalizing the score of instances running on this device. This encourages that only applications with low score will be assigned to risky host devices, enhancing resilience.

As an alternative to score, the reconfiguration can also try to prioritize critical applications (and their dependencies). In this case, non-critical application instances do not count toward the score tally, and only critical applications need to respect the minimum number of instances (if set).

## Moving target defense program

As explained in Section 2.2, our approach to the problem, reconfiguring the application-device assignments, is heavily similar to moving target defense, save for the timing being different. Putting aside the doubts regarding the feasibility of thoroughly testing a migration capable system, our constraint program can be modified to output new configurations for a MTD approach. This boils down to three changes :

* Take as input the current configuration, without a compromised component, and the last *n* previous configurations.

* Do not allow for active applications to be stopped

* Take a vector of floats of size *n* as input, coefficients to apply to the score of application-device assignments found in the previous configurations.

As the goal is to generate a set of different configurations, the degradation vector ensures some variety.

# 4 Evaluation

## 4.1 Training factory setup

In order to have a physical use case, a Fischertechnik training factory<fnref n="1" /> was mounted. It imitates the way a plant operates, and is separated in four different modules. One of them manages the input/output of the system, and the gripper that moves resources across modules. Resources are colored items that can be sorted using color sensors. The other modules manage the raw resource storage, the processing unit and the sorter, respectively. These modules were introduced in order of importance to the process, which their score will reflect.

The control program is divided in four parts corresponding to each module, and each PLC is able to reconfigure itself and migrate its program's state to other devices when instructed to by a Modbus command. The four PLC have the full control code loaded, with each part active on at most one PLC at a time. The sensors and actuators are delegated to remote terminal units (RTU). These RTU do not run any control program, and we will assume that they cannot be compromised by a distant attacker. For this setup, we employed Schneider m241 PLCs and TM3 RTUs. The setup is illustrated in Figure 6.

Due to the dynamics of the physical process carried out by the factory, the control system's cycle time should be low, and here was set to the minimum of 10ms. The objective is to sample the different moving parts' positions often enough to avoid collisions, or misplacements of resources. This is also a consideration to take into account for the reaction time, which should be kept low enough to avoid the same issues.

## Model and reconfiguration details

The system is split in four zones, corresponding to the modules. Each zone contains one RTU, the PLC that initially run the module's control program, and the program itself. The vacuum gripper should be able to communicate with every other program, and the multiprocessing station should communicate with the sorting station. Additionally, the gripper program must access the sorting station RTU to read specific values. In our model, the conduits are therefore defined based on these initial needs, leading to the layout found in Figure 7. In this example, and in later generated ones, the conduits are "empty": they do not contain any components explicitly, only describing which zones they link. They do not define a zone within themselves, even if the standard allows it. As a reminder, it is assumed that no communication may cross over more than one conduit. We chose to give every zone the same security level, as the number of possible reconfiguration is already small. In this example, we also state that each PLC may only execute up to two applications due to application size constraints. Due to the strict timing constraints, migrating tasks away

<footnote n="1">¹https://www.fischertechnik.de/en/products/industry-and-universities/training-models/554868-training-fact
ory-industry-4-0-24v</footnote>
<figure><img src="image_7.png" /><figcaption>Figure 6: Training factory setup, divided in four zones. The corresponding Zone/Conduit layout is shown in Figure 7.</figcaption></figure>

from the zone they control is discouraged. This translates to lower application scores on PLCs that are not the original location, and encourages fast reconfiguration. Application scores must be appropriately defined to prioritize important applications. In our case, this is mostly the Gripper program, followed by the HBW storage. The application scores are as follows:

* MPO: 4 on the original PLC, 3 on other execution locations.

* HBW: 6 on the original PLC, 5 on other execution locations.

* Gripper: 10 on the original PLC, 8 on other execution locations.

* Sorter: 3 on the original PLC, 2 on other execution locations.

As for costs, there are no countermeasures, and conduits are given a small cost of 1, ensuring their deactivation does not take priority over keeping applications running.

Note that a lot of elements in the model are more or less arbitrary. In general, this example is too small a scale, and the hardware too homogeneous to allow for a truly realistic portrayal of an industrial control system. The zone split, restrictions on concurrent applications and lower score based on execution location are some of these arbitrary elements.
<figure><img src="image_8.png" /><figcaption>Figure 7: Zone/conduit layout. Conduits shown with solid lines, applications dependencies with dotted lines.</figcaption></figure>

## Reconfiguration controller

The reconfiguration controller takes as input the system description to initialize the current configuration. The controller reacts whenever a device is compromised, marking it as such and starting the reconfiguration. A new constraint program is created as defined in Section 3.2, removing compromised devices and applications that need to communicate with them, and aiming to find a new configuration with maximal score. Here, we are testing the simple constraint program, without the variants mentioned in Section 3.3. This CP is then solved using the OR-Tools CP solver [21]. The resulting values gives, for each application that was not stopped beforehand, whether it is now stopped (*none*<sub>*a*</sub>), and if it still runs, which device executes it (the only device *d* such that *run*<sub>*a*,*d*</sub> is true). The new allocation of tasks is computed, and a message is sent to the old and new location to reflect this change. On the other hand, if the application was stopped, a Modbus message is sent to every PLC, halting any remaining parts of the process that interacts with it. Note that halting an application means putting the controlled process in a safe mode, as stated in the reconfiguration problem presentation in Section 3.1.

## Experimental protocol

We are mainly interested in the measurement of the time elapsed between the attack being signaled and the reconfiguration controller output. Any other non-temporal criterion should be able to be integrated in the score calculation, and the time elapsed between the attack and its detection is IDS dependent. The reconfiguration can be divided in two phases: solving the CP, and communicating the new solution to the set of PLC. Uploading new code to PLCs and restarting them would be both difficult to automate, slow, and would temporarily halt other running applications. To avoid these issues, the reconfiguration process only moves execution context. As stated in section 3.3, valid execution locations for a given application hold a corresponding instance in memory. Context can therefore be migrated to these PLCs without restarting them, avoiding a costly third phase for the reconfiguration process.

The controller is run on a DELL Precision 7770 laptop, with 128GB of RAM and a i9-12950HX CPU with up to date drivers as of January 2024. Other non-essential applications are stopped. The OR-Tools' solver native libraries for CP are loaded prior to measurements.

The PLCs and RTU controlling the training factory are connected to the controller through a switch, as seen in the setup in Figure 6.

The following is repeated $N=200$ times:

* Choose a random PLC as attacked, and start the timer

* Launch the CP solver to get a configuration without this PLC.

* Get the time elapsed since the timer started to measure the reconfiguration computation time.
* Communicate the new configuration to the PLCs using an implementation<fnref n="2" /> of the Modbus TCP protocol.

* Get the time elapsed since the timer started, to get the total reconfiguration time.

* The controller sends a signal to each PLC to reset the programs to their initial locations.

## Preliminary results

The results obtained using the training factory are shown in Figure 8. Two main information can be gathered from these. Firstly, solving the constraint program was always faster than applying the results. Each PLC processes its instructions a cycle after they are received, thus a delay of about 10ms is to be expected. As the current implementation is not parallelized, the obtained mean of 34ms is not surprising. As communication is a low priority tasks for the PLC compared to local control, it is sometimes postponed by a cycle, potentially explaining the worst cases. Enhancing communications will be a priority if we get a larger use case, as treating each of them sequentially will considerably lengthen the control delays. Secondly, the mean computation time is less than a PLC cycle time, while the worst lasted two cycle times. Almost nothing can happen in such a short time, and if the communication delays were improved, it's almost as fast as the PLC can react. Of course, this level of speed is only attainable because the studied ICS is very small.

<table><caption>Figure 8: Minimum, mean and maximum elapsed time (in ms) for the reconfiguration on the training factory, using a sample size of N=200, and a 95% confidence interval.</caption><thead><tr><th></th><th>min</th><th>mean</th><th>max</th></tr></thead><tbody><tr><td>computation</td><td>3</td><td>8.1±0.31</td><td>20</td></tr><tr><td>communication</td><td>15</td><td>34.3±1.71</td><td>69</td></tr></tbody></table>

## 4.2 Generated problems

### Type and shape of generated problems

While the basic reconfiguration process was implemented, run and evaluated on a physical small scale learning factory, this is not sufficient to test the entire approach. While this ensured that migration capabilities can be added to PLCs, and is a proof of concept for the reconfiguration controller, the system's small size prevents us from evaluating the constraint program's performance evolution as the number of zones and components scale. The preemptive assignment of application instances also cannot be tested, as the memory and computing limits are not reached, and most other variants presented in Section 3.3 similarly cannot apply to such small systems.

To solve these issues, we generate random systems of varying size. These systems all respect the following characteristics:

* A system of size *n* contains *n* zones, 2*n* devices and 4*n* applications.

* In the initial configuration, each zone contains two devices, each running two applications.

* Optionally, two countermeasures can be generated for each zone. They have a random cost, and do not need to be active in the initial configuration for the zone to reach their target security level. They may be activated during a reconfiguration, to enable less secure applications to migrate in the zone.

* If security levels are enabled, the generation ensures that the starting state is valid: every application and device in a zone has a higher capability than the zone's target.

* The score obtained by applications is randomly decided, but always higher on the initial device it is assigned to, and decreases on "farther" devices. The definition of farther depends on the system shape.

* Aside from a difference in score, specific constraints and potentially security levels considerations, every device in the generated system can execute any application.

<footnote n="2">²https://github.com/rossmann-engineering/EasyModbusTCP.NET</footnote>
For now, two types of system shapes are generated.

First, systems shaped in a tree fashion, illustrated in Figure 9. These follow a rigid, and heavily constrained structure. Zones are linked by conduits such that, if a zone numbered *i* exists, with $2 \le i \le n$, a conduits connects it to the zone numbered $\lfloor \frac{i}{2} \rfloor$. Application dependencies also follow a strict pattern. The first application in each zone (so, application $4(n-1)+1$ for zone *n*) is considered the master application, i.e. :

* It has a random, non master application in the previous zone as a dependency.

* All other application in the zone have it as a dependency.

* It is considered a critical application.

With this system shape, we aim to imitate the hierarchical structure of common ICS architectures like SCADA, where information comes from the outer parts and flows upstream to be centralized.

The other shape for generated systems is “random”. For a system of size *n*, this means:

* *n* conduits, randomly linking two different zones. Each such conduit must be unique, and there's no conduit instead for systems with one zone, and one conduit for systems with two zones.

* Of the four applications in each zone:

- One has another application in the zone as a dependency.

- Another one has a device in the zone as a dependency.

- A third one has an application in an adjacent zone (accessible through one conduit) as a dependency.

* An application in zone number *i* ($1 \le i \le n$) can only be ran on devices within zones with numbers in the interval $[max(1, i - \lfloor \frac{n}{4} \rfloor), min(n, i + \lfloor \frac{n}{4} \rfloor)]$. At most, an application can therefore be run in approximately half of the system's devices.

## Score-wise evaluation

In order to measure the reconfiguration's performance on larger systems, we created random instances of varying size (with size $n=4$ to 20 zones, growing in increments of 2). The instances were grouped in four categories, separated by shapes (tree or shapeless, as seen before) and reconfiguration "difficulty". The difficulty is either easy or hard, the difference lying in the number of applications device can run concurrently. In hard instances, devices can only run a maximum of two applications at the same time, so every reconfiguration will lead to stopping at least two applications, and reconfiguration may need to swap applications around. In easy instances, each device can run three applications (but still starts with two). For every size *n* tested, and four each category, 30 different systems were generated.

As for the experiment, we still do not evaluate the resulting configuration's score, as by construction it is maximized. We cannot evaluate the communication time, as the generated instances do not correspond to concrete physical systems. We are therefore only interested in the time spent solving the constraint program, after one of the system's device is compromised.

The results can be found in Figure 10. Keep in mind that the graph follows a logarithmic scale on the y axis. Here, the computation times for small systems seems to be around 10ms, which corroborates the results from the use case. While generally the constraint satisfaction problem and solving MILP problems is NP-hard, the performances observed here are peculiar. For the CP solver, the difficulty of the problem does not have an important influence on the solving time, while the shape has a drastic one for both solver types. This result is in fact expected: while the “shapeless” systems define a limit for application-device compatibility, the “tree” ones do not. This leads to a dramatically larger state space, which is the scaling factor for the solving time. One may also observe that the CP-based solution execution time rises quickly regardless of difficulty, while the MILP-based one solves easy problems quickly, and has more erratic performances for hard ones. Except for tree-like “easy” problems of large size, CP is typically faster, and has more predictable solving times in general, hence our preference goes to it.

As stated in 3.3, this rapidly increasing solving times prevents this method from being directly employed online in larger systems. Evaluating n-step controllers with regard to solving time is not very relevant, as they are computed offline. On the other hand, we need to check how the heuristic approach performs.

As a reminder, the heuristic is based on Tabu search, a form of local search, and run for 100ms at most. We want to compare the score obtained in the resulting configurations to the ones output by solving the
<figure><img src="image_9.png" /><figcaption>Figure 9: Organization of the generated tree shaped systems, with *n* zones, 2*n* devices and 4*n* applications. The tree is filled from left to right, breadth-first.</figcaption></figure>

constraint program. The metric employed is the score loss between the two results, expressed as a percentage of the score difference between the optimal configuration, and the one occurring when no reconfiguration takes place. This evaluation was done on the exact same problems as the previous one (same model, same device attacked), in parallel, and the results can be seen in Figure 11.

Several information can be gathered by observing the figure. First, the heuristic approach is much more effective when solving simple problems, where optimal or at least good solutions are within the neighborhood of the starting search point. This is expected, as the heuristic used is a form of local search. Secondly, there is a clear loss of performance for the “easy tree” configurations, between 48 and 56 applications. This is a limit of the time bound approach, the performances degrade once the neighborhood exploration does not entirely fit within the time frame. As explained before, this is only visible for the “tree” instances, as their space state for an equivalent *n* is much larger. All in all, in easy examples, this method generally leads to acceptable results. For real systems, this entails that the heuristic method could be used as an answer to the first compromised devices, as long as the system has sufficient computing power to continue executing all of its applications. Once choices between which application to keep active have to be made, exploring the different possible swaps quickly becomes too costly and prevents timely answers.

We also tried to compare this heuristic approach to a basic greedy algorithm. This greedy approach is as follows:

* Start from a blank slate, with no running application

* Until every application is given an execution location:

- Search through every possible remaining application-device assignments, and keep the one with the best score.

- If at least one valid assignment was found, apply it.

- If not, return the current configuration.
<figure><img src="image_10.png" /><figcaption>Figure 10: Graph showing the evolution of the CP (in red) and MILP (in blue) solvers resolution time as a function of the number of applications in the system. The y-axis follows a logarithmic scale. Each point is computed as a mean of 30 values, and a 95% confidence interval is provided. The heuristic approach always lasts 100ms.</figcaption></figure>

* Return the resulting configuration.

As stated when we motivated the use of local search algorithm, designing solutions from the ground up is extremely inefficient for our problem. In fact, in our observations, the score of the configurations resulting from this algorithm was always worse than not applying any reconfiguration, therefore the heuristic approach is by default always better. This is expected, as this greedy algorithm cannot handle placing, for instance, two mutually dependent applications.

## Resilience evaluation

Aside from minimizing the score loss after one device is attacked, another meaningful metric would be the number of devices that need to be attacked on average before a critical part of the system shuts down. To evaluate this, the generated systems needs to contain a set of critical applications. In this section, we will also be interested in the impact of preemptive instances assignment on this metric.

This time, the generated systems follow the shapeless generation rule, each device can run up to three applications concurrently, and are all of size $n = 10$. Memory constraints are added to applications and devices, with each application having a size of 1, and each device a capacity of 8. Out of the four applications running in each zone, one is set as critical, and its score is generally weighted to be higher. 50 such systems are generated.

The experiment consists of the following steps, repeated ten times for each generated instance:

* Make four copies of the model. Apply preemptive instances assignment to three of them, with:

- one with default parameters;

- one with a minimum of 3 instances for all applications;

- One prioritizing critical applications, with a minimum of 4 instances for each.

* Make one additional copy, which will not be reconfigured (but will still lose devices).
<figure><img src="image_11.png" /><figcaption>Figure 11: Graph showing the “quality” of solutions found by the heuristic approach, in bins of percentage score loss compared to the optimal. Pink bins correspond to cases where the optimal is reached without needing any reconfiguration. Derived from the same evaluations (Plant model and attack order) as 10.</figcaption></figure>

* Until each of the five instances are fully stopped (i.e. a critical application had to be stopped during reconfiguration):

- pick a random device to be attacked from the remaining ones.

- Apply reconfiguration to each of the four configuration, assuming the chosen device is compromised. Replace each with their respective output.

- Store the current score attained by each, as well as the current number of reconfiguration steps.

As can be seen, two metrics are gathered for every experiment: the evolution of the score (until it inevitably reaches 0), and the number of steps before stopping a critical application. First, the difference in the number of device failure until failure can be seen in Figure 12. The result is relatively clear cut: while reconfiguring with the previous hypothesis of infinite memory still has an edge, the preemptive assignment focusing on critical applications almost matches its performance. The default assignment policy predictably gives too few / no additional instance to some of the critical application's dependencies, which results in volatile performances. By design, the “no reconfiguration” instances have a higher than 50% chance of failing whenever a device is compromised, the observed abysmal resilience is therefore expected.

Of course, such resilience does not come without a cost. As can be seen in Figure 13, when we look at the mean score obtained after *i* devices are compromised, prioritizing critical applications is consistently worse than all other shown options. Default assignment, assignment with a minimum of three instances for each application give similar scores, while the previous result showed that the latter is more stable. However, this is only taking into account valid configuration: if a modality failed to provide a new configuration beforehand, it is, in this graph, not part of the mean computation (and therefore does not count as 0). This leads to an interesting trade-off: if few devices are attacked, it's preferable to rely on assignments with a high number of minimum instances for each application, while prioritizing critical applications is only preferable if the attacker compromises a large number of devices within the system. This is a compromise between graceful degradation for the former method, and resilience of essential functions for the latter.
<figure><img src="image_12.png" /><figcaption>Figure 12: Box plots for the number of devices attacked until a critical application must be shut down. Different boxplot for each paradigm (default, min. 3 instances, min. 4 instances for critical applications, infinite memory, no reconfiguration).</figcaption></figure>

# 5 Conclusion and perspectives

## 5.1 Conclusion

In this paper, we pointed to the increased exposure of ICS to cyberattacks, and the need for novel defense mechanisms that maintain availability. To this end, we developed a novel constraint programming approach that dynamically migrates tasks and isolates compromised components. We defined a configuration model derived from the IEC 62443 standard, focusing on elements relevant to reconfiguration. This encompasses zones, conduits, devices, and applications, along with critical attributes such as security levels, device capacities, and application dependencies. These descriptions are used as input to create constraint programs, subsequently solved to find a new, optimal configuration, within a feed-back loop. This constraint program was also extended, allowing conduits and countermeasures to be dynamically activated and defining critical applications that cannot be stopped. A similar constraint program was also created to assign application instances to host device under memory constraints, with variants prioritizing either quality or resilience. Furthermore, heuristic approaches have been defined, to quickly obtain solutions for large scale systems, without quality guarantees however. The possible use of the reconfiguration constraint program as a means of moving target defense, by degrading the score of previously encountered application-device associations, is also discussed.

The base control reconfiguration is then tested on a Fischertechnik learning factory, showing that it is applicable, and almost seamless when applied on such a small scale. Quality and resilience of the configuration provided by the reconfiguration mechanism and its variants were also tested on generated system descriptions, demonstrating the potential to significantly increase robustness against multiple device compromises. The results reveal a trade-off between maximizing the score (as in, the quality of service) of the reconfigured system and ensuring that critical applications remain operational, both when reconfiguring and
<figure><img src="image_13.png" /><figcaption>Figure 13: Comparison of mean score achieved (with 95% confidence interval error bars) for each type of preemptive score assignment. Only takes into account found configurations in the mean computation.</figcaption></figure>

when selecting preemptive assignment strategies.

## 5.2 Perspectives

While this article presents a reconfiguration approach based on application migration, it focuses on a small part of the process. As seen in Figure 3, we mainly presented the means of obtaining the next configuration, i.e. the reconfiguration controller and the ZAD or ZCAD system model. This leaves several points of extension:

* As stated in Section 3.1, to create our system model, we need a complete description of the plant, in a format conforming with IEC 62443's Zone/Conduit model. In our case, we developed a domain specific language (DSL), in order to fulfill this need [22]. We may want to formally present the interconnection between this DSL and the reconfiguration process in the future.

* The reconfiguration process works on the assumption that applications' contexts can be migrated. This capacity is handled by abstract backup controllers shown in Figure 3, one of the loop's actuators, that take snapshots of their respective application's state regularly, and can be ordered to transfer a snapshot's content to a new execution location. We plan to formalize a method to add context switching capabilities to PLC application, and to create corresponding backup controllers capable of reading, storing and writing this context.

* Another actuator in the loop concerns firewall filter rules reconfiguration, also shown in Figure 3. The objective is to only allow communications explicitly part of the plant model, blocking everything else, and this should remain true when applications are migrated. We have ongoing work regarding an automatic method creating necessary rules on firewalls based on plant description, and deriving necessary rule changes from the results of the reconfiguration presented here.

On another hand, we also aim to apply this reactive process to part of a real industrial plant. This would allow us both a more realistic use case, as well as a template from which we could derive better generated examples. As explained beforehand, the current generated plant models are only abstractly similar to real installations.
Bibliography

[1] Stephen McLaughlin et al. "The cybersecurity landscape in industrial control systems".
In: Proceedings of the IEEE 104.5 (2016), pp. 1039-1057.

[2] Thomas M Chen and Saeed Abu-Nimeh. "Lessons from stuxnet".
In: Computer 44.4 (2011), pp. 91-93.

[3] Tiago Cruz et al. "Security implications of SCADA ICS virtualization: Survey and future trends".
In: Proc. 15th Eur. Conf. Cyber Warfare Security (ECCWS). 2016, pp. 74-83.

[4] IEC 62443 Part 1-1: Terminology, concepts and models. Tech. rep.
International electronical commission, 2009.
URL: https://webstore.iec.ch/preview/info_iec62443-1-1%7Bed1.0%7Den.pdf.

[5] Aris Kanellopoulos and Kyriakos G Vamvoudakis.
"A moving target defense control framework for cyber-physical systems".
In: IEEE Transactions on Automatic Control 65.3 (2019), pp. 1029-1043.

[6] Paul Griffioen, Sean Weerakkody, and Bruno Sinopoli.
"A moving target defense for securing cyber-physical systems".
In: IEEE Transactions on Automatic Control 66.5 (2020), pp. 2016-2031.

[7] Bradley Potteiger, Zhenkai Zhang, and Xenofon Koutsoukos. "Integrated instruction set randomization and control reconfiguration for securing cyber-physical systems". In: Proceedings of the 5th Annual Symposium and Bootcamp on Hot Topics in the Science of Security. 2018, pp. 1-10.

[8] Syrine Ben Meskina et al.
"Reconfiguration-based methodology for improving recovery performance of faults in smart grids".
In: Information Sciences 454 (2018), pp. 73-95.

[9] Salim Chehida et al.
"A model-based approach for self-adaptive security in CPS: Application to smart grids".
In: Journal of Systems Architecture 150 (2024), p. 103118.

[10] Hunor Sándor et al.
"Cyber attack detection and mitigation: Software defined survivable industrial control systems".
In: International Journal of Critical Infrastructure Protection 25 (2019), pp. 152-168.

[11] JJ Verbakel et al. "Legend pattern calculation for dynamic traffic management using ILP".
In: 2023 IEEE 19th International Conference on Automation Science and Engineering (CASE). IEEE. 2023, pp. 1-7.

[12] Gui-lin Cai et al. "Moving target defense: state of the art and characteristics".
In: Frontiers of Information Technology & Electronic Engineering 17.11 (2016), pp. 1122-1153.

[13] Jung-Shian Li et al. "Design of Industrial Control System Secure Communication Using Moving Target Defense with Legacy Infrastructure." In: Sensors & Materials 33 (2021).

[14] Matheus Torquato, Paulo Maciel, and Marco Vieira.
"Analysis of VM migration scheduling as moving target defense against insider attacks".
In: Proceedings of the 36th Annual ACM Symposium on Applied Computing. 2021, pp. 194-202.

[15] Alicia Rubio and Rafael Ors. "A comparative analysis of the reliability of simple and two-level checkpointing techniques in two different distributed industrial control system architectures".
In: Systems Analysis Modelling Simulation 43.7 (2003), pp. 945-957.

[16] Mark A Flood and Odo J Struger. "Real-time Backup Systems for Programmable Controllers".
In: IEEE Transactions on Industrial Electronics 4 (1982), pp. 265-268.

[17] Jim Luo et al. "A quad-redundant plc architecture for cyber-resilient industrial control systems".
In: IEEE Embedded Systems Letters 13.4 (2020), pp. 218-221.
[18] Andrei Simion and Calin Bira. "A review of redundancy in PLC-based systems". In: *Advanced Topics in Optoelectronics, Microelectronics, and Nanotechnologies XI* 12493 (2023), pp. 269-276.

[19] Gwenaël Delaval et al. "Discrete Control of Response for Cybersecurity in Industrial Control". In: *IFAC-PapersOnLine* 53.2 (2020). 21st IFAC World Congress, pp. 1747-1754. ISSN: 2405-8963.
DOI: https://doi.org/10.1016/j.ifacol.2020.12.2295.
URL: https://www.sciencedirect.com/science/article/pii/S2405896320329554.

[20] Jeffrey O Kephart and David M Chess. "The vision of autonomic computing". In: *Computer* 36.1 (2003), pp. 41-50.

[21] Laurent Perron and Frédéric Didier. *CP-SAT*. Version v9.8. Google, Nov. 15, 2023.
URL: https://developers.google.com/optimization/cp/cpSolution/.

[22] Jolahn Vaudey et al. "An IEC 62443-security oriented domain specific modelling language". In: *Proceedings of the 19th International Conference on Availability, Reliability and Security*. 2024, pp. 1-10.

# 1 References Table

<table><thead><tr><td>Author</td><td>Objective</td><td>Action</td><td>Relevant decision mechanism</td></tr></thead><tbody><tr><td>Kanellopoulos et al.</td><td>MTD</td><td>Parameter alteration</td><td>Ø</td></tr><tr><td>Griffioen et al.</td><td>MTD</td><td>Parameter alteration</td><td>Ø</td></tr><tr><td>Potteiger et al.</td><td>MTD</td><td>Instruction set randomization</td><td>Ø</td></tr><tr><td>Meskina et al.</td><td>Reconfiguration</td><td>Adding line to smart grid</td><td>Knapsack / progDyn</td></tr><tr><td>Chehida et al.</td><td>Reconfiguration</td><td>Application mode switching</td><td>Constraint programming</td></tr><tr><td>Sandor et al.</td><td>Reconfiguration</td><td>Device isolation</td><td>Integer Programming</td></tr><tr><td>Cai et al.</td><td>Reconfiguration</td><td>Legend assignments</td><td>Constraint programming</td></tr><tr><td>Li et al.</td><td>MTD</td><td>SDN and address rewriting</td><td>Ø</td></tr><tr><td>Torquato et al.:</td><td>MTD</td><td>VM migration</td><td>Round robin</td></tr><tr><td>Rubio et al.:</td><td>Fault tolerance</td><td>checkpoint stored in two locations</td><td>Ø</td></tr><tr><td>Flood et al.</td><td>Reconfiguration</td><td>Backup PLC</td><td>Predetermined</td></tr><tr><td>Luo et al.</td><td>Reconfiguration</td><td>Redundant backup PLCs</td><td>Predetermined</td></tr><tr><td>Delaval et al.</td><td>Reconfiguration</td><td>Application migration</td><td>Discrete Controller Synthesis</td></tr><tr><td>This paper</td><td>Reconfiguration</td><td>Application migration</td><td>Constraint/Linear programming</td></tr></tbody></table>

# 2 Constraint Program Variables

<table><thead><tr><td>Variable</td><td>Type</td><td>Integer values</td><td>Used in</td><td>Meaning</td></tr></thead><tbody><tr><td>run<sub>a,d</sub></td><td>B</td><td>[0..1]</td><td>All Constraint Programs</td><td>application <i>a</i> runs on device <i>d</i></td></tr><tr><td>none<sub>a</sub></td><td>B</td><td>[0..1]</td><td>All Constraint Programs</td><td>application <i>a</i> is stopped</td></tr><tr><td>in<sub>a,z</sub></td><td>B</td><td>[0..1]</td><td>All Constraint Programs</td><td>application <i>a</i> runs in zone <i>z</i></td></tr><tr><td>active<sub>c</sub></td><td>B</td><td>[0..1]</td><td>Extended Constraint Program</td><td>state of conduit <i>c</i></td></tr><tr><td>active<sub>m</sub></td><td>B</td><td>[0..1]</td><td>Extended Constraint Program</td><td>state of countermeasure <i>m</i></td></tr></tbody></table>