Chapter 19 — Security architecture and engineering: monitoring
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 What to log"]
N2["Lab — Simple alert rules over a day of events"]
N3["19.2 Alert rules"]
N4["19.3 Weekly review"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 What to log"]
N2["Lab — Simple alert rules over a day of events"]
N3["19.2 Alert rules"]
N4["19.3 Weekly review"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 What to log]
|
v
[Lab — Simple alert rules over a day of events]
|
v
[19.2 Alert rules]
|
v
[19.3 Weekly review]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) choose what to log and alert on; (2) write simple alert rules; (3) run a weekly review routine.
19.1 What to log
Tomás decides which events matter: sign-ins to the tracking service and portal, administrator actions, vendor support sessions, firewall changes, backup results and manifest validation flags. He avoids collecting everything, because a small team cannot review it and storage costs money. Each log source is linked to a risk scenario. He checks that clocks on devices are synchronised, since events with wrong times are hard to correlate when investigating an incident across several systems. He also sets retention periods for each source, keeping most logs for ninety days and backup results for a year, so investigations have enough history without excessive storage costs.
Lab — Simple alert rules over a day of events
# Three alert rules over a synthetic day of events: (minute, kind, subject, detail)
events = [(480 + i, "signin_fail", "r-07", "") for i in range(0, 7)] + \
[(600, "signin_fail", "r-02", ""), (605, "signin_fail", "r-02", ""),
(130, "vendor_session", "conveyor", "unapproved"), (840, "vendor_session", "conveyor", "approved"),
(180, "backup", "routeplan", "fail"), (185, "backup", "files", "ok")]
alerts = []
fails = {}
for t, k, s, d in sorted(events):
if k == "signin_fail":
fails.setdefault(s, []).append(t)
recent = [x for x in fails[s] if t - x <= 10]
if len(recent) > 5 and not any(a[1] == s for a in alerts if a[0] == "signin"):
alerts.append(("signin", s, f"{len(recent)} failures by {t//60:02d}:{t%60:02d}"))
elif k == "vendor_session" and d != "approved":
alerts.append(("vendor", s, f"session at {t//60:02d}:{t%60:02d} without approval"))
elif k == "backup" and d == "fail":
alerts.append(("backup", s, "backup failed"))
for a in alerts: print("ALERT", *a)
print(f"{len(alerts)} alerts")
Run with python3 lab_alerts.py. Verified output:
ALERT vendor conveyor session at 02:10 without approval
ALERT backup routeplan backup failed
ALERT signin r-07 6 failures by 08:05
3 alerts
19.2 Alert rules
Tomás writes three rules: alert on more than five failed portal sign-ins for one account within ten minutes; alert on any vendor session outside an approved window; and alert on a failed backup. The lab runs them over a synthetic day of events. It raises three alerts: a burst of failed sign-ins for one retailer account, one vendor session at night with no approval and one failed backup. He investigates each in the synthetic data and writes what a real responder should check first.
19.3 Weekly review
Sam and Tomás set a thirty-minute weekly review: alerts raised, how each was handled, any rule changes and backup status. They record decisions in a shared log. Rules that fire too often are tuned; rules that never fire are tested with a simulated event to make sure they still work. Ruth notes that monitoring is a routine, not a product. A small team that reviews a few good alerts every week sees more than a large team buried in unread dashboards.
Worked example
Tomás chooses log sources tied to scenarios, writes three alert rules tested on synthetic events and sets a weekly review routine.
Synthetic case. Events and rules are synthetic.
Errors and limits
Thresholds miss slow attacks. Unsynchronised clocks confuse investigations.
Exercises
- EX055 — Clock sync. Why check device clocks? Rubric: 3 = events with wrong times are hard to correlate;; 2 = correlation;; 1 = vague;; 0 = none.
- EX056 — Lab alerts. Which three alerts did the lab raise? Rubric: 3 = failed sign-ins for r-07, unapproved night vendor session, failed backup;; 2 = two;; 1 = vague;; 0 = none.
- EX057 — Silent rules. What do they do with rules that never fire? Rubric: 3 = test them with a simulated event;; 2 = test;; 1 = delete;; 0 = none.
Synthesis
Monitoring is a weekly routine built on a few well-chosen logs and rules that are tuned and tested.
Continue studying — chapter 19 of 30
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →