What to Monitor in Security & Operations with Microsoft Defender

#Context

Security operations teams running Microsoft Defender (Microsoft Defender for Endpoint and Microsoft Defender XDR) face a recurring problem: alert volume and telemetry breadth exceed what a small team can triage without a defined monitoring scope. This deep dive defines one bounded workflow — selecting, validating and operating a monitoring configuration for a specific device group or workload — rather than attempting to cover the entire Defender surface. The scope assumes an existing Microsoft 365

E5 or Defender-licensed tenant with Security Administrator or equivalent role access, and a non-production or pilot device group available for validation before any tenant-wide change (UNI-023).

Operational excellence guidance from Microsoft’s Well-Architected Framework treats observability, safe deployment and readiness as connected disciplines rather than separate checklists (Microsoft Learn, Operational Excellence design principles). That framing applies directly to Defender monitoring: what you observe, how you validate detection logic, and how you recover from a misconfigured rule are the same design problem viewed from three angles.

#Architecture

Microsoft Defender XDR aggregates signal from several product surfaces: Defender for Endpoint (device telemetry, EDR), Defender for Identity (directory and authentication signal), Defender for Cloud Apps (SaaS and OAuth activity), and Defender for Office 365 (mail and collaboration). Each surface emits alerts into a unified incident queue, and advanced hunting exposes the underlying raw tables (DeviceEvents, AlertInfo, IdentityLogonEvents, and related schemas) via Kusto Query Language.

A bounded monitoring workflow requires three architectural decisions, made explicit before implementation: (1) which device or user scope is in-monitor (a pilot group, not the full tenant); (2) which alert and incident severities trigger action versus passive logging

; and (3) where custom detection rules and analytics rules are stored so they can be audited and rolled back. Defender supports custom detection rules built on advanced hunting queries, scheduled on an interval, that generate alerts when a query returns results. These are the primary lever for defining what gets monitored beyond built-in analytics.

An observation, not an assumption: Microsoft’s own operational excellence principles state that automation and safe deployment practices reduce operational risk, but they do not specify Defender-specific thresholds (Microsoft Learn, Operational Excellence design principles). Any severity threshold or scope boundary described below is a recommendation for this workflow, not a vendor-mandated default, and must be confirmed against your current tenant configuration and licence tier (UNI-004, UNI-022).

#Implementation

Implementation proceeds in four steps, each scoped to the pilot device group defined in Architecture.

Step 1 – Confirm scope and permissions. Verify the acting account holds Security Administrator or Security Operator role in Microsoft Entra ID

, and that the target device group exists and is correctly populated in Microsoft Defender for Endpoint’s device groups. Confirm the current Defender product version and licence tier in the Microsoft 365 Defender portal before proceeding, since custom detection rule quotas and advanced hunting table availability vary by licence (UNI-004).

Step 2 – Define the monitored signal set. Choose a narrow, named set of behaviours to monitor for the pilot group — for example, suspicious PowerShell execution chains, unusual sign-in patterns for privileged accounts, or lateral movement indicators. Avoid monitoring “everything”; the bounded scope is what makes triage sustainable.

Step 3 – Build and test a custom detection rule. Write the advanced hunting query against the pilot scope only, run it in query mode first to inspect result volume before saving it as a scheduled detection rule. This distinguishes a read-only diagnostic step from a state-changing configuration step.

Step 4 – Deploy the rule with a defined action and review cadence. Save the rule with an explicit alert severity and a documented action (notify only, or notify plus automated response). Record the rule name, query, and intended scope in change documentation so it can be identified and reversed later.

#Validation

Validation confirms the rule detects the intended signal without generating unmanageable noise, before any tenant-wide rollout.

• Run the underlying advanced hunting query manually against the pilot scope and confirm the result count is proportionate to expected activity, not zero and not excessive.
• Trigger a benign, representative version of the monitored behaviour in the non-production environment (for example, a scripted PowerShell command matching the query pattern) and confirm an alert is generated within the expected schedule interval.
• Review the generated alert in the Microsoft 365 Defender incident queue and confirm severity, affected entity and query reference are all correct.
• Leave the rule active for an observation window (a minimum of 48–72 hours is a reasonable starting point pending your own change-control policy) and review alert volume before considering wider rollout.

#Failure Modes

Three failure patterns are the most common in bounded Defender monitoring pilots.

• Symptom: The custom detection rule generates zero alerts even when the monitored behaviour occurs. Cause: The advanced hunting query references a table or field not populated for the device’s onboarding state, or the device is not correctly onboarded to Defender for Endpoint. Response: Re-run the query manually with a wider time window and confirm the device appears in DeviceInfo; check onboarding status in the portal.
• Symptom: Alert volume is far higher than expected, overwhelming the pilot review. Cause: The query scope was not correctly restricted to the pilot device group, or the detection logic matches common benign activity. Response: Pause the rule (disable, do not delete, to preserve audit history) and refine the query scope before re-enabling.
• Symptom: Detection works in testing but stops firing after a period in production. Cause: Scheduled detection rules can silently fail if the underlying query exceeds execution limits or referenced entities change. Response: Check the rule’s run history in the portal for execution errors and confirm the query still returns results manually.

#Security

Least-privilege design applies at two layers. First, the account used to create and manage detection rules should hold only the Security Administrator or Security Operator role, not Global Administrator, to limit blast radius if that account is compromised. Second, any automated response action attached to a detection rule (such as isolating a device) should itself be scoped and reviewed, since an overly broad automated action is itself a residual risk introduced by the monitoring workflow, not eliminated by it (UNI-024). Document who can modify or disable pilot rules, and treat that list as part of the monitored surface, not an afterthought.

Residual risk that is not eliminated by this workflow: a bounded pilot monitors only the defined signal set and scope; it does not provide tenant-wide coverage, and gaps outside the pilot scope remain until the workflow is deliberately extended and re-validated.

#Recovery

Recovery addresses two scenarios: a misbehaving detection rule, and a misconfigured scope.

If a rule is generating excessive or incorrect alerts, disable it from the Custom detection rules page rather than deleting it. Disabling preserves the rule definition and audit trail while stopping new alert generation immediately; this is the primary containment step and is reversible in both directions (UNI-026).

If the pilot device group scope was defined incorrectly, correct the group membership rather than the rule logic, then re-run the Validation steps above before re-enabling the rule.

Rollback boundary: only the pilot-scoped rule and its associated device group membership are in scope for this workflow’s recovery actions. Tenant-wide security policies, conditional access, and other Defender-integrated products are out of scope and must not be modified as part of recovering from a pilot rule issue.

#Operational Readiness and Next Steps

Before extending this workflow beyond the pilot group, confirm three things: the observation window showed proportionate alert volume, the rollback path (disable rule, correct group membership) was exercised at least once without incident, and the reviewing team has documented who owns rule review going forward. Only after these checks pass should the monitored signal set be considered for wider rollout, and even then, extend it incrementally to one additional device group at a time rather than tenant-wide, repeating the same validation sequence at each step.