Incident Response — Interview Q&A
Q: Why must evidence preservation happen before containment, and what's a concrete example of what's lost if that order is reversed?
A: Memory is volatile — it's lost the moment a host is powered off, and can be meaningfully altered by containment actions themselves, like killing a process or disconnecting the network. A concrete example: fileless malware may exist only in memory with minimal or no disk artifacts — if a host is isolated or rebooted before a memory dump is captured, that evidence is permanently gone, and the investigation loses the ability to determine exactly what the attacker's malware was actually doing. The correct order is capturing volatile evidence (memory, active network connections) first, then containing — reversing it under pressure is a common, real mistake worth explicitly guarding against in a runbook.
Q: What's chain of custody, and why does it matter even for an incident that seems unlikely to end up in litigation?
A: It's the documented record of exactly who collected a piece of evidence, when, how, and every subsequent access to it — collector name, timestamp, collection method, a hash at time of collection, and a log of every later access. It matters even for incidents that don't seem headed toward litigation because the decision to pursue legal action or notify regulators often comes later, after evidence handling is already complete — evidence collected without a chain of custody from the start can't be retroactively fixed once that decision is made, so treating chain of custody as standard practice for every incident, not just ones that seem likely to become legal matters, is the only way to avoid that gap.
Q: How would you design a SIEM correlation rule to reduce false positives, using a concrete example?
A: Combine multiple individually weak signals into one higher-confidence alert rather than alerting on any single event alone. A single failed login is weak, low-confidence signal — could just be a mistyped password. Multiple failed logins followed by a successful login from a different IP than the account's usual pattern is a meaningfully stronger, more specific signal of credential compromise. Correlation rules built this way — requiring a combination of signals, not a single event — are what actually reduces alert fatigue, since analysts learn to trust and investigate well-correlated alerts far more reliably than a flood of raw single-event alerts they've learned to mostly ignore.
Q: What's the difference between incident response and threat hunting?
A: IR is fundamentally reactive — responding to an alert that's already fired. Threat hunting is proactive — actively searching for signs of compromise that haven't triggered any existing alert, working from a specific hypothesis rather than a triggered signature. This matters specifically for catching living-off-the-land techniques, where an attacker uses entirely legitimate system tools (PowerShell, scheduled tasks) in a way that won't match any signature looking for known-malicious files, but a hypothesis-driven hunt looking for anomalous use of legitimate tools can surface. Mature security teams run both — reactive IR for what's already alerted, and regular proactive threat hunting assuming some level of undetected compromise might already exist.
Q: How would you design SOAR automation for incident response without it taking a dangerous automated action on a false positive?
A: Automate only actions that are well-understood, safe, and reversible even if the triggering alert turns out to be wrong — forcing a password reset, revoking active sessions, quarantining a suspicious email are all low-risk to execute automatically. Route anything higher-risk or requiring genuine judgment — permanently disabling an account, notifying customers, engaging legal — to a human analyst, but with as much context as possible already gathered and presented by the automation. The value of SOAR is speed on the safe, mechanical steps; auto-executing an irreversible action on an unconfirmed alert risks the automation itself causing real harm faster than a human ever would have.
Q: Why would you track MTTD/MTTR per incident type rather than as one blended organization-wide average?
A: A single blended average can mask a genuinely severe detection gap in one specific attack category — insider threats, for instance, are notoriously harder to detect than external network intrusions, and strong detection performance against common external attacks can hide a much worse MTTD for insider threats within one combined number. Tracking metrics separately by incident type and by which specific detection source actually caught it makes gaps visible and actionable — investigating outliers (an incident with unusually long dwell time relative to the typical average) is where the real, specific improvement opportunities are, not in the blended number.
Q: A ransomware incident is discovered, and the team goes to restore from backup — what has to be verified first, and why?
A: Backup integrity and a confirmed clean scan, before restoring anything — online, continuously-connected backups reachable by the same compromised network the ransomware spread across may themselves be encrypted or compromised, not a safe recovery point. Restoring from a backup that's silently also infected can reintroduce the exact same incident immediately after what looked like a successful recovery. This is the direct, practical argument for maintaining offline or immutable backups as a deliberate architectural decision made before an incident — an organization that only discovers its backups are compromised during an active ransomware incident is in a substantially worse position than one with a verified, isolated offline backup already in place.