SOAR & Playbook Engine

AuroraSOC includes a built-in SOAR (Security Orchestration, Automation, and Response) engine that executes predefined playbooks for automated incident response. Playbooks combine automated actions, conditional logic, and human approval gates into repeatable response workflows.

Runtime Truth

Showcase SOAR playbooks and automation rules are available in dummy mode. In dry_run and real modes, the Playbooks and Execution views are backed by the live PostgreSQL playbook tables. The Rules tab is backed by the automation_rules database table — rules you create persist across restarts and are evaluated autonomously against every new alert.

Playbook Architecture

Available Playbooks

In dummy mode, AuroraSOC ships with six showcase playbooks:

Playbook	Trigger	Actions	Approval Required
Malware Response	Malware detection alert	Isolate → Scan → Block → Report	Yes (isolate)
Phishing Response	Phishing alert	Extract IOCs → Block URLs → Notify users → Report	No
Ransomware Emergency	Ransomware indicator	Isolate all → Snapshot → Forensics → Exec brief	Yes (isolate)
Brute Force Mitigation	5+ failed logins	Block source → Reset credentials → Audit → Report	Yes (credential reset)
Data Exfiltration	DLP/network anomaly	Block egress → Capture traffic → Forensics → Report	Yes (block)
CPS Anomaly	CPS device alert	Quarantine segment → Verify firmware → Attestation → Report	Yes (quarantine)

In dry_run and real modes, the dashboard shows only the playbooks stored in the live database. If no playbooks have been configured yet, the page stays empty instead of fabricating seeded rows.

Playbook Execution Detail

Step Types

Each playbook step executes one of eight registered actions:

Action	Description	Reversible
isolate_host	Network-isolate an endpoint	Yes
block_ip	Block IP at firewall/NGFW	Yes
disable_user	Disable Active Directory account	Yes
revoke_certificate	Revoke TLS/device certificate	No
run_scan	Execute endpoint scan	N/A
collect_forensics	Gather forensic evidence	N/A
enrich_ioc	Enrich IOC via threat intel	N/A
notify	Send notification	N/A

Conditional Branching

Steps can include conditions based on:

• Alert severity
• Asset criticality
• Device type (IT vs. OT/CPS)
• Previous step results
• Time of day (business hours vs. after-hours)

Rollback on Failure

If any step fails, the engine automatically rolls back completed actions in reverse order:

Playbook Dashboard

Critical playbooks now enforce a human approval gate in the dashboard instead of executing immediately.

Playbooks Tab

• Critical playbooks display an Approval badge
• Clicking Request Approval creates a pending approval request instead of starting execution
• Non-critical playbooks continue to execute immediately when triggered manually

Pending Approvals Tab

AuroraSOC now includes a dedicated Approvals tab in the SOAR workspace for users with approvals:manage.

From that tab, analysts can:

• review the requested playbook and risk level
• approve or deny the action
• automatically launch the gated playbook after approval

Execution List

Shows all playbook runs with:

• Playbook name and triggered alert
• Start time and duration
• Status: Running / Completed / Failed / Rolled Back
• Steps completed vs. total steps

Rules Tab

In dummy mode the Rules tab shows showcase data. In dry_run and real modes the Rules tab reads from the automation_rules PostgreSQL table.

Automation Rule Engine

When a new alert is ingested (via any source — API, SIEM bridge, Suricata EVE, or CPS), AuroraSOC automatically evaluates every enabled rule in priority order and triggers matching playbooks without any manual intervention.

How rules match:

Condition field	Match logic
severities	Alert severity must be in the list (empty = match all)
sources	Alert source must be in the list (empty = match all)
statuses	Alert status must be in the list (empty = match all)

Cooldown protection: Each rule has a cooldown_seconds window. Once a rule fires, it will not fire again for that many seconds — preventing alert storms from spawning hundreds of identical playbook executions.

Priority ordering: Rules with a lower priority value (default 100) are evaluated first. Use priority 1 for critical catch-all rules.

Managing Rules from the Dashboard

All rule CRUD operations are available from the Rules tab:

• Create: Fill in name, condition, linked playbook, priority, and cooldown.
• Toggle: Enable/disable any rule with a single click.
• Delete: Remove a rule permanently.

Managing Rules via API

# List all rules
curl -H "Authorization: Bearer $TOKEN" \
     http://localhost:8001/api/v1/soar/rules

# Create a rule that auto-triggers the malware playbook on critical alerts
curl -X POST \
     "http://localhost:8001/api/v1/soar/rules?name=AutoMalware&playbook_id=<pb-uuid>&condition=%7B%22severities%22%3A%5B%22critical%22%5D%7D" \
     -H "Authorization: Bearer $TOKEN"

# Toggle a rule on/off
curl -X POST \
     "http://localhost:8001/api/v1/soar/rules/<rule-id>/toggle" \
     -H "Authorization: Bearer $TOKEN"

# Delete a rule
curl -X DELETE \
     "http://localhost:8001/api/v1/soar/rules/<rule-id>" \
     -H "Authorization: Bearer $TOKEN"

Execution Detail

Click any execution to see:

• Step-by-step progress with timestamps
• Approval request status and responder
• Action outputs and return values
• Error details for failed steps
• Rollback log if applicable

Dry Run Mode

Test playbooks without executing real actions:

curl -X POST /api/v1/soar/playbooks/{playbook_id}/execute \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{}'

Use a playbook ID returned by GET /api/v1/soar/playbooks. In dry_run mode, AuroraSOC simulates each step and reports what would happen, allowing you to verify playbook logic before production use.

Best Practice

Always run new or modified playbooks in dry-run mode first. Review the simulated execution carefully before enabling live execution, especially for playbooks with irreversible actions like certificate revocation.

Approval-Gated Execution API Behavior

When a critical playbook is triggered manually, the initial API response now returns pending_approval plus an approval_id. After an analyst approves the request, the client replays the execute call with that approval_id and the playbook starts normally.

Creating Custom Playbooks

Playbooks are defined as JSON documents stored in PostgreSQL:

{
  "name": "Custom Response",
  "description": "Custom incident response workflow",
  "trigger": "manual",
  "steps": [
    {
      "order": 1,
      "action": "enrich_ioc",
      "parameters": {"sources": ["virustotal", "alienvault"]},
      "on_failure": "continue"
    },
    {
      "order": 2,
      "action": "block_ip",
      "parameters": {"duration": "24h"},
      "requires_approval": true,
      "condition": {"field": "severity", "operator": ">=", "value": "high"}
    },
    {
      "order": 3,
      "action": "notify",
      "parameters": {"channel": "slack", "template": "incident-update"}
    }
  ]
}