Chapter 7: SOAR & Automation¶

Learning Objectives¶

By the end of this chapter, you will be able to:

• Explain the role and architecture of SOAR platforms
• Design automated playbooks for common security workflows
• Implement safe automation with human approval gates
• Measure automation ROI and effectiveness
• Apply AI-assisted playbook generation and optimization

Prerequisites¶

• Chapter 3: SIEM fundamentals and correlation
• Chapter 5: Triage and investigation workflows
• Understanding of API concepts and integrations

Key Concepts¶

SOAR • Playbook • Orchestration • Case Management • API Integration • Automation ROI

Curiosity Hook: The 2 AM Page That Could Have Been Avoided¶

Scenario: 2:17 AM. Tier 1 analyst paged for "High Severity: Brute Force Detected."

Manual Process (45 minutes): 1. Acknowledge alert (2 min) 2. Look up IP in threat intel (3 min) 3. Check if IP previously seen (5 min) 4. Query firewall for connection count (4 min) 5. Look up affected account details (3 min) 6. Check account for successful logins after failures (6 min) 7. Document findings in ticket (8 min) 8. If malicious: Block IP in firewall (5 min) 9. Reset account password (4 min) 10. Notify account owner (5 min)

Automated Process (3 minutes): 1. SOAR receives alert 2. Auto-enriches with threat intel, historical data, account details 3. Determines: Known botnet IP + service account + no successful login = auto-block 4. Executes: Block IP, reset password, create ticket, notify owner 5. Pages analyst only if auto-remediation fails

Result: Analyst sleeps through the night. Threat contained in 3 minutes instead of 45.

This chapter teaches: How to build automation that handles the repetitive 90%, so humans focus on the complex 10%.

7.1 What is SOAR?¶

Definition¶

SOAR (Security Orchestration, Automation, and Response) platforms integrate security tools, automate repetitive tasks, and orchestrate complex workflows to accelerate incident response.

Three Pillars¶

1. Orchestration - Connect disparate security tools (SIEM, EDR, firewall, IAM, ticketing) - Centralize control and visibility

2. Automation - Execute pre-defined playbooks (IF-THEN logic) - Reduce manual, repetitive tasks

3. Response - Accelerate containment and remediation - Standardize incident handling

SOAR vs. SIEM¶

Best Practice: SIEM and SOAR work together. SIEM generates alerts; SOAR executes response.

7.2 SOAR Architecture¶

Components¶

[SIEM Alert] → [SOAR Trigger] → [Playbook Execution] → [Tool Integrations] → [Case Management]
                     ↓                    ↓                      ↓                    ↓
                 Event Ingestion      Decision Logic        API Calls            Ticket/Notes

1. Trigger Sources - SIEM alerts - EDR detections - Email (phishing inbox) - Webhook from third-party tools - Manual analyst initiation

2. Playbook Engine - IF-THEN-ELSE logic - Loops and conditionals - Human approval gates - Parallel and sequential execution

3. Integrations - REST APIs to security tools (firewall, EDR, Active Directory) - Pre-built connectors (100+ tools for major SOAR platforms) - Custom scripts (Python, PowerShell)

4. Case Management - Track incidents from detection to closure - Centralize evidence and analyst notes - Metrics and reporting

Major SOAR Platforms¶

7.3 Building Playbooks¶

Anatomy of a Playbook¶

Playbook: A structured, repeatable workflow that defines how to respond to a specific alert type.

Example: Phishing Email Response

Trigger: Email forwarded to phishing@company.com

Step 1: Extract IOCs (URLs, sender, attachments)
Step 2: Check sender reputation (threat intel lookup)
Step 3: Search email logs for other recipients
Step 4: IF malicious:
   4a. Quarantine all copies of email
   4b. Block sender domain on email gateway
   4c. Extract and detonate attachments in sandbox
   4d. Create ticket for analyst review
Step 5: IF benign:
   5a. Reply to submitter: "Email is safe"
   5b. Close case
Step 6: Update metrics dashboard

Playbook Design Principles¶

1. Start Simple - Begin with high-volume, low-risk tasks (enrichment, data gathering) - Avoid automating complex decisions early

2. Human-in-the-Loop for High-Impact Actions - Require approval before: - Blocking production IPs/domains - Disabling user accounts - Isolating critical servers

3. Fail-Safe Defaults - If API call fails, alert analyst (don't silently fail) - Implement rollback mechanisms (e.g., unblock IP after 24 hours)

4. Logging and Auditability - Log every action taken by playbook - Include reasoning (why was IP blocked?) - Enable post-incident review

7.4 Common Automation Use Cases¶

Use Case 1: Automated Enrichment¶

Problem: Analysts spend 30% of time looking up IOCs in threat intel, WHOIS, VirusTotal.

Solution: Auto-enrich all alerts with: - Threat intel reputation (IP, domain, hash) - GeoIP location - WHOIS registration data - VirusTotal scan results - Historical activity (has this IOC appeared before?)

Playbook Logic:

def enrich_alert(alert):
    iocs = extract_iocs(alert)

    for ip in iocs['ips']:
        threat_intel = query_threatfeed(ip)
        geoip = lookup_geoip(ip)
        alert.add_enrichment(f"IP {ip}: {threat_intel['reputation']}, Location: {geoip['country']}")

    for hash in iocs['hashes']:
        vt_result = virustotal_lookup(hash)
        alert.add_enrichment(f"Hash {hash}: VT {vt_result['positives']}/{vt_result['total']}")

    return alert

Result: Enriched alert presented to analyst in <10 seconds, reducing triage time by 60%.

Use Case 2: Automated Account Lockout¶

Problem: Compromised accounts require immediate lockout, but waiting for analyst triage delays response.

Playbook: Impossible Travel → Auto-Lockout

Trigger: Impossible Travel alert (>500 km in <1 hour)

Step 1: Validate alert data (both login events exist?)
Step 2: Check account type:
   - IF service account → Alert analyst (do not lock, may break automation)
   - IF VIP account → Alert analyst + manager
   - IF standard user → Proceed to Step 3
Step 3: Disable account in Active Directory
Step 4: Send email to user: "Your account has been locked due to suspicious activity. Contact IT Security."
Step 5: Create ticket for analyst follow-up investigation
Step 6: Log action to audit trail

Safety Measures: - Don't lock service accounts (break business processes) - Don't lock VIPs without approval (executive impact) - Auto-unlock after 4 hours if analyst doesn't confirm compromise (prevent prolonged FP impact)

Use Case 3: Automated Threat Intel Ingestion¶

Problem: Manually importing 10,000 daily IOCs from 5 threat feeds is impractical.

Playbook:

Trigger: Scheduled (every 15 minutes)

Step 1: Fetch IOCs from threat feeds (TAXII, API)
Step 2: De-duplicate against existing database
Step 3: Validate IOC format (valid IP, domain, hash?)
Step 4: Age-out stale IOCs (>90 days old)
Step 5: IF high-confidence IOC:
   5a. Auto-block on firewall/proxy
   5b. Add to SIEM watchlist
Step 6: IF medium-confidence IOC:
   6a. Add to SIEM for alerting (don't block)
Step 7: Update threat intel dashboard

Use Case 4: Phishing Email Takedown¶

Problem: Responding to phishing emails manually takes 20+ minutes per report.

Automated Workflow:

Trigger: User forwards email to phishing@company.com

Step 1: Parse email (extract sender, subject, URLs, attachments)
Step 2: Check URLs against threat intel
Step 3: IF malicious (threat intel match):
   3a. Quarantine all instances of email organization-wide
   3b. Block sender domain on email gateway
   3c. Extract attachments → submit to sandbox
   3d. Notify submitter: "Confirmed malicious, removed from all mailboxes"
   3e. Create ticket for analyst review of sandbox results
Step 4: IF unknown (no threat intel match):
   4a. Submit URLs to sandbox for detonation
   4b. Queue for analyst review
   4c. Notify submitter: "Under investigation"
Step 5: IF benign:
   5a. Notify submitter: "Email is safe"
   5b. Close case

Result: Known phishing emails removed in <2 minutes. Analysts focus on ambiguous cases.

7.5 Safe Automation Practices¶

Approval Gates¶

When to Require Human Approval: - High-impact actions: Blocking production IPs, isolating critical servers - Uncertain classification: Alert confidence <80% - Scope escalation: Action affects >10 users or systems - Compliance-sensitive: Actions involving PII or regulated data

Example Approval Logic:

if alert['severity'] == 'critical' and alert['confidence'] < 0.80:
    request_analyst_approval(alert, action="block_ip")
    if approved:
        execute_action()
    else:
        log_rejection()
else:
    execute_action()  # Auto-execute high-confidence actions

Rollback Mechanisms¶

Auto-Expiring Blocks:

Block IP on firewall with 24-hour TTL
IF analyst confirms malicious within 24 hours:
   Extend block permanently
ELSE:
   Auto-unblock (assume FP or threat mitigated)

Benefit: Prevents indefinite blocking of legitimate IPs due to temporary FPs.

Testing and Validation¶

Pre-Production Testing: 1. Dry-run mode: Execute playbook logic but don't take real actions (log what would happen) 2. Test environment: Run playbook against non-production systems 3. Manual review: Senior analyst reviews playbook logic before enabling

Example Dry-Run:

[DRY RUN] Would block IP 203.0.113.45 on firewall
[DRY RUN] Would disable user account jsmith in AD
[DRY RUN] Would create ticket INC-2026-456
Analyst reviews: Logic correct, enable for production

7.6 Measuring Automation Effectiveness¶

Key Metrics¶

1. Time Savings

Time Saved = (Manual Process Time - Automated Process Time) × Number of Incidents

Example:
  Manual phishing response: 20 minutes
  Automated: 2 minutes
  Incidents/month: 300
  Time Saved = (20 - 2) × 300 = 5,400 minutes (90 hours/month)

2. Mean Time to Respond (MTTR)

Before automation: MTTR = 45 minutes
After automation: MTTR = 5 minutes
Improvement: 89% reduction

3. Analyst Capacity

Alerts handled per analyst per day:
  Manual: 30 alerts
  Automated: 120 alerts (90 auto-triaged, 30 analyst-reviewed)
Capacity increase: 300%

4. Accuracy and False Positives

Automated action accuracy = Correct Actions / Total Actions

Example:
  Automated IP blocks: 1,000
  False positive blocks: 20
  Accuracy: 98%

Monitor: If accuracy <95%, investigate playbook logic or input data quality

7.7 AI-Assisted Playbook Development¶

Use Case 1: Playbook Generation from Natural Language¶

Analyst Input:

"Create a playbook that blocks IPs with >50 failed login attempts in 5 minutes and notifies the SOC manager."

LLM Output (Structured Playbook):

name: Brute Force Auto-Block
trigger:
  type: siem_alert
  alert_name: "Brute Force Detected"
conditions:
  - failed_login_count > 50
  - time_window: 5 minutes
actions:
  - name: Block IP on Firewall
    tool: firewall_api
    parameters:
      ip: "{{alert.source_ip}}"
      duration: 24h
  - name: Notify SOC Manager
    tool: email
    parameters:
      to: "soc-manager@company.com"
      subject: "Auto-blocked IP {{alert.source_ip}} due to brute force"
      body: "Details: {{alert.details}}"
  - name: Create Ticket
    tool: ticketing_system
    parameters:
      title: "Brute Force: {{alert.source_ip}}"
      severity: high

Benefit: Accelerates playbook creation from hours to minutes.

Use Case 2: Playbook Optimization Suggestions¶

Scenario: Existing playbook has 15% false positive rate for auto-blocking IPs.

AI Analysis:

Current Playbook Logic:
  IF (failed_logins > 10 in 5 min) → Block IP

AI Suggestion:
  Issue: Blocking VPN concentrators with many legitimate users
  Recommendation: Add allowlist for known VPN IPs

  Updated Logic:
  IF (failed_logins > 10 in 5 min)
     AND (IP NOT IN vpn_whitelist)
     AND (source_country NOT IN ["US", "CA", "UK"])  # Expected user locations
  THEN Block IP

Expected Outcome: Reduce FPs from 15% to <5%

Use Case 3: Adaptive Playbooks¶

ML-Driven Thresholds:

# Traditional: Static threshold
if failed_logins > 10:
    alert()

# AI-Enhanced: Dynamic threshold based on baseline
baseline = calculate_baseline(user, time_of_day, day_of_week)
threshold = baseline + (3 * std_dev)

if failed_logins > threshold:
    alert()

Benefit: Adapts to normal user behavior (higher tolerance for service accounts, lower for dormant accounts).

Interactive Element¶

MicroSim 7: Playbook Builder

Design and test automated response playbooks. See real-time metrics on time saved and accuracy.

Common Misconceptions¶

Practice Tasks¶

Task 1: Design a Playbook¶

Scenario: Your organization receives 50 alerts/day for "Unusual PowerShell Execution." 80% are false positives from admin scripts.

Task: Design a playbook to reduce analyst workload.

Trigger: SIEM alert "Unusual PowerShell Execution"

Step 1: Extract details (host, user, command_line, parent_process)

Step 2: Enrichment
  - Check user against admin group membership
  - Check script hash against allowlist (known admin scripts)
  - Query EDR for behavioral indicators (network connections, file writes)

Step 3: Classification
  IF (user in admin_group) AND (hash in allowlist):
     → Auto-close as benign (log for audit)

  ELSE IF (behavioral_indicators == suspicious):
     → Escalate to Tier 2 (isolate endpoint option)

  ELSE:
     → Queue for Tier 1 review with enrichment data

Step 4: Document decision in ticket

Task 2: Identify Approval Gate Needs¶

Which actions should require human approval?

a) Enriching an alert with threat intel data b) Blocking an IP that has 1,000 failed login attempts from a known botnet c) Disabling the CEO's account due to impossible travel alert d) Quarantining a phishing email confirmed malicious by 3 threat intel sources

Task 3: Calculate Automation ROI¶

Scenario: - Manual process: 15 minutes/alert - Automated process: 2 minutes/alert - Alert volume: 200/day - Analyst hourly cost: $50/hour

Task: Calculate monthly time and cost savings.

Exam Prep & Certifications¶

Self-Assessment Quiz¶

Summary¶

In this chapter, you learned:

• SOAR fundamentals: Orchestration, Automation, Response—connecting tools and automating workflows
• Playbook design: Structured workflows with IF-THEN logic, enrichment, and decision points
• Common use cases: Automated enrichment, account lockout, threat intel ingestion, phishing response
• Safe automation: Approval gates, rollback mechanisms, testing before production
• ROI metrics: Time saved, MTTR reduction, analyst capacity increase
• AI-assisted SOAR: LLM playbook generation, optimization suggestions, adaptive thresholds

Next Steps¶

• Next Chapter: Chapter 8: Incident Response - Learn formal IR processes and post-incident activities
• Practice: Build a simple playbook in your SOAR platform (or sketch one on paper)
• Explore: Review SOAR vendor marketplaces for pre-built playbooks (Cortex XSOAR, Splunk SOAR)
• Optimize: Identify your SOC's most time-consuming manual task and design an automation playbook

Chapter 7 Complete | Next: Chapter 8 →