Incident Response Architecture

What it is

Incident response (IR) architecture encompasses the systems, processes, and runbooks that enable an organisation to effectively detect, contain, eradicate, and recover from security incidents. The NIST SP 800-61 lifecycle defines six phases: Preparation (runbooks, tooling, training, contact lists), Detection & Analysis (SIEM alerts, anomaly detection, threat intelligence correlation), Containment (short-term isolation, then long-term containment), Eradication (removing threat actor tooling, patching vulnerabilities), Recovery (restoring systems, validating integrity), and Post-Incident Activity (root cause analysis, lessons learned, control improvements). The technical infrastructure supporting IR is built around a SIEM (Security Information and Event Management) system that aggregates logs, correlates events across sources, and generates alerts. Common SIEMs include Splunk, Elastic Security, Microsoft Sentinel, and AWS Security Hub.

SOAR (Security Orchestration, Automation and Response) platforms automate repetitive IR tasks: enriching alerts with threat intelligence context (VirusTotal, Shodan lookups), executing containment actions (quarantining a host, revoking a credential), and escalating to human analysts only for decisions requiring judgement. Evidence preservation is a critical architectural requirement often overlooked: before containing or eradicating, forensically important data (memory dumps, disk images, network captures, log exports) must be preserved to an immutable store for post-incident investigation and potential legal proceedings. Blast radius containment means designing systems so that a compromise of one component cannot easily spread to others — implemented through network segmentation, least-privilege IAM, and immutable infrastructure patterns.

Why it exists

A security incident is inevitable; the question is whether the organisation responds effectively or ineffectively. IBM research shows that organisations with tested IR plans and teams contained breaches 54 days faster and spent $2.66M less per breach on average compared to organisations without IR capability. Without pre-defined runbooks and automation, IR teams waste critical minutes during a live incident determining what tools to use and what steps to take, while attackers continue to exfiltrate data or expand access. Evidence preservation matters for two reasons: forensic investigation to understand the full scope and root cause of the breach, and legal preservation in case criminal prosecution or civil litigation follows the incident.

When to use

• All organisations running production systems — a basic IR plan and SIEM are minimum requirements.
• Regulated environments (financial, healthcare, critical infrastructure) — formal IR plans are mandated by most frameworks (ISO 27001, SOC 2, PCI DSS).
• Organisations with high-value data or IP — sophisticated adversaries (nation-states, ransomware groups) require mature IR capability to detect and contain before significant damage.

When not to use

• There are no scenarios where an IR plan is inappropriate. Scale the complexity of the plan to the organisation size — a startup needs a simple IR runbook and a SIEM; an enterprise needs a full SOC with SOAR and 24/7 coverage.

Typical architecture

IR TECHNICAL ARCHITECTURE:

DATA SOURCES → SIEM → SOAR → ANALYST

Data Sources:
  Cloud: CloudTrail, VPC Flow Logs, GuardDuty
  Application: structured security logs (auth events,
               access denied, config changes)
  Endpoint: EDR (CrowdStrike, SentinelOne) telemetry
  Network: NGFW logs, DNS query logs
  Identity: IdP authentication events (Okta, AAD)

SIEM (Splunk / Elastic / Sentinel):
  - Ingest and normalise all log sources
  - Correlation rules: detect multi-source attack patterns
  - Threat intel enrichment: IOC matching (IPs, hashes, domains)
  - Alert triage queue for analyst review
  - Dashboards: MTTD, MTTR, open incidents

SOAR Automation Playbooks:
  Trigger: "Credential stuffing detected"
  Auto-actions:
  1. Enrich: query VirusTotal for source IPs
  2. Look up user in IdP (how many accounts affected?)
  3. Block source IPs in WAF (automated)
  4. Force MFA re-prompt for affected accounts
  5. Create ticket with enriched context
  6. Escalate to analyst if > 10 accounts affected

INCIDENT CLASSIFICATION:
  P1: Active breach, data exfiltration, ransomware
      → 15 min response SLA, executive notification
  P2: Compromised credential, lateral movement attempt
      → 1 hour response SLA
  P3: Policy violation, failed attack (contained)
      → 24 hour review SLA

CONTAINMENT ACTIONS:
  Host: - Quarantine from network (EDR isolation)
        - Snapshot disk for forensics before remediation
  Identity: - Revoke all sessions and tokens
            - Disable account, rotate credentials
  Network: - Block IOC IPs/domains at WAF/DNS
           - Isolate affected VPC subnet
  Application: - Feature flag off affected endpoint
               - Deploy circuit breaker to affected service

EVIDENCE PRESERVATION:
  Before any containment:
  1. Export relevant logs to S3 WORM bucket (Object Lock)
  2. Snapshot EC2 EBS volumes
  3. Network packet capture (if available)
  4. Memory dump (if host is accessible)
  Timeline: all evidence timestamped; chain of custody logged

Pros and cons

Implementation notes

Write runbooks before you need them. An IR runbook for each threat scenario (compromised credential, S3 bucket data exposure, ransomware, insider threat) should define: detection indicators, immediate containment steps, evidence to collect, escalation path, and communication templates. Store runbooks in a location accessible when primary systems are compromised — not only in the SIEM. Test runbooks in tabletop exercises at least quarterly; the first time a runbook is executed should never be during a live incident. Establish communication channels that are independent of potentially-compromised company infrastructure: use a separate Slack workspace or Signal group for IR communications that is pre-configured before any incident.

For SIEM alerting, adopt a hypothesis-based detection approach: write detection rules for the specific attacker techniques (MITRE ATT&CK framework) most relevant to your threat model rather than relying solely on vendor-provided rules. Prioritise high-fidelity, low-volume alerts that are almost always true positives (impossible travel, authentication from tor exit nodes, creation of new admin user) over high-volume low-fidelity alerts that generate noise.

Common failure modes

• No tested runbooks: IR plans that exist only as documents never exercised result in disorganised, slow responses during real incidents.
• Alert fatigue: SIEM with hundreds of daily false positives trains analysts to ignore alerts; the critical true positive is missed in the noise.
• Evidence destroyed before preservation: Responding immediately by terminating compromised instances destroys forensic evidence needed to understand the attack scope.
• No out-of-band communication: IR communications over company email/Slack that may be monitored by an attacker who has compromised the identity provider allow attackers to observe and counter the response.
• Scope underestimation: Containing the initially-discovered compromise without investigating whether the attacker had already moved laterally; declaring the incident closed prematurely.

Decision checklist

• Is there a SIEM aggregating logs from all critical systems (cloud, identity, application, endpoint)?
• Are written, tested runbooks available for the top 5 most likely incident scenarios?
• Is there an out-of-band communication channel for IR team use during incidents?
• Is evidence preservation (log export to WORM storage, EBS snapshots) part of the containment procedure?
• Are tabletop exercises or GameDays conducted at least annually?
• Is there a defined escalation path and stakeholder notification plan for P1 incidents?

Example use cases

• Credential stuffing response: GuardDuty alert triggers SOAR playbook; playbook auto-enriches attacking IPs via threat intel; blocks IPs in WAF; forces MFA re-prompt for all affected users; creates ticket with full context; analyst reviews and decides whether to notify affected users within 5 minutes of initial alert.
• Ransomware isolation: EDR detects file encryption activity; SOAR playbook immediately quarantines host (network isolation); takes EBS snapshot; preserves last 30 days of CloudTrail and application logs to S3 WORM bucket; pages P1 on-call; activates IR war room.
• S3 data exposure: AWS Config rule detects public S3 bucket; SOAR immediately sets bucket to private; preserves S3 access logs to WORM storage; checks CloudTrail for all access to the bucket for the prior 90 days; estimates data exposed for breach notification decision.

Related patterns

• Alerting Strategies — SIEM alerting and alert fatigue management.
• Log Aggregation — Log infrastructure that feeds the SIEM.
• Threat Modeling — Threat models inform IR runbook scenarios.

Further reading

• NIST SP 800-61r2: Computer Security Incident Handling Guide
• MITRE ATT&CK Framework
• SANS Incident Handler's Handbook