What are the four phases of the NIST SP 800-61 incident response lifecycle?
NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide): (1) Preparation — establish tools, contacts, baselines, policies before incidents occur. (2) Detection and Analysis — identify and characterize incidents using IPS, AV, FIM, network traffic analysis. (3) Containment, Eradication, and Recovery — isolate, remove threats, restore systems. (4) Post-Incident Activity — lessons learned, timeline reconstruction, process improvement. These four phases are the primary exam content for incident response. NIST CSF is a different framework.
What is an incident go bag, and what does it contain?
Incident go bag: pre-assembled kit of hardware and software needed to respond to any incident, assembled during the Preparation phase before incidents occur. Contents: Forensic laptops (dedicated systems with forensic software pre-installed, not general-purpose workstations). Removable media (USB drives/external drives for copying evidence). Forensic software (disk imaging, memory capture, artifact analysis without modifying evidence). Digital cameras (photograph physical evidence, screen states, cable connections, physical scene before anything is moved). Having these tools ready means no scrambling during an active incident.
What analysis resources must be prepared before an incident, and why is each critical?
Contact list: up-to-date info for all personnel to notify (management, legal, PR, law enforcement). Without this, notifications are delayed. Network diagrams: accurate topology documentation so responders understand traffic flows and quickly locate affected systems. Security baselines: documented known-good configurations for all system types; used to identify attacker-introduced changes. Critical file hash values: cryptographic hashes of critical OS and application files computed before incidents; during analysis, current hashes are compared to detect malware-modified files. Clean OS/application images: verified backups for rapid reimaging. Policies and procedures: documented roles and escalation paths so all personnel know what to do.
Why is detection the most difficult phase of incident response?
Detection challenges: (1) Volume: internet-connected organizations receive constant attack traffic; distinguishing legitimate compromise from automated scanning is difficult at scale. (2) Complexity: incidents rarely present as single clear events; a malware infection involves dozens of processes, registry changes, network connections across hours or days. (3) Lead time signals may be present: exploit announcements (Patch Tuesday), vulnerability scanner activity in web logs, and direct threats provide advance warning — but only if someone is monitoring for them. The challenge is identifying the legitimate threats within an enormous volume of security events.
What four detection sources does NIST SP 800-61 identify for incident identification?
IPS (Intrusion Prevention System): detects and blocks known attack patterns; a buffer overflow attempt is a high-fidelity alert. Antivirus / EDR: identifies malware by signature or behavior; reports presence and location. FIM (File Integrity Monitoring): monitors critical system and configuration files for unauthorized changes; alerts on host-based modifications by attackers. Network traffic analysis: monitors flows for anomalies; a large spike in outbound traffic can indicate active data exfiltration. Also: web server logs for vulnerability scanner activity. These sources provide different views; multiple sources together provide the clearest picture.
What is a sandbox in incident response, and what is the self-destruct problem?
Sandbox: an isolated operating system environment where analysts safely execute and observe malware. Malware is loaded, run, and monitored for OS changes (registry, files, network connections). The sandbox is analyzed then reset without affecting production. Self-destruct problem: sophisticated malware detects isolation (checks for VMs, absence of user activity, limited network connectivity) and responds by deleting itself, encrypting its payload, or triggering a destructive payload. Isolating the system destroys the evidence. Mitigation: capture a full memory image and disk snapshot BEFORE disconnecting the system, so analysis can proceed even if the malware self-destructs after isolation.
What are the eradication steps in NIST SP 800-61, and why must all be completed?
Eradication removes the threat and closes pathways that allowed the incident: (1) Remove malware: delete all malicious files, registry entries, scheduled tasks, persistence mechanisms. Do not assume AV removal is complete for advanced threats. (2) Disable compromised accounts: any account used by the attacker or with exposed credentials must be disabled and password-reset before re-enabling. (3) Patch vulnerabilities: identify and fix the specific vulnerability exploited for initial access — without patching, recovery is temporary. (4) Close unauthorized access points: remove backdoors, rogue accounts, unauthorized software. All four must be completed; missing any one leaves the attacker able to re-enter.
What are the three recovery methods for affected systems, and in what order should they be preferred?
Recovery restores systems to a known-good state. Preference order: (1) Restore from verified backups: fastest when clean backups exist; overwrite affected systems with pre-incident backups verified as uncompromised. (2) Rebuild from scratch (reimage): use clean OS and application images from the go bag; more thorough than restoration, eliminates any doubt about residual malware, but more time-consuming. (3) Replace specific compromised files: if full reimage is impractical, replace only the identified malicious files with known-good versions verified by hash comparison. After recovery: patch the vulnerability, tighten perimeter controls, enhance monitoring. Systems must not return to production if the initial entry vulnerability remains unpatched.
When should the post-incident meeting be held, and what four questions must it answer?
Timing: as soon as possible after the incident is resolved. Delayed post-mortems suffer from memory fade: specific timestamps, decisions made, and attacker actions become unclear. Four required questions: (1) What happened exactly? — reconstruct the complete timeline from first indicator to resolution using logs, alerts, forensic evidence. (2) How did the IR plan perform? — were procedures followed? Did communication and escalation work? (3) What would be done differently? — identify procedural weaknesses, missing tools, training gaps. (4) Which indicators should be monitored in the future? — were early warning signals missed? Update monitoring to detect similar events earlier.
What are the three types of incident response training, ordered by cost and realism?
(1) Tabletop exercise: lowest cost. Scenario-based discussion where the team walks through a hypothetical incident and makes decisions without touching live systems. Suitable for executives and management participation. Identifies procedural and communication gaps. (2) Simulation: moderate cost. Technical teams execute actual response procedures against a simulated incident in a test environment. Higher fidelity than tabletop; tests actual technical skills. (3) Red team / purple team exercise: highest cost, highest realism. An attack team attempts realistic intrusions while the defensive team detects and responds. Identifies real detection and response gaps in the live-equivalent environment. Training must occur BEFORE incidents — there is no on-the-job training during an active event.
Why is incident response training expensive, and why is it nonetheless a required investment?
Why expensive: incident response training, especially simulations and red team exercises, requires dedicated time, technical infrastructure (test environments), skilled attack team personnel, and often specialized outside consultants. For large organizations with multiple response teams, the cost scales significantly. Why it is required: real incidents provide no time for learning. When an active attack is occurring, responders must already know their roles, tools, and procedures. Inadequate training leads to: delayed containment (incident spreads further), missed evidence (improper handling destroys forensic value), and ineffective communication (unclear roles cause duplication and gaps). The cost of poor incident response — greater damage, regulatory penalties, extended downtime — consistently exceeds the cost of proper training.
What is the correct order of actions when a responder discovers active malware on a system, considering the self-destruct risk?
Order depends on self-destruct risk assessment: If self-destruct risk is LOW: (1) Isolate system from network immediately to stop C2 communication. (2) Capture disk image. (3) Analyze in sandbox. If self-destruct risk is HIGH (sophisticated malware, APT indicators, previous self-destruct behavior known): (1) Capture live memory image BEFORE isolation (running processes, network connections, encryption keys in RAM). (2) Take disk snapshot. (3) Then isolate. (4) Analyze captured images in sandbox environment. The key principle: isolating FIRST destroys volatile memory evidence (RAM is lost). But failing to isolate allows continued C2 communication. The decision is a risk tradeoff that must be made per-incident based on threat intelligence.