Multi-tenant XDR incidents in Microsoft Sentinel

The native Sentinel Connector for Microsoft Defender XDR only supports integration inside one tenant. How to collect incidents from multiple tenants to Sentinel? Read more to learn about one approach.

When a company is either the owner or operator of multiple Entra ID tenants, the architecture for handling security events and incidents gets more complex.

In the last year I’ve had many assignments where a customer wants to build centralised multi-tenant incident management for Microsoft Sentinel and Defender XDR.

For a SOC managing multiple Sentinel instances this is easy, as you can view all customer XDR incidents in the central Sentinel workspaces over Azure Lighthouse delegation.

But in the case where a central Sentinel exists - but the target tenants with XDR don’t have Sentinel - things get more complex.

Integrating Defender XDR incidents from multiple tenants to a central Sentinel workspace is not supported with the native Defender XDR data connector. So we need to build something custom.

For many MSSPs doing Managed Detection and Response (MDR) services this is likely everyday stuff, but for some organisations who manage multiple tenants it may be new scenario. I thought it would be interesting to explore it in a blog post.

In one case for a recent customer I ended up with the following architecture:

Below I will describe the solution in more detail, focusing on authorisation, data collection and Logic App solution in more detail.

App Registration & permissions

At the heart of the solution is an Entra ID App Registration created in the central tenant, which needs access to read SecurityIncidents via Microsoft Graph:

After granting the permissions, the App Registration needs admin consent from all of the target tenants:

To get to the consent, you can generate the following URL from your App Registration and open it with admin access to the target tenant:

https://login.microsoftonline.com/common/oauth2/authorize?prompt=consent&client_id={client id}&response_type=code&sso_reload=true

You also need to create a client secret for the App Registration. This will be used in the Logic App HTTP call that fetches incidents from the target tenant.

Logic App overview

At the heart of the solution are Azure Logic Apps, one for each customer.

It would also possible to create a single Logic App and have the actions parse each customer from an array. This was out of scope for my test.

In short, the Logic App general flow works like this:

1. Recurrence (30 minutes for example)

2. Get incidents from target tenant

3. For each incident, post the relevant details to central tenant Sentinel

I will describe the Logic App in this chapter in a generic fashion with screenshots. It’s pretty simple to reproduce, but you can also see my example template here.

Overview of the flow and all actions:

A detailed look at the HTTP Get Defender Incidents action:

Here we query Microsoft Graph for all Security Incidents that have Active status, meaning that Resolved incidents are not fetched.

Authentication happens with the App Registration client secret. In production, this must be moved to a Key Vault.

Next we have a closer look at the HTTP Post to Azure Data Collection Endpoint action, which writes the incident data to Sentinel via Logs Ingestion API:

In this action, the important thing to note is that this does not handle duplicate incidents in Sentinel! Every run creates a new batch of events in Log Analytics, with duplicates.

For testing and presenting how the flow works to customers, this is better, as I can repeat the test runs without creating new incidents.

A production version needs a KQL query action before the HTTP POST, to check that the incident ID in question does not already exist in the table. This would look something like the following:

Here the Condition would return True if the resulting array from the KQL query is empty.

Data collection overview

The Logic App authenticates to Sentinel Logs Ingestion API with Managed Identity and writes the data we want to have in Sentinel.

This requires a couple of things in Azure resources and Microsoft Sentinel:

• Data Collection Endpoint.

• Data Collection Rule, with a custom stream matching our data.

• Custom table, with columns matching our data.

If you want to see the example table schema I used, you can check my template for deploying the Data Collection Rule here.

Note that my examples were from a quick personal test. There are other interesting attributes in the incident metadata you will want to use in production.

Results in Microsoft Sentinel

After the Logic App has run, you will find XDR incidents in the custom table:

From here it’s a simple job to create an Analytics Rule to generate Sentinel incidents for all target tenants:

References:

• List incidents - Microsoft Graph v1.0 | Microsoft Learn

• Logs Ingestion API in Azure Monitor - Azure Monitor | Microsoft Learn

• Tutorial: Send data to Azure Monitor Logs with Logs ingestion API (Resource Manager templates) - Azure Monitor | Microsoft Learn