SOAR and Security Automation Guide

Security automation fails in two directions: too little, and analysts spend their shifts copying indicators between consoles while real incidents wait; too much, and a playbook with a privileged API key isolates the wrong server or becomes the attacker's best foothold. Security orchestration, automation and response (SOAR) covers the playbooks, integrations, case management and response actions that sit between detection and the people who decide what to do. This guide explains how to design playbooks, what to automate first, how to gate risky actions behind human approval, how to secure the automation identities that hold the keys to your security stack, where AI agents fit, and how to measure results. It is vendor-neutral, draws on NIST SP 800-61 Rev. 3, OASIS CACAO v2.0 and MITRE D3FEND, and is written for SOC leads, security engineers and automation owners.

Key takeaways

• Automate enrichment first, response second. Enrichment is read-only, high volume and safe to run on every alert; containment changes production and needs confidence, reversibility and, often, an approver.
• Write playbooks as engineered code. CACAO defines a playbook as "a workflow for security orchestration containing a set of steps (security actions) to be performed based on a logical process"; treat that workflow with version control, tests, owners and rollback.
• Gate actions by blast radius. Blocking a hash can be automatic; disabling a privileged account, isolating a domain controller or rotating a production secret should wait for a named approver with a defined timeout.
• The SOAR platform is a privileged non-human identity hub. Its integrations hold API keys, OAuth tokens and service accounts with write access to EDR, firewalls and the identity provider; protect them like domain admin credentials.
• AI agents triage, humans decide. Give SOC agents their own identity, read-mostly permissions and a human approval step for any destructive action, and assume attacker-controlled alert content will try to steer them.

What SOAR does, and how it relates to SIEM and XDR

SOAR combines three jobs: orchestration (connecting tools through APIs so one workflow can query and act across them), automation (running those workflows without an analyst clicking each step) and response (case management, task tracking and the actions that contain and eradicate). NIST SP 800-61 Rev. 3, now a CSF 2.0 Community Profile, names SOAR alongside SIEM for correlating and analysing adverse events (DE.AE-03: "Use event correlation technology (e.g., SIEM, SOAR)") and recognises automated containment: organisations can configure tools "to automatically perform some containment actions, like quarantining malware" (RS.MI-01). The idea predates the product category: the Integrated Adaptive Cyber Defense (IACD) programme at Johns Hopkins APL describes itself as "a framework enabling the integration and automation of diverse cybersecurity solutions".

For detection content and alert quality see the SIEM Guide and the Detection Engineering Guide; SOAR is only as good as the alerts it receives.

Playbooks and runbooks

NIST SP 800-61 Rev. 3 notes that "Playbooks provide actionable steps or tasks for people to perform during various scenarios or situations". In SOAR the term usually means an executable workflow, while a runbook is the human procedure it automates or supports. Keep both: the runbook explains intent and manual fallback, the playbook executes it.

OASIS CACAO Security Playbooks v2.0 (Committee Specification 01, November 2023) gives a vendor-neutral model worth borrowing even if your platform does not import it:

• Playbook types: notification, detection, investigation, prevention, mitigation, remediation, attack and engagement. Separating them stops one enormous "phishing" playbook from mixing investigation and containment logic.
• Workflow steps: start, end, action, playbook-action (call a sub-playbook), parallel, if-condition, while-condition and switch-condition.
• Command types: manual, bash, powershell, ssh, http-api, openc2-http, sigma, yara, kestrel, elastic, jupyter and caldera-cmd. The manual type matters: a human step is a first-class part of the workflow, not a gap in it.
• Sharing controls: playbooks can carry TLP data markings and digital signatures (JSON Signature Scheme with JCS canonicalisation), so a received playbook can be checked for integrity before import.

Engineering rules that prevent most playbook incidents:

• Idempotent actions: running a step twice (after a retry or a duplicate alert) must not double the effect, for example by disabling then re-enabling an account.
• Explicit inputs and validation: check that an IP is external, a hostname exists in the asset inventory and an account is not on the protected list before acting.
• Timeouts and error branches: every API call has a timeout and a failure path that creates an analyst task rather than failing silently.
• Version control and peer review: playbook changes go through the same review as detection rules, with a changelog and an owner.
• Audit trail: every action records the playbook name, version, run ID, case ID and the identity that executed it.

What to automate first

Good first candidates are high volume, low variance, read-only or easily reversible, and well understood by the team. Poor candidates are rare, ambiguous, or irreversible.

For leaked credentials, the sequence and owners are covered in the Leaked Credential Response Playbook; automate its evidence gathering and ticketing before its revocation steps.

Enrichment and case management

Enrichment turns an alert into a decision. The most valuable context is usually internal, not external:

• Asset context: owner, business service, criticality, environment (production or test) and whether the host is a server, workstation or domain controller.
• Identity context: whether the account is human, service, workload or AI agent; its owner, privilege level, MFA status and normal sign-in locations. A service account signing in interactively is a different case from a user doing so.
• Threat intelligence: reputation and sightings for IPs, domains, hashes and URLs, with the source and age attached. See the Threat Intelligence Guide.
• Analysis services: sandbox detonation, file analysis and log searches. Open-source examples include Cortex analyzers called from TheHive, with Cortex responders that act on alerts, cases and observables, such as blocking an IP at the proxy.
• History: prior cases on the same entity, which often reveals a recurring false positive or a slow-burning intrusion.

Case management is where automation meets accountability. Each case should hold the alerts, observables, enrichment results, actions taken (automatic and manual), approvals, timeline and closure reason. Microsoft Sentinel's automation rules, for example, can "Automatically tag, assign, or close incidents without a playbook" and "Create lists of tasks for your analysts"; equivalent features exist in other platforms. NIST's DE.AE-06 suggests "automatically creating and assigning tickets". Keep evidence handling aligned with your retention rules; see the Log Management and Retention Guide.

Response actions and approval gates

MITRE D3FEND gives neutral names for response actions, which helps when documenting playbooks and their risks.

• Name the approver: the on-call SOC lead for host isolation, the service owner for credential rotation, the identity team for privileged accounts. Approval requests should carry the enrichment so the approver decides in seconds.
• Define timeout behaviour: decide what happens if nobody answers. In Microsoft Defender for Endpoint's semi-automated levels, pending actions "time out after seven days" and a timeout behaves "as if the action is rejected". For an active intrusion, seven days is too long; escalate after minutes, not days.
• Protect critical assets: keep an exclusion list for domain controllers, break-glass accounts and safety-critical systems. Microsoft's automatic attack disruption, which can contain devices, disable users, revoke sessions and suspend users in Entra or Okta, supports exclusions for "critical assets that shouldn't be automatically contained". See the Break-Glass Account Guide.
• Make every action reversible: record the prior state so release, re-enable and unblock are one click. NIST's RS.MI-01 also expects handlers to be able to act manually "instead of or in addition to automated containment measures".

Automation identities: the SOAR as a privileged NHI

A mature SOAR deployment holds credentials for the EDR console, firewalls, email platform, identity provider, cloud accounts and ticketing system. Many of those integrations need write access to contain threats, which makes the platform one of the most privileged non-human identities in the organisation. Security and admin tooling credentials are prime targets: in the BeyondTrust breach a stolen API key for a remote support SaaS platform led to a major incident at the US Treasury, and the Salesloft Drift breach showed how one integration's OAuth tokens can open hundreds of downstream tenants.

• One identity per integration: never a shared "soar-admin" account. Separate read (enrichment) and write (response) identities so a compromised enrichment key cannot isolate hosts.
• Least privilege per action: grant the API scopes the playbook uses, not the vendor's default admin role. Review scopes when playbooks change.
• Prefer workload identity over static keys: use managed identities or federated workload credentials where the platform supports them; otherwise store keys in a vault with rotation. See the Secrets Management Guide and the NHI Authentication Guide.
• Restrict where they work: conditional access or IP restrictions so integration credentials only work from the SOAR's egress addresses, with alerts on use from anywhere else.
• Control who edits playbooks: anyone who can edit a playbook can make it run any action its credentials allow. Treat playbook authoring as privileged access, with change review. See the Service Account Security Guide.

AI agents in the SOC

AI agents now triage alerts, summarise cases and draft response steps. Microsoft's Phishing Triage Agent is a documented example of the pattern to copy: it classifies user-reported emails, resolves those it judges false positives, and leaves true positives open "for an analyst to investigate and take further action". It runs under its own Microsoft Entra Agent ID (recommended over a user account, which would make it inherit that user's access), with narrow permissions such as access "only to emails associated with alerts, rather than all emails", and Microsoft advises that the group monitoring the agent has "equal or higher permissions to oversee its activity and output".

• Own identity, narrow scope: each agent gets a dedicated identity and the minimum read permissions; write actions go through the same approval gates as playbooks. See the AI Agent Authorisation Guide.
• Human approval for destructive actions: agents may recommend isolation or account disablement; a person approves.
• Assume hostile input: phishing emails, file contents and log fields are attacker-controlled text that an agent reads. Test agents against injected instructions. See the Prompt Injection Guide.
• Measure agent verdicts: sample auto-closed cases weekly and track how often analysts overturn the agent; feed corrections back only through a reviewed process.
• Log tool calls: record every query and action the agent performs against the case. See the AI Agent Observability and Incident Response Guide.

Choosing a platform and operating model

• Built-in automation first: if most of your tooling comes from one vendor, its native automation (SIEM automation rules, XDR automated response) covers the commonest cases with fewer integration credentials to manage.
• Standalone SOAR: worth it when you orchestrate across many vendors, need cross-tool case management, or run a large SOC with dedicated automation engineers.
• Workflow and no-code platforms: fast to build, but check audit logging, secret storage, approval steps and role separation before using them for response actions.
• Small organisations: automate enrichment, phishing triage and workstation containment inside existing products; buy managed detection and response for the rest, and contract for visibility of which actions the provider can take automatically.
• Large organisations: an automation engineering function, playbooks as code with CI tests, a playbook catalogue mapped to detections, and quarterly reviews of integration permissions.

Rolling out automation step by step

1. Baseline: measure current alert volume by type, time to triage and time to contain, and analyst hours per use case.
2. Pick three use cases: choose high-volume, low-risk ones (enrichment, phishing triage, vulnerability ticketing) and write the runbooks first.
3. Build integrations safely: create a dedicated, least-privilege identity per integration and store its credential in a vault.
4. Run in shadow mode: playbooks enrich and recommend actions in the case but do not execute them; compare recommendations with what analysts actually did for two to four weeks.
5. Enable with gates: switch on automatic execution for low blast radius actions and approval gates for the rest; keep exclusion lists in force.
6. Test regularly: replay known alerts in a test tenant or with simulation tools, and exercise approval and rollback paths, not only the happy path.
7. Rollback: every playbook has a kill switch that returns it to notify-only, and every action type has a documented undo. Disable first, investigate second, when a playbook misfires.
8. Expand: add use cases in order of analyst time saved, and review each playbook's results monthly.

Automation supports, but does not replace, the incident response plan and its roles. See the Incident Response Guide.

Measuring results

Report automation alongside quality: a rising automation rate with a rising reversal rate means the playbooks are guessing.

Framework mapping

Common failure patterns

• Automating a broken process: a playbook encodes a triage procedure nobody agreed on, so it closes the wrong alerts faster.
• Over-privileged integrations: every connector uses a global admin account or a vendor default role, so a SOAR compromise is an estate compromise.
• Silent failures: an expired API key breaks enrichment, playbooks skip the step without error, and analysts trust empty fields.
• Automated disruption of the business: a rule isolates a server or disables a service account, and production stops. Exclusion lists and approval gates were never defined.
• Feedback loops: a playbook's own action (an account disable, a block) generates an alert that triggers another playbook, and they fight.
• Automation without metrics: no baseline, so nobody can show whether playbooks reduced response time, and the programme loses funding.

Practitioner checklist

• Baseline alert volume, triage time and containment time before automating.
• Automate enrichment for every alert type, including identity type and owner.
• Write runbooks first, then playbooks with validation, timeouts and error branches.
• Classify every response action by blast radius and assign an automatic, approval or manual gate.
• Maintain exclusion lists for critical hosts, break-glass and service accounts.
• Give each integration and each AI agent its own least-privilege identity, vaulted and restricted to the SOAR's network location.
• Keep playbooks in version control with peer review and a kill switch.
• Test playbooks, approvals and rollbacks with replayed alerts every quarter.
• Track MTTR, automation rate, failure rate and reversal rate by use case.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• OASIS: CACAO Security Playbooks Version 2.0
• CISA: Guidance for SIEM and SOAR Implementation
• MITRE D3FEND: Evict tactic
• MITRE D3FEND: Isolate tactic
• Johns Hopkins APL: Integrated Adaptive Cyber Defense
• Microsoft Learn: Automatic attack disruption in Microsoft Defender
• Microsoft Learn: Phishing Triage Agent in Microsoft Defender

Related NHI Mgmt Group resources: SIEM Guide · Incident Response Guide · Detection Engineering Guide · Service Account Security Guide · ITDR Guide