Defender XDR - Part 5f - Unified Console

Rolling Aerts into Incidents - XDR

A key strength of Microsoft Defender is its ability to correlate disparate alerts from various detection sources into a single, cohesive incident view. This approach enables defenders to understand an attack or compromise holistically rather than managing fragmented alerts.

Microsoft Defender XDR extends this capability by continuing to unify and correlate alerts from multiple security domains, identity, endpoint, email, and cloud applications, into a single, actionable incident.

For example, ransomware attacks often involve a series of coordinated techniques across different systems, from identity compromise to endpoint exploitation. Each system may have its own Defender tool to prevent and detect specific threats. Defender XDR correlates these individual alerts to provide a comprehensive view of the attack, enabling faster and more effective responses.

A detailed example of this correlation in action can be found in this Microsoft article on ransomware detection: Detecting Ransomware with Microsoft 365 Defender: https://learn.microsoft.com/en-us/microsoft-365/security/defender/playbook-detecting-ransomware-m365-defender?view=o365-worldwide

This unified approach ensures that security teams can efficiently manage incidents and mitigate threats using insights from across the Defender ecosystem.

[image from article]

Working off the EDR/XDR Console or SIEM

In Security Operations Centers (SOCs), there’s often a dual-tool approach to managing threats and incidents:

1. EDR/XDR Systems:

• These tools act as a "SOC in a box," monitoring telemetry from various integrated detection sources.

• They provide capabilities for alerting, automated and manual containment, remediation actions, and event/log analysis within their supported scope.

2. SIEM Systems:

• Complementing the EDR/XDR, SIEM platforms aggregate logs and alerts from a broader range of non-EDR/XDR systems and cyber sensors across the organization.

• They centralize data from diverse sources to provide a more comprehensive view of the security environment.

While EDR/XDR tools excel at detection and response for specific domains (e.g., endpoints, identity, cloud), the SIEM serves as the overarching repository and analysis tool for the entire security ecosystem. Together, they form a synergistic approach to threat detection and incident management.

[image]

This dynamic gives rise to several common operating models in SOCs. One prevalent approach is where EDR/XDR alerts are integrated into the SIEM, enabling the SOC to operate primarily from the SIEM as a centralized platform for monitoring, analysis, and response.

[image]

Here are examples of Elastic Common Schema (ECS) field mappings that illustrate how data from Microsoft Defender is integrated:

• The Defender detection source, such as Defender for Cloud Apps (MDA), is parsed into the ECS field event.provider by the Elastic Defender integration.

• A specific feature within MDA, such as CustomTI, is mapped to the field M365_defender.alert.detection_source.

These mappings demonstrate how Elastic organizes and standardizes data from Defender EDR/XDR.

m365_defender.alert.title : Malware detection
event.provider : microsoftDefenderForCloudApps
file.name : Client Shutdown Software_V#.##.exe
m365_defender.alert.detection_source : customTi

Sending EDR/XDR alerts to a SIEM is a common practice and perfectly valid, but there are key challenges that often lead SOC analysts to work simultaneously within both the SIEM and the EDR/XDR consoles. Here’s why:

1. Integration Limitations:

• Not all EDR/XDR detection sources integrate seamlessly with a SIEM. For example, while Microsoft Defender comprises components like MDE, MDI, MDO, and MDA, these are often deployed independently. Consequently, a SIEM might easily ingest alerts from MDE but struggle with MDI or MDA alerts.

2. Incomplete Alert Management Capabilities:

• SIEM platforms typically lack the full functionality of EDR/XDR consoles for alert/incident assignment, tagging, adding notes, or marking resolution.

• This creates three options:

  • Leave these fields (e.g., assignment, tagging, notes, resolution) incomplete in the EDR/XDR console.

  • Manually log into the EDR/XDR console to update them.

  • Automate these actions programmatically from the SIEM using SOAR tools or operate directly from a SOAR platform that integrates with both the SIEM and EDR/XDR systems.

3. Advanced Actions in EDR/XDR Consoles:

• Analysts frequently need to perform tasks like containment, timeline analysis, pivoting, or threat hunting directly within the EDR/XDR console.

• While SOAR automation can streamline certain actions, replicating the full functionality and intuitive user interface of a native EDR/XDR platform often requires significant effort. In many cases, the time and resources needed to achieve the same level of capability may outweigh the benefits.

• In many cases, the SIEM simply includes a link back to the EDR/XDR alert or incident, allowing the analyst to pivot into the native platform when necessary.

This dual-console approach highlights the complementary nature of SIEM and EDR/XDR systems, where the SIEM offers centralized visibility, and the EDR/XDR console provides specialized tools for deeper analysis and response.