Skip to main content
{ Endpoint Security }

Microsoft Defender for Endpoint Control Drift

Provides the Defender for Endpoint indicators, custom detections, Intune endpoint security policies, and exported suppression rules and device groups that changed since a baseline the team approved.

What this agent does

This read-only agent detects changes to the security controls in Microsoft Defender for Endpoint. It fingerprints each indicator and custom detection rule from the API. It fingerprints the antivirus, attack surface reduction, and endpoint detection and response policies from Intune. It fingerprints the alert suppression rules, device groups with their automation levels, and web content filtering policies from an export I hand it. It compares the fingerprints with a baseline the team approved and reports each control that was deleted, disabled, modified, or created.

The challenge

Defender controls change through the portal, Intune, the API, and integrations, often with no review. A new allow indicator for a file hash or a signing certificate lets that file run on every device. A suppression rule scoped to all devices hides a detection. An attack surface reduction rule moves from block to audit and nobody notices. Teams find unapproved changes only when a detection fails to fire.

The solution

The agent compares current controls only against a baseline that a person approved. It treats a control surface with no approved baseline as a candidate, never as drift. It ranks deleted and disabled controls, and new allow indicators and tenant-wide suppression rules, above modified and created ones. It never approves a baseline itself, to enable defenders to catch unapproved control changes before a detection fails because of them.

Workflow

  1. 01

    Fingerprint controls

    Read each control surface from the API, from Intune, or from the export, and fingerprint each control, ignoring timestamps and editor metadata.

  2. 02

    Compare with the baseline

    Compare each surface with its approved baseline, and mark surfaces without one as candidates.

  3. 03

    Rank drift

    Rank deleted and disabled controls and new allow indicators and tenant-wide suppression rules above modified and created ones.

  4. 04

    Report

    Publish the drift queue, the candidate surfaces, and the surfaces not assessed, with controls replaced by stable pseudonyms.

Agent template 

# Microsoft Defender for Endpoint Control Drift

## Measurable outcomes

Every Defender for Endpoint control that differs from its approved baseline is in the drift queue with its change type. Every surface without an approved baseline is listed. Track the drift count for each change type on every run.

## Procedure

Read these control surfaces from the Defender API: indicators for files, IP addresses, URLs and domains, and certificates, and custom detection rules. Read the antivirus, attack surface reduction, and endpoint detection and response policies from Intune, for devices enrolled in Intune and for devices under security settings management. Report settings pushed by Group Policy or Configuration Manager as not assessed. Read the alert suppression rules, the device groups with their membership rules and automation levels, and the web content filtering policies from the export I hand it, and report each of those surfaces as not assessed when I supply no export. Fingerprint each control from its configuration, and ignore timestamps and the identity of the last editor. Compare each surface with its approved baseline. A control in the baseline and absent now is deleted. A control that is new is created. A control with a changed fingerprint is disabled when it is now off or in audit mode, and modified otherwise. Rank deleted and disabled above modified and created. Rank a new allow indicator and a new suppression rule scoped to all devices with the deleted and disabled controls. A surface with no approved baseline is a candidate, never drift. I approve a baseline for a named run and surface only after I review it. Never approve a baseline to clear drift.

## Requirements

It needs read access to Defender for Endpoint indicators and custom detection rules, through an app registration with the Ti.ReadWrite and CustomDetection.Read.All permissions, read access to Intune endpoint security policies through the DeviceManagementConfiguration.Read.All permission, and the suppression rule, device group, and web content filtering export I hand it, and nothing more. The Ti.ReadWrite permission is the only one Defender offers for reading indicators, and the agent never writes with it. A surface that returns access denied is not assessed, not absent. It never changes Defender or Intune configuration and never approves a baseline. Reports show the surface and change type, with controls replaced by stable pseudonyms.