Industrial Control Systems Security via Runtime Enforcement

Industrial Control Systems (ICSs) are physical and engineered systems whose operations are monitored, coordinated, controlled, and integrated by a computing and communication core [57]. They represent the backbone of Critical Infrastructures for safety-critical applications such as electric power distribution, nuclear power production, and water supply.

The growing connectivity and integration in Industry 4.0 have triggered a dramatic increase in the number of cyber-physical attacks [32] targeting ICSs, i.e., security breaches in cyberspace that adversely affect the physical processes. Some notorious examples are: (i) the Stuxnet worm, which reprogrammed Siemens PLCs of nuclear centrifuges in the nuclear facility of Natanz in Iran [36]; (ii) the CRASHOVERRIDE attack on the Ukrainian power grid, otherwise known as Industroyer [62]; (iii) the recent TRITON/TRISIS malware that targeted a petrochemical plant in Saudi Arabia [19].

One of the key components of ICSs is Programmable Logic Controllers, better known as PLCs. They control mission-critical electrical hardware such as pumps or centrifuges, effectively serving as a bridge between the cyber and the physical worlds. PLCs have a simple ad-hoc architecture based on a central processing module (CPU) and further modules supporting physical inputs and outputs. The CPU executes the operating system of the PLC and runs a logic program defined by the user, called the user program, which executes simple repeating processes known as scan cycles (IEC 61131-3 [1]). Each scan cycle consists of three phases: (i) reading of sensor measurements of the physical process; (ii) execution of the controller code to compute how the physical process should evolve; (iii) transmission of commands to the actuator devices to govern the physical process as desired.

Due to their sensitive role in controlling industrial processes, the successful exploitation of PLCs can have severe consequences on ICSs. In fact, although modern controllers provide security mechanisms to allow only legitimate firmware to be uploaded, the running code can be typically altered by anyone with network or USB access to the controllers (see Figure 1). Published scan data shows how thousands of PLCs are directly accessible from the Internet to improve efficiency [56]. Thus, despite their responsibility, controllers are vulnerable to several kinds of attacks, including PLC-Blaster worm [63], Ladder Logic Bombs [28], and PLC PIN Control attacks [5].

Extra trusted hardware components have been proposed to enhance the security of PLC architectures [48, 50]. For instance, McLaughlin [48] proposed a policy-based enforcement mechanism to mediate the actuator commands transmitted by the PLC to the physical plant. Mohan et al. [50] introduced a different architecture, in which every PLC runs under the scrutiny of a monitor which looks for deviations with respect to safe behaviors. Both architectures have been validated by means of simulation-based techniques. However, as far as we know, only in recent years have formal methodologies been used to model and formally enforce security-oriented architectures for ICSs.

Runtime enforcement [22, 43, 60] is a formal verification/validation technique aiming at correcting possibly-incorrect executions of a system-under-scrutiny (SuS). It employs a kind of monitor [23] that acts as a proxy between the SuS and the environment interacting with it. At runtime, the monitor transforms any incorrect executions exhibited by the SuS into correct ones by either replacing, suppressing, or inserting observable actions on behalf of the system. The effectiveness of the enforcement depends on the achievement of the two following general principles [43, 60]:

In this article, we propose a formal approach based on runtime enforcement to ensure specification compliance in networks of controllers possibly compromised by colluding malware that may tamper with actuator commands, sensor readings, and inter-controller communications. As pointed out by Pearce et al. [53], the use of runtime enforcement for ensuring security can be thought of as behavior monitoring misuse and anomaly detection models [17] combined with automatic recovery mechanisms.

Our goal is to enforce potentially corrupted controllers using secure proxies based on a sub-class of Ligatti et al.’s edit automata [43]. These automata will be synthesized from enforceable timed correctness properties to form networks of monitored controllers, as in Figure 2. The proposed enforcement will enjoy both transparency and soundness together with the following features:

Obviously, when a controller is compromised, these objectives can be achieved only with the introduction of a physically independent secure proxy, as advocated by McLaughlin and Mohan et al. [48, 50], which does not have any Internet or USB access, and which is connected with the monitored controller via secure channels. This may seem like we just moved the problem over to securing the proxy. However, this is not the case because the proxy only needs to enforce a timed correctness property of the system, while the controller does the whole job of controlling the physical process relying on potentially dangerous communications via the Internet or the USB ports. Thus, any upgrade of the control system will be made to the controller and not to the secure proxy. Of course, by no means runtime reconfigurations of the secure proxy should be allowed as its enforcing should be based on the physics of the plant itself and not on the controller code (only periodic offline updates are allowed to account for possible system drifts).

Contribution. First of all, we define the attacker model and the attacker objectives in an enforced ICS architecture such as that depicted in Figure 2. Then, we introduce a formal language to specify controller programs. For this very purpose, we resort to process calculi, a successful and widespread formal approach in concurrency theory for representing complex systems, such as mobile systems [16, 29] and cyber-physical systems [37, 42], and used in many areas, including verification of security protocols [3, 4] and security analysis of cyber-physical attacks [40, 41]. Thus, we define a simple timed process calculus, based on Hennessy and Regan’s Timed Process Language (TPL) [30], for specifying controllers, finite-state enforcers, and networks of communicating monitored controllers.

Then, we define a simple description language to express timed correctness properties that should hold for a (possibly unbounded) number of scan cycles of the monitored controller. This will allow us to abstract over controller implementations, focusing on general properties which may even be shared by completely different controllers. In this regard, we might resort to one of the several logics existing in the literature for monitoring timed concurrent systems, and in particular cyber-physical systems (see, e.g., [9, 24]). However, the peculiar iterative behavior of controllers convinced us to adopt the sub-class of regular expressions that can be recognized by finite automata whose cycles always contain at least one final state; this is the largest class of regular properties that can be enforced by finite-state Ligatti et al.’s edit automata (see Beauquier et al.’s work [10]). In Section 5, we express a wide class of correctness properties for controllers in terms of such regular properties.

After defining a formal language to describe controller properties, we provide a synthesis function \({\langle \!| \!{-}\! | \! \rangle ^{\mathcal {P}} }\) that, given an alphabet \(\mathcal {P}\) of observable actions (sensor readings, actuator commands, and inter-controller communications) and a deterministic regular property e combining events of \(\mathcal {P}\) , returns an edit automaton \({\langle \!| \!{e}\! | \! \rangle ^{\mathcal {P}} }\!\) . The resulting enforcement mechanism will ensure the required features mentioned before: transparency, soundness, determinism preservation, deadlock-freedom, divergence-freedom, mitigation, and scalability. Then, we propose a non-trivial case study, taken from the context of industrial water treatment systems, and implemented as follows: (i) the physical plant is simulated in Simulink [47]; (ii) the open-source PLCs are implemented in OpenPLC [8] and executed on Raspberry Pi; (iii) the enforcers run on connected FPGAs. In this setting, we test our enforcement mechanism when injecting the PLCs with five different malware aiming at causing three different physical perturbations: tank overflow, valve damage, and pump damage.

Outline. Section 2 describes the attacker model and the attacker objectives. Section 3 gives a formal language for monitored controllers. Section 4 defines the case study. Section 5 provides a language of regular properties to express controller behaviors; it also contains a taxonomy of properties expressible in the language. Section 6 contains the algorithm to synthesize monitors from regular properties, together with the main results. Section 7 discusses the implementation of the case study when exposed to five different attacks. Section 8 is devoted to related work. Section 9 draws conclusions and discusses future work. Technical proofs can be found in the appendix.

Our enforcement-based architecture for ICSs (see Figure 2) assumes physically independent secure proxies connected to the controller via secure channels and no Internet or USB access.

In such secure architecture, the attacker can basically inject arbitrary code in the user program of PLCs. As a consequence, the attacker has the following capabilities on PLCs: (i) forge/drop actuator commands, (ii) read/modify sensor readings coming from the plant, (iii) forge/drop inter-controller communications. The malware injected in different PLCs of the same field communications network may collaborate/communicate with each other to achieve common objectives and possibly take control of the PLC network communication.

The attacker assumed in this article has the following two limitations.

Thus, the attacker objectives can be resumed in affecting the runtime evolution of the controlled physical process, possibly transmitting fake measurements to the supervisory control network.

In this section, we introduce the Timed Calculus of Monitored Controllers, called TCMC, as an abstract formal language to express networks of controllers integrated with edit automata sitting on the network interface of each controller to monitor/correct their interactions with the rest of the system. Basically, TCMC extends Hennessy and Regan’s TPL [30] with monitoring edit automata. Like TPL time proceeds in discrete time slots separated by \({\scriptstyle \mathsf {tick}}\) -actions.

Let us start with some preliminary notation. We use \(s, s_k \in \mathsf {Sens}\) to name sensor signals; \(a,a_k \in \mathsf {Act}\) to indicate actuator commands; \(c, c_k \in \mathsf {Chn}\) for channels; \(z, z_k\) for generic names.

Controllers. In our setting, controllers are nondeterministic sequential timed processes evolving through three main phases: sensing of sensor signals, communication with other controllers, and actuation. For convenience, we use five different syntactic categories to distinguish the five main states of a controller: \(\mathbb {C}{𝕥𝕣𝕝}\) for initial states, \(\mathbb {S}{𝕝𝕖𝕖𝕡}\) for sleeping states, \(\mathbb {S}{𝕖𝕟𝕤}\) for sensing states, \(\mathbb {Com}\) for communication states, and \(\mathbb {Act}\) for actuation states. In its initial state, a controller is a recursive process waiting for signal stabilization in order to start the sensing phase:

The main process describing a controller consists of some recursive process defined via equations of the form \(X = {\scriptstyle \mathsf {tick}}.W\) , with \(W \in \mathbb {S}{𝕝𝕖𝕖𝕡}\) ; here, X is a process variable that may occur (free) in W. For convenience, our controllers always have at least one initial timed action \({\scriptstyle \mathsf {tick}}\) to ensure time-guarded recursion, thus avoiding undesired zeno behaviors [31]: the number of untimed actions between two \({\scriptstyle \mathsf {tick}}\) -actions is always finite. Then, after a determined sleeping period, when sensor signals get stable, the sensing phase can start.

During the sensing phase, the controller waits for a finite number of admissible sensor signals. If none of those signals arrives in the current time slot then the controller will timeout moving to the following time slot (we adopt the TPL construct \(\lfloor \cdot \rfloor \cdot\) for timeout). The syntax is the following:where \(\sum _{i \in I} s_i.S_i\) denotes the standard construct for nondeterministic choice with \(s_k \ne s_h\) , for \(k,h \in I\) . Once the sensing phase is concluded, the controller starts its calculations that may depend on communications with other controllers governing different physical processes. Controllers communicate with each other for mainly two reasons: either to receive notice about the state of other physical sub-processes or to require an actuation on a physical process which is out of their control. As in TPL, we adopt a channel-based handshake point-to-point communication paradigm. Note that, in order to avoid starvation, communication is always under timeout. The syntax for the communication phase iswhere \(\lfloor \sum _{i \in I}c_i.C_i \rfloor C\) denotes nondeterministic input choice under timeout, with \(c_k \ne c_h\) for \(k,h \in I\) , whereas \(\lfloor \overline{c}.C \rfloor C\) represents output along channel c under timeout.

In the actuation phase, a controller eventually transmits a finite sequence of commands to actuators, and then, it emits a fictitious system signal \({\scriptstyle \mathsf {end}}\) to denote the end of the scan cycle. After that, the whole scan cycle can restart. Notice that, while \({\scriptstyle \mathsf {tick}}\) -actions model the passage of (discrete) time, \({\scriptstyle \mathsf {end}}\) -actions have a different granularity, as they signal the end of a scan cycle. Formally,

The operational semantics in Table 1 is along the lines of Hennessy and Regan’s TPL [30]. In the following, we use the metavariable \(\alpha\) to range over the set of all (observable) controller actions: \(\mathsf {Sens}\cup \overline{\mathsf {Act}} \cup \mathsf {Chn}\cup \overline{\mathsf {Chn}} \cup \lbrace {\scriptstyle \mathsf {tick}}\rbrace \cup \lbrace {\scriptstyle \mathsf {end}}\rbrace\) .¹ These actions denote: sensor readings, actuator commands, channel transmissions, channel receptions, passage of time, and end of scan cycles, respectively. Notice that at our level of abstraction we represent only the observable behavior of PLCs: internal computations are not modeled within PLCs; although, we do have \(\tau\) -actions to express communications between two PLCs, as the reader will notice in Table 2.

Monitored controllers. The core of our enforcement relies on (timed) finite-state Ligatti et al.’s edit automata [43], i.e., a particular class of automata specifically designed to allow/suppress/insert actions in a generic system in order to preserve its correct behavior. The syntax is as follows:

The special automaton \({\sf go}\) will admit any action of the monitored system. The edit automaton \(\sum _{i \in I} \lambda _i.\mathsf {E}_i\) enforces an action \(\lambda _i\) , and then continues as \(\mathsf {E}_i\) , for any \(i \in I\) , with I finite. Here, the symbol \(\lambda\) ranges over: (i) \(\alpha\) to allow the action \(\alpha\) , (ii) \(^-\alpha\) to suppress the action \(\alpha\) , and (iii) \(\alpha _1 \prec \alpha _2\) , for \(\alpha _1 \ne \alpha _2\) , to insert the action \(\alpha _1\) before the action \(\alpha _2\) . Recursive automata \(\mathsf {X}\) are defined via equations of the form \(\mathsf {X} = \mathsf {E}\) , where the automata variable \(\mathsf {X}\) may occur (free) in \(\mathsf {E}\) .

The operational semantics of our edit automata is given via the following transition rules:

Our monitored controllers, written \(\mathsf {E} \! \bowtie \! {\boldsymbol { \lbrace }}J{\boldsymbol { \rbrace }}\) , consist of a controller J, for \(J \in \mathbb {C}{𝕥𝕣𝕝} \cup \mathbb {S}{𝕝𝕖𝕖𝕡} \cup \mathbb {S}{𝕖𝕟𝕤} \cup \mathbb {C}{𝕠𝕞𝕞} \cup \mathbb {Act}\) , and an edit automaton \(\mathsf {E}\) enforcing the behavior of J, according to the following transition rules, presented in the style of Martinelli and Matteucci [45]:Rule (Allow) is used for allowing observable actions emitted by the controller under scrutiny. By an application of Rule (Suppress), incorrect actions \(\alpha\) emitted by (possibly corrupted) controllers J are suppressed, i.e., converted into (silent) \(\tau\) -actions. Rule (Insert) is used to insert an action \(\alpha _1\) before an action \(\alpha _2\) of the controller.

Here, we wish to stress that, like Ligatti et al. [43], we are interested in deterministic (and hence implementable) enforcement. With the following technical definitions we extract from enforcer actions \(\lambda\) both: (i) the controller triggering actions, and (ii) the resulting output actions.

Now, we provide a definition of deterministic enforcer along the lines of Pinisetty et al. [54].

Finally, we can generalize the concept of the monitored controller to a field communications network of parallel monitored controllers, each one acting on different actuators, and exchanging information via channels. These networks are formally defined via a straightforward grammar:with the operational semantics defined in Table 2.

Notice that monitored controllers may interact with each other via channel synchronization (see Rule (ChnSync)). Moreover, via rule (TimeSync) they may evolve in time only when channel synchronization may not occur (our controllers do not admit zeno behaviors). This ensures maximal progress [30], a desirable time property when modeling real-time systems: channel communications will never be postponed.

In the following, the metavariable \(\beta\) will range over the same set of actions as \(\alpha\) , together with the silent action \(\tau\) . It is used to denote actions of monitored field networks.

In the rest of the article, we adopt the following notations.

In this section, we describe how to specify in TCMC a non-trivial network of PLCs to control (a simplified version of) the Secure Water Treatment system (SWaT) [46].

SWaT represents a scaled down version of a real-world industrial water treatment plant. The system consists of six stages, each of which deals with a different treatment, including: chemical dosing, filtration, dechlorination, and reverse osmosis. For simplicity, in our use case, depicted in Figure 3, we consider only three stages. In the first stage, raw water is chemically dosed and pumped in a tank \(T_1\) , via two pumps \(\mathit {pump}_1\) and \(\mathit {pump}_2\) . A valve connects \(T_1\) with a filtration unit that releases the treated water in a second tank \(T_2\) . Here, we assume that the flow of the incoming water in \(T_1\) is greater than the outgoing flow passing through the valve. The water in \(T_2\) flows into a reverse osmosis unit to reduce inorganic impurities. In the last stage, the water coming from the reverse osmosis unit is either distributed as clean water, if required standards are met, or stored in a backwash tank \(T_3\) and then pumped back, via a pump \(\mathit {pump}_3\) , to the filtration unit. Here, we assume that tank \(T_2\) is large enough to receive the whole content of tank \(T_3\) at any moment.

The SWaT system has been used to provide a dataset containing physical and network data recorded during 11 days of activity [27]. Part of this dataset contains information about the execution of the system in isolation, while a second part records the effects on the system when exposed to different kinds of cyber-physical attacks. Thus, for instance, (i) drops of commands to activate \({\it pump}_2\) may affect the quality of the water, as they would affect the correct functioning of the chemical dosing pump; (ii) injections of commands to close the valve between \(T_1\) and \(T_2\) , may give rise to an overflow of tank \(T_1\) if this tank is full; (iii) integrity attacks on the signals coming from the sensor of the tank \(T_3\) may result in damages of the pump \(\mathit {pump}_3\) if it is activated when \(T_3\) is empty.

Each tank is controlled by its own PLC. The programs of the three PLCs, expressed in terms of ladder logic, are given in Figure 4. In the following, we give their descriptions in TCMC.

Let us start with the user program of the controller \(\mathrm{PLC}_1\) managing the tank \(T_1\) . Its definition is given in terms of two equations to deal with the case when the two pumps, \(\mathit {pump}_1\) and \(\mathit {pump}_2\) , are both off and both on, respectively. Intuitively, when the pumps are off, the level of water in \(T_1\) drops until it reaches its low-level (event \(l_1\) ); when this happens both pumps are turned on and they remain so until the tank is refilled, reaching its high-level (event \(h_1\) ). Formally,Thus, for instance, when the pumps are off the \(\mathrm{PLC}_1\) waits for one-time slot (to get stable sensor signals) and then checks the water level of the tank \(T_1\) , distinguishing between three possible states. If \(T_1\) reaches its low-level (signal \(l_1\) ) then the pumps are turned on (commands \(\overline{ {\mathsf {\scriptstyle on_{1}}} }\) and \(\overline{ {\mathsf {\scriptstyle on_{2}}} }\) ) and the valve is closed (command \({\mathsf {\scriptstyle { {\mathsf {\scriptstyle close}} }{\_}req}}\) ). Otherwise, if the tank \(T_1\) is at some intermediate level between low and high (say, some level \(m_1\) ) then \(\mathrm{PLC}_1\) listens for requests arriving from \(\mathrm{PLC}_2\) to open/close the valve. Precisely, if the PLC gets an \({\mathsf {\scriptstyle {open}{\_}req}}\) request then it opens the valve, letting the water flow from \(T_1\) to \(T_2\) , otherwise, if it gets a \({\mathsf {\scriptstyle {close}{\_}req}}\) request then it closes the valve; in both cases, the pumps remain off. If the level of the tank is high (signal \(h_1\) ) then the requests of water coming from \(\mathrm{PLC}_2\) are served as before, but the two pumps are eventually turned off (commands \(\scriptstyle \overline{\mathsf {off}_1}\) and \(\scriptstyle \overline{\mathsf {off}_2}\) ).

\(\mathrm{PLC_2}\) manages the water level of tank \(T_2\) . Its user program consists of the two equations to model the filling (state \(\uparrow\) ) and the emptying (state \(\downarrow\) ) of the tank. Formally,

Here, after one-time slot, the level of \(T_2\) is checked. If the level is low (signal \(l_2\) ) then \(\mathrm{PLC}_2\) sends a request to \(\mathrm{PLC}_1\) , via the channel \({\mathsf {\scriptstyle {open}{\_}req}}\) , to open the valve that lets the water flow from \(T_1\) to \(T_2\) , and then returns. Otherwise, if the level of tank \(T_2\) is high (signal \(h_2\) ) then \(\mathrm{PLC}_2\) asks \(\mathrm{PLC}_1\) to close the valve, via the channel \({\mathsf {\scriptstyle {close}{\_}req}}\) , and then returns. Finally, if the tank \(T_2\) is at some intermediate level between \(l_2\) and \(h_2\) (say, some level \(m_2\) ) then the valve remains open (respectively, closed) when the tank is refilling (respectively, emptying).

Finally, \(\mathrm{PLC_3}\) manages the water level of the backwash tank \(T_3\) . Its user program consists of two equations to deal with the case when the pump \(\mathit {pump}_3\) is off and on, respectively. Formally,

Here, after one-time slot, the level of tank \(T_3\) is checked. If the level is low (signal \(l_3\) ) then \(\mathrm{PLC}_3\) turns off the pump \(\mathit {pump}_3\) (command \(\scriptstyle \overline{ {\mathsf {\scriptstyle off_{3}}} }\) ), and then returns. Otherwise, if the level of \(T_3\) is high (signal \(h_3\) ) then the pump is turned on (command \(\scriptstyle \overline{ {\mathsf {\scriptstyle on_{3}}} }\) ) until the whole content of \(T_3\) is pumped back into the filtration unit of \(T_2\) .

Examples of correctness properties and attacks. In a system similar to that described above, one would expect a number of properties to capturing the correct functioning of system components. Let us provide a few examples of such correctness properties and some specific attacks that may potentially invalidate these properties.

A first property might say that if \(\mathrm{PLC}_1\) receives a request to open the valve between tanks \(T_1\) and \(T_2\) then the same valve will be eventually closed early enough to prevent water overflow in tank \(T_2\) . This property certainly holds when the system is not exposed to any attack. However, a malware injected in \(\mathrm{PLC}_1\) might try to undermine this property by tampering either with the actuator dedicated to the valve or with the requests of \(\mathrm{PLC}_2\) to open/close the valve. In particular, a malicious request to open the valve might be forged by an attacker injected in \(\mathrm{PLC}_2\) . Another desired correctness property might say that whenever the tank \(T_2\) is full then \(\mathrm{PLC}_2\) will never ask for incoming water from tank \(T_1\) . Finally, another expected property might say that \(\mathit {pump}_3\) will never work without enough water in tank \(T_3\) . Again, an attacker injected in \(\mathrm{PLC}_3\) might try to undermine this property by tampering either with the actuator dedicated to the pump or with the sensor measuring the level of tank \(T_3\) .

In Section 7.3 we will provide formal definitions for patterns template of structured correctness properties that are suitable for enforcing correct behaviors of our PLCs.

In this section, we provide a simple description language to express correctness properties that we may wish to enforce at runtime in our controllers. As discussed in the Introduction, we resort to (a sub-class of) regular properties as they allow us to express interesting classes of properties referring to one or more scan cycles of a controller.

The proposed language distinguishes between two kinds of properties: (i) global properties, \(e \in \mathbb {P}{𝕣𝕠𝕡}\mathbb{G}\) , to express general controllers’ execution traces; (ii) local properties, \(p \in \mathbb {P}{𝕣𝕠𝕡}\mathbb{L}\) , to express traces confined to a finite number of consecutive scan cycles. The two families of properties are formalized via the following regular grammar:where \(\pi _i \in \mathsf {Events}\triangleq \mathsf {Sens}\cup \overline{\mathsf {Act}} \cup \mathsf {Chn}\cup \overline{\mathsf {Chn}} \cup \lbrace {\scriptstyle \mathsf {tick}}\rbrace \cup \lbrace {\scriptstyle \mathsf {end}}\rbrace\) denote atomic properties, called events, that may occur as prefix of a property. With an abuse of notation, we use the symbol \(\epsilon\) to denote both the empty property and the empty trace.

The semantics of our logic is naturally defined in terms of sets of execution traces that satisfy a given property; its formal definition is given in Table 3.

However, the syntax of our logic is a bit too permissive with respect to our intentions, as it allows us to describe partial scan cycles, i.e., cycles that have not been completed. Thus, we restrict ourselves to considering properties that builds on top of local properties associated with complete scan cycles, i.e., scan cycles whose last action is an \({\scriptstyle \mathsf {end}}\) -action. Formally,

In the rest of the article, we always assume to work with well-formed properties. Moreover, we adopt the following notations and/or abbreviations on properties.

Note that our properties are in general nondeterministic. However, since we are interested in deterministic enforcers, in the following we will focus on deterministic enforcing properties.

In this section, we provide an algorithm to synthesize monitors from regular properties whose events are contained in (the set of events associated with) a fixed set \(\mathcal {P}\) of observable controller actions. More precisely, given a global property \(e \in \mathbb {P}{𝕣𝕠𝕡}\mathbb{G}\) the algorithm returns an edit automaton \(\langle \! | \! e \! | \! \rangle _{}^{\mathcal {P}} \in \mathbb {E}{𝕕𝕚𝕥}\) that is capable to enforce the property e during the execution of a generic controller whose possible actions are confined to those in \(\mathcal {P}\) . The synthesis algorithm is defined in Table 5 by induction on the structure of the global/local property given in input; as we distinguish global properties from local ones, we define our algorithm in two steps.

The monitor \(\langle \! | \! p^{\ast } \! | \! \rangle _{}^{\mathcal {P}}\) associated with a global property \(p^{\ast }\) is an edit automaton defined via the recursive equation \(\mathsf {X} = { \langle \! | p | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}\) , to recursively enforce the local property p. The monitor \(\langle \! | \!e_1\cap e_2\! | \! \rangle _{}^{\mathcal {P}}\) is given by the cross product between the edit automata \(\langle \! | e_1 | \! \rangle _{}^{\mathcal {P}}\) and \(\langle \! | e_2 | \! \rangle _{}^{\mathcal {P}}\) , to accept only traces that satisfy both \(e_1\) and \(e_2\) ; the definition of the cross product between two edit automata recalls that for finite state automata, and it is reported in the appendix in Table 6. The monitor \({{ \langle \! | \! p_1\cap p_2 \! | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}}\) is given by the cross product between the edit automata \({{ \langle \! | p_1 | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}}\) and \({{ \langle \! | p_2 | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}}\) . The monitor \({{ \langle \! | p_1;p_2 | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}}\) is given by the automaton \({{ \langle \! | p_1 | \! \rangle _{\mathsf {Z}}^{\mathcal {P}}}}\) , where \(\mathsf {Z} = {{ \langle \! | p_2 | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}}\) ; basically \(\mathsf {Z}\) ties the final states of the automaton enforcing \(p_1\) with the initial state of the automaton enforcing \(p_2\) (e.g., \({{ \langle \! | \epsilon ;p_2 | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}} = {{ \langle \! | \epsilon | \! \rangle _{\mathsf {Z}}^{\mathcal {P}}}} = \mathsf {Z}\) , for \({\mathsf {Z}} = {{ \langle \! | p_2 | \! \rangle _{\mathsf {X}}^{\mathcal {P}}}}\) ). The monitor associated with a union property \(\bigcup _{i\in I}\pi _i.p_i\) does the following: (i) allows all actions associated with the events \(\pi _i\) , (ii) inserts an action associated with some admissible event \(\pi _i\) only when the controller wishes to prematurely complete the scan cycle, i.e., it emits an \({\scriptstyle \mathsf {end}}\) -action, and (iii) suppresses any other action except for \({\scriptstyle \mathsf {tick}}\) - and \({\scriptstyle \mathsf {end}}\) -actions.

Thus, the mitigation of the enforcement is actually implemented in the monitors synthesized from union properties. In practice, when the controller under scrutiny complies with the property enforced by the monitor, the two components, monitor and controller, evolve in a tethered fashion (by applying rule (Allow)), moving through related correct states. However, if the controller gets somehow corrupted (for instance, due to the presence of a malware) then the two components will get misaligned reaching unrelated states. In this case, the enforcer mitigates the attack by suppressing the remaining actions emitted by the controller (by applying rule (Suppress)) until the controller reaches the end of the scan cycle, signaled by the emission of the \({\scriptstyle \mathsf {end}}\) -action.³ After that, if the monitor and controller are not aligned the monitor will command the insertion of a safe trace, without any involvement of the controller, via one or more applications of the rule (Insert). Safe traces inserted in full autonomy by our enforcers always terminate with an \({\scriptstyle \mathsf {end}}\) . Thus, when both the controller and the monitor will be aligned, at the end of the scan cycle, they will synchronize on the action \({\scriptstyle \mathsf {end}}\) , via an application of the rule (Allow), and from then on they may continue in a tethered fashion.

Note that, according to Remark 1, even when the controller is completely unreliable and the monitor inserts an entire safe trace, the enforced scan cycle always will end well before a violation of the maximum cycle limit.

Now, we calculate the complexity of the synthesis algorithm based on the number of occurrences of the operator \(\cap\) in e and the dimension of e, \(\mathsf {dim}(e)\) , i.e., the number of all operators occurring in e. Intuitively, the size of a property is given by the number of operators occurring in it.

In the following, we prove that the enforcement induced by our synthesized monitors enjoys the properties stated in the Introduction: determinism preservation, transparency, soundness, deadlock-freedom, divergence-freedom, and scalability. In this section, with a small abuse of notation, given a set of observable actions \(\mathcal {P}\) , we will use \(\mathcal {P}\) to denote also the set of the corresponding events.

Given a deterministic global property e, our synthesis algorithm returns a deterministic enforcer (according to Definition 2), i.e., an enforcer that can be effectively implemented. Formally,

Let us move to transparency. Intuitively, the enforcement induced by a deterministic property \(e \in \mathbb {P}{𝕣𝕠𝕡}\mathbb{G}\) should preserve any execution trace satisfying e itself (Definition 2 at page 5 of [43]).

Basically, conclusion (1) says that all execution trace t (of a controller P) satisfying the enforcing property e are allowed by the associated enforcer \({\langle \!| \!{e}\! | \! \rangle ^{\mathcal {P}} }\!\) , while conclusion (2) says that allowing the trace t is the only possible option in the enforcement (this follows by the determinism of e).

Another important property of our enforcement is soundness [43]. Intuitively, a controller under the scrutiny of a monitor \({\langle \!| \!{e}\! | \! \rangle ^{\mathcal {P}} }\) should only yield execution traces, which satisfy the enforced property e, i.e., execution traces which are consistent with its semantics \({[\!\![} e{]\!\!]}\) (up to \(\tau\) -actions).

Here, it is important to stress that in general soundness does not ensure the deadlock-freedom of the monitored controller. That is, it may be possible that the enforcement of some property e causes a deadlock of the controller P under scrutiny. In particular, this may happen in our controllers only when the initial sleeping phase does not match the enforcing property (e.g., \(P={\scriptstyle \mathsf {tick}}.c.{\scriptstyle \mathsf {end}}.P\) and \(e=(c.{\scriptstyle \mathsf {end}})^\ast\) ). Intuitively, a local property will be called a k-sleeping property if it allows k initial time instants of sleep. Formally,

The enforcement of k-sleeping properties does not introduce deadlocks in k-sleeping controllers. This is because our synthesized monitors suppress all incorrect actions of the controller under scrutiny, driving it to the end of its scan cycle. Then, the controller remains on stand-by while the monitor yields a safe sequence of actions to mimic a safe completion of the current scan cycle.

Another important property of our enforcement mechanism is divergence-freedom. In practice, the enforcement does not introduce divergence: monitored controllers will always be able to complete their scan cycles by executing a finite number of actions. This is because we limit our enforcement to well-formed properties (Definition 4) which always terminates with an \({\scriptstyle \mathsf {end}}\) event. In particular, the well-formedness of local properties ensures us that in a global property of the form \(p^\ast\) the number of events within two subsequent \({\scriptstyle \mathsf {end}}\) events is always finite.

Notice that all properties seen up to now scale to field communications networks of controllers. This means that they are preserved when the controller under scrutiny is running in parallel with other controllers in the same field communications network. As an example, by an application of Theorems 1 and 2, we show how both transparency and soundness scale to field networks. A similar result applies to the remaining properties.

In this section, we propose an implementation of our enforcement mechanism in which monitors, running on field-programmable gate arrays (FPGAs) [65], enforce open-source PLCs [8], running on Raspberry Pi devices [25], and governing a physical plant simulated in Simulink [47] (see Figure 8). The section has the following structure. In Section 7.1, we argue why FPGAs are good candidates for implementing secure proxies. In Section 7.2, we describe how we implemented the whole enforcement architecture for the use case of Section 4. In Section 7.3, we test our implementation by injecting the enforced PLCs with five different malware aiming at causing three different physical perturbations: tank overflow, valve damage, and pump damage. The attacks have been chosen to cover as much as possible the attacker model of Section 2. In particular, they include: a drop of the actuator commands of the valve, an integrity attack on the water-level sensors, a forgery of the actuator commands of the valve, a forgery of the message requests to open/close the valve, and a forgery of the actuator commands of the pumps. Section 7.4 discusses the performance of our implementation.

The notion of runtime enforcement was introduced by Schneider [60] to enforce security policies via truncation automata, a kind of automata that terminates the monitored system in case of violation of the property. Thus, truncation automata can only enforce safety properties. Furthermore, the resulting enforcement may obviously lead to deadlock (actually termination) of the monitored system with no room for mitigation.

Ligatti et al. [43] studied a hierarchy of enforcement mechanisms, each with different transformational capabilities: Schneider’s truncation automata, suppression automata, insertion automata, and finally, edit automata that combine the power of suppression and insertion automata. Edit automata are capable of enforcing instances of safety and liveness properties, along with other properties such as renewal properties [12, 43]. Ligatti et al. defined different notions of enforcement, and in particular the so called precise enforcement (Definition 2, page 5) which basically corresponds to the combination of our notion of transparency and soundness, proved in Theorems 1 and 2, respectively. Our enforcers differ from Ligatti et al.’s edit automata for the following three aspects. First, in general, the edit automata have an enumerable number of states, whereas in the current article, we restrict ourselves to finite-state edit automata. Second, Ligatti et al.’s edit automata can insert a non-empty string of symbols in a single step, whereas, without no loss of expressiveness, our enforcers can only insert one symbol per step (i.e., we will need multiple steps to insert a string of symbols). Third, Ligatti et al.’s edit automata are deterministic, in the sense that for any action of the system under scrutiny the enforcer admits only one possible output. In our article, we adopt Pinisetty et al. [54] notion of deterministic enforcer, in which the insertion has a certain degree of freedom since the inserted symbol is chosen within a set of admissible symbols. Despite these differences, we believe that when focusing on finite-state enforcers we are able to enforce the same set of correctness properties as Ligatti et al. [43].

Bielova and Massacci [12, 13] provided a stronger notion of enforceability by introducing a predictability criterion to prevent monitors from transforming invalid executions in an arbitrary manner. Intuitively, a monitor is said predictable if one can predict the number of transformations used to correct invalid executions. In our setting, in case of injection of a malware that may act in an unpredictable manner, this approach appears unfeasible.

Falcone et al. [21, 22] proposed a synthesis algorithm, relying on Streett automata, to translate most of the property classes defined within the safety-progress hierarchy [44] into (a slight variation of) edit automata. In the safety-progress hierarchy, our global properties can be seen as guarantee properties for which all execution traces that satisfy a property contain at least one prefix that still satisfies the property. However, it should be noticed that they consider untimed properties only; as already pointed out before, timed actions play a special role in our enforcement and they cannot be treated as untimed actions.

Beauquier et al. [10] proved that finite-state edit automata (i.e., those kinds of enforcers we are actually interested in) can only enforce a sub-class of regular properties. Actually, they can enforce all and only the regular properties that can be recognized using finite automata whose cycles always contain at least one final state. This is the case of our enforced regular properties, as well-formed local properties in \(\mathbb {P}{𝕣𝕠𝕡}\mathbb{L}\) always terminate with the “final” atomic property \({\scriptstyle \mathsf {end}}\) .

Pinisetty and Tripakis [55] studied the compositionality of the enforcement of different regular properties \(p_1, \ldots , p_n\) at the same time, by composing the associated enforcing monitors. The idea is to replace a monolithic approach, in which a monitor is synthesized from the property \(p_1 \cap \ldots \cap p_n\) , with a compositional one, where the n monitors enforcing the properties \(p_i\) are somehow put together to enforce \(p_1 \cap \ldots \cap p_n\) . The authors of [55] proved that runtime enforcement is not compositional with respect to general regular properties, neither with respect to serial nor parallel composition. On the other hand, compositionality holds for certain sub-classes of regular properties such as safety (or co-safety) properties. Here, we wish to point out that our notion of scalability is different from their notion of compositionality, as we aim at scaling our enforcement on a network of PLCs and not on multiple regular properties on the same PLC.

Bloem et al. [14] defined a synthesis algorithm that given a safety property returns a monitor, called a shield, to enforce untimed properties in reactive systems (which have many aspects in common with control systems). Their algorithm relies on a notion called k-stabilization: when the design reaches a state where a property violation becomes unavoidable for some possible future inputs, the shield is allowed to deviate for at most \(k \in \mathbb {N}\) steps; if a second violation happens during the k-step recovery phase, the shield enters a fail-safe mode where it only enforces correctness, but no longer minimizes the deviation. However, The k-stabilizing shield synthesis problem is unrealizable for many safety-critical systems, because a finite number of deviations cannot be guaranteed. Humphrey et al. [34] addressed this problem by proposing the notion of admissible shields which was extended and generalized in Könighofer et al. [35] by assuming that systems have a cooperative behavior with respect to the shield, i.e., the shield ensures a finite number of deviations if the system chooses certain outputs. The authors presented a synthesis procedure that maximizes the cooperation between system and environment for satisfying the required enforced properties. This approach has some similarities with our enforcement in which a violation of a property during a scan cycle induces the suppression of all subsequent controller actions until the PLC reaches the end of the scan, so the monitor can insert a safe trace before permitting the completion of the scan cycle.

Pinisetty et al. [54] proposed a bi-directional runtime enforcement mechanism for reactive systems, and more generally for cyber-physical relying on Berry and Gonthier’s synchronous hypothesis [11], to correct both inputs and outputs. Pinisetty et al. express safety properties in terms of Discrete Timed Automata (DTA) which are more expressive than our class of regular properties. Thus, an execution trace satisfies a required property only if it ends up on a final state of the corresponding DTA. However, as not all regular properties can be enforced [10], they proposed a more permissive enforcement mechanism that accepts execution traces as long as there is still the possibility of reaching a final state. Furthermore, due to the instantaneity of the synchronous approach, their enforcement actions are applied in the same reaction step to ensure reactivity. On the contrary, in our approach, the enforcement takes places before the conclusion of scan cycles which are clearly delimited via \({\scriptstyle \mathsf {end}}\) -actions. Our notion of deterministic enforcers is taken from Pinisetty et al. [54]. Moreover, when inserting safe actions, our synthesized enforcers follow Pinisetty et al.’s random edit approach, where the inserted safe action is randomly chosen from a list of admissible actions.

Pearce et al. [53] proposed a bi-directional runtime enforcement over valued signals for PLCs, by introducing smart I/O modules (similar to our secure proxy) between the PLCs and the controlled physical processes, to act as an effective line of defense. The authors express security properties in terms of Values Discrete Timed Automata (VDTA), inspired by the DTA of Pinisetty et al. [54]. Unlike DTA, VDTA support valued signals, internal variables, and guard conditions. As in Pinisetty et al. [54], the article adopts the synchronous hypothesis [11] to correct both inputs and outputs; thus, their enforcement actions are applied in the same reaction step to ensure instantaneous reactivity. The authors do not consider attacks that may tamper with inter-controller communications: their attackers may only manipulate sensor signals and/or actuator commands. Finally, their semantics requires that every enforcer knows the state of all relevant signals and commands in a given system. Thus, as written by the same authors, a networked system featuring multiple I/O modules may significantly complicate the enforcement, as pertinent I/O for a security policy may not be locally available. As a consequence, unlike us, their enforcement does not naturally scale to networks of controllers; we believe this is basically due to the fact that they do bi-directional enforcement. Last but not least, like them, we implement enforcers via FPGAs to ensure efficiency and security at the same time. In particular, when inserting safe actions our implementation fixes a priority between admissible safe actions, similarly to their selected edit approach. However, our implementation differs from theirs in at least the following aspects: (1) our FPGAs do enforce PLC transmissions (with a negligible latency); (2) our enforcement is uni-directional and hence our FPGAs need to know only the state of signals and commands of the corresponding enforced PLCs; (3) as a consequence, our FPGAs can be networked to monitor field communications networks paying only negligible overhead in terms of computational resources and communication latency.

Aceto et al. [6] developed an operational framework to enforce properties in HML logic with recursion ( \(\mu\) HML) relying on suppression only. More precisely, they achieved the enforcement of a safety fragment of \(\mu\) HML by providing a linear automated synthesis algorithm that generates correct suppression monitors from formulas. Enforceability of modal \(\mu\) -calculus (a reformulation of \(\mu\) HML) was previously tackled by Martinelli and Matteucci [45] by means of a synthesis algorithm which is exponential in the length of the enforceable formula. Cassar [18] defined a general framework to compare different enforcement models and different correctness criteria, including optimality. His works focuses on the enforcement of a safety fragment of \(\mu\) HML, paying attention to both uni-directional and bi-directional notions of enforcement. More recently, Aceto et al. [7] developed an operational framework for bi-directional enforcement and used it to study the enforceability of the aforementioned safety fragment of HML with recursion, via a specific type of bi-directional enforcement monitors called action disabling monitors.

As regards articles in the context of control system security closer to our objectives, McLaughlin [48] proposed the introduction of an enforcement mechanism, called \(\mathrm{C}^2\) , similar to our secure proxy, to mediate the control signals \(u_k\) transmitted by the PLC to the plant. Thus, like our secured proxy, \(\mathrm{C}^2\) is able to suppress commands, but unlike our proxy, it cannot autonomously send commands to the physical devices in the absence of a timely correct action from the PLC. Furthermore, \(\mathrm{C}^2\) does not cope with inter-controller communications, and hence with colluding malware operating on PLCs of the same field network.

Mohan et al. [50] proposed a different approach by defining an ad-hoc security architecture, called Secure System Simplex Architecture (S3A), with the intention to generalize the notion of “correct system state” to include not just the physical state of the plant but also the cyber state of the PLCs of the system. In S3A, every PLC runs under the scrutiny of a side-channel monitor which looks for deviations with respect to safe executions, taking care of real-time constraints, memory usage, and communication patterns. If the information obtained via the monitor differs from the expected model(s) of the PLC, a decision module is informed to decide whether to pass the control from the “potentially compromised” PLC to a safety controller to maintain the plant within the required safety margins. As reported by the same authors, S3A has a number of limitations comprising: (i) the possible compromising of the side channels used for monitoring, (ii) the tuning of the timing parameters of the state machine, which is still a manual process.

The present work is a revised extension of the conference version that appeared in [38]. Here, we provide a detailed comparison with that article. In Section 2 we specified the attacker model and the attacker objectives. In Section 3, we adopted a simplified operational semantics for edit automata, in the style of Martinelli and Matteucci [45]. In Section 5, we have extended our language of regular properties with the intersection of both local and global properties. With this extension we have expressed a wide family of correctness properties that can be combined in a modular fashion; these properties include and extend the three classes of properties appearing in the conference article. In Section 6, we have extended our synthesis algorithm to deal with our extended properties: both local and global intersection of properties are synthesized in terms of cross products of edit automata. Notice that, compared to the conference article, our enforcement mechanism does not rely anymore on an ad-hoc semantic rule (Mitigation) to insert safe actions at the end of the scan cycle, but rather on the more standard rule (Insert) together with the syntactic structure of synthesized enforcers. As stated in Proposition 1, now our synthesis algorithm depends on the size and the number of occurrences of intersection operators of the property in input. Last but not least, in this journal version we provide an implementation of our use case based on: (i) Simulink to simulate the physical plant, (ii) OpenPLC on Raspberry Pi to run open PLCs, and (iii) FPGAs to implement enforcers. We have then exposed our implementation to five different attacks targeting the PLCs and discussed the effectiveness of the proposed enforced mechanism.

In a preliminary work [39], we proposed an extension of our process calculus with an explicit representation for malware code. In that article, monitors are synthesized from PLC code rather than correctness properties. The focus of that article was mainly on: (i) deadlock-free enforcement, and (ii) intrusion detection via secure proxies. Here, it is worth pointing out that the work in [39] shares some similarities with supervisory control theory [15, 58], a general theory for the automatic synthesis of controllers (supervisors) for discrete event systems, given a plant model and a specification for the controlled behavior. Fabian and Hellgren [20] have pointed out a number of issues to be addressed when adopting supervisory control theory in industrial PLC-based facilities, such as causality, incorrect synchronization, and choice between alternative paths. However, our synthesis is plant-independent as it returns an enforcer from a given logical property (the plant does not play any role).

Finally, Yoong et al. [69] proposed a synchronous semantics for functions blocks, a component-oriented model at the core of the IEC 61499 international standard [2] used to design distributed industrial process measurement and control systems. In contrast to the scan cycle model followed in the current article (IEC 61131 [1]) prescribing the execution of a sequential portion of code at each scan cycle, the event-driven model for function blocks relies on the occurrence of asynchronous events to trigger program execution. Yoong et al. [69] adopted a synchronous approach to define an execution semantics to function blocks by translating them into a subset of Esterel [11], a well-known synchronous language. Here, we wish to point out that our PLC specification is given at a more abstract level compared to that of [69], and it complies with the sequential scan cycle standard IEC 61131, rather than the event-driven standard IEC 61499.

We have defined a formal language to express networks of monitored controllers, potentially compromised by colluding malware that may forge/drop actuator commands, modify sensor readings, and forge/drop inter-controller communications. The enforcing monitors have been expressed via a finite-state sub-class of Ligatti et al.’s edit automata. In this manner, we have provided a formal representation of field communications networks in which controllers are enforced via secure monitors, as depicted in Figure 2. The room of maneuver of attackers is defined via a proper attacker model. Then, we have defined a simple description language to express timed regular properties that are recognized by finite automata whose cycles always contain at least one final state (denoted via an \({\scriptstyle \mathsf {end}}\) -action). We have used that language to build up formal definitions for pattern templates suitable for expressing a broad family of correctness properties that can be combined in a modular fashion to prescribe precise controller behaviors. As an example, our description language allows us to capture all (bounded variants of the) controller properties studied in Frehse et al. [24]. Once defined a formal language to describe controller properties, we have provided a synthesis function \(\langle \!| \ \!-\!\ |\! \rangle\) that, given an alphabet \(\mathcal {P}\) of observable controller actions and a deterministic regular property e consistent with \(\mathcal {P}\) , returns a finite-state deterministic edit automaton \({\langle \!| \!{e}\! | \! \rangle ^{\mathcal {P}} }\) . The resulting enforcement mechanism will ensure the required features advocated in the Introduction: transparency, soundness, deadlock-freedom, divergence-freedom, mitigation, and scalability.

As a final contribution, we have provided a full implementation of a non-trivial case study in the context of industrial water treatment, where enforcers are implemented via FPGAs. In this setting, we showed the effectiveness our enforcement mechanism when exposed to five carefully-designed attacks targeting the PLCs of our use case.

As future work, we wish to test our enforcement mechanism in different domains, such as industrial and cooperative robotic arms (e.g., Kuka, ABB, Universal Robots) which are endowed with control architectures working at a fixed rate [61]. More generally, we would like to consider physical plants with significant uncertainties, in terms of measurements noise, possibly due to malicious alterations of sensor devices, and physical process uncertainty. To address such challenges we intend to integrate our secured proxies with physics-based attack detection mechanisms [17, 26] based on well-known control-theory algorithms to correctly estimate the state of the physical plant. Furthermore, notice that in the proposed enforced secure architecture all outputs of the monitored controllers are handled to the associated proxies via a dedicated logical connection. Thus, the secure proxy has full observability of the controller outputs. However, the measurements coming from the plants are much less reliable, as sensors devices are exposed to failures. So, we would like to extend our enforcement mechanism under the hypothesis of partial observability of the measurements, taking inspiration from the works by Yin and Lafortune [67, 68].

In order to prove the results of Section 6, in Table 6 we provide the technical definition of the cross product between two edit automata used in the synthesis of Table 5. As the first three cases are straightforward, we explain only the fourth case, the cross product associated with \(\mathsf {Prod}^{\mathcal {P}}_{\mathsf {Z}}(\sum _{i \in I}\lambda _i.\mathsf {E}_i,\sum _{j \in J}\nu _j.\mathsf {E}_j)\) Here, we use the abbreviation \(\lambda .\mathsf {E}\oplus \lambda ^{\prime }.\mathsf {E}\) to denote the automaton \(\lambda .\mathsf {E}+ \lambda ^{\prime }.\mathsf {E}\) , if \(\lambda \ne \lambda ^{\prime }\) , and, the automaton \(\lambda .\mathsf {E}\) , if \(\lambda = \lambda ^{\prime }\) . Thus, the product does the intersection of those addends \(\lambda _i.\mathsf {E}_i\) and \(\nu _j.\mathsf {E}_j\) , with \((i,j) \in H\) , for which: (a) the prefixes have the same output (e.g., \(\lambda _i=\alpha\) and \(\nu _j=\alpha \lt \alpha ^{\prime }\) ), (b) the prefixes are not suppressions, (c) the product of their continuations \(\mathsf {E}_i\) and \(\mathsf {E}_j\) “is not empty”, i.e., it is not a suppression-only automaton. For the other addends \(\lambda _i.\mathsf {E}_i\) and \(\nu _j.\mathsf {E}_j\) which do not comply with the above conditions (i.e., \((i,j) \not\in H\) ), the product results in a suppression-only automaton.

Let us prove the complexity of the synthesis algorithm formalized in Proposition 1. For that, we need three technical lemmata. The first lemma shows that our synthesis algorithm always returns an edit automaton in a specific canonical form.

By an application of Lemma 1, we derive a second lemma which extends a classical result on the complexity of the cross product of finite state automata to the cross product of (synthesized) edit automata.

The third lemma provides an upper bound to the number of derivates of the automaton \(\langle \! | e | \! \rangle _{}^{\mathcal {P}}\) .

In order to prove Theorem 1, we need to prove that the cross product between edit automata satisfies a standard correctness result saying that any execution trace associated with the intersection of two regular properties is also a trace of the cross product of the edit automata associated with the two properties, and vice versa.

In order to prove Theorem 2, we need a couple of technical lemmata.

In the next lemma, we prove that, given the execution traces of a monitored controller, we can always extract from them the traces performed by its edit automaton and its monitored controller in isolation.

We thank the anonymous reviewers for their insightful and careful reviews. We thank Adrian Francalanza, Yuan Gu, Davide Sangiorgi, and Marjan Sirjani for their comments on early drafts of the article.