Explain appropriate incident response activities

Incident response is the structured approach to handling security incidents — from detection through recovery and lessons learned. The exam tests the phases, the order, and the decisions within each phase.

Incident Response Process

1. Preparation

Everything before an incident occurs. The most important phase — determines how effective the rest will be.

• IRIncident Response — Structured approach to handling security incidents plan: Documented procedures for detection, analysis, containment, eradication, and recovery
• IRIncident Response — Structured approach to handling security incidents team: Defined roles — incident commander, analysts, communications lead, legal liaison, management
• Communication plan: Who is notified, when, and through what channels (internal and external)
• Tools and access: Forensic tools staged, network diagrams current, credentials for critical systems accessible to IRIncident Response — Structured approach to handling security incidents team
• Training and exercises: Tabletop exercises, simulated incidents, red team/blue team drills
• Contact lists: Legal counsel, law enforcement, insurance provider, PR, affected third parties

2. Detection and Analysis

Identifying that an incident is occurring and determining its nature and scope.

Detection sources:

• SIEMSecurity Information and Event Management — Centralized log collection, correlation, and alerting alerts, EDREndpoint Detection and Response — Monitors endpoints for threats and enables response notifications, IDSIntrusion Detection System — Monitors and alerts on suspicious activity (passive)/IPSIntrusion Prevention System — Detects and blocks suspicious activity (inline) alerts
• User reports (suspicious email, unusual system behavior)
• External notification (vendor, law enforcement, threat intel)
• Anomaly detection (behavioral analytics, impossible travel)

Analysis activities:

• Triage: Determine if the alert is a true positive or false positive
• Scoping: Identify affected systems, accounts, and data
• Classification: Categorize the incident (malware, unauthorized access, data breach, DoSDenial of Service — Attack making a resource unavailable, insider threat)
• Severity assignment: Based on impact and scope — drives response urgency and resources

3. Containment

Stop the incident from spreading while preserving evidence for investigation.

Short-term containment:

• Isolate affected systems from the network (but don’t power off — preserve volatile evidence)
• Block attacker IPInternet Protocol — Network layer addressing and routing addresses at the firewall
• Disable compromised accounts
• Redirect DNSDomain Name System — Port 53 (UDP/TCP). Resolves domain names to IP addresses for compromised domains

Long-term containment:

• Rebuild compromised systems from clean images on isolated network
• Apply patches that address the exploited vulnerability
• Enhance monitoring on affected systems and adjacent assets

Key decision: Containment must balance speed (stop the spread) with evidence preservation (don’t destroy forensic data). Pulling the network cable preserves disk evidence but loses volatile memory data.

4. Eradication

Remove the threat completely from the environment.

• Remove malware, backdoors, rootkits from all affected systems
• Identify and close the initial attack vector (patched vulnerability, disabled phishing vector)
• Reset all potentially compromised credentials
• Verify: Scan for persistence mechanisms — attackers install multiple backdoors expecting you’ll miss one

5. Recovery

Restore affected systems to normal operations.

• Restore from known-good backups (verify backup integrity first)
• Rebuild systems from clean images where necessary
• Gradually reintroduce systems to production with enhanced monitoring
• Validation: Monitor restored systems closely for signs of reinfection
• Confirm all business functions are operational

6. Post-Incident Activity (Lessons Learned)

After the incident is resolved — arguably the most valuable phase.

• Post-incident review: What happened, when, how was it detected, how was it contained?
• Root cause analysis: What was the underlying vulnerability/failure that enabled the incident?
• What worked: Effective detections, fast containment decisions, good communication
• What didn’t: Missed detections, slow response, communication gaps, missing procedures
• Recommendations: Specific, actionable improvements to prevent recurrence
• Documentation: Full incident report including timeline, actions taken, and outcomes
• IRIncident Response — Structured approach to handling security incidents plan updates: Incorporate lessons learned into procedures

Root Cause Analysis Methodology

Five Whys: Keep asking “why?” until you reach the root cause, not just the symptom.

Example:

1. Why did the breach occur? → Attacker exploited an unpatched vulnerability.
2. Why was the system unpatched? → The patch wasn’t applied during the last cycle.
3. Why wasn’t it applied? → The system wasn’t in the patch management inventory.
4. Why wasn’t it inventoried? → It was provisioned outside the standard process.
5. Why was it provisioned outside the process? → No guardrails prevent shadow ITInformation Technology — Broad term for computing infrastructure and services provisioning.

Root cause: lack of provisioning controls, not the missing patch.

Causal chain / fault tree analysis: Map all contributing factors visually. An incident rarely has a single root cause — it’s usually a chain: missing control + misconfiguration + human error + detection gap.

Exercises

Tabletop vs. Simulation

Exercise Type	Format	Participants	Systems Affected	Purpose
Tabletop	Discussion-based. Walk through a scenario verbally.	IRIncident Response — Structured approach to handling security incidents team, management, legal, comms	None — no actual systems tested	Validate IRIncident Response — Structured approach to handling security incidents plan, identify gaps in procedures, practice communication and decision-making
Simulation (functional)	Hands-on. Inject realistic events into systems.	IRIncident Response — Structured approach to handling security incidents team, SOC analysts	Test/staging (ideally), possibly production monitoring	Test actual detection and response capabilities, measure response times, validate tool integrations
Full-scale	Live exercise with real-world conditions. Red team vs. blue team.	Full organization	Production (controlled)	Most realistic test. Validates the entire response chain from detection to recovery.

Exam tip: Tabletop = talk through it. Simulation = do it. Full-scale = do it for real. Tabletop is cheapest and least disruptive, full-scale is most expensive and most realistic. Organizations should do tabletops frequently (quarterly) and simulations/full-scale less often (annually).

Threat Hunting

Proactive searching for threats that evade existing detection — not waiting for alerts.

How It Differs from Monitoring

• Monitoring: Reactive. Wait for SIEMSecurity Information and Event Management — Centralized log collection, correlation, and alerting/EDREndpoint Detection and Response — Monitors endpoints for threats and enables response to alert on known patterns.
• Threat hunting: Proactive. Hypothesis-driven investigation looking for unknown threats. “An attacker who compromised our VPNVirtual Private Network — Encrypted tunnel over public networks would do X — let’s look for evidence of X.”

Threat Hunting Process

1. Hypothesis: Based on threat intelligence, industry trends, or intuition. “APT group Y is targeting our sector using technique Z.”
2. Data collection: Gather relevant logs, network data, endpoint telemetry for the scope being investigated.
3. Investigation: Search for indicators consistent with the hypothesis — anomalous patterns, unexpected connections, suspicious processes.
4. Resolution: Either confirm a threat (escalate to IRIncident Response — Structured approach to handling security incidents) or disprove the hypothesis (document findings, refine future hunts).

Where Threat Hunting Fits in IR

• It’s a preparation and detection activity — it improves detection before incidents are declared
• Successful hunts that find threats transition directly into the IRIncident Response — Structured approach to handling security incidents process
• Hunt findings drive new SIEMSecurity Information and Event Management — Centralized log collection, correlation, and alerting correlation rules and EDREndpoint Detection and Response — Monitors endpoints for threats and enables response detections (turning manual hunts into automated detection)

Digital Forensics

Legal Hold

When litigation is anticipated, the organization has a legal obligation to preserve all potentially relevant evidence.

• Trigger: Lawsuit filed, regulatory investigation initiated, or litigation reasonably anticipated
• Scope: All data that could be relevant — emails, documents, logs, backups, chat messages, voicemails
• What it means: Normal data retention/deletion schedules are suspended for in-scope data. Auto-delete policies, mailbox cleanups, and log rotation must be paused.
• Notification: Custodians (people who hold relevant data) are formally notified of their preservation obligation
• Duration: Until legal counsel lifts the hold (could be years)
• Failure to preserve: Spoliation — intentional or negligent destruction of evidence. Can result in adverse inference (court assumes the destroyed evidence was unfavorable), sanctions, or case dismissal.

E-Discovery

The process of identifying, collecting, and producing electronically stored information (ESI) for legal proceedings.

E-Discovery Reference Model (EDRM) phases:

1. Identification: Determine what data exists and where
2. Preservation: Legal hold implementation
3. Collection: Gather data in a forensically sound manner
4. Processing: Reduce data volume (de-duplication, filtering by date/custodian/keyword)
5. Review: Attorneys review for relevance and privilege
6. Production: Deliver relevant documents in agreed-upon format
7. Presentation: Use in depositions, hearings, or trial

Security implications: E-discovery requires broad access to data stores — this conflicts with least privilege. Balance legal requirements with security controls. Use dedicated e-discovery tools with full audit logging.

Write-Blockers

Hardware or software devices that prevent writing to storage media during forensic acquisition.

• Why: Accessing a drive normally can modify metadata (last accessed timestamps) which alters evidence
• Hardware write-blocker: Physical device between the forensic workstation and the evidence drive. Most reliable — no software bugs.
• Software write-blocker: OSOperating System — System software managing hardware and applications-level or tool-level block. Convenient but less trusted in court.
• Exam tip: Write-blockers are mandatory for forensic imaging. Without one, the defense can argue the evidence was tampered with.

Forensic Imaging and Reporting

Imaging:

• Bit-for-bit (sector-level) copy of the entire drive, including slack space, unallocated space, and deleted files
• Tools: FTK Imager, dd, Guymager
• Hash the original drive before imaging (SHASecure Hash Algorithm — Family of hash functions (SHA-1, SHA-256, SHA-3)-256). Hash the image after. They must match.
• Create two copies: one working copy, one sealed archive

Forensic Report:

• Executive summary: What happened, when, scope of impact
• Methodology: Tools used, procedures followed, chain of custody
• Timeline: Chronological sequence of events reconstructed from evidence
• Findings: Detailed technical findings with supporting evidence
• Conclusions: What the evidence shows (and doesn’t show — stay objective)
• Must be written to be understandable by non-technical audiences (attorneys, judges, juries)

Expert testimony: Forensic examiners may be called to testify about their findings. The report and methodology must be defensible under cross-examination. Following established procedures (NISTNational Institute of Standards and Technology — US standards body, publishes CSF and SP 800 series 800-86, SWGDE guidelines) strengthens credibility.

Incident Types and Classification

Type	Examples
Malware	Ransomware, trojans, worms, rootkits
Unauthorized access	Compromised credentials, brute force, privilege escalation
Data breach	Exfiltration, accidental exposure, unauthorized disclosure
Denial of service	DDoSDistributed Denial of Service — Attack overwhelming target from multiple sources, resource exhaustion, application-layer attacks
Insider threat	Data theft, sabotage, policy violations
Social engineering	Successful phishing, pretexting, BECBusiness Email Compromise — Impersonating executives to authorize fraudulent transfers

Communication During Incidents

Internal Communication

• Incident commander coordinates all activities
• Regular status updates to management and stakeholders
• Secure communication channel (don’t use potentially compromised systems)

External Communication

• Legal counsel: Before any external disclosure — legal drives timing and content
• Regulators: Required by law for many incident types (GDPRGeneral Data Protection Regulation — EU data privacy regulation 72-hour notification, HIPAAHealth Insurance Portability and Accountability Act — US healthcare data protection law breach notification)
• Customers/affected parties: Notification of data breaches as required by law
• Law enforcement: For criminal activity (ransomware, fraud, espionage)
• Media: Through PR/communications team only. Controlled messaging.

What NOT to Communicate

• Technical details that could help the attacker (during active incident)
• Speculation about attribution before investigation is complete
• Information that could increase legal liability without counsel review

Evidence Handling

Order of Volatility

Collect the most volatile evidence first — it disappears when power is lost:

1. CPUCentral Processing Unit — Main processor in a computer registers, cache (milliseconds)
2. RAMRandom Access Memory — Volatile system memory contents (lost on power-off)
3. Network connections, running processes (change constantly)
4. Disk (temporary files, swap) (may be overwritten)
5. Disk (persistent data) (stable until overwritten)
6. Remote logging, monitoring data (may be on retention schedule)
7. Physical evidence, archival media (most stable)

Chain of Custody

Documented record of who handled evidence, when, and what they did with it.

• Required for evidence to be admissible in legal proceedings
• Any break in chain of custody may invalidate the evidence

Forensic Imaging

• Create bit-for-bit copies of drives using write-blockers
• Hash original and copy to verify integrity (SHASecure Hash Algorithm — Family of hash functions (SHA-1, SHA-256, SHA-3)-256)
• Work on the copy, preserve the original

Offensive Context

Incident response is the defensive endgame — it’s what happens when all preventive and detective controls have either failed or succeeded in detecting the breach. Understanding the attacker’s post-exploitation playbook (persistence mechanisms, lateral movement, data staging, exfiltration) directly informs your containment and eradication phases. Attackers who anticipate IRIncident Response — Structured approach to handling security incidents will pre-stage multiple persistence mechanisms, time their exfiltration to avoid business-hours monitoring, and attempt to compromise the IRIncident Response — Structured approach to handling security incidents team’s communication channels. The assume-breach model means your IRIncident Response — Structured approach to handling security incidents plan should account for the possibility that the attacker is watching your response.