Chapter 5 — Security literacy
Lesson map
Lesson 05 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes and connection"]
N1["5.1 Precise terms"]
N2["5.2 The lifecycle in NIST SP 800-61 Rev. 3"]
N3["5.3 Techniques and their evidence"]
N4["5.5 Defence in depth, briefly"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["5.1 Precise terms"]
N2["5.2 The lifecycle in NIST SP 800-61 Rev. 3"]
N3["5.3 Techniques and their evidence"]
N4["5.5 Defence in depth, briefly"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]
[Learning outcomes and connection]
|
v
[5.1 Precise terms]
|
v
[5.2 The lifecycle in NIST SP 800-61 Rev. 3]
|
v
[5.3 Techniques and their evidence]
|
v
[5.5 Defence in depth, briefly]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes and connection
You will be able to (1) use the vocabulary of event, alert, incident, vulnerability, threat and risk precisely; (2) relate common attack techniques to the evidence and controls in your service; and (3) explain the response lifecycle in the current NIST framing. Chapters 1–4 gave you systems, networks, code and data; this chapter gives you the language the response service is built on.
5.1 Precise terms
An event is any observable occurrence. An alert is an event or pattern that a detection rule flagged for attention. An incident is an occurrence that actually or imminently jeopardizes confidentiality, integrity or availability, or violates policy. A vulnerability is a weakness; a threat is a circumstance or actor with potential to exploit it; risk combines likelihood and impact. Most alerts are not incidents, and many incidents begin as something other than an alert — a call from a resident, a supplier notice, a journalist's question.
5.2 The lifecycle in NIST SP 800-61 Rev. 3
Rev. 3 (April 2025) replaces the earlier four-phase lifecycle with a mapping onto the CSF 2.0 functions: Govern, Identify and Protect support preparation; Detect, Respond and Recover cover the incident itself; improvement feeds back into all functions. For a technologist this means the response service is not a separate island: inventory (Identify), access control (Protect), monitoring (Detect) and recovery planning (Recover) are all parts of it. The impossible-travel case shows the mapping at work. Detection raised the alert, MFA from the Protect function stopped the session, and the analyst's response, a password reset and a recorded decision, sat under Respond. The password-spraying pattern found earlier came from Identify-style knowledge of which accounts and logs existed.
5.3 Techniques and their evidence
MITRE ATT&CK catalogues adversary tactics and techniques observed in real intrusions. You do not need to memorize it; you need to connect a technique to where its traces would appear in your systems. For example: valid-account use appears in identity logs; persistence through new authentication methods appears in identity audit logs; data collection appears in file-server or database audit logs; exfiltration appears in edge or egress flow logs. For the water-billing-2 case, this mapping told the analyst where to look: spraying appears in identity sign-in logs, and a newly registered method would appear in identity audit logs.
5.4 Worked example (synthetic): from alert to incident
Fictional. At 08:40 an alert fires: "impossible travel" for water-billing-2 — a sign-in from Fernmoor and, eleven minutes later, from a foreign hosting provider. The duty analyst checks: the second sign-in failed MFA; no session was created; the account owner confirms she was at work. Classification: alert true-positive for suspicious activity, not an incident yet (no jeopardy realized), but it joins the password-spraying pattern found in Chapter 3. The analyst opens a case at low severity because the password is evidently known to someone else, resets it, and records the decision. Had MFA been approved, the same alert would have been an incident: valid credentials used by an unauthorized party.
5.5 Defence in depth, briefly
No single control is reliable. The example shows layers: a detection rule raised an alert; MFA blocked the session; a human verified with the owner; a script found the broader pattern. Your service should know which layer caught each case — that information drives improvement (Chapter 19). In the water-billing-2 case, no single layer would have been enough. Without MFA the session would have succeeded; without the human check the analyst could not have ruled out a legitimate trip; without the script the alert would have looked like one isolated event rather than part of a spraying pattern. Recording which layer acted in each case shows where the next investment matters.
5.6 Common errors and limits
- Calling every alert an incident, which floods the case system, or calling nothing an incident until damage is proven, which delays response.
- Using ATT&CK labels as conclusions rather than hypotheses to test.
- Treating the lifecycle as strictly sequential; containment and investigation overlap.
The impossible-travel case shows the balance. The analyst did not declare an incident, because no access was gained, but did open a low-severity case and reset the password, because someone else evidently knew it. That kept the case system honest while still responding to the risk. The ATT&CK label for password spraying stayed a hypothesis until the script showed the same pattern across many accounts.
Exercises — chapter 5
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.
EX013 — Classify. Steps: classify five synthetic occurrences as event, alert, incident or not security-relevant, with reason: a failed sign-in; a firewall deny; a resident reporting a phishing SMS using Fernmoor's name; ransomware note on a file server; a detection rule on a known admin script. Rubric: 3 = all five defensible with reasons; 2 = four; 1 = two; 0 = none.
EX014 — Technique to evidence. Steps: for three techniques (valid accounts, adding an MFA method, bulk file reads), name the Fernmoor log where traces would appear and one control. Rubric: 3 = correct source and control for each; 2 = two; 1 = one; 0 = none.
EX015 — CSF mapping. Steps: map five response-service activities to CSF 2.0 functions. Rubric: 3 = five correct (e.g., inventory–Identify, MFA–Protect, alerting–Detect, containment–Respond, restore test–Recover); 2 = four; 1 = two; 0 = none.
Chapter synthesis
Use event, alert and incident precisely; place response inside the CSF 2.0 functions as Rev. 3 does; connect each technique to the evidence it leaves in your own systems; and record which layer caught each case so the service can improve.
Continue studying — chapter 05 of 30
← Chapter 04 · Course chapter index · Chapter 06 →
Continue to the next authored lesson.