Understanding playbook types in Splunk SOAR
Splunk SOAR playbooks are a great way to automate security workflows so that analysts can spend more time performing analysis and investigation. However, you need to use the correct playbook type if you want your automation to work as intended. This article explains the difference in types and when each should be used.
How to use Splunk software for this use case
- SOAR type (formerly known as automation type) playbook: Designed to work on data created by SOAR apps (meaning containers)
- Splunk Enterprise Security (ES) type playbook: Designed to work on ES findings and investigations. For example, if you need to update a note on finding or investigation, the playbook needs access to those data paths. Additionally, if you have analysts who use ES to manage cases, they need access to the playbooks without having to toggle between interfaces. Converting SOAR type playbooks to ES type enables this functionality.
- Input type playbook: Designed to work on data fields specifically passed to it, not all the data from an event.
As of SOAR 6.4.1, refactoring the playbook type is easy. When you have Splunk Enterprise Security and Splunk SOAR paired, you will see a playbook type dropdown menu that allows you to change the type. For more information, see Manage settings for a playbook in Splunk SOAR (On-premises).
Automating with Splunk Enterprise Security type playbooks
The following diagram shows how Splunk Enterprise Security 8 automation works, which is key to understanding how to use the playbook types discussed above. Event-based or finding-based detections in ES go to the analyst queue as a finding, but simultaneously check to see if there is automation available for the scenario. If so, they launch a playbook and generate a container (event) for the automation. Then, when an analyst looks at the finding, that person might also run automation, at which time ES checks to see if there is a paired container for the finding. If not, it creates the container. So for every finding, there will be a container on SOAR created one way or the other.
ES 8 automation dispatch can be one-to-one, one-to-many, or many-to-many. For example you might say "I would like this detection to fire this playbook every time if produces a finding" or have 100 detections always produce three playbooks. Not that ES will not dispatch any automation on manually created findings.
Keep in mind that findings and investigations are different, and ES will not dispatch a playbook on investigation creation. However, an investigation can see all the containers that are paired with any finding in the investigation.
Automating with SOAR type playbooks
What if you want to start with SOAR and generate a finding or investigation in Splunk Enterprise Security?
- Create a SOAR-type playbook that is active on a label (see the instructions for on-premises or cloud).
- Add the following blocks to the canvas when building the playbook:
- Splunk block to create finding with data from container
- ES block for “Refresh finding or investigation”
- Custom code block to set a new key with finding ID
- Custom code block to launch child ES-type playbook
- Edit launch playbook to launch it against the newly created container.
Additional resources
Now that you have an idea of how each type of playbook can help you achieve your automation use cases, watch the full .conf25 talk, (Best) practices make perfect: Automating smarter, not harder with Splunk SOAR. In the talk, you'll learn about lots more ways to improve your playbook design, and you'll also learn how to work with the SOAR community.
In addition, the following resources might help you implement the guidance in this use case:
- Splunk Help: Create a new playbook in Splunk SOAR (On-premises)
- Splunk GitHub: SOAR (Phantom) playbooks
- Splunk Lantern Article: Developing SOAR use cases using workbooks and playbooks
- Splunk Lantern Article: Improving SOAR playbook design