Die klassischen Schutzmechanismen für die IT-Infrastruktur von Unternehmen sind auch heute noch regelmäßig aktualisierte Software, ein aktueller Viren- und Spamschutz, eine oder mehrere Firewalls (Stichwort: Netzwerksegmentierung) und Intrusion-Detection- und Prevention-Systeme. Unternehmen, die an jede der Kategorien einen Haken machen können, sind dadurch aber noch nicht automatisch sicher. Denn trotz aller Maßnahmen gibt es immer wieder Nachrichten über Firmen, die Hackern zum Opfer gefallen sind.

Seit Jahren schon prägt Microsoft den Begriff der "Attack Surface Reduction" [1], also dem Verringern der Angriffsoberfläche. Bevor wir uns den konkreten Ratschlägen dazu widmen, ist ein Blick auf die grundlegenden Begriffe und Zusammenhänge sinnvoll. Stellen wir uns die IT-Infrastruktur einer Organisation vor, gibt es bildlich eine Oberfläche dieser (einen) Struktur. Dabei könnte es sich etwa um die über ein Netzwerk nach außen angebotenen Webdienste handeln, wenngleich das bei Weitem noch nicht alle Elemente der Oberfläche sind. Die "Angriffsoberfläche", also das, was im Fokus der Microsoft-Dokumentation steht, ist die Summe der potenziellen Angriffspunkte der in einem IT-Netzwerk enthaltenen Computersysteme, die nicht autorisierte Benutzer ausnutzen könnten. Andere Begriffe für Angriffspunkte wären Sicherheitslücken oder Verwundbarkeiten – hier sind grundsätzlich auch physikalische Zugriffe auf eigentlich geschützte Hardware inbegriffen.

Neben den offensichtlichen Netzwerkkomponenten, darunter jegliche Art von Hardware und die darauf installierte und laufende Firmware, gibt es auch auf der Softwareseite mögliche Angriffspunkte für Hacker. Das müssen nicht zwangsweise Fehler in der Entwicklung der Serversoftware selbst sein. IIS, Apache oder Nginx sowie Mailserver und viele andere Standarddienste bringen heute in den meisten Fällen eine sichere Grundkonfiguration mit. Oft ist es die darauf oder dahinter laufende Software, die in Form von APIs oder vergleichbaren Schnittstellen direkten Zugang zu weiterer Infrastruktur oder Daten anbietet.

Selbst menschliche Schnittstellen können ein relevanter Teil der Angriffsoberfläche sein. Häufig im Fokus der Cyberkriminellen stehen dabei Zugänge zu den Benutzerkonten von Mitarbeitern oder Kunden sowie die darüber erreichbaren Ressourcen innerhalb der Infrastruktur. Natürlich sind schwache, leicht zu erratende oder kompromittierte und bei mehreren Diensten verwendete Passwörter ein ähnlich großes Risiko wie selbstverwaltete Geräte bei BYOD oder die ohne Wissen der IT-Abteilung aufgebaute Schatteninfrastruktur.

Der Angriffsvektor bezieht sich auf die Methode oder die Schritte, die ein Hacker nutzt, um in ein Netzwerk oder System einzudringen, existierende Sicherheitsmaßnahmen zu umgehen und Zugang zu relevanten Ressourcen zu erlangen oder einfach einen irreparablen Schaden anzurichten. Angriffsvektoren können vielfältig sein und auch aus mehreren Einzelschritten bestehen. Das macht sie unter den legitimen Tätigkeiten der Benutzer mitunter schwer zu entdecken. Technisch gesehen sind Angriffsvektoren also eine Mischung aus Phishing-Attacken, Malware in E-Mail-Anhängen, Zero-Day-Exploits von Softwareschwachstellen, Man-in-the-Middle-Angriffen und physischem Zugang zu kritischen Ressourcen.

Die Unterscheidung bildet die Basis für die Entwicklung effektiver Sicherheitsstrategien. Während die Angriffsvektoren also konkrete Methoden darstellen, die Kriminelle nutzen, um Schritt für Schritt Zugang zu einer Ressource zu erhalten, bietet die Angriffsoberfläche eine ganzheitliche Sicht auf alle möglichen Angriffsvektoren und die dafür relevanten Geräte oder Dienste. Dabei lassen sich drei Klassen unterscheiden: unbekannte, bekannte und bösartige Assets.

Unbekannte Assets sind eines der größten Sicherheitsprobleme, das wir auch in vorherigen Ausgaben immer wieder thematisiert haben. Es handelt sich dabei um Schatteninfrastruktur unter individueller und meist ohne umfassendes Fachwissen durchgeführter Verwaltung durch die Mitarbeiter und ohne Kontrolle seitens der IT-Abteilung. Bekannte Assets sind das entsprechende Gegenteil, also durch die IT-Abteilung verwaltete Geräte und Dienste, etwa alle Clientcomputer und Server mit den darauf laufenden Diensten und zugehörigen Abhängigkeiten. Bösartige Assets sind mitunter bekannt, aber außerhalb der direkten Kontrolle der IT-Abteilung. Dabei kann es sich um Schadsoftware-Domains von Domain-Generatoren, von Kriminellen übernommene (Web-)Server oder Mailserver zum Spamversand handeln.

Das Herzstück der Angriffsoberflächenreduzierung auf Firmen-Assets ist Microsoft Defender for Endpoint oder Windows-E5-Lizenzen in einer Umgebung mit Entra-ID und Intune. Tatsächlich können Sie den Defender aber auch auf Linux-Geräten in Ihrer Infrastruktur installieren, dort sind aber mitunter andere Regelsätze als die in den Standarddokumenten empfohlenen sinnvoll.

Die Regeln zur Verringerung der Angriffsoberfläche lassen sich auf Windows Server ab Version 2012 sowie ab Windows 10 aktivieren – das geht übrigens auch ohne Defender-Portal oder Gruppenrichtlinien, sogar auf Heimrechnern, dazu später mehr. Mit den zum Defender gehörenden Tools erstellen Sie unter Zuhilfenahme der von Microsoft bereitgestellten Checklisten die Richtlinien, um die vorhandene Angriffsoberfläche zu reduzieren. So können Sie in der Verwaltung der Endpoint-Security die Regeln in unterschiedlichen Modi aktivieren oder deaktivieren.

Bevor Sie nun aber einfach loslegen und wild Regeln im Unternehmen zuschalten, empfiehlt Microsoft eine sorgfältige Planung und die Durchführung von Tests, sodass die Richtlinien später in Ihrer Infrastruktur keine Probleme verursachen. Dabei sollten Sie sich in der Planungsphase zunächst einen Überblick über die Geschäftsbereiche machen und die für diese Bereiche jeweils sinnvollen Richtlinien identifizieren. Abteilungen mit Softwareentwicklern benötigen vermutlich andere zugelassene Windows-Funktionen als die Buchhaltung.

Dafür müssen Sie auch die genutzten Anwendungen und die Auswirkungen Ihrer geplanten Änderungen darauf im Blick haben. Stellen Sie ein Team zusammen, das während der Umstellungsphase als Ansprechpartner für diesen Geschäftsbereich fungiert, Meldungen zu Problemen auswertet und darauf zeitnah reagieren kann. In großen Firmen besteht ein solches Team aus einem oder mehreren Admins und mindestens einem Analysten Ihres Security Operations Centers. In kleinen Unternehmen wird häufig der Administrator selbst Analysen zu berichteten Problemen und möglichen Bedrohungen durchführen müssen.

Möchten Sie in Ihrer Organisation die Regelsätze für eine sehr große Anzahl an Geräten bereitstellen, sollten Sie, ähnlich wie Sie das bereits bei Windows-Updates machen, Ringe für die schrittweise Bereitstellung definieren. Diese stimmen dabei sinnvollerweise mit denen der Bereitstellung von Windows selbst überein. Beginnen Sie nun mit dem inneren Ring und schalten Sie die dafür ausgewählten Regeln zunächst in den Audit-Modus. Nach einiger Zeit erhalten Sie im Defender-Portal entsprechende Berichte. In einer 30-Tage-Darstellung sehen Sie die Auswirkungen Ihres Regelsatzes und wie viele Ereignisse die einzelnen Regeln verursacht haben.

Arbeiten Sie diese durch, identifizieren Sie Probleme sowie False-Positives und definieren bei Bedarf Ausnahmen für den weiteren Verlauf. Beachten Sie, dass bereits existierende Ausnahmen des Defender auch für die meisten der Regeln zur Verringerung der Angriffsoberfläche gelten. Einmal freigegebene Ordner, Programme oder Prozesse bleiben damit bei der Überwachung außen vor. Dies gilt allerdings nicht für die Regel zur WMI-Persistenz.

In der nächsten Phase verlassen Sie den Audit-Modus und schalten die definierten Regeln scharf. Haben Sie während der Auditierung Regeln identifiziert, die immer wieder Probleme bereiten, sollten Sie für diese möglicherweise nicht den Blockieren-Modus aktivieren, sondern erst einmal über den Warnmodus weitere Daten dazu sammeln. In dem Fall lassen sich Ausnahmereglungen durch die Benutzer setzen. Diese bleiben auf dem lokalen Gerät für 24 Stunden gültig. Es ist kein Problem, zunächst nur die einfachen und offensichtlich problemfreien Regeln zu aktivieren. Beobachten Sie auch in dieser Phase die Meldungen im Defender-Portal und halten Sie Rücksprache mit den betroffenen Mitarbeitern. Dabei sollten Sie auch bedenken, dass ein gemeldetes Ereignis nicht zwingend ein False-Positive sein muss, nur weil ein Benutzer Probleme meldet. Dahinter kann auch ein tatsächlicher Angriff stecken.

Sind Sie mit einem Ring fertig, gehen Sie zum nächsten und führen die Schritte auch für diesen analog aus, bis alle Geräte mit entsprechenden Regelsätzen versorgt sind. Erst dann folgt der operationelle Betrieb. In dieser Phase müssen Sie den Regeln und dem Reporting im Defender weiterhin Aufmerksamkeit schenken. Auch wenn die Regelsätze nach einiger Zeit als etabliert gelten, sollten Sie die Meldungen regelmäßig durchgehen und Ausreißer analysieren. Microsoft empfiehlt, dies täglich zu erledigen. Auch gilt es, die gemachten Ausnahmen regelmäßig zu überprüfen und bei Bedarf wieder zu entfernen. Wenn Sie bei den Auswirkungen für eine Regel unsicher sind, können Sie diese natürlich jederzeit wieder in den Auditierungsmodus zurückstufen. Möchten Sie die gesetzten Regeln überprüfen, bietet sich das Portal der Microsoft Defender Advanced Threat Protection (ATP) unter [2] an. Dort erhalten Sie weitere Informationen zu möglichen Angriffen und auch Skripte oder Code-Snippets, um diese zu simulieren und den Effekt auf die Angriffsoberflächen Ihrer Systeme zu ermitteln.

Natürlich ist es wichtig, die Regeln zur Verringerung der Angriffsoberfläche zu kennen und diese für den eigenen Zweck zu hinterfragen. Eine Übersicht der aktuell 19 Regeln finden Sie in der Tabelle. Es sind sehr wahrscheinlich nicht alle vorhandenen Regeln immer und für jede Infrastruktur oder jede Situation sinnvoll. Microsoft listet selbst nur drei Regeln als Standardschutzregeln oder Grundregeln auf, die Admins ohne weitere Analyse aktivieren sollten.

Diese betreffen das Blockieren des Diebstahls von Anmeldeinformationen aus dem lokalen Windows-Sicherheitsautoritätssubsystem (lsass.exe), das Blockieren des Missbrauchs gefährdeter signierter Treiber sowie Verhindern von Persistenzmechanismen über das Ereignisabonnement der Windows Management Instrumentation (WMI).

Letzteres ist vor allem eine von Malware genutzte Möglichkeit, um sich mittels WMI-Repository zu verbergen und immer wieder auf dem Zielsystem mit ausgeführt zu werden. Die erste der drei Regeln zur Sicherung der Anmeldeinformationen kann übrigens zahlreiche Logeinträge hervorrufen, da mitunter auch legitime Apps auf diese Art von Nutzerdaten zugreifen.

Die Regeln lassen sich grob in fünf unterschiedliche Kategorien einteilen:

1. Schutz gegen Exploits und ausnutzbare Schwachstellen,

2. Verhindern der Malware-Verbreitung durch E-Mail und Web

3. Einschränkungen für Office-Anwendungen, die die Ausführung von Schadcode verhindern,

4. Maßnahmen gegen den Diebstahl von Anmeldeinformationen und

5. das Blockieren der Ausführung von unsignierten oder nicht vertrauenswürdigen Prozessen.

Einige der Regeln greifen im Hintergrund auf Analyseergebnisse von Microsoft oder anderen Anbietern zurück. Das Erkennen gefährdeter signierter Treiber etwa prüft bereits bei deren Herunterladen, ob diese an einer anderen Stelle als gefährlich erkannt wurden. Ist das der Fall, wird der Download verhindert. Läuft ein solcher Treiber aber bereits auf einem System, bleibt dessen Ausführung weiterhin möglich. Und da es sich um signierte Treiber handelt, greifen dann auch keine anderen Schutzmechanismen. Möchten Sie einen Treiber vor dem Einsatz noch einmal explizit prüfen lassen, können Sie ihn über ein Formular [3] zur Analyse an Microsoft senden.

Viele der Regeln betreffen den Einsatz von Microsoft Office und daraus erstellte Dateien oder Prozesse. Immer wieder dient die Software Kriminellen als Einfallstor für Schadsoftware. So verhindern Sie etwa über eine Regel, dass Office-Anwendungen ausführbare Inhalte erstellen und so Malware aus dem Office-Kontext ausbrechen und das System infizieren kann. Eine weitere Office-Regel verhindert, dass alle Office-Anwendungen untergeordnete Prozesse erstellen. Das bedeutet konkret, dass sich etwa über VBA-Makros keine Prozesse starten lassen. Dies stoppt Schadsoftware, die als Dropper weiteren maßgeschneiderten Code aus dem Internet nachlädt und diesen ausführen möchte.

Auch die Regel zum erweiterten Schutz vor Ransomware greift auf Erkenntnisse aus der Microsoft-Cloud beziehungsweise dem Microsoft Antimalware Protection Service (MAPS) zurück. Um sie zu aktivieren, muss der Cloudschutz in Defender aktiv sein. Dateien, die online als unschädlich erkannt wurden, eine gültige Signatur besitzen oder derart weit verbreitet sind, dass sie keine Ransomware sein können, werden durch diese Regel nicht blockiert.

Ein weiterer Angriffspunkt für Malware lässt sich mit der Regel zum Blockieren von nicht vertrauenswürdigen und nicht signierten Prozessen, die über USB ausgeführt werden, schließen. So verhindern Sie, dass ausführbare Dateien – das sind etwa Files mit der Endung EXE, DLL oder SCR – von USB-Datenträgern auf einem Gerät starten. Das umfasst auch Dateien, die Nutzer von einem angeschlossenen USB-Datenträger auf die Festplatte des Geräts kopiert haben. Die Vorgabe ist also nicht so leicht zu umgehen, wie im ersten Moment zu vermuten wäre.

Im Normalfall dürften Sie die grafische Konfiguration der Regelsätze im Defender-Portal verwenden. Hier liegen die Regeln und Auswertungen direkt nebeneinander vor und über die erweiterte Suche lassen sich schnell relevante Probleme ausfindig machen. Steht das Portal nicht zur Verfügung, lassen sich die Regeln über die PowerShell aktivieren und deaktivieren. Dabei müssen Sie jedoch die jeweiligen GUIDs nutzen, die Sie in der Tabelle aufgelistet vorfinden. Zum Aktivieren einer Regel öffnen Sie die PowerShell im Administratormodus. Möchten Sie nun etwa die Regel zum Blockieren "ausführbarer Inhalte vom E-Mail-Client und Webmail" in den Audit-Modus setzen, führen Sie das folgende Cmdlet aus:

Statt des Audit-Modus können Sie mit "Warn" oder "Block" als Argument die jeweils anderen Varianten aktivieren. Um eine Regel auszuschalten, verwenden Sie das Argument "Disable". Möchten Sie mit der PowerShell Ausnahmen für Ordner, Dateien oder Prozesse aktivieren, bietet sich das folgende Cmdlet an:

Um Ihre Aktionen für alle vorhandenen Regeln auszuführen, können Sie sich ein kleines Skript schreiben, das mit (Get-MpPreference).AttackSurfaceReductionRules_Ids zunächst die existierenden GUIDs abfragt und diese Liste dann durchläuft. Wenn Sie keine Möglichkeit haben, die ASR-Regeln per Gruppenrichtlinien zu setzen und Ihnen die Konfiguration über die PowerShell zu umständlich ist, bieten sich zwei kostenlose Tools an.

Da wären das installationsfreie "ConfigureDefender" [4] von Andrzej Pluta sowie "DefenderUI" [5] von Voodooshield. Beide erlauben das Setzen aller ASR-Regeln in einem übersichtlichen Interface. Zudem können Nutzer die Eigenschaften von Microsoft Defender selbst anpassen – etwa wie sensibel der Scanner auf verdächtige Files reagieren soll, wie lange Defender auf eine Rückmeldung aus der Microsoft-Cloud wartet, bevor er eine Datei durchwinkt, oder auch, welchen Prozessoranteil der Mal- wareschutz für sich beanspruchen darf.

Praktisch: Beide Tools kommen mit verschiedenen, vordefinierten Sicherheitsstufen daher, die die Nutzer bei Bedarf mit einem Mausklick aktivieren können – hierzu zählt beispielsweise eine empfohlene Einstellung ("High" bei ConfigureDefender beziehungsweise "Recommended" bei DefenderUI), eine interaktive Stufe mit häufigeren Rückfragen sowie ein maximales Sicherheitslevel, das im Prinzip alle Regeln scharf schaltet. Sollten Sie sich dabei verkonfigurieren und nicht wissen, welche Einstellung plötzlich Probleme bereitet, ermöglichen beide Programme das Zurücksetzen auf die Windows-Default-Einstellungen ebenfalls per Mausklick. All die in der GUI getätigten Einstellungen lassen sich im Übrigen auch per PowerShell mit dem Cmdlet Set-MpPreference setzen und mit dessen "Get-"Pendant abfragen.

Windows bietet sicherheitstechnisch mehr, als auf den ersten Blick zu sehen ist. Unter der Haube stehen etliche Regeln bereit, die die Angriffsoberfläche verringern. In diesem Beitrag haben wir Ihnen die grundlegenden Aspekte einer Attack Surface Reduction vorgestellt. Die 19 Regeln mögen eher überschaubar wirken, adressieren aber gerne verwendete Einfallstore.

Deshalb sollten Sie deren Nutzung zum Schutz Ihrer Infrastruktur in Erwägung ziehen. Hinzu kommt, dass es sich dabei um Bordmittel handelt und nicht um Drittanbieter-Code. Im Normalfall dürften die Mitarbeiter keine oder nur kaum Einschränkungen in ihrer täglichen Arbeit spüren, während Sie so manches Schlupfloch für Angreifer schließen.