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

HAL
open science

# Reconfiguration of Firewall Filter Rules as a Response to Industrial Control System Intrusion

Jolahn Vaudey, Stéphane Mocanu, Gwenaël Delaval, Eric Rutten

► To cite this version:

Jolahn Vaudey, Stéphane Mocanu, Gwenaël Delaval, Eric Rutten. Reconfiguration of Firewall Filter Rules as a Response to Industrial Control System Intrusion. SICSI 2025 - 1st IEEE International Workshop on Secure Industrial Control Systems and Industrial-IoT, Aug 2025, Avignon, France. pp.1-6. hal-05260039

HAL Id: hal-05260039

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

Submitted on 15 Sep 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_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Reconfiguration of Firewall Filter Rules as a Response to Industrial Control System Intrusion

Jolahn Vaudey

Stéphane Mocanu

Gwenaël Delaval

Eric Rutten

Univ. Grenoble Alpes, CNRS, Inria, Grenoble INP*, LIG, 38 000 Grenoble, France

*Institute of Engineering Univ. Grenoble Alpes

firstname.lastname@inria.fr

**Abstract**—In recent years, industrial control systems (ICS) have become a target of choice for cybercriminals. In turn, developing new defense mechanisms against intrusions in ICS has become a necessity. In a previous work, we created a reaction framework, able to reconfigure a system under attack by migrating applications away from compromised host devices. Since communication within an ICS should be heavily filtered to prevent anomalous commands, we need to redefine these filters to match our new configurations. In this paper, from a formal description of the IEC 62443 compliant ICS under study, we aim to automate the creation of all necessary filter rules, and the adaptation to application migration and device isolation. This approach is tested on a small scale installation supervising a physical process with industrial hardware.

## I. INTRODUCTION

### A. Industrial control systems

On an industrial plant, the industrial control systems (ICS) are a network of dedicated hardware and software controlling physical processes. Typically, they include Programmable Logic Controllers (PLC), rugged computers with dedicated programming languages to host industrial applications. Historically, ICS lacked cybersecurity measures as communication were strictly internal. Nowadays, their increased connectivity, use of legacy protocols, and management of critical processes made them a target of choice for cyberattacks [1]. As a reaction, research regarding defense against attacks in industrial systems is a highly active field nowadays. In Operational Technology (OT) cybersecurity, which includes ICS, the aim is to maintain system availability first and foremost, as interruptions of control over physical processes are extremely hazardous and/or costly. To assist in the development and maintenance of secure ICS, the IEC 62443 standard was created.

### B. IEC 62443 standard

The IEC 62443 is a set of standards, dedicated to the cybersecurity of ICS. It spans multiple parts, covering the

whole process of designing the system, from the concept phase to the disposal. In this paper, we will only use a model defined in its first part IEC 62443-1-1, [2], with additional details from IEC 62443-3-2 [3].

In this Zone/Conduit model, the plant is divided into zones. Components within a zone can be physical devices or applications and are supposed to have similar security requirements. Applications need to be run on a compatible device in the same zone.

Each communication between two zones must pass through conduits. These conduits are defined by the set of zones they link. Each conduit is further divided in channels, each corresponding to a communication over the parent conduit between components in different zones.

In order to detect anomalies, the model also requires all potential dataflows in the system, as in (source, destination, protocol) tuples, to be listed.

### C. Objective

Using models defined in the IEC 62443 standards, especially the Zone/Conduit model for ICS layouts, we aim to design a reactive mechanism able to reconfigure the system while under attack. This reconfiguration mainly entails the migration of control programs away from compromised components, as well as the deactivation of communication conduits. The main goal is to maintain system availability, and gracefully degrade performances as devices are attacked. The approach is illustrated in Figure 1. It consists in a MAPE-K loop (Monitor-Analyze-Plan-Execute over a shared Knowledge), which we will now detail.

The system is **monitored** by an intrusion detection system (IDS), which aims to detect attacked components. The reconfiguration mechanism is started whenever this IDS detects a compromised device in the system. The **analysis** consists in finding a new valid configuration for the system. A constraint program (CP) is created, whose decision variables are the conduits' states (activated or not) and the applications' execution locations. The constraints ensure that any solution to the CP is a valid system state. Additionally, a maximization objective ensures the found solution is optimal with regards to system availability. This step is the focus of another

<footnote>This work has been partially supported by the French National Research Agency under the France 2030 label (Superviz ANR-22-PECY-0008). The views reflected herein do not necessarily reflect the opinion of the French government.</footnote>
<figure><img src="image_3.png" /><figcaption>Fig. 1: The overall research topic: ICS reconfiguration as an autonomous control loop.

paper [4]. The **planning** phase computes the necessary system modifications to achieve this new configuration. In particular, changing application locations requires altering firewall filter rules to maintain communication, which **will be the focus of this article**. Finally, the **execution** phase is heavily implementation dependent. For firewall reconfiguration, it requires executing model-specific commands on the firewall to change filter rules.</figcaption></figure>

As stated, while this work is part of the overarching reactive mechanism, it focuses on the reconfiguration of filter rules in firewalls specifically. Our objective will therefore be twofold:

* Based on the Zone/Conduit model for our system, we must be able to automatically derive the list of filter rules that may be necessary in any valid configuration, using the description of dataflows.

* Afterwards, based on the current state of the system (Application-Device assignments and conduits states), we must be able to decide which filter rules should be active automatically.

## II. RELATED WORKS

A survey by [5] shows ICS cybersecurity research focuses primarily on intrusion detection systems (IDS), which are the first line of defense against attacks. Our reconfiguration mechanism also needs an IDS to detect compromised devices. Our contribution lies however in the less explored field of reaction to attacks, barely touched upon in the survey. Reconfiguration of firewalls within a system as a response to attacks has already been researched for virtualized IT systems. In [6], a method employing optimization algorithms for automatically designing optimal network layouts is adapted, adding new constraints to the optimization program when a part of the system is attacked, and running it again to find a new configuration. Apart from this paper, the firewall (re)configuration studies found in the literature are mostly about finding optimal firewall rules placement in virtualized networks. For instance, [7] places firewalls and rules in a system using formal methods, taking a representation of the system and security requirements as input. Other kinds of network reconfiguration are used

as a defense mechanism: in [8], a moving target defense technique is devised, changing the protocols employed and the layout of a virtualized network to change the attack surface and thus impair attackers.

In our use case, when a new configuration is computed, applications may be moved, and conduits may be deactivated. Additionally, we need to isolate compromised devices. This means that, to automate the overall reconfiguration process, we need an automatic reconfiguration of firewall filter rules across the system to conform to new configurations. Compared to the literature, our approach is specific to systems following a Zone/Conduit layout. As shown in a previous paper [4], we also use optimization algorithms to find new system configuration from a formal definition of the system, in a manner similar to [6]. However, our set of decision variables concerns the location of applications within the system and the state of conduits, and we will present how to derive the needed modifications on network configuration from this output. As no preexisting solution applies to the studied systems, we needed to devise our own firewall reconfiguration procedure.

## III. RESILIENT FIREWALL RECONFIGURATION

### A. System configuration model

Inspired by the IEC 62443 standard Zone/Conduit system, we will employ a system model where components are grouped into zones by similar security needs and/or functionalities. Communication across zones must pass through conduits, which are filtered by firewalls. As stated in [4], our research consists of defining a reconfiguration method, able to redistribute control applications over the system whenever a device is compromised. We will only use a fraction of the model, focusing on parts relevant for firewall reconfiguration. The system is represented as a tuple ZCHAD (Zones, Conduits, Hosts, Applications and Dataflows).

Here, $Zones (z \in Z)$ are defined by a subnet address **adr**(z) and mask **mask**(z); **Conduits** ($c \in C$) link sets of zones (**links**(c)) and have an active state **active**(c); **Hosts** ($h \in H$) have an IP address **adr**(h) and location **loc**(h); **Applications** ($a \in A$) are defined by their execution location **exloc**(a) and compatible hosts **comp**(a); and **Dataflows** ($d \in D$) describe each allowed communication by its source **src**(d), destination **dst**(d), and protocol. From these, we derive the set of potential source hosts **srcs**(d) and destination hosts **dsts**(d) in the following manner:

For any $d \in D$, if **src**(d) is a host device (**src**(d) $\in H$), **srcs**(d) = {**src**(d)}, and if it is an application (**src**(d) = $a \in A$), **srcs**(d) = **comp**(**src**(d)). The same reasoning applies for computing **dsts** from **dst**.

### B. Derivation of Firewall objects and rules

1) **Hosts and networks:** To allow for online firewall reconfiguration, the first step is to define, on the firewall,
all the potential rules that can be activated. In our case, on the specific firewall used, we have to define hosts and networks prior to rules. The translation from the model is straightforward: each zone defines a network with the same name, subnet IP address and mask, while each host device gives a host with the same name and IP address.

2) Filter rules: As for filter rules, depending on the granularity of control, we may need to assume that all communications, even within a zone, must go through a firewall. This means that each zone and conduit is assumed to contain a firewall, filtering any communication that passes through them. Therefore, filter rules will need to be assigned to specific sets of firewalls. Here, we will use an hypothesis on the application-device reconfiguration process: communication may only pass through at most one conduit. Also, assume that any communication not explicitly allowed is denied by default. With this in mind, one set of rules is always needed: for each host device, a rule blocking any outgoing traffic, to activate when the device is compromised. This prevents the attacker from using the compromised device as an intermediate, to attack other parts of the system. Two other sets of rules can be alternatively used depending on the level of control needed, either at conduit or at channel level. We will now formalize these three sets of rules.

If the set of dataflows is not exhaustive, or in order to limit the amount of modifications to the system, one may only apply rules related to which conduit is active, meaning:

* For each zone $z$, a rule allowing connection starting and ending in the corresponding subnet.

* for each conduit $c$, a rule allowing communication starting from any of the networks it connects, and ending in any of them.

These rules are shown in Table I:

<table><caption>TABLE I: Conduit-based rules</caption><thead><tr><th></th><th>Source</th><th>Destination</th><th>Protocol</th><th>Action</th></tr></thead><tbody><tr><td>$\forall z \in Z$</td><td>adrl(z)/z:mask</td><td>adrl(z):z:mask</td><td>ANY</td><td>ALLOW</td></tr><tr><td>$\forall c \in C$</td><td>adrl(z<sub>1</sub>)/mask(z<sub>1</sub>)</td><td>adrl(z<sub>2</sub>)/mask(z<sub>2</sub>)</td><td>ANY</td><td>ALLOW</td></tr><tr><td>$\forall z1 \neq z2 \in links(c)$</td><td></td><td></td><td></td><td></td></tr></tbody></table>

Do note that duplicate rules are not inserted: if two different conduits both link two given zones, only a single corresponding rule is created.

If a conduit-based rule concerns communication between two zones $z_1$ and $z_2$, it is assigned to firewalls as follows:

* if $z_1 = z_2$, only the zone's firewall needs to contain the filter rule.

* if $z_1 \neq z_2$ however, it must be assigned to the firewalls of both $z_1$ and $z_2$, as well as to any conduit linking $z_1$ and $z_2$, which translates as: $\{c \in C | z_1 \in \textbf{links}(c) \wedge z_2 \in \textbf{links}(c)\}$.

On the other hand, we may want to implement more precise firewall rules corresponding to active channels. Here, we need to create one for each possible couple of host machines and/or applications that may need to communicate after any reconfiguration. Therefore, we

need to define the set of potential channels that may be activated, a subset of the Cartesian product of hosts $H^2$ that we will name *Channels*. For a more precise filtering, we will also add another element $p$ at the end of the tuple, indicating the protocol this channel allows. A channel $(h_1, h_2, p)$ is present in *Channels* if and only if:

$$ \exists d \in D : h_1 \in \text{srcs}(d) \wedge h_2 \in \text{dsts}(d) \wedge \text{protocol}(d) = p \\ \wedge (\text{loc}(h_1) = \text{loc}(h_2) \vee \exists c \in C : \text{loc}(h_1), \text{loc}(h_2) \in \text{links}(c)) $$

The corresponding rules can be found in Table II.

<table><caption>TABLE II: Channel-based rules</caption><thead><tr><th></th><th>Source</th><th>Destination</th><th>Protocol</th><th>Action</th></tr></thead><tbody><tr><td>$\forall (h_1, h_2, p) \in \text{Channels}$</td><td>adrl(h<sub>1</sub>)</td><td>adrl(h<sub>2</sub>)</td><td>p</td><td>ALLOW</td></tr></tbody></table>

These rules are not compatible with the prior conduit-based rules, which would authorize by default all communications through an active conduit, or within the same zone.

Let us consider a channel-based rule, concerning communication between two hosts $h_1$ and $h_2$, with $\text{loc}(h_1)$ denoted as $z_1$ and $\text{loc}(h_2)$ as $z_2$. This filter rule is assigned to firewalls in the exact same manner as conduit-based rules:

* if $z_1 = z_2$, as in $h_1$ and $h_2$ are in the same zone, only the zone's firewall needs to contain the filter rule.

* if $z_1 \neq z_2$ however, it must be assigned to the firewalls of both $z_1$ and $z_2$, as well as to any conduit linking $z_1$ and $z_2$, which translates as: $\{c \in C | z_1 \in \textbf{links}(c) \wedge z_2 \in \textbf{links}(c)\}$.

On top of either set of filters, we need to define rules disabling all outgoing communications from any given host, used to isolate compromised ones. They are defined in Table III.

<table><caption>TABLE III: Host device isolation rules</caption><thead><tr><th></th><th>Source</th><th>Destination</th><th>Protocol</th><th>Action</th></tr></thead><tbody><tr><td>$\forall h \in H$</td><td>adrl(h)</td><td>ANY</td><td>ANY</td><td>DENY</td></tr></tbody></table>

The isolation rule for a given host $h$ only needs to be assigned to the firewall of zone $\text{loc}(h)$.

### C. Firewall reconfiguration

Now that all these rules are defined, all that remains is to decide which ones are active for a given configuration. This must be done both statically for the initial configuration, and whenever a cycle of the loop shown in Figure 1 occurs. As stated before, firewall reconfiguration is derived from the application-device assignments, which are the actual decision variables for finding a new configuration. As such, this section describes the behaviour of an actuator in the loop, shown at the bottom of the figure.

Concerning host isolation (see Table III), computing it is trivial. The starting point of a reconfiguration cycle being the detection by an IDS of a compromised host, the corresponding isolation rule must be activated. If
communications are filtered at a conduit level (see Table I), computing the active rules is still simple. For each pair of zone $z_1, z_2 \in Z^2$, if there is a corresponding filter rule, activate it iff there is a corresponding active conduit:

$$ \exists c \in C : \mathbf{active}(c) \wedge z_1, z_2 \in \mathbf{links}(c) $$

If we remain at the conduit level, same zone communications are never stopped.

On the other hand, if communications are filtered at the channel level, a rule concerning hosts $h_1$ and $h_2$, with a certain protocol $p$ is only active if this type of communication initiated from $h_1$, going to $h_2$ is actually expected. This means that, there exists a dataflow, for which the destination and source are currently located on $h_1$ and $h_2$ respectively. In a more formal manner, this filter is only active if there exists a dataflow $d$, such that:

$$ ((\mathbf{src}(d) \in H \wedge \mathbf{src}(d) = h_1) \vee (\mathbf{src}(d) \in A \wedge \mathbf{exloc}(\mathbf{src}(d)) = h_1)) \wedge ((\mathbf{dst}(d) \in H \wedge \mathbf{dst}(d) = h_2) \vee (\mathbf{dst}(d) \in A \wedge \mathbf{exloc}(\mathbf{dst}(d)) = h_2)) $$

Apart from the level of information required in the system description, the main difference between these two approaches is the number of filter rules whose state must be updated each time a reconfiguration occurs. If we remain at the conduit level, very few modifications need to be made, thus our reaction to attacks is faster, albeit less precise. The channel-based approach has the opposite qualities. A compromise can also be considered, with filter rules based on conduits, but activation/deactivation based on active dataflows rather than the state of conduits, achieving a middle ground for both metrics. In that case, communication from zone $z_1$ to zone $z_2$ is allowed iff there is at least one corresponding dataflow $d$ such that:

$$ ((\mathbf{src}(d) \in H \wedge \mathbf{loc}(\mathbf{src}(d)) = z_1) \vee (\mathbf{src}(d) \in A \wedge \mathbf{loc}(\mathbf{exloc}(\mathbf{src}(d))) = z_1)) \wedge ((\mathbf{dst}(d) \in H \wedge \mathbf{loc}(\mathbf{dst}(d)) = z_2) \vee (\mathbf{dst}(d) \in A \wedge \mathbf{loc}(\mathbf{exloc}(\mathbf{dst}(d))) = z_2)) $$

# IV. EXPERIMENTAL SETUP

## A. Setup presentation

1) Fischertechnik learning factory: As our main use case, we employ a Fischertechnik learning factory [9]. It is a small scale installation imitating an industrial control system: it implements a physical process, and is controlled in our case by four Programmable Logic Controllers (PLC), each managing a part of the process. This division translates to our Zone/Conduit model, shown in Figure 2.

On this system, we can migrate tasks from one PLC to another when a host is compromised. To allow this, I/Os are managed by remote terminal units (RTU), allowing read and write operations through Modbus TCP/IP.

The system's reconfiguration is managed as a MAPE-K control loop [10], illustrated on Figure 1.

<figure><img src="image_4.png" /><figcaption>Fig. 2: Fischertechnik learning factory represented as a zone/conduit schema. Each application is, in the default configuration, executed on the PLC within its zone. A dataflow's orientation shows which element initiate the communication.</figcaption></figure>

2) Stormshield Firewall: A single SNI20 [11] Stormshield firewall was used in the experimental setup, at the crossroads of every communication. The firewall provides stateful filters, used to allow only communications initiated by the source, and a command line interface (CLI) to edit filter rules. As long as a firewall possesses these characteristics, we can automatize, from a system description, the associated network reconfiguration shown in Section III-C. Do note however, that typically each conduit in a normal ICS should be filtered by a dedicated firewall, containing only relevant rules, as defined in Section III-B2.

## B. Resulting model

We will now translate the zone/conduit system shown in Figure 2 to the ZCHAD tuple described in Section III-A:

* $Z = \{MPO, HBW, GRIP, SORT\}$

* $C = \{\{HBW, GRIP\}, \{MPO, GRIP\}, \{SORT, GRIP\}, \{SORT, MPO\}, \}$

* $H = \{PLC1, PLC2, PLC3, PLC4, RTU1, RTU2, RTU3, RTU4\}$

* $A = \{a_{MPO}, a_{HBW}, a_{GRIP}, a_{SORT}\}$

* $D = \{a_{MPO} \mapsto RTU1, a_{MPO} \mapsto a_{SORT}, a_{HBW} \mapsto RTU2, a_{GRIP} \mapsto RTU3, a_{GRIP} \mapsto RTU4, a_{GRIP} \mapsto a_{HBW}, a_{SORT} \mapsto RTU4\}$

Note that RTUs are defined as hosts in this model, but cannot actually run any application.

When translated to Firewall rules, $|H| = 8$ rules are created for host isolation. Then, if the granularity is at a conduit level, 12 rules are created to allow communication: $|Z| = 4$ for same zone communication, and $2 * |C| = 8$ for communication across a conduit. In this case, every rule is active in the initial configuration, and the corresponding interconnection graph is shown on Figure 3.

If, on the other hand, we create rules at the channel level, we need to also know application-device compatibility. Here, $comp(a_{MPO}) = comp(a_{GRIP}) = comp(a_{SORT}) = \{PLC1, PLC3, PLC4\}$ and $comp(a_{HBW}) = \{PLC2, PLC3\}$.

Using this, every potential dataflow is added, without adding duplicates. For instance, $a_{MPO} \mapsto RTU1$ defines three different filters as $a_{MPO}$ may change location:
<figure><img src="image_5.png" /><figcaption>Fig. 3: Graph of zone interconnections, at a conduit level. PLC1 $\mapsto$ RTU1, PLC3 $\mapsto$ RTU1 and PLC4 $\mapsto$ RTU1. In total, 18 rules (+3 rules for self communication) are defined for this example, with the theoretical maximum being $|H|^2 = 64$. The resulting graph is shown on Figure 4.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 4: Graph of hosts potential interconnections. Each arrow corresponds to a filter rule.</figcaption></figure>

### C. Example attack and results

As an example, assume that an alert is raised, indicating that PLC4 is compromised. Once the reconfiguration process has taken place, PLC4 is isolated from the network, $a_{SORT}$, which ran on PLC4, is executed on PLC3 and the conduit between SORT and MPO is deactivated.

Looking at it through the lens of conduit-level filtering and aside from isolating PLC4, the only effect on the rules is to stop communications between zone MPO and zone SORT, resulting in the configuration shown on Figure 5.

<figure><img src="image_7.png" /><figcaption>Fig. 5: Graph of zones interconnections after PLC4 compromise.</figcaption></figure>

On the other hand, following Section III-C, for the channel based filters, the rules PLC1 $\rightarrow$ PLC4 and PLC4 $\rightarrow$ RTU4 are now inactive, while PLC1 $\rightarrow$ PLC3 and the isolation rule for PLC4 are now active, resulting in the configuration shown in Figure 6.

To finish this section, we evaluated how many changes need to be applied to firewalls rules, depending on the type of filtering implemented and which PLC is attacked. The results can be seen in Table IV. As expected, conduit-based filters lead to the least changes, channel-based to the most, and the hybrid approach strikes a middle ground.

<figure><img src="image_8.png" /><figcaption>Fig. 6: Graph of hosts interconnections after PLC4 compromise.</figcaption></figure>

<table><caption>TABLE IV: Number of filter rule changed when specified host is attacked in the initial configuration.</caption><thead><tr><td>Host</td><td>Conduit</td><td>Channel</td><td>Conduit rules, Channel change</td></tr></thead><tbody><tr><td>PLC1</td><td>2</td><td>6</td><td>4</td></tr><tr><td>PLC2</td><td>0</td><td>4</td><td>1</td></tr><tr><td>PLC3</td><td>2</td><td>6</td><td>4</td></tr><tr><td>PLC4</td><td>2</td><td>3</td><td>3</td></tr></tbody></table>

### D. Discussion on metric and scaling

This small-scale use case, while useful for showcasing the method on a readable example, does not allow us to test its applicability on larger, more realistic industrial control systems. Here, larger would imply the presence of more zones, hosts, applications, and most importantly several firewalls. While the assignment of filter rules to specific firewalls was discussed in Section III-B2, it could not be applied there.

To allow for larger scale experiments, we need to find metrics able to evaluate either the reconfiguration process, or the firewall configurations themselves.

In our case, key performance metrics are latency, throughput, reconfiguration time, and the number of rule changes. Latency is bounded, as packets cross at most three firewalls, and industrial firewalls offer latency upper bounds guarantees. Throughput is not a key concern for typical ICS traffic. Reconfiguration time depends on computation (which scales well) and CLI communication. The latter is a potential bottleneck, mitigated by simultaneous communication to multiple firewalls, and is also heavily correlated to the number of rules changed. Therefore, we will use the latter as a hardware-independent metric for our scalability analysis, that can be tested on synthetic examples.

### E. Filter rules change in synthetic examples

As stated in the previous section, the number of filter rules changed by the reconfiguration can be computed based on theoretical model, without needing a larger physical or simulated model. We will therefore use this metric as a basis for studying system size effect on our reconfiguration process. First, we need to define the type of synthetic systems we will generate.

1) Synthetic plant shapes: In general, we will create systems of size *n*, comprised of *n* zones, each containing two devices, each initially running two applications. These zones may be connected by conduits in one of two types of shape: a “Shapeless” type, where *n* conduits link random
zones, and a “Tree-like” type, inspired by SCADA systems,
and following a strict hierarchy for zones in the shape of
a binary tree, as seen in Figure 7.

<figure><img src="image_9.png" /><figcaption>Fig. 7: Illustration of “Tree-like” synthetic systems structure.</figcaption></figure>

Additionally, we will define a difficulty for the generated problems, either easy (redundant capacity: all applications can be kept active) or hard (need to stop some applications).

2) *Evaluation*: We generated 30 synthetic systems for each size $n \in \{4, 6, 8, 10\}$, for all combinations of problem difficulty and shape. The evolution of the number of filter rules that need to be changed after a random host device is attacked, based on the type and difficulty of the generated plant, is shown in Figure 8.

An important observation is that, in most cases, system size does not have an influence on the number of modifications. In fact, it only impacts the number of changes when the new optimal configuration is very different from the previous one. This number is still heavily dependant on the granularity employed when defining filter rules, with channel based rules leading to the most changes, followed by hybrid ones, and conduit-based rules typically causing the fewest changes.

Our approach appears to scale well, as the number of rule changes is largely independent of system size. However, as channel-based rules number scales with the amount of dataflows, the hybrid approach may be preferable for heavily interconnected systems.

V. CONCLUSION

In this article, we devised which filter rules should be deployed in an IEC-62443 compliant system based on a formal description, with different granularity levels. Then, we created a policy for modifying filter rules within a firewall based on the system configuration changes. This approach was applied both to a physical use case and to theoretical systems of varying sizes, showcasing the difference between filtering granularity levels.

As for perspectives, we would mainly want to experiment on a larger, probably simulated, use case. In our example, all communications within the system pass through a single, Stormshield SNI20 firewall. While

<figure><img src="image_10.png" /><figcaption>Fig. 8: Evolution of number of filter rules to change after a device is attacked, depending on filter rule granularity and types of generated problems.

appropriate due to our installation's relative size, a larger scale experiment should be run on a bigger testbed, allocating a different firewall in each conduit and zone. An increase in scale would also allow us to confirm the impact on performance of the three types of filter rules, as tested on synthetic examples. We also plan to evaluate performance against more complex attacks targeting multiple components simultaneously.</figcaption></figure>

REFERENCES

[1] S. McLaughlin, C. Konstantinou, X. Wang, L. Davi, A.-R. Sadeghi, M. Maniatakos, and R. Karri, "The cybersecurity landscape in industrial control systems," Proceedings of the IEEE, vol. 104, no. 5, pp. 1039-1057, 2016.

[2] "IEC 62443 part 1-1: Terminology, concepts and models," International electronical commission, Tech. Rep., 2009.

[3] "IEC 62443 part 3-2: Security risk assessment and system design," International electronical commission, Tech. Rep., 2020.

[4] J. Vaudey, S. Mocanu, G. Delaval, and E. Rutten, "Self-reconfiguration of industrial control systems as a response to cyberattacks," in *2024 IEEE 10th International Conference on Network Softwarization (NetSoft)*. IEEE, 2024, pp. 375-380.

[5] J. E. Rubio, C. Alcaraz, R. Roman, and J. Lopez, "Current cyber-defense trends in industrial control systems," Computers & Security, vol. 87, p. 101561, 2019.

[6] D. Bringhenti, F. Pizzato, R. Sisto, and F. Valenza, "Autonomous attack mitigation through firewall reconfiguration," International Journal of Network Management, vol. 35, no. 1, p. e2307, 2025.

[7] D. Bringhenti, G. Marchetto, R. Sisto, F. Valenza, and J. Yusupov, "Automated firewall configuration in virtual networks," IEEE Transactions on Dependable and Secure Computing, vol. 20, no. 2, pp. 1559-1576, 2022.

[8] J. B. Hong, S. Yoon, H. Lim, and D. S. Kim, "Optimal network reconfiguration for software defined networks using shuffle-based online mtd," in *2017 IEEE 36th Symposium on Reliable Distributed Systems (SRDS)*. IEEE, 2017, pp. 234-243.

[9] Fischertechnik, "Fischerteknik learning factory 4.0," https://www.fischertechnik.de/en/products/industry-and-universities/training-models/554868-training-factory-industry-4-0-24v (Feb. 2025).

[10] J. O. Kephart and D. M. Chess, "The vision of autonomic computing," Computer, vol. 36, no. 1, pp. 41-50, 2003.

[11] Stormshield, "Stormshield Sni20 Firewall," https://www.stormshield.com/produits/sni20/ (Mar. 2025).