Skip to main content

 

Splunk Lantern

Developing SOAR use cases using workbooks and playbooks

 

Splunk SOAR is a security orchestration, automation, and response platform that combines security infrastructure orchestration, playbook automation, and case management capabilities. It integrates your team, processes, and tools to help you orchestrate security workflows, automate repetitive security tasks, and quickly respond to threats. The best use of Splunk SOAR is to only send events to it that need work done. You should not use it as a replacement for a SIEM, like Splunk Enterprise Security or for general notifications and alerts that don't require action.

SOAR is also not a replacement for a well designed SOC and experienced SOC analysts. Although SOAR is excellent at automating processes that are well-defined, it is more like a SOC intern than an experienced analyst. It can free up analysts' time for tasks that require more critical thinking. Additionally, the better your SOC processes are, the more useful SOAR will be to your team.

If you are a new Splunk SOAR customer, start with the guide Getting started with SOAR and then return to this article for some expert recommendations on how to best to use SOAR in conjunction with the Splunk platform to improve your processes.

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.

clipboard_ecb69102ddbb86e73fa3ff4c3415b5d51.png

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

clipboard_e67cf7e6cd58e28822c52aa728329a2c8.png

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?

clipboard_e2bb1287b655d615a0bf00c828b112c5f.png

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.

clipboard_e585cf451a773fab9a2b6cd4be89c6b47.png

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).

clipboard_e88694e7fd0c2b507dc96894a7566b37e.png

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.

You don't have to complete a workbook all at once. You can focus on one phase at time, and add or change as needed. Even a rough, high-level workbook will give your analysts a process to follow, and as your organization matures, you'll add more and more actions into playbooks.

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.

clipboard_e561cb942b62a09c3c73036b15c02097a.png

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.

Investigation

Description: Complete the bulk of an investigation on an indicator of compromise and maybe some high level triaging. Query third-party sources about indicator reputation, summarize results, and save in a note or tag a reputation to the event.

  • investigate domains
  • investigate URLs
  • investigate email
  • investigate file attachments

Outcome: time saved per indicator = tens of minutes

Data parsing

Description: Parse structured email or email attachment content for network indicators and act on those indicators. Splunk SOAR is really good at this.

  • generate text from email content or attachments
  • parse text for network indicators
  • updating access list directly
  • creating ticket or sending email to request updating access list

Outcome: time saved per indicator report = tens of minutes

Generating reports

Description: Query SOAR or other external systems to summarize events and create reports (PDF or HTML) for management. Splunk SOAR is also very good at these tasks.

  • how many events per type for a time period
  • how many events per status
  • how many events per user

Outcome: time saved per generated report = minutes to hours

Case management

Description: Handle common case management tasks (like filling out a bunch of fields in ServiceNow). This is useful because every use case has some tickets related to it.

SOAR is really good at this. there's an app for this

  • open a ticket: filling out standard fields based on alert data
  • close ticket: prompting analyst for summary, justification before closing ticket, documenting answers, updating close status

Outcome: time saved per case = tens of minutes

Handling employment status changes

Description: Handle tasks required when onboarding or off-boarding an employee. These are repeatable processes that Splunk SOAR is good at.

  • look up information about employee
    • accounts
    • groups
    • access
  • put in ticket to close accounts
  • put in ticket to update access list
  • document changes

Outcome: time saved per employment status change request = tens of minutes