In vielen Tenants, die ich mir anschaue, gehören ASR-Regeln (Attack Surface Reduction Rules) zu den wirksamsten Schutzmaßnahmen – und zugleich zu den am häufigsten missverstandenen. Meist erlebe ich eines von zwei Extremen: Entweder werden sie komplett ignoriert, oder jemand schaltet sie im Hauruckverfahren alle auf einmal ein. Das geht nicht selten zulasten von Fachanwendungen und der Produktivität der Benutzer. Besser fährt, wer differenziert vorgeht, also die wichtigsten ASR-Regeln gezielt aktiviert, Block- und Audit-Modus sinnvoll kombiniert und vor allem die Auswirkungen und Events sauber auswertet.

Einige ASR-Regeln gehören laut Microsoft sofort in den Block-Modus

Microsoft benennt klar, welche ASR-Regeln sofort im Block-Modus laufen sollten, um die Angriffsfläche deutlich zu verkleinern (Standard Protection). Besonders wichtig sind diese:

  • Blockieren, dass Office-Apps Kindprozesse erzeugen
  • Blockieren des Diebstahls von Anmeldeinformationen aus LSASS
  • Blockieren von ausführbaren Inhalten aus E-Mail und Webmail
  • Blockieren des Missbrauchs bekannter, ausgenutzter, aber signierter Treiber
  • Blockieren von Prozessstarts durch PSExec und WMI

Diese Regeln setzen genau bei den Taktiken an, auf die Angreifer nach dem Erstzugriff am häufigsten zurückgreifen. Makros aus Phishing-Mails, die Kindprozesse starten, oder ausgelesene Passwort-Hashes aus LSASS sind in echten Angriffen alles andere als selten. Auch in aktuellen Projekten sehe ich regelmäßig, dass Angreifer genau diese Wege gehen, sobald entsprechende Schutzmaßnahmen fehlen.

Beim Rollout per Intune kommt es auf Audit-Phase und Dokumentation an

Mit den Endpoint-Sicherheitsrichtlinien in Intune (Anleitung) lassen sich ASR-Regeln granular steuern. Praktisch ist, dass man einzelne Regeln zunächst nur im Audit-Modus betreiben und ihre Auswirkungen beobachten kann. Nach meiner Erfahrung stören selbst Standardregeln in manchen Umgebungen Legacy-Anwendungen oder Admin-Tools. Ich empfehle deshalb, den Block-Modus nur für Regeln einzusetzen, bei denen sich unerwartete Nebenwirkungen ausschließen lassen; alle anderen starten erst einmal im Audit-Modus. Wichtig ist außerdem, die Richtlinien klar zu dokumentieren und jede Ausnahme nachvollziehbar zu halten.

Mein Tipp: Im Audit-Modus lassen sich ASR-Events per KQL oder direkt im Reporting des Defender-Portals gut nachverfolgen, bevor man auf den Block-Modus umstellt. Das erspart einem böse Überraschungen.

KQL und der ASR-Report zeigen, was die Regeln im Audit-Modus auslösen

Gerade wenn neue Regeln ausgerollt werden, lohnt sich ein genauer Blick auf die Audit-Events. Im Defender-Portal gibt es unter „Reports > ASR rules“ eine Übersicht der ausgelösten Events, die sich nach Regel, Gerät und Aktion filtern lässt. Will ich tiefer einsteigen, greife ich meist zu Advanced-Hunting-Abfragen in Microsoft Defender:

DeviceEvents
| where ActionType startswith "Asr"
| project Timestamp, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessFileName, ReportId

Die Abfrage filtert alle ASR-bezogenen Events heraus, sodass man sie gezielt auf Auffälligkeiten prüfen kann. Vor allem erkennt man so frühzeitig, welche Anwendungen oder Skripte von einer bestimmten Regel betroffen wären, bevor die Blockierung scharfgeschaltet wird. Weitere Details zu den einzelnen Regeln und Deployment-Strategien finden sich bei Microsoft.

Jede Ausnahme muss so eng wie möglich gefasst sein

Nicht jeder Regelkonflikt lässt sich lösen, indem man die Anwendung anpasst. Für solche Fälle kann man in Intune pro ASR-Regel Ausnahmen für bestimmte Dateien oder Ordner festlegen. Damit sollte man äußerst sparsam umgehen und möglichst explizit arbeiten, sonst leidet die Schutzwirkung. Praktisch bedeutet das, Ausnahmen so eng wie möglich auf die betroffenen Pfade oder Hashes zu beschränken und regelmäßig zu prüfen, ob sie noch gebraucht werden. Breite Ausnahmen wie „C:\Programme“ sind für mich tabu.

Reporting und Advanced Hunting setzen die passende Lizenz voraus

Für Verwirrung sorgt immer wieder die Lizenzfrage. Die vollständige Auswertung und das Advanced Hunting der ASR-Events funktionieren nur mit Microsoft Defender for Endpoint P2 oder Microsoft 365 E5. Fehlen diese Lizenzen, bleiben viele wertvolle Telemetriedaten verborgen, was sich besonders bei der tiefergehenden Analyse und der Korrelation von Events bemerkbar macht. Wer nur Defender Antivirus ohne die Komponente Defender for Endpoint einsetzt, kann ASR-Regeln zwar technisch aktivieren, muss beim Reporting und Hunting aber deutliche Abstriche hinnehmen.

Ich setze auf konsequentes Blockieren, behalte dabei aber die Kontrolle

Grundsätzlich halte ich viel davon, die von Microsoft empfohlenen ASR-Regeln möglichst schnell in den Block-Modus zu bringen. Ein pauschales „Enable all“ funktioniert in der Praxis allerdings selten. Zuerst sollte man sich einen Überblick über bestehende Ausnahmen und Anwendungen verschaffen, dann mit den Audit-Daten arbeiten und erst im zweiten Schritt in den Block-Modus wechseln. Wer dabei sauber dokumentiert und nachvollziehbar vorgeht, verkleinert die Angriffsfläche im Tenant dauerhaft, ohne die Anwender zu frustrieren. Meine Erfahrungen mit Themen wie Tenant-Readiness oder Conditional Access habe ich in den Beiträgen zu Copilot für Microsoft 365 und zu Best Practices für Conditional Access beschrieben.

Man sollte dabei nie vergessen, dass jede angelegte Ausnahme zu einem neuen Einfallstor werden kann. ASR-Regeln lösen nicht jedes Sicherheitsproblem, als Baustein einer durchdachten Endpoint-Strategie sind sie aber unverzichtbar.

Bevor man auf den Block-Modus umstellt, hilft es, das Zusammenspiel von Richtlinienkonfiguration, Event-Auswertung und Ausnahmen grafisch darzustellen. Das folgende Diagramm zeigt, wie die wichtigsten Komponenten ineinandergreifen:

flowchart TD
    Policy["ASR-Policy in Intune"] --> Device["Windows-Gerät"]
    Device --> AuditEvent["Audit-Event (Defender for Endpoint)"]
    Device --> BlockAction["Block-Event (Defender for Endpoint)"]
    AuditEvent --> Report["ASR-Report Portal"]
    BlockAction --> Report
    Policy --> Exception["Ausnahme (Dateipfad/Hash)"]
    Exception -.-> Device

Abbildung: Zusammenspiel von ASR-Richtlinien, Ausnahmen und Reporting