OpenCyber AcademyLesson map
Lesson 37 published. Map, example, EX109.
flowchart TD
N0["Learning outcomes"]
N1["37.1 Daily routines"]
N2["37.2 Incident handling"]
N3["37.3 Post-incident review"]
N4["37.4 Metrics"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX109"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["37.1 Daily routines"]
N2["37.2 Incident handling"]
N3["37.3 Post-incident review"]
N4["37.4 Metrics"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX109"]
[Learning outcomes]
|
v
[37.1 Daily routines]
|
v
[37.2 Incident handling]
|
v
[37.3 Post-incident review]
|
v
[37.4 Metrics]
|
v
[Worked example] --> [Exercise EX109]
Learning outcomes
You will (1) run security operations routines; (2) handle incidents with a defined process; (3) learn from incidents without blame.
37.1 Daily routines
Security operations at Saltmarsh run on routines: reviewing overnight alerts, checking failed backups, reviewing new exceptions and confirming that scheduled checks ran. Lindiwe writes a checklist for the morning shift and times it at about forty minutes. Prof. Hale notes that routines catch drift before it becomes an incident, and that written checklists let new staff cover absences without missing steps that experienced staff perform from memory. She tests the checklist with two analysts during their first week, and both complete it without needing help from experienced colleagues.
37.2 Incident handling
Lindiwe helps write Saltmarsh's incident process using the Detect, Respond and Recover functions of the NIST Cybersecurity Framework 2.0 as a guide, with practical steps to analyse, contain, eradicate, recover and report. Each step has an owner and a template. When a synthetic incident occurs, a phished account sending invoices to customers, the team follows the process: they lock the account, remove forwarding rules, warn customers and report to the retail customer within the required twenty-four hours. The whole incident is closed within two days, and Lindiwe records the timeline in the incident register.
37.3 Post-incident review
After the incident, Lindiwe facilitates a review. The question is not who clicked, but why the attack succeeded and how to make it harder. The review finds that the account lacked multi-factor authentication because it was on an exception list whose expiry had been extended twice without review. The fix is a rule that second extensions need the security lead's approval. She learns that blameless reviews uncover process weaknesses that blame would hide. The security lead approves the new rule the same week.
37.4 Metrics
Lindiwe reports operational metrics monthly: alerts handled, median time to contain, open exceptions, baseline compliance and restore test results. She avoids targets that encourage gaming, such as rewarding fewer alerts, which could be met by turning detection off. Prof. Hale explains that good security metrics describe the state of controls and the speed of response, and that context should always accompany numbers sent to managers. She includes a short commentary with each monthly report explaining any significant change, so readers do not misread a rise in alerts as a decline in security.
Worked example
Lindiwe writes a forty-minute morning checklist, runs a phished-account incident through a defined process, holds a blameless review finding a repeatedly extended exception and reports balanced metrics.
Synthetic case. The incident is synthetic.
Errors and limits
Rewarding fewer alerts can encourage turning detection off.
Exercises
- EX109 — Checklist length. How long does the morning checklist take?
Show marking criteria
Rubric: 3 = about forty minutes;; 2 = partly correct;; 1 = wrong;; 0 = none. - EX110 — Incident actions. Name one containment action taken.
Show marking criteria
Rubric: 3 = locking the account;; 2 = one;; 1 = vague;; 0 = none. - EX111 — Root cause. Why did the account lack multi-factor authentication?
Show marking criteria
Rubric: 3 = an exception extended twice without review;; 2 = partly correct;; 1 = vague;; 0 = none.