Safety Graph: When Safety Responses Become Attack Surfaces in Cyber-Physical Systems

Safety Graph: When Safety Responses Become Attack Surfaces in Cyber-Physical Systems Rakesh Podder, Philip D. Hopkins, Sarath Sreedharan, Indrakshi Ray, and Indrajit Ray

arXiv:2610.13086v1 [cs.CR] 9 Oct 2026

Computer Science Department, Colorado State University, Fort Collins, Colorado, USA {Rakesh.Podder, Philip.Hopkins, Sarath.Sreedharan, Indrakshi.Ray, Indrajit.Ray}@colostate.edu

Abstract—Modern industrial control systems (ICS) are susceptible to cyber attacks triggering safety failures in the operational technology (OT) layer. The traditional way to mitigate any failure in OT is to implement safety responses. However, we show in this work that these responses can open up new attack surfaces, thereby vastly expanding the scope of lateral movement. Existing frameworks model cyber-to-physical escalation but provide no mechanism to reason about how these safety responses to OT-failures can trigger new cascading cyber attacks in the Information Technology (IT) layer. To enable such reasoning, we introduce Safety Graph (SG), a formal framework unifying three paradigms – Attack Graphs (AG), Fault Trees (FT), and Event Trees (ET) – over a shared propositional state space, capturing the full bidirectional IT-OT cascade. We provide a sound and complete compilation of SG to a classical AI planning problem, performing plan search using A* to find cross-layer cascade paths. Through a Web3D modeling and simulation of the Tennessee Eastman chemical process plant, which is a widely used chemical engineering benchmark serving as a standard for testing control, monitoring and fault propagation, we demonstrate that the planning compilation of SG automatically discovers safetyresponse-induced lateral movements, and identifies the responsible barriers that are unidentifiable under existing models. A complexity and scalability analysis characterizes how the planning compilation of SG scales with model size and cascade depth. To the best of our knowledge, SG is the first framework to formally model IT-OT attacks and enable operators to explore the problem of cyber attacks triggering cascading failures in ICS. Index Terms—Cyber-Physical System, Attack Graph, Fault Tree, Event Tree, AI Planning

I. I NTRODUCTION Modern industrial infrastructure depends on the tight coupling of Information Technology (IT) and Operational Technology (OT). IT systems handle enterprise communication, data management, and business logic. OT systems — Programmable Logic Controllers (PLCs), Human-Machine Interfaces (HMIs), and SCADA servers — control physical processes in power grids, water treatment plants, chemical refineries and pipelines. This coupling creates security challenges as IT and OT teams operate in silos (NIST IR 8576 Initial Public Draft [1]). A successful intrusion in a CPS does not merely expose data — it can manipulate pressure setpoints, disable safety valves, or corrupt control logic, with consequences that are physical, potentially irreversible, and catastrophic. Major CPS attacks such as the 2010 Stuxnet attack [2], the 2016 Ukraine power grid [3] or the 2021 Colonial Pipeline attack [4], all

share a consistent pattern where attackers enter through IT and cascade downward into OT. The research community has responded to solve these challenges. A substantial body of work models how cyber attacks propagate from IT to OT — using attack graphs [5], [6], [7], attack trees [8], [9], resiliency graph [10], state dependency graphs [11], and hybrid frameworks that link cyber and physical layers [12], [13]. These models capture the cyber incidents and their effects on a physical failure. However, the mitigation solutions of physical failures do not simply terminate the threat. They trigger safety responses — alarms, operator procedures, diagnostic checks, maintenance modes — that alter the system’s operational state. As we observe in this work, each such response is a potential new cyber exposure. A software vulnerability that is unexploitable under normal operating conditions may become exploitable after a network reconfiguration is performed during fault recovery. This OT-to-IT jump, where a physical fault enables a new cyber attack, is precisely what existing models fail to capture and enable analysis. We identify this as a new class of lateral movement that we call safety-response-induced lateral movement and is a subtle exploitable weakness in ICS environments. Safety-response-induced lateral movement exploits transient operational state changes — diagnostic connectivity, maintenance mode activation, temporary host exposure — that occur as a direct consequence of prescribed safety procedures. Current frameworks model cyber-to-physical triggering in detail, but treat safety responses as terminal events rather than as intermediate states that reshape the cyber threat landscape. Even the most expressive prior frameworks handle this asymmetrically, as cyber behavior is modeled explicitly, while physical and safety-response consequences are abstracted into discrete end states. IT professionals have used Attack Graphs (AG) to analyze system vulnerabilities and plan cybersecurity defenses [14]. ICS operators have separately used Fault Trees (FT) to reason about the propagation of failure [15], and Event Trees (ET) to model time-ordered safety responses that follow a fault [16]. No prior framework captures the full bidirectional cascade — IT attacks triggering OT faults (IT → OT) and safety responses creating new IT attack surfaces (OT → IT). To address this gap, we introduce Safety Graph (SG), a formal modeling framework that integrates AG, FT, and ET into a unified propositional state space. Cross-domain dependencies are encoded through a shared attribute set over all hosts

where an attack’s postconditions can enable a fault transition, a fault’s occurrence can trigger an event, and event barriers (safety responses) outcome can establish new host-level cyber preconditions that enable subsequent attacks. This captures the full bidirectional cascade without requiring separate linking relations between layers. However, modeling alone is not sufficient for practical security analysis. A defender operating on a real IT-OT deployment cannot manually enumerate all feasible cross-layer paths — the space is too large, and the interactions between cyber, physical, and safety-response layers are too subtle. We address this through a sound compilation of SG into classical AI planning. Every attack step, fault transition, and event-tree barrier evaluation become a planning action. Every system state proposition becomes a planning fluent. The question of whether a critical failure is reachable under a given IT-OT configuration is reduced to a planning problem, which an AI planner can solve automatically. To evaluate SG in practice, we build IT-OT test-benches modeled on the Tennessee Eastman chemical process plant [17], with a real network architecture implemented on virtual machines (VMs). We instantiate an AG from network configuration, cyber threat intelligence (CTI) reports, and penetrationtesting evidence, construct an FT with input from domain experts, and derive ETs from safety manuals. The AT, FT and ET are the inputs to our modeling process. All three are automatically compiled into a planning model (encoded in Planning Domain Definition Language (PDDL)) using the compilation defined in §V. The AI planner operates over this unified model to discover feasible cross-layer cascades. The planner discovers a path traversing AG → FT → ET → AG → FT, establishing that the critical failure is reachable under SG. We validate every step of the planner-generated trace in the live test-bench. In this work, we make the following major contributions:

surveys related work. Section III presents the running example and test-bench construction. Section IV provides the threat model and assumptions. We formalize SG in Section V. Section VI describes the workflow and analysis on running example. Section VII reports the evaluation. Section VIII concludes the findings and future works. II. R ELATED W ORK CPS security research has largely focused on one direction – attacks that originate in the IT layer and cascade downward into operational technology – ultimately disrupting or manipulating the physical process. The dominant tools for this analysis are the attack graph [5], [6], [7], [18], and a rich body of work has developed around it [8], [9], [12], [13], [19], [20]. Barrère et al. extend attack graphs to Cyber-Physical Attack Graphs (CPAG), linking cyber and physical components in ICS [5]. Hawrylak et al. encode physical parameters alongside cyber states in Hybrid Attack Graphs for the smart grid, capturing cyber actions that cause physical failures [6]. Ibrahim et al. apply model checking over graphs of attacker privileges, vulnerabilities, and state transitions [7]. Adamos et al. use state dependency graphs to trace cascading paths across IT and OT layers [11]. Attack trees address the same problem. Lemaire et al. generate system- and attacker-specific trees from a formal CPS architecture model [8]. Xie et al. quantify threat, CVEs, and expected damage along paths within one tree [9]. Several works have addressed quantitative risk in CPS. Semertzis et al. use attack graphs to model attacker progression in electric power systems [12] and perform quantitative risk analysis. Presekal et al. propose a modeling approach for online situational awareness in power grid OT networks [21], detecting early-stage cyber kill-chain activity through anomaly detection and mapping behaviors into attack graphs. This work is extended [22] to combine hybrid deep learning with spatialtemporal traffic features to detect and isolate attack nodes in the power grid. Few et al. present a case study [23] using the Purdue model [24] to show how an attacker can traverse from Level 5 (Internet DMZ) down to Level 0 (Field), capturing multi-layer traversal within a single attack graph. On the defensive side, Sahu and Davis model adversarial behavior in cyber-physical power systems using a Bayesian attack graph approach [13] to infer attacker intent and track progression under uncertainty. Banik et al. automatically synthesize defense strategies for CPSs [25] that account for adaptive adversary behavior. Khaled et al. introduce a framework for modeling industrial CPS under smart, adaptive attackers and recommending countermeasures [26], capturing interactions across cyber, control, physical, and social components within a unified formal framework. Despite this breadth, the cyber-physical integration of cyber attacks, faults, safety measures remains asymmetric. While cyber behavior is modeled in detail, the physical and operational side appears only as discrete terminal states or final attack objectives. The physical process is never considered as a layer whose faults and safety responses reshape the cyber attack surface. The closest work is by Ray et al., whose Explainable

i) We develop a uniform framework (namely, safety graph, SG) that allows one to model security, faults, and safety, and their interdependencies in a cyber-physical system. To the best of our knowledge, ours is the first effort in this direction. ii) We compile SG to a classical planning problem and provide theoretical results proving soundness, completeness, and other theoretical guarantees. iii) We demonstrate how to leverage AI planning for reasoning about attacks, faults, and safety events in SGs. iv) We also identify and formalize safety-response-induced lateral movement, a new attack class in which the prescribed safety response to a physical fault opens up a new attack surface. Any model that treats safety responses as terminal is unable to capture this class of attacks. v) We demonstrate our approach on Tennessee Eastman; specifically, we show that the critical failure is unreachable using AG and FT, but is reachable in SG; we identify the enabling barrier, and validate every planner step in a live test bench with real tooling. The rest of this paper is organized as follows. Section II

2

Resiliency Graph (ERG) analyzes how vulnerabilities trigger safety events and cascade within a unified transition system [27]. Bashir et al. extend this with the Resiliency Graph (RG), using AI planning to link vulnerabilities to the failures they induce, demonstrated on an IT-to-OT cascade [10]. Both treat propagation as one-directional. Neither captures the path, in which fault-driven safety responses open new IT attack surfaces (OT → IT). We address this.

potentially via phishing, exposed services, or exploiting known Common Vulnerabilities and Exposures (CVEs) — whose objective is to trigger safety-critical failures in the OT layer. The adversary has the following properties: (i) The adversary exploits known vulnerabilities (e.g., published CVEs) in both IT and OT components. Note, zero-day exploits are outside the scope of this model. (ii) The adversary executes sequences of attack steps across networked components, progressing from an initial IT foothold toward OT targets by satisfying the preconditions of each step using postconditions established by prior steps. (iii) Cyber actions executed by the adversary may establish postconditions that satisfy the enabling conditions of OT fault transitions. The adversary cannot alter prescribed safety procedures but can corrupt the information environment such as sensor feeds, operator displays etc. on which barrier evaluation depends, and can exploit the operational side effects of safety responses as new attack surfaces. (iv) The adversary is constrained by network reachability, host-level access state, and the precondition structure of available attack actions. Operator Model. System operators follow safety procedures prescribed under IEC 61511 [32] and ISA-84 [33] for each initiating fault event. These procedures are deterministic and documented. Given a fault, the sequence of barriers of event trees, and their outcomes is fixed by certified safety documentation. Operators may modify the IT layer between incidents — patching vulnerabilities, restricting connectivity, or disabling services — and may or may not select the prescribed safety response during a fault event. Modeling Assumptions. (i) Vulnerability information, network configuration, and failure relationships are available from CVE databases. Penetration testing results, system logs, CTI reports, and engineering documentation are provided for each machine in the network. Attack graph (AG) construction, fault tree (FT) specification, and event tree (ET) derivation are grounded from these sources. (ii) All three modeling layers — the AG, FT, and ET — operate over a single global proposition set defined over the hosts and devices of the ITOT deployment. This shared space is the mechanism by which cross-layer dependencies are captured without explicit linking relations.This assumption requires that vulnerability descriptions, fault condition labels, and safety procedure states use semantically consistent propositions. Syntax mismatches across layers is addressed by domain expert reconciliation.(iii) The vulnerability and configuration state of the system is fixed at analysis time. Dynamic changes — patch deployment, configuration drift, or new CVE disclosure — are considered as new state which require re-running the analysis. (iv) Analysis operates within a bounded relational scope such that there exists a finite set of hosts, a finite fault and event set derived from certified safety documentation, and a bounded number of AG → FT → ET cascade cycles.

III. RUNNING E XAMPLE We start our discussion by first describing the ICS test bench of the Tennessee Eastman Process (TEP) plant [17], [28] using a combination of web-3D modeling and virtualization. TEP is a widely used chemical manufacturing benchmark developed by Eastman Chemical Company [17]. It serves as a standard for testing control, monitoring, and fault propagation, featuring five main units: a reactor, condenser, compressor, separator, and stripper. Information Technology (IT) Layer - Subnet: 192.168.90.0/24 Human-Machine Interface ScadaBR

Attacker - Kali Linux

IP: 192.168.90.5

IP: 192.168.90.114

WAN: 192.168.90.100

pfSense Operational Technology (OT) Layer - Subnet: 192.168.95.0/24

IP: 192.168.95.10 Simulated TE Process Plant

Firewall LAN: 192.168.95.2

IP: 192.168.95.2 OpenPLC Runtime V2

Engineering WorkStation

IP: 192.168.95.113 OpenPLC Editor

Fig. 1: Schematic architecture of the ICS test bench with virtual HMI, firewall, PLC, workstation, and TEP plant simulation. The networked-ICS test-bench illustrated in Figure 1 enables us to (i) execute realistic cyber actions, (ii) observe their physical impact on a controlled process simulation, and (iii) evaluate how safety responses can lead to new cyber exposure. The test-bench consists of a Human-Machine Interface (HMI) using ScadaBR, an OpenPLC software, an engineering workstation with OpenPLC Editor, a pfSense firewall separating the IT and OT subnets, a process simulation backend, and a Kali Linux attacker VM. The IT and OT segments use the 192.168.90.0/24 and 192.168.95.0/24 subnets respectively. The firewall enforces segmentation between the two networks, while the process simulation and PLC jointly provide an observable control loop on which the effects of cyber actions can be validated. Information related faults and safety measures for TEP is collected from published articles [29], [30], [31].

V. S AFETY G RAPH (SG) F ORMALIZATION

IV. T HREAT M ODEL AND A SSUMPTIONS

We now introduce Safety Graph (SG), the unified modeling framework for cyber-resilient IT–OT systems that captures how attacks on IT, physical faults on OT, and safety responses

Adversary Model. We consider a capability-bounded adversary with an established foothold in the IT layer — acquired

3

during faults jointly shape system risk over time. SG represents possible attacks in cyber space as an attack graph (AG), causal escalation of physical or operational failures as a fault tree (FT), and time-ordered safety barriers and operator or automation decisions that unfold after a fault as an event tree (ET). By explicitly capturing the cascade path, AG → FT → ET → AG → FT → · · · (cyber-to-physical triggering followed by safety-response induced exposure that can create new cyber attack surfaces), SG models how benign-seeming safety events or false alarms can enable new OT-to-IT and IT-to-OT pathways. SG considers an IT–OT deployment consisting of (i) a collection of hosts or devices arranged in a specified network architecture (HMI, workstations and PLCs), (ii) a set of physical/operational faults (sensor failure, open valve etc.) that may occur and propagate in the OT process (sensor failure → reactor shutdown), and (iii) a time-ordered sequence of safety barriers and operational events (alarm visible, PLC code checks) that unfold once a fault occurs. We model all three layers using propositional attributes. Intuitively, a host-level attribute captures cyber or device state (e.g., has vuln(host, CVEs), configurations(host), reachable(host1 , host2 )); a fault-level attribute captures OT fault state (e.g., has instrumental failure(host), has sensor failure(host)), and an event-level attribute captures safety-response state and temporal stage (e.g., has system checked, has alarm raised, has repaired). These three sets comprise SG attributes.

Nodes represent hosts along with their attributes, namely, NA ⊆ H × 2PH , and edges are attack edges. An Attack Edge e ∈ EA of the form src(e) ⊆ NA and dest(e) ⊆ NA exists iff there is an attack ai = ⟨pre i (a), post +i (a), post −i (a)⟩, where ∃ni ∈ src(e), that corresponds to the same host as the one for n′i ∈ dest(e), where ni = (hi , Pi ) S i • pre (a) ⊆ nj ∈src(e) Pj , where nj = (hj , Pj ) ′ ′ ′ • for the node ni = (hi , Pi ), we have Pi = (Pi \ −i +i post (a)) ∪ post (a) •

For example, consider an attack a = ‘discover PLC via arp spoofing’, the pre(a) is ‘attacker present’ ∧ ‘HMI is compromised’ ∧ ‘PLC is live’ ∧ ‘attacker performs ARP spoofing’. Each attack enables an edge (e) from src(e) = {attacker, HM I, P LC} to dst(e) = {P LC}, thus forming attack graph. B. Fault Tree (FT) We represent a fault occurrence and escalation using preconditions and postconditions over fault-level attributes. Let F be the finite set of faults in the OT system (including basic, intermediate, and top-level faults). Each fault f ∈ F is captured by a tuple of the form f = ⟨pre(f ), post+ (f ), post− (f )⟩, where pre(f ) ⊆ PH captures the enabling conditions for f to occur (e.g., the occurrence of basic faults, intermediate faults, or operating conditions), post+ (f ) ⊆ PH captures the positive postconditions (fault attributes that become true after f occurs), and post− (f ) ⊆ PH captures the negative postconditions (fault attributes that become false after f occurs, if any). We treat the fault tree (with AND/OR gates) as inducing a transition system over fault propositions, yielding the directed tree F defined below.

Definition 1. Let H represent the set of unique hosts and their labels, where H = {H1 , H2 , . . . , Hn } and PH represent the attribute set of propositions, used to describe the system state in IT-OT network. Each host Hi ∈ H has a unique collection of attributes, namely, Pi , that are true for Hi , where Pi ⊆ PH represents a set of propositions about host Hi ’s attribute (network-level, fault-level, safety/event level).

Definition 3. A Fault Tree (FT) is denoted as F = ⟨NF , EF ⟩, where NF are nodes and EF are directed fault edges. Nodes represent hosts with fault-level attributes, NF ⊆ H × 2PH . For any edge e ∈ EF , let src(e) ⊆ NF denote its source node-set and let dest(e) ∈ NF denote its destination node. A fault edge e with src(e) and dest(e) exists iff there exists fj = ⟨prej (f ), post+j (f ), post−j (f )⟩ fault such that:

For any instance, an SG system state is a set s ⊆ PH of propositions that are currently true. Note that attack graph, fault tree and event trees revolve around a finite set of hosts/devices where some propositions can be true for all, so rather than separate proposition set, we define PH as global proposition set over all the hosts of IT-OT network.

∃ nj ∈ src(e) and n′j = (hj , Pj′ ) correspond to the same host hj , where nj = (hj , Pj ) S j • pre (f ) ⊆ nk ∈src(e) Pk , where nk = (hk , Pk ); ′ − + ′ ′ • Pj = (Pj \post (f ))∪post (f ) for node nj = (hj , Pj ). •

A. Attack Graph (AG) We represent an attack using preconditions and postconditions. Let A be the set of attacks associated with a network, where each attack a ∈ A is captured by a tuple of the form a = ⟨pre(a), post+ (a), post− (a)⟩, where for any attack tuple, pre(a) ⊆ PH captures the preconditions, post+ (a) ⊆ PH captures the positive postconditions (i.e., the set of attributes turned true), and post− (a) ⊆ PH captures the negative postconditions (i.e., the set of attributes turned false). Thus, to capture all the attacks on the network we formally define attack graph (AG) as an AND-OR graph [34].

Note that we treat the fault tree as a host-scoped faultpropagation tree that encodes how fault conditions can occur and escalate at specific systems in the IT–OT deployment. Concretely, each fault proposition is interpreted relative to a host, instead of modeling a fault as a standalone event, we model ‘fault-level propositions pf holds at host h’ using a host-indexed proposition (h, pf ) where h ∈ H and pf ⊆ PH . For example, ‘pressure sensor failure’ is a fault-level proposition pi that holds at host hi , ‘Simulated TE Process plant’. Together, these define the fault node ni = (hi , pi ).

Definition 2. An Attack Graph (AG) is a graph, G = ⟨NA , EA ⟩, where NA are the nodes and EA are the edges.

4

C. Event Tree (ET)

ALGORITHM 1: Timed Event-Tree Execution with Yes/No Barriers

An Event Tree (ET) is a forward, consequence-oriented model that describes how a system evolves after an initiating event (a fault) by enumerating a time-ordered sequence of safety barriers such as operator actions, procedures, and automatic protections. Each barrier yields a discrete outcome (i.e., yes or no) along with a change of states in the host, and the combination of barrier outcomes determines the resulting operational or safety states.

Input : Initiating event ie ∈ IE , ordered barriers B = {b1 , . . . , bm }, time steps T = {t0 , . . . , tm }, condition map µ : B → PH , barrier specs pre(·), post+T (·), post−T (·), post+F (·), post−F (·), outcome map out : {True, False}m → O Output: Outcome O and final event-state sH sH ← {ie , at(t0 )}; ω ← ⟨ ⟩; for i ← 1 to m do // Timed enablement and ordering if pre(bi ) ̸⊆ sH then return (⟨ ⟩, sH ); end // Evaluate barrier outcome & update sH if µ(bi ) ∈ sH then ωi ← True;
sH ← sH \ post−T (bi ) ∪ post+T (bi ); else ωi ← False;
sH ← sH \ post−F (bi ) ∪ post+F (bi ); end Append ωi to ω; end O ← out(ω); return (O, sH );

Definition 4. An initiating event (ie ) is the first significant deviation from a normal operating condition that may lead to unwanted consequences. Note that by definition each event tree is triggered by exactly one initiating event (ie ) but as we are discussing about IT-OT network, there could be multiple faults and multiple initial events (IE ) which leads to multiple ETs for the network. To reduce notation overload all the below discussion is for single event tree initiated due to an initial event (ie ). A timed barrier system in event tree (ET) can be modeled as an ordered collection of barriers together with discrete time steps and a binary outcome condition for each barrier.

For any event state s ⊆ PH satisfying ie ∈ s and pre(bi ) ⊆ s, the successor state s′ after evaluating bi is defined by: (
s \ post−T (bi ) ∪ post+T (bi ) if µ(bi ) ∈ s, ′ s =
s \ post−F (bi ) ∪ post+F (bi ) if µ(bi ) ∈ / s.

Definition 5. Let B = {b1 , . . . , bm } be the ordered set of barriers and let T = {t0 , t1 , . . . , tm } be the ordered set of discrete time steps for initial event ie , encoded as propositions at(t) ∈ PH . For each barrier bi ∈ B, there is a propositional condition µ(bi ) ∈ PH that determines the barrier outcome (true or false).

A complete ET execution for ie is a sequence of evaluations {b1 , . . . , bm } starting at at(t0 ) and ending at at(tm ), producing an outcome valuation over O determined by the barriers. As described in Algorithm 1, after executing the ET for initiating event ie , the evaluation of each barrier bi yields a binary result determined by whether µ(bi ) holds in the state at the time of evaluation. We capture these barrier results as an outcome vector ω = ⟨ω1 , . . . , ωm ⟩, where each component records the observed outcome of barrier bi , i.e., ωi = T if µ(bi ) holds (equivalently, T rue(bi ) becomes true), and ωi = F otherwise (equivalently, F alse(bi ) becomes true). The overall event-tree outcome is defined by an outcome function out : {T, F }m → O, (or more generally out : {T, F }m → 2O when multiple outcome propositions may hold simultaneously), which maps a complete barrieroutcome pattern to the corresponding ET consequence class. Intuitively, out encodes the ET leaf semantics such that each root-to-leaf path corresponds to a unique truth assignment to the barriers, and out(ω) returns the outcome proposition(s) labeling that leaf (e.g., mitigated, degraded, unsafe-escalation, exposure-created). Therefore, once ω is obtained after evaluating {b1 , . . . , bm }, the ET outcome is given by O = out(ω).

The deterministic barrier model reflects regulatory practice in ICS safety engineering. Under IEC 61511 and ISA-84, each barrier outcome is prescribed in advance by domain experts for each initiating event — the safety procedure is a fixed document, not a runtime decision. Accordingly, barrier truth values µ(bi ) can be changed based on operator’s decision as an operator has a choice to implement the barrier or not. Definition 6. An Event Tree (ET) is defined as a tuple, E = ⟨ie , B, µ, T, O⟩ where: ie is the initiating-event propositions that triggers the ET. • B = {b1 , . . . , bm } is an ordered set of timed barriers. • T = {t0 , t1 , . . . , tm } is an ordered set of discrete time steps represented by propositions at(t) ∈ PH . • µ : B → PH assigns each barrier bi a propositional condition µ(bi ) whose truth value determines the barrier outcome (True/False). • Each barrier bi is associated with a common precondition set pre(bi ) ⊆ PH and two outcomedependent postcondition pairs (post+T (bi ), post−T (bi )) and (post+F (bi ), post−F (bi )), all subsets of PH , where at(ti−1 ) ∈ pre(bi ) and at(ti ) ∈ post+T (bi )∩post+F (bi ) and at(ti−1 ) ∈ post−T (bi ) ∩ post−F (bi ). • O ⊆ PH is the set of ET outcome propositions. •

D. Safety Graph (SG) Safety Graph (SG) unifies 1 the attack graph G = ⟨NA , EA ⟩, 2 the fault tree F = ⟨NF , EF ⟩, and 3 a family of event-tree objects {Eie }ie ∈IE , one ET for each initiatingevent proposition, where IE is set of all possible initial event ie . For ease of representation, Eie = ⟨ie , Bie , µie , Tie , Oie ⟩ will be subsequently denoted as E = ⟨ie , B, µ, T, O⟩.

5

for pairs (h, p) ∈ H × PH using a mapping function γ M , while event-tree facts (e.g., stage propositions at(t), barrierstatus propositions resolved(b), decision propositions µ(b), and outcome propositions) are represented as global fluents using a mapping function φM since the ET is modeled as a structured object over propositions rather than as host-level state.

Cross-domain dependencies in SG are captured without separate linking relations. Cyber-to-physical triggering is represented by faults whose enabling conditions include hostlevel propositions established by attacks (e.g., pre(f ) ⊆ PH may contain propositions produced by some attack action). Fault-to-event activation is represented by initiating-event propositions ie ∈ IE ⊆ PH that are produced by fault occurrences. Safety-response induced cyber exposure is represented by barrier effects and/or ET outcomes which add host-level propositions in PH that can serve as preconditions of subsequent attacks. We summarize this exposure using a mapping ψ : O → 2PH , where ψ(O) denotes the set of propositions made available after ET outcome O. Now we can formally define the Safety Graph (SG) framework.

0 Definition 8. For a given SG, SN be an initial node-set and let (ht , pt ) be the target host-attribute, a representative classical planning model is defined as MSG = ⟨F SG , ASG , I SG , GSG ⟩, where: SG • F contains fluents for host-attribute pairs in H × PH and or event-tree propositions relevant to ET execution. γ M maps H × PH to F SG . For each ET proposition p ∈ PH relevant to ET execution (for example q ∈ {at(t), resolved(b), µ(b), O, ie } is mapped to F SG using φM (to simplify notation we will also allow the application of the function over sets). SG • A contains three families of actions: 1) For each attack edge e ∈ EA with destination node (hi , Pi ), create an action ae where [ pre(ae ) = γ M ({(h, p) | p ∈ P }).

Definition 7. Safety Graph (SG) is defined as the unified model [ {Eie }⟩, SG = ⟨G, F, ie ∈IE

where G = ⟨NA , EA ⟩ is an attack graph, F = ⟨NF , EF ⟩ is a fault tree, and for each ie ∈ IE , Eie = ⟨ie , Bie , µie , Tie , Oie ⟩ be an event-tree triggered by ie . Please note that the definitions above — G, F, E, and their unification as SG — constitute the complete modeling framework. However, instead of performing the analysis directly on (SG) graph, we first compile them into a planning problem and use planners to perform the analysis. Since planning scales to large problem spaces, it is well-suited for automated reasoning over complex IT-OT deployments [34], [10].

(h,P )∈src(e)

Let a = ⟨pre(a), post+ (a), post− (a)⟩ ∈ A be the attack tuple inducing e. Then add(ae ) = γ M ({hi } × post+ (a)), del(ae ) = γ M ({hi } × post− (a)). 2) For each fault edge e ∈ EF with destination node (hj , Pj ), create an action ae where [ pre(ae ) = γ M ({(h, p) | p ∈ P }).

E. Planning Compilation for SG

(h,P )∈src(e)

A classical planning problem is defined by a tuple M = ⟨F, A, I, G⟩, where F is a finite set of propositional fluents that characterizes the state space. A state s ⊆ F is the set of fluents currently true. A is the set of actions available to the planner, I ⊆ F is the initial state, and G ⊆ F is the goal state. A planning problem encodes a transition system whose nodes are states and whose directed edges are state transitions induced by action execution. Each action a ∈ A is defined by the tuple a = ⟨pre(a), add(a), del(a)⟩, where pre(a) ⊆ F specifies the preconditions that must hold for a to be executable, add(a) ⊆ F specifies the fluents set to true upon execution, and del(a) ⊆ F specifies the fluents set to false. Executing action a in state s produces a successor state via the transition function, ΓM (s, a) = (s \ del(a)) ∪ add(a), if pre(a) ⊆ s. A solution to a planning problem, called a plan, is a sequence of actions π = ⟨a1 , . . . , ak ⟩ such that ΓM (I, π) ⊇ G, where ΓM is extended to action sequences in the natural way. A plan is optimal if no shorter valid plan exists. To compile a SG instance into a classical planning model M = ⟨F, A, I, G⟩, we treat every propositional fact that can become true during a valid path as a planning fluent, and we treat every possible evolution step (attack, fault propagation, and barrier evaluation) as a planning action. The fluent set F is formed from a global attribute set of propositional facts such that host/device facts are represented as host-indexed fluents

Let f = ⟨pre(f ), post+ (f ), post− (f )⟩ ∈ F be the fault tuple inducing e. Then add(ae ) = γ M ({hj } × post+ (f )), del(ae ) = γ M ({hj } × post− (f )). 3) For each event tree Eie ∈ EIE with ordered barriers B = ⟨b1 , . . . , bm ⟩ and time steps T = ⟨t0 , . . . , tm ⟩, include action abk for each barrier bk . The precondition is pre(abk ) = φM {(p) | p ∈ pre(bk )}) where pre(bk ) includes the required stage proposition at(tk−1 ) and any enabling facts (including ie when needed). The effects contain conditional branch determined by the decision proposition µ(bk ) ∈ PH , if φM ((µ(bk ))) then add(abk ) = φM ({p | p ∈ post+T (bk )}), del(abk ) = φM ({(h⋆ , p) | p ∈ post−T (bk )}), else add(abk ) = φM ({p | p ∈ post+F (bk )}), del(abk ) = φM ({p | p ∈ post−F (bk )}). Here the truth value of µ(bk ) is fixed by the initial state (operator/automation decision as an initial condition). Please note that φM (at(tk ))), φM (resolved(bk )) is part of add(abk ) M and del(a bk ) for both φ ((µ(bk ))) true or false. S  SG M • I = γ ({(h, p) | p ∈ P }) ∪ 0 (h,P )∈SN M φ ({at(t0 )} ∪ {µ(b) | b ∈ B}).

6

•

GSG = {γ M ((ht , pt ))}.

executable at the matching planning state. Applying all actions in order yields a final state containing γ M (ht , pt ) = GSG , so the induced action sequence is a valid plan in MSG .

We now show that the representative planning model MSG is a sound and complete representation of the SG instance. S Theorem 1. Let SG = ⟨G, F, ie ∈IE {Eie }⟩ be an Safety 0 Graph (SG) instance, SN be an initial node-set, and let (ht , pt ) be a target host-attribute. The planning model MSG = ⟨F SG , ASG , I SG , GSG ⟩ is a sound and complete representation of SG: C1 (Soundness) Any valid plan π in MSG corresponds to a valid cross-layer path through SG, i.e., a sequence of attack edges in G, fault edges in F, and barrier evaluations in {Eie }ie ∈IE . 0 C2 (Completeness) Any valid path through SG from SN to SG (ht , pt ) corresponds to a valid plan π in M .

This equivalence also allows us to prove the complexity of finding a cascade path through Safety Graph (SG) . Theorem 2. For a general Safety Graph, the problem of determining the existence of a cascade path through the Safety Graph (SG) is PSPACE-complete. Proof Sketch. The membership proof, i.e., the problem is within the class of PSPACE, is given by Theorem 1, as a planning problem of the form discussed here is PSPACEcomplete [35]. The model described above belongs to that class, proving the membership. Regarding hardness, we can show that for any planning problem, we can reduce it to a problem of identifying a path for the Safety Graph in polynomial time. To do so, we consider a SG with a single host, a single fault tree node (eliminating any corresponding fault edges and fault actions), and a corresponding single event tree Eie with a trivial single barrier (containing no conditional effects). For this planning problem, given by the tuple ⟨F SG , ASG , I SG , GSG ⟩, the fluents F map to the attribute set PH of the SG, the actions ASG map to the attack edges in the attack graph, the initial state I SG maps to 0 the facts from PH true in the initial node SN , and the goal SG G maps to the node in the attack graph which initiates the fault in the single fault tree node. If the corresponding planning problem has a goal containing multiple propositions, a new attack is added with the preconditions being the original goals, and the postcondition is a single new attribute that is the target of the SG. Thus, the constructed SG instance has a cascade path if and only if the original planning problem has a valid plan.

Proof Sketch. The proof follows from the observation that the compilation in Definition 8 establishes a one-to-one correspondence between edges in SG and actions in MSG . By construction, ASG contains exactly three families of actions. (i) For each attack edge e S∈ EA , the corresponding action ae has preconditions γ M ( (h,P )∈src(e) {(h, p) | p ∈ P }) and effects γ M ({hi } × post+ (a)) and γ M ({hi } × post− (a)), mirroring exactly the precondition and postcondition structure of the attack tuple a inducing e. (ii) For each fault edge e ∈ EF , the corresponding action ae is defined analogously from the fault tuple f inducing e. (iii) For each barrier bk in each event tree Eie , the corresponding action abk requires the stage proposition φM (at(tk−1 )) and produces φM (at(tk )), advancing the ET execution by exactly one step and applying the True or False branch postconditions determined by the fixed truth value of φM (µ(bk )) in the initial state I SG . Soundness (C1). Let π = ⟨a1 , . . . , an ⟩ be a valid plan in MSG , so that ΓMSG (I SG , π) ⊇ GSG . Each action ai ∈ π belongs to exactly one of the three families above. An action is executable at a state s only if its preconditions are satisfied in s; by the correspondence above, this means the source node-set of the equivalent edge in GSG or F SG is present in the current propositional state, or the required ET stage and enabling propositions hold for the barrier action. Executing ai updates the state by exactly the add and delete effects of the corresponding edge or barrier evaluation. Therefore, π induces a valid sequence of attack edges, fault edges, and barrier evaluations in SG that reaches a state containing γ M (ht , pt ), satisfying the target host-attribute (ht , pt ). Completeness (C2). Let ρ be a valid cross-layer path in 0 SG from SN to (ht , pt ), comprising a sequence of attack edges, fault edges, and barrier evaluations. By the action-step correspondence, each edge or barrier evaluation in ρ maps to a unique action in ASG whose preconditions and effects faithfully encode the enabling conditions and postconditions of 0 that step. The initial state I SG encodes the propositions of SN M together with the ET initialization facts φ (at(t0 )) and the fixed decision propositions φM (µ(b)) for all barriers. Since ρ is valid in SG, the enabling conditions of each step hold when that step is taken; the corresponding action is therefore

VI. A NALYSIS OF SG FOR RUNNING E XAMPLE In this section we demonstrate that SG can discover crosslayer cascade paths that are invisible to models covering only the cyber and physical layers. We instantiate SG on the TEP test-bench, compile it to a planning problem, and pose a question, “does a feasible path from an IT foothold to reactor rupture (fault) exist, and if so, what enables it?” We answer this in two phases. First, we establish that the analysis of the critical path is unreachable under AG+FT alone. We also run the same planning compilation in RG and ERG [10], [27]. Second, we show that integrating the safety measures (ET) causes the planner to discover a feasible cascade, and that the returned plan identifies a safety barrier as the precise enabling mechanism. Figure 2 shows the workflow of generation of SG instance and analysis performed using planner. A. Constructing the SG Instance For the given network (see § III), we collected: (i) network configuration artifacts (host inventory, subnet segmentation, firewall rules), (ii) penetration testing results (open ports, exploitable services, reachable ICS endpoints) [28], and (iii) CTI reports identifying known vulnerabilities in the deployed

7

IT-OT Network

Fault Information, Domain Data

Extraction using NLP, LLM

Network Data, CTI reports, Pentest data

Attack Graph

Safety Graph (SG)

PDDL Domain & Problem Generation

Planning Compilation Update

PDDL Domain File problem.pddl PDDL Problem File

Fault Tree Domain Expert Reconciliation Event Trees

Safety Documents

Operator's Decision on Barriers

Cross Domain Propositions validated by Domain Expert

AI Planner

NO

- Fast Downwards - A* Search (LMCut) YES Previous Plan

Reasons for Fail

System Admins

PDDL Domain File PDDL Problem File

VAL

Update problem.pddl

Mitigations

Mitigation Applied

Updated Planning Compilation

No Plan/ Cascade Path

Plan

Plan Analysis

Plan/Cascade Path

Fig. 2: Workflow for modeling SG instance and analyzing SG using AI planner.

software stack to construct the corresponding AG. FT is constructed based on fault analysis report on TEP [36], [17], [28] as a host-scoped fault-propagation structure using Relyence [37]. The ET layer is derived from safety manuals following IEC 61511 procedures. For the TEP instantiation, 32 faults were modeled, each with a corresponding event tree of 5–6 barriers, yielding approximately 190 barriers in total — all grounded in certified safety documentation. For the interested reader, the details of the AG, FT and ET for an initiating event ‘pressure-sensor-failure’ are shown respectively in Appendix B-A Figure 13, Appendix B-B, Figures 14 and 15, and Appendix B-C Figure 16. We use llama3:8b based NER (Named Entity Recognition) methods to extract data from various reports. All the LLM extracted propositions are validated by domain experts. Given the instantiated AG, FT, and ET, we use automated scripts that generates the AI planner’s domain.pddl and problem.pddl files for the corresponding SG instance. The planning compilation maps host, fault, ET stage/barrier, and outcome propositions into planning fluents, and maps attack steps, fault transitions, and barrier evaluations into planning actions. The operator’s choice to implement barrier or not is captured in the problem.pddl file as barrier’s truth value. Once the planning problem is constructed, we use the Fast Downward planner [38] with A* and the LM-cut admissible heuristic to perform analysis. For each variation of operator’s decision and goal condition we ran the planner iteratively. Once planner finds a plan or cascade path, we analyze the plan to find the reason why a cascade path exists. Based on the analysis, a mitigation or solution is applied which updates the problem.pddl file. Then the updated compilation and the previous plan are analyzed using VAL [39] to show how the mitigation causes the plan failure.

is: “can an attacker trigger reactor rupture (fault: REXRUP) failure starting from an IT foothold?” The planner finds the partial cascade shown in Figure 3. Four attack steps traverse the AG — subnet scan, ARP spoofing, firewall bypass, Modbus injection — and trigger the first fault transition (‘fault-reactor-pressure-decrease’). However, when the goal is strengthened to the critical top-level fault (reactor rupture), the planner reports no plan exists. RG or ERG can not find this plan because they consider fault as terminal events and safety measures are given as remediation suggestions. The FT transitions required to escalate from ‘fault-reactor-pressure-decrease’ to ‘fault-reactor-rupture’ needs preconditions that are never established in the AG+FT model. 1 2 3 4 5 6 7 8 9

(scan-network-and-discover-hmi 192-dot-168-dot-90-dot-114 192-dot-168-dot-90-dot-5) (discover-plc-via-arp-spoofing 192-dot-168-dot-90-dot-5 192-dot-168-dot-95-dot-2) (connect-to-plc-bypassing-firewall 192-dot-168-dot-95-dot-2) (exploit-buffer-overflow-vulnerability-to-reset-pressure-sensor 192-dot-168-dot-95-dot-2) (fault-reactor-pressure-decrease ) ; cost = 5 (unit cost)

Fig. 3: A PDDL representation of initial attack plan/path from IT cyber attacks to OT fault. Next, we integrate safety measures as the ET layer. Now, the defender’s question becomes: “does reactor rupture become reachable once safety-response behavior is modeled”? The planner finds a plan that did not exist under AG+FT alone. The first four steps are identical to the AG+FT case. The key difference is what happens after the initial pressurerelated fault is triggered. If a fault is observed, operator typically follows a safety protocol. For this case, the fault, ‘pressure-sensor-failure’, act as initial state (i) to activate safety sequences which presented as the event tree as shown in Figure 4. The planner evaluates B1 and B2 (barrier’s of ET), corresponding to alarm visibility and operator recognition, and then reaches B3, where the safety procedure requires PLC logic inspection from the engineering workstation. This workstation was not previously connected to system’s network. It has became live due to safety checks. From the

B. Analysis on the Running Example We first ask whether the critical failure is reachable using only the cyber and physical layers, with no safety measures. This corresponds to the standard cyber-physical threat model used in RG [10] and ERG [27]. The defender’s question

8

operator’s perspective, the ‘pressure-sensor-failure’ response can still appear to reach the normal recovery outcome O1 . However, evaluating B3 adds a new state in SG ,‘workstation-is-live’. This proposition was absent in the AG+FT model. But due to safety it now becomes a hostlevel precondition for later workstation attack actions. This is the safety-induced later movement of the adversary. With the workstation now reachable, the planner finds a plan where the attacker compromises the workstation and uploads malicious PLC logic through the OpenPLC Editor interface. This corrupts the pressure setpoint logic and establishes a new faultenabling condition. The later FT chain then escalates through ‘fault-relief-pressure-sensor-failure’ and ‘fault-technical-protection-failure’ to the top-level fault ‘fault-reactor-rupture’ (Figure 4). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

compiled planning model. We ran our experiment on Apple M3, 16 core macOS Tahoe, with 24 GB LPDDR5 memory. A. Operator’s Decision & Mitigation Operator’s Decision. In SG model, the outcome of each barrier can be either true or false. An operator has a choice to implement the barrier or not. Our model can work for any choice the operator makes and will update µ(bi ) of the current state. In problem.pddl the operator’s decision for each barrier is represented as (barier-b1) (barier-b2) (barier-b3) (barier-b4) (barier-b5) (barier-b6). If (barier-b1) is set to true as initial condition by operator (meaning operator decides to implement barrier B1), it will make proposition (b1-alarm-visible) true; if not (b1-alarm-visible) is false. For each decision based on operator, some propositions are true or false. For example if operator decides to perform all safety checks then outcome would be (o1-normal-recovery). If the operator only evaluated (barier-b1), (barier-b5) (others are false) it will generate an outcome (o4-contamination). In the TEP running example, correctly executing the B3 PLC-logic check by operator is what brings the workstation online and opens the new attack surface. If the operator does not check the PLC logic ((not (barier-b3))) then µ(b3) = false, in which case there would not be any new attack as workstation-is-live proposition is false.

(scan-network-and-discover-hmi 192-dot-168-dot-90-dot-114 192-dot-168-dot-90-dot-5) (discover-plc-via-arp-spoofing 192-dot-168-dot-90-dot-5 192-dot-168-dot-95-dot-2) (connect-to-plc-bypassing-firewall 192-dot-168-dot-95-dot-2) (exploit-buffer-overflow-vulnerability-to-reset-pressure-sensor 192-dot-168-dot-95-dot-2) (fault-rex-press-dcr ) (initiate-event-tree-pressure-sensor-failure ) (evaluate-barrier-b1-hmi-alarm-visibility ) (evaluate-barrier-b2-operator-recognition ) (evaluate-barrier-b3-plc-logic-check-in-workstation ) (discover-engineering-workstation 192-dot-168-dot-95-dot-2 192-dot-168-dot-95-dot-5) (gain-access-to-workstation 192-dot-168-dot-95-dot-5) (upload-malicious-plc-pressure-setpoint 192-dot-168-dot-95-dot-5) (evaluate-barrier-b4-corrective-action ) (evaluate-barrier-b5-auto-protection ) (evaluate-barrier-b6-isolation-prevention ) (determine-safety-outcome ) (fault-rlf-press-fail ) (fault-tech-p-fail ) (fault-rex-rup ) ; cost = 19 (unit cost)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Fig. 4: Planner-generated SG cascade path for the TEP case. The dotted box marks the transition where barrier b3 fails and the attacker pivots from the PLC to the workstation. This analysis shows that SG captures a cascade path that was absent in the prior models (RG and ERG). The missing link is not an additional exploit in the original attack graph. It is the safety-response-induced exposure created during barrier B3. Analyzing the planner-generated trace now identifies a concrete hardening recommendation. The engineering workstation must not be brought online during safety checks without additional network controls or segmentation enforcement. SG converts a subtle cross-layer interaction into a specific, actionable finding before a real adversary can exploit it. The mitigation process and operator’s choices are discussed in the evaluation (§VII).

(scan-network-and-discover-hmi ip-192-dot-168-dot-90-dot-114 ip-192-dot-168-dot-90-dot-5) (discover-plc-via-arp-spoofing ip-192-dot-168-dot-90-dot-5 ip-192-dot-168-dot-95-dot-2) (connect-to-plc-bypassing-firewall ip-192-dot-168-dot-95-dot-2) (exploit-buffer-overflow-vulnerability-to-reset-pressure-sensor ip-192-dot-168-dot-95-dot-2) (fault-rex-press-dcr ) (initiate-event-tree-pressure-sensor-failure ) (evaluate-barrier-b1-hmi-alarm-visibility ) (evaluate-barrier-b2-operator-recognition ) (evaluate-barrier-b3-plc-logic-check-in-workstation ) (evaluate-barrier-b4-corrective-action ) (evaluate-barrier-b5-auto-protection ) (evaluate-barrier-b6-isolation-prevention ) (determine-safety-outcome ) ; cost = 13 (unit cost)

Fig. 5: Planner-generated SG cascade path for the TEP case. As illustrated in Figure 5, planner found a plan when operator does not perform PLC logic check ((not (barier-b3))), resulting in a normal recovery — no new attack surface. This validates that operator decisions can influence the outcome, and SG can model them. For single initiate-event-tree-pressure-sensor-failure with 6 barriers, we have run an iteration over 26 operator’s decisions and all possible goal state combinations. For the running case we have 25 − 26 combinations of operator’s choice for each fault and goal state that we run iteratively. Mitigation. After the plan analysis, it is found that bringing workstation live to the network for PLC check exposes workstation’s IP to the attacker and a set of attacks could be launched (See steps 11-12 in Appendix A). The mitigation solution is isolating workstation for diagnosis or introducing security controls. By doing this it updates the

VII. E VALUATION We validate the planner-generated SG trace by replaying it step-by-step in the TEP test-bench, verifying that each abstract action — attack step, fault transition, or ET barrier evaluation — is executable in the deployed environment. The results are described in details in Appendix A. Validation evidence is drawn from network observations, protocol traces, reachability tests, workstation interaction logs, and process-state changes, compared against the corresponding state transitions in the

9

L = 15151

Plan Length (L) planning compilation. In the previous problem.pddl 10 10 initial state, the predicates (node-exists 10 ip-192-dot-168-dot-95-dot-5) and 10 10 (connected-to ip-192-dot-168-dot-90-dot-114 10 ip-192-dot-168-dot-95-dot-5) were true. 10 Bringing up 192.168.95.5 into the network creates a path for attacker to upload malicious code to trigger Safety Graph: Attack Nodes (an), Fault Nodes (fn), Event Barriers (eb), AG FT ET Sequences (seq) plc-pressure-setpoint fault. With the security controls or isolation the workstation now becomes unreachable Fig. 7: Planner time vs increasing the size of Safety Graph. which results in both predicate to be false. With this update compilation and previous plan as input we ran VAL (validator) Configurations at five times the test-bench scale in every to find out the reasoning behind the failure. parameter solve within minutes. The practical tractability Plan failed because of unsatisfied precondition in: boundary is near 5,000 plan steps under a 30-minute analysis (discover-engineering-workstation ip-192-dot-168-dot-95-dot-2 budget. Practitioners should manage seq first, as halving it ip-192-dot-168-dot-95-dot-5) Plan failed to execute reduces planning time by roughly 8×. Doubling an or fn at fixed seq costs 3–4× and stays within interactive bounds. For Plan Repair Advice: (discover-engineering-workstation ip-192-dot-168-dot-95-dot-2 very large deployments, decomposing the SG into sub-graphs ip-192-dot-168-dot-95-dot-5) has an unsatisfied with bounded seq is the recommended mitigation. Reasoning precondition at time 10 over unbounded cascade cycles is left as future work. (Set (node-exists ip-192-dot-168-dot-95-dot-5) to true) L = 9091

Total Planning Time (s)

4

L = 4201L = 4951 L = 2701L = 2851L = 3151

3

L = 1601L = 1801 L = 1401 L = 1041

2 1

L = 601L = 651

0

= 326 L = 276L = 301L L = 226

1

L = 37 L = 57

eb an= =4 5, , s fn e = eban=1 q=2 4 =5 0, , s fn eban=1 eq= =8 =1 0, 2 0, fn s = eban=1 eq= 10 =1 0, 3 0, fn s = eban=2 eq= 20 =1 0, 5 0, fn s = eban=2 eq= 20 =1 0, 5 5, fn s = eban=2 eq= 20 =1 5, 5 5, fn s = eban=5 eq= 20 =2 0, 5 5, fn s = eban=5 eq= 40 =2 0, 5 5, fn s = eban=5 eq= 50 =2 0, 5 5, fn eb an= seq =50 =2 60 =8 5, , f s n eb an= eq= =50 =2 80 10 5, , f s n eban=1 eq= =50 =2 00 10 5, , f s n eban=1 eq= =50 =2 00 10 5, , f s n eban=1 eq= =50 =2 00 15 5, , f s n eban=1 eq= =60 =2 00 15 a 5, s , fn ebn=10 eq= =80 =2 0, 15 a 5, s fn= ebn=10 eq= 150 =2 0, 15 5, fn eban=2 seq =20 =1 00 =1 0 00 , f 5 , n eban=2 seq =20 =1 00 =1 0 00 , f 8 , s n= eq 20 =3 0 0

2

L = 106

Fig. 6: VAL’s output for the failed SG plan on the TEP case.

VIII. C ONCLUSION

As illustrated in Figure 6, the action discoverengineering-workstation is failing because the workstation is not accessible by adversary (node-exists ip-192-dot-168-dot-95-dot-5 is false) which stops subsequent cascade in the system.

In this work, we have presented Safety Graph (SG), a formal framework that unifies cyber attacks as Attack Graphs (AG), faults transitions as Fault Trees (FT), and safety measures as Event Trees (ET) over a shared propositional state space to capture the full bidirectional cascade between IT and OT layers in cyber-physical systems. We defined a sound and complete compilation of SG to classical AI planning, reducing crosslayer cascade path discovery to a PSPACE-complete planning problem solvable automatically by a classical planner. The compilation preserves the full semantics of AG attack steps, FT fault transitions, and ET barrier evaluations as planning actions over a unified fluent space. On a simulated Tennessee Eastman Process test-bench, and the planner is able to discover a critical cascade path traversing IT ↔ OT. SG produces hardening recommendations for cascade and verifies them by re-running the planner after applying recommended security control. We have also evaluated how operator’s choices influence the outcome. Scalability analysis confirms tractability across configurations substantially larger than realistic ICS deployments. Automated semantic alignment of propositions across AG, FT, and ET layers, currently requiring domain expert reconciliation, is a natural target for future task. Incremental re-analysis as the vulnerability surface evolves and multi-domain validation in other critical infrastructures are also directions for future work.

B. Scalability Analysis Although the SG framework is intended as an offline resiliency posture analysis platform, we still assessed the tractability for realistic IT-OT deployments. We evaluate on the four core parameters of the SG – attack nodes (an ), fault nodes (fn ), event barriers per ET (eb ), and AG→FT→ET cascade cycles (seq). We assume one event tree per fault. On the TEP instance, we compared Fast Downward with LMcut against FF, LAMA, and blind BFS. LM-cut finds optimal plans fastest, since landmark extraction recovers the mandatory action sequence induced by the cascade structure. The TEP instantiation is an =19, fn =32, eb =6 per ET (≈ 190 total), and seq=2, and it solves in 0.8 seconds. We sweep each parameter independently up to an =200, fn =200, eb =100 per ET, and seq=30. Two hundred attack nodes already exceed a large enterprise network, making the sweep aggressive relative to realistic deployment requirements. The planner solves 192 configurations with planning time ranging from 0.004 to 1,592 seconds (Figure 7). Peak memory stays at 415 MB across the full parameter range, so the encoding remains compact. Doubling plan length increases planning time approximately eightfold. seq dominates the cost because it multiplies the per-cycle contribution of every other parameter. Attack and fault nodes contribute additively within a cycle and scale near-identically, as the symmetry of plan length predicts. This behavior holds under the current SG assumption of deterministic barrier evaluation.

ACKNOWLEDGMENT This work is partially supported by the U.S. Office of Naval Research (ONR) under award N000142612041. The opinions, results, conclusions, and suggestions presented in this work are those of the authors and do not necessarily represent those of the ONR or federal organizations and agencies.

10

R EFERENCES

[22] ——, “Anomaly Detection and Mitigation in Cyber-Physical Power Systems Based on Hybrid Deep Learning and Attack Graphs,” Smart Cyber-Physical Power Systems: Fundamental Concepts, Challenges, and Solutions, vol. 1, pp. 505–537, 2025. [23] C. Few, J. Thompson, K. Awuson-David, and T. Al-Hadhrami, “A Case Study in the Use of Attack Graphs for Predicting the Security of Cyber-Physical Systems,” in 2021 International Congress of Advanced Technology and Engineering (ICOTEN). IEEE, 2021, pp. 1–7. [24] T. J. Williams, “The Purdue Enterprise Reference Architecture,” Computers in industry, vol. 24, no. 2-3, pp. 141–158, 1994. [25] S. Banik, T. Ramachandran, A. Bhattacharya, and S. D. Bopardikar, “Automated adversary-in-the-loop cyber-physical defense planning,” ACM Transactions on Cyber-Physical Systems, vol. 7, no. 3, pp. 1–25, 2023. [26] A. Khaled, S. Ouchani, Z. Tari, and K. Drira, “Assessing the Severity of Smart Attacks in Industrial Cyber-Physical Systems,” ACM Transactions on Cyber-Physical Systems, vol. 5, no. 1, pp. 1–28, 2020. [27] I. Ray, S. Sreedharan, R. Podder, S. K. Bashir, and I. Ray, “Explainable AI for Prioritizing and Deploying Defenses for Cyber-Physical System Resiliency,” in 2023 5th IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA). IEEE, 2023, pp. 184–192. [28] D. Formby, M. Rad, and R. Beyah, “Lowering the Barriers to Industrial Control System Security with {GRFICS},” in 2018 USENIX Workshop on Advances in Security Education (ASE 18), 2018. [29] W. Shang, J. Lu, Z. Cao, L. Ding, M. Zhang, and S. Huan, “A Treebased Scheme to Assess the Safety and Security for Industrial Control Systems,” IEEE Transactions on Dependable and Secure Computing, vol. 22, no. 3, pp. 2011–2021, 2024. [30] C. Agbo and H. Mehrpouyan, “Conflict analysis and resolution of safety and security boundary conditions for industrial control systems,” in 2022 6th International Conference on System Reliability and Safety (ICSRS). IEEE, 2022, pp. 145–156. [31] C. Reinartz, M. Kulahci, and O. Ravn, “An Extended Tennessee Eastman Simulation Dataset for Fault-Detection and Decision Support Systems,” Computers & chemical engineering, vol. 149, p. 107281, 2021. [32] D. J. Smith and K. G. Simpson, The Safety Critical Systems Handbook: A Straightforward Guide to Functional Safety: IEC 61508 (2010 Edition), IEC 61511 (2015 edition) and related guidance. ButterworthHeinemann, 2020. [33] ISA-84, “Instrumented Systems to Achieve Functional Safety in the Process Industries.” [Online]. Available: https://www.isa.org/standardsand-publications/isa-standards/isa-standards-committees/isa84 [34] R. Podder, T. Caglar, S. K. Bashir, S. Sreedharan, I. Ray, and I. Ray, “SPEAR: Security Posture Evaluation using AI Planner-Reasoning on Attack-Connectivity Hypergraphs,” in Proceedings of the 30th ACM Symposium on Access Control Models and Technologies, 2025, pp. 62– 73. [35] B. Nebel, “On the Compilability and Expressive Power of Propositional Planning Formalisms,” Journal of Artificial Intelligence Research, vol. 12, pp. 271–315, 2000. [36] H. Zhao, J. Liu, W. Dong, X. Sun, and Y. Ji, “An Improved Case-Based Reasoning Method and Its Application on Fault Diagnosis of Tennessee Eastman Process,” Neurocomputing, vol. 249, pp. 266–276, 2017. [37] Relyence, “Relyence Fault Tree Analysis Software,” https://relyence.com/products/fault-tree/, accessed: Oct. 2, 2026. [38] M. Helmert, “The fast downward planning system,” Journal of Artificial Intelligence Research, vol. 26, pp. 191–246, 2006. [39] KCL Planning, “VAL: The Automatic Plan Validation Tool,” https://github.com/KCL-Planning/VAL, accessed: Oct. 2, 2026.

[1] C. Tang, A. Alshtein, M. Hardison, E. Holt, C. Sames, H. Tran et al., “Transit Cybersecurity Framework Community Profile,” National Institute of Standards and Technology, Tech. Rep., 2026. [2] M. Baezner and P. Robin, “Stuxnet,” ETH Zurich, Tech. Rep., 2017. [3] D. U. Case, “Analysis of the Cyber Attack on the Ukrainian Power Grid,” Electricity information sharing and analysis center (E-ISAC), vol. 388, no. 1-29, p. 3, 2016. [4] J. Beerman, D. Berent, Z. Falter, and S. Bhunia, “A Review of Colonial Pipeline Ransomware Attack,” in 2023 IEEE/ACM 23rd international symposium on cluster, cloud and internet computing workshops (CCGridW). IEEE, 2023, pp. 8–15. [5] M. Barrère, C. Hankin, and D. O’Reilly, “Cyber-Physical Attack Graphs (CPAGs): Composable and Scalable Attack Graphs for Cyber-Physical Systems,” Computers & security, vol. 132, p. 103348, 2023. [6] P. J. Hawrylak, M. Haney, M. Papa, and J. Hale, “Using Hybrid Attack Graphs to Model Cyber-Physical Attacks in the Smart Grid,” in 2012 5th International symposium on resilient control systems. IEEE, 2012, pp. 161–164. [7] M. Ibrahim, Q. Al-Hindawi, R. Elhafiz, A. Alsheikh, and O. Alquq, “Attack Graph Implementation and Visualization for Cyber Physical Systems,” Processes, vol. 8, no. 1, p. 12, 2019. [8] L. Lemaire, J. Vossaert, B. De Decker, and V. Naessens, “Security Evaluation of Cyber-Physical Systems using Automatically Generated Attack Trees,” in International Conference on Critical Information Infrastructures Security. Springer, 2017, pp. 225–228. [9] F. Xie, T. Lu, X. Guo, J. Liu, Y. Peng, and Y. Gao, “Security Analysis on Cyber-Physical System using Attack Tree,” in 2013 Ninth International Conference on Intelligent Information Hiding and Multimedia Signal Processing. IEEE, 2013, pp. 429–432. [10] S. K. Bashir, R. Podder, S. Sreedharan, I. Ray, and I. Ray, “Resiliency Graphs: Modelling the Interplay Between Cyber Attacks and System Failures through AI Planning,” in 2024 IEEE 6th International Conference on Trust, Privacy and Security in Intelligent Systems, and Applications (TPS-ISA). IEEE, 2024, pp. 292–302. [11] K. Adamos, G. Stergiopoulos, M. Karamousadakis, and D. Gritzalis, “Enhancing Attack Resilience of Cyber-Physical Systems Through State Dependency Graph Models,” International Journal of Information Security, vol. 23, no. 1, pp. 187–198, 2024. [12] I. Semertzis, V. S. Rajkumar, A. Ştefanov, F. Fransen, and P. Palensky, “Quantitative Risk Assessment of Cyber Attacks on Cyber-Physical Systems Using Attack Graphs,” in 2022 10th Workshop on Modelling and Simulation of Cyber-Physical Energy Systems (MSCPES). IEEE, 2022, pp. 1–6. [13] A. Sahu and K. Davis, “Inferring Adversarial Behaviour in CyberPhysical Power Systems using a Bayesian Attack Graph Approach,” IET Cyber-Physical Systems: Theory & Applications, vol. 8, no. 2, pp. 91–108, 2023. [14] H. S. Lallie, K. Debattista, and J. Bal, “A Review of Attack Graph and Attack Tree Visual Syntax in Cyber Security,” Computer Science Review, vol. 35, p. 100219, 2020. [15] E. Ruijters and M. Stoelinga, “Fault Tree Analysis: A survey of the stateof-the-art in modeling, analysis and tools,” Computer science review, vol. 15, pp. 29–62, 2015. [16] C. A. Ericson et al., Hazard analysis techniques for system safety. John Wiley & Sons, 2015. [17] L. H. Chiang, E. L. Russell, and R. D. Braatz, “Tennessee Eastman Process,” in Fault detection and diagnosis in industrial systems. Springer, 2001, pp. 103–112. [18] M. R. H. Talukder, R. Podder, and I. Ray, “VKG2AG: Generating Automated Knowledge-Enriched Attack Graph (AG) from Vulnerability Knowledge Graph (VKG),” in SECRYPT, 2025, pp. 420–428. [19] R. Podder, W. Ganim, S. Sreedharan, I. Ray, and I. Ray, “i-EXAM: Instructable and Explainable Attack Connectivity Graph Modeler,” arXiv preprint arXiv:2607.05888, 2026. [20] R. Podder and I. Ray, “Sera–an ai driven re-programmable simulation environment for explainable resiliency analysis in cyber-physical systems,” in Proceedings of the 6th ACM Workshop on Secure and Trustworthy Cyber-Physical Systems, 2026, pp. 83–92. [21] A. Presekal, A. Ştefanov, V. S. Rajkumar, and P. Palensky, “Attack Graph Model for Cyber-Physical Power Systems Using Hybrid Deep Learning,” IEEE Transactions on Smart Grid, vol. 14, no. 5, pp. 4007–4020, 2023.

A PPENDIX A P LANNER T RACE E XECUTION The planner-generated trace in Figure 4 contains attack, fault, and event steps. We evaluate these steps as follows: Steps 1–2 (HMI and PLC discovery) Running netdiscover on the IT subnet (Figure 8) confirms the HMI (192.168.90.5) is reachable from the attacker (192.168.90.114). ARP spoofing against the HMI reveals Modbus traffic to the PLC (192.168.95.2), exposing coil addresses and communication patterns (Figure 9).

11

Fig. 8: HMI discovery on the IT Subnet.

src

dst

protocol

Fig. 11: The pressure value of the main tank constantly decreasing.

Reading Coils Address and Value

Fig. 9: ARP spoofing and packet analysis using wireshark. a malicious ladder logic file (maliciousplc.st) is uploaded via port 8080, corrupting the pressure setpoint. This validate our claim that safety response can create a cyber precondition that enables a previously unreachable attack.

Step 3 (Firewall bypass) We use Hydra to crack the HMI password. SSH access reveals the pfSense gateway (192.168.90.100). Adding a static route to 192.168.95.0/24 via the firewall gives the attacker direct reachability to the PLC, validating the ‘connect-to-plc-bypassing-firewall’ precondition. Step 4–5 (Modbus injection and fault initiation) An nmap scan identifies the OpenPLC service. A Metasploit Modbus write operation (Figure 10) resets the pressure coil, causing the main tank pressure to drop continuously (Figure 11), confirming the AG→FT transition: ‘faultreactor-pressure-decrease’ is established in the physical process. Steps 6–9 (ET initiation and critical exposure) The abnormal pressure condition triggers the operator safety workflow. Barriers B1–B2 evaluate normally. At B3, ‘evaluate-barrier-b3-plc-logic-check-inworkstation’, the safety procedure requires PLC logic inspection from the engineering workstation, bringing it online. This is the ET→AG transition. The workstation, previously unreachable, enters the reachable state space exactly as modeled. Steps 10–12 (Workstation access and PLC corruption) The engineering workstation is located in the OT segment hosting OpenPLC Editor. Remote access is obtained and

Steps 13–19 (Fault escalation to REX-RUP) The pressuresensor-failure event tree completes the operator-visible response, and the operator may interpret the local response as recovery. However, B3 has already exposed the engineering workstation, allowing the attacker to corrupt the PLC pressure setpoint logic. This corrupted logic establishes the new fault-enabling condition used by the subsequent FT transitions. The process then escalates through ‘fault-relief-pressure-sensor-failure’ and ‘fault-technical-protection-failure’ to ‘fault-reactor-rupture’, observed as pressure exceeding the threshold in the simulated plant (Figure 12).

Fig. 12: The pressure value of the main tank exceeds the threshold.

Our evaluation confirms that the planner-generated SG trace is not merely a modeling artifact. Most importantly, the evaluation supports the central claim of SG such that the critical failure path is not available in the previous models, but becomes realizable once safety-response behavior introduces new cyber exposure through the engineering workstation.

Fig. 10: Modbus injection to PLC using Metasploit.

12

REX-SHT-DWN

A PPENDIX B AUTOMATED PDDL G ENERATION

Reactor Shut Down

The compilation pipeline described in §V produces two PDDL files from the Safety Graph (SG) of the simulated TEP plant running example, domain.pddl, which encodes the fluent space F SG and action families ASG , and problem.pddl, which encodes the initial state I SG , the object set, and the goal GSG . Both files are generated automatically by pddl_generator.py (ref. Artifacts) from the parsed AG, FT, and ET (see Figure 2).

TEC-FAILS

REX-PRESS-D...

Technical Failure

Reactor Pressure Decrease

MECH-FAILS

INST-FAILS

VNT-PTH-OPE...

NO-FEED-REX

PRESS-SNSR-...

Mechanical Failure

Instrumental Failure

Vent or Relief Path Open

No Feed to Reactor

Pressure Sensor Failure

VNT-VLV-OPE...

RLF-ISO-OPE...

A-FEED-0

B-FEED-0

Vent Valve Open

Relief Isolation Open

A FEED is 0

B Feed is 0

A. Attack Graph as Attack Actions

Reactor Pressure Set Point Changed

Fig. 14: Fault Tree for reactor shut down (REX-SHT-DWN). Unauthorized Access to WorkStation

Workstation Discovered IP:192.168.95.5

Reactor Pressure Value goes down

Analyse network traffics to find the COIL

Malicious PLC Script Upload

Privileged Remote Access (PRA)

IT Checks WorkStation PLC Logic

Connected to PLC Exploit Buffer Overflow for Modbus IP:192.168.95.2 Injection

ARP Spoofing on 192.168.90.5

Leaked/Stollen Password

7 8 9 10 11 12 13 14

RLF-PRESS-F...

INST-AIR-LO...

CNTRL-SYS-O...

Relief Pressor Sensor Failure

Instrument AIR Loss

Control System Outage

PRG-VLV-FAI...

A-FEED-HIGH

B-FEED-HIGH

VNT-VLV-CL

RLF-ISOLN-C...

CHEM_REC-FA...

LOW-HEAT-RE...

PRESS-SFTY-...

PRESS-SET-W...

Purge Valve Failure

A Feed High

B FEED HIGH

Vent Valve Closed

Relief Isolation Closed

Chemical Reaction Failure

Low Heat Removal

Pressor Safety Valve Fails

Pressor Set Point Wrong

Scan the Subnet: 19.168.90.0/24

2 3 4

6

REX-RATE-HI... Reaction Rate High

Listing 2 shows the attack action that enable the fault actions precondition.  

Each attack step in the AG becomes a PDDL action whose parameter signature is inferred from the step name and its proposition set. Actions whose source or destination involves two distinct hosts receive two node parameters (?at ?to - node) and actions confined to a single host receive one parameter (?at - node). Listing 1 shows an attack in AG encodes in PDDL.  

5

VNT-PATH-RE... Vent or Relief Path Restricted

XSS vuln in login page of ScadaBR

Fig. 13: Attack Graph for simulated TEP plant.

4

EX-FEED-REX Excess Feed into Reactor

Product Valve Failure

1

3

OUT-BLCK Outlet blocked or restricted

Fig. 15: Fault Tree for reactor rupture (REX-RUP).

HIM (ScadaBR) Discovered IP:192.168.90.5/8080

Attacker IP: 192.168.90.114

2

TECH-P-FAIL Technical Protection Failure

Gain Access to HMI to Steal Data

AND Logical Operation

1

REX-P-EXCEE... Reactor Pressure Exceeds Threshold

PRD-VLV-FAI...

PLC (OpenPLC) Discovered IP:192.168.95.2

Create a Router to bypass pfSense Firewall

OR Logical Operation

REX-RUP Reactor Ruptures

(:action scan-network-and-discover-hmi :parameters (?at ?to - node) :precondition (and (node-exists ?to) (at-node ?at) (connected-to ?at ?to) (attacker-scan-ip-and-port ?to) ) :effect (and (attacker-discover-HMI ?to) (at-node ?to) (attacker-perform-arp-spoofing ?to) ) )

5 6 7 8 9 10 11 12

(:action exploit-buffer-overflow-vulnerability-toreset-pressure-sensor :parameters (?at - node) :precondition (and (attacker-connected-PLC ?at) (at-node ?at) (attacker-analyse-network-traffic-to-find-COIL -number ?at) (attacker-exploit-buffer-overflow-for-modbusinjection ?at) ) :effect (and (Pressure-Sensor-Failure) ) )

  Listing 2: Attack action establishes the fault action’s precondition. B. Fault Tree as Fault Actions Each fault actions encodes one fault edge of the FT. The gate type (OR or AND) of the corresponding FT node determines the precondition shape. Listing 3 shows the a fault action triggered by the cyber attack or attack action.  

  Listing 1: Attacker moves from initial foothold to HMI.

1 2 3 4

13

(:action fault-reactor-pressure-decrease :parameters () :precondition (or (Vent-or-Relief-Path-Open)

(No-Feed-to-Reactor) (Pressure-Sensor-Failure) exploit action

5 6

) :effect (and (Reactor-Pressure-Decrease))

7 8 9 10

  Listing 5: ET action: B1 conditional effect structure encoding the yes/no barrier outcome (Definition 5).

; produced by AG

Listing 6 shows the pivotal barrier action. 

)

  Listing 3: FT action: OR gate over three enabling conditions, one of which is produced by the AG.

1 2 3

The OR precondition directly transcribes the OR gate in Figures 14 and 15. The disjunct ‘Pressure-Sensor-Failure’ is the AG→FT link in the domain.pddl, where a cyber post-condition from Listing 2 appears here as a physical enabling condition. Listing 4 shows the fault action’s pre- and post-conditions.   1 2 3 4 5 6 7 8 9

(:action fault-relief-pressure-sensor-failure :parameters () :precondition (and (event-tree-resolved) (or (Pressor-Safety-Valve-Fails) (Pressure-Set -Point-Wrong)) ) :effect (and (Relief-Pressor-Sensor-Failure)) )

4 5 6 7 8 9 10 11 12

  Listing 6: ET barrier B3: ‘YES’ branch establishes the workstation-check proposition that enables next attack actions. Listing 7 shows the final ET action with the outcomes.  1 2

  Listing 4: FT action: top-level fault gated on ET completion.

3 4 5 6 7 8 9

C. Event Tree Actions

10 11

t1

Time Initial Event (IE)

t2

B1: Low-pressure alarm visible on HMI?

t3 B2: Operator recognizes promptly?

t4

t5

t6

B3: Check Work B4: Correct B5: Automatic Station PLC corrective action low-pressure Logic taken in time? protection works?

t7 B6: Isolation prevention works?

12 O: Outcomes

13 14

Yes

Yes

O1: Normal recovery (pressure restored safely)

15 16

O2: Safe shutdown / safe degraded operation

Yes Yes Yes

17 18 19

No Yes Reactor pressure starts decreasing abnormally

20

No No

21

No Yes

No No

22

O3: Unstable/offspec upset (no containment loss)

23 No

24

O4: Reverse flow / contamination event



(:action evaluate-barrier-b3-plc-logic-check-inworkstation :parameters () :precondition (and (current-time-t3) (b2-resolved) ) :effect (and (when (barrier-b3) ; YES: check performed (and (b3-plc-checked) (b3-resolved))) (when (not (barrier-b3)) ; NO: check skipped (and (b3-resolved))) (not (current-time-t3)) (current-time-t4) ) )

25 26 27



(:action determine-safety-outcome :parameters () :precondition (and (current-time-t7) (b6-resolved) (not (o1-normal-recovery)) (not (o2-safe-shutdown)) (not (o3-upset-no-loss)) (not (o4-contamination))) :effect (and ; O1: Normal recovery (when (and (b1-alarm-visible) (b2-operatorrecognized) (b3-plc-checked) (b4-corrective-intime)) (o1-normal-recovery)) ; O2: Safe shutdown (when (and (not (b4-corrective-in-time)) (b5-auto-protection) (b6-isolationprevention)) (o2-safe-shutdown)) ; O4: Contamination (when (and (not (b4-corrective-in-time)) (not (b6-isolation-prevention))) (o4-contamination)) ; O3: Upset, no loss (catch-all) (when (and (not (o1-normal-recovery)) (not (o2 -safe-shutdown)) (not (o4-contamination))) (o3-upset-no-loss)) (event-tree-resolved) ; gates second fault cascade ) )

  Listing 7: ET action: outcome resolution encodes the out(ω) function as four conditional effects. The unconditional (event-tree-resolved) gates the second fault cascade.

Fig. 16: An Event Tree (Eie ) generated for a fault/Initial Event (ie ) ‘pressure-sensor-failure’.

Each barrier bk compiles to a single action with two conditional effect branches. Listing 5 shows B1 as a minimal Each when clause corresponds to one root-to-leaf example of the pattern.  path in the event tree of Figure 16. The four condi 1 (:action evaluate-barrier-b1-hmi-alarm-visibility tional effects jointly realize the outcome function out : 2 :parameters () {T, F }6 → O from Definition 6. The unconditional ef3 :precondition (and (current-time-t1) (activateevent-tree)) fect (event-tree-resolved) is produced regardless of 4 :effect (and which outcome branch fires, unlocking the second fault cas5 (when (barrier-b1) 6 (and (b1-alarm-visible) (b1-resolved))) cade. (when (not (barrier-b1)) (and (b1-resolved))) (not (current-time-t1)) (current-time-t2)

7 8 9 10

)

11 12

)

14

Related documents

• Safety Graph: When Safety Responses Become Attack Surfaces in Cyber-Physical Systems#1297438
• A survey of emerging threats in cybersecurity#421600
• On the Degree of Safety: Beyond Safe or Unsafe with Control Barrier Functions#925662
• Cybersecurity and Safety Co-Engineering of Cyberphysical Systems—A Comprehensive Survey#671756
• Cybersecurity Foundations: Understanding Computer, Network, and Internet Security#1178679