Thanks to Javier Soriano, Principal Product Manager - OneSOC Customer Experience Engineering, for the peer review

Introduction

Although the recommended approach is to not have multiple SIEM solutions in place, many organizations are still running dual-SIEM setups, sometimes even introducing additional ones in the mix. Combination most often seen is running a legacy solution and pairing it with modern SIEM solutions like Microsoft Sentinel SIEM. Side-by-side architecture is recommended for just long enough to complete the migration, train people and update processes - but organizations might stay with the side-by-side configuration longer when they are not ready to move away from legacy solutions.

In such situations, organizations usually opt for sending alerts from their legacy SIEM to Sentinel SIEM:

• Cloud data is ingested and analyzed in Sentinel SIEM
• On-premises data is ingested and analyzed in legacy SIEM which generates alerts
• Alerts are forwarded from legacy SIEM to Sentinel SIEM

With this approach, SOC teams have a single interface where they are able to cross-correlate and investigate alerts from their organizations while benefiting from full value of unified security operations in Microsoft Defender.

Send Splunk alerts to Sentinel SIEM

Splunk side

When an alert is raised in Splunk, organizations have an option to set up following alert actions:

• Email notification action
• Webhook alert action
• Output results to a CSV lookup
• Log events
• Monitor triggered alerts
• Send alerts and dashboards to Splunk Mobile Users

Interestingly, it is possible to work with Webhooks to make an HTTP POST request on a URL. The data is in JSON format which makes it easily consumable by Sentinel SIEM. For this to work, Splunk needs the hook URL from the target source (in this case, Sentinel SIEM).

 

{

	"result": {
		"sourcetype" : "mongod",
		"count" : "8"
	},
	"sid" : "scheduler_admin_search_W2_at_14232356_132",
	"results_link" : "http://web.example.local:8000/app/search/@go?sid=scheduler_admin_search_W2_at_14232356_132",
	"search_name" : null,
	"owner" : "admin",
	"app" : "search"
}

Example: Splunk alert JSON payload 

Microsoft side

From Microsoft perspective, organizations can take advantage of Logs Ingestion API, which allows for any application that can make a REST API call to send data to Sentinel SIEM.

To configure Logs Ingestion API, a couple of supporting resources are needed:

1. Microsoft Entra application which will authenticate against the API
2. Custom table in Log Analytics workspace, where the data will be sent to and accessible from Sentinel SIEM
3. Data Collection Rule (DCR) which will direct data to the target custom table
4. Entra application from the first step needs to have RBAC assigned on the DCR resource
5. A solution to call Logs Ingestion API so the data can be sent to the Sentinel SIEM.

In order to make this process streamlined and easy to deploy, a solution has been developed which will automate creation of all of these supporting resources and allow you to have a Webhook URL ready which can be just placed in your Splunk solution:

 

https://github.com/Azure/Azure-Sentinel/tree/master/Tools/SplunkAlertIngestion 

 

Picture: Content of the solution

 

The script with supporting ARM templates can be run directly from the Azure Cloud Shell and configured with a couple of parameters:

./SplunkAlertIngestion.ps1 -ServicePrincipalName "" -tableName "" -workspaceResourceId "" -dataCollectionRuleName "" -location ""

• ServicePrincipalName - mandatory, define a name for the SP
• tableName - mandatory, define a name for the custom table with the suffix _CL (example: SplunkAlertInfo_CL)
• workspaceResourceId - mandatory, the resourceId can be fetched from the Log Analytics Workspace Properties blade (/subscriptions/xxx-xxx/resourceGroups/xxx/providers/Microsoft.OperationalInsights/workspaces/xxx)
• dataCollectionRuleName - mandatory, define DCR name
• location - mandatory, define Azure location for the resources (example: northeurope, eastus2)
• LogicAppName - not mandatory, define the name for the LogicApp, otherwise it will be named SplunkAlertAutomationLogicApp

Result

The script will create all supporting resources that are needed and will provide the Webhook URL as an output. Use this URL to configure trigger action in Splunk:

Picture: Instructions for configuring webhook alert action in Splunk

 

Once the webhook is configured on Splunk side, any time the alert is raised it will trigger the webhook, which will initiate the Logic App resource on Azure side responsible for parsing the data and sending that data through Logs Ingestion API to the destination table in Sentinel SIEM.

Picture: Workflow of the Logic App

Conclusion

Ingesting alert data from other solutions in your organization to Sentinel SIEM allows for security teams to take advantage of unified security operations in Microsoft Defender - easier cross-correlation between various data sources, comprehensive threat intelligence and case management experience.