Die 10 größten Vorurteile gegen Application Whitelisting

Application Whitelisting ist nichts Neues. Wie der Name schon andeutet ist Whitelisting der umgekehrte Ansatz zu Blacklisting. Blacklisting als Begriff ist weniger geläufig als die Produktgattung die sich auf dieses Prinzip stützt – Virenscanner.

Das Whitelisting von Anwendungen geht den umgekehrten Weg und verweigert standardmäßig die Ausführung von Anwendungen, die nicht explizit als "bekannt und vertrauenswürdig" auf der Whitelist bekannt sind. Dieser "Default Deny"-Ansatz bietet aus vielen Gründen ein wesentlich höheres Schutzniveau als der etablierte Blacklisting-Ansatz für Antivirus Produkte.
Hauptgrund für den Einsatz von Application Whitelisting (im folgenden nur noch als AWL abgekürzt) aber ist und bleibt, dass bösartiger Code, der noch nie zuvor gesehen wurde, verhindert werden kann. So genannte "Zero-Day"-Angriffe. Ein Virenscanner der eine Blacklist bereits bekannter Schädlinge oder Verhaltensweisen führt, kann diese neuen Schädlinge nicht identifizieren.

Jeder vernunftbegabte Mensch fragt sich jetzt: Wenn Whitelisting so viel sicherer ist als Blacklisting, warum ist es dann nicht so weit verbreitet wie Blacklisting-Lösungen, also Virenscanner?

Die Antwort ist einfach. Eine Blacklisting-Lösung lässt zwar Schadcode ungehindert ins Netzwerk wenn sie einen schlechten Job macht, aber blockiert niemals gutartigen, unbekannten Code. Beispielsweise Teile des Betriebssystems. Wenn ein Whitelisting Produkt einen schlechten Job macht, sind die Systeme vielleicht extrem sicher, aber es wird die Nutzbarkeit des Systems beeinträchtigen, indem es unbekannten aber vertrauenswürdigen Code blockiert. Die meisten Menschen haben daher die einfache Handhabung von Blacklisting gegenüber der unumstritten besseren Sicherheit von Whitelisting bevorzugt.

Ein weiterer Grund, warum AWL nicht sehr verbreitet ist, sind frühe AWL-Lösungen aus den 90er Jahren. Diese waren wie beschrieben oft eher ein Hindernis im Alltag und haben dem Prinzip Whitelisting einen bis heute schlechten Ruf eingebracht. Moderne AWL-Lösungen werden daher bis heute an der schlechten Leistung der Lösungen aus dem letzten Jahrtausend gemessen. Moderne Whitelisting Lösungen können aber wesentlich automatisierter operieren und verursachen im Alltag heute weder ungewollt blockierte Software noch den oft gefürchteten Mehraufwand. Dieser Artikel soll diese und andere Vorurteile sowie Missverständnisse widerlegen, die selbst von Sicherheitsexperten immer noch gegen die Technik vorgebracht werden. Beim Blacklisting wird jede neue Datei auf einem System überprüft. Erkennt der Virenscanner eine Datei als schädlich, wird die Ausführung verhindert.

Vorurteil Nummer 1:

Whitelisting Produkte von Drittanbietern sind überflüssig, da die Technik bereits in modernen Betriebssystemen kostenlos integriert ist.

Der wohl bekannteste integrierte Whitelisting Service ist der AppLocker von Microsoft. Mit einer Windows Server Lizenz können Sie auch stolzer Besitzer einer Application Whitelisting Lösung werden. Wenn Sie also keine andere "Default-Deny" Technik nutzen, die Teil Ihres Sicherheitskonzepts ist, dann können Sie dieses Tool in Betracht ziehen, um die Lücken zu schließen, die Virenscanner konzeptbedingt hinterlassen. Die Verwendung integrierter Lösungen ist aus Sicht des Gesamtkonzepts viel sinnvoller als diese Angebote einfach zu ignorieren.

Das Problem ist jedoch, dass diese Lösungen nur schwer zu handhaben und aktuell zu halten sind. Die Verwaltung dieser Tools erfordern oft, dass der IT-Administrator alle Programme identifiziert, die erlaubt sein sollten. Auf einem Standard Betriebssystem sind das Tausende von Dateien. Änderungen und Ergänzungen der Whitelist brauchen Zeit und sind nicht direkt verfügbar. Die manuelle Verwaltung der Liste von erwünschten und vertrauenswürdigen Anwendungen, kann eine Belastung darstellen, die den Zugewinn an Sicherheit obsolet macht. Kritiker von AWL führen diese Mankos integrierter Whitelisting Tools oft als Grund an, keine AWL-Lösungen zu verwenden.

Die Frage aber bleibt: Wenn moderne AWL Lösungen so viel besser sind, warum ignoriert die überwiegende Mehrheit der IT-Administratoren und Sicherheitsexperte sie und verwendet nur Blacklisting zur Absicherung der Systeme? 

Vorurteil Nummer 2:

Application Whitelisting ist kompliziert zu handhaben und zu zeitaufwändig

Zugegeben bei tausenden von Anwendungen für einen einzigen PC klingt das nachvollziehbar. ständig ändern Updates einzelne Anwendungen oder das gesamte Betriebssystem wird gepatcht. Genau das ist eines der Kernprobleme, die moderne AWL-Lösungen schon längst gelöst haben. Denn so aufwändig es klingt, es ist ein sehr gut lösbares Problem. Moderne AWL-Produkte sind sehr geschickt darin, die relevanten Daten auf einem System zu identifizieren, Änderungen automatisch zu genehmigen und die Whitelist-Datenbank entsprechend aktuell zu halten. In einer ordentlichen AWL-Lösung ist es selten nötig einzelne Dateien der Whitelist manuell hinzuzufügen oder gar zu löschen. Änderungen, wie z.B. das Installieren eines neuen Softwarepakets bringen diese Lösungen nicht mehr dazu alles als unbekannt zu blockieren. Moderne AWL-Lösung macht das Management der Whitelist so automatisch und zeitsparend wie möglich.

Vorurteil Nummer 3:

Application Whitelisting setzt jeden Nutzer der Gnade der Administratoren aus.

Einige AWL-Lösungen folgen dem Ansatz, dass alle Entscheidungen über das, was erlaubt oder verweigert werden soll, ausschließlich in den Händen von IT-Administratoren oder Sicherheitsexperten liegen. Jedoch ist das nur in sehr statischen Umgebungen oder für PCs mit festem Anwendungsumfang überhaupt umsetzbar.

Die meisten Whitelisting Produkte ermöglichen heute, dass Aktionen die ein Nutzer ausführt sich auch mit AWL vereinbaren lassen. Dabei wird nicht dem Nutzer vertraut, sondern sogenannten Reputationsservices. Führt ein Nutzer also eine unbekanntes Programm aus, so blockiert die Whitelist die Ausführung nicht direkt, sondern versucht anhand von Informationen z.B. aus der Cloud, zu erkennen ob diese Anwendung tatsächlich schon als schädlich oder gutartig bekannt ist. In den meisten Fällen können nämlich für neue Anwendungen automatisch Freigaben erteilt werden, ohne dass der Nutzer dies mitbekommt oder in seiner Arbeit gehindert wird. Sind keine entsprechenden Erkenntnisse vorhanden oder handelt es sich tatsächlich um Schadcode wird die Software natürlich trotzdem blockiert.

Der Administrator der AWL-Lösung ist bei der Vorkonfiguration aber auch immer in der Lage, bestimmte vertrauenswürdige Anwendungen von vornherein von diesem Prozess auszuschließen. Auch wenn diese prinzipiell vertrauenswürdig sind. Spiele und andere unerwünschte Software kann so vom automatischen Lernen ausgeschlossen werden. Versucht der Endbenutzer so verbotene Software zu installieren, wird ihm das nicht gelingen, auch wenn die Software gutartig ist. Dies alles kann unter Beibehaltung der standardmäßigen "Default-Deny" Schutzfunktionen, die das gesamte System schützt, durchgeführt werden.

Vorurteil Nummer 4:

Entwickler können ihrer Arbeit nicht mehr nachgehen

Der Großteil der Dateien, die Nutzer im Rahmen ihrer Arbeit erstellen und bearbeiten, sind lediglich Daten die nicht ausführbar sind. Entwickler jedoch erstellen ausführbaren Code als Teil ihrer täglichen Arbeit. Unbekannter ausführbarer Code ist aber genau das, was AWL-Lösungen blockieren. Die vorher genannten Reputationsdienste nützen hier nichts, denn woher soll die gerade erstellte Software dort bekannt sein? Bei richtiger Vorgehensweise können auch Entwickler AWL zum Schutz ihrer Systeme verwenden, ohne ihre normale Arbeit zu beeinträchtigen.

Der einfachste Weg, Entwickler zu integrieren, ist den generierten Code zu signieren. Wenn ein Entwickler zum Beispiel Visual Studio für die Entwicklung verwendet, bedeutet das Vertrauen in Signatur mit der Visual Studio jedem kompilierten Code unterschreibt, dass jeder so signierte und ausführbare Code automatisch zur Whitelist-Datenbank hinzugefügt und zur Ausführung freigegeben werden kann.

Andere Lösungsansätze sind sogenannte Lernbenutzer. Das Anstarten einer unbekannten Software wird statt mit dem angemeldeten Nutzer einfach mit einem speziell berechtigten AD Nutzer durchgeführt. Alles was im Nutzerkontext dieses Lernbenutzers ausgeführt wird darf auch auf die Whitelist aufgenommen werden.

Eine komplett andere Möglichkeiten bietet die physische Trennung von Entwicklungsumgebungen vom Rest des Netzes. In einer DMZ braucht man keinen Schutz durch die AWL Lösung.

Vorurteil Nummer 5:

Application Whitelisting verlangt die komplette Konzipierung eines Netzwerks zu ändern.

Auch bei diesem Vorurteil kann nur wiederholt werden: für eine schlechte AWL Lösung mag das zutreffen. Ein gutes Whitelisting Produkt arbeitet nahtlos mit der bestehenden Netzwerk- und Hardwarearchitektur zusammen und integriert sowohl Softwareverteilung als auch Systemmanagement. Denn eine Whitelisting Lösung muss lediglich mit den verwendeten Tools bekannt gemacht werden, alles andere geschieht dann automatisch.

Vorurteil Nummer 6:

Application Whitelisting und bestehende Antivirus Lösungen können nicht parallel betrieben werden. 

Es gibt keinen Grund, warum Whitelisting und das Blacklisting von Virenscannern nicht parallel arbeiten sollten. Es wird sogar häufig die Empfehlung ausgesprochen beide zur gleichen Zeit zu verwenden. AWL schützt proaktiv vor Zero-Day-Angriffen, die Virenscanner andernfalls durchlassen würden. Der Virenscanner kann von der Whitelist blockierte Schadsoftware schließlich von den Endpoints entfernen, ohne dass irgendjemand dafür einen Finger rühren muss. Aus technischer Sicht sollten alle AWL-Lösungen neben allen Blacklist-Lösungen gut funktionieren. Ob es tatsächlich sinnvoll ist beide parallel zu betreiben ist wahrscheinlich eine Frage der Einstellung und der finanziellen Mittel. Der Schutz den Whitelisting bietet macht den Virenscanner überflüssig.

Vorurteil Nummer 7:

Application Whitelisting kann durch Skripte leicht umgangen werden.

Das ist einfach nur falsch. Jedes moderne AWL Produkt wird die Fähigkeit beinhalten, bestimmte Programme (Interpreter) in der Nutzung zu beschränken. Diese Option wird Application Control genannt. Nur bestimmte User wie Administratoren beispielsweise sind über Application Control in der Lage einen Interpreter wie PowerShell überhaupt auszuführen. Alle anderen User können das für das Skript notwendige Programm erst gar nicht ausführen. Es gibt sogar Lösungen die sämtliche Skripte verweigern können, jedoch wird diese Option nur in den seltensten Fällen überhaupt aktiviert, da das Blockieren von Skripten mit unter zu Problemen führt, die vorher nicht abzusehen sind. Skripte stellen überdies auch keine permanente Bedrohung für einen Endpoint dar, sobald der betroffene PC auf dem ein schadhaftes Skript läuft neu gestartet wird, ist auch das Skript wieder inaktiv.

Vorurteil Nummer 8:

Anwendungen die bereits auf der Whitelist stehen können genutzt werden um das Whitelisting zu umgehen.

Ähnlich wie bei der potenziellen Bedrohung durch Skripte würden ernstzunehmende Hersteller einen so offensichtlichen Weg die eigene Sicherheitslösung zu umgehen nicht in ihre Produkte einbauen. Obwohl Betriebssystemkomponenten natürlich ausgeführt werden dürfen, so sind diese oft nur für den Start eines Angriffs in Verwendung. Der Code der den tatsächlichen Angriff dann ausführen soll, kann wiederum nicht gestartet werden da er unbekannt ist.

Vorurteil Nummer 9:

Application Whitelisting kann während Änderungen an Systemen umgangen werden.

Dieses Vorurteil ist auf die Funktionsweise früherer AWL-Lösungen zurückzuführen. Wenn der Administrator eine genehmigte Systemänderung vornimmt, wie z.B. die Installation eines neuen Softwarepakets, wurden die Schutzvorkehrungen vorübergehend aufgehoben, so dass die Änderungen erlernbar werden. Während dieses genehmigten Lernprozesses könnten schädliche Programme die auf die Whitelist angelernt wurden gemäß der aktualisierten Whitelist ausgeführt werden. Moderne AWL-Lösungen aber lernen nur noch die Änderungen die durch die neuen Bestandteile des Updates angefragt werden und prüfen diese gleichzeitig. Parallel ausgeführte Schadprogramme werden als unbekannt oder als bekannt und schädlich blockiert.

Vorurteil Nummer 10:

Application Whitelisting benötigt sehr viel Performance.

Diese Behauptung ist bei keiner AWL-Lösung zutreffend. Dies gilt insbesondere im Vergleich zum Overhead, der bei Blacklist-Lösungen anfällt. Damit ein Virenscanner eine Datei überprüfen kann, um diese zuzulassen oder zu blockieren, muss im einfachsten Fall der gesamten Dateiinhalt mit einer Signaturdatenbank für jede jemals identifizierte Malware-Variante abgeglichen werden. Das ist keine leichte Aufgabe und es ist das, was die CPU auf jedem System wo der Virenscanner läuft tun muss, um eine Schutzfunktion zu gewährleisten.
Damit ist noch nicht auf wesentlich aufwändigere Prüfmethoden wie Sandboxing, heuristische Analysen oder Deep Learning eingegangen worden. Zudem muss der Virenscanner immer alle Dateitypen prüfen, Sie geben also immer einen Vollzugriff auf alle Ihre Daten.

Bei AWL muss das Binary einer ausführbaren Datei nur einmalig durch durch einen Algorithmus in einen Hash umgewandelt werden. Diese Methode ermöglicht die eindeutige Identifizierung des Programms, weil jedes Programm einen anderen Hash ergibt. Man kann sich das ganze vereinfacht wie eine Quersumme vorstellen bzw. wird oft vom elektronischen Fingerabdruck des Programms gesprochen. Dieser Hash wird dann einfach an die Whitelist Datenbank gesendet und abgeglichen. Wenn der Hash nicht auf der Whitelist ist, wird das Programm welches diesen Hash erzeugt blockiert. Dieser Vorgang dauert weder lange (ca. 30ms) noch benötigt das Erzeugen des Hashs viel Performance.

Fazit

Dieser Ausschnitt an Vorurteilen beleuchtet nur die am meisten genannten im Zusammenhang mit Application Whitelisting Lösungen im Allgemeinen und seculution im speziellen. Anhand dieser 10 Vorurteile kann man allerdings sehr gut klar machen, dass diese entweder nicht mehr zutreffend oder komplett aus der Luft gegriffen sind. Inzwischen wird Whitelisting sogar als primäre Antivirus Lösung noch vor Virenscannern empfohlen, da die Bedrohungslage heutzutage eine andere Herangehensweise in der IT-Sicherheit benötigt.