◇ OpenCyber Academy
Technical · Chapter 9 · English

Chapter 9 — Reading logs and alarms

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 9 — Reading logs and alarms

Lesson map

Lesson 09 published. Map, example, EX033.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Two kinds of messages"]
  N2["9.2 Patterns that matter"]
  N3["9.3 Reading the output"]
  N4["9.4 Escalate, do not investigate alone"]
  N5["9.5 Time matters"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX033"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Two kinds of messages"]
  N2["9.2 Patterns that matter"]
  N3["9.3 Reading the output"]
  N4["9.4 Escalate, do not investigate alone"]
  N5["9.5 Time matters"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX033"]
[Learning outcomes]
    |
    v
[9.1 Two kinds of messages]
    |
    v
[9.2 Patterns that matter]
    |
    v
[9.3 Reading the output]
    |
    v
[9.4 Escalate, do not investigate alone]
    |
    v
[9.5 Time matters]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX033]

Learning outcomes

You will (1) tell process alarms from security-relevant events; (2) filter a log with a short script; and (3) decide when a pattern needs escalation.

9.1 Two kinds of messages

HMIs and PLCs report process alarms such as low film or a jam. They also record logins, setting changes and program downloads. Process alarms are handled by operators; the second kind tells you who did what to the system, and that is where security clues usually appear.

Logins, setpoint changes and program downloads are the records to export and keep. Separating the two keeps the security review short enough to happen every day. Operators still tell the supervisor about an odd pattern of process alarms, because it can be the first visible sign of a security problem.

9.2 Patterns that matter

Several failed logins followed by a success can mean someone guessed a password. A setpoint changed outside a planned job, a program download nobody expected, or an admin login at an odd hour all deserve a look. One event alone is often innocent; the sequence is what matters.

"""Lab 9: filter a synthetic HMI event log for security-relevant entries."""
log = """06:02 HMI-1 login operator1 ok
06:15 PLC-FILL alarm low-film
07:40 HMI-1 login admin fail
07:41 HMI-1 login admin fail
07:41 HMI-1 login admin fail
07:43 HMI-1 login admin ok
07:45 PLC-WRAP setpoint speed 120->180 by admin
08:10 PLC-FILL alarm jam-cleared"""
fails = 0
for line in log.splitlines():
    t, dev, kind, *rest = line.split()
    if kind == "login" and rest[-1] == "fail":
        fails += 1
    if kind == "setpoint" or (kind == "login" and rest[0] == "admin" and rest[-1] == "ok"):
        print("REVIEW", line)
print("failed logins:", fails)

Run with python3 lab_logs.py. Verified output:

REVIEW 07:43 HMI-1 login admin ok
REVIEW 07:45 PLC-WRAP setpoint speed 120->180 by admin
failed logins: 3

At HPFL the lab shows exactly this kind of sequence: three failed admin logins, a success, then a speed change two minutes later. Each event alone could be ignored. Together they raise a question that needs an answer from the supervisor.

9.3 Reading the output

The script counts three failed admin logins, then shows a successful admin login at 07:43 and a wrapper speed change from 120 to 180 two minutes later. Together that is a story worth checking: was a planned change happening at 07:45, and who was logged in?

The script does not explain what happened; it only picks out lines worth asking about. The next step is to check whether a change was planned and who was on shift. At HPFL the answer turned out to be innocent, but the sequence was still worth checking.

9.4 Escalate, do not investigate alone

Tomás's job is to notice and report with evidence: the log lines, the time, what the line did. The controls engineer and security lead decide what happens next.

Report with the log lines attached, the time you noticed them and what the line was doing then. Do not log into devices to look further or change passwords yourself. If the controls engineer asks for more evidence, they will tell you what to collect and how. Keep a copy of what you reported and when you sent it.

9.5 Time matters

Logs are only comparable if device clocks agree. Note any clock difference you know of in your report.

If HMI-1 and PLC-WRAP disagree by several minutes, a setpoint change might appear to happen before the login that caused it. Ask the controls engineer how clocks are set on the line and record any known offset in the register. When you export logs, note the time on your watch and the time shown on each device, so the difference can be corrected later. A clock that drifts by minutes can make an innocent sequence look suspicious, or hide a suspicious one.

Worked example (synthetic HPFL)

Tomás asks the supervisor; no change was planned. The night operator says he forgot the admin password, tried three times, then remembered it and raised speed to clear a backlog. The change is reverted, recorded, and admin use for speed changes is withdrawn from operators.

Synthetic case — HPFL. The log and explanation are invented.

Errors and limits

Logs on small devices are short and may overwrite themselves within days, so export them regularly. An innocent explanation should still be recorded.

Exercises

Synthesis

Security clues sit in login and change records; sequences, not single lines, justify escalation.

Continue studying — chapter 09 of 18

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →