SOAR & Playbooks
The SOAR engine runs durable, approval-gated response playbooks as directed acyclic graphs over Temporal workflows. Playbooks are authored in a visual builder, validated against hard safety rules, published, and bound to event triggers — in shadow mode first, then automatic.
Engine
antemure-soar is one process that is both an internal API and a set of Temporal workers. It connects to Postgres (API and worker roles) and Temporal, builds the integration registry, and runs four workers (orchestration, integrations, endpoints, webhooks) plus a transactional outbox and a notification dispatcher. It listens on 18902 and is reached only through the hub, which proxies /api/soar/* with a proxy secret and tenant header. Stand it up with scripts/install-soar.sh (systemd + Postgres 16 + Temporal containers) or the aura-soar Helm chart — see Deployment.
Playbook model
A playbook is a directed acyclic graph of nodes and edges with an input schema and a content hash. Node kinds: Trigger, Action, Condition, Approval, Delay, Success, Failure, Escalation (Parallel/Join exist in the type system but are not executable in this release). Edges connect nodes and carry an outcome — condition nodes branch on true/false, everything else follows success.
Validation rules
Both the builder (client-side) and the server enforce the same rulebook before a playbook can be published:
- Exactly one Trigger; unique node ids; every edge references known nodes; at least one terminal (Success/Failure/Escalation); the graph is acyclic; every node is reachable from the trigger.
- Action nodes must carry a known built-in capability, with config validated per capability.
- Condition nodes require exactly one
trueand onefalseoutgoing edge; Trigger/Action/Approval/Delay require exactly one outgoing edge; terminals have none. - Destructive capabilities (revoke sessions, suspend user, block network, quarantine file) must sit behind an Approval node on every path from the trigger.
- No raw secrets — tokens, passwords, private keys and bearer headers are rejected unless supplied as a
*_refvault reference.
Built-in capability catalog
Each capability has an input/output schema, a risk class (read / write / recoverable / destructive) and a verification. Grouped:
| Category | Capabilities |
|---|---|
| Identity | identity.enrich (read), revoke_sessions, suspend_user, mfa_reset, reset_password (destructive), enforce_mfa (write) |
| Endpoint | block_network, quarantine_file, isolate_host, kill_process, remove_persistence (destructive), collect_forensics (read), restart/start/reload/enable_service (recoverable) |
| Network / Cloud / Email | network.firewall_block_cidr, network.dns_sink, cloud.disable_key, cloud.revoke_role, email.quarantine, email.block_sender |
| Intel / SIEM | threat.enrich_ioc, siem.pivot_search, siem.enrich_alert (read) |
| Ticketing / Notify | ticket.create (Jira), webhook.signed, notify.google_chat, notify.slack, notify.pagerduty |
Some catalog entries have schema and validation but no runtime adapter yet; a run that reaches one fails cleanly with “no integration adapter registered.”
Autonomy policy
A published playbook version can carry an autonomy policy: minimum confidence, approval-below-confidence, max runs per hour (default 20), allowed incident types, device scope (allow/exclude), and approval requirements on protected assets or expanded scope. At event time the engine evaluates the policy and returns whether a run is eligible and whether approval is required.
Triggers
A trigger binds a published playbook version to an event source: manual, integration-alert, antemure-incident or antemure-remediation. Triggers carry a matcher, a priority and a mode — shadow (default; evaluates but doesn't act), automatic, or paused. Events arrive at POST /api/soar/events (the hub forwards alerts and incidents) and are matched against triggers. Creating a trigger needs Admin; changing its mode needs Operator.
Execution
The Temporal workflow walks the graph from the trigger, following edges by outcome. Conditions evaluate a JSON-pointer against the event with operators (exists, equals, contains, greater/less-than, …); delays use a durable timer (capped 1 h); approvals set waiting_approval and block on a decision signal up to a timeout (default 1 h, deny → denied, timeout → escalated) — skipped only when the run is autonomous and the policy marked approval not required. Actions run on the matching worker queue with retries. Endpoint actions are issued to the fleet as signed commands (HMAC over a canonical string binding tenant/device/run/step/action/target/expiry), dispatched through the hub, and the result is verified (executed && verified) before the step succeeds. Each step is idempotent (effect-cached by run:step:version) and persisted for audit.
Visual playbook builder
The builder (React Flow, served by the hub at /soar-builder/ and embedded in the dashboard's SOAR tab) is a drag-and-drop canvas. Entry screen: start blank, import YAML, or load one of three templates (endpoint containment, identity compromise, device reference triage). Builder shell:
- Toolbar — playbook name, save-status indicator, Visual/YAML tab switch, and Export YAML, Save, Validate (local + server), Publish (which auto-creates a shadow-mode trigger), Close.
- Node palette (left) — draggable Start/Logic/Response/Finish blocks: trigger, condition, approval, delay, action, success, failure, escalation.
- Canvas (center) — React Flow with smoothstep edges, a minimap, zoom controls, keyboard delete and marquee select; condition nodes expose YES/NO handles; terminals have no outgoing handle.
- Property inspector (right) — per-node fields: trigger source + matcher JSON; action capability select with capability-specific sub-forms (Jira fields, signed-webhook url/secret-ref, Google Chat ref, allowed-hosts); condition pointer + operator + value; approval role + instructions; delay seconds; terminal message; an Advanced-JSON escape hatch; and Remove.
- YAML view — the full portable playbook envelope, round-tripping with the graph.
The dashboard's SOAR tab wraps the builder with a playbook list, a run form (pick a device, Run), the published graph, an Autonomous execution panel (admin authorization, trigger mode, tenant emergency pause/resume), a runs list, and a run-inspection view with per-step approvals and audit.