Chapter 18 — Logging and monitoring
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Choosing events"]
N2["18.2 Centralising"]
N3["18.3 Weekly review"]
N4["18.4 Privacy"]
N5["18.5 Alert fatigue"]
N6["Clock synchronisation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Choosing events"]
N2["18.2 Centralising"]
N3["18.3 Weekly review"]
N4["18.4 Privacy"]
N5["18.5 Alert fatigue"]
N6["Clock synchronisation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Choosing events]
|
v
[18.2 Centralising]
|
v
[18.3 Weekly review]
|
v
[18.4 Privacy]
|
v
[18.5 Alert fatigue]
|
v
[Clock synchronisation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) choose events to collect; (2) centralise logs; (3) review them regularly.
18.1 Choosing events
NIST SP 800-92 recommends deciding which events matter before collecting. For the trust, the useful events are sign-in failures and successes on servers, new accounts and group changes, security software disabled, and backup failures. These answer simple questions: who signed in, what changed, and did protection stop.
Choosing first keeps the volume small enough for a part-time technician to read. Each chosen event answers a question someone at the trust has already asked, such as whether the supply teacher's account had been used after they left, which nobody could answer when Dev noticed it.
18.2 Centralising
Logs on each machine can be deleted by someone who gains control of that machine. Dev forwards server logs to the outside company's log service and uses the endpoint protection console for laptop events. Times are synchronised so events across machines line up.
Sending server logs to the outside company's service also gives a second pair of eyes when Dev is away. Tomás checks that each of the six servers actually appears in the log service, because a server that stopped forwarding would look exactly like a quiet one.
18.3 Weekly review
A thirty-minute weekly review covers a short checklist. Tomás writes it so anyone can follow it: check the sign-in failures list, the new admin group members, the disabled protection alerts and the backup report. Each finding is either explained or turned into a task.
The checklist is written so the business manager or an engineer from the outside company could follow it when Dev is absent. Thirty minutes is enough because the review only looks at the four chosen lists, and anything needing longer becomes a task with a named owner rather than extending the review.
18.4 Privacy
Logs contain staff names and times. They are viewed only for security, kept for ninety days and accessible to Dev and the outside company. Staff are told in the acceptable use policy that security logs are kept.
Viewing logs only for security means they are not used to check when a teacher arrives or how long they spend online, which would be a different purpose needing its own agreement. Ninety days is long enough to look back over a school holiday when investigating something noticed late.
18.5 Alert fatigue
If every alert demands attention, people stop reading them. Tomás suggests tuning alerts so only important events notify Dev immediately, and the rest wait for the weekly review.
In practice, an immediate notification is kept for protection disabled, a new member of an administrator group and a backup missing for two days. Routine blocked downloads stay in the console for the weekly review, and Tomás records each tuning decision so it can be reversed if something important is missed.
Clock synchronisation
Logs are only useful together if their timestamps agree. If one server's clock is five minutes fast, a sign-in on that server can appear to happen after a change it actually caused, and an investigation draws the wrong conclusion. All the trust's servers and laptops take time from the directory servers, which take it from a reliable external source using the network time protocol. Tomás checks the time offset on each server and finds the print server several minutes out, because its time service was disabled. Dev re-enables it, and the weekly review gains a single line confirming that all clocks are synchronised.
Worked example
In the first weekly review, Tomás notices that the shared outside-company account signed in to mis01 at 02:00; the company confirms an agreed maintenance task, and both agree that future maintenance will be noted in the change log beforehand.
Synthetic case. Events are synthetic.
Errors and limits
Collecting logs nobody reads gives false comfort; a short regular review is worth more.
Exercises
- EX052 — Why centralise. Explain why logs should leave the machine that created them. Rubric: 3 = attacker could delete local logs;; 2 = safety;; 1 = vague;; 0 = none.
- EX053 — Review checklist. Write four items for a weekly log review. Rubric: 3 = four relevant;; 2 = three;; 1 = fewer;; 0 = none.
- EX054 — Night sign-in. How should a night-time sign-in by a supplier be handled? Rubric: 3 = verify with supplier, record, improve process;; 2 = ask;; 1 = ignore;; 0 = none.
Synthesis
A few chosen events, centralised and reviewed weekly, give a small team real visibility.
Continue studying — chapter 18 of 30
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →