▣ TechAnv Blog — Open Source · AI-First · Security · Transparent
◄ HOME › ALL POSTS › INCIDENT RESPONSE AUTOMATION: FROM …
▣ INCIDENT RESPONSE AUTOMATION: FROM DETECTION TO CONTAINMENT …

Incident Response Automation: From Detection to Containment in Minutes, Not Days

by Anubhav Gain

The IBM Cost of a Data Breach report puts the average attacker dwell time at 207 days — that is how long an adversary lives inside your environment before detection. Add another 73 days to contain it. Every single one of those days costs money, data, and trust. The fix is not hiring more analysts. The fix is automation that executes your response playbook faster than any human team can page one another.

The Dwell Time Problem

207 days is not just a statistic. It is a window. In that window, attackers escalate privileges, move laterally, exfiltrate data in small chunks, plant backdoors, and cover tracks. By the time your SOC gets a credible alert, the blast radius is already enormous.

Why does dwell time stay so high? Three reasons: alert fatigue drowns real signals in noise (the average SOC processes over 10,000 alerts per day), manual triage is slow by nature, and containment requires coordination across teams — network, identity, endpoint — each with their own change-control overhead. Automation attacks all three.

The IR Lifecycle

Incident response follows a well-defined loop: Detect → Triage → Contain → Eradicate → Recover. The problem is that in most organizations, only detection is automated. Everything downstream is human-driven, which means it is slow and inconsistent.

The goal of IR automation is to push the automation boundary as far right as possible — ideally through containment — while keeping humans in the loop for decisions with irreversible consequences.

Automation at Each Phase

Detect: Runtime security tools like Falco watch kernel syscalls and flag anomalous process behavior in containers and VMs. SIEM platforms aggregate logs from across the stack. OpenArmor rule sets add threat-specific detections on top of raw log data, catching patterns like lateral movement via SMB, unusual cron modifications, or credential dumping behavior.

Triage: SOAR platforms (Splunk SOAR, Palo Alto XSOAR, Tines) receive enriched alerts and automatically pull context: threat intel lookups on IPs and hashes, asset owner data from your CMDB, recent auth logs for the affected user, and vulnerability data for the impacted host. This context, assembled in seconds, is what used to take an analyst 30–45 minutes per alert.

Contain: Automated playbooks can isolate a host from the network, revoke an OAuth token, disable an AD account, or block an IP at the firewall — all without human action, provided predefined confidence thresholds are met.

Eradicate and Recover: These phases typically stay human-supervised. Eradication means confirming root cause and removing the foothold. Recovery means restoring services with confidence that the threat is gone. Automation can stage the work — snapshotting affected systems, queuing reimaging jobs, preparing rollback scripts — but a human signs off.

AI-Powered Triage

Raw SIEM alerts are useless at scale. The signal-to-noise ratio in a modern environment makes individual alert review economically impossible. AI triage changes the equation.

A triage model correlates alerts across the kill chain: a failed login followed by a successful one from a new geography, followed by an unusual process spawn, followed by an outbound connection to a newly registered domain — individually these might each be noise. Together they are a confirmed compromise indicator.

Blast radius scoring prioritizes response: an alert on a tier-1 production database triggers faster than the same alert on a dev sandbox. AI models can score blast radius using asset criticality, data sensitivity classification, and downstream dependency mapping. False positive rates drop significantly when triage uses correlated context rather than single-event logic — teams running ML-assisted triage report 40–60% reductions in analyst-escalated false positives.

Automated Containment Playbooks

A containment playbook is a decision tree with automated actions at each node and human-in-the-loop gates at high-consequence steps. Here is a concrete example for a compromised credential scenario:

  1. Trigger: UEBA model flags impossible travel + privilege escalation attempt
  2. Auto-action: Revoke active sessions for the affected account via IdP API
  3. Human checkpoint: Notify account owner and security lead via PagerDuty — confirm or deny suspicious activity within 15 minutes
  4. If confirmed: Auto-disable account in AD, quarantine the source host via EDR API, block source IP at perimeter firewall, open a P1 ticket with full context pre-populated
  5. If denied: Auto-close alert, log false positive for model retraining

The human checkpoint prevents automation from locking out a legitimate employee traveling for work. The automation ensures that if it is real, containment happens in minutes rather than after a 2am pager chain.

Building Runbooks as Code

Storing playbooks in YAML makes them version-controlled, testable, and auditable. A minimal structure:

playbook:
  name: compromised-credential-response
  trigger:
    source: ueba
    condition: impossible_travel AND privilege_escalation
  steps:
    - id: revoke-sessions
      action: idp.revoke_sessions
      target: "{{ alert.user_id }}"
      auto: true

    - id: human-checkpoint
      action: notify.pagerduty
      message: "Suspicious activity on {{ alert.user_id }}. Confirm or deny."
      timeout_minutes: 15
      on_timeout: escalate

    - id: isolate-host
      action: edr.quarantine_host
      target: "{{ alert.host_id }}"
      requires_approval: true
      approved_by: security-lead

    - id: block-ip
      action: firewall.block_ip
      target: "{{ alert.source_ip }}"
      auto: true
      if: human_checkpoint.confirmed == true

Playbooks as code means your IR procedures live in Git, get reviewed like any other change, and can be unit-tested against simulated alert data before they ever run in production. OpenArmor supports importing YAML playbooks directly, mapping alert rule IDs to response actions.

Measuring IR Effectiveness

You cannot improve what you do not measure. Four metrics matter:

  • MTTD (Mean Time to Detect): Time from incident start to first alert. Target: under 1 hour. Automated detection with Falco and SIEM correlation gets most teams there.
  • MTTR (Mean Time to Respond/Remediate): Time from first alert to containment. Target: under 4 hours for critical incidents. Automation typically cuts this from days to under 30 minutes for covered playbook scenarios.
  • False Positive Rate: Percentage of escalated alerts that turn out to be benign. High false positive rates burn analyst time and cause alert fatigue. Target: under 10% for escalated alerts.
  • Playbook Coverage Rate: Percentage of incident types with a defined, automated playbook. Most teams start below 30%. Getting to 70%+ coverage is a realistic 12-month goal.

Track these weekly. Review uncovered incident types in retrospectives. Each novel incident is a candidate for a new runbook.


The 207-day dwell time is not a technology problem — it is a process problem that technology can fix. Automated detection closes the visibility gap. AI triage cuts the noise. Automated containment playbooks compress the response window from days to minutes. The infrastructure exists today: Falco, SOAR platforms, OpenArmor rules, YAML playbooks in Git. The question is whether your team builds the playbooks before the next incident, or after it.

Tags:
← BACK TO INDEX