I Want A Splunk SOAR Playbook! Now What?
By Marvin Martinez, Team Lead, Automation Engineering
Security Orchestration, Automation, and Response, or SOAR for short, has added an entirely new world of capabilities to any company’s tool belt. The possibilities are seemingly endless. While that may sound like an all-out win/win situation, it doesn’t come without its considerations and potential pitfalls. Splunk SOAR is not immune to this. What do you develop first? More importantly, how do you design and develop your playbook(s)?
Developing a playbook may seem like it is mostly a technical endeavor but there very much is a significant element of “art” behind it as well! Everything from what the catalyst for your playbook will be, what fields need to be passed into it, all the way to “will there be any outputs from it?” or “does my process even need a SOAR playbook?” has to be conceptualized before you even click the “+ Playbook” button, let alone drag your first playbook block into your Visual Playbook Editor (VPE).
The first, and most important, question is “Do I need a playbook in the first place?”. Many times, you may not need a Splunk SOAR playbook to accomplish what you’re looking to do and may be able to fulfill your requirements with just a Splunk alert or something else entirely that can keep your process streamlined and not too complex. One key question that is usually useful and helping determing if a Splunk SOAR playbook is necessary is: “Are there various activities I need to achieve in sequence as part of this process and, if not, is the single action I need available within my current toolset?”. There is no need to externalize and expand your process if your current tool (i.e. Splunk, etc.) can already do it. For example, if all you need is an email when a specific incident type is generated, you could easily do that within Splunk with an alert and some clever SPL.
Ok, so you’ve decided that automation playbooks are the only way to achieve what you want. How do we design it?
Once you’ve decided that you do need to develop a playbook to meet your requirements, you now need to design the end-to-end solution for your playbook. The very nature of Splunk SOAR being versatile and powerful means that, almost by definition, your playbook solution development is a blank canvas but don’t feel daunted! Some key basic items to consider when designing your playbook are:
- Trigger: What is the catalyst/trigger for my playbook?
- Fields: Does my playbook need specific fields? If so, how will the playbook reference them?
- Playbook actions and general workflow design: What is my playbook doing?
There are much more than just these considerations when it comes to playbook design, but these are the 3 basic ones we try to work from to extrapolate into a robust Splunk SOAR playbook solution. Let’s explore them.
Trigger
Playbooks can be triggered in a myriad of ways. For example, you could have an automation playbook that is triggered automatically when a container/event is created in SOAR with a specific label (i.e. “Defender”). This is the most common method when developing playbooks. You could also develop an input playbook that is called as part of an entire playbook solution. Note that automation playbooks can be manually executed and can also programmatically call other playbooks (automation or input) but input playbooks can do neither.
With this in mind, deciding what type of playbook you need to create will largely depend on your use case as well. Generally speaking, if your playbook will be triggered from a Splunk search or other container-creating method (Splunk App For SOAR Export, etc), you’ll need an automation playbook that will execute based on the label that comes in. Configure this in your Splunk search/SOAR app configuration and the triggering of your playbook is that simple! On the other hand, input playbooks are more useful as part of larger playbook solutions or for more “ad-hoc” type executions that you want to call repeatedly from different playbooks. Think more of an “Send Email” playbook that would take in various inputs (Subject, recipient, etc.) and send an email but also generate notes or comments and perform some common status updates or things like that along the way that you don’t want to keep developing over and over in different playbooks.
Fields
So, you know what type of playbook you’ll need and how you’ll kick it off, but what does it need to do its job? Generally, if you’re kicking off a playbook from a Splunk search, some things to consider passing along are things like Incident IDs or any other identifying information that your SOAR playbook might need to execute its actions. Things like email addresses, usernames, timestamps, and error codes or error messages are common things that get passed along because they will likely make it easy for the SOAR playbook to send emails or reach out to its app integrations to get additional details using those identifiers. These fields will be populated in the artifact that gets created in the SOAR event/container and the playbook can easily read the data from there. You want to be careful to pass in your fields in meaningful and considerate ways: keep the field names free of special characters other than underscores as Splunk SOAR has issues with special characters, notably periods (.)!
Playbook Actions/Workflow Design
So, your SOAR container is showing up with the appropriate label and the fields are in the artifact. What’s my playbook supposed to do and how should it do it? This is where “art” and “science” intersect! It’s usually best to go back to fundamentals and simply create a workflow of what your business process looks like and begin to “SOAR-ify” it from there. Keep in mind a couple of the key SOAR development principles:
- Modularize as much as possible. Develop smaller playbooks that work together instead of big, bulky playbooks where many more things can go wrong and it’s harder to troubleshoot or re-execute without doing too many things over.
- Try to keep custom code within playbooks to a minimum. Create custom functions that can be reused as much as possible. This helps you eliminate having random code snippets all over the place and begins to help you build a library of “helpers” that you can use efficiently and repeatedly in future developments.
Let’s consider a small example use case. A customer has Microsoft Defender data coming into their Splunk environment and they want to create a container in SOAR for every unique incident ID that comes in. Once this event is generated in SOAR, their playbook solution needs to take the incident ID and gather additional details for the Incident ID using their defender integration (status, description, comments, etc) and then send an email with that information to a specific group of people based on a lookup in Splunk. Here’s what a sample workflow would look like:
In this case, you could design and develop a single playbook that would use the Incident ID present in the artifact and execute an action with the Microsoft Defender app integration to gather the incident details. This information comes back in JSON format and can contain extraneous information that isn’t relevant so the customer could develop a custom function that would take that JSON payload and extract the pertinent information and format it in an HTML-friendly string to send the email. After this, the customer could execute a Splunk app action with an SPL query to retrieve the user email list. Now, having all the information necessary, the Send Email step in the workflow could easily be converted into an input playbook of its own that would have some inputs (Recipients, Subject, Body) and would be able to take those inputs, send the email using the SMTP app, update the status to “Closed”, and add a comment to the container with confirmation of the email being sent. Once the small input playbook is developed, simply take the output from the custom function to populate the Body input to Send Email and the output of the SPL query from the Splunk app integration to populate the Recipients input to the Send Email playbook. The Subject can be hardcoded or a formatted input as well.
As you can see, even a somewhat straightforward use case still required some design thought, two separate playbooks, three separate apps (Defender, SMTP, Splunk) and a custom function (mostly as a best practice). But, it resulted in a seamless playbook that does exactly what the customer needs and can be easily customized in the future should something change (i.e. additional users to email or updates to “pertinent” information from the Defender incident) and an input playbook that can now be used in the future to send an email and close out a container.
Splunk SOAR is immensely useful and powerful. Taking adequate time to conceptualize and think through how you want to leverage that power and capability can provide immense dividends downstream as you grow your playbook library along with other objects like custom functions, custom lists, etc. So, don’t feel overwhelmed, take your time and let SOAR automations simplify your business processes!