17 · OT attack paths, detection, and response

Depth: developed lesson with a scenario exercise · Prerequisites: SCADA architecture, trace analysis · Time: two 90-minute sessions.

The previous chapter produced a policy deviation, not a confirmed physical incident. This lesson turns that observation into an investigation with falsifiable claims, competing explanations, and a response decision.

Outcomes

Build an attack path without assuming that each intermediate step succeeded.
Correlate protocol, identity, maintenance, and process evidence.
Test a detection hypothesis against a legitimate maintenance case.
Explain containment choices and missing recovery evidence to an operator.

The attacker’s objective and required authority

In the fictional tank scenario, an attacker’s objective is to change a controller parameter through a path intended only for measurement collection. A possible route is control of the historian, reachability to the controller, acceptance of a write, and an effective change in the running process.

MITRE’s embedded-device threat model describes remotely accessible unauthenticated services and links unauthorized command messages as an observed technique. This motivates checking both the ability to deliver a command and the control enforcing that authority. It does not establish that our synthetic requests caused an impact. See MITRE EMB3D TID-310.

For each link, write the observation that would support it and the observation that would contradict it:

Hypothesis	Evidence to seek in the scenario	A possible contradiction
Historian-originated write	Trace at a relevant observation point, source attribution	Collector mislabeled or duplicated the record
Unauthorized use	Approved role and work order compared with the observed action	Valid, time-bounded exception covers this operation
Controller accepted request	Correlated server decision or configuration evidence	Explicit rejection or request never reached the device
Effective process change	Independent, time-aligned process observation	Value unchanged, overridden, or interpreted differently

A stronger investigation adds evidence at each step. It does not increase the certainty of the last step merely because the first observation is alarming.

Three competing explanations

Hypothesis A — misuse: someone used a reporting path to attempt an unauthorized change. In the trace, r4 is consistent with an unexpected function for the historian label. It leaves actor, intent, acceptance, and effect unresolved.

Hypothesis B — maintenance: a documented maintenance action temporarily used a different host or role mapping. This explanation needs an approved work item naming the relevant action, not a generic statement that maintenance sometimes happens.

Hypothesis C — observation error: the source role or timestamp is wrong, the message is incomplete, or the collector observed traffic before an enforcing boundary. The malformed r5 shows why input quality belongs in the investigation.

Choose the next evidence request that best distinguishes these explanations. A request for “all logs” is usually less useful than a specific question such as “Which approved change covers unit 1, address 101, during this interval?”

Lab: create an investigation timeline

Use the seven records from the offline fixture. Add the following fictional scenario cards to a separate document:

Card	Scenario statement
M1	An approved work item covers the engineering role changing address 101 between 10:00:00 and 10:00:02 UTC.
M2	No work item in the supplied scenario covers historian writes.
O1	The process-observation export is unavailable for 10:00:02–10:00:07 UTC.
A1	Source roles were assigned by the collector configuration; no endpoint identity log was supplied.
R1	A baseline controller-configuration backup exists, but its restoration has not been exercised in this scenario.

These cards are teaching inputs, not real incident records. Combine them with the trace without inventing controller responses.

Write a timeline with separate columns for event time, evidence source, direct observation, interpretation, and confidence limit. Do not mark the missing process interval as “normal.” Missing data leaves a gap.

Reasoning checkpoint

r3 is consistent with M1’s stated time and address, but the role label alone does not prove actor identity. r4 conflicts with M2’s supplied maintenance context. r7 falls outside M1’s address and time coverage even though the simple function rule did not flag it. O1 prevents this evidence set from establishing the physical result of either request. R1 is not a tested recovery procedure.

Lab: evaluate a detection rule

Start with the chapter-16 rule: flag a write under the historian label. Against this fixture it identifies one policy deviation. Its blind spots include a permitted function aimed at an unexpected register, an incorrect role label, and missing observations.

Refine the rule using the scenario cards. Explain how it treats r3, r4, and r7, then create a legitimate maintenance counterexample with a different, explicitly approved window. A rule that flags every write may find suspicious operations while also overwhelming the operator with expected ones.

Do not report real-world detection precision from these hand-picked examples. Instead record a small decision table: three selected requests, their scenario labels, the rule decision, and why. A held-out set with independent labels is needed before claiming general performance.

Response is a decision with dependencies

Draft two response options for the fictional operator:

Option	Intended benefit	Dependency to resolve before choosing it
Restrict the reporting-origin path	Reduce the route carrying unexpected writes	Does that path also carry essential observation or operator functions?
Restrict maintenance access temporarily	Reduce available change authority	Is a necessary approved intervention currently using that access?

Neither row is an instruction to act on a real installation. Your task is to identify which facts an operator needs, who owns the decision, and which observation would show the restriction is working as intended. Preserve the distinction between a security hypothesis and an operating instruction.

For recovery, ask what exact configuration must be restored, who approves it, what dependencies it needs, how success is observed, and how failure is handled. A file named “backup” answers only one small part of that chain.

Write the finding

Title: Reporting-role write request conflicts with the synthetic access policy
Scope: Deadwire offline tank scenario, seven request records
Observation: r4 encodes a write to address 101 under the historian label
Policy comparison: the supplied role table permits historian reads only
Corroboration: M2 provides no matching maintenance exception
Unknowns: actor identity, server acceptance, and physical effect
Control proposal: review command authority and relevant boundary enforcement
Validation plan: test permitted maintenance and denied reporting operations in an approved simulator
Recovery dependency: validate the configuration baseline and restoration procedure

This finding is useful because another reviewer can reproduce its narrow conclusion. “Tank compromised” would claim evidence the scenario does not contain.

Evidence

Submit the timeline, competing explanations, decision table, response comparison, and finding. Include one false-positive counterexample and one blind spot. Acceptance requires explaining r7 despite its initial policy-match label, retaining O1’s gap, and avoiding a claim of successful restoration from R1 alone.

Safety and scope

This is a document-and-fixture investigation. It performs no containment, credential collection, controller changes, or plant operations. Physical and simulator exercises require separate equipment-specific procedures and operator approval.

Teach-back

Which additional evidence would most improve the claim that r4 caused a change?
Why can a permitted protocol function still be outside an approved maintenance task?
What must be known before selecting either containment option?
Why is a restore test different from possessing a backup file?

Next: use the assessment rubric to review this exercise. The coverage map lists the OT topics still to develop, including instrumentation, additional protocols, controller programming, and hardware-specific simulator work.