Lab 03 — Safety-Aware OT Response Decision Engine

Difficulty: 4/5 | Runs locally: yes

Pairs with the Phase 10 WARMUP Chapter 11 (safety-aware incident response) and the HITCHHIKERS-GUIDE ("Recovery Exercise").

Why This Lab Exists (Purpose & Goal)

In IT incident response, the reflex is "isolate the compromised system now." In operational technology, that reflex can kill people — cutting a controller off mid-process can drive the physical process into a dangerous state. The goal of this lab is to build the decision engine that evaluates a proposed incident action against the things IT response ignores: process state, safety approval, manual-operation readiness, evidence needs, vendor dependency, and recovery-image availability — and denies an action that could create an unmanaged physical consequence.

The Concept, In the Weeds

OT inverts the IT priorities: Safety, then Availability, then Integrity, then Confidentiality. A response action is therefore evaluated not just on "does it stop the attacker?" but on "what does it do to the physical process, and who must approve it?" The engine encodes:

  • Process state matters. The same action (isolate a controller) is safe when the process is idle and dangerous mid-batch. Decisions are state-dependent — "ignoring process state" is a flagged mistake.
  • Safety approval and shared authority. Many actions require control-engineer and safety-officer approval; the safety officer holds a veto on anything affecting safety. Response is a multi-stakeholder decision, not a unilateral security call — and "excluding operators" is a flagged mistake, because the operators know the process state and the safe sequence.
  • Manual-operation readiness — the OT lifeline. A containment option unavailable in IT: revert to manual/local operation (operators run the process by hand) so you can isolate the compromised digital control without stopping the physical process unsafely.
  • Evidence, vendor dependency, recovery images. Recovery is complete only when operations confirms safe process behavior — not when the malware is removed.

So the engine denies immediate isolation or restart when it could create an unmanaged physical consequence, and routes the decision to the right authorities with a manual-operation fallback.

Why This Matters for Protecting the Company

For an operator of physical infrastructure, a botched incident response is itself a safety incident — a plant trip, an unsafe shutdown, a release. The TRITON/TRISIS malware specifically targeted a safety system; an unsafe response could have done the harm the safety system existed to prevent. A safety-aware response engine ensures that the security team's actions during an incident protect the physical process and the people near it, by encoding the approval authorities and the manual-operation fallback into the decision. This is how a company defends OT without its own response becoming the catastrophe.

Build It

Implement the decision engine: evaluate proposed incident actions against process state, safety approval, manual-operation readiness, evidence needs, vendor dependency, and recovery-image availability. Deny immediate isolation or restart when it could create an unmanaged physical consequence.

LAB_MODULE=solution pytest -q

Validation — What You Should Be Able to Do Now

  • Explain why immediate isolation or patching can be dangerous in OT, and what to do instead (manual operation first, joint approval, safety veto).
  • Encode response decisions with the right approval authorities (control engineer, safety officer, operations) and a manual-operation fallback.
  • Explain why recovery is complete only when operations confirms safe process behavior, not when the malware is removed.

The Broader Perspective

This lab teaches the most important judgment in all of security: a security action has consequences beyond security, and the right decision weighs the whole impact, with the right people, in the right order. OT makes this vivid because the consequence is physical, but the principle is universal — containment that takes down production (Phase 09), a Conditional Access policy that locks out admins (Phase 07), a sandbox change that breaks a service (Phase 06). The mature engineer never optimizes for the security objective in isolation; they weigh blast radius, sequence the action safely, and bring the stakeholders who hold the missing context and the veto. In OT that discipline is the difference between a contained incident and a disaster — and carrying it everywhere is what makes you trusted to act on systems that matter.

Interview Angle

  • "Respond to suspicious HMI behavior." — Preserve evidence passively; engage control engineering + safety to assess process state; decide containment jointly — isolating/rebooting mid-process may be unsafe, so the option may be manual operation first, then targeted isolation; the safety officer holds veto; no attribution; weigh blast radius and safety in every action.

Extension (Stretch)

Build the joint decision table (which actions require control engineer / safety officer / operations / vendor / legal / executive approval) and run a tabletop recovery exercise with the manual-operation fallback.

References

  • Phase 10 WARMUP Chapter 11; NIST SP 800-82; ISA/IEC 62443; TRITON/TRISIS case study.