How to Build a SOAR Playbook
Building SOAR (security orchestration, automation, and response) playbooks can be challenging if you haven’t built them before. This is because the number of possible designs for any new playbook is so high. There may be out-of-the-box playbooks that vendors provide but these require major improvements and changes in order to apply to your environment.
Start with integration commands
Every SOAR customer has a set of tools they integrate into the platform. The SOAR tool you use will have a list of commands available for each integration. Some provide commands out of the box, others require you to code them yourselves. Here are the integration commands available for SentinelOne, Palo Alto, and Active Directory in D3 SOAR. I’ll use them as examples throughout this article.
Available integration commands are the possible ingredients of your playbook. By starting with integration commands you have a more defined set of possibilities rather than a blank canvas. By not starting with these constraints, playbooks often become overly complex or too simple.
Group integration commands
The next step is to organize the integration commands into one of four categories:
- Enrichment
- Containment
- Recovery
- Case management
These have stood out as four core stages to incident response playbooks.
Identify important artifacts
Once your integration commands are listed and categorized, the second step is to know which artifacts will appear in your data. Some examples are device ID, user ID, process name, and file hash. The list is dependent on your detection rules, environment, and use-case. In this scenario it helps to use raw data from an alert you’d like the playbook to address.
Map integration commands to artifacts
For this example I’ll use device ID, user ID, and IP address. Now I’ll narrow down the large list of integration commands to include only those that accept these artifacts as an input. This shortens the list to only those that could be relevant for this playbook.
Build playbook stages
Select across each group of commands for those the commands that make sense. Here’s a workflow that uses three commands from each integration to automate alert enrichment. It collects:
- User groups, management chain, and activity logs.
- Blocked and allowed IP addresses and active security rules.
- Device information, applications, and processes.
Alert enrichment is the core value proposition of SOAR. It is the simplest to build, eliminates the highest number of repetitive tasks, and adds the most value in helping users make better decisions, faster than any other playbook step.
The second stage to build out is containment. This would be triggered by a manual task after the user has reviewed the information collected in stage one. Here, the playbook uses Active Directory, Palo Alto and SentinelOne to:
- Revoke sign-in sessions, reset the user’s password and remove them from high privilege groups.
- Update active security rules and address groups to include the new IP address.
- Initiate a scan on the affected host, quarantine it, and add the threat to a blacklist for further prevention.
The third stage, recovery, is typically triggered manually like containment. It can reconnect the host back to the network and remove our IP from our blacklist. Then it can unblock the IP address from the firewall and re-add the user to the groups they were originally a part of, minimizing the containment’s impact on day-to-day operations.
Takeaway
The planning, organization, and trimming done before getting to the playbook building stage makes command selection and playbook design more straightforward. So you don’t feel like you’re boiling the ocean, start by answering these four questions:
- Which integrations are we going to use?
- What commands are available for those integrations?
- Which artifacts are we working with?
- Which integration commands can process those artifacts?
This will reduce the number of possibilities for your playbook down to a few that make sense.
