Skip to main content

 

Splunk Lantern

The Splunk platform as a SOAR data source

 

The Splunk platform and Splunk SOAR interact with each other in multiple ways to improve your organizational security processes. The Splunk platform can be:

  • a data source
  • an appliance
  • a monitoring and reporting tool

This article explains how the Splunk platform functions as a data source for Splunk SOAR through the Splunk App for SOAR Export. It covers some best practices and recommendations for server configuration and event forwarding. For more comprehensive documentation on how to use this app, see About the Splunk App for SOAR Export.

The information below applies to SOAR and Splunk Enterprise Security (ES) integrations versions prior to ES 8.x. ES 8 introduced a streamlined and direct integration with SOAR. For more information on that integration, see Pair Splunk Enterprise Security with Splunk SOAR.

To learn about the other ways that the Splunk platform and Splunk SOAR interact, see Demystifying apps for the Splunk platform and SOAR.

Configure the server

You can install the Splunk App for SOAR Export either from the Apps page of Splunk Enterprise or from Splunkbase. When you've done that, the first thing you'll need to do in the app configuration is enter credentials for your SOAR instance.

The following steps assume that Splunk Enterprise can touch the SOAR REST endpoint directly. Sometimes this isn't the case. For example, if you have Splunk Cloud Platform and SOAR on-premises, and not inside your DMZ, you might not want Splunk Cloud Platform to be able to reach your internal work. If this is the case, see the alternative connections section.

When you've done that, you'll go to your SOAR interface and complete the following:

  1. Ensure that you have an Automation type user set up. This is required for REST access to SOAR.
  2. For the username, best practice is to use a name specific to the service, so in this case, you should update the default "automation" name to something like "splunk_automation". Because you'll have a unique automation user for each service, this naming convention will prevent confusion.
  3. For the allowed IPs:
    • For testing purposes, you can use "any" to prevent wrong IPs being an issue that might cause troubleshooting.
    • For production, specify an IP or IP block of your Splunk instance, in CIDR notation.
  4. Authorization credentials are generated automatically, and you can click Show Token to see them in plain text. Copy this token to use in the next set of instructions.
  5. Add the roles required for the app.

Then return to the app configuration in Splunk Enterprise.

  1. Paste in the authorization token.
  2. Provide a name for the server.
  3. Click Save.

At this point, the app will automatically try to test connectivity. If it cannot connect, check the following:

  • Can your Splunk instance reach your SOAR instance? Try some network connectivity tests if not.
  • Is the Splunk instance IP in the SOAR automation user IP List?
  • Was the authentication information copied over correctly?
  • Have you added the SOAR certificate to the Splunk certificate? By default, certificate validation is enabled, but you can disable certificate verification for testing. For production, SOAR needs a valid certificate signed by CA (your nginx certificate), or can add your SOAR root CA certificate to Splunk Enterprise. For more information on certificates, see Provide a valid SSL certificate for the connection between Splunk SOAR and Splunk Enterprise.

Alternative connections

This is configured on a heavy forwarder that's on your internal network, and the heavy forwarder on a schedule will reach out to your Splunk instance and see if there's any data for SOAR. If there is, it'll bring it back in and and and create the events and do the automation. For more information on how this works, see Use adaptive response relay to send notable events from Splunk ES to Splunk SOAR. However, while sending notables directly to SOAR through adaptive response might be beneficial, you lose enrichment of the notable macro and you could potential lose aggregations.

A better option might be to use the Splunk App for SOAR. However, with this solution, you will be unable to run event ingestion or playbook actions through adaptive response. Therefore, It is best practice and recommended to use Event Forwarding if possible. More information on configuring this app is available in The Splunk platform as a SOAR search and reporting engine.

Configure saved searches

Sending data from the Splunk platform to Splunk SOAR requires saved searches.

Here's a basic sample search:

index=demo alert='failed login attempt'
| fields _time src dst alert

Note that the search lists every field that this user wants returned in the search. This is a best practice. Each one of those fields becomes an artifact in a SOAR event.

  • If you don't specify which fields you want, you get the default fields. This might be too many or include ones that you don't care about.
  • If you want all the fields, you can use field*.

The sample search above doesn't indicate the time picker settings, but you don't need to worry about setting that. The time picker value will be overwritten by the Event Forwarding configuration.

Permissions: The saved search has to be accessible to all apps and everyone must have read access to the search. Be sure your saved search has the following permissions configuration:

  • Display for: All apps
  • Everyone: Select read access

Another best practice is that if you use Splunk Enterprise Security (ES), your search should use the`notable` macro to get enriched information and the expandtoken command to expand token values shown in ES Incident review. Here is a sample search for ES customers:

`notable`
| search rule_name=”Phantom*”
| expandtoken
|fields <desired fields>

You can specify notables to go to SOAR with tagging, by using specific Rule Names, or even a lookup table.

Configure event forwarding

In the Splunk App for SOAR Export, go the Event Forwarding tab and add a new saved search export. When completing the fields on the configuration screen, remember the following:

  • If you can't find your saved search in the dropdown, check the permissions.
  • The destination is your SOAR server.
  • Best practices for the container name is to set the container name based on a field returned from the saved search, or for notables, use the rule name. This helps you distinguish what data is sent to SOAR when you see it in the SOAR UI.
  • Have the container label match a response plan. This is part of good orchestration to organization plans and playbooks and events. If it is a custom label, then the label must be created in SOAR prior to configuring the rule. Otherwise, the event will not be created.
  • Set the time picker to match the schedule of your saved search.
    • Note that SOAR will not create duplicate containers if they have the exact same artifact information from searches running at the same time.
    • We don't recommend running in real time because that puts a huge load on whatever search head is running the search. Running as frequently as one minute is generally sufficient, but you should check your SLAs when making this decision.

When you click next, keep the following in mind when completing the configuration on the second screen.

  • Severity and sensitivity are hard coded. Therefore, you should have a separate event forwarding rule for each different use case so you can make the adjustments needed. Alternatively, you could create one event forwarding rule for all notables you want to send to SOAR, and then have an ingestion playbook that updates the severity and sensitivity based on alert information at ingestion.
  • SOAR uses Common Event Format (CEF) fields, but the Splunk platform uses the Common Information Model, so you'll need to map unmapped fields. Doing so provides context for the data type. Some fields map automatically, for example, it understands that the IP is the destinationAddress. Other fields you will have to map manually. If you select the option to save your mappings, those mappings will be applied to all future rules you create so you won't have to complete the manual mapping every time.

After you create the forwarding rule, it will start running according to the scheduled job.

View the event in SOAR

Here are a few things to note when viewing the event in SOAR:

  • The name of the container created will match the name of the saved search.
  • The description tells you where the event came from, in this case, the Splunk App for SOAR Export.
  • The artifacts are the fields you added to the search.

Additional resources

Now that you've learned how to set up the Splunk platform as a data source for Splunk SOAR, learn how to use it as: