A comprehensive study guide covering the five containment steps, isolation vs. segmentation, media sanitisation methods (cryptographic erase / zero-fill / secure erase / physical destruction), eradication actions (reconstruction / reimaging / reconstitution), recovery actions (patching / permissions / logging / system hardening), post-incident activities, lessons learned six questions, and root cause analysis.
Objective 3.2 — Perform incident response activitiesObjective 3.3 — Post-incident activity phaseObjective 4.2 — IR reporting & communication
1
Containment — Five Priority Steps
Containment limits the scope and magnitude of an incident by securing data and minimising impact to business operations and customers. Rapid containment is critical — every minute of delay gives the adversary more time to pivot, spread laterally, and do damage. These five steps are in priority order.
1
Ensure safety and security of all personnel. People first — always. You can replace data and technology, but you cannot replace people. Every containment plan must start with ensuring no human safety is at risk.
2
Prevent ongoing intrusion or data breach. With people safe, focus on stopping the active breach. Cut off the attacker's ability to continue exfiltrating data or moving through the network.
3
Identify if the intrusion is primary or secondary. What you've found may be a distraction — attackers sometimes create a visible incident to draw attention while their real attack continues elsewhere (e.g., exfiltrating unimportant data to hide access to a critical data store).
4
Avoid alerting the attacker that they've been discovered. Some APT groups will "burn down the house" — destructively formatting all systems — if they realise they've been detected. Cut off their ability to do harm before you reveal that you know they're there. Never tip your hand prematurely.
5
Preserve forensic evidence. Last priority among the five — but still essential. Evidence from the intrusion may be needed for law enforcement prosecution, legal proceedings, or understanding the attack chain for future defence improvements.
"Burn down the house" — a real threat: Certain nation-state APT groups are documented to destructively wipe all systems if they detect that responders have found them. This is why Step 4 (not alerting the attacker) is critical — you need to cut off their access before they know you've detected them. Coordinate containment actions to happen simultaneously, not sequentially.
2
Isolation vs. Segmentation
There are two primary containment strategies. The choice between them depends on how urgently you need to stop the damage vs. how much forensic value you want to preserve. Both decisions should involve senior leadership, since each has significant business impact.
Isolation — complete removal
Removes the affected component entirely from the environment. Creates an air gap — turn off the switch port or physically unplug the cable. No traffic in or out. Also applies logically: disable a compromised account to isolate its access. Fastest way to stop damage spreading. Least stealthy — attacker may notice the loss of access. Reduces forensic analysis opportunity because you've cut off the connection entirely. Use when the risk is high enough that preventing damage is more important than observing the attacker.
Segmentation / Sandboxing — network boundary
Uses VLANs, routing, subnets, and firewall ACLs to prevent communications outside the protected segment while the system remains partially observable. Sandboxing redirects attacker traffic to a honeypot — allowing you to study their methods, capture IOCs, and create detection signatures without exposing production systems. More stealthy than isolation. Provides forensic and intelligence value. Requires legal counsel review (some jurisdictions treat this as entrapment if used in law enforcement). Use when you want to observe and learn from the attacker before cutting them off.
Consult senior leadership for both options. Isolation takes systems offline — immediate business impact. Segmentation/sandboxing may have legal implications. Neither decision belongs solely to the technical team. Present your recommendation with the business trade-offs and let executives make the final call.
3
Eradication — Media Sanitisation Decision Matrix
Eradication is the complete removal and destruction of the cause of the incident. The simplest option is replacing a system with a clean image from a trusted source. But when a drive must be sanitised for reuse or secure disposal, the correct method depends on the drive type. A quick format is never sufficient — some malware survives format operations.
Exam priority: Know which sanitisation method to use for which drive type. This is the most commonly tested concept from this section. Key reference: NIST SP 800-88 (Guidelines for Media Sanitisation).
Drive Type
Method
How it works
Command / Tool
Notes
Magnetic HDD
Zero-fill
Overwrites every bit on the drive with zeros. Multiple passes increase security.
Only reliable on magnetic media. Wear leveling on SSDs makes zero-fill unreliable for SSDs.
Self-Encrypting SSD
Cryptographic Erase (CE)
Erases the media encryption key, making all data permanently unreadable. Instantaneous.
Drive firmware command Built-in to self-encrypting drive (SED)
Fastest and most thorough for SEDs. Data is encrypted — destroying the key destroys access to all data.
Any SSD (non-SE)
Secure Erase
Manufacturer-provided software overrides wear-leveling to ensure all cells are wiped.
Manufacturer tool e.g. Samsung Magician, Intel MAS
Required because SSD wear leveling prevents zero-fill from reaching all physical cells.
Top Secret / Highly Classified
Secure Disposal
Physical destruction — mechanical shredding, incineration, or degaussing.
Physical destruction equipment
Reserved for highest classification data. Drive cannot be reused — it is destroyed. Degaussing also works on HDDs but not SSDs (no magnetic media).
Why zero-fill fails on SSDs: SSDs have a wear-leveling controller that distributes writes across cells to prevent premature wear. When you issue a zero-fill, the controller may not write zeros to recently written cells — some cells are skipped. Data remains recoverable in those cells. Always use Secure Erase (manufacturer software) or Cryptographic Erase for SSDs.
Once a system has been sanitised (or before, if restoration without full wipe is attempted), there are three approaches to bringing it back to a known-good state, ordered by complexity.
Reconstruction
Script-based restoration
Runs scripted installation routines and templates to copy files and settings back to a known-good state. Replaces or restores specific files that may have been modified. Faster than reimaging for targeted infections. Requires trusted, tested scripts.
Reimaging
Bit-by-bit image restore
Restores a complete image backup — a bit-by-bit copy of a known-good drive state. The most thorough automated restoration method. Requires a pre-existing known-good image. Slower than reconstruction but ensures the entire system state is clean.
Reconstitution
Surgical manual removal
Used when a system cannot be sanitised and reimaged — malware is removed piece by piece using manual analysis, selective file replacement, and monitoring. Riskiest and most complex. Seven-step process. Uses a Definitive Media Library (DML) for trusted replacement files.
Reconstitution — seven steps
Step 1
Analyse processes and network activity for signs of malware. Use Wireshark, Sysinternals, Process Explorer to map all malicious activity on the system before touching anything.
Step 2
Terminate suspicious processes and securely delete them. If any infected data files exist, recover their clean data before quarantining or deleting them.
Step 3
Identify and disable autostart locations — registry Run/RunOnce keys, Task Scheduler entries, crontab jobs — to prevent malware from relaunching after reboot.
Step 4
Replace contaminated processes with clean versions from trusted media — the Definitive Media Library (DML). Do not download replacements from the internet; only use known-good offline sources.
Step 5
Reboot and analyse for signs of continued infection. If malware persisted, it will reappear after reboot — return to Step 1 to identify what was missed.
Step 6
If infection persists, analyse firmware and connected USB devices. Some sophisticated malware resides in firmware — software-level removal alone won't eliminate it.
Step 7
If all tests are negative, reintroduce the system into the production environment. The system has been successfully reconstituted and is ready to resume normal operations.
5
Recovery — Four Action Types & Three Hardening Mottos
Recovery ensures hosts are fully reconfigured to operate business workflows as they did before the incident — and that the same vulnerability can't be exploited again. Recovery is typically the longest and most challenging part of the incident response. It's not complete until the system is both restored and hardened.
Patching
Scan → Patch → Scan
Install all missing security updates. Most non-zero-day attacks succeed because patches weren't applied. After patching, scan again to verify every patch was successfully installed — some systems silently fail patch installation in large environments.
Permissions
Reset and review all access
Mass password change for all affected accounts. Review firewall ACLs, file system permissions, and system privileges. Be aware that mass password changes cause some users to write passwords down — a new vulnerability. Check all permission settings are correctly configured.
Logging
Verify monitoring is back online
Attackers frequently disable logging as one of their first actions. Verify all logging, scanning, monitoring, and SIEM ingestion systems are functioning. Audit existing logs for attacker modification. Confirm logs are being written and forwarded to your security monitoring infrastructure.
System Hardening
Close every door that was open
Deactivate unused components (hardware, software, ports, services). Disable unused user accounts (guest, default admin). Implement patch management. Restrict peripheral access (USB, Bluetooth). Restrict shell/command line access to administrators only.
Three system hardening mottos
Motto 1
Uninstall everything you aren't using
Hardware, software, services, ports — if it's not needed, remove it. Every unused component is an attack surface.
Motto 2
Patch everything you need to keep
Scan → patch → scan. Find vulnerabilities, apply fixes, then verify the fixes took hold.
Motto 3
Restrict all users to least privilege
What you can't turn off and can't patch, you mitigate by limiting who can reach it. Users with least privilege limit the blast radius of any single compromise.
Once the threat is neutralised and systems are restored, post-incident activities document what happened, communicate it to the right people, and preserve the evidence. Three main areas: report writing, incident summary reports, and evidence retention.
Executive Summary
For leadership
Short (a handful of pages). Charts and bullets, not technical detail. Covers problem statement, observations, conclusions, and recommendations. Should clearly ask for what is needed (budget, people, tools) to prevent recurrence. Leaders need business impact and resource needs — not packet captures.
Incident Summary Report
Audience-specific versions
A broader category that includes the executive summary plus other audience-specific versions: a PR-facing version for media release, a technical version for sysadmins showing misconfigured systems, a legal version for prosecution support. Tailor content and technical depth to each audience.
Evidence Retention
Preserve for legal proceedings
Retain evidence for the period required by regulation and for the duration of any legal proceedings including appeals. Most organisations: minimum 6 months. Publicly traded (Sarbanes-Oxley): several years. Prosecution cases: hold evidence until all appeals complete. Hardware seized as evidence may not be returned for 2–3 years — budget for replacement. Cost of storage decreases over time; cloud storage is a cost-effective option.
Mark reports for their intended audience. Government reports on classified incidents must be marked with their classification level (e.g., Top Secret). Business reports should be marked for their intended audience and distribution. Improperly distributed incident details can create legal liability or tip off the attacker to your detection capabilities.
7
Lessons Learned — Six Questions, AAR & Benefits
Lessons learned is a structured post-incident analysis that identifies what happened, what worked, and what should be improved. The goal is improvement — not blame. Creating a psychologically safe environment where team members can speak honestly without fear of punishment is essential for getting accurate, actionable lessons.
Six lessons-learned questions
Who?
Who was the adversary — insider threat, external attacker, or both? What was their level of sophistication and capability?
Why?
What was the motive? What assets were they targeting? Financial gain, espionage, disruption, ransomware, hacktivism?
When?
When did the incident occur? When was it detected? What was the dwell time? Were we targeted during a vulnerable period (holidays, night shift)?
Where?
Where in the environment did the incident occur — which host, server, network segment? What was the scope of affected systems?
How?
What TTPs did the adversary use? How did they break in? What did they know about our environment? This drives future defensive improvements.
What?
What controls could have mitigated or prevented this incident? What do we need to add, change, or improve? This is the output that drives action.
Three benefits of lessons learned
IR Plan Updates
Real incidents reveal gaps in theoretical plans. Update playbooks, call lists, escalation procedures, and response timelines based on what actually happened vs. what the plan assumed. Plans written in theory must be refined by practice.
IOC Generation
Analysts create new detection filters, query statements, and binary signatures during the incident. These IOCs, detection rules, and signatures get added to SIEM and IDS systems, improving future detection of the same or variant threats.
Change Management Improvement
Slow change approval processes can cripple incident response. Lessons learned identifies specific bottlenecks and drives improvements to enable faster emergency changes during future incidents — without bypassing proper oversight entirely.
AAR vs. LLR: An After-Action Report (AAR) and a Lessons Learned Report (LLR) serve the same purpose under different names. Both document what happened, what worked, what didn't, and what should be changed. The AAR term comes from military tradition; LLR is more common in corporate environments. Either format is acceptable for the exam.
8
Root Cause Analysis — Four Steps
A Root Cause Analysis (RCA) is a systematic process to identify the initial source of the incident and how to prevent it from recurring. The goal is not just to fix this one instance, but to find and fix every other vulnerable system across the network that shares the same weakness.
1
Define and scope
Determine the full scope of the incident — how many machines affected, which users, what operational impact. Document the initial attack vector (USB malware, phishing click, web drive-by) and all systems that were touched.
2
Determine causal relationships
Trace the chain of events that led to the incident. Identify the root cause — not just the symptom. Example: malware installed via USB. Root cause: USB mass storage allowed + AV not updated + Windows version missing security patch.
3
Identify effective solutions
Develop specific, actionable mitigations for each causal factor. Disable USB mass storage? Update AV? Upgrade Windows? Patch vulnerability? Generate a concrete list of solutions tied to specific root causes.
4
Implement and track
Push solutions through the change management process. Track implementation status per system. Then expand the scope — if a specific Windows version was the root cause, scan the whole network for other machines running that version and apply the same fix.
The most important RCA step — look beyond the single incident: The real value of RCA is network-wide remediation. Once you identify the root cause on one machine, scan the entire organisation for the same vulnerability. If 200 machines share the same unpatched Windows version, fixing just the one that was attacked leaves 199 others vulnerable to the exact same attack.
Exam
Quick Reference Cheat Sheet
Containment — 5 steps (in order)
1 Safety of personnel (people first). 2 Stop ongoing breach. 3 Identify primary vs. secondary attack (is this a decoy?). 4 Don't alert the attacker (burn-down-the-house APTs). 5 Preserve forensic evidence (last, not least). Order matters for the exam.
Isolation vs. Segmentation
Isolation = air gap (unplug cable, disable account) — total cutoff, least stealthy, least forensic value. Segmentation/sandboxing = VLAN/ACL boundary + honeypot — stealthier, preserves forensic opportunity, requires legal counsel. Both need senior leadership approval.
Sanitisation decision matrix
HDD (magnetic) → Zero-fill (format /p:1). Self-encrypting SSD → Cryptographic Erase (CE). Any SSD → Secure Erase (manufacturer software). Top Secret / highly classified → Physical destruction (shred / incinerate / degauss). Never trust a quick format — malware survives it. Reference: NIST SP 800-88.
Why zero-fill fails on SSDs
SSD wear-leveling controller distributes writes to prevent cell wear. When you zero-fill, the controller may skip recently-written cells. Data remains in unwiped cells. Use manufacturer Secure Erase software which overrides wear leveling, or Cryptographic Erase if the SSD is self-encrypting.
Eradication actions
Reconstruction = scripts restore specific files. Reimaging = bit-by-bit image restore (most thorough automated). Reconstitution = surgical 7-step manual removal when wipe isn't possible. DML (Definitive Media Library) = trusted offline source for replacement files during reconstitution.
1 Uninstall everything you aren't using. 2 Patch everything you need to keep (scan→patch→scan). 3 Restrict all users to least privilege. If in doubt on a hardening exam question — does it uninstall, patch, or restrict? If yes, it's the right answer.
Post-incident & evidence
Executive Summary = short, bullets/charts, for leadership, includes resource ask. Incident Summary Report = audience-specific versions (PR, technical, legal). Evidence Retention = minimum 6 months; prosecution = years; SOX = years. Hardware seized may not return for 2–3 years — budget for replacement.
Lessons learned
6 questions: Who / Why / When / Where / How / What. No blame — improvement only. Culture of safety. Outputs: IR Plan Updates, IOC Generation, Change Management Improvement. AAR = After-Action Report; LLR = Lessons Learned Report — same thing, different names. RCA: Define → Causal relationships → Solutions → Implement + expand network-wide.