Incident Response

Trick 1 NIST SP 800-61 — Map Every Activity to Its Phase Instantly

The exam presents a specific activity and asks which NIST IR lifecycle phase it belongs to. The trap is that NIST IR and NIST CSF use different terminology, and many candidates confuse phases from the two frameworks. Use only the NIST SP 800-61 four-phase model for incident handling questions.

Phase 1 — Preparation (everything done BEFORE an incident):

Assembling the go bag (forensic laptops, removable media, forensic software, digital cameras)
Creating and updating the contact list
Documenting network diagrams
Computing critical file hash values
Obtaining clean OS and application images
Writing and testing incident response policies and procedures
Training (tabletop exercises, simulations)

Phase 2 — Detection and Analysis (identifying the incident):

IPS alert fires; AV detects malware; FIM alerts on configuration change; traffic analysis shows anomaly
Sandbox analysis of suspected malware
Characterizing the scope and severity of the incident

Phase 3 — Containment, Eradication, and Recovery (stopping and fixing):

Containment: isolate affected systems; stop lateral movement
Eradication: remove malware; disable compromised accounts; patch the exploited vulnerability; close backdoors
Recovery: restore from backups; reimage; replace compromised files; tighten perimeter

Phase 4 — Post-Incident Activity (learning and improving):

Post-incident meeting (ASAP after resolution)
Timeline reconstruction
Answering the four retrospective questions
Updating monitoring, procedures, and training based on findings

Rule: Before = Preparation. Detecting/sandboxing = Detection and Analysis. Isolate/remove/restore = Containment, Eradication, and Recovery (all in the same phase). Post-meeting/timeline/questions = Post-Incident Activity.

Trick 2 Preparation Items — All Belong to Preparation, Not Later Phases

The exam frequently presents a preparation activity and offers phases 2, 3, or 4 as distractors. Candidates who think logically about when items are “used” (not when they are “created”) answer incorrectly. The phase assignment is based on when the item is CREATED, not when it is APPLIED.

The classification error candidates make:

“Critical file hash values are compared to detect malware during an incident → therefore they belong to Detection and Analysis” — WRONG
“Clean OS images are used during recovery → therefore they belong to Recovery” — WRONG
“Network diagrams are consulted during analysis → therefore they belong to Detection and Analysis” — WRONG

The correct reasoning: all of these items are created, assembled, and verified BEFORE an incident occurs. They belong to the Preparation phase. The fact that they are used in other phases does not change their phase classification. The Preparation phase creates the conditions for all other phases to succeed.

What actually belongs to other phases:

Detection and Analysis: the ACT of comparing current file hashes to the baseline (using the hashes created in Preparation)
Recovery: the ACT of restoring from a clean image (using the image created in Preparation)

Rule: Preparation = CREATING the tools. Other phases = USING the tools. File hashes, network diagrams, clean images, contact lists, go bag, procedures = ALL Preparation. Created before incidents, used during incidents.

Trick 3 Sandbox + Self-Destruct — The Isolation Timing Problem

The exam presents a scenario where a responder isolates a system and the malware triggers a destructive action in response. The question asks why this happened or what should have been done differently. The answer involves the isolation-before-imaging problem.

What a sandbox is: an isolated OS environment for safely analyzing malware behavior without affecting production systems. The sandbox is reset after analysis.

Why isolation is not always safe: sophisticated malware checks for signs of isolation (absence of real user activity, missing network connectivity, VM detection artifacts). When it detects isolation, it may:

Delete itself (destroy evidence)
Encrypt its payload (prevent analysis)
Execute a destructive action (ransomware encryption, data wipe)

The correct isolation sequence when self-destruct risk is high:

Capture live memory image FIRST (RAM contains running processes, encryption keys, network connections — volatile data lost on shutdown or disconnect)
Take disk snapshot
THEN isolate the system
Analyze captured images offline, not the live system

The exam trap: “isolate immediately” is always presented as the correct containment action — and it generally is. The exception is when memory evidence must be captured first. If the question describes self-destruct behavior after isolation, the answer is “memory should have been captured before isolating.”

Rule: Sandbox = isolated OS for safe analysis. Self-destruct malware = detects isolation and destroys itself. Solution: capture memory image BEFORE isolating to preserve volatile evidence. Isolation ASAP is correct unless self-destruct risk is known.

Trick 4 Post-Incident Meeting — Timing and the Four Required Questions

The exam tests two facts about post-incident meetings: when they should be held, and what questions they must answer. Both are frequently included in scenario questions where the wrong answer is plausible.

Timing — the most tested fact: post-incident meetings should be held as soon as possible after the incident is resolved. Candidates who answer “within 30 days” or “at the next scheduled review cycle” are wrong. The reason is memory degradation: specific timelines, decision points, and observations fade quickly. Accurate retrospective analysis requires prompt review.

The four required questions (NIST SP 800-61 framework for post-incident analysis):

What happened exactly? (timeline reconstruction using logs, alerts, forensic evidence)
How did the incident response plan perform? (were procedures followed? did communication work?)
What would be done differently? (retrospective analysis of procedural gaps, tool deficiencies, training needs)
Which indicators should be monitored in the future? (were early warning signals missed? update monitoring to detect similar events earlier)

Common wrong answer: “The first question at a post-incident meeting should be who was responsible for the breach.” Wrong — post-incident meetings are improvement-focused, not blame-focused. The goal is process improvement, not accountability assignment.

Rule: Post-incident meeting = ASAP after resolution (not weekly/monthly schedule). Four questions: WHAT happened, HOW did the plan work, WHAT would be different, WHICH indicators to watch. Not blame-focused -- improvement-focused.

Practice Scenarios

Scenario A: A hospital is auditing its incident response preparedness. The audit identifies five items and asks the IR team to classify each by NIST SP 800-61 lifecycle phase: (1) The IR team maintains a kit with dedicated forensic laptops, USB drives, forensic software, and digital cameras stored in the security office. (2) The SIEM generates an alert when outbound traffic from a workstation exceeds 500 MB in a 10-minute window, indicating possible data exfiltration. (3) After confirming ransomware, the team disconnects the affected servers from the network. (4) Following complete system restoration, the team holds a meeting to reconstruct the attack timeline and determine which monitoring rules failed to detect the initial compromise. (5) The IR team computes and stores SHA-256 hashes of all critical OS system files on a secured offline server.

Answer: Item 1 — Preparation: The go bag is assembled before incidents occur. Forensic laptops, removable media, forensic software, and digital cameras are the standard go bag contents listed in NIST SP 800-61. Their presence supports the Preparation phase regardless of when they will be used. The fact that they will be used during Detection and Recovery does not change this classification. Item 2 — Detection and Analysis: The SIEM rule is a detection mechanism. When triggered, it alerts the team that an incident may be in progress and enables analysis of the alert to determine severity and scope. The traffic threshold rule itself is a detection configuration; the alert it generates initiates the Detection and Analysis phase. Item 3 — Containment (within Containment, Eradication, and Recovery): Disconnecting servers from the network is a containment action -- it stops lateral movement and cuts off attacker communication. This is the first sub-phase within Phase 3. Note: the NIST phase name is "Containment, Eradication, and Recovery" -- all three are sub-phases within Phase 3, not separate phases. Item 4 — Post-Incident Activity: The meeting held after restoration to reconstruct the timeline and identify monitoring gaps is Post-Incident Activity. Key indicators: (a) occurs AFTER resolution, (b) focused on reconstruction and improvement, (c) explicitly asks which monitoring rules failed -- a retrospective improvement question. Item 5 — Preparation: Computing and storing critical file hashes before incidents is a Preparation phase activity. The hashes will be used during Detection and Analysis (comparing current hashes against the baseline to identify malware-modified files), but they are created in Preparation. The phase is assigned based on when the item is created, not when it is used.

Scenario B: A financial firm discovers that a workstation has been infected with sophisticated malware. The incident responder considers two courses of action: Option A -- immediately disconnect the workstation from the network and then image the disk. Option B -- capture a live memory image and disk snapshot while the workstation is still connected, then disconnect and image. The threat intelligence team informs the IR team that this malware family is known to monitor for network disconnection events and initiates a secure file deletion routine when network connectivity is lost. Given this information, evaluate both options: which is correct, what evidence does each preserve, and what would be lost if Option A were followed?

Answer: Option B is correct given the known self-destruct behavior. Option A analysis -- immediate disconnection: In most scenarios, isolating immediately is the correct first action for containment. However, given that this specific malware monitors for network disconnection and initiates secure deletion when connectivity is lost, Option A would cause the malware to destroy evidence upon disconnection. What would be lost if Option A is followed: (1) All volatile memory contents -- running processes, open network connections, injected code in memory, and most critically, any encryption keys held in RAM that could decrypt encrypted files or communications. (2) Any malware components that reside only in memory and have not written to disk (fileless malware). (3) Potentially the disk contents if the malware performs a secure wipe on disconnection. After isolation, forensic analysis would find a largely clean system from which the attacker successfully destroyed their tracks. Option B analysis -- memory capture before isolation: Capturing a live memory image first preserves the full contents of RAM at the moment of capture: running malware processes, injected DLLs, network socket state, encryption keys, and command history. The disk snapshot preserves the full disk state including any temporary files or malware persistence mechanisms the malware might delete. After capturing both images, the workstation is disconnected. The malware self-destructs, but the responder already has complete copies of everything that was running at the time of capture. Forensic analysis proceeds on the captured images, not the live (now wiped) system. The self-destruct behavior is irrelevant because evidence was already preserved. Key principle: when self-destruct behavior is known or suspected, the priority ordering changes from "contain first" to "capture evidence first, then contain." This is the specific exception to the general rule that isolation should be immediate.

Scenario C: A retail company suffered a point-of-sale malware infection that resulted in 200,000 payment card records being exfiltrated over a 6-week period. The incident was detected when a card-issuing bank contacted the company about fraudulent charges. After the incident was fully resolved (systems reimaged, vulnerability patched, new detection rules deployed), the CISO scheduled the post-incident meeting for the following month to allow team members to "settle down and reflect." The meeting was held 5 weeks after resolution. Evaluate this approach and identify: (1) the specific NIST recommendation that was violated, (2) what was likely lost due to the delay, (3) what the post-incident meeting should accomplish, and (4) what changes to the monitoring environment should result from this incident.

Answer: (1) NIST recommendation violated: NIST SP 800-61 recommends holding the post-incident meeting as soon as possible after the incident is resolved -- not weeks later. The "settle down and reflect" approach, while understandable from a human perspective, violates this guidance. Memories of specific timeline details, decision points, and observations fade within days, not weeks. A 5-week delay means that the most detailed and accurate recollections have been lost. (2) What was lost due to the delay: Specific timeline precision -- responders who remember "it was around week 3 when we first suspected lateral movement" cannot reconstruct whether the timeline was actually 19 days or 25 days. Individual decision recollection -- "I remember deciding not to escalate that alert because it seemed low-priority" is hard to recover accurately after 5 weeks. Contextual detail -- why specific actions were taken (or not taken) in the moment is much harder to reconstruct from notes and logs alone than from fresh memory. The accuracy of the timeline affects the quality of the retrospective analysis and the actionability of the recommendations. (3) What the post-incident meeting should accomplish: Reconstruct the complete attack timeline from initial compromise (approximately 6 weeks before detection) through resolution. Identify how the initial POS compromise occurred and why it persisted undetected for 6 weeks. Answer the four NIST questions: What happened exactly (timeline)? How did the IR plan perform (the incident was detected by an external bank, not internal monitoring -- this is a significant failure)? What would be done differently (earlier detection, better monitoring)? Which indicators should be watched in the future (the malware likely left detectable artifacts that better monitoring would have caught earlier). (4) Monitoring changes that should result: The malware operated for 6 weeks exfiltrating data undetected. This indicates failures in: (a) Outbound traffic monitoring -- 200,000 card records leaving the network should have triggered data loss prevention or traffic anomaly alerts. (b) POS system integrity monitoring -- FIM on POS systems would have detected the malware modification of payment processing software. (c) Network segmentation -- POS systems should have had limited outbound internet access, making exfiltration significantly harder. Monitoring updates: implement DLP for cardholder data patterns; deploy FIM on all POS systems with alerting on executable and configuration file changes; restrict POS outbound internet access to approved payment processor IPs only; add behavioral monitoring for unusual data staging (large files in temp directories).

Incident Response — Exam Tricks