Incident Response Automation: Building Playbooks with Workflow Orchestration

By /

Introduction

Manual incident response doesn’t scale. When your SIEM generates hundreds of alerts daily, security analysts spend more time on repetitive triage tasks than actual investigation. Incident response automation through workflow orchestration tools like n8n provides a practical path to SOAR (Security Orchestration, Automation, and Response) capabilities without the six-figure price tag of commercial platforms. This guide covers building automated response playbooks that integrate with your existing security stack.

Automation Architecture

A practical IR automation architecture connects your detection layer to response actions through a workflow engine:

SIEM (Wazuh/Elastic)
  → Webhook trigger
    → Workflow Engine (n8n)
      → Enrichment (VirusTotal, AbuseIPDB, Shodan)
      → Decision logic (severity, confidence)
      → Response actions (firewall block, ticket creation, notification)
      → Documentation (incident log, timeline)

Webhook Integration

Configure your SIEM to send alert webhooks to the workflow engine. With Wazuh, use the integrations configuration:

<!-- /var/ossec/etc/ossec.conf -->
<integration>
  <name>custom-webhook</name>
  <hook_url>http://automation01.internal:5678/webhook/siem-alert</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Playbook 1: Brute Force Response

When your SIEM detects repeated authentication failures from a single source, automatically investigate and respond:

Trigger

Webhook receives alert with rule ID matching brute force patterns (e.g., Wazuh rule 5763 — multiple authentication failures).

Enrichment

// n8n Function node: Enrich source IP
const srcIP = $input.first().json.data.srcip;

// Query AbuseIPDB
const abuseCheck = await $http.request({
  method: 'GET',
  url: `https://api.abuseipdb.com/api/v2/check`,
  headers: { 'Key': process.env.ABUSEIPDB_KEY },
  qs: { ipAddress: srcIP, maxAgeInDays: 90 }
});

// Query VirusTotal
const vtCheck = await $http.request({
  method: 'GET',
  url: `https://www.virustotal.com/api/v3/ip_addresses/${srcIP}`,
  headers: { 'x-apikey': process.env.VT_KEY }
});

return {
  ip: srcIP,
  abuse_score: abuseCheck.data.abuseConfidenceScore,
  vt_malicious: vtCheck.data.attributes.last_analysis_stats.malicious,
  country: abuseCheck.data.countryCode,
};

Decision Logic

// n8n IF node: Determine response level
const abuseScore = $input.first().json.abuse_score;
const vtMalicious = $input.first().json.vt_malicious;

if (abuseScore > 80 || vtMalicious > 5) {
  return { action: 'block_and_alert' };
} else if (abuseScore > 50) {
  return { action: 'alert_only' };
} else {
  return { action: 'log_only' };
}

Response Actions

# Automated firewall block via SSH
ssh firewall01.internal "pfctl -t bruteforce -T add ${SRC_IP}"

# Create incident ticket
curl -X POST "https://tickets.internal/api/v1/tickets" \
  -H "Authorization: Bearer ${TICKET_API_KEY}" \
  -d "{\"title\": \"Brute force from ${SRC_IP}\", \"priority\": \"high\"}"

# Notify SOC via chat
curl -X POST "https://chat.internal/api/v1/message" \
  -d "{\"channel\": \"soc-alerts\", \"text\": \"Blocked ${SRC_IP} (abuse score: ${SCORE})\"}"

Playbook 2: Malware Alert Triage

When endpoint detection identifies a potential malware sample, automatically collect forensic data and isolate the host:

  1. Trigger — SIEM alert for malware detection (file hash, process name, host)
  2. Hash lookup — Query VirusTotal and MalwareBazaar for the file hash
  3. Host isolation — If confirmed malicious, quarantine the host via network policy
  4. Evidence collection — SSH to the host and collect running processes, network connections, and recent file changes
  5. Ticket creation — Create an incident ticket with all enrichment data attached
  6. Notification — Alert the SOC team with a summary and recommended next steps

Playbook 3: Credential Leak Response

When dark web monitoring or DMARC reports indicate compromised credentials:

1. Parse the alert for affected email addresses
2. Cross-reference with Active Directory to identify the user account
3. Force password reset via LDAP API
4. Revoke all active sessions (OAuth tokens, VPN sessions)
5. Enable enhanced monitoring for the account (24h elevated logging)
6. Notify the user and their manager via email
7. Create incident ticket for follow-up investigation

Error Handling and Failsafes

Automated response systems must include safeguards against false positives and cascading failures:

  • Rate limiting — never block more than N IPs per hour without human approval
  • Whitelist checking — always verify targets against a whitelist of critical infrastructure IPs before taking blocking actions
  • Rollback capability — every automated block should have an automatic expiration (e.g., 24h) with manual extension required
  • Audit trail — log every automated action with the triggering alert, enrichment data, and decision rationale
  • Human escalation — if confidence is below threshold, create an alert for human review instead of taking action

Measuring Effectiveness

Track these metrics to evaluate your automation program:

  • Mean Time to Respond (MTTR) — should decrease significantly for automated playbook types
  • False positive rate — automated blocks that were subsequently reversed
  • Analyst time saved — hours per week freed from repetitive triage tasks
  • Coverage — percentage of high-severity alert types with automated playbooks

Conclusion

Incident response automation through workflow orchestration provides immediate, consistent responses to known threat patterns while freeing analysts for complex investigations. Start with high-volume, low-complexity alerts (brute force, known-bad IPs) and gradually expand to more nuanced playbooks. The key is building in proper safeguards — rate limits, whitelists, and human escalation paths — so automation enhances your security posture without creating new risks.

Scroll to Top