Building a SOAR playbook for container enrichment
It is common for manual SOC processes to scale poorly and consume considerable amounts of analyst time, detracting from actual analysis or impeding progress towards making a disposition. For example:
- An incident comes into Splunk Enterprise Security which contains Indicators of Compromise (IOCs) for analysis.
- The analyst copies and pastes multiple URLs / domains / IPs one by one from the incident into one or more private or public reputation lookup services.
- They then copy and paste results or screenshots from that service back into Splunk SOAR or a ticketing system such as JIRA.
While seemingly necessary, a lot of time wasted in this process. You can improve total time spent and analyst experience by creating a SOAR playbook to automatically provide enrichment of such indicators.
This article assumes that you already know how to write SOAR playbooks. If not, see Create playbooks in Splunk SOAR, and then come back to this article.
How to use Splunk software for this use case
This sample playbook uses VirusTotal v3, which can be swapped out to any service. It gathers URLs from the container and runs a custom script to ‘re-fang’ an URL, a process that protects you against passing around potentially malicious URLs. Those are then run against an action block. Here are the components:
Format Block: First, we leverage format block markup %% to list URLs as an array. The double percent grabs each URL and forces it into a list. This will be passed down into the custom code in the next block.
Code Block: As the URLs are typically 'de-fanged' we can use custom code to replace characters to 're-fang' the IOC for processing. Some services will support the upload of defanged IOCs, so it depends on your specific scenario if this is required or not.
If you're unfamiliar with the concept of 'defanging' indicators, it's quite simple. Often, for safety, a suspect indicator is modified in order to prevent an accidental click from an analyst, automatic page previews within a browser, or blocking by another security tool. Common examples include replacing https:// with hxxps:// @ with [at], and periods with [.]
For example, https://lantern.splunk.com becomes hxxps://lantern[.]splunk[.]com, and pwny@splunk.com becomes pwny[at]splunk[.]com
Instead of implementing custom code, another option is to use eval statements within Splunk SOAR. 
Format Block: The now ‘fanged’ URLs are gathered into an array again to send to the next action block.
Action Block: The input uses formatted_data.* This makes the action block run for each item in the array that was passed down in the previous block.
If we simply used the *option, it would try to pass everything as a single string and the VirusTotal API would fail to parse the input.
After the action block is run, it passes each value to the reputation service and returns a score. This information can then be added to the container for additional context, and used by subsequent blocks for further automation.
In this example, some simple filtering occurs to determine if a result was found:
- If successful (result): Continue on path and build out as desired, for example, detonate or not.
- If unsuccessful (no result): Update Splunk Enterprise Security and finish.
Additional resources
This article is one of many in a series on using SOAR automation to improve your SOC processes. Check out the additional playbook guidance or some of the links below to continue getting more value out of Splunk SOAR.
- Splunk Lantern Article: Understanding playbook types in SOAR
- Splunk Lantern Article: Improving SOAR playbook design
- Splunk Lantern Article: Applying useful SOAR playbook design features
- Practical SOAR examples from the field (.conf24) [ recording | slides ]
- Practical SOAR examples from the field: Part 2 (.conf25) [ recording | slides ]