At Elastic, we have always had one mission: to bring the best search and analytics capabilities to wherever our users are. This principle is built into all three of Elastic’s solutions, including Elastic Security. The AI-driven security analytics solution is built to be open, transparent, and available to users of all kinds.
Microsoft Sentinel is a widely adopted security information and event management (SIEM) solution, including with Elastic users. As an Azure based SaaS product, it integrates seamlessly into other Microsoft products and beyond.
Elastic has complementary strengths that can bring a lot of value to security teams that use Microsoft Sentinel. Let’s dive into a few of the main ones.
https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt07c2c19f4d966067/6815446d478db20482757840/Logical_-case-webhook-architecture.png,Logical -case-webhook-architecture.pngPart 1: Create Azure Logic Apps
Although it’s not complicated to build the Logic Apps, we will provide an Azure Resource Manager (ARM) template that can speed up the process.
1. Download the template here, which includes:
An API connector for Microsoft Sentinel
An Azure Logic Apps workflow to create, update, and add comments to an incident
An Azure Logic Apps workflow that gets the details of an incident (this separates modifications and reads.)
2. Search in the Azure console for “Deploy a custom template.”
3. Click Build your own template in the editor. Upload the template file you downloaded.
4. Click Save.
5. Fill out the details for the template:
Subscription and resource group for the Logic Apps
Names for your workflows and your API Connector to Sentinel
The name of your Sentinel Workspace
The Resource Group of your Sentinel Workspace
6. Click Review and create.
7. Click Create.
8. After your deployment is complete, navigate to the new API Connection by clicking Deployment details and then clicking on the created API Connection.
9. Within the API Connection, authorize Microsoft Sentinel. Navigate to General→Edit API connection and click Authorize. After you authorize, click Save.
10. Now that you have authorized the API connection, the logic apps can interact with Sentinel. Open both workflows in new tabs so they are available for the next part.
Part 2: Configure case management connector in Kibana
1. In Kibana, head to Stack Management → Connectors and click Create Connector.
2. Select Webhook - Case Management and give your connector a name, and then select Authentication = None as the authentication will be embedded in the url. Add HTTP header switch on and enter Content-Type as a key and application/json as its value.
3. On the next screen, enter the endpoint details for case creation. Copy the URL of the corresponding Logic App and paste it into the Create case URL box (e.g., example-elastic-create-incident). You will find this inside the Request action’s details page. Navigate to Development Tools → Logic Apps designer to see the workflow.
In the Create case object box, build a JSON object using the variables that Kibana makes available. The keys here must match up with the JSON schema that the Logic App’s request connector is expecting, so that the values can be correctly extracted and used where needed.
{ "action": "create-incident", "case_id": {{{case.id}}}, "case_title": {{{case.title}}}, "case_severity": {{{case.severity}}}, "case_status": {{{case.status}}}, "case_description": {{{case.description}}}, "case_tags": {{{case.tags}}}, "elastic_url_base": "/app/security/cases/" }Finally, set the Create case response external key. This tells Kibana how to extract the Microsoft Sentinel incident ID from the response returned by your Logic app.
Create case response external key:
sentinel_incident_id4. On the next screen, configure the connector needed to get case information from Microsoft Sentinel. Here, use a new variable called external.system.id, which has been populated by the Microsoft Sentinel incident ID extracted during the previous step. Go to the Logic App created earlier that gets the incident information (e.g., example-elastic-get-incident) and retrieve the URL. Use the URL and add the external.system.id as a query parameter.Get case URL:
&sentinel_incident_id={{{external.system.id}}}Also configure the following.
Get case response external title key:
External case view URL:
https://portal.azure.com/#asset/Microsoft_Azure_Security_Insights/Incident/subscriptions//resourceGroups//providers/Microsoft.OperationalInsights/workspaces//providers/Microsoft.SecurityInsights/Incidents/{{{external.system.id}}}5. On the final screen of the connector wizard, we configure the final two endpoints for creating case updates and adding comments. Use the URL from the create case workflow and set the following parameters:
Update case method: POST
Update case object:
Create comment method: POST
Create comment object:
{ "action": "add-comment-to-incident", "case_comment": {{{case.comment}}}, "sentinel_incident_id": {{{external.system.id}}} }6. Kibana provides an option to test the connector by filling in dummy values. Make sure to use this and ensure everything works before rolling out for real!
Part 3: Activate the case management connector
In Kibana, head to Security → Cases and click Settings.
Find the External incident management system section and select your new connector from the drop-down box. You can choose to edit the connector settings from here also if necessary.
Now, whenever you go to create a case in Kibana, the External Connector Fields section will be completed and your connector will be selected by default.
Try creating a case, updating its status, and adding comments! Then head over to Microsoft Sentinel to see all the same information already synchronized.
Part 1: Create Azure Logic Apps
To replicate this architecture, we have provided an example ARM template that creates a Logic App and related Log Analytics collector to connect the two.
To deploy the template:
Download our example workflow template here.
In Azure, search for “Deploy a custom template.”
Select Build your own template in the editor.
Select Load file.
Choose the downloaded template.
Click Save.
Choose your resource group and name.
Choose your name for the workflow, the :ph Analytics Collector, and the details of your Log Analytics workspace.
To find your workspace ID and key, navigate to the workspace and select “Agents” and choose instructions.
After review and create, navigate to Logic Apps to check the created workflow
Part 2: Configure the Elastic Alert Connector
Now that we have the Logic App workflow, we need to configure Elastic to send alerts to Logic Apps. To do that we can follow the documentation.
In Kibana, navigate to Stack Management.
In Connectors, create a new Webhook connector.
In Logic Apps, open your workflow, open the “Logic Apps Designer” view, click the request trigger, and copy the “HTTP URL”
Fill out the Webhook connector configuration:
Name: Logic Apps
Method: POST
URL: <logic apps HTTP URL>
Authentication: none (this is embedded in the url)
Add HTTP Header: Content-Type = application/json
Click Save and Test.
In the Test box, use a basic test body such as: {"alert":{"id": "Test"}}
You should see “Test was successful.”
You can also see the test event in the Logic App by clicking on Overview and scrolling down to the Runs History table.
You now have a working route between Elastic and your chosen Log Analytics workspace.
Part 3: Create an Elastic SIEM detection rule to test the connector
1. In Kibana, navigate to Security → Rules → Detection Rules (SIEM).
2. Click Create new rule.
3. In the first section, “Define Rule,” use the following configuration:
Select Custom Query.
Optional: You may leave the index patterns settings as default, but if you want to limit the rule to certain indices or data views, change that here.
In the Custom Query box, enter the KQL query string “message:malware.” This will fire the alert when any log is found that contains the word “malware” in its message field.
Click Next.
4. In the second section, “About rule,” complete the following:
Enter a name (e.g., Sentinel Test Rule).
Enter a description (e.g., My Elastic detection rule to test Sentinel integration).
Click Next.
5. In the third section, “Schedule rule,” you can leave everything as default.
Optional: If you’d like the rule to fire more frequently to make testing quicker, reduce the Runs every value from 5 minutes to 1 minute, for example.
Click Next.
6. In the final section, “Rule actions,” link the rule to the connector we defined in the previous section.
Select the connector type “Webhook.”
From the Webhook connector dropdown, select your connector. (Note: If you only have one of these, skip this step as it will already be selected for you.)
For Action frequency, select For each alert and Per rule run.
Optional: You have the option to filter the alerts that are sent to the webhook by using a query string, or a timeframe, but we can leave these options disabled for now.
For the Body, package up the information available from the alert into a JSON object that will be sent to the webhook. This is entirely flexible and you can include as much or as little context as you want. We have provided an example body which you can copy/paste for simplicity.
Click Add action.
Click Create & enable rule.
Part 4: Create a Microsoft Sentinel analytics rule to pick up the alert
The final piece of the puzzle is to define a query rule in Microsoft Sentinel that takes some action when Elastic alerts appear as logs in the Log Analytics stream.
1. In Microsoft Sentinel, navigate to Configuration → Analytics.
2. Click Create and then NRT Query Rule.
3. In the General section, complete the following:
Enter a name (e.g., Sentinel Test Rule).
Enter a description (e.g., My Sentinel analytics rule to pick up Elastic alerts).
Optional: You can also choose to set a Severity here and map the rule to tactics, techniques, and sub-techniques from MITRE ATT&CK.
Click Next.
4. In the Set rule logic section, complete the following:
In the Rule query box, enter a KQL string (but remember, this time we mean Kusto Query Language and not Kibana!). The simplest option if you don’t want any filtering or transformation is to enter only the table name (e.g., ElasticAlerts_CL).
Optional: In the Alert enhancement section, you have the possibility to enrich the generated Microsoft Sentinel alerts in a number of ways. If the alert data from Elastic Security contains identifiers that relate to entities recognized by Microsoft Sentinel, the Entity mapping option allows these links to be made. Parameters from the Elastic Security alert can be added as key-value pairs in the Custom details option or formatted as the name or description of the alert in the Alert details option.
For Event Grouping, select Trigger an alert for each event.
Click Next.
5. In the Incident settings section, complete the following:
Leave the “Create incidents from alerts triggered by this analytics rule” toggle enabled.
Optional: There are more advanced alert grouping options available here to help you define the incidents to be created in finer detail.
Click Next.
6. Skip the Automated response section and click Next.
7. Review all entered details and if all looks good, click Save to add the new rule to Sentinel. This is enabled automatically.
And we’re done! So, from this point onward, any time our detection rule fires in Elastic Security and creates an alert, we will see corresponding alerts and incidents in Sentinel.
If you would like to test the integration, simply send a log in to Elastic Security to trigger the rule. One way to do this is by using Kibana’s Console (inside Management menu → Dev Tools).
Enter the following into the Shell panel and hit the play button to send the request:
Even if your main goal is to provide additional information into your Microsoft Sentinel instance, it is also worth thinking about replicating logs relating to alerts, incidents, and events from Microsoft Sentinel into Elastic Security. If your use case for Elastic involves threat hunting through diverse data or carrying out historic analysis, it is incredibly valuable to have the context from Microsoft Sentinel as part of your investigation in Elastic.
ElasticSecurity provides an out-of-the-box integration for Sentinel that collects and parses alerts and incidents from Microsoft Sentinel REST API and events from the Azure Event Hub.
For more information, see the documentation.