Enhanced Monitoring in Defender XDR & Sentinel
- brencronin
- Mar 5
- 8 min read
Enhanced Monitoring Overview
In environments using Microsoft Defender XDR and Microsoft Sentinel, there are situations where enhanced monitoring is required beyond normal security operations. This article outlines several enhanced monitoring approaches and explains the nuances associated with each.
The starting point is understanding the steady-state security monitoring model in an environment where Defender XDR and Sentinel are integrated. In this architecture, detections are generated by Detection Engines (DE) within each platform.
In Defender XDR, detections primarily originate from the underlying Microsoft security products that feed the platform. Examples include Microsoft Defender for Endpoint (MDE) and Microsoft Defender for Office 365 (MDO), among others. These products generate alerts based on their native detection logic, which Defender XDR then aggregates and correlates into incidents.
In Sentinel, the detection engine operates differently. Sentinel detections are driven by analytics rules, which may include:
Microsoft-provided detection content installed with data connectors
Built-in analytics templates
Custom detection logic written in Kusto Query Language (KQL)
These analytics rules can operate on a wide range of log sources, including Microsoft telemetry as well as third-party or non-Microsoft data ingested into Sentinel.
When Defender XDR and Sentinel are properly connected, incidents generated by their respective detection engines should synchronize between the two platforms, providing a unified investigation experience.
Enhanced Monitoring Approaches
There are several approaches to implementing enhanced monitoring, and these approaches are not mutually exclusive. In practice, multiple techniques are often combined to create overlap. In some cases, this overlap is necessary because each method addresses different visibility gaps within the environment.
The first approach is to analyze the available telemetry in Microsoft Sentinel and answer several foundational questions:
What type of enhanced monitoring is required?
What monitoring is realistically possible based on the telemetry currently ingested into Sentinel?
How should that telemetry be analyzed?
There are generally three analysis models to consider:
Detection-driven analysis – Creating analytics rules that generate alerts when specific conditions are met.
Analyst-driven analysis – Using data exploration and investigative queries to track activity patterns and identify suspicious behavior or anomalies over time.
Hybrid monitoring – A combination of automated detections and ongoing analyst-led data analysis.
This introduces a common challenge in detection engineering. If detection logic is written too broadly, it can generate excessive alerts and quickly become operationally ineffective. Conversely, if detection criteria are overly narrow, important signals may be missed.
The key principle is that not every analytical question should be implemented as a detection rule. Some monitoring objectives are better suited to periodic analysis, threat hunting, or dashboard-based visibility rather than real-time alerting.
Analyst-Driven Analysis Using Sentinel Workbooks
Another approach to enhanced monitoring is analyst-driven analysis using workbooks in Microsoft Sentinel.
In this model, SOC analysts review Sentinel workbooks to analyze telemetry, identify trends, and monitor activity patterns that may not warrant automated detections.
A key advantage of workbooks is collaboration and shared visibility. Workbooks can be shared across the SOC team and with leadership, allowing multiple analysts or stakeholders to view the same dashboards and analytical outputs. This shared view helps ensure the team maintains a consistent understanding of ongoing monitoring and analysis.
One operational consideration is that workbook-based monitoring requires analysts to open and review a separate analytical object during their shift rather than relying solely on alert queues. However, Microsoft has improved accessibility by making Sentinel workbooks available through the unified security console in Microsoft Defender XDR, enabling analysts to access these dashboards within the same investigation interface used for alerts and incidents.
Reusing Enhanced Monitoring Workbooks
Once created, enhanced monitoring workbooks can be reused for future monitoring exercises. To apply them to a new event, you simply update the user and device lists associated with enhanced monitoring. This allows the same workbook structure and queries to be leveraged without rebuilding the workbooks from scratch, ensuring efficiency and consistency across multiple monitoring initiatives.
Prioritizing Enhanced Monitoring Within Standard Alerts
A common challenge in enhanced monitoring scenarios is ensuring that alerts involving enhanced-monitoring users or devices are prioritized appropriately, even when they trigger routine detections.
In practice, SOC analysts are expected to treat all detections with a high level of diligence. However, operational realities such as alert volume and workload balancing often require prioritization decisions. Because of this, it is important to ensure that alerts associated with enhanced-monitoring entities are clearly elevated above normal alert traffic.
When a routine detection triggers on a user or device that has been placed under enhanced monitoring, that alert should automatically surface to the top of the investigation queue. This allows analysts to quickly identify and respond to activity involving high-interest accounts, systems, or investigative targets.
Using Sentinel Watchlists for Enhanced Monitoring
When Microsoft Defender XDR and Microsoft Sentinel are integrated, incidents generated in one platform are synchronized with the other. Understanding how alerts and incidents function in this architecture is essential when implementing enhanced monitoring with Sentinel watchlists.
In Microsoft’s security model, an alert represents a single detection event, while an incident is a higher-level object that correlates one or more alerts related to the same activity or investigation.
For example, consider a scenario where two systems communicate with a known malicious IP address:
User A’s system connects to the malicious IP.
User B’s system connects to the same malicious IP.
In this situation:
An alert is generated for User A’s system.
A second alert is generated for User B’s system.
These alerts may be correlated into a single incident, with the two alerts appearing as child objects under the incident.
There are also many situations where only a single alert is generated. In those cases, the incident simply contains one alert associated with it.
It is also important to recognize that alerts and incidents are forms of metadata, that is, data about other data. In the previous example:
The underlying log events (Firewall, Azure activity, DeviceNetwork, etc) record the actual network connection to the malicious IP.
The alert is metadata indicating that the detection logic identified that activity as suspicious.
The incident is additional metadata that groups related alerts together for investigation.
Both alert metadata and incident metadata are ingested and stored within Sentinel. This allows analysts to query, enrich, and correlate them with other data sources, which is where mechanisms such as Sentinel watchlists can be applied to support enhanced monitoring of specific users, devices, or entities.
Querying Alert Metadata Against Watchlists
In the example below, a query retrieves alert metadata and compares it against an enhanced monitoring list maintained in Sentinel watchlists within Microsoft Sentinel. This allows alerts involving users, devices, or entities on the enhanced monitoring list to be quickly identified and elevated for analyst attention.
It is also important to understand that the storage of alert and incident metadata in Sentinel is separate from the incident synchronization process between Microsoft Defender XDR and Sentinel. While incidents may be synchronized between the two platforms for investigation purposes, the underlying alert and incident metadata logs are independently stored within Sentinel. This separation enables analysts to query, correlate, and enrich detection data directly within Sentinel regardless of where the original incident was generated.
Entity Tagging in Defender XDR
Microsoft Defender XDR provides a native mechanism for tagging entities, which can include users and devices. These tags allow organizations to designate certain accounts or systems as higher priority within the security monitoring workflow.
For example, tagging a user as a priority or sensitive user enables several operational benefits. Alerts and incidents involving that user can be automatically prioritized within Defender XDR, ensuring that activity associated with high-value or high-risk entities receives faster analyst attention. This prioritization operates independently of monitoring mechanisms such as watchlists used in Microsoft Sentinel workbooks or analytics.
In addition to alert prioritization, entity tagging can also enable differentiated security controls and protections for those users or devices. This allows security teams to apply more aggressive monitoring or defensive measures to critical assets while maintaining standard protections for the broader environment.
Tagging Gap for Non-Microsoft Detection Sources
A monitoring gap can occur when detections originate from non-Microsoft log sources. Entity tagging in Microsoft Defender XDR is effective for prioritizing alerts generated by Microsoft security products, but it does not always apply cleanly when incidents are created by custom detections or third-party telemetry.
In these situations, watchlists in Microsoft Sentinel provide an effective mechanism for maintaining enhanced monitoring coverage.
The workflow operates as follows:
A detection rule in Sentinel analyzes log data from a non-Microsoft source and creates an incident.
That incident synchronizes to Defender XDR through the platform integration.
Defender XDR generates a corresponding security alert representing the synchronized Sentinel incident.
The alert metadata is then stored back in Sentinel as part of the alert log data.
As discussed previously, a Sentinel workbook can query these alert records and compare them against the enhanced-monitoring watchlist. This allows analysts to identify when incidents generated from non-Microsoft telemetry involve users or devices that are under enhanced monitoring, ensuring those cases are elevated for review even when native Defender XDR tagging does not apply.
Enhanced Monitoring Through Custom Detections
As part of the enhanced monitoring research process, organizations may determine that certain activities involving monitored users or devices should generate automated alerts, rather than being reviewed only through workbook-based analysis.
In these cases, the same queries used to build enhanced monitoring workbooks in Microsoft Sentinel can also be adapted to create custom detection rules. These detections become part of the standard SOC detection pipeline and are executed by the Sentinel detection engine.
When triggered, these detections generate incidents in Sentinel that can then synchronize to Microsoft Defender XDR, allowing them to flow into the organization’s normal SOC investigation and response processes.
These types of detections are often based on “zero-result” queries, where the expected steady-state condition is that the query returns no results. Any match indicates activity involving an entity under enhanced monitoring and therefore warrants immediate alerting and investigation.
Why Not Modify Existing Detections for Enhanced Monitoring?
A common question when implementing enhanced monitoring is why organizations do not simply duplicate/modify existing detection rules to include enhanced-monitoring users and devices. While this approach may appear straightforward, there are two primary reasons it is generally not the preferred starting point.
1. Operational and Maintenance Overhead
Incorporating enhanced-monitoring users directly into existing detections would typically require duplicating many detection rules and then modifying those copies to account for the monitored users or devices. This creates significant operational overhead, including additional rule maintenance, testing, and resource consumption.
In contrast, querying Security Alert metadata and comparing it against enhanced-monitoring watchlists in Microsoft Sentinel provides a far more efficient approach. It allows the SOC to identify alerts involving monitored entities without duplicating the entire detection rule set.
2. Enhanced Monitoring Extends Beyond Users and Devices
Enhanced monitoring is broader than simply identifying high-risk users or devices. The overall monitoring strategy often depends on contextual factors, such as:
Travel location or geographic anomalies
Specific tools, applications, or access patterns
Temporary operational circumstances that elevate risk
Because of this, enhanced monitoring frequently requires context-driven analysis and flexible queries, rather than static modifications to existing detections. Leveraging analytics, workbooks, and watchlists in Sentinel, combined with alert prioritization capabilities in Microsoft Defender XDR, provides a more scalable and adaptable monitoring model.
Enhanced Monitoring Research Drives New Detections
Research conducted during enhanced monitoring exercises often identifies patterns or behaviors that warrant new detection rules. Insights gained while investigating enhanced-monitoring events can be applied more broadly, allowing the SOC to develop detections for all users or devices that exhibited similar activity. This process ensures that lessons learned during targeted monitoring contribute to the organization’s overall detection capabilities and strengthen security coverage across the environment.
References
A Practical Guide to Using User Tags in Microsoft Defender for Office 36
User tags in Microsoft Defender for Office 365
Defender for Identity entity tags in Microsoft Defender XDR
Defender docs