Incident Planning — Flashcards

Tabletop exercise: a structured discussion where IR team members walk through a hypothetical security scenario verbally, making decisions without touching any live systems. Tests: plans (are procedures documented and understood?), communication (who notifies whom and how?), roles (does everyone know their responsibilities?), escalation (when and to whom do decisions escalate?). Does NOT test: technical skills, tool familiarity, or whether systems actually work as expected. Low cost; typically a few hours; suitable for executives and management. Findings must be documented and addressed after each exercise.

Incidents move fast: alerts fire, stakeholders demand answers, and systems may be actively compromised simultaneously. The first time a responder encounters a procedure cannot be during a live event. Exercising converts written procedures into practiced capability. Key principle: an incident is not a training event. A team learning to respond while an attacker is active gives the attacker a critical advantage. Tabletops, simulations, and red team exercises at different cost levels all build the muscle memory and role clarity needed for effective real-world response. A team that has never exercised will improvise during incidents, creating inconsistent and often incomplete responses.

Simulation: a training exercise where participants execute actual response procedures against a realistic scenario in a test environment (or live environment for maximum fidelity). Unlike tabletops, simulations use real systems and real tools. What simulations reveal that tabletops do not: technical gaps (tools that do not work as expected), credential issues (missing access during response), response speed (how long procedures actually take under pressure). Cost: moderate (requires infrastructure). Most realistic simulation type: red team / purple team exercises against production-equivalent environments. Simulations should follow tabletops in the training progression.

Phishing simulation: realistic phishing emails sent to real users; results are measured. Simultaneously tests: (1) Human behavior — click rate, credential submission rate, and report-to-security rate measure security awareness training effectiveness. (2) Technical controls — whether email filters, URL reputation checks, sandbox detonation, and attachment scanning detect and quarantine the message. A single simulation revealing high click rates AND filter bypass exposes two independent failures. Both must be addressed separately: training for users, tuning for filters. Key insight: a simulation that everyone passes and all filters block teaches nothing — realistic lures must be used.

Root cause analysis (RCA): a structured post-incident process for identifying why an incident occurred — not just what happened. Core methodology: ask "why" repeatedly. Example: "The firewall was misconfigured" → Why? "The change was not reviewed." → Why? "The review process was bypassed under time pressure." → Root cause: change management process failure. RCA requirements: fact-based conclusions (grounded in logs, forensic evidence, not assumptions), blame-free focus (mistakes happen; RCA asks why systems allowed a mistake to cause harm, not who made the mistake), and multiple root causes (complex incidents typically have several contributing causes that must all be addressed).

Tunnel vision: a cognitive bias in RCA where investigators fixate on the most obvious cause and stop asking why. The most obvious cause is usually a proximate cause (the immediate trigger), not the root cause (the underlying systemic failure). Example: "The attacker got in through an unpatched system" is a proximate cause. Stopping there leads to patching that one system. The root cause might be a broken patch management process that leaves hundreds of systems unpatched. Fixing only the proximate cause means the same root cause will produce a different incident through a different path. Systematic RCA requires asking why until no further productive why can be answered.

Blame-free requirement: Mistakes happen in every environment. If RCA produces blame rather than systemic findings, a culture of concealment develops: people hide mistakes rather than reporting them. Unreported mistakes cannot be fixed. Well-designed systems must tolerate individual human errors without catastrophic outcomes. If a single mistake causes a breach, the system lacked sufficient resilience — that is the finding. Fact-based requirement: Conclusions based on assumptions rather than evidence from logs, forensic artifacts, and documentation produce recommendations that address the assumed cause, not the actual cause. The fix is applied to the wrong problem and the actual vulnerability remains. Both requirements are necessary for RCA to produce actionable improvements.

Threat hunting: a proactive security discipline where analysts search for evidence of compromise or malicious activity that has not yet triggered any alert. Traditional monitoring: reactive — an alert fires when a known signature matches or a threshold is crossed, then responders react. Traditional monitoring only detects known-bad patterns. Threat hunting: proactive — hunters hypothesize how an attack technique would manifest, then actively search for that pattern using SIEM, EDR, and behavioral analytics. Threat hunting discovers sophisticated attacks that deliberately operate below detection thresholds. Key relationship: threat intelligence (reactive) provides IOCs and hypotheses; threat hunting (proactive) searches for threats that intelligence has not yet characterized.

SIEM: centralized log aggregation with ad-hoc query capability; hunters search historical data across all log sources. EDR (Endpoint Detection and Response): deep endpoint telemetry including process trees, file writes, registry changes, and network connections per process — essential for detecting living-off-the-land techniques. Behavioral analytics / UBA: baselines normal user and system behavior; flags deviations (unusual login times, new lateral movement paths, atypical data access). Network flow data (NetFlow/IPFIX): identifies unusual data volumes, unexpected connections between systems, lateral movement patterns. Threat intelligence feeds: provide IOCs and TTPs (Tactics, Techniques, and Procedures) to guide hypothesis formation for each hunt.

Threat hunting is inherently adversarial. As defenders develop new hunting techniques and detection rules, sophisticated attackers adapt to avoid those specific detections. This creates a continuous cycle: hunters find a technique → attackers find a new hiding place → hunters adapt → repeat. This cycle cannot be won permanently; it must be maintained continuously. Organizations that stop hunting give attackers time to establish and maintain footholds without triggering alerts. The best hunts produce: (1) confirmation of compromise or confirmed absence, (2) new automated detection rules derived from the hunt methodology, and (3) improved understanding of normal environment behavior. Both outcomes — finding something and finding nothing — have value.

Reactive gap: security intelligence (threat feeds, SIEM rules, IPS signatures) is inherently backward-looking. It detects what has already been characterized as malicious. It will not detect: new techniques not yet in any threat feed, attackers using legitimate tools (living-off-the-land), activity carefully calibrated to stay below thresholds, and novel malware without matching signatures. Sophisticated attackers study detection capabilities and deliberately operate in the gap between detection and normal behavior. An organization relying exclusively on reactive detection will not find advanced intrusions until significant damage has occurred. Threat hunting fills this gap by actively searching for anomalies that have not been characterized as malicious yet — finding attacks in progress rather than post-incident.