SOAR
Also known as: security orchestration, automation and response
A platform that ties a security team's tools together and runs the routine steps of handling an alarm by itself.
Draft - this entry has not been reviewed yet.
Formal
Software that receives alarms, mostly from a SIEM, and runs stored step-by-step plans across other tools, such as looking up an address in threat intelligence, locking an account or isolating a laptop, while keeping one case record for the analysts.
In plain English
Like a kitchen where the prep cook does all the chopping and measuring from the recipe, so the chef only has to make the real decisions.
In practice
When a clerk at a municipality reports a phishing email, SOAR pulls out the links, checks them against known bad sites, deletes the same email from every inbox and hands the analyst a finished summary.
Why it matters
Teams get far more alarms than people can handle by hand; taking the routine steps off their hands answers attacks in minutes instead of hours.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- Pick the handful of alert types that take the most analyst time and follow the same steps every time, such as reported phishing emails, and write those steps down as they are done by hand today.
- Sort each step by risk - enrichment and deduplication can run fully automatically, reversible containment such as quarantining a file can run on high-confidence detections, and disruptive actions such as isolating a server or disabling an executive's account need a human approval step.
- Connect the tools the playbook needs, such as SIEM, EDR, email, identity and ticketing, using service accounts with only the rights each action requires, and store their API keys in a secrets vault.
- Build the first playbook, run it in a mode that only suggests actions, and compare its verdicts with the analysts' before letting it act.
- Keep playbooks under version control with an owner, review changes before they go live, and test them again whenever a connected tool or API changes.
- Restrict who can edit playbooks and administer the platform, and send the platform's own audit log to the SIEM.
- Measure time saved, time to respond and wrong automatic actions every month, and only expand automation where the underlying detections are reliable.
Common pitfalls
- Automating actions on top of noisy detections, so false positives turn into outages.
- Giving the platform broad administrator rights across every tool, which makes it a prize target for attackers.
- Letting playbooks break silently when a connected API changes, so nobody notices that the automation stopped working.
Good guides
Technical deep dive
The term SOAR was popularised by Gartner around 2017 to describe the convergence of three earlier product categories: security orchestration and automation, security incident response platforms (case management) and threat-intelligence platforms. A SOAR platform has four core components: integrations (connectors wrapping the APIs of SIEM, EDR, email, identity, firewall, ticketing and threat-intelligence tools), playbooks (workflows of actions, conditions, loops and human approval steps, usually built in a visual editor or as code), a case management layer that records artefacts, tasks, evidence and timelines, and metrics reporting. Well-known products include Splunk SOAR (formerly Phantom), Palo Alto Networks Cortex XSOAR (formerly Demisto), and Microsoft Sentinel's automation rules and Logic Apps playbooks; newer tools such as Tines market themselves as general security automation platforms.
A typical playbook for a reported phishing email parses the message, extracts observables (sender, URLs, attachments, hashes), queries reputation services and sandbox detonation, searches the mail platform for other recipients, and branches: benign verdicts are closed with a reply to the reporter, while malicious verdicts trigger purging of the message from all mailboxes, blocking of indicators and, after analyst approval, containment such as disabling the account or isolating the endpoint. OASIS's CACAO Security Playbooks specification (version 2.0, 2023) defines a vendor-neutral JSON format for describing and exchanging such playbooks, though adoption in commercial products is still limited.
The design principle that matters most is graduated automation. Enrichment and deduplication are safe to automate fully; reversible containment (quarantining a file, forcing a password reset) can often be automated for high-confidence detections; disruptive or irreversible actions (disabling an executive's account, isolating a production server, blocking a cloud provider's IP range) should require a human decision. Automating actions on top of noisy detections scales false positives into outages, so playbook quality is bounded by detection quality.
SOAR introduces its own risks. The platform stores API credentials with broad privileges across the security stack, making it a high-value target that needs strict access control, secrets management, change control on playbooks and audit logging of its own actions. Playbooks decay silently when connected APIs change, so they need testing like code. SOAR differs from a SIEM, which collects and correlates events to raise alerts, whereas SOAR acts on those alerts; the categories are converging as SIEM and XDR platforms build in automation, and AI assistants are increasingly used for enrichment and summarisation within these workflows, which calls for the same approval gates as any other automated action.
What to learn first
Everything this builds on, foundations first.
Relationships
- A kind of
- Security control
- Requires
- SIEMAlert triage
Sources & further reading
Standards & official texts
Reference works
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…