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:

Context engineering

Vector database

Search powered applications

Logs

Threat protection

Workflows

Elasticsearch

Kibana (Discover, Dashboards)

Elastic Agent Builder

AutoOps

Piped query language

Jina AI search models

Elastic Cloud Serverless

Elastic Cloud Hosted

Self-managed Elasticsearch

Ecommerce search

Customer support search

Search-driven apps

Log analytics

Infrastructure monitoring

Digital experience monitoring

App performance monitoring

AIOps

LLM observability

Next-gen SIEM

Workflows for security

XDR and endpoint security

AI for security

10x your data's value

Cloud providers

Elastic AI Ecosystem

Search AI Partner Program

AV-Comparatives

Forrester Wave™ XDR

Gartner Magic Quadrant Leader

IDC MarketScape

Search

Security

Observability

Get started

Demo gallery

Downloads

Integrations

Docs

Elasticsearch Labs

Elastic Security Labs

Elastic Observability Labs

Blog

Community

Events

Webinars

Discuss

Training

Support

Consulting

Author

Articles by Matthew Adams

Senior Principal Product Solution Architect, Elastic

Unifying security monitoring with Elastic Security and Microsoft Sentinel

Sign up for Elastic Cloud free trial