Application Whitelisting im Vergleich: Richtlinien für Software-Einschränkung (SRP), AppLocker, Windows Defender Application Control

Obwohl mit den Software Restriction Policies (SRP oder auch SAFER) seit XP ein ent­sprechender Mecha­nismus zu den Bordmitteln von Windows gehört, ist das App Whitelisting nicht über­mäßig weit verbreitet.

Der wichtigste Grund dafür dürfte sein, dass viele Unter­nehmen den Aufwand scheuen, der für das Erstellen und Pflegen des benötigten Regel­werks notwendig ist. Lässt man hier nicht die erfor­derliche Sorg­falt walten, dann muss man entweder mit Lücken für Schadcode oder mit dem Blockieren legitimer Anwendungen und Anrufen beim Helpdesk rechnen.

Programmstart aus User-Profil verhindern

Häufig herrscht auch die Vorstellung vor, dass man alle zulässigen Applikationen explizit erfassen und freigeben muss. Für einen soliden Grundschutz reicht es aber schon aus, Anwendungen aus dem Programm- und Windows-Verzeichnis zuzulassen und die Ausführung von Code dort zu verhindern, wo der Benutzer Schreibrechte hat.

Damit blockiert man alle Programme, die der User (unwissentlich) aus dem Internet herunterlädt oder von einem USB-Stick starten möchte. Dagegen läuft alles, was der Administrator installiert hat oder über ein Tool zur Software-Verteilung auf den Rechner gelangt ist. So stellt man sicher, dass der unbedachte Klick auf einen Mail-Anhang nicht gleich böse Folgen hat.

Standardbenutzer als Zielgruppe

Weiter­gehende Erwartungen können die Funktionen für das Whitelisting teilweise gar nicht erfüllen. So ist es fast unmöglich, lokale Admini­stratoren an der Ausführung von nicht autorisierter Software zu hindern, weil sie die Sperre durch Anhalten von Diensten, das Ändern der Registry oder sonstige Umgehungs­strategien durch­brechen können.

Daher setzt ein wirksames Whitelisting voraus, dass Unter­nehmen dem Prinzip des Least Privilege folgen und normalen Benutzern keine admini­strativen Rechte einräumen. Umgekehrt reicht diese Maßnahme alleine als Schutz gegen Malware nicht aus, weil diese auch im Kontext eines Standard­benutzers beträchtlichen Schaden anrichten kann, beispiels­weise durch Verschlüsselung seiner Daten.

Windows-Verzeichnis mit Schlupflöchern

Aber auch ein grund­legender Schutz lässt sich nicht ganz einfach erreichen. So greift das Freischalten von C:\windows und aller seiner Unterver­zeichnisse zu kurz, weil sich darunter auch solche befinden, in denen Standard­benutzer Schreib­rechte besitzen. Außerdem gibt es dort Programme, die normale User nicht brauchen, aber für Angriffe missbraucht werden können, wie etwa cipher.exe.

Andererseits kann es sein, dass legitime Anwendungen aus dem Profil der Benutzer starten müssen, in der Regel eine Folge schlechter Programmierung. Ein Beispiel dafür liefert Microsoft selbst mit Windows Defender Antimalware.

Regeltypen auf Basis verschiedener Kriterien

Wie diese Beispiele zeigen, bedarf es schon einiger Regeln, um Programm- und System­verzeichnisse für das Ausführen von Code zuzulassen und gleichzeitig die Benutzer­profile dafür zu sperren. Die Mechanismen für das Whitelisting stellen dafür verschiedene Regel­typen zur Verfügung.

So erlauben sie das Starten von Anwendungen abhängig vom Hersteller, dem Pfad der Programm­datei oder vom Hashcode für die ausführbare Datei. In einer idealen Welt würde man einfach nur signierte Applikationen ausge­wählter Lieferanten zulassen. Da aber auf absehbare Zeit längst nicht alle Anwendungen signiert sein werden, muss man auch zu anderen Mitteln greifen.

So kann man eine vertrauens­würdige, nicht signierte Anwendung in einem Benutzer­verzeichnis freischalten, indem man davon einen Hashcode erzeugt. Sobald sich aber die Datei etwa durch ein Update auch nur gering­fügig ändert, dann muss man die dazugehörige Regel ebenfalls aktualisieren.

Testen von Regeln im Audit-Modus

Aufgrund möglicher Komplikationen durch versehentlich blockierte Software bieten die meisten Tools für das App Whitelisting einen Audit-Modus an. Er protokolliert alle Ereignisse, bei denen Anwendungen von Regeln betroffen sind.

Auf diese Weise erhält der Administrator einen Überblick darüber, welche Programme ausgeführt werden und welche das Whitelisting dann im Erzwingungs­modus blockieren würde.

Richtlinien für Software-Einschränkung

Bei den Software Restriction Policies (SRP bzw. SAFER) handelt es sich um den ältesten der in Windows enthaltenen Mecha­nismen für das Whitelisting von Anwendungen. Es ist der einzige, der in allen Versionen und Editionen des Betriebs­systems (inklusive Server) enthalten ist. Seit Windows 7 sehen die SRP nur mehr 2 Sicherheits­stufen vor, nämlich Nicht erlaubt und Nicht eingeschränkt (das Ausführen als Standard­benutzer entfällt seitdem).

Neben Regeln basierend auf Zertifikaten, Hashes und Pfaden unterstützt SAFER auch solche auf Basis von Internet-Zonen. Das Feature umfasst kein Set an Basisregeln, die bereits einen Grundschutz bieten würden. Vielmehr obliegt es dem Admin, das gesamte Regel­werk zu entwickeln. Dabei fehlt aber ein Auditmodus, mit dem man die Wirkung von Richt­linien erst beobachten könnte.

Zu den weiteren Ein­schränkungen der SRP gehört, dass es die (vergleichsweise sicheren) Store Apps (.appx) nicht blockieren kann. Außerdem lassen sich keine Regeln getrennt nach Dateitypen wie EXE, Batchdateien oder Scripts definieren, sondern sie gelten immer für alle Arten von Code.

Schließlich lassen sich Regeln für SAFER nicht exportieren oder importieren. Vielmehr werden sie standard­mäßig im GPO-Editor erstellt und in einer .pol-Datei gespeichert, von wo sie in die Registry gelangen.

Viele der genannten Nachteile der SRP beseitigt Stefan Kanthak mit seinem Regelwerk, das als .inf-Datei für die ver­schiedenen Versionen von Windows vorliegt. Die ausführlich kommentierten Einträge lassen sich bei Bedarf anpassen, sie schreiben bei Installation die vorgesehenen Werte direkt in die Registrier­datenbank. Insgesamt stellen sie sicher, dass Standard­benutzer nur Programme von dort ausführen können, wo sie diese nicht selbst speichern dürfen.

Als ergänzende Lektüre empfiehlt sich dieses ausführliche Whitepaper der NSA.

AppLocker

Der mit Windows 7 und Server 2008 eingeführte AppLocker ist eine Weiter­entwicklung der Richtlinien für Software-Einschränkung. Das Feature ist der Enterprise Edition vorbehalten und somit gerade in kleineren Firmen nicht verfügbar, wenn diese mit der Pro Edition arbeiten.

Wie die SRP wird AppLocker über Gruppen­richtlinien verwaltet. Als Verbesserung gegenüber der älteren Technik bringt es ein Set an Standard­regeln mit, die %PROGRAMFILES%\* und alle Verzeichnisse unter %SYSTEMROOT% für nicht-administrative Benutzer zur Ausführung von Programmen freischalten (was angesichts der weiter oben beschriebenen Problematik aber nicht reicht).

Im Unterschied zu den SRP lassen sich jeweils separate Regeln für unter­schiedliche Arten von ausführ­baren Dateien definieren, und zwar für Scripts, Programm­dateien, Appx und Installer. AppLocker kennt mit Ausnahme von Internet-Zonen die gleichen Regeltypen wie SAFER.

Ein weiterer Vorteil von AppLocker gegenüber den SRP ist die Mög­lichkeit, eine Regel bestimmten Benutzern und Gruppen zuzuordnen. Darüber hinaus bietet das Feature einen Audit Mode, in dem man alle Regeln testen kann, bevor man sie produktiv schaltet.

Schließlich kann man Regeln im XML-Format importieren und exportieren. Das macht sich AaronLocker zunutze, das für AppLocker eine ähnliche Aufgabe erfüllt wie Stefan Kanthaks .inf-Dateien für SRP.

Das Tool verfolgt jedoch mit einer Kombination aus PowerShell-Scripts und XML-Dateien einen anderen Ansatz. Dabei erstellt der Admin einen Regelsatz im XML-Format und importiert diesen in den GPO-Editor. Auch AaronLocker bringt zahlreiche Richtlinien mit, die Lücken der Standard­regeln schließen und Umgehungen verhindern.

Windows Defender Application Control

Dabei handelt es sich um den neuesten Mechanismus für das Whitelisting von Anwendungen. Bis Windows 10 1709 und Server 2016 firmierte es zusammen mit der Komponente für Virtualization Based Security (VBS) unter der Bezeichnung Device Guard.

Der VBS-Teil heißt seitdem Exploit Guard, das Whitelisting hört auf Windows Defender Application Control (WDAC). Letzteres lässt es sich aber unab­hängig von der VBS nutzen, allerdings um den Preis geringerer Sicherheit. WDAC kann Code nicht nur im User Mode, sondern auch auf Kernel-Ebene (z.B. Treiber) blockieren.

Im Unterschied zu den beiden älteren Techno­logien orientiert sich Application Control stärker an Microsofts Konzept des Modern Desktop. Die mittels PowerShell generierten Policies lassen sich über Mobile Device Management anwenden, etwa über den Cloud-Service Intune (wobei allerdings eine Verteilung über GPOs ebenso möglich ist). Damit ist es auch unabhängig von den AD Domain Services.

Für das Erstellen von Regeln benötigt man laut Systemanforderungen Windows 10 Pro oder Enterprise bzw. Server ab der Version 2016, anwenden lassen sie sich demnach auf alle Editionen. In der Praxis kann man auf der Pro Edition aber weder Regeln erstellen noch anwenden.

Für die Definition von eigenen Regeln gibt es kein grafisches Werkzeug, sondern nur PowerShell-Cmdlets. Sie erlauben nur ein Whitelisting in engeren Sinn, bei der Anwendungen explizit zugelassen werden. Pfadregeln wie in den beiden anderen Features gibt es beispiels­weise nicht.

Limitiert ist auch das Targeting der Regeln, die sich nur auf Computer und nicht auf Benutzer anwenden lassen. Benötigt man User-spezifische Einschränkungen, dann empfiehlt Microsoft eine parallele Nutzung von AppLocker.

Wie AppLocker unterstützt WDAC einen Audit-Modus, der standard­mäßig beim Erzeugen einer neuen Richtlinie aktiv ist. Sie wird in einer XML-Datei gespeichert, welche erst in ein binäres Format konvertiert werden muss, bevor sie auf die Zielrechner ausgebracht werden kann.

Einen Einstieg in die Konfiguration und auch einen ersten Eindruck von der Komplexität dieser Aufgabe erhält man durch das Script CIDeployment.ps1 von Matthew Graeber.

Gerade kleinere Unternehmen, die diesen Aufwand nicht leisten können, bietet Microsoft mit der Integration des Intelligent Security Graph eine alternative Option. Damit führt WDAC nur Anwendungen aus, die in dieser Cloud-gestützten Datenbank als vertrauenswürdig aufgeführt sind.