Interview mit Arnas Staude (Teil 2) „Das Ganze ist mehr als die Summe der Einzelteile“

Bei BEAST steht ja das Verhalten von Prozessen im Mittelpunkt. Im Backend sind ganz viele Graphen gespeichert mit gutartigem und auch schadhaftem Verhalten. Jetzt können wir anhand unserer Regeln sicherstellen, dass wir die schadhaften Prozesse identifizieren. Denn bei jeder Änderung im Graph scannen wir die Umgebung des Knotens auf bekannte Muster. BEAST spielt dann seine Stärken aus, wenn schadhaftes Verhalten über mehrere Prozesse verteilt ist. BEAST erkennt diese Zusammenhänge mittels Subgraph-Matching und gleicht das aktuelle Verhalten mit bestehenden Regeln ab.

Ein typischer schadhafter Prozess ist etwa folgender Ablauf: Prozess 1 erzeugt eine Datei in einem bestimmten Ordner und startet Prozess 2. Dieser wiederum verändert Firewall Regeln und andere Sicherheitseinstellungen, um später ungestört agieren zu können – beispielsweise für den Diebstahl von Zugangsdaten oder Kreditkartennummern. Parallel lädt Prozess 1 eine weitere Datei nach, startet Prozess 3 und löscht sich anschließend selbstständig, um seine Spuren zu verwischen. Prozess 3 sorgt für Langlebigkeit der Schadsoftware und erzeugt einen RunKey mit Eintrag in der Registry auf Prozess 2. RunKeys nutzen Malware-Autoren, um Persistenz zu erzeugen, sodass bei einem Neustart auch die schadhaften Prozesse automatisch starten. So sieht dann auch die Regel aus: Wir haben einen gerichteten Graphen mit drei Prozess-Knoten und drei Datei-Knoten. Wir kennen außerdem die Reihenfolge der einzelnen Prozesse. Der Scanner gleicht dieses Verhalten mit den bestehenden Graphen ab und kann ihn eindeutig als schadhaft einordnen. Denn einzelne Prozessschritte sind dabei nicht grundsätzlich schadhaft. Ein Beispiel ist etwa das Herunterladen von Dateien aus dem Internet. Das passiert nicht nur bei Malware, sondern auch bei Updates für Programme, die auf dem Rechner installiert sind.

Wir wollten die Erkennung besser verstehen, indem wir die Daten vorliegen haben und betrachten können. Und da die Verhaltensdaten in ihrer natürlichen Form eigentlich Graphen sind, lag es nah, eine Graphdatenbank zu benutzen. So können wir sehr effizient mit den Daten und dem damit einhergehenden Datenwachstum umgehen. Es funktioniert einfach und schnell. Prozesse lassen sich etwa als Baum darstellen. Ein Oberprozess startet mehrere Unterprozesse, die wiederum jeder mehrere untergeordnete Prozesse starten. So haben wir dann sowohl die Prozessstruktur als auch andere Informationen wie etwa Dateizugriffe in einem System gespeichert, sodass wir die Zusammenhänge nachvollziehen können. Die Prozesse bilden dann im Graphen die zentralen Knotenpunkte. Von diesen zweigen weitere Informationsstränge ab wie etwa Dateizugriffe oder Anpassungen an der Registry.

Der Graph visualisiert dieses Verhalten wunderbar und macht es anschaulich. Damit lässt sich auch der Infektionsweg einer Malware sehr genau nachvollziehen. Gleichzeitig speichern wir auch die Historie der Prozesskette. Ein großer Vorteil gegenüber dem alten System, das ohne Historie auskommen musste. Hier hatten wir nur den einen Scoringwert, der die Datei als gut oder böse einstufte. BEAST kommt ganz ohne Scoring aus. Wir matchen einen aktuellen Prozess mit der Graphdatenbank und prüfen dabei, ob das Verhalten gutartig oder schadhaft ist.

Die Graphdatenbank und damit auch die Daten liegen immer lokal beim Client und nach circa einer Woche löschen wir Daten, um eine gute Performance zu gewährleisten. Der benötigte Speicherplatz liegt bei maximal 200 MB. Erkennt BEAST eine Abnormalität, sendet er die Daten anonymisiert an unser Telemetrie-Backend – sofern der Kunde dieser Datenübermittlung zugestimmt hat. Wir prüfen einerseits, ob es sich nicht doch um einen False Positive handelt und verbessern damit auch die Erkennung.

Als wir 2014 das Projekt gestartet haben, steckten Graphdatenbanken noch in den Kinderschuhen. Da mussten wir also genau hinschauen, was zu unseren Anforderungen passte. Denn die Anwendung sollte direkt im Client laufen und dabei wenig Speicher verbrauchen und wenig Ressourcenlast beim Kunden erzeugen. Wir wollten eine Datenbank, die sich leicht in unsere eigenen Programme einbinden lässt, sodass wir maximale Kontrolle darüber haben, wie viel Speicher und CPU die Datenbank braucht. Daher konnten wir keine Datenbank nutzen, die darauf ausgelegt war, auf hoch performanten Serversystemen zu laufen. Nach einer eingehenden Marktbetrachtung war klar, dass keine der damals am Markt befindlichen Lösungen wie etwa die Enterprise-Lösung Neo4j unsere Anforderungen erfüllt. Daher haben wir uns entschieden, eine eigene Lösung zu bauen. Vorbildcharakter hatte dabei SQLite, eine relationale Datenbank mit Tabellen, die in eigene Prozesse einbettbar ist. Graphdatenbanken funktionieren grundsätzlich anders. Aber auch heute ist mir noch keine Datenbank bekannt, die unsere Anforderungen vollständig erfüllt.

Hier mussten wir natürlich Grundlagenarbeit leisten und viel selbst entwickeln. Da ich mich selbst vorher nur wenig mit dem Thema auseinandergesetzt hatte, war die Lernkurve entsprechend steil. Bevor wir mit der eigentlichen Graphdatenbank loslegen konnten, stand am Anfang das Event Processing. Also die Frage, woher die Daten für den Graphen kommen. Hier konnten wir auf das bestehende Daten-Backend des Behaviour Blockers zurückgreifen. Dieses mussten wir erweitern, um die eigenen Anforderungen an die Performance zu erfüllen. Neben der Datenbank mussten wir auch das Graphschema definieren – also die Fragen klären, was sind Knoten, was sind Kanten. Und wie hängen die Daten zusammen, damit ich hinterher effizient und ohne Umwege suchen kann.

Ein ganz spannendes Thema ist das Scannen auf dem Graphen. Eigentlich ist es mathematisch schwer zu lösen, effizient zwei Graphen miteinander zu vergleichen. Und nicht zuletzt benötigten wir graphbasierte Algorithmen für das Removal, um die zu löschenden Daten zu identifizieren. Nutzen konnten wir das standardisierte Graphformat GraphML, um Graphen zu exportieren. Auch Tools, um Graphen zu visualisieren, gab es damals schon, wie etwa yEd. Nichts desto trotz haben wir auch eigene Tools entwickelt, um den Graph darin zu visualisieren. Darüber hinaus haben wir den Scanner direkt in die Visualisierung eingebettet. So können wir neue Signaturen mit dem Graph visuell vergleichen, und zum Beispiel schauen, welcher Subgraph für den schädlichen Prozess verantwortlich ist.

Ich habe eigentlich in den vergangenen Jahren jeden Tag etwas Neues gelernt. Da wir eine bestehende Komponente ersetzt haben, hatten wir schließlich den Anspruch, alle bestehenden Features zu übernehmen. Für den Kunden sollte sich nichts verändern und BEAST den gleichen Funktionsumfang bieten. Daher mussten wir quasi direkt eine Version mit vollem Funktionsumfang bereitstellen, was eigentlich total unüblich ist. Normalerweise wächst die Technologie über die Zeit und wird sukzessive erweitert – Features und Funktionen werden nach und nach ergänzt oder verbessert. Daher hatte das Testen während der Entwicklung eine große Bedeutung. Spannend war auch das Schreiben von neuen Regeln. Gerade, wenn man denkt, dass kein gutartiges Programm so reagiert, wird man eines Besseren belehrt. Es ist überraschend, dass viele Programme unsauber arbeiten und somit Schadsoftware sehr ähnlich sind.

Sehr überrascht hat mich der Release. Denn dieser lief tatsächlich fehlerfrei. An dieser Stelle ein riesen Lob und einen großen Dank an das ganze Team und an alle die an dieser großartigen Arbeit beteiligt waren. Auf die abgelieferte Leistung können wir zu Recht wirklich stolz sein. Die Erwartungen waren natürlich im Vorfeld immens, weil wir eine gute funktionierende Technologie ersetzt haben. Gewöhnlich laufen Releases von neuen Komponenten immer ein bisschen holprig ab und sind nicht ohne Risiko. Schließlich können wir nie alle Spezialfälle testen, die am Ende bei unseren Kunden auftreten. Nach und nach traten dann doch noch ein paar kleinere Bugs auf, die wir recht schnell beseitigt haben. Im Großen und Ganzen sind wir erleichtert, dass alles glatt gelaufen ist. Von Vorteil war, dass wir BEAST nicht bei allen Kunden gleichzeitig ausgerollt haben, sondern immer nur bestimmte Kundengruppen in kleinen Margen bedient haben. So waren wir immer handlungsfähig, um Anpassungen bei Problemen schnell vorzunehmen.

Es ist geplant BEAST weiter mit bestehenden und neuen Technologien zu verknüpfen, wie wir es bereits mit DeepRay getan haben. So profitieren alle von dem Datenschatz der Graphdatenbank.

Konkret arbeiten wir daran, die Performance noch weiter zu verbessern. Gleichzeitig wollen wir neue Eventquellen erschließen, sodass wir den Graphen erweitern können, um unsere Regeln weiter zu verbessern. Unter Event verstehen wir, dass ein Prozess einen anderen startet oder ein Prozess eine Datei erzeugt. Dann sehen wir mehr, was die Schadsoftware anrichtet. Wir können noch nicht jede CPU-Instruktion beobachten, sondern erhalten Informationen von den Systemkomponenten auf Aktionsebene. Und je mehr Informationen wir haben, desto treffsicherer können wir unsere Regeln anpassen. Ansonsten haben wir noch ganz viele Ideen, denn BEAST bietet großes Potenzial.