Study guide
Technical reference and lesson notes
Purpose of This Lesson
Attack Surface Reduction, commonly called ASR, is a Microsoft Defender for Endpoint capability used to reduce the number of ways an attacker can compromise a Windows device. For the SC-200 exam, this topic matters because Security Operations Analysts need to understand how endpoint prevention controls affect detection, investigation, alert triage, ransomware defense, and endpoint hardening.
ASR rules help prevent common attacker techniques such as malicious Office macro behavior, script abuse, credential theft from LSASS, suspicious child processes, ransomware-like behavior, and abuse of remote execution tools. Microsoft recommends enabling standard protection rules and testing other ASR rules in Audit mode before enforcing them in Block or Warn mode.
Key Concepts
What Is an Attack Surface?
An attack surface is the collection of possible ways an attacker can enter, exploit, or abuse a system. On an endpoint, this can include:
- Email attachments
- Office macros
- Scripts
- Browsers
- USB devices
- Vulnerable drivers
- Remote management tools
- Credential theft attempts
- Web shells on servers
- Ransomware behavior
- Applications launching suspicious child processes
The goal of attack surface reduction is not just to detect malicious activity after compromise. The goal is to reduce the number of behaviors that attackers can abuse in the first place.
In Microsoft Defender for Endpoint, ASR rules focus on risky behaviors commonly used by malware and hands-on-keyboard attackers. Microsoft describes ASR rules as protections against attacks that use macros, scripts, and common injection techniques.
What Are ASR Rules?
Attack Surface Reduction rules are endpoint security controls in Microsoft Defender for Endpoint that block, warn, or audit specific behaviors. They are especially important on Windows endpoints because Windows receives the broadest ASR rule support compared to other operating systems.
Common ASR rule categories include:
- Blocking Office applications from creating child processes
- Blocking Office macros from calling Win32 APIs
- Blocking executable content from email and webmail
- Blocking JavaScript or VBScript from launching downloaded executables
- Blocking credential stealing from LSASS
- Blocking abuse of vulnerable signed drivers
- Blocking persistence through WMI event subscriptions
- Blocking process creation from PsExec and WMI commands
- Blocking executable content from USB devices
- Blocking Adobe Reader from creating child processes
- Blocking web shell creation on servers
- Enabling ransomware protection behavior
- Enabling Controlled Folder Access
ASR rules are prevention-focused, but they also support SOC visibility because audit and block events can be reviewed in Defender reporting and Advanced Hunting. ASR events are available in the DeviceEvents table in Microsoft Defender XDR Advanced Hunting.
ASR Rule Modes: Off, Audit, Warn, and Block
ASR rules can generally be configured in several modes.
| Mode | Meaning | SOC / Operations Use |
|---|---|---|
| Off | The rule is not enforced or audited. | No protection or useful signal from that rule. |
| Audit | Defender records what would have happened if the rule were enforced. | Best for testing impact before enforcement. |
| Warn | The user is warned and may be able to bypass depending on configuration. | Useful when you want friction without full blocking. |
| Block | The behavior is prevented. | Strongest protection, but requires testing to avoid business disruption. |
For real environments, Audit mode is critical. It allows the SOC and endpoint team to understand which rules would fire before those rules start blocking users, applications, scripts, or business workflows. Microsoft specifically recommends testing non-standard ASR rules in Audit mode before moving them to Block or Warn mode.
Standard Protection Rules vs Other ASR Rules
Microsoft groups some ASR rules as standard protection rules. These are the rules Microsoft generally expects organizations to enable with minimal end-user impact while they evaluate the rest of the ASR rule set.
The standard protection rules include protections such as:
- Blocking abuse of exploited vulnerable signed drivers
- Blocking credential stealing from the Windows Local Security Authority Subsystem Service, or LSASS
- Blocking persistence through WMI event subscriptions
The exam-relevant point is this: standard protection rules are usually safer to enable earlier, while other ASR rules should normally be piloted, audited, and reviewed before broad enforcement.
Where ASR Rules Are Configured
ASR rules can be managed through Microsoft endpoint security policy workflows. In modern Microsoft environments, this often involves:
- Microsoft Defender portal
- Microsoft Intune endpoint security policies
- Defender for Endpoint security settings management
- Group Policy
- PowerShell
- Configuration Manager
In the portal workflow shown in the lesson, the policy is created under endpoint security policy settings for Windows devices. Microsoft Intune endpoint security policies can configure attack surface reduction settings for managed devices when Microsoft Defender Antivirus is in use.
A typical policy workflow looks like this:
- Go to the Microsoft Defender / security portal.
- Navigate to endpoint security policy configuration.
- Create a new Windows endpoint security policy.
- Select the Attack Surface Reduction Rules profile.
- Configure each ASR rule as Off, Audit, Warn, or Block.
- Add exclusions only when justified.
- Assign the policy to a device group.
- Save and allow time for policy sync.
- Review ASR events and reports.
- Move carefully from Audit to Warn or Block after validation.
Windows, macOS, and Linux Considerations
ASR rules are primarily a Windows endpoint protection capability. Other operating systems may support different Microsoft Defender for Endpoint settings, but the exact same ASR rule templates are not necessarily available across Windows, macOS, and Linux.
For SC-200, remember that when the scenario involves ASR rules such as blocking Office child processes, macro abuse, LSASS credential theft, WMI persistence, or executable content from email, the expected workload is usually Windows endpoints protected by Microsoft Defender for Endpoint.
Important ASR Rule Examples
Block Office Applications from Creating Child Processes
This rule helps prevent Office applications like Word, Excel, PowerPoint, and Outlook from launching suspicious child processes. Attackers frequently abuse Office documents to spawn PowerShell, cmd.exe, wscript.exe, or other tools.
SOC relevance:
- Useful against phishing attachments and malicious documents.
- Helps stop macro-based initial access.
- Can generate alerts or hunting events if Office tries to spawn suspicious processes.
Exam angle:
- If the scenario involves malicious Office documents launching scripts or command shells, think Defender for Endpoint ASR.
Block Win32 API Calls from Office Macros
This rule targets more advanced macro abuse. A malicious macro may call Windows APIs to download payloads, manipulate memory, or interact with the OS in suspicious ways.
SOC relevance:
- Reduces risk from macro malware.
- Supports email-to-endpoint investigation workflows.
- Can connect Defender for Office 365 phishing detection with Defender for Endpoint device behavior.
Block Executable Content from Email Client and Webmail
This rule helps stop executable payloads launched from email or webmail.
SOC relevance:
- Useful when phishing is a major initial access vector.
- Helps reduce malware execution from user-downloaded attachments.
- Works alongside Defender for Office 365, but it is enforced at the endpoint behavior layer.
Block JavaScript or VBScript from Launching Downloaded Executables
Attackers often use scripts as a first-stage downloader. This ASR rule helps prevent script files from launching downloaded payloads.
SOC relevance:
- Useful against phishing, drive-by downloads, and script-based malware.
- Helps reduce initial execution opportunities.
Block Credential Stealing from LSASS
LSASS stores sensitive authentication material. Attackers often attempt to dump LSASS memory to extract credentials.
SOC relevance:
- Strong defensive control against credential theft.
- Relevant to lateral movement and privilege escalation investigations.
- Pairs well with identity investigation in Microsoft Defender XDR.
Exam angle:
- If the scenario involves credential theft from a Windows endpoint, Defender for Endpoint ASR is highly relevant.
Block Persistence Through WMI Event Subscriptions
WMI can be abused for persistence. An attacker may create event subscriptions that execute malicious commands when certain system events occur.
SOC relevance:
- Helps prevent stealthy persistence.
- Useful in post-compromise hardening.
- Relevant to MITRE ATT&CK persistence techniques.
Block Process Creation from PsExec and WMI Commands
PsExec and WMI are legitimate administrative tools, but attackers also abuse them for lateral movement and remote execution.
SOC relevance:
- Useful in ransomware containment strategies.
- May impact legitimate admin workflows.
- Should be tested before broad enforcement.
Real-world gotcha:
- Blocking PsExec or WMI process creation without testing can disrupt IT operations, scripts, remote management, or software deployment.
Block Abuse of Exploited Vulnerable Signed Drivers
Attackers sometimes abuse legitimately signed but vulnerable drivers. This rule helps block known abused vulnerable drivers.
SOC relevance:
- Protects against kernel-level abuse and bring-your-own-vulnerable-driver techniques.
- Important for endpoint hardening.
Block Web Shell Creation for Servers
Web shells are commonly used after exploiting internet-facing servers. This ASR rule helps reduce the ability to create web shells on servers.
SOC relevance:
- Especially important for Windows servers hosting web applications.
- Can support investigation of suspected web server compromise.
- Useful after exploitation attempts against IIS or other web workloads.
Controlled Folder Access
Controlled Folder Access protects specified folders by preventing untrusted applications from modifying or deleting files. This is commonly associated with ransomware protection.
Important components:
- Protected folders
- Allowed applications
- Audit, block, or off behavior
- Exclusions for trusted apps or paths
SOC relevance:
- Helps limit ransomware impact.
- Requires careful testing to avoid blocking legitimate business applications.
- Allowed app configuration should be tightly controlled.
ASR Exclusions
ASR exclusions allow administrators to exclude certain files, folders, or paths from ASR enforcement. Microsoft supports global ASR exclusions and per-rule exclusions.
Use exclusions carefully.
Good reasons for an exclusion:
- A trusted business application is blocked after testing.
- The app is validated, signed, documented, and required.
- The exclusion is scoped as narrowly as possible.
Bad reasons for an exclusion:
- Users complain before investigation.
- The exclusion is broad, such as an entire user profile or downloads folder.
- The organization wants to bypass testing.
- The exclusion is not documented or reviewed.
ASR Reporting
After ASR policies are assigned and devices sync, events can be reviewed in Defender reporting. Microsoft provides an Attack surface reduction rules report in the Microsoft Defender portal that shows detections, device configuration status, and exclusion management.
For analysts, this reporting helps answer:
- Which ASR rules are firing?
- Which devices are affected?
- Which applications would have been blocked?
- Are there false positives?
- Which rules are safe to move from Audit to Warn or Block?
- Are exclusions being overused?
- Are high-risk behaviors happening repeatedly?
Microsoft Security Operations Context
ASR rules fit into the SOC as both preventive controls and investigation signals.
Triage Workflow
When an ASR-related detection appears, an analyst should determine:
- Which rule fired?
- Was the rule in Audit, Warn, or Block mode?
- Which device was involved?
- Which user was logged in?
- What file, process, script, or parent process triggered the rule?
- Was the activity expected business behavior?
- Did the behavior connect to an email, download, USB device, or remote execution tool?
- Are other devices showing the same behavior?
- Is containment required?
- Should the rule be moved toward enforcement?
Investigation Workflow
A SOC analyst may investigate ASR activity by pivoting through:
- Device timeline
- Advanced Hunting
- File entity page
- User entity page
- Alert evidence
- Process tree
- Email investigation in Defender for Office 365
- Identity signals in Defender for Identity
- Related incidents in Microsoft Defender XDR
- Sentinel incidents if Defender data is connected to Sentinel
Scope and Impact
ASR audit events help determine potential impact before enforcement. For example:
- If only one non-critical app triggers an ASR rule, enforcement may be low risk.
- If hundreds of endpoints trigger a rule because of a business-critical app, the rule needs staged testing or a controlled exclusion.
- If the rule triggers from Office spawning PowerShell on multiple devices, that may indicate phishing or malware activity.
Containment and Remediation
Depending on the finding, response actions may include:
- Isolate the device in Defender for Endpoint.
- Collect an investigation package.
- Quarantine or block a file.
- Submit the file for analysis.
- Disable a compromised account.
- Remove malicious persistence.
- Block indicators.
- Create or tune an ASR policy.
- Add a narrowly scoped exclusion only after validation.
- Escalate to endpoint engineering, identity, email security, or server teams.
Improving Future Detection
ASR audit data can be used to improve security posture by:
- Moving tested rules from Audit to Block.
- Creating exclusions for verified business processes.
- Identifying risky legacy applications.
- Creating Defender XDR hunting queries.
- Creating Sentinel analytics rules if ASR data is ingested.
- Updating incident response playbooks.
- Building dashboards for rule adoption and enforcement.
Exam-Relevant Takeaways
- ASR rules are a Microsoft Defender for Endpoint capability used to reduce risky endpoint behaviors.
- ASR is mainly associated with Windows endpoint protection.
- Use Audit mode before enforcement to understand business impact.
- Use Block mode when you are ready to prevent the behavior.
- Use Warn mode when users should receive a warning before proceeding.
- Use exclusions carefully and narrowly.
- ASR events can be reviewed in Defender reports and Advanced Hunting.
- ASR events appear in the
DeviceEventstable in Microsoft Defender XDR Advanced Hunting. - Controlled Folder Access is related to ransomware protection.
- Standard protection rules are generally safer to enable earlier than more disruptive rules.
- For endpoint behavior prevention, choose Microsoft Defender for Endpoint, not Sentinel.
- For centralized SIEM correlation across many data sources, choose Microsoft Sentinel.
- For policy deployment to managed endpoints, expect Intune endpoint security policies or Defender security settings management.
- For investigation, pivot from rule event to device, user, process, file, and related incident.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| Block Office from launching PowerShell or cmd.exe | Microsoft Defender for Endpoint ASR rule | ASR controls risky endpoint behavior. |
| Test whether a rule would break business apps | ASR Audit mode | Audit mode records what would have happened without blocking users. |
| Prevent ransomware from modifying user documents | Controlled Folder Access | Protects specified folders from untrusted applications. |
| Review which ASR rules are triggering | Microsoft Defender portal ASR rules report | Shows detections, configuration status, and exclusion information. |
| Hunt for ASR events across devices | Microsoft Defender XDR Advanced Hunting | ASR events are available in the DeviceEvents table. |
| Centrally correlate ASR events with firewall, identity, and cloud logs | Microsoft Sentinel | Sentinel is the SIEM/SOAR platform for multi-source correlation. |
| Deploy ASR policy to managed Windows devices | Intune endpoint security policy | Intune can manage endpoint security settings for Defender Antivirus-protected devices. |
| Allow a trusted business app blocked by ASR | ASR exclusion | Exclusions should be narrow, validated, and documented. |
| Investigate credential theft behavior on a device | Defender for Endpoint device timeline and ASR events | LSASS-related ASR rules can help detect or prevent credential theft attempts. |
| Investigate phishing email that led to endpoint execution | Defender for Office 365 + Defender for Endpoint | Email investigation shows delivery; endpoint investigation shows execution behavior. |
| Build a dashboard of ASR activity | Defender reporting or Sentinel workbook | Defender gives native ASR reporting; Sentinel workbooks help if data is ingested into Sentinel. |
| Automatically respond to Sentinel incidents created from endpoint data | Sentinel automation rule or playbook | Automation rules manage incident automation; playbooks run Logic Apps workflows. |
KQL Notes
The transcript does not focus heavily on KQL, but ASR activity can be investigated using Advanced Hunting in Microsoft Defender XDR. Microsoft documents ASR rule events in the DeviceEvents table.
Example: Find ASR Events
DeviceEvents
| where ActionType contains "Asr"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath,
InitiatingProcessFileName, InitiatingProcessCommandLine,
AccountName, ReportId
| order by Timestamp desc
What This Query Does
DeviceEvents
Searches endpoint event data in Microsoft Defender XDR.where ActionType contains "Asr"
Filters for ASR-related events. Exact action names can vary by rule and event type.project
Selects the most useful columns for triage.order by Timestamp desc
Shows the newest activity first.
Example: Summarize ASR Activity by Rule Type
DeviceEvents
| where ActionType contains "Asr"
| summarize EventCount = count(), Devices = dcount(DeviceId) by ActionType
| order by EventCount desc
What This Query Does
This query helps identify which ASR rules are firing most often. It is useful during an audit phase because it can show which rules may need more testing before enforcement.
Example: Identify Devices with Repeated ASR Events
DeviceEvents
| where ActionType contains "Asr"
| summarize EventCount = count() by DeviceName, ActionType
| where EventCount > 10
| order by EventCount desc
Investigation Value
This helps find devices repeatedly triggering the same ASR rule. That could indicate:
- A legitimate app that needs review
- A misconfigured script
- A user repeatedly opening malicious content
- Malware attempting the same behavior multiple times
- A rule that needs phased deployment or exception handling
Common Exam Traps
Trap 1: Confusing Defender for Endpoint with Sentinel
ASR rules are a Defender for Endpoint endpoint protection feature. Microsoft Sentinel can ingest and correlate security data, but Sentinel is not where ASR rules are primarily enforced.
Trap 2: Blocking Everything Immediately
For exam scenarios involving production users, the safest answer is often to deploy ASR rules in Audit mode first, review impact, then move to enforcement.
Trap 3: Confusing Alerts and Incidents
An ASR event may contribute to an alert or incident, but an alert is a detection and an incident is a grouped investigation container. Defender XDR can correlate multiple alerts into incidents.
Trap 4: Using Broad Exclusions
Broad exclusions weaken protection. If an answer choice excludes large paths like C:\Users\*\Downloads, that is usually risky unless the question specifically justifies it.
Trap 5: Forgetting Business Impact
Some ASR rules can affect legitimate admin tools, Office automation, scripts, or legacy applications. Audit mode and pilot groups reduce the risk of production disruption.
Trap 6: Choosing Email Security for Endpoint Behavior
Defender for Office 365 helps with phishing and malicious email investigation, but ASR enforcement happens on the endpoint through Defender for Endpoint.
Trap 7: Assuming macOS and Linux Have the Same ASR Options
ASR rule coverage is strongest on Windows. Other operating systems may support different Defender settings, but not necessarily the same Windows ASR rule set.
Trap 8: Treating Controlled Folder Access as a Backup
Controlled Folder Access can reduce ransomware impact, but it is not a replacement for backup, disaster recovery, or incident response.
Real-World SOC Analyst Notes
Alert Fatigue
ASR audit data can be noisy during rollout. Analysts should avoid treating every audit event as an incident. Instead, look for patterns:
- Same rule across many devices
- Same suspicious parent process
- Office spawning script interpreters
- Repeated LSASS access attempts
- WMI or PsExec behavior outside approved admin systems
- Activity tied to phishing campaigns
False Positives
False positives are common when deploying prevention controls. Some business applications legitimately use scripts, child processes, or automation. The key is to validate before excluding.
A good false positive review should document:
- Device name
- User
- Rule triggered
- Process path
- Command line
- Business justification
- Vendor or application owner
- Risk of allowing the behavior
- Approved exclusion scope
- Change record or ticket reference
Evidence Preservation
Before remediating a suspicious endpoint, collect enough evidence to understand what happened. Useful evidence includes:
- Device timeline
- Process tree
- File hash
- Command line
- User context
- Email source if phishing-related
- Related alerts
- Network connections
- Persistence mechanisms
- Screenshot or export of ASR report details
Escalation Paths
ASR findings may require escalation to different teams:
| Finding | Escalation Team |
|---|---|
| Business app blocked | Endpoint engineering / application owner |
| Office macro malware | Email security and endpoint security |
| LSASS credential theft attempt | Identity / Active Directory / incident response |
| WMI persistence | Endpoint security / IR team |
| Web shell creation | Server / web application / cloud team |
| Ransomware-like behavior | Incident response / infrastructure / backup team |
| Excessive exclusions | Security governance / endpoint architecture |
Automation Safety
Do not automatically isolate devices or disable accounts for every ASR audit event. Automation should consider severity, confidence, rule type, asset criticality, and correlation with other evidence.
Good automation candidates:
- High-confidence ASR block tied to known malware
- Multiple suspicious ASR events on the same device
- ASR event plus Defender alert plus malicious file hash
- ASR event plus risky sign-in or identity alert
Bad automation candidates:
- Single audit event from a known business app
- Activity from a known admin tool during a maintenance window
- Broad response actions without validation
Change Control
Moving ASR rules from Audit to Block should be treated like a production security change. A mature rollout includes:
- Pilot group
- Audit period
- Review of triggered events
- Business app validation
- Exclusion review
- Help desk communication
- Change approval
- Phased deployment
- Post-change monitoring
Cost Considerations
ASR reporting in Defender does not have the same ingestion-cost model as Microsoft Sentinel. However, if Defender data is connected to Sentinel, ingestion and retention choices can affect cost. For SC-200, remember that Sentinel is powerful for correlation and SIEM use cases, but data ingestion volume matters.
Quick Reference Summary
- ASR stands for Attack Surface Reduction.
- ASR rules reduce risky endpoint behaviors attackers commonly abuse.
- ASR is part of Microsoft Defender for Endpoint.
- Use Audit mode to test rule impact before enforcement.
- Use Block mode to prevent behavior.
- Use Warn mode when user warning is appropriate.
- Standard protection rules are generally safer to enable earlier.
- ASR exclusions should be narrow and justified.
- Controlled Folder Access helps protect folders from untrusted app changes.
- ASR events can be reviewed in Defender reports and Advanced Hunting.
- In Advanced Hunting, ASR activity can be investigated in
DeviceEvents. - For endpoint prevention, choose Defender for Endpoint.
- For SIEM correlation and automation across many sources, choose Sentinel.
- For deployment, think Intune endpoint security policy or Defender security settings management.
- For SOC triage, pivot from ASR event to device, user, process, file, and related alerts.
Flashcards
Q: What does ASR stand for?
A: Attack Surface Reduction.
Q: Which Microsoft security product provides ASR rules?
A: Microsoft Defender for Endpoint.
Q: What is the purpose of ASR rules?
A: To reduce risky endpoint behaviors that attackers commonly abuse, such as malicious scripts, Office child processes, credential theft, and ransomware-like activity.
Q: What ASR mode should usually be used before enforcing rules broadly?
A: Audit mode.
Q: What does ASR Audit mode do?
A: It records what would have happened if the rule were enforced, without blocking the activity.
Q: What ASR mode prevents the behavior from occurring?
A: Block mode.
Q: Why should ASR exclusions be used carefully?
A: Exclusions weaken protection and can create bypass paths if they are too broad.
Q: Which ASR-related feature helps protect user folders from ransomware-like modification?
A: Controlled Folder Access.
Q: Where can ASR activity be hunted in Microsoft Defender XDR?
A: In Advanced Hunting, using the DeviceEvents table.
Q: If Office launches PowerShell from a document, which Microsoft feature is most relevant?
A: A Defender for Endpoint ASR rule that blocks Office child process creation.
Q: If you need to correlate ASR events with firewall, identity, and cloud logs, which tool is best?
A: Microsoft Sentinel.
Q: Why are ASR rules important to a SOC analyst?
A: They provide both prevention and investigation signals for endpoint attack techniques.
Q: What is a common risk when enabling ASR Block mode too quickly?
A: Disrupting legitimate business applications, scripts, or administrative tools.
Q: What should an analyst review before moving an ASR rule from Audit to Block?
A: Triggered events, affected devices, process details, business impact, and required exclusions.
Q: What type of attack does blocking LSASS credential theft help prevent?
A: Credential dumping and credential theft from Windows endpoints.
Practice Questions
Question 1:
You are deploying Microsoft Defender for Endpoint ASR rules to a production Windows device group. The security team wants to understand which applications would be affected before blocking any behavior. What should you do first?
A. Configure all ASR rules in Block mode
B. Configure the rules in Audit mode and review the ASR report
C. Disable Defender Antivirus until testing is complete
D. Create broad exclusions for all business application folders
Correct Answer:
B. Configure the rules in Audit mode and review the ASR report
Explanation:
Audit mode allows the organization to see what would have been blocked without disrupting users. This is the safest first step before moving rules to Warn or Block.
Question 2:
A user opens a malicious Word document, and Microsoft Defender detects that Word attempted to launch PowerShell. Which security capability is most directly related to preventing this behavior?
A. Microsoft Sentinel workbook
B. Microsoft Defender for Endpoint Attack Surface Reduction rule
C. Microsoft Entra ID Conditional Access
D. Microsoft Defender for Cloud regulatory compliance dashboard
Correct Answer:
B. Microsoft Defender for Endpoint Attack Surface Reduction rule
Explanation:
ASR rules can block Office applications from creating child processes, which helps stop macro-based malware and phishing payload execution.
Question 3:
You need to investigate ASR rule activity across multiple endpoints using KQL. Which table should you query in Microsoft Defender XDR Advanced Hunting?
A. SigninLogs
B. EmailEvents
C. DeviceEvents
D. SecurityRecommendation
Correct Answer:
C. DeviceEvents
Explanation:
ASR rule events are available in the DeviceEvents table in Microsoft Defender XDR Advanced Hunting.
Question 4:
A business-critical application is blocked by an ASR rule after pilot testing. The application is validated as legitimate. What is the best next step?
A. Disable all ASR rules globally
B. Add a narrowly scoped ASR exclusion for the validated application
C. Remove Defender for Endpoint from the affected devices
D. Move all devices back to Audit mode permanently
Correct Answer:
B. Add a narrowly scoped ASR exclusion for the validated application
Explanation:
A narrowly scoped exclusion preserves the security value of ASR while allowing a verified business process to function.
Question 5:
Your organization wants to correlate ASR events with firewall logs, identity alerts, and cloud activity to create cross-domain incidents. Which Microsoft tool is best suited for this requirement?
A. Microsoft Sentinel
B. Controlled Folder Access
C. Local Group Policy Editor
D. Microsoft Word Trust Center
Correct Answer:
A. Microsoft Sentinel
Explanation:
Microsoft Sentinel is the SIEM/SOAR platform used to correlate data from multiple sources. Defender for Endpoint provides the endpoint ASR telemetry and enforcement, while Sentinel is used for broader correlation and automation.