How do I forward Splunk Mission Control Investigations to SIR?

[Cheryl ODell]

Our SOC is using the Splunk SIEM known as Mission Control.  All of their investigations into notable events are handled through the Splunk SIEM.  However, we need to have the data sent to SIR so we can provide reports and metrics of their investigations.  It needs to be bidirectional, because they will manually want to push an investigation to SIR, and updates to the investigation in Splunk will need to be sync'd up with the SIR ticket until it is Closed.

Looking at the Splunk ES Integration for SecOps looks like it only works with events linking to SIR tickets, not an investigation.  I asked AI how to do it, and of course doesn't mean it's right, but it says I need to use the Splunk Enterprise DATA Integration for Security Operations and the Splunk Search Integration for Security Operations.  I don't see a Splunk DATA Integration in the ServiceNow store.

Has anyone been able to set this up, or does anyone know how I need to set it up?  BTW we are on the version Australia.

Thank you,

Cheryl

[Aravind2799]

Hi Cheryl,

You've spotted the core issue correctly. The ServiceNow Splunk integrations were built around the older ES model of notable events, and ES 8 / Mission Control works differently.

Why the store integrations don't fit

In ES 8, notables became findings, and investigations are cases that are displayed in the analyst queue of the Mission Control page, with each one built from one or more findings. The two ServiceNow options are both event-oriented:

• Splunk ES Integration for Security Operations is the pull model. Profiles are created in your Now Platform instance to handle different notable event types that are created via correlation searches, and ServiceNow polls Splunk.
• Splunk Enterprise Event Ingestion for Security Operations is the push model. Its companion Splunkbase add-on lets you forward notable events from Splunk ES Incident Review to ServiceNow to create security incidents.

I'm not aware of a "Splunk Enterprise DATA Integration" in the store. My guess is the AI blended the Event Ingestion integration with the Search integration. The Splunk Search Integration is for running searches from SIR (sightings and enrichment), not for syncing case lifecycle, so it won't solve this either.

Before going custom, do check the store listings and release notes for the latest versions compatible with Australia, in case investigation support has been added recently.

What will work: a custom integration on the ES 8 API

Splunk exposes an API to access and modify findings, investigations, risk scores, assets, and identities, so you can build the sync around investigations directly:

• Manual push from Splunk: create a custom adaptive response action that calls ServiceNow (Scripted REST API or Table API on sn_si_incident). Splunk lets you trigger adaptive response actions from detections or on an ad hoc basis when examining findings and investigations, which gives analysts the "send to SIR" button they want.
• Correlation: store the Splunk investigation ID on the SIR record (correlation ID field or a custom field), and write the SIR number back to the investigation so analysts can see the link.
• Ongoing updates: a scheduled Flow or job in ServiceNow polls the ES API for investigations with a linked SIR record, updated since the last run. Map status, owner, severity, notes and included findings. Stop syncing once the SIR record is closed.
• Connectivity: use a MID Server if Splunk is on-prem, or allowlisting if it's Splunk Cloud.

Design decisions that matter more than the code

• Source of truth per field. If investigation work happens in Splunk, Splunk owns status, notes and disposition, and SIR mostly mirrors. Truly bidirectional editing of the same fields creates conflict and loop problems.
• Loop prevention. Mark updates by origin so a change written by the integration doesn't trigger a sync back.
• State mapping. Agree on how Splunk statuses and dispositions map to SIR states and close codes. Your metrics depend entirely on this.
• Metrics fields. Capture Splunk's own created, acknowledged and closed timestamps on the SIR record, rather than relying on SIR timestamps, which reflect when the sync happened, not when the analyst acted.

If you have Splunk SOAR, it's another option for orchestrating the push and updates, but the ES API approach works without it.

Happy to share more on field mapping if it helps. I've worked through a Splunk ES to SIR integration recently, and state mapping and metrics timestamps were where most of the effort went.

Thanks

Aravind Panchanathan