Objective 4.8: Explain appropriate incident response activities

Cert: CompTIA Security+ (SY0-701) Domain: 4.0 Security Operations Weight: ~28% of SY0-701 (Domain 4 total) Depth: Explain. Be able to read a scenario about an incident, name the phase the team is in, recommend the correct next action, and explain why evidence preservation matters.

What this objective tests

You should be able to name the seven phases of incident response (preparation, detection, analysis, containment, eradication, recovery, lessons learned), differentiate short-term from long-term containment, rank testing methods by realism (tabletop vs simulation), define root cause analysis and threat hunting, and name and explain the six digital forensic concepts (legal hold, chain of custody, acquisition, reporting, preservation, e-discovery). The exam likes scenario questions that hand you an incident in progress and ask which phase the team is in or what the correct next action is. Get the phase right and the answer usually follows.

This is the operational center of Domain 4. SP-4.4 (Alerting and monitoring) feeds incidents to this process. SP-4.7 (Automation and orchestration) runs the playbook this lesson describes. SP-4.9 (Data sources to support an investigation) provides the evidence this lesson preserves. SP-3.4 (Resilience and recovery) supplies the recovery infrastructure that comes online during phase 5. Read SP-4.8 as the seam where every other Domain 4 objective meets the keyboard.

Key facts

The seven teaching steps (NIST SP 800-61 Rev 2 defines four phases)

NIST SP 800-61 Rev 2 is the canonical reference for incident handling. It lists four high-level phases that the field has long broken out into seven for teaching. SANS publishes the same idea as PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned), combining detection and analysis into a single "identification" step. The phases are not strictly linear in real incidents. Teams bounce between containment and eradication, sometimes loop back to analysis when new evidence surfaces, and always close with lessons learned.

A few mechanical points the exam likes to test. Do not power off compromised hosts unless safety requires it: memory holds evidence that vanishes on power-off. Containment buys time, not a fix. Eradication includes credential rotation and patching the exploited weakness, not just wiping the host. Recovery is declared closed when leadership signs off, not when the host is up. Lessons learned belong on a calendar before the bridge closes, not as a vague "we will get to it."

Training and testing

Training is the bridge between the plan on paper and the team in the room at 2 AM. Every IR team member should know the plan, know their role, and know who else is in the room. New hires walk the plan in their first 30 days. Senior IR staff own the playbooks and the tabletop cadence.

Testing proves the plan works. Two methods anchor this objective.

Tabletops are cheap and find planning gaps: stale call trees, unclear decision rights, unknown escalation paths, missing legal counsel triggers. Simulations are formative and find tool and coordination gaps: alert fatigue, slow EDR response, missing log sources, unclear playbook steps under realistic load. Both are required. Most organizations over-index on tabletops and under-index on simulations.

A note on the SP-3.4 testing methods (parallel processing and fail over). Those test recovery infrastructure, not IR process. They share vocabulary but the audience is different. SP-3.4 tests the architecture's ability to come back. SP-4.8 tests the team's ability to respond.

Root cause analysis (RCA)

RCA is the discipline of finding the underlying cause of an incident, not just the surface symptom. The 5 Whys is the simplest technique. Ask why the incident happened. Ask why again of the answer. Keep asking until you reach a system rather than a person.

A worked example. A ransomware encryption hit a finance workstation. Why? The user clicked a malicious link and entered credentials. Why did the link reach the user? The mail filter did not flag it. Why did the mail filter miss it? The sender domain was newly registered and not on any blocklist. Why was a brand-new sender allowed to deliver a credential-prompt link? Inbound mail does not sandbox attachments or detonate suspicious URLs. Why does inbound mail not sandbox? Sandboxing was descoped during the last budget cycle. The first "why" blames a user. The fifth "why" surfaces an architecture choice. Good RCA changes the architecture. Bad RCA blames the user.

Other RCA techniques exist (Ishikawa fishbone diagrams, fault-tree analysis, Apollo RCA) but 5 Whys is the technique most likely to appear on the exam and the technique most accessible to a junior SOC analyst.

Threat hunting

Threat hunting is the proactive cousin of reactive IR. Reactive IR responds to alerts. Threat hunting forms a hypothesis about adversary behavior and searches the environment for evidence of it before any alert fires. A mature SOC alternates between reactive IR and proactive hunting.

Hunts have four common shapes.

• Hypothesis-driven. "An attacker who got past our perimeter would try to dump credentials." Search for the techniques credential dumpers use.
• Intel-informed. A vendor advisory describes a new variant using specific IOCs and techniques. Search your environment for those.
• Anomaly-driven. Watch for behavior that deviates from baseline. New service accounts running interactive logins. Mass file access at 3 AM.
• Crown-jewel-driven. Start from the most valuable assets and walk outward. Who has accessed the EMR database in the past 30 days from new endpoints.

MITRE ATT&CK is the common map. ATT&CK catalogs adversary tactics (the why) and techniques (the how) observed in the wild. A hunt named "T1003 credential dumping" maps to a specific ATT&CK technique, which gives the SOC analyst a known set of indicators and detection logic to look for. Hunts are time-bounded (a hunt has a start and an end), data-driven (SIEM, EDR, packet captures), and documented (findings feed back into detections).

Digital forensics: six concepts

Forensics is the discipline of collecting and analyzing evidence so it stands up to scrutiny. SP-4.8 lists six forensic concepts every SOC analyst should recognize.

A few mechanical points. Order of volatility matters during acquisition. Memory and running processes vanish on power-off, so capture them first when possible. Disk images come next. Log copies and cloud snapshots come after. Hash everything (SHA-256 is the modern default) and record the hash. A write blocker is a hardware or software tool that allows reading a storage device but blocks any writes. Without it, the act of plugging in the drive may alter the evidence and contaminate the chain of custody.

NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response) is the canonical reference here. Read it as the forensics companion to SP 800-61's IR process.

The IR playbook

The playbook is the artifact that ties the seven phases to a specific incident type. A phishing playbook reads differently from a ransomware playbook reads differently from a lost-device playbook, but they all share the spine.

A phishing playbook in plain English:

1. Detect. SIEM rule fires on the reported sender or the user files a ticket.
2. Contain. Block the sender at the mail gateway. Remove the message from every mailbox (mailbox search-and-purge). Isolate any host where the user clicked.
3. Eradicate. Reset credentials for any user who entered them. Revoke active sessions and refresh tokens. Hunt for follow-on activity from the same sender, the same domain, the same IOCs.
4. Recover. Release hosts from isolation after EDR scan confirms clean. Restore mail service normalcy.
5. Document. Timeline, IOCs, MITRE ATT&CK mapping, RCA, lessons learned.

SOAR platforms (Security Orchestration, Automation, and Response, from SP-4.7) run playbooks automatically for the steps that can be safely automated. Block-at-gateway is a great fit for automation. Force-credential-rotation usually requires human approval because the blast radius of a wrong call is real. The pattern is automate the deterministic steps, keep human approval on the destructive ones.

Common gotchas

• Wiping the host first destroys evidence. The instinct to "just reimage it and move on" feels productive but burns down memory, disk artifacts, and the ability to scope the incident. Contain, preserve, then eradicate.
• Powering off compromised hosts loses memory evidence. Memory holds running processes, network sessions, and unencrypted strings. Use EDR isolation instead of a power button.
• Containment without analysis can scope wrong. Containing one host while ten others are still talking to the attacker buys nothing. Analysis sets the right scope.
• Plugging a seized device into a workstation contaminates evidence. Use a write blocker. Image first. Work from the copy.
• Chain of custody breaks during fast incidents. Document every handoff even when the timer is running. Hour-six incidents become month-six legal cases.
• Skipping the lessons-learned review is the most common IR mistake. The PIR is what turns one bad day into a stronger program. Schedule it on the bridge, before anyone leaves.
• Tabletops are not simulations. Tabletops find planning gaps. Simulations find tool and coordination gaps. Both are required.
• RCA that stops at "the user clicked the link" is not RCA. Keep asking why. The fifth why is usually an architecture decision.
• Threat hunting without time bounds is open-ended drift. Hunts have a start, an end, and a documented finding.
• An IR playbook without a SOAR platform is a manual playbook. That is fine for small teams. As volume grows, the playbook needs an engine.

Real-world context

In a SOC Tier 1 seat, IR shows up every shift. Most alerts are not incidents. Triage means deciding which alerts are real, which need a playbook run, and which need to escalate. The Tier 1 analyst opens the ticket, runs the early phases of the relevant playbook, and hands off to Tier 2 when the incident gets larger than one host or one user. The Tier 1 analyst is also the most reliable detector for user-reported phishing: the user sends the suspicious mail, the Tier 1 analyst confirms it is malicious, and the playbook runs.

In a SOC Tier 2 seat, the work shifts to containment and eradication. Tier 2 owns the technical decisions: which credentials need rotating, which hosts need reimaging, which detections need tuning. Tier 2 also leads the threat hunts that find adversary activity before alerts catch it.

In an IR lead seat, the work is the bridge. The IR lead runs the incident bridge, communicates with leadership, owns evidence preservation and legal hold, drives the PIR, and is accountable for the lessons learned. IR leads tend to come up through Tier 2 or through specialist consulting (the IR firm that gets called in for major incidents).

Cyber insurance underwriters now read IR maturity directly. Underwriting questionnaires include IR plan presence and last update, tabletop cadence, simulation cadence, IR team roster, outside counsel relationship, SOAR platform presence, and last real-incident retrospective. Premiums move with these numbers. A small business that cannot demonstrate a tested IR plan is increasingly uninsurable at any price.

Regulators look at the same evidence. HIPAA breach notification, PCI DSS incident handling requirements, GDPR breach reporting, state breach notification laws, and SEC cyber disclosure rules all assume an organization has a working IR capability. The exam may not test the regulatory specifics, but the SOC seat lives inside those requirements every day.

Sources

• CompTIA Security+ SY0-701 Exam Objectives, Section 4.8
• NIST SP 800-61 Rev 2 Computer Security Incident Handling Guide
• NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• NIST SP 800-184 Guide for Cybersecurity Event Recovery
• NIST Cybersecurity Framework (CSF) 2.0 Respond (RS.RP, RS.CO, RS.AN, RS.MI, RS.IM) and Recover (RC.RP, RC.IM, RC.CO) functions
• SANS PICERL incident-handling model (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned)
• MITRE ATT&CK Framework (adversary tactics and techniques)
• ISO/IEC 27035:2023 Information Security Incident Management
• CIS Critical Security Controls v8 (especially Control 17 Incident Response Management)