OpenCyber AcademyLesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes and connection"]
N1["19.1 A short history"]
N2["19.2 Lifecycle models"]
N3["19.3 Assumptions behind the models"]
N4["19.4 Resilience"]
N5["19.5 Coordination theory"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["19.1 A short history"]
N2["19.2 Lifecycle models"]
N3["19.3 Assumptions behind the models"]
N4["19.4 Resilience"]
N5["19.5 Coordination theory"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX055"]
[Learning outcomes and connection]
|
v
[19.1 A short history]
|
v
[19.2 Lifecycle models]
|
v
[19.3 Assumptions behind the models]
|
v
[19.4 Resilience]
|
v
[19.5 Coordination theory]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes and connection
You will be able to (1) describe how incident response developed as a discipline; (2) compare lifecycle models and their assumptions; (3) explain resilience as distinct from response; and (4) evaluate where a model fits or fails for a specific organization. This chapter opens the discipline-specific half of the book; it builds on all the foundations so far and prepares the comparative cases of Chapter 20.
19.1 A short history
Organized incident response is usually dated to the Morris worm of November 1988, after which DARPA funded the Computer Emergency Response Team Coordination Center (CERT/CC) at Carnegie Mellon University. Many national and organizational CSIRTs followed, and FIRST (Forum of Incident Response and Security Teams) was formed in 1990 to connect them. Early guidance treated incidents as technical events handled by specialists. Over time the scope widened: legal, privacy, communications, business continuity and supply chains became part of response.
For a student, the history explains why practice still varies so much between teams.
19.2 Lifecycle models
NIST SP 800-61 Revision 2 (2012) described a four-phase lifecycle: preparation; detection and analysis; containment, eradication and recovery; post-incident activity. It became widely taught. SP 800-61 Revision 3 (April 2025) replaced this framing with recommendations organized around the NIST Cybersecurity Framework 2.0 functions, emphasizing that incident response is part of overall cybersecurity risk management — Govern, Identify and Protect activities prepare for incidents; Detect, Respond and Recover handle them; and lessons feed back into all. ISO/IEC 27035 provides an international series on incident management with a similar plan-detect-assess-respond-learn structure. The FIRST CSIRT Services Framework describes the services a team may provide rather than a sequence of phases.
19.3 Assumptions behind the models
Lifecycle models assume, often implicitly: that an incident is a bounded event with a start and end; that a team has authority to act; that evidence is available; and that phases proceed roughly in order. In practice, phases overlap (containment begins before analysis ends), incidents merge and split, authority is shared with system owners and providers, and evidence is incomplete. A model is a teaching and coordination tool, not a description of reality.
Harbourline shows the gap: containment of the vendor-hosted booking platform is not an action its own team can take, yet a phase model draws it as one.
19.4 Resilience
Resilience shifts the question from "how do we handle the incident?" to "how does the organization keep delivering essential functions despite incidents?". It emphasizes anticipation, withstanding, recovery and adaptation (terms used in NIST's cyber-resiliency engineering guidance, SP 800-160 Vol. 2). A resilient organization may tolerate an unsolved incident for a while because it can operate in a degraded mode; a response-focused organization may solve the incident quickly yet suffer an outage because nothing was designed to degrade gracefully.
For Harbourline, a resilience question would be whether clinics can keep booking patients on paper while the platform is down.
19.5 Coordination theory
Response is a coordination problem among people with different information and authority. Ideas from emergency management — notably the Incident Command System's roles of command, operations, planning, logistics and finance — have been adapted to cyber incidents. They work best when roles are clear and rehearsed; they struggle when the "incident" is ambiguous for days.
For a small organization like Harbourline, with a two-person IT team, the command roles cannot each have a dedicated person; one individual may hold several. What still matters is that everyone knows who decides, who acts and who talks to the vendor and the managed detection service, and that someone takes over when the decider is unavailable.
19.6 Worked example (synthetic): fitting models to Harbourline
Fictional organization. Harbourline has six clinics, a two-person IT team, an outsourced managed detection service and a cloud-hosted booking platform run by a vendor.
Rev. 2 four-phase model: easy to teach; but "containment" of the booking platform is the vendor's action, not Harbourline's, so the model hides the contract and communication dependency.
Rev. 3 / CSF 2.0 framing: puts Govern first — roles, responsibilities, supplier agreements — which fits Harbourline's real dependency on the vendor and the detection service; it is broader and harder for a small team to operationalize without templates.
Resilience framing: asks whether clinics can book appointments on paper for a day; for a healthcare provider this may matter more than how fast the IT team analyses logs.
Where each may fail: the phase model fails at the vendor boundary; the CSF framing can become a compliance checklist without operational detail; the resilience framing can neglect investigation and legal duties.
19.7 Common errors and limits
- Treating a lifecycle as a strict sequence.
- Citing Rev. 2 phases as current NIST guidance.
- Equating resilience with backups.
-
Historical claims require sources; this chapter's history is brief and should be checked against CERT/CC and FIRST accounts.
-
Applying a model designed for a large team unchanged to a small organization like Harbourline, where one person may hold several roles.
- Ignoring suppliers in the model, when much of the containment may rest with a vendor.
- Treating resilience and response as competitors rather than complementary questions.
Exercises — chapter 19
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.
EX055 — Model comparison table. Steps: compare SP 800-61 Rev. 2, Rev. 3 and a resilience framing on scope, unit of analysis, strengths and blind spots. Rubric: 3 = accurate, sourced, blind spots specific; 2 = one inaccuracy; 1 = superficial; 0 = none.
EX056 — Assumption failure. Steps: describe a synthetic incident in which "incidents have a clear start and end" fails, and explain the consequences for metrics. Rubric: 3 = example such as a slow credential-abuse campaign discovered months later; explains that "time to detect" depends on an unknown start and cases may merge; 2 = example without metric consequence; 1 = vague; 0 = none.
EX057 — Vendor boundary. Steps: for Harbourline, list three governance items that must exist before an incident on the vendor platform. Rubric: 3 = contractual notification duty and timeline, log access rights, named contacts and escalation path, joint exercise; 2 = two; 1 = one; 0 = none.
Chapter synthesis
Models are coordination tools with assumptions. Know their history, use the current framing (CSF 2.0-aligned Rev. 3), treat resilience as continuity of essential functions, and look hardest where your organization's reality — suppliers, overlap, ambiguity — breaks the model.