RISK: Auditing Industrial Control Systems for Too-Late-to-Recover Vulnerabilities

The security of industrial control systems (ICS) requires attention to recovery after detection, as existing efforts often focus only on detection. This paper addresses this gap by defining and auditing too-late-to-recover (TLTR) vulnerabilities, which allow an attack to drain the available recovery margin before detection, rendering subsequent recovery procedures unable to restore the system safely.

The gist

RISK is an automated framework that discovers and validates possible TLTR attack scenarios by holistically modeling and analyzing the PLC control logic, attack detection policies, recovery procedures, and operational behaviors of an ICS to generate TLTR attack scenarios with concrete attack parameters.

How it works

RISK operates in four sequential steps to audit a subject ICS for TLTR vulnerabilities:

1. It first extracts process-specific constraints from PLC programs as well as detection policies, recovery procedures, and, where available, protection policies, organizing them into a unified multi-layer model that characterizes how the process is governed across the control, detection, and supervisory layers.

2. Next, it analyzes operational traces to capture how the process evolves relative to constraints during normal operation, specifically quantifying how quickly the safety margin shrinks and how effective recovery actions are.

3. It then uses this model to explore a space of feasible process manipulations that remain within control and safety limits, yet progressively exhaust recovery margins prior to detection. For this exploration, it leverages a large language model (LLM) agent that suggests candidate TLTR attacks by specifying which process variables to manipulate, when to manipulate them, and by how much, with these attacks evaluated using a virtual PLC (vPLC), a software replica of physical controllers.

4. Finally, it analyzes the resulting execution traces to confirm TLTR attacks, classifying them as recovery-infeasible or recovery-unsafe.

TLTR Vulnerability Formulation

The paper defines an ICS exhibiting a TLTR vulnerability when "adversarial manipulations can drain the available physical or temporal recovery margin before detection, such that, once detected, the deployed recovery procedures can no longer restore the plant to its intended safe operating state due to the insufficient margin. This vulnerability is characterized by attacks that only needs to drive the process to the point, beyond which the deployed recovery procedure will not have sufficient margin to succeed." TLTR vulnerabilities lead to two specific failure modes:

1. Recovery can become infeasible, where the deployed recovery procedure can no longer restore the process to its intended safe operating state within the applicable recovery constraints.

2. Recovery can become unsafe, where executing recovery actions triggers cascading violations or hazards, leading to multiple failures.

Constraint-Guided Trace Analysis

RISK builds a Multi-layer Constraint Model (MCM) and uses it for constraint-guided trace analysis. The MCM is a directed graph where nodes represent constraints annotated with their triggering condition, enforcement action, and regulated variables. Edges capture relationships between constraints, such as implication between activation conditions, shared regulated variables, and interactions across control, detection, and supervisory logic. This model allows RISK to quantify the available recovery margin by deriving three quantities from trace segments:

(Di)

The minimum remaining slack to the relevant recovery-target.

(Ti)

The minimum estimated time to reach that boundary while the process is approaching it.

(Ri)

The maximum observed rate at which slack is restored within the segment.

TLTR Scenario Discovery and Evaluation

RISK discovers candidate TLTR scenarios by exploring admissible process manipulations that reduce the recovery margin at detection relative to the constraint-centric patterns identified above. The LLM agent proposes attack scripts based on these low-margin regions, and these scripts are validated against constraint-derived bounds before being executed in a vPLC environment. The final classification uses Algorithm 1 to determine recoverability:

(Recovery-Infeasible)

If a target constraint is violated after detection and before recovery completes, or if the recovery condition is not reached within the specified interval.

(Recovery-Unsafe)

If execution of the deployed recovery logic is associated with a secondary constraint violation before the recovery condition is reached.

Evaluation and Findings

RISK was evaluated on three ICS testbeds (Fischertechnik manufacturing plant, water treatment testbed, and chemical processing testbed) as well as a real-world fertilizer plant. Across these three testbeds, a total of 392 TLTR attacks are generated and confirmed, with 76% resulting in TLTR conditions. Among these cases, 222 are recovery-infeasible scenarios and 170 are recovery-unsafe scenarios. Furthermore, the paper demonstrates that existing ICS vetting tools like AttackLLM and GENICS only identify a small fraction of TLTR attacks (7% and 8%, respectively), showing that "existing solutions are not TLTR-sensitive.

Here are specific improvements to AI systems based on the methodology and findings of the RISK framework described in the paper, along with what these improved systems can achieve:

1. Develop a new class of Recoverability-Aware or Resilience-Optimized AI Agents for critical infrastructure control.

2. The improved system will be able to proactively identify and mitigate Too-Late-To-Recover (TLTR) vulnerabilities in PLC logic, detection policies, and recovery procedures.

3. Specifically, the system can perform the following functions:

4. Identify TLTR Scenarios: The AI agent will systematically search for adversarial manipulations (within physical constraints) that drain the available physical or temporal recovery margin before a detection event occurs.

5. Characterize Recovery Failure Modes: The system will not only detect if an attack is successful but will explicitly classify the resulting state as either Recovery-Infeasible (where the recovery procedure cannot reach its target constraint within its interval) or Recovery-Unsafe (where executing the recovery procedure triggers cascading secondary constraint violations).

6. Enhance Detection Thresholds: The system can recommend specific, data-driven adjustments to alarm thresholds and detection policies based on predicted TLTR susceptibility, ensuring that alarms trigger early enough for recovery to succeed.

7. Optimize Recovery Procedures: By simulating various attack trajectories against the deployed recovery logic, the system can suggest modifications to existing recovery procedures—such as adjusting actuation rates or timing—to ensure they are robust against margin exhaustion attacks.

8. Provide Proactive Security Auditing: The AI system will serve as a continuous, automated auditor that integrates PLC code analysis (static/dynamic) with operational trace monitoring to continuously assess the real-time recoverability margin of the ICS.

9. Compare and Contrast Attack Generation Methods: The AI system can be used to benchmark existing attack generation tools (like AttackLLM or GENICS) against its own method, providing quantifiable evidence on whether a tool is sensitive to post-detection recoverability constraints, thereby guiding better security research and tool development.