◇ OpenCyber Academy
Professional · Chapter 9 · English

Chapter 9 — Monitoring trends and logs

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 — Monitoring trends and logs

Lesson map

Lesson 09 published. Map, example, EX041.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Trends as evidence"]
  N2["9.2 Change windows"]
  N3["9.3 Reading the output"]
  N4["9.4 Combining sources"]
  N5["9.5 Alerting"]
  N6["9.6 Keeping evidence"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX041"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Trends as evidence"]
  N2["9.2 Change windows"]
  N3["9.3 Reading the output"]
  N4["9.4 Combining sources"]
  N5["9.5 Alerting"]
  N6["9.6 Keeping evidence"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]

[Learning outcomes]
    |
    v
[9.1 Trends as evidence]
    |
    v
[9.2 Change windows]
    |
    v
[9.3 Reading the output]
    |
    v
[9.4 Combining sources]
    |
    v
[9.5 Alerting]
    |
    v
[9.6 Keeping evidence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX041]

Learning outcomes

You will (1) use BMS trend logs as security evidence; (2) flag changes outside approved windows with a short script; and (3) combine trend, login and network evidence.

9.1 Trends as evidence

A BMS records values over time — temperatures, setpoints, valve positions — mainly for engineers. The same records show when a setpoint changed and, with named accounts, who changed it. They are often the best evidence of tampering in a building system.

For Aisha, the trend log is often the first place to look when something seems wrong, because it shows the physical effect directly. Find out how often each point is sampled and how long records are kept before relying on them. Where accounts are shared, the trend shows what changed but not who changed it.

9.2 Change windows

Estates agrees windows for planned setpoint changes, for example weekday mornings. A change outside a window is not necessarily malicious, but it needs an explanation.

"""Lab 9: flag operating-theatre temperature setpoint changes outside a synthetic change window."""
trend = [("01:00", 20.0), ("02:00", 20.0), ("03:00", 26.0), ("04:00", 26.0), ("09:00", 21.0)]
window = ("08:00", "10:00")
prev = None
for t, sp in trend:
    if prev is not None and sp != prev:
        inside = window[0] <= t <= window[1]
        print(f"{t} setpoint {prev}->{sp} {'in window' if inside else 'OUTSIDE WINDOW - review'}")
    prev = sp

Run with python3 lab_trend.py. Verified output:

03:00 setpoint 20.0->26.0 OUTSIDE WINDOW - review
09:00 setpoint 26.0->21.0 in window

The windows should be agreed with estates and written down, with any exceptions such as emergency repairs. Outside the window, the question is simply what happened and who did it. Lab 9 checks one theatre setpoint trend against a morning window and flags any change outside it. Review the windows with estates yearly.

9.3 Reading the output

At 03:00 the theatre setpoint rose from 20 °C to 26 °C, outside the 08:00–10:00 window; it was set back to 21 °C at 09:00 inside the window. The 03:00 change is the one to review.

The return to 21 °C at 09:00 is inside the window, but it is still worth noting because it suggests someone noticed the earlier change and corrected it. Both changes belong in the review, with the questions of who made each and why. The lab shows only the setpoint; the actual theatre temperature trend would show whether the change mattered.

9.4 Combining sources

Check the BMS audit log for who was logged in at 03:00; the gateway log for remote sessions; the firewall log for connections to the BMS zone. Agreement between sources strengthens the conclusion either way.

Record what each source showed, including the ones that showed nothing. At Millbrook the gateway log had no sessions at 03:00, which made a remote change unlikely, and the BMS audit log named the night engineer. The firewall log would have been checked as well if the first two had disagreed.

9.5 Alerting

Where the BMS supports it, raise an alarm for setpoint changes outside windows on critical units, sent to the estates on-call engineer.

Agree with estates which units count as critical, such as the theatre air-handling units, and what the on-call engineer should do on receiving the alarm. An alarm that nobody acts on soon gets ignored. Test it once after setting it up, during a planned change, and record the result. Review the alarm list each quarter with the on-call engineers, removing units that no longer need it.

9.6 Keeping evidence

When a change needs review, export the relevant trend and audit records the same day, note the export time, and store them with the review notes; BMS retention is often short.

Store exports where only the people reviewing the change can read them, with a note of where each came from. At Millbrook trend logs were kept for only 14 days, which later became a finding in Aisha's risk report. Until retention is extended, same-day export is the only safe practice.

Worked example (synthetic Millbrook)

Aisha checks the logs: no gateway sessions at 03:00, but the BMS audit log shows the night engineer raised the setpoint during a chiller fault to reduce load, and forgot to record it. The explanation is documented, and the on-call procedure gains a step: record any out-of-window change in the shift log.

Synthetic case — Millbrook. The trend and explanation are invented.

Errors and limits

Trend logs may sample infrequently and miss short changes; clocks must be synchronised. Retention may be weeks only — export what you need.

Exercises

Synthesis

Trend logs show what changed and when; combined with access logs they explain it.

Continue studying — chapter 09 of 12

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