What is SOAR and how does it work?

[Backstory: I’ve been using Phantom, Komand, and Demisto for several years and I’m always meeting people that are just getting started. If you’re looking to get into the SOAR space, but aren’t sure what it’s like (dream vs. reality) before spending the company bucks on it, I’ve documented the mechanics of these tools and considerations I’ve come to learn are important to think about before putting them to use.]

So… what is it?

Security orchestration, Automation, and Response (SOAR) is an intermediate programming layer to communicate with security tools that have an API for data enrichment and automated response. Doing so shortens development time and provides opportunities that custom coding may have missed. It’s similar to a Security Incident Event Monitor (SIEM), which provides uniform visibility and alerting into security events, except SOAR provides uniform responses to those events.

It’s a capability that big Silicon Valley companies have developed on their own, and if you really wanted to, you could develop yourself. But if you’re like me, then you need to prioritize your time in a different area of your work, and would rather your company let you use the thing so you don’t have to architect, develop, debug, and then use the thing.

The implementation

A high level view of how an input event is handled looks like this:

• A JSON object of some event is sent to the REST endpoint of the SOAR platform.
• The platform, typically written in a combination of Go, Python and JavaScript, parses the JSON into its constituent parts, with key names and values adapted to values that can be used elsewhere.
• An object or container is created to house all the information about the event, which will include any future data enrichment added by other security tools.
• A “workflow” or “playbook” that’s assigned to the event type executes, and attempts to apply control logic to the fields presented.
• The workflow can then decide to respond automatically or to wait for human interaction.
• If executed, the playbooks coordinates the response across all of your security tooling and is totally automated, leaving no room for human error.
• All the actions taken are logged for compliance with your local or global regulations.

Some of these tools accomplish this via Docker containers, which fit in nicely with the idea of a playbook passing input into a container and retrieving a specific output, while other tools may provide a generic coding environment with additional modules and debugging.

Considerations when buying/developing a SOAR platform

Your security tooling may not have API connectivity! If you’re using a legacy product for firewall maintenance, or email boundary protection, chances are there’s no way to remotely tell it to block or allow this or that domain name, short of some Burp (a web application analysis tool) replays or gnarly UI scripting and a homespun REST endpoint. Take an inventory of what systems you are currently using and whether they even have an API to interact with.

Experience has taught me that a product may have an API but not support all the specific actions you need it to perform. Have a look at what actions they actually support via API before spending money on a tool that won’t integrate with what you have. If you have a security tool with no API or an API that doesn’t cover the actions you need then I actually recommend replacing it entirely with one that’s API-centric and then getting a SOAR product afterward.

Carefully consider what your current development preferences and workflows are for adding new functionality. If your team is mostly diehard coders that spar in the “best text editor” debate, you might consider SOAR platforms that aren’t Docker based. Most of the platforms force UI interactions on you when developing automation, but the Docker based implementations tend to be more UI heavy than not. This isn’t a functional limitation, but it can be a point of friction and make some people want to use it less.

Finally, consider whether the response you want automated can and should be “automatic”. A judgement call on a VirusTotal value is dubious and not always repeatable between analysts. One domain with 15/56 detections might be malicious, but a domain with 20/56 might still be benign. If you’re employing SOAR, you must determine whether your control logic is deductive. Only if the response is always appropriate given the inputs, then you can automate it, otherwise a human should probably be involved in the decision making process.

‘Gourmet’ considerations

These shouldn’t dramatically affect which SOAR product people will invest in, but people who have or are on mature security teams will want to consider:

• How the platform controls the credentials to all the security tooling it connects to. Find out if they are able to use a credential store like Hashicorp’s Vault, or if they sit in plaintext within a SQLite database.
• Whether the platform supports SAML authentication, and if they don’t, determine how they’ll support multi-factor authentication (MFA) on the platform.
• Whether you can create reasonable role based access controls (RBAC) within the system, or better yet, attach it to existing AD security groups or SAML groups.
• How you’ll debug and troubleshoot issues in development, and what tools the vendor supplies to assist with debugging (sad hint: It’s probably the equivalent of “printf debugging”).
• Whether or not it has a Command Line Interface (CLI), even if it’s embedded in the UI. A CLI allows instant trial and error and greatly reduces development time for your engineers.
• Whether your development can be versioned and managed outside of the platform and what that looks like (e.g., Docker based playbooks tend to be YAML based and many times rely on UI editing vs. code-only approaches).

I suck at writing conclusions, but my final thoughts are that you probably need one, think about it first, I think it’s better to buy rather than develop, Demisto is my current favorite, and I am way too nerdy about this niche of Blue Teaming.