◇ OpenCyber Academy
Rapid course · Chapter 3 · English

Chapter 3 — Recognising and reporting problems

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Recognising and reporting problems

Lesson map

Lesson 03 published. Map, example, EX027.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Normal first"]
  N2["3.2 Reading the lab"]
  N3["3.3 Naming what you saw"]
  N4["3.4 Other warning signs"]
  N5["3.5 Reporting"]
  N6["3.6 Safety comes first"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX027"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Normal first"]
  N2["3.2 Reading the lab"]
  N3["3.3 Naming what you saw"]
  N4["3.4 Other warning signs"]
  N5["3.5 Reporting"]
  N6["3.6 Safety comes first"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]

[Learning outcomes]
    |
    v
[3.1 Normal first]
    |
    v
[3.2 Reading the lab]
    |
    v
[3.3 Naming what you saw]
    |
    v
[3.4 Other warning signs]
    |
    v
[3.5 Reporting]
    |
    v
[3.6 Safety comes first]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX027]

Learning outcomes

You will (1) describe normal behaviour at Elmstead; (2) spot a command that does not fit the schedule; (3) describe what you saw using ATT&CK for ICS names; and (4) write a short, factual report.

3.1 Normal first

The site controller follows a daily schedule: discharge in the morning peak, charge at midday when solar output is high, discharge again in the evening. Commands come from SC-1. Logins happen during planned work. Writing this down is what lets anyone recognise abnormal.

"""Lab 3: compare synthetic battery charge commands with the agreed daily schedule."""
schedule = {"06": "discharge", "12": "charge", "18": "discharge"}
commands = [("06", "discharge", "site-controller"), ("12", "charge", "site-controller"),
            ("14", "discharge", "remote-portal"), ("18", "discharge", "site-controller")]
for hour, cmd, src in commands:
    ok = schedule.get(hour) == cmd and src == "site-controller"
    print(f"{hour}:00 {cmd:9} from {src:15} {'expected' if ok else 'UNEXPECTED - report'}")

Run with python3 lab_soc.py. Verified output:

06:00 discharge from site-controller expected
12:00 charge    from site-controller expected
14:00 discharge from remote-portal   UNEXPECTED - report
18:00 discharge from site-controller expected

A written normal does not need to be detailed to be useful. Lab 3 works from three scheduled hours and one expected source, and that is already enough to make an odd command stand out. As the site changes, for example when the grid operator asks for a different evening pattern, the written schedule must be updated, or the lab will flag legitimate commands.

3.2 Reading the lab

Three commands match the schedule and come from SC-1. At 14:00 a discharge command arrived from the vendor's remote portal: wrong time and wrong source. It may be a vendor test, a mistake or misuse of stolen credentials; you cannot tell from this line alone, and you do not need to. You report it.

The lab also has a blind spot: any command at an hour missing from the schedule is flagged, even when it comes from SC-1. That is acceptable for a short list, because a false alarm is cheap, but a real site would need a fuller schedule. What matters here is that Jonah reports facts without guessing which explanation is true.

3.3 Naming what you saw

MITRE ATT&CK for ICS gives shared names: T0836 Modify Parameter for changed settings, T0886 Remote Services for misuse of remote access routes, T0831 Manipulation of Control for unauthorised commands to the process. Use them to describe observations, not to accuse.

For the 14:00 event at Elmstead, the command itself fits Manipulation of Control, and its route through the vendor portal fits Remote Services. Neither label says who did it or why. They simply let the engineer, the vendor and anyone reading the report later understand what kind of behaviour was seen, in words that mean the same thing to all of them.

3.4 Other warning signs

Battery temperatures rising without load; inverter settings changed with no ticket; new devices on the network; screens disagreeing with local meters; accounts logging in at odd hours; alarms silenced.

None of these signs proves an attack; many come from faulty sensors, rushed maintenance or a forgotten change. Their value is that each one differs from the written normal and can be checked. A trainee who notices one should write down when and where it was seen, keep any screenshot or log line, and pass it to the person on call rather than investigating alone.

3.5 Reporting

Tell the site engineer or the person on call immediately. State what, where, when, the current state and what you have done. Keep evidence: screenshots, log lines, times. Do not change settings, reboot devices or contact the vendor yourself unless asked.

A short message sent quickly is better than a complete one sent late. Jonah's report on the 14:00 command fits in five sentences and still gives the engineer what she needs to decide. Times should include the time zone or say that they are site local time, because portal logs and site logs may not use the same clock.

3.6 Safety comes first

If a battery is overheating, follow the site's fire and safety procedure first; security questions wait.

At Elmstead that means raising the alarm, keeping clear of the battery enclosure and following the evacuation and fire steps on the site card. The person on call can decide later whether the overheating had a security cause. Evidence that is lost while people are kept safe is an acceptable price; a person hurt while saving a log file is not. Safety staff should never wait for a security answer.

Worked example (synthetic Elmstead)

Jonah reports: "14:00 today, BESS received a discharge command from the vendor remote portal, outside schedule (schedule says charge 12:00–18:00). Battery currently discharging. I have not changed anything. Log export saved." The engineer calls the vendor, who has no record of a session; the portal account is disabled and its password reset with MFA enforced.

Synthetic case — Elmstead. The command and response are invented.

Errors and limits

Most unexpected events are mistakes or faults; still report them. Logs from clouds may arrive late or with different time zones.

Exercises

Synthesis

Write down normal, notice what does not fit, describe it plainly with shared names, and report it without touching anything.

Continue studying — chapter 03 of 04

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →