Chapter 23 — Logging and monitoring
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 What to log"]
N2["23.2 Reviewing logs"]
N3["23.3 A real pattern"]
N4["23.4 Protecting logs"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 What to log"]
N2["23.2 Reviewing logs"]
N3["23.3 A real pattern"]
N4["23.4 Protecting logs"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 What to log]
|
v
[23.2 Reviewing logs]
|
v
[23.3 A real pattern]
|
v
[23.4 Protecting logs]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) choose which events to log; (2) review logs for suspicious activity; (3) protect logs from tampering.
23.1 What to log
Logs record events: logins, failed logins, changes to accounts, access to sensitive records and system errors. Aisha helps Ashfield decide what to log. She asks what questions an investigator would need answered, such as who viewed this member's record last week or who created this account. Each question points to events that must be logged. Dr. Carrow notes that logging everything produces too much to review, while logging too little leaves investigators blind. She lists six investigation questions and the events each requires in a table.
23.2 Reviewing logs
Logs only help if someone looks at them. Ashfield is too small for a full-time monitoring team, so Aisha proposes automated alerts for a few high-value events: administrator logins outside working hours, many failed logins on one account and bulk viewing of member records by one staff member. The IT manager reviews alerts each morning. She learns that a short list of meaningful alerts is more effective than a long list nobody reads. The review takes about ten minutes each morning and is recorded in a short log.
23.3 A real pattern
In a synthetic review, Aisha finds that one staff account viewed over three hundred member records in an afternoon, far more than usual. Investigation shows the staff member was preparing a legitimate mailing list for an annual meeting, approved by a manager. The alert worked correctly but the activity was authorised. She recommends that bulk tasks be notified in advance, so alerts can be checked quickly and genuine misuse stands out. The operations manager agrees to email IT before any approved bulk task, which takes only a minute and saves investigation time.
23.4 Protecting logs
Attackers who gain control often delete logs to hide their actions. Aisha recommends sending logs to a separate system that ordinary administrators cannot alter, and keeping them for a defined period agreed with the compliance officer. She also recommends that clocks on all systems be synchronised, so events from different systems can be put in order. Dr. Carrow notes that logs are evidence, and evidence must be trustworthy. The compliance officer sets a twelve-month retention period, after which the central system deletes old logs automatically, and the IT manager confirms clocks are synchronised.
Worked example
Aisha chooses events from investigation questions, sets three automated alerts, investigates a bulk-viewing alert that proves authorised and protects logs centrally with synchronised clocks.
Synthetic case. Logs are synthetic.
Errors and limits
Logs kept only where administrators can alter them are weak evidence.
Exercises
- EX067 — Alert events. Name one automated alert event. Rubric: 3 = admin logins outside working hours;; 2 = one;; 1 = vague;; 0 = none.
- EX068 — Bulk viewing. Why did one account view many records? Rubric: 3 = preparing an approved mailing list;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX069 — Clock sync. Why synchronise clocks? Rubric: 3 = to order events across systems;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 23 (chapter 23 of 40)
← Chapter 22 · Course chapter index · Chapter 24 →
Continue to the next authored lesson.