In a typical enterprise environment, numerous solutions and tools protect the digital landscape. Different tools check emails for phishing attempts, secure infrastructure, and the cloud, and provide generative AI to detect threats and uplevel response beyond human ability. While each of these tools is valuable on its own, each just tells one part of a more comprehensive security story. Microsoft Unified XDR and SIEM solution provides a comprehensive approach where multiple security solutions are combined into a single platform to improve detection and response capabilities.

One of the newest innovations in this area is the Unified Security Operations Platform, which brings together Microsoft Sentinel, Microsoft Defender XDR, and Copilot for Security. Frankly speaking, the security operations platform is more of a new branding name for the Defender XDR portal. It has new capabilities, and by utilizing those, you will get most of the security tools into one unified portal, at least the most important ones. In this blog, I will go through what it means to have Sentinel in the unified security operations platform (+ notes from the field).

Background of Microsoft Unified XDR and SIEM

Let’s start going through some background information about Microsoft’s unified XDR and SIEM solution.

In the early stages of Microsoft’s cloud-based security solutions architecture, they were designed across multiple portals. This architecture made it challenging for security analysts to get a holistic view when investigating alerts and incidents or when evaluating the environment’s security posture. Over recent years, Microsoft’s unified XDR and SIEM solution has undergone significant development to support workloads across multi-cloud and on-premises environments.

The solution was initially designed to consolidate various Microsoft cloud-based security solutions under one umbrella (M365 Defender portal). Its primary goal was to enhance security operations efficiency and detect and remediate sophisticated threats faster. Together, these solutions offer a comprehensive solution for cybersecurity threats and complex attacks. Large enterprises, often operating in multi-cloud or hybrid environments, are discovering significant holistic benefits from Microsoft’s unified XDR and SIEM solution. This unified approach allows organizations to fully benefit from Microsoft’s unified XDR and SIEM solution within their own ecosystems.

One of the main advantages of using Microsoft’s unified XDR and SIEM solution is native integrations across the products, which means they share signals and events and sync alerts and incidents. Also, one key benefit of XDR is its ability to automate correlations, enabling the SOC team to focus on complex threats and prioritize investigations effectively.

The latest innovations, such as Microsoft Sentinel integration into the Defender XDR platform (unified security operations platform) and Copilot for Security, make the unified platform unique and can reduce precious time in incident triage.

Unified Security Operations Platform

What is a Unified Security Operations Platform? It’s not a new solution; it’s the same Defender XDR platform pumped up with steroids (Sentinel, Copilot for Security & Threat Intelligence) that combines these tools into a single solution.

  1. Microsoft Sentinel: Microsoft cloud-native Security Information and Event Management (SIEM) solution.
  2. Microsoft Defender XDR: Formerly known as Microsoft 365 Defender, the platform provides unified visibility, investigation, and response across various areas such as endpoints, hybrid identities, emails, collaboration tools, cloud apps, and workloads. 
  3. Microsoft Security Copilot: This is the newest innovation that enhances security operations by providing AI-driven insights, automation capabilities, and curated recommendations.

The move to a unified security operations platform means a fully integrated toolset for defenders to prevent, detect, investigate, and respond to threats across every layer of their digital landscape. 

Prerequisites for Integrating Sentinel

The prerequisites list is pretty short. You just need to have the following resources available and access in place:

  • A Log Analytics workspace that has Microsoft Sentinel enabled
  • XDR data connector enabled in  Sentinel
  • Microsoft Defender XDR onboarded to the Microsoft Entra tenant
  • Necessary permissions to Azure for sentinel operations (quite obvious)
    • Connect/disconnect Sentinel: Owner or User Access Administrator + Sentinel Contributor to Azure sub where Sentinel is located

The rest of the permissions are in the table below; detailed actions are listed here if you want to use custom roles.

TaskAzure built-in role requiredScope
Connect or disconnect a workspace with Microsoft Sentinel enabledOwner or
User Access Administrator and Microsoft Sentinel Contributor
– Subscription for Owner or User Access Administrator roles

– Subscription, resource group, or workspace resource for Microsoft Sentinel Contributor
View Microsoft Sentinel in the Defender portalMicrosoft Sentinel ReaderSubscription, resource group, or workspace resource
Query Sentinel data tables or view incidentsMicrosoft Sentinel Reader or a role with the necessary actions:
Subscription, resource group, or workspace resource
Take investigative actions on incidentsMicrosoft Sentinel Contributor or a role with the necessary actions:
Subscription, resource group, or workspace resource
Create a support requestOwner or
Contributor or
Support request contributor or a custom role with Microsoft.Support/*
Subscription

Site note: Defender XDR supports only one Sentinel workspace connection at a time.

How to integrate

When you navigate to the Defender XDR portal, you can see a banner below. Just select ‘Connect a workspace’, and the migration wizard opens to start the migration process. When integration is ready, the banner changes, and you can start evaluating unified security platform capabilities.

Side note: Take into account that only one workspace can be connected at a time. If pre-requisites are not set correctly, the wizard highlights what’s missing, as seen below (3rd figure)

From System—Settings—Microsoft Sentinel, you can manage your Sentinel instance settings and verify the connected workspace.

What to Expect after migration?

When you integrate Sentinel into the unified security operations platform (Defender XDR), you can expect to see the following changes:

  • Log tables, queries, and functions in the Microsoft Sentinel workspace will also be available in advanced hunting within Microsoft Defender XDR.
  • The ‘Microsoft Sentinel Contributor’ role will be assigned to the ‘Microsoft Threat Protection’ and ‘WindowsDefenderATP’ apps within the subscription.
  • To avoid duplicate incidents, Active Microsoft Security incident creation rules will be deactivated. This change will only apply to incident creation rules for Microsoft alerts, not to other analytics rules.
  • To ensure consistency, all alerts related to Microsoft Defender XDR products will be streamed directly from the main Microsoft Defender XDR data connector. 

When you integrate Sentinel into the unified security operations platform (Defender XDR), you can enjoy new capabilities such as:

  • Advanced hunting for across different data sets enjoying both Sentinel & XDR raw data
    • Ability to use single user interface and portal for query across different data sets to make hunting more efficient and remove the need for context-switching
    • View and query all data, including data from Defender XDR and Microsoft Sentinel
    • You can leverage existing Sentinel content, such as queries and functions
  • Attack disruption for SAP
    • In addition to Defender XDR automatic attack disruption, you can enjoy the same protection as SAP
  • Unified entity pages for all entity pages
    • Entity pages for devices, users, IP addresses, and Azure resources show details from Sentinel & Defender data sources
  • Unified incidents
    • Single incident view for all incidents across the ecosystem (more details below)

Sentinel content will be available in the Defender XDR left-side menu in the following categories:

  • Threat Management
  • Content Management
  • Configuration

Sentinel settings are found underneath the settings blade, where you can control which workspace is integrated into XDR or other Sentinel settings. At the time of writing, the settings are just links to the Azure portal. Instead, a unified incident view and advanced hunting across all data in Sentinel and XDR are available accordingly.

What to expect for Defender XDR tables streamed to Microsoft Sentinel

There are some interesting changes in Defender XDR data tables if those are streamed into Sentinel through the native Defender XDR data connector. In my opinion, XDR raw data is crucial for effective detection and threat hunting, and I always recommend my customers ingest the XDR data into Sentinel.

Side note: to enjoy the changes listed below, such as longer data retention, you need to ingest XDR raw data into Sentinel in the first place. The list below is from MS Learn.

  • XDR data tables have longer data retention. Advanced hunting follows the maximum data retention period configured for the Defender XDR tables (see Understand quotas). If you stream Defender XDR tables to Microsoft Sentinel and have a data retention period longer than 30 days for said tables, you can query for the longer period in advanced hunting.
  • Use Kusto operators you’ve used in Microsoft Sentinel. In general, queries from Microsoft Sentinel work in advanced hunting, including queries that use the adx() operator. There might be cases where IntelliSense warns you that the operators in your query don’t match the schema. However, you can still run the query, and it should still be executed successfully.
  • Use the time filter dropdown instead of setting the time span in the query. If you’re filtering ingestion of Defender XDR tables to Sentinel instead of streaming the tables as is, don’t filter the time in the query, as this might generate incomplete results. If you set the time in the query, the streamed, filtered data from Sentinel is used because it usually has a longer data retention period. If you would like to make sure you’re querying all Defender XDR data for up to 30 days, use the time filter dropdown provided in the query editor instead.
  • View SourceSystem and MachineGroup columns for Defender XDR data that have been streamed from Microsoft Sentinel – Since the columns SourceSystem and MachineGroup are added to Defender XDR tables once they’re streamed to Microsoft Sentinel; they also appear in results in advanced hunting in Defender. However, they remain blank for Defender XDR tables that weren’t streamed (tables that follow the default 30-day data retention period)

https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-microsoft-defender

Notes from the field

Sentinel in Defender XDR is in the public preview phase at the time of writing. It’s expected that all the features are not 100% integrated into the Defender XDR portal. I have a few customers who have done the integration, and here are some findings you need to take into consideration when planning the integration (some list items from MS Learn):

General

  • All incidents are created on the XDR side
  • XDR does what it is supposed to do, combining alerts and incidents into the full attack path, which might be seen with a lower number of incidents (based on my experience)
  • In some cases, XDR might change the incident name, which could affect your third-party solution sync (for example, Snow, Jira, etc.).
  • XDR might change existing incident names when the correlation is applied
    • Therefore, MS recommends avoiding incident titles in automation rules
  • Fusion analytics rule is disabled when you onboard Sentinel to Defender XDR
  • Some incident management capabilities are available only in the Azure portal
  • Some data connectors are available only in the Azure portal
    • Microsoft Defender for Cloud Apps
    • Microsoft Defender for Endpoint
    • Microsoft Defender for Identity
    • Microsoft Defender for Office 365 (Preview)
    • Microsoft Defender XDR
    • Subscription-based Microsoft Defender for Cloud (Legacy)
    • Tenant-based Microsoft Defender for Cloud (Preview)
  • If you have Sentinel scheduled rules, an alert will be created in Sentinel and synced to XDR.
  • XDR is responsible for creating incidents from the alerts. This means that Defender XDR is a provider of all detections created by Sentinel or XDR
    • In both the Azure portal and Defender XDR, the Incident provider condition property is removed
  • XDR incidents will be synced to the Sentinel incidents table

Automation layer – there are many changes in the automation layer. The full list of changes is found here, I highlight some of them below.

  • XDR might change the incident name in some cases. This might affect your 3rd party solution sync (for example, Snow, Jira, etc)
  • XDR might change existing incident names when the correlation is applied
    • Therefore, MS recommends avoiding incident titles in automation rules
  • XDR might have a different incident severity classification than Sentinel in some cases
  • If you are running automation rules from the XDR portal, there might be a 10min delay
  • You can run playbooks on incidents on the XDR portal but not against alert or entity
  • It is not directly related to automation, but many organizations are using comments to add/enrich information in incidents
    • If you’re adding comments into incidents, that can be done in both portals
    • If you are editing comments in the Azure portal, the changes are not synced to the XDR portal

Permissions

  • Defender XDR honors Azure RBAC permissions and manages roles and permissions for your Microsoft Sentinel users from the Azure portal
  • All RBAC permissions are not necessarily reflected in the MSSP scenario as expected
    • Take into consideration the needed permissions on the Sentinel side to be able to view and manage incidents and automation in the Defender XDR portal
      • Sentinel Reader: view incidents in the Defender portal
      • Sentinel Reader: query data tables or view incidents
      • Sentinel Contributor: take investigative actions on incidents & run automation
      • Or create a custom role – details are here
  • Sync delay typically a few minutes in incidents (in some rare cases, 5-10min in my tests)

In my tests in the MSSP scenario, Azure Lighthouse delegated permissions are not reflected to Defender XDR (URBAC is enabled). The workaround in the MSSP scenario is to set permissions for Entra ID B2B accounts separately. Kind of locally set permissions to Sentinel instance or Sentinel rg.

Also, there are capability differences between the portals that are not listed above. The full list can be found here.

References

Introducing a Unified Microsoft Security Operations portal

Microsoft Sentinel in the Microsoft Defender XDR portal

Connect Microsoft Sentinel to Defender XDR

Automation in Defender XDR (unified security operations platform)