PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Rakesh Podder, Philip D. Hopkins, Sarath Sreedharan, Indrakshi Ray, Indrajit Ray

arXiv:2610.13086v1cs.CR

TL;DR

Existing frameworks model cyber attacks escalating from IT to OT, but do not capture safety responses that create new IT attack surfaces. SG unifies attack, fault, and event models and compiles them to classical planning. On the Tennessee Eastman test-bench, it found a critical failure reachable in SG but not with AG and FT, identifying the enabling barrier and validating planner steps live.

  • Problem

    Existing frameworks model cyber-to-physical escalation but do not capture how OT safety responses can create new IT attack surfaces and enable further attacks.

    Source: §I · p. 1

  • Method

    Safety Graph unifies Attack Graphs, Fault Trees, and Event Trees over a shared propositional state space and compiles them into classical AI planning.

    Source: §I · pp. 1–2

  • Results

    The critical failure was unreachable with AG and FT but reachable in SG; the enabling barrier was identified and planner steps were validated in a live test-bench.

    Source: §I · p. 2

  • Takeaways & Limitations

    Models that treat safety responses as terminal events cannot capture safety-response-induced lateral movement.

    Source: §I · p. 2

Abstract

from arXiv · show

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 safety-response-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.

I. INTRODUCTION

Prior models capture attacks moving from IT toward OT but treat safety responses as terminal, leaving safety-response-induced cyber exposure unmodeled. Safety Graph (SG) unifies attack, fault, and event models so the full bidirectional cascade can be analyzed through planning.

II. RELATED WORK

  • Prior frameworks model cyber-to-physical escalation in detail but treat safety responses as terminal, so they miss fault-driven responses that create new IT attack surfaces.Earlier approaches include attack graphs, attack trees, resiliency graphs, state dependency graphs, and hybrid cyber-physical frameworks.Source: §I · p. 1, §II · pp. 2–3

I. INTRODUCTION

  • SG integrates Attack Graphs, Fault Trees, and Event Trees over a shared propositional state space to model their interdependencies.Its compilation to classical AI planning is described as sound and complete, with theoretical guarantees.Source: §I · pp. 1–2
  • SG captures the bidirectional cascade: attacks can enable faults, faults can trigger safety events, and safety outcomes can create preconditions for later attacks.The planning compilation represents attack steps, fault transitions, and barrier evaluations as actions over system-state propositions.Source: §I · p. 2
  • Safety-response-induced lateral movement occurs when a prescribed response to a physical fault opens a new attack surface, such as through recovery-time network reconfiguration.A vulnerability that is unexploitable during normal operation may become exploitable after that reconfiguration.Source: §I · pp. 1–2
  • On the Tennessee Eastman test-bench, the critical failure was unreachable with AG and FT but reachable in SG; the enabling barrier was identified and planner steps validated live.The planner found a cross-layer path through AG → FT → ET → AG → FT.Source: §I · p. 2

III. RUNNING EXAMPLE

The section presents a virtualized Tennessee Eastman test bench and defines the assumptions and propositional representations used to model cyber, fault, and safety-response states. It then describes how attacks are represented as graph transitions.

III. RUNNING EXAMPLE

  • The Tennessee Eastman Process test bench combines web-3D modeling and virtualization to support control, monitoring, and fault-propagation testing,.Its networked setup connects an HMI, OpenPLC, engineering workstation, firewall, process simulation, and attacker VM across segmented IT and OT subnets.Source: §III · p. 3

IV. THREAT MODEL AND ASSUMPTIONS

  • The model assumes a capability-bounded attacker with an IT foothold who can exploit known vulnerabilities and use safety-response side effects, but not alter prescribed procedures.Operators follow documented procedures, while vulnerability, configuration, and failure information are assumed available; system state is fixed during analysis and changes require rerunning it.Source: §IV · p. 3

V. SAFETY GRAPH (SG) FORMALIZATION

  • Safety Graph represents cyber attacks, OT faults, and timed safety responses using propositional attributes over a shared state space.Host, fault, and event attributes support cascades from attacks to faults to event trees and back to new cyber exposure.Source: §V · pp. 3–4

A. Attack Graph (AG)

  • An attack graph is an AND-OR graph whose host-and-attribute nodes are connected by edges enabled by attack preconditions and effects.For example, discovering a PLC through ARP spoofing requires an attacker foothold, a compromised HMI, a live PLC, and the spoofing action.Source: A. Attack Graph (AG) · p. 4

B. Fault Tree (FT)

The fault tree models how OT fault conditions occur and escalate at particular hosts. The event tree then evaluates ordered safety barriers after an initiating fault to determine the resulting operational or safety state.

B. Fault Tree (FT)

  • Fault-tree nodes attach fault propositions to hosts, and fault edges encode how enabling conditions produce or escalate those host-specific faults.Fault conditions are represented as host-indexed propositions rather than standalone events.Source: B. Fault Tree (FT) · p. 4

C. Event Tree (ET)

  • An event tree orders safety barriers after an initiating fault, with each barrier producing a binary outcome and changing host state.Barrier outcomes depend on whether the assigned proposition holds; operators may choose whether to implement a prescribed barrier.Source: C. Event Tree (ET) · p. 5
  • The sequence of barrier outcomes maps to an event-tree consequence class, such as mitigated, degraded, unsafe-escalation, or exposure-created.A complete execution evaluates barriers from the initial time step through the final step and applies the outcome function to the resulting outcome vector.Source: C. Event Tree (ET) · p. 5

D. Safety Graph (SG)

Safety Graph unifies attack graphs, fault trees, and initiating-event-specific event trees over shared propositions. It represents cross-domain transitions without separate linking relations.

D. Safety Graph (SG)

  • Safety Graph comprises an attack graph, a fault tree, and one event tree for each initiating-event proposition.The unified model uses shared propositions to represent attack-enabled faults, fault-triggered events, and safety-response outcomes that establish preconditions for subsequent attacks.Source: D. Safety Graph (SG) · pp. 5–6
  • The paper compiles Safety Graph into a planning problem and uses planners for automated reasoning over complex IT-OT deployments.The authors motivate planning because its search scales to large problem spaces.Source: D. Safety Graph (SG) · p. 6

E. Planning Compilation for SG

The compilation maps Safety Graph states and transitions to a classical planning model. The paper establishes soundness and completeness and shows that finding a cascade path is PSPACE-complete.

E. Planning Compilation for SG

  • The compilation represents host attributes and event-tree propositions as fluents, and attack, fault, and barrier-evaluation steps as planning actions.Attack and fault actions encode their preconditions and effects; barrier actions advance the event-tree stage and apply the branch determined by the barrier condition.Source: E. Planning Compilation for SG · pp. 6–7
  • The planning model is sound and complete: valid plans correspond to valid cross-layer Safety Graph paths, and valid paths correspond to plans.The proof relies on a one-to-one correspondence between Safety Graph edges or barrier evaluations and planning actions.Source: E. Planning Compilation for SG · p. 7
  • PSPACE-complete: determining whether a general Safety Graph contains a cascade path.The hardness argument reduces any classical planning problem to a Safety Graph path-existence problem.Source: E. Planning Compilation for SG · p. 7

VI. ANALYSIS OF SG FOR RUNNING EXAMPLE

The running example tests whether an IT foothold can lead to reactor rupture. AG+FT alone cannot reach that fault, while adding safety-response behavior yields a path and identifies its enabling barrier.

B. Analysis on the Running Example

  • With AG+FT alone, the planner reaches the initial pressure-decrease fault but finds no plan to reactor rupture.The required FT transitions need preconditions that the AG+FT model never establishes.Source: §VI · p. 7
  • Adding the ET safety measures produces a feasible cascade path that was absent under AG+FT alone.The planner identifies a safety barrier as the precise enabling mechanism.Source: §VI · p. 7
  • The analysis poses the critical question as whether an IT foothold can reach reactor rupture and, if so, what enables it.The workflow generates an SG instance and analyzes it with a planner.Source: §VI · p. 7

A. Constructing the SG Instance

The TEP instance is assembled from network, fault, and safety documentation, then compiled for planning analysis. In the running example, safety-response behavior creates a path to reactor rupture that AG+FT alone cannot find.

A. Constructing the SG Instance

  • The SG instance draws on network configuration, penetration-test results, CTI, TEP fault analysis, and safety manuals.It models 32 faults with 5–6 barriers per event tree, approximately 190 barriers total; extracted propositions are validated by domain experts.Source: A. Constructing the SG Instance · pp. 7–8
  • Automated scripts map attacks, fault transitions, and barrier evaluations into PDDL fluents and actions for Fast Downward A* analysis.The workflow analyzes plans, applies mitigations, and uses VAL to check why an updated plan fails.Source: A. Constructing the SG Instance · p. 8, Figure 2 · p. 8

B. Analysis on the Running Example

  • AG+FT reaches the initial pressure-related fault, but the planner finds no path from the IT foothold to reactor rupture.The escalation needs FT-transition preconditions that the AG+FT model does not establish.Source: B. Analysis on the Running Example · p. 8
  • Adding ET safety responses yields a feasible cascade, with barrier B3’s PLC inspection bringing the engineering workstation online.The first four attack steps match the AG+FT case; B1 and B2 represent alarm visibility and operator recognition.Source: B. Analysis on the Running Example · p. 8
  • The live workstation becomes a host-level precondition for attack, enabling compromise and malicious PLC-logic upload before the FT chain reaches reactor rupture.The subsequent fault chain passes through relief-pressure-sensor and technical-protection failures.Source: B. Analysis on the Running Example · p. 9, Figure 4 · p. 9
  • The planner-generated path exposes a safety-response-induced attack surface absent from prior models and yields a recommendation to keep the engineering workstation isolated or enforce network controls during safety checks.The proposed hardening follows from the workstation being brought online at B3.Source: B. Analysis on the Running Example · p. 9

VII. EVALUATION

The evaluation replays planner traces in the TEP test-bench, models operator choices and mitigations, and measures planning scalability. Its conclusion reports tractability beyond realistic ICS deployment sizes while identifying expert reconciliation and unbounded cycles as future-work areas.

VII. EVALUATION

  • Planner-generated SG traces are replayed step by step in the TEP test-bench to verify that abstract attack, fault, and barrier actions execute in the deployed environment.Validation evidence includes network observations, protocol traces, reachability tests, workstation logs, and process-state changes.Source: §VII · p. 9

A. Operator’s Decision & Mitigation

  • Operator choices affect barrier outcomes; the running example finds that omitting the B3 PLC-logic check avoids the new attack surface, while isolation or security controls make the workstation unreachable.The study iterates across operator decisions and goal-state combinations, then uses VAL to identify the failed workstation-discovery action after mitigation.Source: A. Operator’s Decision & Mitigation · pp. 9–10

B. Scalability Analysis

  • The TEP instantiation has an=19, fn=32, eb=6 per ET (≈190 total), and seq=2, and solves in 0.8 seconds.Across 192 configurations, planning time ranges from 0.004 to 1,592 seconds, with peak memory of 415 MB.Source: B. Scalability Analysis · p. 10
  • Configurations at five times the test-bench scale in every parameter solve within minutes, with a practical boundary near 5,000 plan steps under a 30-minute budget.Halving seq reduces planning time by roughly 8×; doubling an or fn at fixed seq costs 3–4×.Source: B. Scalability Analysis · p. 10

VIII. CONCLUSION

  • The conclusion presents SG as a sound and complete planning compilation for cross-layer cascade discovery and reports a critical IT↔OT path and hardening recommendations on the simulated TEP bench.Automated semantic alignment, incremental re-analysis, and validation in other infrastructures remain future directions; unbounded cascade cycles are also left for future work.Source: §VIII · p. 10, B. Scalability Analysis · p. 10

APPENDIX A PLANNER TRACE EXECUTION

The planner trace shows an attack progressing from IT discovery to a physical fault, then using a safety response to expose an engineering workstation and enable further PLC corruption. The appendix also describes automatic generation of the planning files from the Safety Graph.

APPENDIX A PLANNER TRACE EXECUTION

  • Network discovery and traffic analysis revealed a reachable HMI and Modbus traffic to the PLC; firewall bypass enabled PLC access and pressure-coil manipulation.The Modbus write caused main-tank pressure to drop continuously, initiating the physical fault.Source: Appendix A · pp. 11–12, Figure 8 · p. 12, Figure 9 · p. 12
  • The exposed engineering workstation enabled PLC setpoint corruption, and the simulated process escalated to reactor rupture as pressure exceeded its threshold.The planner trace identifies B3’s PLC logic check as the step that brought the previously unreachable workstation online.Source: Appendix A · p. 12, Figure 12 · p. 12

APPENDIX B AUTOMATED PDDL GENERATION

  • The appendix describes automatic generation of domain.pddl and problem.pddl from the parsed attack graph, fault tree, and event tree.The domain file encodes the fluent space and action families; the problem file encodes the initial state, objects, and goal.Source: Appendix B · p. 13

A. Attack Graph as Attack Actions

Attack-graph steps are encoded as PDDL actions, translating network attack paths into planning operators. Their parameter signatures reflect whether an attack crosses hosts or stays on one host.

A. Attack Graph as Attack Actions

  • Each attack-graph step becomes a PDDL action whose parameters are inferred from its name and propositions.Actions involving distinct source and destination hosts receive two node parameters; single-host actions receive one.Source: A. Attack Graph as Attack Actions · p. 13
  • The illustrated discovery action represents an attacker moving from an initial foothold to the HMI through network scanning and discovery steps.The listing includes scanning IPs and ports, discovering the HMI, and performing ARP spoofing.Source: A. Attack Graph as Attack Actions · p. 13
  • An attack action can establish a fault action’s precondition, encoding the cyber-to-physical transition in the planning domain.The text identifies the attack’s postcondition as the physical enabling condition for a fault.Source: A. Attack Graph as Attack Actions · p. 13

B. Fault Tree as Fault Actions

Fault-tree edges become PDDL actions, with the tree’s gate type determining action preconditions. This permits cyber-produced conditions to enable modeled physical faults.

B. Fault Tree as Fault Actions

  • Each fault-tree edge is encoded as a PDDL action, and its node’s OR or AND gate determines the precondition structure.The pressure-decrease action illustrates an OR gate over three enabling conditions.Source: B. Fault Tree as Fault Actions · pp. 13–14
  • The OR precondition represents the fault-tree gate, including a pressure-sensor-failure condition produced by an attack action.This links the cyber postcondition to a physical enabling condition in the planning domain.Source: B. Fault Tree as Fault Actions · pp. 13–14

C. Event Tree Actions

Event-tree barriers and outcomes are represented through conditional effects in PDDL actions. The resulting event-tree resolution also gates a subsequent fault cascade.

C. Event Tree Actions

  • Each event-tree barrier compiles to one action with conditional branches for whether the barrier succeeds or is skipped.The B3 “YES” branch establishes the PLC-check proposition that enables later attack actions.Source: C. Event Tree Actions · p. 14
  • A barrier action’s conditional effect records its evaluated outcome and advances the event-tree sequence.The B1 example encodes the yes/no barrier outcome and updates the current-time proposition.Source: C. Event Tree Actions · p. 14
  • The final event-tree action encodes four possible outcomes through conditional effects, with event-tree resolution gating the second fault cascade.Each conditional effect corresponds to a root-to-leaf path in the event tree.Source: C. Event Tree Actions · p. 14
Loading 2610.13086v1…