Interview mit Arnas Staude (Teil 1): "BEAST macht es einfach, Zusammenhänge zu erkennen"

Grundsätzlich nutzen wir in der Malware-Bekämpfung statische und dynamische Analyseverfahren. Statische Verfahren analysieren die Eigenschaften von verdächtigen Dateien wie Hashsumme, Zeichenketten, Codefragmente, Dateigröße, Header-Eigenschaften. Der Vorteil: Bei der Analyse müssen wir die Malware nicht ausführen. Bei dynamischen Verfahren hingegen führen wir die potenziell schädliche Datei aus und beobachten ihr Verhalten. Der Unterschied zwischen beiden Verfahren ist, dass wir bei der statischen Analyse die Malware bereits blockieren, bevor wir sie ausführen. Bei den dynamischen Methoden erkennen wir erst nachgelagert das schädliche Verhalten und stoppen die Malware dann. Während wir bei den statischen Verfahren für jede Malware-Familie eine eigene Regel für die Erkennung erstellen müssen, können wir bei verhaltensbasierten Regeln allgemeiner und langlebiger definieren, was schädlich ist.

Das Verhalten von Malware lässt sich dagegen deutlich schwerer ändern, als der Programmcode. Auf das schadhafte Verhalten können und wollen die Cyberkriminellen nicht verzichten. Denn dann könnten sie nicht mehr mit dem Betriebssystem agieren, um beispielsweise Passwörter auszulesen oder wichtige Daten zu verschlüsseln. Kurzum: Sie richten dann keinen Schaden mehr an.

Verhaltensanalyse ist seit vielen Jahren ein fester Bestandteil in den Sicherheitslösungen von G DATA. Der Behaviour Blocker leistete dabei solide Arbeit. Es ist eine sehr stabile und über die Jahre ausgereifte Verhaltensanalyse mit sehr guten Ergebnissen. Trotzdem haben wir gemerkt, dass das Potenzial für verhaltensbasierte Erkennung noch lange nicht ausgeschöpft ist. Der bisherige Ansatz war wenig erweiterbar. Zudem ließ sich mitunter schwer nachvollziehen, wie einzelne Ergebnisse zu Stande gekommen sind. Denn der bisherige Ansatz ist Scoring-basiert und berechnet daher für jedes Programm einen numerischen Wert zwischen Null und Eins. Wenn ein vorab definierter Grenzwert überschritten wird, gilt das Programm dann als bösartig. Dieser Wert berechnet sich nach einer großen mathematischen Formel. Das heißt aber auch, dass für uns nicht immer nachvollziehbar ist, welcher Aspekt zu einer Einstufung als schadhaft geführt hat. Eine Einzelfall-Betrachtung ist also aufwendig. Gerade der Umgang mit ‚False Positives‘ ist dadurch besonders schwierig und bedarf einer gesonderten Herangehensweise. Eine Anpassung der Formel ist nur schwer machbar. Denn es ist leider nicht immer absehbar, wie sich eine kleine Änderung bei der Berechnung später auf andere Programme auswirkt.

Daher haben wir uns für eine zukunftsfähige Neu-Entwicklung entschieden. Der Name BEAST steht dabei für BEhAviour STorage. Ein Ziel war ein nachvollziehbarer Entscheidungsprozess. Wir wollten wissen und nachvollziehen, was im Detail passiert. Gleichzeitig wollten wir bestehende Technologien wie den Bank Guard oder Exploit Protection mit der neuen Verhaltensanalyse verbinden können. Denn diese erkennen zwar Auffälligkeiten, aber sammeln keine Informationen, wie diese Auffälligkeiten zustande kommen.

Der große Vorteil von BEAST ist die Nachvollziehbarkeit, so dass wir alle Erkennungen sehr genau verstehen. Denn die Grundlage von BEAST ist eine leistungsfähige Graphdatenbank, mit der wir alle Vorgänge visualisieren können. Dadurch sind wir in der Lage, schädliches Verhalten gezielt zu erkennen, damit keine ‚False Positives‘ entstehen. Ein Grund ist, dass wir jetzt deutlich einfacher die Regeln anpassen können. Im Grunde hatten wir beim Behaviour Blocker eine große mathematische Regel, sodass unklar war, welche Auswirkungen Änderungen auf das gesamte System haben. Vorher hatten wir somit eine einzige sehr große Regel, jetzt gibt es sehr viele kleine, die sich entsprechend leichter anpassen lassen. Zusätzlich sind wir dank BEAST in der Lage, viel mehr Tests durchzuführen.

Dafür können wir mit dem Graph auch offline scannen. Für die Tests haben wir eine große Datenbank mit bekannten schädlichen Verhaltensmustern aufgebaut und können darauf unsere Regeln testen. So optimieren wir unsere Erkennung. Zeitgleich haben wir auch gutartige Graphen, mit denen wir sicherstellen, dass dort keine Erkennungen stattfinden. Die Pflege dieser Datenbank sichert unsere gute Erkennung und vermeidet ‚False Positives‘. Sobald wir einmal ein Verhalten als ‚False Positive‘ klassifiziert haben, fügen wir dieses in unsere Datenbank ein, sodass BEAST denselben Fehler nie zweimal macht.

Retrospektiv meint dabei die zeitliche Komponente. Wir schauen zurück, was in der Vergangenheit passiert ist. Daher können wir damit jetzt auch Prozesse in Betracht ziehen, die schon lange nicht mehr existieren. Indicators of Compromise gibt es im Verlauf von Infektionen immer. Sei es ein besuchter Server oder eine geöffnete Datei. Bis diese Indikatoren aber als schadhaft identifiziert werden, sind sie häufig auf dem betroffenen System nicht mehr verfügbar, weil etwa die Malware zum Beginn der Infektionskette zugehörende Dateien gelöscht hat.

Bei BEAST existieren diese noch im Graphen, so dass die gesamte Infektionskette verfügbar ist und rückgängig gemacht werden kann.

Im Graph bleiben diese Informationen erhalten und die verbliebenen Artefakte im System lassen sich trotzdem aufspüren. Denn mit dem Retrospective Removal lässt sich, ausgehend von einem Knoten, den ich bereits als schädlich erkannt habe, der ursprüngliche Parent-Prozess identifizieren und im Nachgang genauer untersuchen. Hat er etwa verdächtige Dateien heruntergeladen und weitere Programme gestartet? Ich habe dann genügend Informationen, um die Infektion vollständig zu bereinigen. Solche komplexen Zusammenhänge bleiben gewöhnlichen verhaltensbasierten Technologien verborgen. Das bietet insbesondere Vorteile, wenn sich Malware zum Beginn der Infektion „schlafen legt“ oder auf ein Kommando des Botnet-Operators wartet, aber noch keine schädlichen Aktionen durchgeführt hat. Denn die schädlichen Aktionen würden wir dann mit BEAST erkennen.

BEAST ist ziemlich unauffällig. Gerade aus dem Support erhalten wir sehr wenig Rückfragen, was ein ziemlich gutes Zeichen ist. Denn das bedeutet, dass wir unsere Kunden beispielsweise kaum durch ‚False Positives‘ stören. Hier gilt: Je unauffälliger, desto besser. Zusätzlich verfolgen wir die Arbeit von BEAST sehr genau über unsere Erkennungstelemetrie. Hier können wir nachvollziehen, dass BEAST jeden Tag eine Vielzahl von Kunden erfolgreich schützt. Auch externe Tests haben schon bestätigt, dass BEAST seinen Job zuverlässig erledigt: Schadsoftware zu erkennen.

Beide Technologien sind sehr unterschiedlich, sodass ein direkter Vergleich schwerfällt. Schließlich haben wir ja unseren alten Behaviour Blocker durch BEAST ersetzt. Was wir jetzt schon sehen, ist das gute Zusammenspiel mit anderen Komponenten wie etwa DeepRay. Damit haben wir eine der zentralen Anforderungen an BEAST erfüllt: BEAST unterstützt die bestehenden Technologien bei ihrer Arbeit und macht diese noch besser. Zusätzlich benutzen wir BEAST auch im Backend und generieren dort Daten, indem wir Schadsoftware analysieren. Damit optimieren wir die Backend-Prozesse und sorgen auch hier für eine noch schnellere Erkennung und für ein besseres Blacklisting. So überführen wir die Ergebnisse der dynamischen Erkennung direkt in die statische Erkennung. Damit verhindern wir, dass bereits bekannte Malware erneut ausgeführt wird.

Gleichzeitig können wir unsere Schutzregeln viel besser anpassen. Beim Behaviour Blocker war das wegen der Komplexität des Algorithmus kaum noch möglich und so schlägt sich das in einer deutlich höheren Reaktionsfähigkeit in der täglichen Arbeit nieder.

Die größte Hürde war sicherlich die Performance. Denn am Anfang hatten wir noch keine harten Kriterien festgelegt. Über die Zeit hat das Thema aber an Bedeutung gewonnen. Denn BEAST sollte viele Daten speichern und verarbeiten, um das Wissen verfügbar zu machen. Gerade im Vergleich zum alten Ansatz wurde schnell klar, dass die neue Technologie rechen- und speicherintensiver arbeitet. BEAST untersucht kontinuierlich auftretendes Verhalten auf bekannte Muster und muss daher ständig verschiedenste Daten verarbeiten. Der alte Ansatz muss sich nichts merken, sondern aggregiert alles in einem numerischen Score, sodass nicht so viel CPU-Last entsteht.

Wir mussten also viel Arbeit in performante Abläufe investieren. Schätzungsweise die Hälfte der Entwicklungszeit haben wir dafür genutzt. Denn nach jeder Änderung haben wir getestet und verglichen, ob sich eine Verbesserung ergeben hat. Schließlich zeigt nur der Test, ob unsere Annahmen korrekt waren. Manchmal hatten vielversprechende Änderungen kaum Auswirkungen auf die Performance. Andersherum haben aber auch kleinere und auf den ersten Blick unbedeutende Korrekturen einen größeren Impact auf die Performance gehabt als erwartet. Das hat sicherlich lange gedauert, bis wir das gewünschte Ergebnis schlussendlich erzielt haben.

Es war auf jeden Fall verdammt viel Arbeit. Immerhin hat es fünf Jahre gedauert, BEAST zu entwickeln. Gerade am Anfang war es aufwendig, weil ich zunächst alleine gearbeitet habe und ich aufgrund von fehlendem Austausch manchmal den Wald vor lauter Bäumen nicht gesehen habe. Aber mit der Zeit ist das deutlich besser geworden. Insbesondere, weil ich auch personell Unterstützung erhalten habe. Es waren sehr viele Teams in das Projekt involviert, nicht nur die Kernentwicklung, sondern einmal quer durch die Firma. Diese Zusammenarbeit hat sehr gut funktioniert. Im Rückblick betrachtet lief alles ganz rund. Der Aufwand hat sich gelohnt und wir können stolz auf das Ergebnis sein.

Im zweiten Teil des Interviews gibt Arnas weitere spannende Einblicke in die Entwicklung unserer neuen Verhaltensüberwachung BEAST.