Skip to content
FR

Incident Response and Security Investigations

Step 21 of 28

Security+ Incident Response, Digital Forensics, and Investigation Data

Introduction

This lesson covers two objectives of Domain 4, Security Operations (28% of SY0-701): objective 4.8, explaining appropriate incident response activities, and objective 4.9, using data sources to support an investigation. Security+ incident response scenarios require preparation, timely containment, reliable evidence, and a tested process that can adapt as facts change. The exam asks you to put response phases in order, choose the correct next step in a scenario, preserve evidence properly, and pick the log or tool that answers a given question.

After this lesson you will be able to run an incident from detection to lessons learned, explain how forensic evidence is collected and protected, and match investigation questions to the right data sources.

Learning objectives

After this lesson you will be able to:

  • Describe the phases of the incident response process: preparation, detection, analysis, containment, eradication, recovery, and lessons learned.
  • Distinguish incident response plans, playbooks, runbooks, and exercises such as tabletop and simulation.
  • Perform root cause analysis and explain what threat hunting adds to detection.
  • Explain digital forensics concepts: legal hold, chain of custody, acquisition, order of volatility, preservation, and reporting.
  • Identify the data sources used in investigations: logs, SIEM, packet captures, NetFlow, endpoint and vulnerability data, and automated reports.
  • Choose the right source for a question about who, what, when, where, and how.

1. The incident response process

For SY0-701, learn the following incident-handling activities and their usual flow. NIST SP 800-61 Rev. 3 (April 2025) supersedes Rev. 2 and integrates response with CSF 2.0 risk management, rather than prescribing this seven-item list as a universal sequential workflow. Activities can overlap and repeat; urgent containment and evidence preservation may proceed alongside analysis.

  1. Preparation: build the team, plan, tools, contact lists, training, and access before anything happens.
  2. Detection: notice a possible event through alerts, user reports, threat intelligence, or hunting.
  3. Analysis: confirm whether the event is a real incident, determine scope, severity, and affected assets.
  4. Containment: stop the spread and limit damage.
  5. Eradication: remove the cause, such as malware, malicious accounts, or the exploited vulnerability.
  6. Recovery: restore systems to normal operation and verify they are clean and monitored.
  7. Lessons learned: review what happened, what worked, and what to change.

An event is any observable occurrence; an incident is an event that violates or threatens policy, confidentiality, integrity, or availability. Many events, such as a failed login, are not incidents.

Preparation in detail

Preparation is the phase with the highest return. It includes:

  • A written incident response plan (IRP) approved by management that defines scope, roles, authority, severity levels, and communication rules.
  • An incident response team (IRT/CSIRT) with named roles: incident commander, analysts, forensic specialists, legal counsel, communications or public relations, human resources, and executive sponsors.
  • Communication plan: who is notified, in what order, and through which channel. Include out-of-band communication, because attackers may be reading company email and chat. Also include regulators, law enforcement, customers, and insurers according to legal and contractual duties.
  • Tools and access: jump bags, forensic workstations, write blockers, clean media, logging, backups, and pre-approved authority to isolate systems.
  • Training and exercises so the first real incident is not the first rehearsal.

Detection and analysis

Detection sources include SIEM correlation, EDR alerts, IDS and IPS, DLP, user reports, helpdesk tickets, threat intelligence feeds, third-party notifications, and threat hunting. During analysis, the team validates the alert, rules out false positives, sets a severity and priority using business impact, and begins documentation. Keep a timestamped log of every action; it supports legal action and the final report.

Containment, eradication, and recovery

Containment comes in two forms. Short-term containment stops damage immediately, for example isolating an endpoint with EDR, disabling an account, or blocking an IP address. Long-term containment keeps the business running while the environment is cleaned, for example moving users to a temporary segment. Isolation versus shutdown matters: powering off loses volatile memory, while network isolation usually preserves the opportunity to collect it. Isolation does not stop local encryption or all destructive code. Choose containment under the incident commander’s authority, balancing ongoing harm, process safety, business impact, and evidence; document unavoidable evidence loss.

Eradication removes the root cause: delete malware, patch the exploited vulnerability, remove persistence mechanisms such as scheduled tasks, rotate exposed credentials from trusted systems, revoke relevant sessions/tokens, and review authentication registrations, and rebuild from known-good images when integrity is uncertain. Recovery restores data from clean backups, returns services to production in a controlled order, and adds enhanced monitoring for signs of reinfection.

Lessons learned

Hold a post-incident review soon after, ideally within days. It is blameless in tone and asks what happened, how it was detected, how quickly the team responded, what slowed them, and what controls or procedures should change. Outputs include an updated plan, new detections, revised training, and metrics such as mean time to detect (MTTD) and mean time to respond (MTTR). This phase feeds back into preparation.

Example 1: ransomware on a file server

At 02:10 EDR flags mass file renaming on a file server. Analysts confirm encryption in progress (detection and analysis). The incident commander authorizes network isolation of the server and disables the compromised service account (short-term containment); the team keeps it powered on while assessing whether local encryption continues and collecting volatile evidence. Network isolation limits remote spread but may require additional host-level containment. Investigators find a phishing-delivered loader and a lateral-movement tool. After the loader and a scheduled-task persistence mechanism are removed, all service-account passwords are rotated and the server is rebuilt from a clean image (eradication). Data is restored from a verified clean protected backup that meets the recovery objectives, then monitored (recovery). A review finds the phishing email was reported but not triaged for 14 hours, leading to a new on-call process (lessons learned).

Coordinate restoration targets and protected backups with disaster recovery, RTO, and RPO.

2. Plans, playbooks, and exercises

Document Purpose Example
Incident response plan High-level policy: roles, authority, phases, communications Defines who can order a system isolated
Playbook Scenario-specific response steps and decision points Phishing, ransomware, lost laptop, DDoS
Runbook Detailed, often automatable operational procedure Steps to isolate an endpoint in the EDR console
Business continuity and disaster recovery plans Keep or restore operations Recovery of a data center

Exercises test the plan:

  • Tabletop exercise: a discussion-based walk-through of a scenario. Low cost, no systems touched, good for executives and cross-team coordination.
  • Simulation or functional exercise: participants perform realistic actions in a lab or a controlled production slice, such as running the playbook against a simulated alert.
  • Full-scale or red/blue/purple team exercise: realistic attack-and-defend activity. Purple teaming has attackers and defenders collaborate to improve detections.
  • Walkthrough: step-by-step review of documents for accuracy.

Exercises find gaps such as out-of-date phone numbers, unclear authority, and missing access before an attacker does.

Worked example: choosing and ordering the next step

Scenario. An analyst sees a workstation beaconing every 60 seconds to an unknown IP address. EDR shows a suspicious process created from an Office document. The host belongs to an accountant with access to payment systems. What should happen, in order?

Reasoning.

  1. Detection and analysis: confirm that the beaconing and process are malicious, check threat intelligence for the IP, and identify other hosts contacting it. Record times.
  2. Contain: isolate the workstation using EDR network containment to limit spread while preserving collection opportunities, and block the destination at the firewall. Disable or reset the accountant's credentials and tokens.
  3. Preserve evidence: capture memory and a disk image using documented procedures with chain of custody.
  4. Scope: search logs and EDR for the same hash, domain, or IP on other hosts.
  5. Eradicate and recover: rebuild the workstation, patch the Office vulnerability or tighten macro policy, and restore the user's data.
  6. Lessons learned: update detections and training.

Why the other approaches are weaker. Powering the machine off immediately loses volatile evidence. Reimaging first destroys the evidence needed for scoping and legal action. Waiting until a complete investigation is finished before containing lets the attacker keep working.

3. Root cause analysis and threat hunting

Root cause analysis (RCA) asks why an incident became possible, not merely what happened. A common technique is repeated "why" questions: the server was encrypted through a stolen service credential; reuse and excess privilege increased its impact; lifecycle controls and credential ownership were missing. Corrective action includes scoped workload identity, managed or short-lived credentials, rotation, and restrictions on interactive use. Non-human workloads generally cannot perform human MFA; protect human administrators with MFA and choose appropriate workload controls. RCA feeds lessons learned and prevents recurrence.

Threat hunting is proactive, human-led searching for threats that existing automated detections missed. It is hypothesis driven: "If an attacker used living-off-the-land tools, we should see unusual PowerShell child processes on finance servers." Hunters use threat intelligence, MITRE ATT&CK techniques, and logs from EDR and SIEM. Hunts that find activity become incidents; hunts that find gaps become new detection rules. Threat hunting assumes a breach could already exist, which differs from waiting for alerts.

Activity Trigger Output
Alert triage Automated detection fires Confirm or dismiss alert
Threat hunting Hypothesis or new intelligence New detections or discovered incident
Vulnerability scan Schedule List of weaknesses
Penetration test Authorized engagement Demonstrated exploit paths

For credential and token containment, review identity lifecycle and privileged access controls.

4. Digital forensics

Digital forensics is the collection, preservation, and analysis of electronic evidence in a way that preserves its integrity and, when needed, its admissibility in court.

Legal hold and e-discovery

A legal hold (litigation hold) instructs the organization to preserve potentially relevant data, suspending normal deletion and rotation. E-discovery is the process of identifying and producing electronically stored information for legal matters. When counsel issues a hold, retention scripts that delete mailboxes or logs must be paused for the affected custodians.

Chain of custody

Chain of custody is a documented record of who handled evidence, when, why, and where it was stored, from collection to presentation. Gaps in the chain let opposing counsel argue that evidence could have been altered. A form typically records: unique evidence ID, description, serial number, collector, date and time, hash values, each transfer with signatures, and storage location. Use sealed tamper-evident packaging for physical media and access-controlled repositories with integrity and transfer records for digital evidence.

Acquisition and integrity

  • Where feasible, acquire a bit-stream forensic image of stable storage and use a validated write blocker for offline media. Live RAM, encrypted running systems, cloud APIs, and provider snapshots require different acquisition methods; document tools, authorization, scope, and unavoidable changes.
  • Calculate and record a modern hash, such as SHA-256, for the acquired data. For stable media, compare the same byte range at source and acquisition; matching hashes strongly support integrity. A compressed evidence container has different bytes from raw storage, so verify its represented data using the format’s documented procedure. Hashes do not prove that the source was trustworthy before acquisition.
  • Work on copies and keep the original sealed.
  • Record time zones and clock offsets, since timelines depend on accurate time.

Order of volatility

Use volatility and retention risk to prioritize collection, subject to safety, authority, and tool capability. A conceptual order is:

  1. CPU registers and cache, where an available acquisition method can capture them
  2. Memory (RAM), routing tables, ARP cache, running processes, network connections
  3. Temporary files and swap space
  4. Disk and persistent storage
  5. Remote logging and monitoring data, unless short retention requires immediate parallel preservation
  6. Physical configuration and network topology
  7. Archival media and backups

RAM may contain keys, injected code, and connections lost at shutdown. When safe and feasible, prioritize live volatile data before offline disk imaging. Live collection changes system state; record those changes and use trusted tools. Preserve expiring cloud logs or telemetry in parallel rather than waiting mechanically for a seven-step sequence.

Other forensic concepts

  • Preservation protects evidence from loss or alteration, including cloud and snapshot data.
  • Provenance documents the origin and history of evidence.
  • Reporting presents findings, methods, tools, timeline, and conclusions in plain language, with enough detail to be reproducible.
  • Cloud and virtual considerations: take snapshots of virtual machines, preserve cloud audit logs, and consider jurisdiction and provider cooperation. Evidence may exist in multiple regions.
  • Admissibility depends on legal rules; follow counsel's guidance, avoid altering evidence, and document everything.
  • Strategic intelligence and counterintelligence gathering may be used to understand adversaries, but must respect law and policy.

Example 2: insider data theft

HR reports that a departing engineer may have copied proprietary designs. Counsel issues a legal hold on the engineer's mailbox and files. The security team images the laptop through a write blocker, records SHA-256 hashes, and logs the chain of custody from collection to the evidence locker. Analysis of USB logs and cloud-storage sync events shows 8 GB copied to a personal drive the night before resignation. The final report includes a timeline and the recorded hashes and acquisition details supporting the image’s integrity. Had the manager simply logged in and browsed the laptop first, timestamps would have changed and the evidence would be weakened.

5. Data sources for investigations

Investigators combine multiple sources. No single log tells the whole story.

Data source What it provides Typical question answered
Firewall logs Allowed and denied connections, ports, addresses Did the host contact the malicious IP?
IPS/IDS logs Signature and anomaly alerts Was an exploit attempt detected?
Network logs and NetFlow/IPFIX Flow metadata: who talked to whom, volume, time How much data left, and to where?
Packet captures Captured packet bytes, subject to capture length, packet loss, and encryption Which observable protocol/data was sent during the capture?
Endpoint logs and EDR Process creation, file changes, registry, user activity What did the process do on the host?
OS-specific security logs Windows Security event log, Linux auth log, syslog Who logged in, when, and from where?
Application logs Application errors, transactions, API calls Which user changed this record?
Web server and proxy logs URLs, user agents, status codes, source IPs Was a web attack attempted or successful?
DNS logs Name resolution requests Did a host look up a malware domain?
Authentication and IdP logs Sign-ins, MFA outcomes, token use Was this account used from an impossible location?
Cloud audit logs API and console activity Who changed this storage policy?
Vulnerability scan data Findings at a recorded assessment time Was a relevant weakness reported, and what evidence confirms its state at incident time?
Metadata Recorded file, mail, or photo properties; may be altered or misleading Which times/identities are claimed, and can other sources corroborate them?
Dashboards, automated reports, and alerts Summarized views and trends Is the incident growing?
Threat intelligence feeds Indicators of compromise Is this IP known malicious?

Review SIEM correlation and enterprise monitoring when selecting collection coverage and alert rules.

SIEM and log aggregation

A security information and event management (SIEM) system collects logs from many sources, normalizes them, correlates events, and produces alerts and dashboards. It enables one query to follow an attacker across firewall, endpoint, and identity logs. Correlation depends on synchronized time (NTP) and consistent log formats; without accurate time, timelines are unreliable. Logs must be protected from tampering: send them to a central, write-restricted store immediately, because attackers often delete local logs.

Packet capture versus flow data

Packet captures can retain packet content but may be truncated, sampled, incomplete, or encrypted. They can require substantial storage and support deep analysis of a defined period. NetFlow-style records store only metadata, scale for weeks or months, and are best for detecting beaconing, exfiltration volume, and lateral movement. Choose flow data to answer "who talked to whom and how much," and packet capture to answer "what exactly was in the traffic," recognizing that encrypted content will not be readable without decryption.

Worked example: matching sources to questions

Scenario. A web application stored customer data. An analyst suspects SQL injection followed by data theft last Tuesday. Which data should be reviewed?

Reasoning.

  1. Web server and WAF logs show requests with SQL syntax and the resulting HTTP status codes and response sizes; a very large response to one request suggests data extraction.
  2. Database audit logs show queries executed and rows returned under the application account.
  3. Firewall or NetFlow data show outbound transfer volume from the web server after the requests.
  4. Authentication logs confirm whether administrator accounts were used afterward.
  5. Endpoint logs on the web server show any new processes or files such as a web shell.
  6. Vulnerability scan data can identify a relevant reported flaw. Correlate with deployed versions, configuration, test evidence, and incident-time logs; the scan alone does not establish successful exploitation.

Why single-source answers are weaker. Only the firewall log shows that traffic occurred but not what the request was. Only the web log shows requests but not whether data left through another path. Corroboration from independent sources increases confidence.

6. Comparison: containment choices

Action Strength Risk
Network isolation via EDR Limits network paths and avoids immediate power loss Local destruction can continue; collection and system state still change
Power off Stops everything quickly Loses volatile evidence, may trigger destructive logic
Account disablement and token revocation Cuts off credential abuse Does not stop malware already running
Segmentation or firewall block Limits the blast radius for many hosts May disrupt business processes
Reimage Rebuilds OS from a trusted source Can destroy evidence; does not by itself resolve firmware or external persistence

7. Common pitfalls

  • Starting eradication before scoping, so persistence on other systems remains and the attacker returns.
  • Powering off or reimaging without considering volatile evidence and the need to stop ongoing damage; record why the containment choice was necessary.
  • Using the compromised network for incident communications.
  • Failing to preserve logs because retention was short or because they were stored only on the compromised host.
  • Skipping lessons learned because the incident was "resolved."
  • Treating a false-positive rate as proof that alerts can be ignored.
  • Forgetting legal, privacy, and regulatory notification requirements.
  • Confusing a tabletop exercise (discussion) with a simulation (hands-on).

8. Exam tips

  • Exam tip: Know the phase order: preparation, detection, analysis, containment, eradication, recovery, lessons learned. For a “best next step” question, use the evidence, urgency, authority, and stated objective; do not wait for exhaustive analysis before necessary containment.
  • Exam tip: Isolation before shutdown when evidence matters; collect memory before disk because of the order of volatility.
  • Exam tip: Hashes support integrity comparisons; chain of custody documents handling; a legal hold requires preservation of the scoped material. None alone guarantees admissibility or establishes every fact about an incident.
  • Exam tip: If a question asks about the document with scenario-specific steps, choose playbook; if it asks for high-level authority and roles, choose the incident response plan.
  • Exam tip: NetFlow answers "how much and with whom"; packet capture answers "what was inside."
  • Exam tip: Threat hunting is proactive and hypothesis driven; it is not just reviewing alerts.

9. Mini case study

Situation. A regional retailer's SIEM alerts that a service account logged in from two countries within ten minutes. The account is used by a point-of-sale update server. EDR on that server shows a new PowerShell process contacting an unfamiliar domain. DNS logs show the same domain requested by two other servers. The incident manager must decide what to do with a 3 a.m. alert, a tight sales season, and a legal team asking about data exposure.

Questions.

  1. What is the first set of actions?
  2. Which data sources confirm scope?
  3. What evidence steps are required?
  4. What should the lessons-learned review examine?

Commented solution.

  1. Validate the sign-in, workload origin, and process/network evidence. A service may legitimately run from several regions, and a DNS lookup does not prove infection. Escalate promptly; contain hosts with sufficiently strong evidence through an approved coordinated action, considering point-of-sale dependencies and local destructive activity. Restrict the compromised workload credential, revoke supported tokens, and block the confirmed malicious domain where effective. Notify the incident commander and legal per the communication plan using an out-of-band channel.
  2. Use DNS logs and EDR to find all hosts that resolved or contacted the domain; authentication logs to trace every use of the account; NetFlow and firewall logs to measure outbound data; POS application and database logs to see whether payment data was accessed; vulnerability findings and incident-time version/configuration evidence to test possible entry paths, without assuming a scan proves the cause.
  3. Have authorized responders prioritize volatile host data and expiring remote logs, then acquire appropriate disk/cloud evidence with integrity and custody records. Use write blockers for suitable offline media, not as a universal live/cloud step. Coordinate any scoped legal hold and preservation notice with counsel.
  4. Review whether workload credentials were scoped to intended hosts/resources, why the servers shared a long-lived credential, and whether human administrators used MFA, how long detection took, and whether the playbook for compromised service accounts existed. Assign owners and dates for each improvement. Update the playbook and run a tabletop in the next quarter.

Key terms

  • Incident: an event that threatens security objectives or policy.
  • IRP / playbook / runbook: the plan, scenario-specific steps, and detailed procedure.
  • Containment, eradication, recovery: stop the spread, remove the cause, restore service.
  • Tabletop exercise: discussion-based rehearsal.
  • Root cause analysis: finding the underlying cause to prevent recurrence.
  • Threat hunting: proactive, hypothesis-driven search for undetected threats.
  • Legal hold: order to preserve potentially relevant data.
  • Chain of custody: documented handling history of evidence.
  • Order of volatility: collecting the most perishable data first.
  • Write blocker: device preventing writes to evidence media.
  • SIEM: platform that aggregates and correlates logs.
  • NetFlow: network flow metadata.
  • MTTD / MTTR: mean time to detect and to respond.

Summary checklist

  • I can list the incident response phases in order and describe each.
  • I can distinguish an IRP, playbook, and runbook, and tabletop from simulation.
  • I can explain root cause analysis and threat hunting.
  • I can describe legal hold, chain of custody, hashing, write blockers, and the order of volatility.
  • I can choose between isolation and shutdown and justify it.
  • I can match investigation questions to logs, SIEM, NetFlow, packet capture, and endpoint data.
  • I can explain why time synchronization and protected log storage matter.

Sources