Chapter 14: Incident Response

Contents

Chapter 14: Incident Response#

“Every breach is a failure of the system to detect and respond before significant damage occurs.”

Learning Objectives#

After completing this chapter, you will be able to:

  1. Define a security incident and distinguish it from a security event.

  2. Describe the four phases of the NIST SP 800-61 incident response lifecycle, and how Rev. 3 reframes them around the six CSF 2.0 functions.

  3. Explain the roles and responsibilities of a Computer Security Incident Response Team (CSIRT).

  4. Perform initial triage and prioritize an incident based on severity and scope.

  5. Describe containment strategies and explain short-term versus long-term containment.

  6. Explain eradication, recovery, and the criteria for returning systems to production.

  7. Write a post-incident report and conduct a lessons-learned review.

  8. Describe legal and regulatory notification obligations following a breach.

Key Terms#

  • Security event: any observable occurrence on a network or system.

  • Security incident: an event that actually or potentially jeopardises confidentiality, integrity, or availability.

  • CSIRT: Computer Security Incident Response Team.

  • NIST SP 800-61: NIST guide to computer security incident handling.

  • Triage: the rapid assessment of an incident to determine severity and prioritize response.

  • Containment: actions that limit the spread and impact of an active incident.

  • Eradication: removal of the threat from the environment.

  • Recovery: restoration of affected systems to normal operation.

  • MTTD: Mean Time to Detect; average time from intrusion to detection.

  • MTTR: Mean Time to Respond; average time from detection to containment.

  • IOC: Indicator of Compromise; artefact indicating a system has been compromised.

  • Playbook: a documented, step-by-step response procedure for a specific incident type.

14.1 Incidents Versus Events#

Every firewall log entry, every failed login, and every antivirus alert is a security event. The vast majority of events are benign. An incident is a subset: an event or series of events that represents an actual or probable breach of policy or security. The first analytical task in incident response is determining whether an event rises to the level of an incident.

Incident Severity Classification#

Severity

Definition

Example

Response SLA

Critical (P1)

Active breach with data exfiltration or operational impact

Ransomware encrypting production servers

Immediate; 24/7 response

High (P2)

Confirmed breach contained; significant data at risk

Compromised admin account; no exfiltration confirmed

Same-day

Medium (P3)

Suspected breach; investigation required

Anomalous data transfer; no confirmed breach

24-48 hours

Low (P4)

Policy violation or minor anomaly

Failed login spike; malware on isolated workstation

Standard business hours

14.2 The NIST SP 800-61 Lifecycle#

The NIST incident response lifecycle [NationalIoSaTechnology12] defines four phases that overlap and iterate.

Preparation#

Preparation is the work done before an incident occurs. It includes: establishing and staffing a CSIRT, developing playbooks for the most likely incident types, deploying the detection tools that will generate alerts, training analysts on triage and response, and establishing legal and communications contacts. An organization that only begins thinking about incident response when an incident occurs will respond slowly and ineffectively.

CSIRT Roles#

A mature CSIRT includes:

  • Incident commander: overall coordination and stakeholder communication.

  • Lead analyst: technical investigation and evidence collection.

  • Threat intelligence analyst: context on the adversary and their TTPs.

  • Legal counsel: breach notification obligations and law enforcement liaison.

  • Communications: internal and external messaging.

  • IT operations: containment and recovery execution.

Detection and Analysis#

Detection identifies that an incident may have occurred. Sources include: SIEM alerts, EDR notifications, threat intelligence feeds, reports from users, and third-party notification (a vendor, law enforcement, or the public reporting a vulnerability). Analysis determines whether the event is a true positive and, if so, its scope and severity.

Initial Triage Questions#

  • What systems are affected and what data do they hold?

  • Is the threat still active, or is the incident historical?

  • What is the probable entry point?

  • What is the blast radius (how many systems could be affected)?

  • Are there regulatory notification obligations?

Using IOCs#

Indicators of Compromise are technical artefacts associated with a known threat: IP addresses of C2 servers, file hashes of malware, domain names used in campaigns, and registry keys created by specific malware families. IOCs allow rapid identification of additional affected systems (scan all endpoints for the known malware hash) and enable blocking at network and endpoint level.

Containment#

Containment stops the bleeding: it limits spread and impact while evidence is preserved.

Short-Term Containment#

Short-term containment is immediate and may be imperfect. Examples: isolating a compromised host from the network (remove from VLAN, block at switch), disabling a compromised account, applying an emergency firewall rule to block outbound traffic to the attacker’s C2 IP. Short-term containment prioritizes stopping spread over preserving full system functionality.

Long-Term Containment#

Long-term containment replaces short-term measures with more sustainable ones: patching the vulnerability that enabled the breach, replacing compromised credentials, deploying network segmentation that prevents the threat from spreading. Long-term containment may run in parallel with eradication and recovery.

Eradication#

Eradication removes the threat from every affected system: deleting malware, removing attacker- created accounts, revoking stolen credentials (and rotating all credentials that may have been observed), removing persistence mechanisms (scheduled tasks, registry run keys, cron jobs, WMI subscriptions), and rebuilding systems where the threat cannot be fully removed.

Rebuild Versus Clean#

Rebuilding a compromised system from a known-good image is the gold standard: it eliminates the possibility of persistent backdoors that evaded detection. Cleaning (removing the known malware and persistence mechanisms from a live system) is faster but relies on the accuracy of the investigation. For critical systems that may have been compromised at a deep level (kernel rootkit, firmware), rebuild is the only defensible approach.

Recovery#

Recovery returns affected systems to normal operation. It includes: restoring from clean backups, verifying system integrity, enhanced monitoring to confirm the threat is gone, and gradual service restoration with monitoring at each step.

Recovery Validation#

Before declaring recovery complete, the response team must verify that: all known malware and persistence mechanisms are removed, the initial access vector is closed (patched or mitigated), monitoring is in place to detect recurrence, and affected data has been audited for integrity. Many incidents have recurred because recovery was declared prematurely.

Post-Incident Activity#

The post-incident phase produces two outputs: a final incident report and a lessons-learned review.

Post-Incident Report Structure#

  1. Executive summary (business impact, timeline, actions taken).

  2. Incident timeline (hour-by-hour narrative from first indicator to closure).

  3. Root cause analysis.

  4. Affected systems and data.

  5. Actions taken (containment, eradication, recovery steps).

  6. Recommendations (changes to prevent recurrence).

  7. Regulatory and legal actions taken.

Lessons Learned#

The lessons-learned review asks: What went well? What went poorly? What would we do differently? It is blameless: the goal is process improvement, not attribution of fault. Findings feed back into the Preparation phase: updated playbooks, additional detection rules, staff training gaps.

NIST SP 800-61 Rev. 3 and the CSF 2.0 Framing#

The lifecycle described above is the long-standing model from NIST SP 800-61 Revision 2 (Preparation; Detection and Analysis; Containment, Eradication, and Recovery; Post-Incident Activity). In April 2025, NIST SP 800-61 Revision 3 superseded it and reframed incident response around the six functions of the Cybersecurity Framework 2.0 (Chapter 19): Govern, Identify, Protect, Detect, Respond, and Recover. Rather than a rigid linear lifecycle, Rev. 3 treats incident response as continuous risk management: Govern, Identify, and Protect build the readiness that prevents and limits incidents, while Detect, Respond, and Recover handle those that occur, with lessons feeding back into governance. The classic phases still describe the handling of an incident well, so this chapter teaches both: the operational phases as a playbook, and the CSF 2.0 framing as the strategic context that ties incident response to the organization’s overall risk posture.

14.4 The Assume-Breach Mindset#

Before walking through a formal lifecycle, it helps to adopt the mindset experienced responders bring to the work: attacks are inevitable. As the saying goes, there are two kinds of organizations, those that have been compromised and those that will be, and the exposure extends to every internet connection, home network, and cell phone. The distinction between a threat and an actual compromise often comes down to discipline: an organization becomes a victim when patching is incomplete, defense-in-depth is missing, security management is poor, or people simply are not on guard. A determined attacker who truly wants in will, in some way, get in, and because most attacks begin with social engineering (Chapter 4), diligence and awareness matter as much as technology. Planning therefore assumes breach rather than hoping to prevent every one.

14.5 Before, During, and After: An Operational IR Playbook#

Incident response is best understood across three phases, which expand the formal lifecycle into the practical actions a team actually takes. The framing comes from a practitioner’s account of defending a 12,000-student university against ransomware.

Before the attack is about preparation. Build an incident response plan; the SANS lifecycle lists Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned, with the overriding goal of minimizing damage. Identify your mission-critical systems and the support services they depend on (network firewalls, switches, routing, data-center links, power), define roles so everyone knows who is in charge and who does what, document how systems are configured and where information lives, designate who owns communication and who must be notified, and plan logistics that teams forget under pressure: who sleeps and when, who fetches food, and who carries a company credit card.

During the attack, process beats panic. The single worst response is to panic, because a level head avoids the mistakes that come from rushing. Execute the plan you built, communicate continuously (a communication plan, real-time events, and changes being made), and remember that tools are not as important as process. A crucial, counterintuitive rule: do not shut systems off. Some attacks run from internal systems, malware can live only in memory, and valuable volatile evidence must be collected while the system is live, so a team member should be assigned to monitoring and reporting. Document everything as it happens; each member records their own actions, and preserving every bit of data aids both recovery and the later lessons-learned review.

After the attack is where organizations improve or repeat their mistakes. While memory is fresh, hold a meeting to fill gaps in everyone’s understanding and assign action items, then collect the documentation and organize it into a timeline. Produce a lessons-learned document covering what happened, what worked, what did not, how to plan for the future, and which security controls to add. Above all, do the work: it is easy to fix problems in the moment and hard to fix them continuously, so repair damage, address newly identified threats, patch newly found vulnerabilities, and reassess risk.

        flowchart LR
    P[Preparation] --> I[Identification]
    I --> C[Containment]
    C --> E[Eradication]
    E --> R[Recovery]
    R --> L[Lessons Learned]
    L -.feeds back.-> P

14.6 Case Study: The Locky Ransomware Incident#

These phases are not abstractions; they map onto a real incident. On a Monday morning in the middle of the semester, with nearly everyone reading weekend email, it took one person with permissions to open a malicious attachment and trigger the Locky ransomware, a strain that encrypts files and demands payment.

Walking the incident through the playbook: the team’s during-the-attack steps were, first, to examine logs (network, server, and access logs) to locate the problem; second, to mitigate damage by switching the affected server’s file system to read-only, preventing further encryption writes; third, to find the infected system and cut it off the network; and fourth, to prepare to recover. After the attack, the sequence was document, restore (from backups), educate (so users recognize the next phishing lure), and communicate. The responders candidly note they were partly lucky and had skipped some steps they would later formalize, which is precisely why the lessons-learned discipline exists. The case reinforces every theme of this chapter: breaches start with people, process beats panic, volatile evidence must be preserved, and recovery depends on backups prepared long before the attack.

Knowledge Check

  1. Name the six phases of the SANS incident response lifecycle.

  2. During an active incident, why should responders generally avoid shutting systems off?

  3. In the Locky case, what single action stopped further file encryption on the affected server?

Answers: (1) Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. (2) Some malware lives only in memory and attacks may originate internally, so powering off destroys volatile evidence needed for analysis and recovery; collect live data first. (3) Switching the server’s file system to read-only, which prevented further encryption writes.

14.7 The CSIRT, Roles, and Communication#

Incidents are handled by people, so preparation begins with a Computer Security Incident Response Team (CSIRT): a standing, cross-functional team with clearly assigned roles, an incident commander who runs the response, technical responders, and crucially non-technical members from legal, communications/PR, human resources, and executive leadership. A RACI chart (who is Responsible, Accountable, Consulted, Informed) prevents the confusion that paralyzes an unrehearsed team. Communication is the hardest part of a real incident: a plan must predefine who speaks to whom, internal stakeholders, customers, regulators, law enforcement, and the public, and through what channels (ideally out-of-band, since the attacker may be reading corporate email). Legal and regulatory notification clocks (GDPR’s 72 hours, U.S. state breach laws, sector rules, Chapters 18-19) start during the incident, so counsel must be engaged early. Deciding when to involve law enforcement (and how that interacts with evidence handling, Chapter 13) is itself a planned decision, not an improvised one.

14.8 Triage, Severity, Containment, and Recovery in Depth#

When an alert arrives (from the detection stack of Chapter 12), responders triage: confirm it is a true incident, scope it, and assign a severity that drives the response. A simple severity matrix combines impact (data sensitivity, systems affected, business disruption) with urgency to yield levels from SEV-5 (minor) to SEV-1 (critical, all-hands), each with defined response times and escalation paths.

Containment then comes in two stages: short-term containment stops the bleeding fast (isolate a host, block a C2 domain, disable an account) while preserving evidence, and long-term containment applies durable fixes that let business continue while eradication proceeds. Eradication removes the root cause, malware, backdoors, and the attacker’s persistence (Chapter 9), often requiring reimaging rather than cleaning, and resetting all potentially compromised credentials. Recovery restores systems from known-good backups, validates they are clean, monitors closely for the attacker’s return, and only then declares normal operations. A critical, recurring mistake is eradicating too early, before the full scope is known, which tips off the attacker and leaves footholds; mature teams scope completely, then evict everywhere at once.

Knowledge Check

  1. Why must a CSIRT include non-technical members and use out-of-band communication?

  2. Distinguish short-term from long-term containment.

  3. Why is evicting an attacker too early a mistake?

Answers: (1) Incidents have legal, regulatory, HR, PR, and executive dimensions, and the attacker may be monitoring corporate channels, so out-of-band communication keeps response coordination private. (2) Short-term containment quickly stops active harm while preserving evidence (isolate/block/disable); long-term containment applies durable fixes so the business can operate while eradication proceeds. (3) Eradicating before the scope is fully understood tips off the attacker and leaves undiscovered footholds, so they return; teams should scope fully, then evict everywhere simultaneously.

14.9 Postmortem, Metrics, and Exercises#

The phase organizations most often skip is the one that creates lasting value: the post-incident review, or blameless postmortem. Conducted while memory is fresh, it produces a factual timeline and a root-cause analysis (asking “why” repeatedly to reach systemic causes, not individual blame), and a lessons-learned document with concrete, owned, deadlined action items, what happened, what worked, what did not, and which controls to add. “Blameless” is essential: if people fear punishment, they hide information and the organization learns nothing. Programs track metrics to improve over time, chiefly mean time to detect (MTTD) and mean time to respond/recover (MTTR) (Chapter 12), plus dwell time and incident counts by type.

Finally, readiness is built before the incident through playbooks (step-by-step runbooks for common incident types such as ransomware or business-email compromise, Appendix H) and tabletop exercises, where the team walks through a realistic scenario to find gaps in the plan, roles, and communication while the stakes are only hypothetical. As the operational playbook earlier in this chapter showed with the Locky case, the teams that handle real incidents well are the ones that practiced, documented, and learned, turning each incident into improved resilience (Chapter 17) rather than a repeated disaster.

14.10 Playbooks, Ransomware Negotiation, and Executive Communication#

The lifecycle above describes how response works in general. Mature teams encode that lifecycle into playbooks: step-by-step procedures for specific incident types such as business email compromise, ransomware, data exfiltration, or a lost device. A good playbook names the decisions that must be made, who is authorized to make them, and what must be communicated, so responders are not improvising governance during a crisis. Playbooks are written and rehearsed in advance through tabletop exercises and kept current as the environment changes.

Ransomware raises decisions that go beyond technical recovery. Whether to engage with attackers is a business and legal decision, not a technical one, and many organizations rely on specialized negotiators and legal counsel; paying may be constrained or prohibited by sanctions regulations if the group is on a restricted list, and payment never guarantees clean or complete recovery. The technical priority remains restoring from known-good, offline backups, which is why their integrity is tested before they are needed. Executive and board communication is its own workstream. Leaders need clear, accurate, and timely updates framed around business impact, the decisions required, and likely timelines rather than packet-level detail, and the organization must coordinate disclosure to regulators, customers, and possibly the public within the deadlines covered earlier in this chapter. Preparing communication templates and a decision-rights chart before an incident keeps these messages consistent and prevents conflicting statements under pressure.

14.11 A Ransomware Incident, Hour by Hour#

Abstract lifecycles become real under time pressure. The following composite walks a mid-size organization through a modern human-operated ransomware incident, mapped to the NIST SP 800-61 phases (Section 14.2) and the containment decisions of Section 14.8. Timings reflect what a prepared team can achieve; an unprepared one measures the same milestones in days.

        flowchart TB
    D[Detection: EDR alert on suspicious encryption] --> T[Triage and scope]
    T --> C{Contain}
    C -->|isolate hosts| I[Network isolation, disable accounts]
    C -->|preserve| P[Capture memory and disk images]
    I --> E[Eradicate: remove persistence, reset credentials]
    P --> E
    E --> R[Recover from clean, offline backups]
    R --> L[Lessons learned and hardening]

Hour 0 (Detection). The EDR platform (Section 12.6) flags a host rapidly renaming files with a new extension and deleting volume shadow copies (vssadmin delete shadows), a near-certain ransomware signature. An alert fires to the on-call analyst, who declares an incident and opens a ticket that will become the single source of truth.

Hour 0 to 1 (Triage and scope). The team answers three questions: what is affected, how did it start, and is it still spreading. EDR process trees show the malware arrived through a compromised VPN account (no MFA) three days earlier, then used the Active Directory attack paths of Chapter 9 to reach a domain controller. Scope is not one host; it is the domain.

Hour 1 to 3 (Containment). This is the decisive phase. The team isolates affected hosts at the network layer (EDR network-contain, switch-port disable, or blocking rules) rather than powering them off, which would destroy the memory evidence of Section 13.13. Simultaneously it disables the compromised accounts, rotates the krbtgt password twice to invalidate forged Kerberos tickets (Chapter 9), and blocks the command-and-control domains at the DNS and firewall layers. Before wiping anything, it captures memory and disk images of representative hosts for the forensic timeline of Section 13.14 and for any later law-enforcement or insurance requirement.

Hour 3 to 12 (Eradication). With spread halted, the team removes persistence mechanisms (scheduled tasks, services, run keys), resets all potentially exposed credentials, and patches the initial-access vulnerability, here by enforcing MFA on the VPN. Rebuilding from a known-good image (Section 11.18) is preferred over cleaning in place, because trust in a compromised host cannot be fully restored.

Hour 12 onward (Recovery). Systems are restored from tested, offline, immutable backups, brought back in priority order, and watched closely for reinfection. Only when monitoring is clean is the incident closed.

After (Lessons learned). Within two weeks the team writes a blameless postmortem (Section 14.9): the root cause was a VPN account without MFA, the biggest delay was locating clean backups, and the fixes are enforced MFA, tested offline backups, and tiered administration. The decision whether to pay is covered in Section 14.10 and remains a business and legal matter, not a technical one.

14.12 Writing and Running Playbooks#

A playbook turns the general lifecycle into a specific, repeatable procedure for one incident type, so that responders execute rather than improvise. A good playbook states the trigger, the roles, the ordered steps with decision points, the evidence to preserve, and the communications required. Below is a compact business-email-compromise (BEC) playbook in the form most teams keep it.

# A playbook expressed as executable pseudocode (a SOAR-style automation skeleton).
# In production this drives real API calls; here it prints the ordered response so the
# logic is auditable and testable.
def bec_playbook(alert):
    steps = []
    # 1. Triage
    steps.append(f"TRIAGE: suspicious login for {alert['user']} from {alert['geo']} / {alert['ip']}")
    risky = alert["impossible_travel"] or alert["new_country"] or alert["mfa_fatigue"]
    if not risky:
        steps.append("CLOSE: benign, no risk indicators"); return steps
    # 2. Contain (fast, reversible actions first)
    steps.append("CONTAIN: revoke active sessions and OAuth tokens")
    steps.append("CONTAIN: force password reset + re-enroll MFA")
    steps.append("CONTAIN: disable mailbox inbox rules (auto-forward is the BEC tell)")
    # 3. Investigate
    steps.append("INVESTIGATE: pull sign-in logs, mailbox audit, sent items, rule history")
    if alert["auto_forward_rule"]:
        steps.append("SCOPE UP: exfiltration likely; check for wire-fraud emails to finance")
    # 4. Eradicate + Recover
    steps.append("ERADICATE: remove malicious rules, revoke app consents")
    steps.append("RECOVER: restore normal access; monitor account for 14 days")
    # 5. Notify
    steps.append("NOTIFY: finance (fraud watch), legal (breach assessment), affected users")
    return steps

alert = {"user":"cfo@example.com","geo":"far away","ip":"203.0.113.9",
         "impossible_travel":True,"new_country":True,"mfa_fatigue":False,
         "auto_forward_rule":True}
for n, s in enumerate(bec_playbook(alert), 1):
    print(f"{n:2}. {s}")

14.13 Evidence Handling and Communication Templates#

Under pressure, teams forget the two things that later determine whether an incident is survivable: preserving evidence properly and communicating clearly. Both are solved in advance with templates.

Evidence handling. Every item collected gets a chain-of-custody record (Section 13.1): what it is, who collected it, when, from where, its hash, and every subsequent handoff. Images are write-protected and stored with their hashes. A single misstep, an analyst working on the original disk or an unlogged transfer, can make the evidence inadmissible and undermine an insurance claim.

Communication. Incidents are lost as often to bad communication as to bad forensics. Prepare templates so messages are consistent and fast:

  • Internal status update (every N hours to leadership): what we know, what we are doing, what we need, next update time. Framed in business impact, not packet detail (Section 14.10).

  • Regulator or customer notification: what happened, what data is involved, what the recipient should do, who to contact, on the clock set by the laws of Section 14.3 (for example the GDPR’s 72-hour window).

  • Holding statement: a short, accurate public line prepared before it is needed, so the organization is not silent while a story forms.

A pre-agreed decision-rights chart (who can isolate production, who can approve external notification, who speaks to press) prevents the paralysis that follows when nobody is sure who may act.

14.14 Tabletop Exercises and Purple Teaming#

Plans that are never rehearsed fail on contact. Two exercise types build readiness. A tabletop exercise is a discussion-based walk-through in which the team talks through its response to an injected scenario (“an employee reports encrypted files and a ransom note”), surfacing gaps in roles, tools, and authority at low cost. A purple-team exercise is hands-on: the red team executes specific ATT&CK techniques (Chapter 12) while the blue team confirms whether each is detected and how fast, turning the abstract question “are we covered?” into a measured detection-and-response scorecard. Both feed the metrics of Section 14.9, principally mean time to detect and mean time to respond, which are the numbers that actually track whether a security program is improving.

Exercises#

  1. During containment, why is network isolation usually preferred over powering a ransomware-infected host off?

  2. A domain controller was compromised. Why must the krbtgt password be reset twice, and what attack does this defeat?

  3. Which single control, had it been present, would most likely have prevented the Section 14.11 incident, and at which lifecycle phase does it act?

  4. Write the first four ordered steps your playbook takes when a finance user reports a suspected business-email-compromise login.

  5. Name the mandatory fields of a chain-of-custody record and explain what goes wrong if the hash is omitted.

  6. Distinguish a tabletop from a purple-team exercise, and name the metric each is best suited to improve.

Answer Key#

  1. Powering off destroys volatile memory evidence (running processes, injected code, keys, network state, Section 13.13); network isolation halts spread while preserving that evidence.

  2. Kerberos golden tickets are forged with the krbtgt key; a single reset leaves the previous key valid for one cycle, so two resets fully invalidate any forged tickets (Chapter 9).

  3. Enforced MFA on the VPN account; it acts at Protect, preventing the initial access that the entire chain depended on.

  4. Revoke active sessions and tokens; force password reset and MFA re-enrollment; disable any mailbox auto-forward or inbox rules; pull sign-in and mailbox-audit logs to scope exfiltration.

  5. Item description, collector identity, date and time, source location, cryptographic hash, and every handoff; without the hash there is no proof the evidence was not altered, so its integrity cannot be defended.

  6. A tabletop is a discussion-based walk-through that improves mean time to respond by exposing process and authority gaps; a purple-team exercise is hands-on and improves mean time to detect by measuring real detection coverage.

14.15 Threat Intelligence and Attribution in Response#

Responders work faster when they know who they are likely facing. Cyber threat intelligence (CTI) turns raw indicators into context: a hash or domain seen during an incident is matched against intelligence feeds to reveal the malware family, the likely threat actor, and that actor’s known tactics, so the team can anticipate the next move rather than react to it. Intelligence is organized on the pyramid of pain (Section 15.12): blocking an attacker’s hashes and IP addresses is easy for them to evade, while detecting their tactics, techniques, and procedures (mapped with MITRE ATT&CK, Chapter 12) forces costly changes on them, so mature teams pivot from indicator matching to behavior detection during an incident.

Attribution, naming the responsible actor, is valuable but perilous. Technical evidence (malware code overlap, infrastructure reuse, language artifacts, and operating hours) supports a hypothesis, but sophisticated adversaries deliberately plant false flags, so responders distinguish clusters of activity (tracked under neutral names such as UNC or TA numbers) from confident nation-state attribution, which is a governmental and diplomatic judgment, not a SOC one. Within an incident, the practical use of attribution is not blame but prediction: knowing an actor’s habitual persistence, exfiltration, and extortion methods tells the team where to look next.

14.16 Cloud and SaaS Incident Response#

Response changes when the environment is someone else’s infrastructure. Under the shared-responsibility model (Chapter 17), the provider secures the platform while the customer secures its configuration, identities, and data, and incident response follows that line: the customer investigates account compromise, misconfiguration, and data exposure using the provider’s audit logs (Section 13.11), while the provider handles the underlying platform. Three differences reshape the playbook. First, identity is the new perimeter: most cloud incidents begin with a stolen credential or over-permissive role, so containment means revoking sessions and keys and tightening IAM policies rather than pulling a network cable. Second, ephemerality means evidence can vanish when an auto-scaling group replaces an instance, so snapshots must be taken immediately and logging must be configured in advance. Third, the blast radius is an API call away: a single leaked key can touch every resource it is authorized for, so scoping asks what that identity could reach, not what host it sat on. Containment actions such as isolating an instance’s security group, revoking a role, or rotating a key are fast and programmable, which is both the advantage and the risk of cloud response.

14.17 A Second Scenario: A Data-Breach Investigation#

Not every incident is ransomware. Consider the quieter and, for many organizations, costlier case of data exfiltration.

Discovery. The organization learns of the breach not from an alarm but from a third party, a common and humbling pattern: a security researcher, a customer, or law enforcement reports that company data is for sale. The clock on the disclosure obligations of Section 14.3 starts now.

Scoping the data. The central question is not “which host” but “what data, whose, and how much.” The team works backward from the leaked sample to identify the source system, then uses database and file-access logs and the DLP records of Section 11.15 to determine the full set of records exposed, because notification law turns on exactly which categories of personal data left the organization.

Root cause. Investigation typically finds one of a small set of causes: an exposed storage bucket or database (Section 10.13), a compromised credential with excessive access, a web-application flaw (Chapter 10), or an insider. The forensic timeline (Section 13.14) establishes when access began and how long it persisted (the dwell time of this chapter’s News in Focus).

Notification and remediation. Legal and communications lead the external response (Section 14.13), notifying regulators and affected individuals within statutory deadlines, while engineering closes the hole, rotates exposed credentials and keys, and adds the monitoring that would have caught it. The postmortem’s hardest finding is often that the data should not have been retained or accessible at all, which points back to the data-minimization principle of Chapter 18.

14.18 Metrics and Continuous Improvement#

A response program is judged by numbers, and the same numbers drive its improvement. The core metrics are mean time to detect (MTTD), mean time to respond or contain (MTTR), and dwell time, the interval from initial compromise to detection, which the industry has driven down from months to days but which still spans the gap most attackers exploit. Around these sit the rate of incidents by type, the false-positive rate of detections (Section 12.8), and the percentage of ATT&CK techniques with detection coverage. The purpose of measuring is to close the loop: every incident feeds the blameless postmortem (Section 14.9), every postmortem produces concrete detection and hardening changes, and the next exercise (Section 14.14) tests whether those changes work. A program that cannot state its MTTD and MTTR, and show them trending down, is not managing incident response; it is merely experiencing incidents.

Exercises#

  1. During an incident you match a dropped file’s hash to a known malware family. Explain, using the pyramid of pain, why you should not stop at blocking that hash.

  2. Give two reasons cloud incident response cannot rely on the same containment actions as on-premises response, and state the cloud equivalent of each.

  3. In the data-breach scenario, why is “what data and whose” a more urgent question than “which host,” and what legal fact turns on the answer?

  4. Define dwell time and explain why it is the metric attackers care about most.

  5. Your MTTD is 30 days and falling, but your false-positive rate is rising. Explain how these two metrics can pull against each other and how detection tuning resolves it.

Answer Key#

  1. Hashes are at the base of the pyramid and are trivial for the attacker to change; detecting the actor’s tactics and techniques (ATT&CK) is far more costly for them to evade, so response should pivot to behavior.

  2. Evidence is ephemeral (instances are replaced), so snapshot immediately and pre-configure logging; and identity is the perimeter, so contain by revoking sessions, keys, and roles rather than isolating a host.

  3. Notification law is triggered by which categories of personal data left the organization and whom they concern, not by which machine was touched, and the disclosure deadline runs from discovery.

  4. Dwell time is the interval from initial compromise to detection; the longer it is, the more the attacker can steal, spread, and entrench, so minimizing it directly limits damage.

  5. Detecting faster can mean firing more, noisier alerts, raising false positives and analyst fatigue; tuning adds context and prioritization so detections stay sensitive without burying real alerts.

14.19 Incident Response for Operational Technology#

Responding in an industrial environment inverts a core assumption of IT incident response. In OT and industrial control systems (Chapter 20), safety and availability outrank confidentiality, because the systems control physical processes where an outage or an unsafe state can injure people or damage equipment. A containment action that is routine in IT, isolating a host or forcing a reboot, can trip a safety system or halt a process that must run continuously, so OT response is planned jointly with plant engineers and safety personnel, and the first question is not “how do we remove the attacker” but “how do we keep the process safe.” The practical differences are that many OT devices cannot run endpoint agents and cannot be patched on demand (Chapter 20), so detection leans on network monitoring of the industrial protocols in Appendix I, and containment favors network segmentation and manual, engineered fallbacks over aggressive isolation. The attacks on water-treatment and grid systems in Chapter 20’s News in Focus are why this specialization exists: the incident is not just a data problem, it is a physical-safety problem.

14.20 Insider and Account-Compromise Incidents#

Not every adversary is external, and the response differs when the actor is, or appears to be, a trusted user. An insider incident may be malicious (an employee exfiltrating data before leaving, the insider risk of Chapter 5) or accidental (a misconfiguration or a lost device), and it is delicate because it involves a real person with employment and privacy rights, so human resources and legal are core responders from the first minute, and evidence must be handled to a standard that supports possible disciplinary or legal action (Section 13.19). Account compromise, where an external attacker operates through a legitimate user’s credentials, looks like insider activity in the logs, which is exactly why it is dangerous: the actions are authorized. Distinguishing the two relies on the behavioral analytics of Section 12.4, impossible travel, a sudden change in access patterns, activity at unusual hours, and the containment for both is the same identity-centric response of Section 14.16: revoke sessions and credentials, then investigate what the identity touched. The recurring lesson is that “authorized” is not “legitimate,” and that the hardest intrusions to detect are the ones that never break a rule because they wear a valid badge.

14.21 Building the Response Program#

Incident response is a capability an organization builds before it needs it. At its center is the computer security incident response team (CSIRT) of Section 14.7, with defined roles (incident commander, technical lead, communications lead, legal and executive liaisons) and the decision-rights chart of Section 14.13, so authority is clear under pressure. Because most organizations cannot staff deep forensic and malware expertise in-house, many hold an incident-response retainer with a specialist firm, pre-negotiated so help arrives in hours rather than after days of contracting, exactly when speed matters most. Readiness is completed by the supporting pieces this chapter has developed: written and rehearsed playbooks (Section 14.12), tested offline backups (Section 14.11), pre-drafted communications (Section 14.13), tabletop and purple-team exercises (Section 14.14), and the metrics (Section 14.18) that show the program improving. The measure of a mature program is not that it never has incidents, which is impossible, but that when one occurs the team executes a rehearsed plan instead of improvising, and that it detects and contains in hours what an unprepared organization discovers in months. The severity-scoring lab below shows the kind of pre-agreed rubric that turns a chaotic “how bad is this?” into a consistent triage decision.

# A pre-agreed incident severity rubric: score by data sensitivity, scope, and
# business impact, then map to a severity tier and response SLA. Consistent triage
# under pressure comes from deciding the rubric in advance, not during the incident.
def score_incident(inc):
    s = 0
    s += {"none":0, "internal":1, "pii":3, "regulated":4}[inc["data"]]     # data at risk
    s += {"one_host":0, "team":1, "department":2, "org_wide":4}[inc["scope"]]  # spread
    s += {"none":0, "degraded":2, "outage":3, "safety":5}[inc["impact"]]   # business/safety
    s += 2 if inc["active"] else 0                                          # attacker still in
    tier = ("SEV-1" if s >= 9 else "SEV-2" if s >= 6 else "SEV-3" if s >= 3 else "SEV-4")
    sla  = {"SEV-1":"15 min, exec bridge", "SEV-2":"1 hour",
            "SEV-3":"4 hours", "SEV-4":"next business day"}[tier]
    return s, tier, sla

for inc in [
    {"data":"regulated","scope":"org_wide","impact":"outage","active":True},
    {"data":"internal", "scope":"one_host","impact":"none",  "active":False},
]:
    s, tier, sla = score_incident(inc)
    print(f"score={s:2d} -> {tier}  (respond within {sla})   {inc}")

Exercises#

  1. Why does incident response in an OT environment prioritize safety and availability over confidentiality, and name one IT containment action that can be dangerous there.

  2. An attacker operating through a stolen credential produces log activity that looks authorized. What kind of analytics helps distinguish this from legitimate use, and what is the containment step?

  3. What is an incident-response retainer, and why do organizations that could technically respond themselves still keep one?

  4. Using the severity rubric, would a single-host infection of internal (non-regulated) data with no outage and no active attacker be a SEV-1? Justify with the scoring.

Answer Key#

  1. Because these systems control physical processes where downtime or an unsafe state can harm people or equipment; isolating or rebooting a controller can trip a safety system or halt a process that must run continuously.

  2. User and entity behavior analytics (impossible travel, unusual hours, changed access patterns); contain by revoking the identity’s sessions and credentials, then investigate what it accessed.

  3. A pre-negotiated contract with a specialist firm for on-demand forensic and response help; it guarantees expert assistance arrives in hours, avoiding the delay of procuring help mid-incident when speed is decisive.

  4. No: data=internal(1) + scope=one_host(0) + impact=none(0) + not active(0) = 1, which maps to SEV-4, the lowest tier.

14.22 Case Study: Business Email Compromise and Wire Fraud#

Ransomware is loud; business email compromise (BEC) is quiet and, in aggregate, costs organizations more. This composite follows a BEC incident to show how the lifecycle applies when the attacker’s goal is fraud rather than encryption.

Initial access. An accounts-payable clerk received a convincing phishing email and entered credentials on a lookalike Microsoft 365 login page. The account had no multi-factor authentication, so the attacker logged in directly, the same root cause as the ransomware case of Section 14.11, and the reason MFA is the highest-value single control.

Establishing control and reconnaissance. Rather than deploy malware, the attacker simply read the mailbox for days, learning the organization’s vendors, payment processes, and the tone of internal correspondence. This is why BEC evades malware-focused defenses entirely: there is nothing malicious on any endpoint. The one technical artifact was an inbox rule that auto-forwarded and then deleted messages containing words like “invoice” and “payment,” so the attacker saw financial threads while hiding them from the real user, the tell that the Section 14.12 playbook checks for first.

The fraud. At an opportune moment the attacker, impersonating a known vendor from a lookalike domain, sent an invoice with updated bank details and followed up in the vendor’s voice. The clerk, seeing a familiar thread, changed the payment destination and wired a large sum.

Detection and response. The behavioral analytics of Section 12.4 flagged the impossible-travel login a day late; by then the wire was sent. The team executed the identity-centric containment of Section 14.16, revoked sessions and tokens, forced a password reset with MFA enrollment, and removed the mailbox rule, then invoked the narrow window in which a wire can sometimes be recalled by immediately contacting the bank and law enforcement (in the United States, the FBI’s Internet Crime Complaint Center and its Financial Fraud Kill Chain), which recovered part of the funds.

Lessons. The postmortem’s fixes were structural rather than technical: enforce MFA, disable external auto-forwarding by policy, and require out-of-band verification (a call to a known number) for any change to payment details, the same defense-in-depth against the deepfake and voice-cloning fraud of Chapter 4. BEC is a reminder that incident response is often about money and process, not malware. The lab below encodes the single most useful BEC detection: a mailbox rule that hides financial mail.

# Detect the classic BEC inbox rule: auto-forward or auto-delete of financial mail.
# Runs over parsed mailbox-rule audit records; flags rules that hide or exfiltrate.
FINANCIAL = ("invoice", "payment", "wire", "bank", "ach", "remittance")

rules = [  # (owner, name, conditions, actions)
    ("clerk@co.com", "rule1", ["subject_contains:invoice"], ["forward_external:x@evil.com","delete"]),
    ("clerk@co.com", "rule2", ["from:newsletter@site.com"], ["move:Reading"]),
    ("cfo@co.com",   "rule3", ["body_contains:payment"],    ["mark_read","move:RSS"]),
]

def score_rule(conds, acts):
    hits = []
    fin = any(any(w in c.lower() for w in FINANCIAL) for c in conds)
    if fin and any(a.startswith("forward_external") for a in acts):
        hits.append("forwards financial mail externally (exfiltration)")
    if fin and ("delete" in acts or any(a in ("mark_read",) for a in acts)):
        hits.append("hides financial mail from the user")
    return hits

for owner, name, conds, acts in rules:
    hits = score_rule(conds, acts)
    verdict = "; ".join(hits) if hits else "benign"
    flag = "  *** BEC INDICATOR ***" if hits else ""
    print(f"{owner:14} {name}: {verdict}{flag}")

14.23 Coordinating with Law Enforcement, Insurers, and Regulators#

Major incidents are not handled by the technical team alone; three external parties shape the response, and knowing when to engage each is part of the plan (Section 14.13). Law enforcement (in the United States, the FBI and the Secret Service; elsewhere, national cybercrime units) can, in narrow windows, help recall fraudulent wires, share intelligence on the threat actor, and pursue the criminals, but involving them affects disclosure and evidence handling, so the decision is made with legal counsel. Cyber-insurance carriers are often involved from the first hours, because the policy may require using the insurer’s approved forensics and legal panel, and may cover response costs, ransom decisions, and business-interruption losses; the incident must be documented to the insurer’s evidentiary standard (Section 13.1) or a claim can be denied. Regulators must be notified within the statutory deadlines of Section 14.3 when personal or regulated data is involved, and increasingly for critical-infrastructure incidents. The unifying point is that a serious incident is a legal, financial, and reputational event as much as a technical one, which is why the CSIRT of Section 14.21 includes legal, communications, and executive roles, and why the decisions that determine whether an organization survives an incident are usually made in a conference room, not at a keyboard.

Exercises#

  1. Why does business email compromise evade malware-focused defenses, and what single artifact most reliably reveals it?

  2. A fraudulent wire has just been sent. What is the time-critical response action, and which external party enables it?

  3. Give three structural (non-malware) controls that would have prevented the case-study fraud, mapping each to the stage it blocks.

  4. Why must incident documentation meet an insurer’s evidentiary standard, and what happens if it does not?

Answer Key#

  1. It uses only legitimate credentials and email, with no malicious file on any endpoint; a mailbox rule that auto-forwards or hides financial messages is the most reliable technical indicator.

  2. Immediately contact the bank to attempt a recall and notify law enforcement (in the US, the FBI’s IC3 and its Financial Fraud Kill Chain), which can sometimes freeze the funds within a narrow window.

  3. Enforced MFA (blocks the initial account takeover), disabling external auto-forwarding by policy (blocks the concealment), and out-of-band verification of payment-detail changes (blocks the fraudulent wire itself).

  4. Because the cyber-insurance claim depends on documented evidence of what happened; inadequate documentation can cause the carrier to deny coverage, leaving the organization to absorb the loss.

14.24 Communication Templates#

Under incident pressure, wording is decided in advance so that messages are fast, accurate, and consistent (Section 14.13). Three templates cover most needs; keep them filled with placeholders and rehearsed.

Internal status update (to leadership, on a fixed cadence):

Incident [ID], update [N] at [time]. Status: [investigating / contained / recovering]. What we know: [brief, factual]. Business impact: [systems and services affected]. Actions in progress: [top three]. Decisions needed: [if any, with the decision owner]. Next update: [time].

Customer or user notification (once facts are confirmed and legal has cleared it):

We are writing to inform you of a security incident affecting [scope]. On [date] we discovered [what happened]. The information involved was [categories]. We have [actions taken]. We recommend you [specific, actionable steps]. For questions, contact [channel]. We are committed to [remediation].

Holding statement (prepared before facts are complete, to avoid silence):

We are aware of an issue affecting [service] and are investigating. We are taking it seriously and will provide updates as we learn more. The security of [customer/data] is our priority.

The principles behind all three: lead with facts and impact, not speculation; never guess at cause or scope in writing; give recipients a concrete action; commit only to what is true; and set the time of the next update so silence never fills the gap. Legal and communications own the external messages; the technical team supplies the facts.

14.25 A Ransomware Readiness Checklist#

Readiness is the difference between the hours-long response of Section 14.11 and a weeks-long catastrophe. Before an incident, an organization should be able to answer yes to each of the following, which double as an audit of the controls this book has built:

  • Multi-factor authentication is enforced on all remote access and privileged accounts (the root cause of most intrusions, Section 14.11).

  • Backups are tested, versioned, and kept offline or immutable, so ransomware cannot encrypt them (Section 14.11).

  • Endpoint detection and response is deployed and monitored, with alerts reaching an on-call responder (Section 12.6).

  • The network is segmented and administration is tiered, limiting a single compromise’s blast radius (Chapter 11).

  • Patch and vulnerability management runs on a defined cadence with exploited-vulnerability prioritization (Section 11.18).

  • Incident-response playbooks exist, are rehearsed in tabletop and purple-team exercises, and name the CSIRT roles and decision rights (Sections 14.12, 14.14, 14.21).

  • An incident-response retainer and cyber-insurance are in place and their contact paths are known (Sections 14.21, 14.23).

  • Communication templates and a regulator-notification plan are pre-drafted (Sections 14.24, 14.3).

An organization that cannot check these boxes is not choosing to accept ransomware risk; it usually does not know it is carrying it.

14.26 Breach Notification Quick Reference#

Notification deadlines are legal obligations with real penalties, and the clock usually starts at discovery (Section 14.3). The exact rules change and vary by jurisdiction, the legal-currency caveat of Chapters 18 through 20 applies, so this is orientation, not legal advice, and counsel must confirm the current requirement.

Regime

Trigger

Typical deadline

GDPR (EU)

Personal-data breach with risk to individuals

Notify the supervisory authority within 72 hours of awareness

US state laws (e.g., California)

Breach of residents’ personal information

Without unreasonable delay; some states set outer limits (e.g., 30-60 days)

HIPAA (US healthcare)

Breach of protected health information

Individuals without unreasonable delay and within 60 days; large breaches to regulators promptly

PCI DSS (payment cards)

Suspected cardholder-data compromise

Notify the card brands and acquirer immediately, per contract

SEC (US public companies)

Material cybersecurity incident

Disclose materiality determination promptly (a four-business-day regime)

Sector and critical-infrastructure rules

Varies (e.g., reporting to a national cyber agency)

Often 24 to 72 hours

The operational lesson is that the notification clock runs in parallel with the technical response, not after it, which is why legal and communications join the CSIRT at the start (Section 14.21) rather than being called in at the end.

Exercises#

  1. Why should an internal status update state the time of the next update, and what failure does this prevent?

  2. From the readiness checklist, which single item most directly determines whether ransomware becomes a recoverable event or a catastrophe, and why?

  3. A public US company determines a cyber incident is material on a Monday. In general terms, what does the SEC regime require of it, and on what clock?

  4. Why do legal and communications need to join the incident from the first hour rather than after containment?

Answer Key#

  1. It commits the team to a cadence so stakeholders are not left in silence inventing worse scenarios; it prevents the information vacuum that speculation and rumor fill.

  2. Tested, offline or immutable backups: they let the organization restore rather than pay, because ransomware that cannot reach the backups cannot hold recovery hostage.

  3. It must disclose the incident promptly once materiality is determined, under a four-business-day regime, so the notification obligation runs on a tight legal clock in parallel with the technical work.

  4. The breach-notification clocks (Section 14.3) start at discovery and run in parallel with the technical response, and external messaging must be legally cleared and consistent, so legal and communications must be engaged from the outset, not after the fact.

14.27 An Incident Report, Annotated#

Section 14.13 provided evidence and communication templates; the deliverable that outlives every incident is the final incident report, so this section walks its structure with annotations explaining why each part exists. The report is read by three very different audiences, executives who need the business impact, engineers who need the technical detail, and sometimes regulators or courts who need defensible facts, so it is layered.

1. Executive Summary (half a page, non-technical)
   What happened, when, business impact, current status, and the one or
   two decisions leadership must make. Written last, read first.
   -> Annotation: if an executive reads only this, they must still be able
      to act. No jargon, no blame, just facts and asks.

2. Timeline (factual, timestamped, time-zone-explicit)
   A chronological account from initial access to containment and recovery,
   each entry tied to evidence (a log line, an alert, an analyst action).
   -> Annotation: this is the spine of the report and the artifact most
      scrutinized later. Separate attacker actions from responder actions.
      Use the forensic timeline of Sections 13.14 and 13.27 as the source.

3. Technical Analysis (the how)
   Initial access vector, tools and malware used (with hashes and IOCs,
   Section 15.12), accounts and systems affected, data accessed or taken,
   and mapping to MITRE ATT&CK techniques.
   -> Annotation: precise and evidence-backed. "We assess with high
      confidence" and "we could not determine" are both honest and useful;
      overstating certainty destroys credibility.

4. Impact Assessment (the so-what)
   Systems, data, users, and business processes affected; regulatory and
   contractual implications (breach-notification triggers, Section 14.26).
   -> Annotation: this section drives legal and notification decisions, so
      it must distinguish confirmed impact from potential impact.

5. Root Cause
   The underlying condition that allowed the incident (an unpatched service,
   a phished credential, a missing control), not merely the proximate event.
   -> Annotation: root cause is a control failure, not a person. Blameless
      analysis (Section 14.14) gets you honest information next time.

6. Lessons Learned and Recommendations
   Prioritized, assigned, and dated actions to prevent recurrence and to
   detect faster next time, each tied to a finding above.
   -> Annotation: recommendations with no owner and no date do not happen.
      Feed detection gaps back into the lifecycle of Section 12.20.

The annotations share a single theme: the report is not a diary, it is an instrument for decisions and improvement. Its authority comes from tying every claim to evidence and from stating uncertainty honestly, which is exactly the standard that makes it defensible if the incident later reaches regulators or court (Section 13.19). A disciplined report is also how the response function earns the resources to do better next time, because it converts a chaotic event into a clear, prioritized case for change.

Exercises#

  1. Why is the incident report layered, and who are its three main audiences?

  2. Why is the timeline described as the spine of the report, and what must it separate?

  3. Why should root cause be expressed as a control failure rather than a person’s mistake?

  4. What makes a recommendation actionable rather than decorative?

Answer Key#

  1. Because its audiences need different things (executives need business impact and decisions, engineers need technical detail, regulators/courts need defensible facts), so it is layered from a non-technical summary down to evidence-backed detail.

  2. It is the chronological, evidence-tied account that everything else references; it must separate attacker actions from responder actions so cause and response are not confused.

  3. Because blameless analysis yields honest information and durable fixes; a control failure can be engineered away, whereas blaming an individual suppresses the reporting needed to improve.

  4. A specific action with an assigned owner and a due date, tied to a finding; recommendations without ownership and dates do not get done.

14.28 Containment Decisions Under Uncertainty#

Section 14.4 introduced containment; in practice the hardest part of response is deciding how to contain when you do not yet know the full scope, and getting it wrong is costly in both directions. This section frames the core tradeoff and the judgment it requires.

The central tension is isolate now versus monitor first. Isolating a compromised host immediately stops ongoing damage and lateral movement, but it also tips off the attacker (who may then destroy evidence, detonate ransomware, or burn their access and move to a system you have not found) and it destroys volatile evidence (Section 13.4) if done by pulling power. Monitoring first preserves evidence and can reveal the full scope, including other compromised hosts and the attacker’s objective, but every minute of monitoring is a minute the attacker can act.

A structured way to decide weighs a few factors:

Contain immediately when:
  - active, ongoing harm (data being exfiltrated now, ransomware spreading)
  - a critical system or regulated data is directly at risk
  - the attacker appears aware they are detected
  - business risk of continued access outweighs intelligence value

Monitor briefly first when:
  - the attack appears slow and the immediate risk is low
  - scope is unknown and premature isolation would leave hidden footholds
  - you can monitor safely without regulated data exposure
  - preserving volatile evidence is essential to the investigation

Containment also has graded options between doing nothing and pulling the plug: network-isolate a host at the switch or EDR (keeping it powered so memory is preserved for Section 13.13) rather than shutting it down; disable a compromised account rather than the whole directory; block a C2 domain at the proxy while watching whether the malware fails over to a backup channel. The professional stance is that containment is a decision made with incomplete information under time pressure, so it is made deliberately, with the reasoning and approval recorded (Section 14.13), and revisited as scope becomes clearer. Deciding well under uncertainty, rather than freezing or overreacting, is what separates a practiced responder from a checklist follower, and it is the judgment the tabletop exercises of Section 14.14 are designed to build.

Exercises#

  1. State the central containment tradeoff and one concrete risk on each side.

  2. Give two conditions under which immediate containment is the right call.

  3. What is a graded containment option that preserves volatile memory evidence, and why does it help?

  4. Why should containment decisions be recorded with their reasoning and revisited?

Answer Key#

  1. Isolate now versus monitor first: isolating immediately stops ongoing harm but tips off the attacker and destroys volatile evidence; monitoring first preserves evidence and reveals scope but gives the attacker more time to act.

  2. Any two of: active ongoing harm (live exfiltration or spreading ransomware), a critical or regulated system directly at risk, or signs the attacker knows they are detected.

  3. Network-isolating the host at the switch or EDR while leaving it powered on; it stops communication and lateral movement while preserving memory for live forensics (Section 13.13).

  4. Because the decision is made with incomplete information under time pressure; recording the reasoning makes it defensible and accountable, and revisiting it lets the team correct course as scope becomes clearer.

Chapter Summary#

This chapter built an operational view of incident response. It separated incidents from events, walked through the NIST SP 800-61 lifecycle, and covered the legal and regulatory obligations that shape response, alongside the assume-breach mindset. It laid out a before, during, and after playbook, illustrated it with a ransomware case study, and detailed the CSIRT, its roles, and communication, then went deep on triage, severity, containment, and recovery and on the postmortem, metrics, and exercises that drive improvement. The recurring lesson is that effective response depends on preparation and clear roles, so that decisions under pressure follow a rehearsed plan rather than improvisation.

Why This Matters#

The median dwell time (time from initial breach to detection) globally has declined from hundreds of days a decade ago to a few weeks, but that still means weeks of unrestricted attacker access before response begins. Every day of undetected intrusion increases the scope of data exposed, the number of systems compromised, and the cost of remediation. Organizations with tested, practiced incident response plans recover faster and with lower cost than those without them.

News in Focus: Attacker Dwell Time in Major Ransomware Incidents#

Post-breach analysis of major ransomware incidents has repeatedly found that the attackers were active inside the network for days to weeks before deploying the ransomware payload. During that dwell time, they explored the network, exfiltrated data, and deployed backup access mechanisms. Organizations that detected the intrusion during this phase and responded quickly prevented the ransomware deployment. Those that detected only when the ransomware deployed faced a far more difficult recovery. This finding drives the investment in MTTD reduction and proactive threat hunting that modern security programs prioritize.

# Chapter 14 -- Incident response: severity scorer and timeline builder

from dataclasses import dataclass, field
from typing import List
from datetime import datetime, timedelta

@dataclass
class IncidentEvent:
    timestamp: str
    phase: str
    actor: str
    action: str
    ioc: str = ""

@dataclass
class Incident:
    id: str
    title: str
    events: List[IncidentEvent] = field(default_factory=list)

    def add(self, ts, phase, actor, action, ioc=""):
        self.events.append(IncidentEvent(ts, phase, actor, action, ioc))

    def severity_score(self):
        score = 0
        for e in self.events:
            if "ransomware" in e.action.lower():   score += 40
            if "exfiltrat" in e.action.lower():    score += 30
            if "domain admin" in e.action.lower(): score += 25
            if "lateral" in e.action.lower():      score += 15
            if "credential" in e.action.lower():   score += 10
        return min(score, 100)

    def print_timeline(self):
        print(f"\n  Incident: {self.id} -- {self.title}")
        print(f"  {'Timestamp':<22} {'Phase':<15} {'Actor':<18} Action")
        print("  " + "-"*85)
        for e in self.events:
            print(f"  {e.timestamp:<22} {e.phase:<15} {e.actor:<18} {e.action}"
                  + (f"  [IOC: {e.ioc}]" if e.ioc else ""))
        score = self.severity_score()
        severity = "CRITICAL" if score>=80 else "HIGH" if score>=50 else "MEDIUM" if score>=25 else "LOW"
        print(f"\n  Severity score: {score}/100 ({severity})")

# Simulate a ransomware incident timeline
inc = Incident("IR-2026-042", "Ransomware: MegaCorp manufacturing network")
inc.add("2026-05-20 02:14", "Detection",   "SIEM",          "Alert: anomalous RDP auth from 198.51.100.5",    "198.51.100.5")
inc.add("2026-05-20 07:30", "Analysis",    "SOC Analyst",   "Triage confirms: admin account compromised")
inc.add("2026-05-20 08:15", "Containment", "Incident Cmd",  "Compromised account disabled; RDP blocked at FW")
inc.add("2026-05-20 09:00", "Analysis",    "Forensics",     "Memory dump: Cobalt Strike beacon found",        "beacon_x64.dll")
inc.add("2026-05-20 09:45", "Analysis",    "Forensics",     "Lateral movement confirmed: 14 hosts affected")
inc.add("2026-05-20 11:00", "Eradication", "IT Ops",        "14 hosts isolated; credential reset initiated")
inc.add("2026-05-20 14:00", "Eradication", "IT Ops",        "Malware removed; persistence mechanisms cleared")
inc.add("2026-05-21 08:00", "Recovery",    "IT Ops",        "Systems rebuilt from clean gold images")
inc.add("2026-05-21 16:00", "Recovery",    "IT Ops",        "Services restored; enhanced monitoring active")
inc.add("2026-05-23 10:00", "Post-Incident","Incident Cmd", "Lessons-learned review completed; playbook updated")

inc.print_timeline()

# MTTD / MTTR calculation
# Breach at ~2026-05-18 (estimated from forensics); detected 2026-05-20 02:14
breach    = datetime(2026, 5, 18, 14, 0)
detected  = datetime(2026, 5, 20,  2, 14)
contained = datetime(2026, 5, 20, 11,  0)
recovered = datetime(2026, 5, 21, 16,  0)

mttd = (detected  - breach).total_seconds() / 3600
mttr = (contained - detected).total_seconds() / 3600
mtti = (recovered - detected).total_seconds() / 3600

print(f"\n  MTTD (breach -> detect)  : {mttd:.1f} hours")
print(f"  MTTR (detect -> contain) : {mttr:.1f} hours")
print(f"  Total recovery time      : {mtti:.1f} hours")

  Incident: IR-2026-042 -- Ransomware: MegaCorp manufacturing network
  Timestamp              Phase           Actor              Action
  -------------------------------------------------------------------------------------
  2026-05-20 02:14       Detection       SIEM               Alert: anomalous RDP auth from 198.51.100.5  [IOC: 198.51.100.5]
  2026-05-20 07:30       Analysis        SOC Analyst        Triage confirms: admin account compromised
  2026-05-20 08:15       Containment     Incident Cmd       Compromised account disabled; RDP blocked at FW
  2026-05-20 09:00       Analysis        Forensics          Memory dump: Cobalt Strike beacon found  [IOC: beacon_x64.dll]
  2026-05-20 09:45       Analysis        Forensics          Lateral movement confirmed: 14 hosts affected
  2026-05-20 11:00       Eradication     IT Ops             14 hosts isolated; credential reset initiated
  2026-05-20 14:00       Eradication     IT Ops             Malware removed; persistence mechanisms cleared
  2026-05-21 08:00       Recovery        IT Ops             Systems rebuilt from clean gold images
  2026-05-21 16:00       Recovery        IT Ops             Services restored; enhanced monitoring active
  2026-05-23 10:00       Post-Incident   Incident Cmd       Lessons-learned review completed; playbook updated

  Severity score: 25/100 (MEDIUM)

  MTTD (breach -> detect)  : 36.2 hours
  MTTR (detect -> contain) : 8.8 hours
  Total recovery time      : 37.8 hours

Review Questions (MCQ)#

Q1. The difference between a security event and a security incident is: A. Events are internal, incidents are external B. An incident is an event that actually or potentially jeopardises CIA C. Events are logged, incidents are not D. Incidents require law enforcement involvement

Q2. NIST SP 800-61 defines incident response phases. Which phase occurs BEFORE an incident? A. Detection B. Containment C. Preparation D. Recovery

Q3. Short-term containment prioritizes: A. Full forensic preservation over all else B. Stopping spread immediately, possibly at cost of full functionality C. Completing eradication before isolating systems D. Notifying regulators

Q4. The gold standard for eradication of a deeply compromised system is: A. Running a full antivirus scan B. Deleting the malware files C. Rebuilding from a known-good image D. Rebooting the system

Q5. MTTD measures: A. Time from detection to containment B. Time from breach to detection C. Time from containment to recovery D. Time to notify regulators

Q6. GDPR breach notification to the supervisory authority is required within: A. 24 hours B. 72 hours C. 7 days D. 30 days

Q7. The lessons-learned review is designed to be: A. A blame assignment exercise B. Blameless and process-improvement focused C. Conducted only after criminal incidents D. Optional for P2 and lower incidents

Q8. An Indicator of Compromise (IOC) is used during response to: A. Write new firewall rules B. Identify additional affected systems and enable blocking C. Prove the attacker’s identity D. Calculate ROSI

Q9. Recovery validation requires confirming that: A. All employees have been retrained B. The initial access vector is closed and monitoring is in place C. Law enforcement has closed the case D. The SIEM has been upgraded

Q10. Which regulatory framework requires healthcare organizations to notify HHS of breaches? A. GDPR B. PCI DSS C. HIPAA D. SOX

Answers: Q1 B, Q2 C, Q3 B, Q4 C, Q5 B, Q6 B, Q7 B, Q8 B, Q9 B, Q10 C.

Lab Assignment#

Part A – Playbook: Write a step-by-step incident response playbook for a ransomware incident. Cover each NIST phase with at least three specific actions per phase. Include who is responsible for each action and what tools are used.

Part B – Triage exercise: Given the following alert: “SIEM: 847 failed SSH logins from 203.0.113.50 to jump-host-01 in 10 minutes, followed by 1 successful login at 03:47 local time.” Rate the severity, identify the likely attack type, list three immediate containment actions, and name three forensic artefacts to collect.

Part C – Incident timeline: Simulate an incident timeline (minimum 8 events) for a business email compromise attack where the finance director’s email was compromised, used to authorize a fraudulent wire transfer, and discovered by the bank three days later. Include timestamps, phases, actors, and actions.

Part D – Notification letter: Draft a breach notification letter to affected customers following a fictitious database breach exposing name and email address (not financial data). Meet GDPR requirements: what happened, when, what data, what action taken, what rights the subject has.

References#

[NationalIoSaTechnology12]

National Institute of Standards and Technology. Computer security incident handling guide. Technical Report NIST SP 800-61 Rev. 2, U.S. Department of Commerce, 2012. doi:10.6028/NIST.SP.800-61r2.

  1. Practical Computer Security (Course 3): lectures on Attacks Are Inevitable; Before, During, and After the Attack; and the Locky ransomware case study. (SANS incident-response lifecycle: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.)

  2. NIST SP 800-61 Rev. 3 (2025): Incident Response Recommendations and Considerations for Cybersecurity Risk Management (CSF 2.0 Community Profile); supersedes SP 800-61r2.

  3. SANS Incident Handler’s Handbook; MITRE ATT&CK for response mapping.

Contents