SPLK-2003 Integrating SOAR into Splunk

Integrating SOAR into Splunk Detailed Explanation

1. Overview

Many people think of Splunk SOAR as a tool that pulls data from Splunk, but the reverse is also true:
Splunk (as a SIEM) can actively push alerts and events into SOAR, where they are automatically investigated, enriched, and responded to.

This bi-directional integration allows analysts to move seamlessly between detecting threats in Splunk and responding to them in SOAR.

Think of Splunk as the alert generator and SOAR as the response engine.

2. Integration Points

Let’s look at the two key integration mechanisms that let Splunk and SOAR work together:

a. Splunk App for SOAR

This app is installed on the Splunk platform (not SOAR), and it enables:

• Forwarding alerts from Splunk to SOAR:

  • Alerts from correlation searches or data models can be sent directly to SOAR as events.

  • These events then trigger playbooks automatically.

• Viewing SOAR data inside Splunk:

  • The app includes dashboards that show:

    • Open SOAR cases

    • Automation timelines

    • Analyst decisions

  • This lets Splunk users track response progress without switching tools.

This app makes the integration feel native and seamless from the Splunk side.

b. Adaptive Response Framework (ARF)

The Adaptive Response Framework (ARF) is a Splunk Enterprise Security (ES) feature that lets you take action directly from search results.

What it does:

• Lets analysts right-click or select a field (e.g., an IP, username) in a notable event.

• Choose a response action, such as:

  • “Send to SOAR for investigation”

  • “Run playbook: Quarantine Host”

  • “Request Enrichment from SOAR”

How it works:

• The chosen action sends the necessary data to SOAR (via REST API or app integration).

• A playbook is triggered in SOAR to handle the response.

ARF empowers analysts to go from detection to action in one click.

3. Data Flow

Here’s what a typical integration workflow looks like:

1. Detection

   • Splunk runs a correlation search and detects suspicious activity.

   • A notable event is generated in Splunk Enterprise Security.

2. Forwarding

   • A custom alert action (from the SOAR app or ARF) sends the event to SOAR.

   • Data is sent via REST API with key fields like IPs, users, domains, etc.

3. Playbook Execution

   • SOAR ingests the event and launches a playbook.

   • The playbook enriches the data, checks threat intelligence, and performs actions.

4. Feedback Loop

   • SOAR can send:

     • Enrichment results (e.g., IP is malicious).

     • Case updates (e.g., investigation closed).

   • Back to Splunk, where it can be:

     • Logged

     • Shown in dashboards

     • Used to update notable events

This tight integration creates a closed-loop security operations workflow.

4. Use Cases

This integration unlocks many real-world security automation scenarios:

a. Trigger SOAR Playbooks from Correlation Searches

• Use Splunk searches (e.g., “User logged in from 2 countries in 5 minutes”) to:

  • Automatically send the event to SOAR.

  • Trigger a prebuilt investigation playbook.

Reduces time to triage and supports consistent response procedures.

b. Automate Threat Responses

• Once SOAR is triggered, it can:

  • Disable compromised user accounts.

  • Block malicious IPs at the firewall.

  • Notify stakeholders or start case management.

This turns manual actions into automatic remediation.

c. View SOAR Case Status from Splunk

• Dashboards in the Splunk SOAR App let analysts:

  • See case progress and status.

  • Understand which actions were taken.

  • Follow automation timelines.

This provides end-to-end visibility without switching tools.

Summary

Feature	Description
Splunk App for SOAR	Sends alerts to SOAR and shows SOAR data in Splunk
Adaptive Response Framework	Allows manual triggering of SOAR playbooks from search results
Detection to Response Flow	Splunk detects → Sends to SOAR → SOAR investigates → Sends results back
Use Case: Auto-Triage	Use correlation rules to launch playbooks
Use Case: Auto-Remediation	Automatically block IPs, disable accounts, escalate incidents
Use Case: Case Visibility	View SOAR case progress and resolution inside Splunk dashboards

Integrating SOAR into Splunk (Additional Content)

1. Custom Alert Actions in Splunk (Forwarding Data to SOAR)

What is a Custom Alert Action?
In Splunk, a Custom Alert Action is a mechanism that allows search results to be sent to external systems — in this case, to Splunk SOAR — for further automated processing.

Configuration Steps:

• Go to Splunk Enterprise Security.

• Under Content Management, select a Correlation Search.

• Edit the search and add an Alert Action.

• Choose one of the following (depending on app version):

  • Send to Phantom

  • Run Playbook

• Configure the destination SOAR asset, playbook (optional), and parameters if required.

Default Fields Sent to SOAR:

• event_id

• host

• user

• source_ip

• dest_ip

• timestamp

• Other relevant search result fields

How these are used in SOAR:
These values are packaged as CEF-formatted artifacts and attached to a container representing the incoming event.

2. Event and Artifact Mapping Logic in SOAR

How Splunk Data Arrives in SOAR:

• Data is sent from Splunk using:

  • The SOAR app on Splunk (uses REST API)

  • Adaptive Response Framework (ARF) (via manual analyst action)

• SOAR receives this as a container, with structured data inside artifacts

How the Structure Works in SOAR:

• The event becomes a container (a unit of investigation).

• Each field from the Splunk result becomes part of an artifact in the container.

  • Example:

    • source_ip → cef.sourceAddress

    • username → cef.destinationUserName

Field Mapping Recommendation:

• Use Splunk's Common Information Model (CIM) fields wherever possible.

• Ensures compatibility with existing playbooks and enrichments inside SOAR.

3. Authentication and Permission Considerations

On the Splunk Side:

• Users must have permissions to run alert actions that send data to SOAR.

• API calls must be authenticated:

  • Best practice: Use API tokens

  • Alternative: Splunk Secure Gateway

On the SOAR Side:

• You must configure a Splunk Asset that:

  • Accepts API-based connections

  • Specifies allowed authentication method (Basic Auth or Token)

  • Has the correct port open (default for API is 443 or 8443 depending on setup)

Security Recommendations:

• Restrict API tokens to least privilege — allow only necessary playbooks or containers.

• Use HTTPS for encrypted data transmission.

• Log all API interactions — helpful for audit trails or detecting misuse.

4. Advanced Feedback Mechanism (Closing the Loop)

After SOAR processes the event, it can send results back to Splunk to complete the lifecycle.

Examples of Feedback Actions:

• Write back to a summary index in Splunk:

  • This enables dashboards or audit trails of SOAR actions.

• Update the status of a notable event (e.g., from “New” to “Resolved”).

• Add metadata like:

  • Tags

  • Risk scores

  • Comments or resolution details

Example:

| inputlookup phantom_results.csv | eval status="Resolved"

Purpose:
This integration ensures full visibility and traceability — from detection to response to documentation — all within the analyst’s SIEM dashboard.

5. Troubleshooting Guide – Common Integration Issues

A brief FAQ-style section can help tackle real-world issues that also appear in exams:

Issue: SOAR is not receiving events from Splunk

• Check: App configuration, API address, authentication settings

Issue: Playbook did not trigger after ingestion

• Check:

  • Is there a default playbook assigned to the container label?

  • Are event labels mapped properly?

  • Is playbook trigger mode set to “on ingestion”?

Issue: Incomplete or missing data in SOAR

• Check:

  • Are fields properly mapped in the Splunk alert action?

  • Is the payload JSON-formatted and valid?

  • Are all required fields present and structured under cef?

Summary

Topic	Details
Custom Alert Action	Sends Correlation Search results from Splunk to SOAR as structured events
Artifact Mapping	Splunk fields are mapped to SOAR artifacts (e.g., cef.sourceAddress)
Authentication	Use API tokens with least privilege; secure communication with HTTPS
Feedback Mechanism	Send results from SOAR back to Splunk (update notable, write to index)
Troubleshooting	Validate playbook triggers, data mapping, and Splunk-SOAR connectivity