Chapter 13 — Incident risk scenarios and triage thresholds
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes and connection"]
N1["13.1 Scenarios"]
N2["13.2 Severity levels"]
N3["13.3 Triage thresholds"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["13.1 Scenarios"]
N2["13.2 Severity levels"]
N3["13.3 Triage thresholds"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[Learning outcomes and connection]
|
v
[13.1 Scenarios]
|
v
[13.2 Severity levels]
|
v
[13.3 Triage thresholds]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes and connection
You will be able to (1) write incident risk scenarios for Fernmoor's services; (2) define severity levels with observable criteria; and (3) set triage thresholds that decide when an alert becomes a case and when a case escalates. Chapters 10–12 built the service's charter, inventory and evidence; triage rules decide how that service spends its limited attention.
13.1 Scenarios
A risk scenario describes a plausible incident in concrete terms: actor or cause, entry, affected asset, impact and the evidence that would reveal it. Examples for Fernmoor: credential phishing of permit staff leading to resident-data access; ransomware on file servers halting billing; supplier compromise of the payment SFTP; public portal enumeration; insider misuse of the billing database. Scenarios come from the inventory (what matters), threat information (what happens to similar organizations, for example sector advisories) and past cases. NIST SP 800-61 Rev. 3 ties response preparation to the organization's risk assessment; scenarios are the operational form of that link.
13.2 Severity levels
Severity must be decided in minutes with incomplete information, so criteria must be observable. Fernmoor's scale:
- S1 Critical: tier-1 service unavailable or confirmed exfiltration of sensitive personal data, or active spread across systems.
- S2 High: confirmed compromise of an account or host with access to tier-1/2 data, contained to that asset so far.
- S3 Medium: suspicious activity requiring investigation, no confirmed compromise; or confirmed compromise of a low-impact asset.
- S4 Low: policy violation or blocked attack with no compromise.
Severity can go up or down as facts arrive; record each change with its reason.
13.3 Triage thresholds
Thresholds connect detections to actions: which alerts open a case automatically, which need an analyst decision, which are suppressed. They should be based on scenarios and data: a rule whose alerts were 95% benign over three months needs tuning, not an automatic case. Escalation thresholds name the triggers that move a case to S1 or wake the director: personal data involved, public service down beyond its recovery time objective, media inquiry, regulator contact. Fernmoor's thresholds are visible in its worked example: the edge-blocked login attempts with no success stayed at S4 without a case, while the billing clerk's bulk export went straight to S2.
13.4 Worked example (synthetic): applying the scale
Fictional. Three alerts arrive within an hour.
- Edge blocked 3,000 login attempts against the staff portal from one range; no successes. → S4, no case; rule counts feed a weekly report.
billing-clerk-7signed in from a new country, approved MFA, downloaded 4,200 customer records via the billing export. The clerk is on leave. → S2 immediately (confirmed account compromise with tier-1 data access); escalate to S1 if export to an external location is confirmed. The incident lead is paged; the privacy officer is informed under the escalation threshold.- Endpoint detection on a reception PC: macro document blocked. → S4 if blocked and no execution; S3 if any child process ran.
13.5 Common errors and limits
- Severity based on how alarming an alert sounds rather than criteria.
- Never lowering severity, which exhausts the team.
- Thresholds copied from a vendor default without reference to local scenarios.
- Escalation triggers that depend on a judgement nobody is authorized to make.
The three alerts in the worked example show the alternative. The 3,000 blocked login attempts sounded alarming but met the criteria for S4 only; the billing clerk's export sounded routine but met the criteria for S2; the blocked macro stayed at S4 unless a child process ran. In each case the criteria, not the tone of the alert, set the level, and the person authorized to escalate was named.
Exercises — chapter 13
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX037 — Write a scenario. Steps: write the ransomware-on-file-servers scenario with entry, assets, impact, early evidence and detection gaps. Rubric: 3 = all five concrete and linked to inventory; 2 = missing gaps; 1 = generic; 0 = none.
EX038 — Classify cases. Steps: assign S1–S4 to five synthetic situations: lost unencrypted laptop of a permits officer; DDoS slows appointments for 20 minutes; confirmed web shell on permit-app-2; an employee emails a spreadsheet of residents to a personal address; billing database encrypted. Rubric: 3 = all defensible with criteria cited; 2 = four; 1 = two; 0 = none.
EX039 — Tuning decision. Steps: a rule produced 240 alerts in 90 days, 3 true positives (all S3). Propose a threshold decision. Rubric: 3 = calculates ~1.25% precision, keeps detection but tunes or enriches, measures again, avoids suppressing outright without analysis; 2 = no measurement; 1 = suppress; 0 = none.
Chapter synthesis
Write concrete scenarios from your inventory and threat information; define severity by observable criteria; tune triage thresholds with data; and specify escalation triggers someone is authorized to act on.
Continue studying — chapter 13 of 30
← Chapter 12 · Course chapter index · Chapter 14 →
Continue to the next authored lesson.