Was ist Application Whitelisting?

Application Whitelisting ist ein Konzept, bei dem eine Liste von Programmen existiert, die ausgeführt werden dürfen, während alles andere nicht funktionieren darf.

Die fortschrittlichsten Application-Whitelist-Technologien kombinieren eine Art Quell- und Ziellogik. Zum Beispiel könnte eine Application Whitelist besagen: „Windows Notepad darf auf den Ordner Steuern auf meinem Desktop zugreifen, Microsoft Word jedoch nicht.“

Wir werden dies weiter untersuchen, aber generell verlassen sich Verteidigungsstrategien mittels Application Whitelisting stark auf diese beiden Variablen:

1. Die Angreifer stimmen zu, sich an die Regeln zu halten, die Sie im Hinblick auf Ihr Application-Whitelisting-Cybersicherheitstool festgelegt haben.

2. Ihre Umgebung ist sehr klein, mit wenigen Anwendungen, die relativ stabil bleiben und keine Exploits aufweisen.

Nachteile von Application-Whitelisting-Technologien

Komplexität

IT-Netzwerke sind wie komplexe Organismen

Selbst kleine IT-Netzwerke sind sich ständig verändernde Gebilde mit einer Vielzahl von Verhaltensweisen. Anwendungen werden von Benutzern ständig hinzugefügt und entfernt. Module innerhalb von Anwendungen werden von den Programmherstellern ständig hinzugefügt und entfernt, insbesondere bei Updates. Schließlich werden Anwendungsverhalten – zusätzlich zu Codeänderungen, die zu Verhaltensänderungen führen – von verschiedenen Benutzern zu unterschiedlichen Zeiten auf unterschiedliche Weise genutzt. Stellen Sie sich nun das Team vor, das diese ständige Verfolgung unterstützen müsste, sowie die IT-Helpdesk-Tickets, die dabei fortlaufend eingehen würden.

Realistisch betrachtet ist die einzige stabile IT-Umgebung eine, die durch Kioske angetrieben wird, bei denen Programme installiert werden, ohne dass sie aktualisiert, hinzugefügt oder entfernt werden können, und bei denen Benutzer nur eng begrenzt eine oder zwei Funktionen ausführen dürfen. Vielleicht ein Kiosk für den Fotodruck oder Ähnliches. In diesem Fall müsste die Application Whitelist nur jedes Mal aktualisiert werden, wenn das Kiosk-Terminal zum Beispiel zweimal jährlich ein Upgrade erhält.

Fortschrittlichere Application Whitelists bedeuten mehr Komplexität

Die einfachsten Application Whitelists bestehen lediglich aus Listen von Programmen, die im System eines Benutzers existieren dürfen.

Dies allein kann bereits eine Herausforderung im Management darstellen, führt aber zu einer Vielzahl möglicher Erweiterungen.

Zum Beispiel: Nur weil die Personalabteilung (Payroll) eine Anwendung zur Interaktion mit dem Gehaltsabrechnungssystem des Unternehmens hat, sollte es dann nicht ein separates Regelwerk für das Lagerteam geben, das andere (nicht mit der Gehaltsabrechnung zusammenhängende) Anwendungen nutzt?

Erweiterungen dahingehend, welche Abteilungen oder Benutzer welche Anwendungen ausführen dürfen, sind also eine naheliegende Erweiterung. Eine Erweiterung, die nun zusätzliche Komplexität schafft, zusätzlich zur bloßen Verfolgung der Anzahl, Art und Versionen der Programme in Ihrem Netzwerk.

Nehmen wir nun an, wir benötigen einen weiteren Satz von Erweiterungen – wir müssen entscheiden, welcher Benutzer Zugriff auf welche Anwendung für welchen Datensatz hat.

Das ergibt ebenfalls vollkommen Sinn, nicht wahr? Sie möchten nicht, dass Ihr Lagerteam Zugriff auf die HR-Daten hat, und das HR-Team benötigt vermutlich keinen Zugriff auf die Betriebsdaten des Lieferteams im Lager.

Das ist eine geradezu absurd komplexe Menge an Kombinationen, die es zu verfolgen gilt, jetzt, da Datenspeicherorte als zusätzliche Variable hinzugekommen sind.

Mit jeder notwendigen Erweiterung, um Application-Whitelisting-Technologien wirksam zu machen, wird also die Verwaltung, Konfiguration und der laufende (man könnte sagen nie endende, stets eskalierende) Support, der zur Aufrechterhaltung der Funktionsfähigkeit erforderlich ist, die Technologie unbrauchbar machen. Das Ergebnis ist normalerweise, dass großen Benutzergruppen Zugriff auf große Gruppen von Anwendungen gewährt wird – und wahrscheinlich auf nahezu alle Daten. Damit entsteht eine nahezu nutzlose Konfiguration der Technologie, da kein Unternehmen über die Ressourcen verfügt, um sie ordnungsgemäß zu verwalten.

Anwendungen interagieren miteinander

In modernen Betriebssystemen ist es üblich, dass Anwendungen mit anderen Anwendungen interagieren. Manchmal beruht diese Interaktion auf einer Integration zwischen zwei Anwendungen, die das Benutzererlebnis verbessert – etwa wenn ein Word-Dokument Microsoft Photos öffnet. In anderen Fällen (dies kommt sehr häufig vor) gibt es Aufrufe zwischen Programmen, die auf eine Weise erfolgen, die für den Endbenutzer in der Regel unsichtbar ist.

Einführung

Application Whitelisting bedeutet im Kontext von Cyber Crucible, einer Anwendung die Erlaubnis zu erteilen, eine Aktion auszuführen, die andernfalls als verdächtig oder bösartig eingestuft werden könnte.

Application-Whitelisting-Technologie findet sich typischerweise in defensiven Fachpraktiken der Verhaltensanalyse, obwohl einige Angreifer sie ebenfalls (hier nicht behandelt) in ihren Operationen einsetzen.

Man kann es sich vorstellen wie in der Schule: Normalerweise durften Schüler während des Unterrichts nicht durch die Flure laufen. Wenn ihnen jedoch von einer Autoritätsperson eine Art „Hallenausweis“ ausgestellt wurde, wurden sie nicht in ihr Klassenzimmer zurückgebracht oder ins Büro des Schulleiters geschickt.

Arten von Application Whitelisting - eine nicht-technische Beschreibung

Bleiben wir bei der Analogie des „Hallenausweises“, so gibt es verschiedene Techniken, die Schulverwaltungen im Laufe der Zeit entwickelt haben, um die Verhaltensweisen zu formalisieren, mit denen manche Schüler (ganz bestimmt nicht unser CEO Dennis) davonzukommen versuchten. All diese Techniken haben eine direkte Entsprechung im Sicherheitsbetrieb.

Der offensichtliche & umständliche Hallenausweis (eine gute Sache)

Erinnern Sie sich noch an einen Hallenausweis oder einen Schlüssel zu einem Raum, der unglaublich groß und auffällig war?

Dafür gab es ein paar gute Gründe:

1. Damit er nicht verloren ging.

2. Um den Zeit- und Energieaufwand einer Autoritätsperson bei der schnellen Überprüfung der genehmigten Aktivitäten des Schülers zu verringern.

Gute Software „verliert“ keine Whitelist, aber eine Application-Whitelist-Software sollte eine schnelle, ressourceneffiziente Überprüfung ermöglichen, dass die Anwendung geprüft wurde.

Der generische Hallenausweis (wahrscheinlich keine gute Sache)

Dies ist wahrscheinlich sowohl für die Anwendungsüberwachung als auch für Schulen am wenigsten nützlich, erfordert aber auch das geringste Management oder Fachwissen.

In diesem Fall darf der Schüler seine Besorgung im Flur erledigen. Der Lehrer weiß vielleicht Bescheid, aber es gibt keine Überprüfung durch Aufsichtspersonen, was der Schüler tatsächlich tut. Selbst wenn eine Überprüfung versucht wird, entstehen zwei Ebenen erheblichen Ressourcenaufwands:

1. der Aufwand, den Schüler anzusprechen und zu seinem Verhalten und seiner Absicht zu befragen

2. der Aufwand, sicherzustellen, dass der Schüler ehrlich ist, um seine Erklärung zu überprüfen

Bei Anwendungen zeigt sich dies meist dann, wenn ein Programm zu einer Whitelist hinzugefügt wird, ohne dass eine weitere Überprüfung der Verhaltensweisen oder erlaubten Aktivitäten erfolgt. Leider steht die Möglichkeit, Kontext zu den Verhaltensweisen einer Anwendung zu erhalten, in der Regel nicht zur Verfügung, wenn dies nicht extern durch ein anderes Framework nachverfolgt wird.

Der generisch-spezifische Hallenausweis

Nicht zu verwechseln mit „Los, Anwendung, mach, was du willst!“

Kehren wir zum Toilettenausweis zurück, denn er passt hier besonders gut. Angesichts der Sichtbarkeit des Ausweises ist es relativ einfach zu beurteilen, was der Schüler tun sollte. Grobe Verhaltensweisen, die nicht mit dem „Toilettengang“ übereinstimmen, lassen sich ohne großen Aufwand erkennen.

Application Whitelisting mit generischen Grenzen der Aktivitäten ist am häufigsten anzutreffen, obwohl diese Grenzen in vielen Fällen dem Äquivalent entsprechen, einem Schüler mit Toilettenausweis das Spielen auf dem Schulhof zu erlauben.

Der spezifisch-spezifische Hallenausweis

Nicht zu verwechseln mit dem „generisch-spezifischen“ Hallenausweis!

Während wir beim generisch-spezifischen Hallenausweis wissen, dass der Schüler die Toilette benutzt, wissen wir in einer großen Schule nicht:
1. Wer dem Schüler die Erlaubnis erteilt hat

2. Wo er gerade herkommt.

3. Welche Toilette die Autoritätsperson bei ihrer Genehmigung im Sinn hatte.

4. Wie lange der Schüler schon „unterwegs“ ist.

Dies erforderte mehr Arbeit am Autoritätsrahmen der Schule.

Um zum Application Whitelisting zurückzukehren: Die Verhaltensanalyse wird genauer, je mehr Variablen in eine Entscheidungsfindungsfähigkeit einfließen.

Wenn man außerdem einen ausgestellten Hallenausweis überprüft, muss man normalerweise keine Kette von 5 Lehrern zurückverfolgen, um zur Quelle zu gelangen. Man kann auch fast immer darauf vertrauen, dass der Lehrer keine Art „schlechter Lehrer“ war, der Schülern falsches Verhalten beibringt. Application Whitelisting erfordert im Beispiel einer spezifisch-spezifischen Whitelist ein Rückwärtsarbeiten, um jede übergeordnete oder vorangehende Anwendung zu untersuchen, die die nächste Anwendung geöffnet hat. Zum Beispiel könnte ein Stück Malware ein legitimes Windows-Dienstprogramm geöffnet haben.

Die folgenden Fragen entsprechen ungefähr dem oben genannten „Schüler-Hallenausweis“:

1. Wofür wurde die Anwendung gestartet, oder was wurde ihr aufgetragen? Wir müssen das beabsichtigte Verhalten kennen.

2. Wer hat die Anwendung gestartet? Dies ist typischerweise ein anderes Programm.

3. Welche „übergeordneten“ oder „vorangehenden“ Programme führten zum Öffnen dieses Programms? Was taten oder beabsichtigten diese jeweils zu tun?

Die kompromittierte Anwendung

Erinnern Sie sich an verschiedene Science-Fiction- oder Horrorliteratur und -filme, in denen ein Betrüger auf irgendeine Weise die

Kontrolle über das Verhalten einer Figur übernommen hat? In Schulen besteht kaum die Gefahr, dass eine Lehrkraft von Außerirdischen übernommen wird.

Die Übernahme von Anwendungen ist eine beliebte Technik von Angreifern, denn wie in den Filmen bemerken die meisten Beobachter nichts Ungewöhnliches, bis es zu spät ist.

In diesem Fall übernimmt ein Angreifer ein laufendes Programm, das gerade in den Speicher geladen ist. Das vollständig intakte Programm im Dateisystem wird dabei ignoriert. Das Programm im Speicher wird bearbeitet, um den Code des Angreifers hinzuzufügen - ähnlich wie ein Außerirdischer im Körper eines Menschen. Der Angreifer führt seine kriminellen Handlungen aus, und wenn das Programm fertig ausgeführt wurde, ist der größte Teil der Beweise verschwunden. Wenn das legitime Programm erneut läuft und der Angreifer den Code nicht erneut bearbeitet, verhält es sich genau so, wie es die ursprünglichen legitimen Programmierer beabsichtigt hatten. Vielleicht wäre in diesem Fall ein Werwolf die bessere Analogie?

Eine Application-Whitelist muss daher zusätzlichen Aufwand betreiben, um sicherzustellen, dass das Programm sowie alle vorangehenden oder übergeordneten Programme intakt sind und nicht von Hackern bearbeitet wurden, während sie ausgeführt werden.

Zusammenfassung - Fragen, die bei der Untersuchung einer Application-Whitelist-Funktion gestellt werden sollten

Stellen Sie sicher, dass Sie die Grenzen dessen verstehen, was eine Whitelist erlaubt, wenn Sie mit Ihrem Technologieteam oder Anbieter über Application Whitelisting sprechen.

1. Untersucht und verfolgt diese Funktion, was ein Programm tun soll, und vergleicht sie erwartetes mit beobachtetem Verhalten?

2. Wie viele Details erfasst die Whitelist-Funktion bei ihrer Entscheidungsfindung? Mehr oder weniger als ein detaillierter Schüler-Hallenausweis?

3. Verfolgt und untersucht die Whitelist-Funktion übergeordnete und vorangehende Programme auf Bösartigkeit? (Programm A öffnet B, öffnet C, öffnet D - sehr häufig)

4. Überprüft die Whitelist-Funktion, ob das laufende Programm nicht manipuliert wurde?

Vertiefende Lektüre des National Institute of Standards & Technology (NIST)

Eine maßgebliche Publikation, die nicht zur beiläufigen Lektüre gedacht ist, aber sehr anschaulich beschreibt.

Obwohl sie nicht jedes Szenario abdeckt und die Details nicht häufig genug aktualisiert werden, um mit jedem Szenario Schritt zu halten, sind die Beschreibungen strategisch genug, um in den meisten Fällen wertvoll zu sein.

Das Team von Cyber Crucible schätzt Erkenntnisse aus NIST-Publikationen stets sehr und nimmt sich entsprechend Zeit dafür.

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-167.pdf

Benutzer können erkennen, welche Erpressungsreaktionen unterbrochen worden wären, wenn ein angepasstes Verhalten nicht existiert hätte, indem sie zunächst zur Seite Erpressungsreaktionen navigieren, die im Bereich Operationen in der Seitenleiste zu finden ist.

Die Spalte Ausgeschlossen zeigt an, ob eine Erpressungsreaktion ausgeschlossen wurde oder nicht, und der Standardfilter der Spalte zeigt nicht ausgeschlossene, nicht stille Reaktionen an.

Um ausgeschlossene Reaktionen anzuzeigen, öffnen Sie den Filter der Spalte Ausgeschlossen und wählen Sie nur Ausgeschlossen aus.

Nach dem Klicken auf Anwenden zeigt das Raster ausgeschlossene Erpressungsreaktionen an, die unterbrochen worden wären, wenn das angepasste Verhalten nicht existiert hätte.

Um zu sehen, welches angepasste Verhalten auf eine Reaktion angewendet wurde, klicken Sie zunächst auf den Pfeil in der Spalte Anzahl der Vorfälle für die jeweilige Zeile. Im inneren Raster, das sich nach dem Klicken auf den Pfeil öffnet, zeigt die Spalte Ausblendregel den Namen des angepassten Verhaltens an, das auf die Reaktion angewendet wurde.

Die Seite „Tailored Behaviors“ finden Sie unter dem Reiter „Operations“ in der Seitenleiste. Beachten Sie, dass Benutzer über die Berechtigung „View Tailored Behaviors“ für eine Gruppe verfügen müssen, um die individuellen Verhaltensregeln dieser Gruppe auf dieser Seite einsehen zu können.

Wie man eine individuelle Verhaltensregel erstellt

Klicken Sie nach dem Aufrufen der Seite „Tailored Behaviors“ auf das Symbol „Prozess ausschließen“ oberhalb dieser Tabelle.

Durch Klicken auf dieses Symbol öffnet sich ein Modal zum Erstellen der individuellen Verhaltensregel.

Benutzer haben die Möglichkeit, bei der Ausnahme ein übergeordnetes Programm anzugeben

Geben Sie zusätzliche anzuwendende Einschränkungen ein

Benutzer haben jetzt die Möglichkeit, die Ausnahme auf bestimmte Dateizugriffsauslöser zu beschränken; standardmäßig sind alle Dateizugriffsauslöser eingeschlossen. Beachten Sie, dass nur Agenten ab Version 4.4.6.2 diese Funktion für Dateizugriffsauslöser unterstützen.

Benutzer haben außerdem die Möglichkeit, temporäre Verhaltensregeln zu erstellen; mehr dazu im nächsten Abschnitt

Wie man temporäre individuelle Verhaltensregeln erstellt und bearbeitet

Benutzer können eine temporäre individuelle Verhaltensregel erstellen, indem sie den normalen Erstellungsprozess wie oben beschrieben durchführen und dabei den Schalter „Make This Tailored Behavior Temporary“ aktivieren. Anschließend können Benutzer die Anzahl der Stunden eingeben, nach denen die temporäre Verhaltensregel ablaufen soll (maximal eine Woche).

Das Ablaufdatum der Verhaltensregel ist in der Spalte „Expiration Date“ der Tabelle sichtbar.

Um bei einer temporären Verhaltensregel das Ablaufdatum zu verlängern, eine temporäre Verhaltensregel dauerhaft zu machen oder eine dauerhafte Verhaltensregel temporär zu machen, klicken Sie auf das Bearbeitungssymbol bei der gewünschten Verhaltensregel in der Spalte „Expiration Date“.

Durch Klicken auf dieses Symbol öffnet sich ein Modal, in dem Benutzer das Ablaufdatum der Verhaltensregel nach Bedarf bearbeiten können

Wie man individuelle Verhaltensregeln löscht

Um eine oder mehrere Verhaltensregeln gleichzeitig zu löschen, wählen Sie zunächst die gewünschte(n) Verhaltensregel(n) in der Tabelle aus und klicken Sie auf das Papierkorbsymbol oberhalb der Tabelle.

Geben Sie anschließend „delete“ ein und klicken Sie auf die Schaltfläche „Delete“.

Wie man individuelle Verhaltensregeln in eine andere Gruppe kopiert

Um eine oder mehrere Verhaltensregeln gleichzeitig in eine andere Gruppe zu kopieren, wählen Sie die gewünschte(n) Verhaltensregel(n) in der Tabelle aus und klicken Sie auf das Kopiersymbol oberhalb der Tabelle.

Durch Klicken auf dieses Symbol öffnet sich ein Modal, in dem Sie die Gruppe auswählen können, in die die Verhaltensregel(n) kopiert werden sollen.

Dieses Modal bietet außerdem die Option, die bestehenden Verhaltensregeln in der ausgewählten Gruppe zu löschen (mit Ausnahme automatisch generierter Verhaltensregeln), sodass nach dem Absenden der Anfrage nur die kopierten Verhaltensregeln in der ausgewählten Gruppe verbleiben.

Nach dem Absenden der Anfrage werden die kopierten Verhaltensregeln nun für die ausgewählte Gruppe angezeigt.

Erstellen einer individuellen Verhaltensregel über die Seite „Extortion Response“

Benutzer haben die Möglichkeit, individuelle Verhaltensregeln über die Seite „Extortion Responses“ zu erstellen.

Klicken Sie zunächst auf den Pfeil in der gewünschten Zeile der Extortion Response in der Spalte „Number of Incidents“, um die innere Tabelle anzuzeigen.

Klicken Sie anschließend auf das Symbol „Response ausschließen“ in der Spalte „Response Name“, wodurch sich ein Modal zum Erstellen der individuellen Verhaltensregel öffnet.

In diesem Modal können Sie Verhaltensregeln anhand der vorgeschlagenen ausführbaren Pfade erstellen oder die Response zur Überprüfung einreichen, falls die vorgeschlagenen Pfade nicht das Gewünschte enthalten.

Sie können auch auf die Schaltfläche „Take me to Tailored Behaviors Page“ klicken, wodurch Sie zur Seite „Tailored Behaviors“ weitergeleitet werden und das Modal zum Erstellen der Verhaltensregel automatisch mit derselben Gruppe, demselben Pfad und denselben Programmargumenten aus der Response vorausgefüllt wird.

Beachten Sie, dass die Einstellung „Limit Exception to Program + Parent Program“ standardmäßig deaktiviert ist. Der Pfad und die Argumente des übergeordneten Programms aus der Extortion Response werden ebenfalls automatisch ausgefüllt, wenn Sie diese Einstellung aktivieren.

Der Tailored Behavior Exclusion-Eintrag nach Klicken auf „Create“ bei aktivierter Einstellung „Limit Exception to Program + Parent Program“: