SOAR, playbooks and workflow automation

Why this matters

Security orchestration, automation and response is the third of this objective's four lessons and the one that most directly changes what a security team can handle. An analyst spends the majority of an investigation gathering context — who owns this host, is this address known bad, has this user done this before, what else did that process do — and almost none of that requires judgement. It requires access to six systems.

SOAR removes that work. The examinable framing is precise: SOAR's value is measured by the work it removes from an analyst, not by the number of playbooks in it. A platform with eighty playbooks of which four run is a common and recognisable failure.

The second theme is the boundary between automated and human action. CAS-005 consistently rewards the answer that automates enrichment and decision support freely, and gates actions with availability or business consequences behind a person. The reasoning — that an attacker who can cause the trigger can cause the action — carries over directly from the previous lesson.

The lesson

What SOAR adds over a SIEM, stated as the work it removes from an analyst

A SIEM collects, normalises, correlates and alerts. It produces a queue. SOAR acts on that queue.

The work it removes, in the order it usually delivers value:

• Enrichment. For every alert, gather the context an analyst would gather: asset owner and classification from the CMDB, user details and recent authentication from the identity provider, reputation and prior sightings for every indicator, process lineage from the endpoint platform, related tickets. This alone typically removes the largest share of handling time, and it requires no decision.
• Deduplication and correlation of cases, so fifty alerts about one host become one case with fifty events.
• Triage against defined criteria, closing the classes that are reliably benign with a recorded reason, and escalating the rest with a reason.
• Consistency. A playbook executes the same steps at 03:00 on a public holiday as at 10:00 on a Tuesday, which is a genuine quality improvement and not only a saving.
• Containment, where it is safe to automate — covered below.
• Documentation. Every step, input and decision recorded automatically, which is the evidence the incident report and any subsequent audit needs.

The examinable distinction: the SIEM decides what is suspicious; SOAR decides what to do about it. A scenario describing an overwhelmed team with a well-tuned SIEM is describing a SOAR gap, and one describing a team drowning in false positives is describing a tuning gap — the answer is domain 4's, not this lesson's.

Writing a playbook: triggers, enrichment, decision points and human approval gates

A playbook has a standard shape, and the discipline is in being explicit about each part.

Trigger. What starts it: an alert of a given type, a case reaching a state, a schedule, or a manual invocation. The trigger must be specific — a playbook triggered by "any alert" will run against cases it was never designed for.

Enrichment. The read-only gathering above. This can be as broad as you like because nothing changes, which is why it is where automation should start.

Decision points. Explicit conditions determining the path: is the asset production or development, is the user privileged, is the indicator known bad, is the classification restricted. Each condition should be documented with its rationale, because a playbook is a policy expressed as logic and will be read later by someone deciding whether it behaved correctly.

Actions. What it does — create a ticket, notify an owner, block an indicator, isolate a host, disable an account, collect evidence.

Approval gates. A pause for a human decision, with the context already assembled. This is the mechanism that makes consequential automation safe: the playbook does all the work and stops before the irreversible step, presenting the evidence and the proposed action.

Outcome. How the case is closed and what is recorded.

Design practices worth applying:

• Start read-only. The first version enriches and recommends. Confidence to automate an action comes from watching the recommendation be right repeatedly.
• One playbook, one purpose. A playbook handling four alert types with branching becomes unmaintainable and untestable.
• Handle failure explicitly. An enrichment source that is unavailable must not silently produce a case that looks unenriched but complete — it should be marked, because an analyst reading "no prior sightings" needs to know whether that means none or unknown.
• Version and review them as code, since they hold production credentials and act on production systems — the approval posture from lesson twenty-six applies unchanged.

Automating containment safely, and the actions that must never be automatic

The line that scenarios test, with the reasoning rather than a list to memorise.

Usually safe to automate, because they are reversible, low-consequence, or proportionate to a high-confidence signal:

• Enrichment and evidence collection of every kind.
• Creating and routing cases and tickets.
• Notifying an asset owner or a user.
• Blocking a known-bad indicator at the perimeter, where the indicator has high confidence and the block is reversible.
• Quarantining an email message across mailboxes.
• Revoking a specific session or token — narrow, reversible, and high value during a credential incident.

Usually requires a human, because of availability impact, breadth, or ambiguity:

• Isolating a host, which is an outage for whoever uses it and may be a production service.
• Disabling an account, which may be a shared or service account with unknown dependencies.
• Blocking an IP range or a domain, where the collateral is unknown.
• Deleting or reimaging anything, which destroys evidence as well as the problem.
• Anything on a system whose business criticality is high or unknown.

Three principles decide the line, and stating them is worth more than either list:

1. Reversibility. If undoing the action restores the previous state in seconds, automation is far more defensible.
2. Blast radius. Actions affecting one entity are safer to automate than actions affecting a class.
3. Signal confidence. A deterministic signal — a known-bad file hash, a confirmed credential in a public repository — supports stronger automatic action than a behavioural anomaly.

And the attacker consideration from lesson twenty-seven, which is the one most often missed: if an attacker can cause the trigger, they can cause the action. Automation that disables an account on a brute-force alert can be used to disable accounts by generating brute-force alerts. Where an action is weaponisable, either gate it or bound it — for example, a cap on how many accounts may be disabled automatically in an hour, after which the playbook escalates rather than continuing.

Measuring a playbook by time saved and error rate, not by number of playbooks

Programmes report the number of playbooks built because it is easy to count. It measures nothing, and the measures that do are all available.

Per playbook:

• Executions, and the trend. A playbook that has not run in ninety days is either unnecessary or broken, and both need action.
• Time saved per execution, estimated from the manual baseline, multiplied by executions. This is the business case and it belongs in the board report from lesson three.
• Error rate — executions that failed, and why. A high rate usually means an upstream API changed.
• Accuracy, where the playbook makes a determination: how often did an analyst reverse it? A playbook auto-closing alerts that turn out to matter is actively harmful, and this is the measure that catches it.
• Intervention rate at approval gates: how often the human approved the proposed action. A gate approved 99% of the time is a candidate for automation; one approved 60% of the time is doing real work and must stay.

Programme level: median time from alert to first action, the proportion of alerts touched by automation, and analyst time returned to proactive work — the last being the outcome the investment was made for.

The measure worth singling out is accuracy, because its absence is how these programmes fail quietly. Automation that closes cases incorrectly looks identical in every dashboard to automation working well: the queue shrinks, handling time falls, and the missed incident surfaces months later. Sampling auto-closed cases for review is the control, and it is the analogue of the canary discipline this library applies to every check — evidence that the thing can be wrong, deliberately gathered.

The playbook that breaks quietly when an upstream API changes

The closing failure mode, and it is the same shape as the integration failures in lesson twenty-one because it is the same underlying cause.

A playbook depends on many external systems. Any of them can change a field name, deprecate a version, alter a response shape, throttle differently, or expire a credential. When that happens the playbook usually does not stop — it continues with a missing value.

What that looks like in practice, and why it is dangerous:

• A reputation lookup returns an error; the playbook treats the absent result as "not known bad" and closes the case.
• An asset lookup fails; the playbook cannot determine criticality, defaults to low, and routes a production incident to a low-priority queue.
• An enrichment returns an empty list because of pagination or a permission change; "no prior sightings" is recorded as a fact.

In every case the output is plausible and wrong, and the case looks handled.

The engineering that prevents it:

• Distinguish "no result" from "no answer" everywhere, and carry that distinction into the case. Absent evidence must never be recorded as negative evidence — the same rule this library applies to a check that could not measure something, where not-measured is a third result and never a pass.
• Fail the playbook on enrichment failure for the enrichments that matter, rather than proceeding with a gap.
• Monitor the playbook's own health: execution count, error rate, and the proportion of executions where each enrichment returned data. A source whose hit rate drops from 80% to 0% overnight has broken, whatever its error code says.
• Test playbooks on a schedule against known inputs with known correct outputs, in the way any other production code is tested. A playbook is code holding production credentials, and the fact that it lives in a security product does not exempt it from the engineering standards the rest of this domain applies.