Migrate Splunk SOAR automation to Microsoft Sentinel

Microsoft Sentinel provides Security Orchestration, Automation, and Response (SOAR) capabilities with automation rules and playbooks. Automation rules automate incident handling and response, and playbooks run predetermined sequences of actions to response and remediate threats. This article discusses how to identify SOAR use cases, and how to migrate your Splunk SOAR automation to Microsoft Sentinel.

Automation rules simplify complex workflows for your incident orchestration processes, and allow you to centrally manage your incident handling automation.

With automation rules, you can:

  • Perform simple automation tasks without necessarily using playbooks. For example, you can assign, tag incidents, change status, and close incidents.
  • Automate responses for multiple analytics rules at once.
  • Control the order of actions that are executed.
  • Run playbooks for those cases where more complex automation tasks are necessary.

Identify SOAR use cases

Here’s what you need to think about when migrating SOAR use cases from Splunk.

  • Use case quality. Choose good use cases for automation. Use cases should be based on procedures that are clearly defined, with minimal variation, and a low false-positive rate. Automation should work with efficient use cases.
  • Manual intervention. Automated response can have wide ranging effects and high impact automations should have human input to confirm high impact actions before they’re taken.
  • Binary criteria. To increase response success, decision points within an automated workflow should be as limited as possible, with binary criteria. Binary criteria reduces the need for human intervention, and enhances outcome predictability.
  • Accurate alerts or data. Response actions are dependent on the accuracy of signals such as alerts. Alerts and enrichment sources should be reliable. Microsoft Sentinel resources such as watchlists and reliable threat intelligence can enhance reliability.
  • Analyst role. While automation where possible is great, reserve more complex tasks for analysts, and provide them with the opportunity for input into workflows that require validation. In short, response automation should augment and extend analyst capabilities.

Migrate SOAR workflow

This section shows how key Splunk SOAR concepts translate to Microsoft Sentinel components, and provides general guidelines for how to migrate each step or component in the SOAR workflow.

Diagram displaying the Splunk and Microsoft Sentinel SOAR workflows.

Step (in diagram) Splunk Microsoft Sentinel
1 Ingest events into main index. Ingest events into the Log Analytics workspace.
2 Create containers. Tag incidents using the custom details feature.
3 Create cases. Microsoft Sentinel can automatically group incidents according to user-defined criteria, such as shared entities or severity. These alerts then generate incidents.
4 Create playbooks. Azure Logic Apps uses several connectors to orchestrate activities across Microsoft Sentinel, Azure, third party and hybrid cloud environments.
4 Create workbooks. Microsoft Sentinel executes playbooks either in isolation or as part of an ordered automation rule. You can also execute playbooks manually against alerts or incidents, according to a predefined Security Operations Center (SOC) procedure.

Map SOAR components

Review which Microsoft Sentinel or Azure Logic Apps features map to the main Splunk SOAR components.

Splunk Microsoft Sentinel/Azure Logic Apps
Playbook editor Logic App designer
Trigger Trigger
• Connectors
• App
• Automation broker
Hybrid Runbook Worker
Action blocks Action
Connectivity broker Hybrid Runbook Worker
Community Automation > Templates tab
Content hub catalog
Decision Conditional control
Code Azure Function connector
Prompt Send approval email
Format Data operations
Input playbooks Obtain variable inputs from results of previously executed steps or explicitly declared variables
Set parameters with Utility block API utility Manage Incidents with the API

Operationalize playbooks and automation rules in Microsoft Sentinel

Most of the playbooks that you use with Microsoft Sentinel are available in either the Automation > Templates tab, the Content hub catalog, or GitHub. In some cases, however, you might need to create playbooks from scratch or from existing templates.

You typically build your custom logic app using the Azure Logic App Designer feature. The logic apps code is based on Azure Resource Manager (ARM) templates, which facilitate development, deployment and portability of Azure Logic Apps across multiple environments. To convert your custom playbook into a portable ARM template, you can use the ARM template generator.

Use these resources for cases where you need to build your own playbooks either from scratch or from existing templates.

SOAR post migration best practices

Here are best practices you should take into account after your SOAR migration:

  • After you migrate your playbooks, test the playbooks extensively to ensure that the migrated actions work as expected.
  • Periodically review your automations to explore ways to further simplify or enhance your SOAR. Microsoft Sentinel constantly adds new connectors and actions that can help you to further simplify or increase the effectiveness of your current response implementations.
  • Monitor the performance of your playbooks using the Playbooks health monitoring workbook.
  • Use managed identities and service principals: Authenticate against various Azure services within your Logic Apps, store the secrets in Azure Key Vault, and obscure the flow execution output. We also recommend that you monitor the activities of these service principals.

Next steps

In this article, you learned how to map your SOAR automation from Splunk to Microsoft Sentinel.