SC-200 Configure Microsoft Defender for Endpoint: Advanced Features, ASR Rules, Device Groups and Roles

Microsoft Defender for Endpoint is configured in the Microsoft Defender portal under Settings > Endpoints, plus the endpoint security policies that reach the devices themselves. For SC-200 the work falls into five areas, each matching a skill in the official outline.

A pattern runs through the whole topic: many features are enforced on the device by Microsoft Defender Antivirus. Indicators, ASR rules, network protection and the allow or block file feature all need Defender Antivirus running in active mode. When another antivirus product is primary and Defender Antivirus is in passive mode, those features don't work, which is the gap EDR in block mode partly fills. Automated investigation and response itself, and automatic attack disruption, are covered in the Defender XDR automation lesson; this lesson covers the Defender for Endpoint settings that shape them.

Advanced features are tenant-wide on/off settings that turn Defender for Endpoint capabilities on for every onboarded device. Each solves a specific problem, so learn them by the problem.

Restrict correlation to within scoped device groups

By default Defender XDR correlates alerts from any devices into one incident. If regional analysts can see only their own device group, an incident spanning two regions is visible only to users who can access every group involved. Turning this feature on keeps correlation inside each device group, so each regional team gets an incident it can work, at the cost of the global SOC seeing several smaller incidents. The change applies to alerts correlated after it is made: incidents that already exist are never re-split.

EDR in block mode

When a non-Microsoft antivirus is primary, Defender Antivirus runs in passive mode and doesn't block anything itself. EDR in block mode (Defender for Endpoint Plan 2) lets Defender Antivirus act on malicious artifacts that EDR's behavioral detections find, without replacing the other product. It is not a substitute for active mode: indicators, ASR rules and network protection still aren't enforced. It respects Defender Antivirus exclusions, but not Defender for Endpoint indicators.

Tamper protection

Attackers with local administrator rights often turn off real-time protection (for example with PowerShell) before running ransomware. Tamper protection locks Defender Antivirus settings such as real-time protection, cloud-delivered protection and behavior monitoring so they can't be changed through apps, scripts or the registry. It protects settings; it doesn't remediate threats, and it's different from authenticated telemetry, which protects what devices report.

Live response gives analysts a remote shell on a device, and using it depends on two independent controls: the tenant's live response advanced features, and the analyst's live response permission level. If sessions work on some devices but not others in the same device group, the permissions are fine and a tenant toggle is missing.

• Live response enables sessions on client devices.
• Live response for servers is a separate toggle; without it no one can start a session on Windows Server, whatever their role.
• Live response unsigned script execution lets sessions run scripts that aren't code-signed. By default only signed scripts run.

So running an in-house unsigned script needs the Advanced permission and the unsigned-script toggle. Uploading a script to the library from the live response console additionally needs Manage security settings; uploading it from the library management page needs no extra permission.

Indicators (Settings > Endpoints > Rules > Indicators) are your own allow or block entries for file hashes, certificates, IP addresses, and URLs or domains, scoped to all devices or to chosen device groups. Each indicator has an action, an optional Generate alert choice (it controls only whether an alert is raised, not whether the action is enforced) and an expiry. A tenant can hold up to 15,000 indicators.

Choose the type by what must be covered. A hash indicator stops one known sample; other tools, or a re-signed variant, still run. A certificate indicator matches the signer, so it is the answer when a stolen code-signing certificate must be blocked for files you haven't seen yet, and Block and remediate also removes copies already present. To stop all connections to a command-and-control address, whatever process makes them, use an IP or domain indicator rather than blocking individual files.

Indicators are not enforced while Defender Antivirus is in passive mode, and EDR in block mode doesn't enforce them either. On those devices a Block and remediate indicator has no enforcement point.

How network indicators are enforced

• In Microsoft Edge, Microsoft Defender SmartScreen enforces URL and domain indicators.
• In Chrome, Firefox and every other process, network protection enforces them, and it must be in block mode; audit mode only logs the connection. Windows Server has its own separate setting to turn network protection on.
• Network protection reads the domain of an HTTPS connection from the TLS handshake (the unencrypted ClientHello over TCP). Non-Microsoft browsers that use QUIC or Encrypted Client Hello hide it, so both must be turned off by browser policy for domain blocking to work there.
• An indicator with a full HTTPS URL path (not just a domain) can be blocked only in Microsoft Edge.

Web content filtering blocks whole categories of websites (for example gambling or social networking) through policies scoped to device groups, and reports access to every category. Turn on the Web content filtering advanced feature, then create policies under Settings > Endpoints > Rules > Web content filtering, choosing the categories to block and the device groups in scope.

• Enforcement is the same as for network indicators: SmartScreen in Microsoft Edge, network protection in block mode in other browsers. Sites blocked in Edge but reachable in Chrome or Firefox point to network protection not being in block mode.
• Overlapping policies don't cancel each other. When several policies apply to a device, the most restrictive result for each category wins.
• Allow indicators take precedence over web content filtering. To open one site inside a blocked category for one team, create an Allow URL/domain indicator scoped to that team's device group.
• Category filtering doesn't depend on the custom network indicators feature; that feature is only for your own IP and URL indicators. A brand-new malicious address is usually uncategorized, so block it with an indicator, not a category.

The rest of the Rules settings tune what Defender for Endpoint alerts on, what automation leaves alone, and what extra telemetry the sensor collects.

• Alert suppression rules stop known-benign alerts from being raised again (alert tuning across Defender XDR is covered in the Defender XDR automation lesson).
• Automation folder exclusions list folders that automated investigation won't remediate in.

Both are managed by users holding the Manage security settings in Security Center permission.

Custom data collection

Custom data collection rules (Settings > Endpoints > Rules > Custom data collection) make the existing Defender for Endpoint sensor collect events beyond its defaults, such as every script execution or network connection on selected devices, without deploying another agent. Know its requirements and limits:

• It needs Defender for Endpoint Plan 2 and a Microsoft Sentinel workspace connected to the Defender portal. The collected events land in that workspace in tables prefixed DeviceCustom, for example DeviceCustomNetworkEvents and DeviceCustomScriptEvents, and are billed as Sentinel ingestion.
• Rules target devices by dynamic tags only. A tag typed by hand on a device page is a manual tag and can't be used. Create the tag with a rule in Asset rule management (Settings > Microsoft Defender XDR), which applies it from conditions such as device name, domain or OS, and let that rule run.
• Each rule can capture up to 75,000 events per device in a rolling 24 hours. When a rule hits the limit on a busy device, only that rule stops on that device until the window resets; other rules carry on. Fix it by narrowing the rule's conditions or splitting it into focused rules.

Custom data collection adds telemetry through the sensor that is already on the device; it is not an alert rule and not a retention setting.

ASR rules block behaviors that malware commonly abuses, such as Office apps creating child processes or credential theft from LSASS, and each rule is set to one of five states.

Test new rules in Audit mode first to see which line-of-business apps would be affected without interrupting users, add exclusions, then move to Block (or Warn). Audit and block events appear in the ASR rules report, in Windows event logs and in the DeviceEvents table:

DeviceEvents
| where ActionType startswith "Asr"
| where ActionType endswith "Audited"
| summarize count() by ActionType, DeviceName

Warn mode isn't a durable exception; when an app needs a lasting one, Microsoft advises a per-rule exclusion. Not every rule supports Warn (the LSASS credential-stealing rule and Block Office applications from injecting code into other processes don't), and Warn can't be set through Configuration Manager.

Standard protection rules

Microsoft recommends three rules for almost every organization and says they can go straight to Block: Block abuse of exploited vulnerable signed drivers, Block credential stealing from the Windows local security authority subsystem and Block persistence through WMI event subscription. The exception: on devices managed by Configuration Manager, test the WMI persistence rule in Audit first, because the Configuration Manager client relies on WMI. Its near-twin, Block process creations originating from PSExec and WMI commands, also conflicts with Configuration Manager but isn't a standard protection rule.

Requirements

ASR rules are a Defender Antivirus feature for Windows devices. They need Defender Antivirus as the primary antivirus in active mode (not passive, not limited periodic scanning, not off), with real-time protection on; several rules also need cloud-delivered protection. When those conditions aren't met, a device can receive the policy and the rules still do nothing. Microsoft 365 E5 or equivalent subscriptions add the advanced management, monitoring and reporting; the rules themselves are enforced without them.

ASR exclusions: global, per-rule and antivirus

Choose the narrowest exclusion that fixes a false positive: a per-rule exclusion lets one file or path bypass one ASR rule, a global ASR exclusion lets it bypass every ASR rule, and a Defender Antivirus exclusion also stops antivirus scanning.

Not every rule honors every exclusion type. In particular, Block credential stealing from the Windows local security authority subsystem ignores Defender Antivirus file and folder exclusions and file indicators, so adding an antivirus exclusion doesn't stop its blocks; it does honor global and per-rule ASR exclusions. Defender Antivirus process exclusions are honored by all ASR rules. When an antivirus exclusion doesn't stop an ASR block, an ASR exclusion is the fix.

Defender for Endpoint security settings management lets the Defender for Endpoint agent receive and enforce Intune endpoint security policies on devices that aren't enrolled in Intune or managed by Configuration Manager, such as onboarded servers.

• Turn it on in the Defender portal at Settings > Endpoints > Configuration management > Enforcement scope, per platform (Windows client, Windows Server, macOS, Linux). In the Intune admin center, the connector setting that allows Defender for Endpoint to enforce endpoint security configurations must also be on.
• Pilot with tags. For each platform choose all devices or tagged devices. With tagged devices, only devices carrying the MDE-Management tag enroll, which is Microsoft's recommended way to pilot. Choosing all devices enrolls every onboarded device, so the tag no longer limits anything.
• Target policies with Microsoft Entra groups, not Defender device groups. Managed devices get an Entra registration (a synthetic one if they aren't joined) so they can be group members.
• Supported profiles include antivirus, antivirus exclusions, firewall, firewall rules, EDR and ASR rules. For Windows devices, create them on the Windows platform; profiles on the Windows 10 and later platform aren't supported for devices managed this way.

A device group is a set of devices defined by matching rules (device name, domain, tag, OS) that shares one remediation level and is visible only to the Microsoft Entra user groups assigned to it. Create them at Settings > Endpoints > Permissions > Device groups.

• Single membership by rank. A device that matches several groups joins only the highest-ranked one, and rank 1 is the highest (a lower number wins). It never belongs to two groups or merges their settings.
• Ungrouped devices (default) holds every device that matches no group.
• Access is open until you restrict it. A device group with no Entra user group on its User access page is visible to everyone with portal access. Assign the intended user groups when you create the group, not later.
• Device groups also scope indicators, web content filtering policies and scoped incident correlation. They don't scope ASR rules, endpoint security policies or custom data collection.

Remediation levels (automation levels)

Each device group's remediation level decides whether remediation actions found by automated investigation run automatically or wait for approval in the Action center.

The two middle levels are mirror images: system folders asks for approval only in the OS folders, non-temporary folders automates only the temporary folders. Pick All folders when actions must still be proposed but never run unapproved (for example on domain controllers), and avoid No automated response in that case, because nothing would be proposed at all. Microsoft recommends Full remediation where it's acceptable. Remediation levels don't affect live response or indicators.

Defender for Endpoint access is controlled either by basic permissions (Entra roles only) or by role-based access control (RBAC), where a role sets what users can do and the device group's user access sets where they can do it.

Switching on RBAC

With basic permissions, Entra Global Administrators and Security Administrators have full access and Security Readers have read-only access. Turning on RBAC (needed for scoped device groups) is one-way, and read-only users such as Security Readers lose access until they are assigned a role. Plan the roles before you switch.

Role permissions

For least privilege, build a custom role with only the permissions the job needs, assign it to an Entra group, and add that group on the User access page of the device groups it should reach. The device group's User access assignment is what scopes a role.

Unified RBAC

Microsoft Defender XDR Unified RBAC (Permissions > Microsoft Defender XDR > Roles) manages permissions for Defender for Endpoint and the other Defender workloads in one model, with device-group scoping. Tenants that started using Defender for Endpoint more recently get Unified RBAC only; older tenants may still use the Defender for Endpoint roles described above.