Your organisation wants to enable the attack surface reduction rule that blocks executable content from email clients and webmail across all onboarded Windows devices. Security operations is concerned that a small number of line-of-business workflows might rely on this behaviour, and they must measure the real-world impact for two weeks before any block takes effect, while still generating telemetry the team can hunt over. How should the rule be configured for this initial rollout?
- ASet the rule to Block, then add per-application exclusions for any line-of-business tool that breaks, so the rule enforces immediately while the discovered exceptions keep the workflows running during the trial.
- BSet the rule to Warn, which prompts the user with a dismissible message each time the rule triggers, so end users decide whether to proceed while the team reviews how often the prompt is dismissed.
- CSet the rule to Audit, which lets the offending action proceed but records a DeviceEvents entry each time the rule would have triggered, so the team can measure impact for two weeks before switching it to Block. Correct
- DSet the rule to Not configured, then rely on Microsoft Defender for Endpoint device discovery to passively report which devices use email-borne executables, so impact is gauged without enabling the rule at all.
Why A is wrong: Block enforces straight away, which is exactly what the requirement forbids during the measurement window, and chasing breakages with exclusions reacts after disruption has already occurred rather than measuring impact safely first.
Why B is wrong: Warn does surface the rule and can be bypassed by the user, but it already disrupts the workflow with a prompt and is not the non-intrusive measurement mode the requirement calls for during a silent two-week impact assessment.
Why C is correct: Audit mode evaluates the rule and logs every would-be block to DeviceEvents without stopping the action, giving the exact telemetry needed to gauge impact over the trial before promoting the rule to Block enforcement.
Why D is wrong: Not configured leaves the rule inactive so it produces no ASR evaluation telemetry, and device discovery inventories unmanaged devices on the network rather than recording which workflows the rule would have blocked.