SOAR and IR Automation
Security Orchestration, Automation, and Response — what to automate, what not to, designing effective playbooks, and how to avoid building automation that adds more complexity than it removes.
The SOC processes 400 alerts per day. An analyst spends an average of 8 minutes per alert on manual enrichment: looking up the IP in VirusTotal, checking the user in AD, querying the SIEM for context. That's 53 analyst hours per day on repetitive lookups. A SOAR platform could automate all three lookups in under 30 seconds. But the SOC manager also has 12 SOAR "playbooks" that were built two years ago and nobody maintains them — when a field in the SIEM changed format, three playbooks broke silently and produced wrong results for three months. The question isn't whether to automate — it's what to automate and how to maintain it.
What to Automate vs What to Keep Manual
Automation Decision Framework
═══════════════════════════════════════════════════════════════════
HIGH automation value — automate these:
├── Data enrichment (repeatable, low-judgment, high volume)
│ IP reputation lookup (VirusTotal, Shodan, AbuseIPDB)
│ Domain/URL analysis
│ Hash lookup
│ User lookup in AD/AAD
│ Asset lookup in CMDB
├── Case creation and ticket routing
│ Alert → ITSM ticket with populated fields
│ Alert → TheHive case with IOCs extracted
├── High-confidence, low-impact automated response
│ Block IP in firewall if VirusTotal score > 80 AND alert = critical
│ Quarantine email from sender domain if DMARC fail + known phishing pattern
└── Notifications and escalation
Slack/Teams alert to on-call when P1 condition met
PagerDuty page based on alert type and time
LOW automation value — keep human judgment:
├── Containment decisions (isolating production hosts)
│ Risk of business disruption requires human authorization
├── Account disables (especially for executives or critical service accounts)
├── Any action that's hard to reverse
├── Scope and impact assessment
└── Any decision requiring interpretation of context
(is this anomalous user behavior or just the user's new job role?)
Playbook Design Principles
| Principle | What it means in practice |
|---|---|
| Idempotent actions | Running the same automation twice should produce the same result, not double-block an IP or send duplicate notifications. Design actions to check whether they've already been done before executing. |
| Human approval gates for destructive actions | Host isolation, account disable, email deletion — these should require human approval, not execute automatically. The automation prepares the action and queues it for approval; a human clicks "approve." |
| Graceful degradation on API failure | If VirusTotal is down, the playbook should continue with a note "enrichment unavailable" rather than failing entirely and leaving the alert unprocessed. |
| Every action logged | The automation must record what it did, when, with what input, and what the output was. This is your audit trail. Without it, you can't debug broken playbooks or defend automated actions in legal proceedings. |
| Regular testing with production-like inputs | Test playbooks monthly with real alert patterns from your environment. A playbook that passed testing two years ago may break silently when data formats change. |
Example: Phishing Triage Playbook
SOAR Phishing Triage Playbook (Automated Steps)
═══════════════════════════════════════════════════════════════════
TRIGGER: User reports phishing email OR email security alert
Step 1 — Extract IOCs (automated):
Parse email headers: sender IP, sending domain, Reply-To
Extract URLs from email body (defang them)
Extract attachments and compute hashes
→ Store all in case
Step 2 — Enrich IOCs (automated):
For each IP: VirusTotal score, AbuseIPDB reports
For each URL: VirusTotal URL scan, Google Safe Browsing check
For each hash: VirusTotal file scan, known malware family
→ Annotate case with enrichment results
Step 3 — Check recipient scope (automated):
Query email gateway: how many mailboxes received the same message?
(Match by: exact sender + subject OR sender domain + URL match)
→ List all recipients in case
Step 4 — Score and route (automated):
If (VirusTotal score > 50 OR known malware hash):
→ Route to Tier 2 analyst with HIGH priority
→ Slack notification to SOC channel
Else:
→ Route to Tier 1 for manual review with enrichment attached
Step 5 — Human review and decision (MANUAL):
Analyst reviews enrichment
Decision: confirmed phishing / false positive / escalate
If confirmed: analyst clicks "Remediate"
Step 6 — Remediation (automated with human approval in Step 5):
Purge email from all mailboxes (Compliance Search action)
Block sender domain in email gateway
Create IOC block in EDR (hash/IP/domain)
→ Case closed with remediation documentation
Common SOAR Platforms
| Platform | Best for | Tradeoffs |
|---|---|---|
| Splunk SOAR (formerly Phantom) | Organizations with heavy Splunk investment; extensive integration library | Expensive; Python-based playbooks require developer skill to maintain well |
| Palo Alto XSOAR (Cortex) | Palo Alto shop; enterprise-grade with market indicators integration | Very expensive; complex to operate at scale; overkill for smaller teams |
| TheHive + Cortex | Open source; budget-conscious teams; highly customizable | Requires infrastructure management; self-hosted; smaller integration library than commercial |
| Tines | Modern low-code approach; good for teams without heavy developer resources | Newer platform; fewer native integrations than established platforms |
| n8n / Zapier (workflow tools) | Simple enrichment workflows; notification routing; not a full SOAR | Not designed for security; limited audit/logging; not suitable for IR automation beyond basic enrichment |
Q & A
Q: Your automated IP block playbook blocked a legitimate cloud provider IP and caused a production outage. How do you prevent this from happening again?
Add an allowlist check as the first step before any block action: if the IP is in a pre-approved allowlist of known-good infrastructure (cloud provider IP ranges, CDN ranges, corporate infrastructure), the playbook stops and routes to human review instead of blocking. Maintain the allowlist as a regularly updated reference dataset (AWS IP ranges are published at ip-ranges.amazonaws.com; similar for Azure and GCP). Also: add a time-to-live (TTL) to automated blocks — automated IP blocks should expire after 24-48 hours and require human confirmation to make permanent. An automated block that expires is much less damaging than one that silently persists after the threat is gone. Post-incident: root cause the false positive — what enrichment signal triggered the block that shouldn't have? Tune the threshold or logic to prevent the same false positive class.