Playbooks
Build a response as a graph of steps, see what it would do before it runs, and know for every step whether it acts for real, needs a connector, or only records what it would do.
A playbook is a set of steps joined into a graph on a canvas. Steps can branch, so one alert can lead to several actions in parallel. A playbook runs on an alert — when you start it, or by itself when a new alert matches its trigger.
Triggers
Section titled “Triggers”A playbook set to run automatically starts on every new alert that matches its trigger:
- Severity — one or more of
critical,high,medium,low,info; - Tags — at least one of the listed tags.
When both are set, both must match, the same rule the detection engine follows. An empty list is not a condition.
What each step really does
Section titled “What each step really does”How a step runs depends on its action and on what your deployment has connected:
| How it runs | Means | Actions |
|---|---|---|
| Locally | The platform does it itself | Update the alert, enrich an indicator, add an address to the block list, revoke a platform session, rotate a platform account’s credentials |
| Through a connector | Sent through a connector — only if that connector is configured | Slack, email (SMTP), PagerDuty, Jira; blocking a domain (Pi-hole) |
| Through the agent | Sent to the Windows agent if a live agent is registered for the host; otherwise recorded as a dry run | Isolate a host, end a process, quarantine a file, collect forensics |
| Not implemented | Recorded only; nothing is changed | Verify backups, snapshot a VM, roll back, restore from backup |
In the editor, a step that is not implemented is marked as such, a step that always waits for approval is labelled Approval: always, and a step that goes through the agent Agent: 2nd admin. The editor refuses to save a step that cannot run.
Approval
Section titled “Approval”A step marked requires approval stops the run with the step queued. Approving it runs the step and carries the run on from there, over the graph as it was when the run started.
The step waits under Pending approvals in the top bar. Someone other than the person who started the run — ANALYST or above — approves or rejects it there. The person who started the run sees why they cannot approve it, and may withdraw it. A rejected step never runs, nothing wired after it runs, and the run ends as rejected. A run the platform started by itself, when an alert matched the playbook’s trigger, has no starter, so any ANALYST may approve its steps.
Some steps wait for approval even if the author did not mark them: blocking an address or a domain, revoking a session and rotating credentials.
Steps that go through the agent do not wait here; they wait in the agent’s own queue, where a different ADMIN from the one who asked must approve them before the agent ever sees them. See Isolation and process kill.
Test before it runs
Section titled “Test before it runs”Test run walks the graph against a real alert and shows, for every step, what would happen and why — executed, queued for approval, dry run, skipped, not implemented or not reached — with the values the step would act on, filled in from the alert. It executes nothing, writes nothing and contacts nothing.
History and versions
Section titled “History and versions”- Every run is kept with each step’s outcome, who started it and when.
- Every save is a version. Earlier versions can be opened and restored.
- Templates give a starting point; using one makes your own copy.