Chapter 14 — Recognising abnormal behaviour
Lesson map
Lesson 14 published. Map, example, EX053.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Knowing normal"]
N2["14.2 Signs to report"]
N3["14.3 Naming what you saw"]
N4["14.4 Fault or attack?"]
N5["14.5 What not to do"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX053"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Knowing normal"]
N2["14.2 Signs to report"]
N3["14.3 Naming what you saw"]
N4["14.4 Fault or attack?"]
N5["14.5 What not to do"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX053"]
[Learning outcomes]
|
v
[14.1 Knowing normal]
|
v
[14.2 Signs to report]
|
v
[14.3 Naming what you saw]
|
v
[14.4 Fault or attack?]
|
v
[14.5 What not to do]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX053]
Learning outcomes
You will (1) describe what normal looks like for the HPFL line; (2) recognise signs that may indicate an attack or a fault; and (3) use ATT&CK for ICS names to describe what you saw.
14.1 Knowing normal
Operators know the line's sound, rhythm and screens. Technicians add network and system normal: which devices talk, which accounts log in, how often programs change. Write it down; "normal" kept only in people's heads disappears with shift changes.
At HPFL Tomás already wrote down that writes come only from HMI-1 and ENG-LT. Similar notes can cover typical login times, how often PLC programs change and which devices appear on the network. Keep them in the register or a shared document, dated and updated after changes.
14.2 Signs to report
A setpoint changes without anyone pressing a button. HMI screens freeze or show values that disagree with gauges. A program download appears in the log with no job. A new device appears on the network. Remote sessions occur outside a ticket. The line stops with no mechanical cause.
Report any of these with the time, the device and what you saw, and attach photographs or log lines where you can. At HPFL a mismatch between HMI-1 and a handheld thermometer turned out to be a failed sensor, but the report still led to a quick diagnosis.
14.3 Naming what you saw
MITRE ATT&CK for ICS gives shared names: T0836 Modify Parameter for altered setpoints, T0886 Remote Services for misuse of remote access, T0843 Program Download for unexpected logic changes. Using these names in a report helps the security team, but report what you observed, not a guess at the attacker.
The names help when reports are compared across shifts or sites. Write the observation first, then the technique name if it fits: for example, wrapper speed changed from 120 to 180 by admin at 07:45, which fits Modify Parameter. Leave intent and attribution to the security team.
14.4 Fault or attack?
Most abnormal events are faults or mistakes. That does not matter at first: the response is the same — keep people safe, preserve evidence, report. Deciding the cause comes later.
At HPFL the temperature mismatch was a failed sensor, and the speed change was an operator's well-meant adjustment. Both were handled with the same steps: make safe, record, report. The cause was found afterwards, with the evidence that had been kept. Treating every event the same way also avoids embarrassment: nobody is accused, and nothing is dismissed too early.
14.5 What not to do
Do not reboot devices, delete logs, unplug cables or "fix" values before the supervisor and engineer agree; you could destroy the evidence of what happened or create a new hazard.
The supervisor decides whether the line keeps running; the engineer decides how to examine devices. Your part is to photograph, note the time and call. If a hazard requires immediate action, follow normal safety procedures and record what you did. At HPFL Tomás did not reset the sensor. That restraint kept the evidence that later showed the cause.
Worked example (synthetic HPFL)
HMI-1 shows the filler at normal temperature, but the operator's handheld thermometer reads 12 °C higher. Tomás photographs both readings, notes the time, and calls the supervisor, who stops the filler safely. Later the engineer finds a failed sensor — a fault, not an attack — but the evidence made the diagnosis quick.
Synthetic case — HPFL. The readings are invented.
Errors and limits
A list of signs is not complete; trust experienced operators who say "this is not right". ATT&CK describes techniques, not certainty about intent.
Exercises
- EX053 — HMI disagrees with gauge. What does a difference between HMI and a local gauge suggest, and what is the first action? Rubric: 3 = sensor fault or manipulated display; keep safe/stop via supervisor, record evidence; 2 = one part; 1 = trust HMI; 0 = none.
- EX054 — Matching techniques. Match to ATT&CK for ICS: (a) unplanned program download; (b) vendor session outside ticket; (c) changed speed value. Rubric: 3 = T0843, T0886, T0836; 2 = two; 1 = one; 0 = none.
- EX055 — Same response. Why is the initial response the same for a fault and an attack? Rubric: 3 = safety and evidence first, cause unknown at start; 2 = partial; 1 = "it isn't"; 0 = none.
- EX056 — Writing down normal. Give three items for an HPFL "normal" sheet. Rubric: 3 = three specific items (talkers, login pattern, change frequency etc.); 2 = two; 1 = vague; 0 = none.
Synthesis
Knowing normal lets you notice the abnormal; respond for safety and evidence before deciding cause.
Continue studying — chapter 14 of 18
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →