SOAR Design — Automating the Right Things

SOAR (Security Orchestration, Automation, and Response) exists to eliminate the repetitive, low-risk work that occupies analysts so they can focus on judgment-intensive investigation. The risk is SOAR designed without thinking about blast radius — automated outages are worse than manual response times.

What SOAR Can and Cannot Replace

SOAR replaces:

Manual enrichment lookups (VirusTotal, WHOIS, GeoIP)
Ticket creation and basic formatting
Notification and escalation routing
Low-risk, pre-approved containment actions

SOAR cannot replace:

Judgment: Is this really a TP? Is this really worth escalating?
Context: The analyst knows this host is used by the CISO and treats it accordingly
Novel situations: The playbook doesn’t cover this scenario
High-stakes decisions: Whether to isolate a production server

SOAR Playbook Design: A Framework

Step 1: Map the Manual Process

Before automating, document every step the analyst does manually:

Manual alert triage (phishing report):
1. Open ticket
2. Copy sender address to VirusTotal URL field
3. Copy sender domain to WHOIS lookup
4. Copy IP from header to AbuseIPDB
5. Search SIEM for other emails from this sender
6. Check if recipient clicked
7. Add enrichment to ticket
8. Make FP/TP decision
9. If TP: send alert to email-security team Slack
10. If TP: submit quarantine request to email platform

Step 2: Classify Each Step

Step 1:  Create ticket       → Automate (zero risk)
Step 2:  VT lookup           → Automate (read-only)
Step 3:  WHOIS lookup        → Automate (read-only)
Step 4:  AbuseIPDB lookup    → Automate (read-only)
Step 5:  SIEM search         → Automate (read-only)
Step 6:  Check if clicked    → Automate (query UAL — read-only)
Step 7:  Populate ticket     → Automate (just formatting)
Step 8:  FP/TP decision      → HUMAN (requires judgment)
Step 9:  Slack notification  → Semi-auto (auto after human decision)
Step 10: Quarantine request  → Approval gate (destructive, but reversible)

Steps 1-7: fully automated. Step 8: hard stop, human required. Steps 9-10: triggered by human decision with approval.

Step 3: Define Approval Gates

For each approval-gated action, specify:

Action: Email quarantine — remove from all mailboxes
Approval: SOC analyst or L2
Pre-condition: Alert is classified as TP
Reversibility: Recoverable within 30 days (retention policy)
Blast radius: Up to 5000 recipients; wrong quarantine = legitimate email missing
Approval timeout: 30 minutes (if no response, auto-escalate to L2)

A Complete SOAR Playbook: Phishing Email Report

Trigger: User submits phishing report via Outlook button → creates ticket

─── AUTOMATED (no human needed) ───────────────────────────────────
1. Extract email metadata (sender, reply-to, subject, all recipients)
2. Extract URLs from body + attachments
3. Extract attachment hashes (MD5/SHA256)

4. Enrich sender IP:
   → VirusTotal IP score + categories
   → AbuseIPDB confidence + ISP + country
   → MaxMind GeoIP (country, city, ASN)

5. Enrich sender domain:
   → WHOIS (registration date, registrar)
   → VirusTotal domain score
   → Passive DNS (how many IPs? recent changes?)

6. Enrich URLs (if any):
   → URLScan.io submission → wait for result → attach screenshot
   → VirusTotal URL score

7. Enrich attachment hashes (if any):
   → VirusTotal hash lookup → attach detection count + family

8. Check M365 UAL:
   → Did any recipient click links in this email?
   → Did reporter interact before reporting?
   → How many total recipients?

9. Update ticket with all enrichment (structured format)
10. Auto-classify preliminary: 
    If VT score > 5 OR WHOIS age < 30 days → flag as "high confidence"
    Else → flag as "needs review"

─── ANALYST DECISION POINT ─────────────────────────────────────
11. ★ ANALYST: Review enriched ticket
    Decision: FP → close | TP → proceed with containment
    (Target: analyst makes decision within 10 min — enrichment done, no manual lookups needed)

─── APPROVAL-GATED CONTAINMENT (requires analyst click) ────────
12. If TP decision:
    → Notification: auto-post to #soc-alerts Slack channel (auto, after analyst clicks TP)
    → Request approval: quarantine email from all mailboxes?
       Approval gate: analyst confirms
       Action: M365 quarantine all instances
    → Request approval: block sender domain at email gateway?
       Approval gate: analyst confirms  
       Action: Submit block to email gateway API

─── FOLLOW-UP AUTOMATION ───────────────────────────────────────
13. If any recipient clicked:
    → Alert: "CLICK CONFIRMED — upgrade to AiTM investigation"
    → Auto-assign to L2 queue
    → Pre-populate AiTM playbook with victim username

14. Case close: auto-generate summary metrics for weekly SOC report

Worked Example

SOAR failure mode: automated host isolation without approval gate

Scenario: A security engineer built a SOAR playbook that automatically isolates any host where:

VirusTotal hash score > 50/90 detections AND
Process is running from C:\Temp

What happened: A software deployment tool placed a new release binary in C:\Temp on 200 hosts before it was uploaded to VirusTotal. The binary was clean, but had 0/90 VT detections (new file, not yet in VT). During testing, the binary was submitted to VT and 12 engines flagged it (false positive — overly aggressive heuristics). Score: 12/90.

Three weeks later, the vendor submitted an updated build (same tool, new version). VT had the new hash: 54/90 detections (now trained on the false positive pattern). The SOAR playbook triggered on 47 hosts, isolating them simultaneously.

Result: 47 workstations isolated during business hours. 47 helpdesk calls. IT operations team spent 4 hours re-connecting hosts. Estimated business disruption: 3,000 hours of lost employee productivity.

Root cause: No approval gate on host isolation. The automation criteria were based on VT score alone, without human verification that the binary was malicious. The VT scores were false positives.

Lesson: Host isolation must always require analyst approval. VT score alone is not sufficient for a destructive action. SOAR’s job was to alert the analyst with the VT score — not to act on it.

Retrieval Practice

A SOAR playbook automatically blocks the sender domain when VirusTotal shows the domain as malicious (any detections). A legitimate vendor's domain was flagged by one VT engine as 'phishing.' The SOAR playbook blocked the domain. All emails from that vendor — including order confirmations and support tickets — were blocked for 3 days. What is the design flaw and how should the playbook be redesigned?

Reveal answer

Design flaw: the trigger condition (any VT detection) is too aggressive, and there is no human approval gate before a blocking action. One VT engine flagging a domain is common noise — domain blocking should require a higher threshold (>5 detections OR WHOIS age < 30 days AND >2 detections) AND a human approval step. Redesigned playbook: (1) VT enrichment is automatic (no change). (2) Alert threshold: only flag for analyst review if ≥5 engines detect the domain OR domain age < 30 days. (3) Approval gate: analyst reviews the enrichment, makes FP/TP decision, and explicitly approves the block. (4) Pre-block check: query internal email logs — has this domain had legitimate email traffic in the past 30 days? If yes, display a warning before the analyst approves. (5) Auto-expiry: domain blocks automatically expire in 30 days pending review, preventing permanent accidental blocks.