Best Practices zur ASR-Konfiguration für verschiedene Szenarien
In diesem Blogbeitrag erfahren Sie, wie Attack Surface Reduction Rules über Intune konfiguriert werden. Es gibt mehrere Optionen zur Konfiguration von ASR Rules. Ich zeige auf, wie sich die integrierten Methoden gegenüber der benutzerdefinierten Option unterscheiden und warum sich nur eine Option für ein Enterprise Szenario eignet. Der Beitrag bietet Unternehmen, die Microsoft Intune aktiv als Device Management einsetzen und deren Verantwortlichen für die Sicherheit der Endgeräte, zum Beispiel einem CISO oder einem Microsoft365 Security Administrator, eine gute Übersicht.
Was sind Attack Surface Reduction Rules?
Attack Surfaces (Angriffsflächen) sind alle Stellen, an denen ein Unternehmen für Cyber-Bedrohungen und Angriffe anfällig ist. Ein Angreifer könnte beispielweise Endgeräte oder Netzwerke eines Unternehmens kompromittieren. Um das Risiko zu minimieren, dass ein Endgerät durch einen Angreifer kompromittiert werden kann, müssen Sicherheitsmassnahmen implementiert werden. In Intune können hierzu die Attack Surface Reduction Rules angewendet werden.
Bei den Attack Surface Reduction Rules handelt es sich demnach um Einstellungen, die das Windows Endgerät besser vor Angriffen und ungewöhnlichem Verhalten schützen (z.B. vor potenziell verschleierten Skripten oder dem Diebstahl von Anmeldeinformationen durch das Local Security Authority Subsystem [LSASS] von Windows).
Ausgangslage und Herausforderung
Wir stellen fest, dass die ASR in den meisten Tenants nicht konfiguriert sind. Dadurch erhöht sich das Risiko eines erfolgreichen Angriffes auf ein Device. Bei einem erfolgreichen Angriff können Endgeräte kompromittiert werden und das Schadenspotenzial ist hoch.
Als mögliche Hürde zur Konfiguration der ASR sehe ich die hohe Komplexität des Themas, der Überschneidung von möglichen Sicherheitseinstellungen in Intune und im Defender und der damit verbundenen Aufgabe, dass zur korrekten Einführung ein konzeptioneller Aufwand und tiefe Kenntnisse notwendig sind.
ASR Rules Konfigurations-Optionen
Nachstehend aufgeführt, stehen uns für die Konfiguration der ASR Rules folgende 5 Optionen zur Verfügung:
1. Configuration Profiles | Endpoint protection
Das Konfigurationsprofil “Endpoint Protection” kann verwendet werden, um die Sicherheit von Windows-Geräten zu kontrollieren.
Die Kategorie Microsoft Defender Exploit Guard beinhaltet eine Gruppe zur Attack Surface Reduction und enthält fast alle derzeit verfügbaren ASR-Rules.
2. Endpoint security | Security baselines
Security-Baselines sind von Microsoft empfohlene Konfigurationseinstellungen. Diese Einstellungen basieren auf dem Feedback der Microsoft security engineering teams, Produktgruppen sowie Partner und Kunden von Microsoft. Eine Security-Baseline umfasst eine Gruppe von Microsoft Defender Einstellungen.
Die Security-Baseline enthält fast alle derzeit verfügbaren ASR-Rules.
3. Endpoint security | Attack surface reduction
Das Profil Attack Surface Reduction rules kann ebenfalls zur Konfiguration der Attack Surface Reduction Rules verwendet werden. Diese ist im Vergleich zu den restlichen Optionen am einfachsten zu konfiguieren und wird daher auch in meisten Fällen für SMB-Umgebungen verwendet. Sie enthält fast alle derzeit verfügbaren ASR- Rules.
4. PowerShell Script
PowerShell ist eine plattformübergreifende Lösung zur Aufgabenautomatisierung, die aus einer Befehlszeilen-Shell, einer Skriptsprache und einem Konfigurationsmanagement-Framework besteht. PowerShell Script kann verwendet werden, um alle verfügbaren ASR- Rules festzulegen.
5. Configuration Profiles | Custom
Ein benutzerdefiniertes Konfigurationsprofil kann verwendet werden, um Einstellungen zu konfigurieren, die im Configuration Service Provider (CSP) verfügbar sind.
CSP enthält alle ASR-Rules. ASR-Rules und Ausschlüsse müssen über benutzerdefinierte OMA-URI’s festgelegt werden.
Welche ASR Rule Option für welches Szenario?
“Built-in” ASR Rules Profile
Alle “Built-in” Profile haben die Gemeinsamtkeit, dass nur fast alle derzeit verfügbaren ASR Rules zur Verfügung stehen. In den meisten Fällen reichen diese Optionen vollkommen aus. Microsoft empfiehlt zwar die Konfiguration über Security Baselines, jedoch in einem Best Pratice Ansatz empfehle ich die Konfiguration über die Option Endpoint Security | Attack Surface Reduction. Diese Empfehlung gilt insbesondere im KMU-/SME-Umfeld, wo diese Möglichkeit einen guten Schutz und eine entsprechende Risiko-Miminierung bietet.
An dieser Stelle wäre es nun extrem lässig beschreiben zu können, dass mit Microsoft 365 Defender ein “vereinfachter” Konfigurationsassistent für ASR-Rules zu Verfügung steht. Aber leider ist dem nicht so, zumindest noch nicht. Wenn man sich die bisherige Microsoft-Vorgehensweise der Step-by-Step-Implentierung von Microsoft Security Features in dem Defender betrachtet, kann man davon ausgehen, dass irgendwann auch ASR-Rules im Defender Portal auftauchen, und zwar unter Endpoints | Device Configuration, wo derzeit Protection Policies der nächsten Generation und Firewall-Einstellungen beheimatet sind.
Im Moment müssen wir jedoch noch über Microsoft Endpoint Manager zugreifen und hier die notwendigen Schritte durchgehen, die zur Erstellung einer Attack Surface Reduction Policy mit ASR Rules erforderlich sind:
Verhinderung von Profilkonflikten
Dies ist die einfachste Option, ASR Rules zu konfigurieren. Es ist zu beachten, dass wenn Einstellungen für ASR-Rules modifiziert werden, diese Einstellungen im Security-Baseline Profil oder im Konfigurationsprofil “Endpoint protection” analog zu den modifizierten Einstellungen auf “not configured” gesetzt werden, somit wird verhindert, dass es zu Profilkonflikten kommt.
Die Built-in Attack Surface Reduction Profiles decken leider nicht alle ASR-Rules ab. Daher müssen jeweils die fehlenden Rules über eine andere Methode definiert werden. Was hierbei sehr umständlich erscheint ist, dass man die fehlenden ASR Rules nicht einfach über eine OMA-URI (Open Mobile Alliance Uniform Resource Identifier) setzen kann, weil sie sich dadurch gegenseitig aufheben würden. Die fehlende ASR Rule wird durch einen PowerShell-Befehl gesetzt. Wie im naschstehenden Abschnitt “Custom Profile Option” beschrieben, hat dies jedoch einen Nachteil hinsichtlich des Managements von ASR-Rules, die mittels PowerShell definiert wurden.
Custom Profile Option
Wie zuvor bereits ausgeführt, gibt es je nach Anforderungen und Präferenzen der Organisation mehrere Methoden für die Bereitstellung. In einem Enterprise-Szenario empfehle ich jedoch das benutzerdefinierte Konfigurationsprofil zu verwenden. Hierbei können alle derzeit zur Verfügung stehende ASR Rules mittels OMI-URI’s in einem Profil zusammengefasst werden. Somit sind alle ASR-Rules in einer einzigen Konfiguration enthalten. Zwar sind diese etwas schwieriger einzurichten und zu verstehen, aber mit dieser Methode können alle ASR Rules konfiguriert werden.
Deployment Phasen
Wie bei jeder neuen, gross angelegten Implementierung, die sich möglicherweise auf alle Geschäftsabläufe auswirken könnte, ist es wichtig, bei der Planung und Implementierung methodisch vorzugehen. Damit der produktive Betrieb während der Deployment-Phase aufgrund einer fehlerhaft erstellten ASR Rule Policy oder wegen False-Positive Effekten nicht unnötig unterbochen wird, sollten die Einstellungen zunächst stets auf “Audit” gesetzt werden (siehe Bereitstellungs-Phase 2).
Aufgrund der leistungsstarken Funktionen von ASR-Regeln zur Verhinderung von Gerätesystem-Kompromitierung ist eine sorgfältige Planung und Implementierung der ASR Rules erforderlich. Um sicherzustellen, dass die individuellen betrieblichen Arbeitsprozesse nicht gestört werden und ASR Rules optimal funktionieren, müssen ASR-Rules vor der Inbetriebnahme sorgfältig geplant, getestet und implementiert werden.
Microsoft empfhielt die Anwendung des Step-by-Step Bereitstellungs-Plans.
ASR Rules Monitoring
Das Monitoring von ASR Rules wird durch das Defender Threat & Vulnerability Management (TVM) bereitgestellt und bildet somit eine Möglichkeit für das Monitoring von ASR-Rules. TVM verwendet Geräte-Telemetriedaten, um festzustellen, ob die Aktivierung der betreffenden Rule Auswirkungen auf die Benutzer hat. Hinweis: Damit dies funktioniert, müssen die Geräte in die Microsoft 365 Defender Suite eingebunden und der Echtzeitschutz muss aktiviert sein. Zudem kann es eine gewisse Zeit dauern, bis die Telemetriedaten erfasst und angezeigt werden.
Ein weitere Möglichkeit für das Monitoring von ASR Rules sind die Search und Reporting Features von M365 Defender, welche jedoch nur bei zugewiesenen Microsoft 365 E5 Lizenzen zur Verfügung steht. Diese Funktion ermöglicht es, leichter zu erkennen, welche Ausnahmen für die Geräte gemacht werden können, die laut TVM “erwartete Auswirkungen auf den Nutzer” haben.
Schlussfolgerung
Die ASR-Rules sind nur ein Teil der Funktionen von Attack Surface Reduction, die in Microsoft 365 Defender enthalten sind.
Sie sind für die grosse Mehrheit der Unternehmen ein geeigneter Einstieg zur Absicherung von Windows Endpoints.
Für Unternehmen mit spezifischen Anforderungen können auch noch weitere ASR-Strategien wie z.B. Device Control, Application Guard, Application Control, etc. von grossem und wichtigem Nutzen sein, doch kann fast jede Intune-Infrastruktur von der Umsetzung der ASR-Regeln sehr schnell profitieren.
Die Anforderungen sind dabei einerseits von der Grösse eines Unternehmens abhängig. Wichtig in der Betrachtung sind andererseits auch branchenspezifische regulatorische Auflagen, Anforderungen aus ISO-Zertifizierungen oder Vorschriften der internen Compliance.
