Developing SOAR use cases using workbooks and playbooks

Use cases versus playbooks

Splunk SOAR use cases and playbooks are not interchangeable terms, but they do relate to each other.

Use cases can be thought of as response plans, end-to-end processes, or standard operating procedures. For example:

• How do we handle phishing emails?
• How do we handle unauthorized access?
• How do we hand malware that has been reported?

Each use case can be represented in a SOAR workbook. These might include:

• a combination of automated (playbook) and manual (analyst) steps
• steps that take place outside SOAR

Analysts will be involved in every use case to confirm information from SOAR or make changes and recommendations. Splunk SOAR is best used to collect information and triage.

Playbooks represent one step in an end-to-end process. For example, in the "how to handle phishing emails" use case, a playbook might represent the step "investigate the IP". Playbooks are:

• modular and reusable
• categorized by the response phase

When designing playbooks, you're looking for repetitive steps in your use cases that cost your team a lot of time. SOAR can do the simplest tasks but still save your teams hours every day, for example, through writing tickets. In addition, modular playbooks that can be reused help you create more use cases faster.

Incident response framework

Incident frameworks help you develop your use cases. Frameworks provide standardization so you make sure that no steps are missed as you think about a use case. For example, the following is a simplified framework based on SANS PICERL. Each of the lettered substeps might be completed with a playbook to help accomplish the overall use case.

1. Preparation
   1. Download full content
   2. Extract attachments
   3. Open tickets
   4. Look up employee information
2. Investigation
   1. External reputation checks
   2. Internal searches for related activity
3. Response
   1. Network isolation
   2. Apply patches
   3. Update network access rules
   4. Update monitoring rules
4. Lessons Learned
   1. Incident report
   2. Process review
   3. Inform affected parties
   4. Update procedures

Workbook design

Using another framework applied to a email phishing use case, let's see how we can create a workbook.

In a SOAR workbook, this framework would be documented as follows.

Each of the tasks for each phase can be further expanded into their own diagram or workbook. The following diagram expands each of the tasks in the External Investigation phase and shows which can be accomplished with automation. Note that the Investigate Email Subject and Body Results has no automation because that is hard to do. Sometimes you can use a regular expression to look for suspicious text in the body or you might be able to use machine learning to see if the result is normal for the environment, but that's not always possible. This task might be easier for a human to do, so here there is no associated playbook. Playbooks have high-level goals - is the result fine or does it need some human analysis?

Here are the tasks written out in a workbook. We can click into these for more information, such as:

• tools and actions we want to run
• what results we should care about
• what would show us that we are looking at something malicious

Write out what you want to accomplish with each task and define it.

After you complete the definitions, you can apply Actions (which are API calls to SOAR apps) and Playbooks (which might already exist, or which need to be created).

So the process of creating a workbook can be understood like this:

• Crawl: Write the prose description of the task in a workbook.
• Walk: Identify any SOAR app actions that are applicable, and document them in a task.
• Run: Combine the actions into a playbook and automate the well-defined portion of a task. Perform initial triage in the playbook, or use it to gather and document information for analysts to use.

Playbook design

Now let's look at playbook design. Remember that the playbooks are one step in the end-to-end process documented in a workbook. Here is a sample playbook framework, the I2A2, based on one task for our sample phishing email use case:

• Inputs. What do you expect to have after you run the playbook? Examples: An email, indicator, or user employee name
• Interactions. What services and people do you interact with? What SOAR apps? Example: You need to update firewall rules, but your security team doesn't have direction access to do that. Do you need to file a ticket for that team?
• Actions. What service actions are run? What API calls? What emails are sent? What are you blocking? Do you run a reputation check?
• Artifacts / Outcomes. What are the high-level outcomes? Is a domain bad or unknown?

Here is an "investigate domains" task in diagram format, with the I2A2 steps explained.

Additional resources

Here are some examples of use cases, playbooks that might be associated with those use cases, and expected outcomes. You can find playbooks like these and more on the Splunk Security Research site.