Lösungen und Services

MalwareGuard: Maschinelles Lernen unterstützt die Erkennung und Abwehr von Malware

Wir bei FireEye haben uns das Ziel gesetzt, unsere Kunden und ihre Daten mit innovativen Technologien und den bei unseren Incident-Response-Einsätzen gesammelten Erfahrungen zu schützen. Mit FireEye Endpoint Security haben wir eines der ersten und erfolgreichsten Produkte auf dem Markt für die Bedrohungserkennung und ‑abwehr auf Endpunkten (Endpoint Detection and Response, EDR) entwickelt. Im Verlauf der letzten zwölf Monate haben wir die Funktionalität von Endpoint Security mit integriertem Antivirus-Schutz erheblich erweitert. Damit haben wir das Funktionsspektrum für die Malwareerkennung erweitert, das bereits ExploitGuard zur Erkennung von Verhaltensmustern und unsere Gefahrenindikatoren (Indicators of Compromise, IOC) enthielt.

Heute kommt eine weitere, auf maschinellem Lernen (ML) basierte Sicherheitsebene hinzu: MalwareGuard. Mit MalwareGuard werden Kunden in der Lage sein, Malware zu erkennen und ihre Ausführung zu verhindern. Das ist ein wichtiger Fortschritt, da konventionelle AV-Technologie neue Malware nicht erkennen kann.

MalwareGuard kann schon vor der Ausführung einer Windows-Datei einschätzen, ob diese schädlich ist oder nicht, und damit die Infiltration von Systemen verhindern. Um dieses neue Feature bestmöglich zu nutzen, werden wir MalwareGuard auch in Network Security und Email Security integrieren. Die statische Malwareerkennung mit dem neuen, auf maschinellem Lernen basierenden Modell wird die dynamische Analyse mit der MVX-Engine (Multi-Vector Virtual Execution) ergänzen, die wir bereits in Network Security und Email Security einsetzen. Mit dieser Kombination aus statischer und dynamischer Analyse steigern wir die Wahrscheinlichkeit, dass Malware erkannt und blockiert wird, bevor sie Schaden anrichten kann.

In diesem Blogpost erläutern wir, wie und warum wir diese zusätzliche Sicherheitsebene entwickelt haben.

Zielsetzung

Unsere Designziele für MalwareGuard waren:

  • Bislang kann FireEye Malware in portierbaren ausführbaren Windows-Dateien (Portable Executables, PE) erkennen und blockieren (z.B. EXE, DLL und SYS Dateien). PE-Dateien haben eine spezielle Struktur, die von Windows genutzt wird, um die zum Laden des ausführbaren Codes erforderlichen Informationen zu finden und auszulesen. PE ist zudem ein bei Malware-Autoren beliebtes Dateiformat, wie die VirusTotal-Grafik in Abbildung 1 zeigt.
  • Unser ML-Algorithmus sollte eine PE-Datei lesen und ermitteln, ob sie schädlich war oder nicht.
  • Die Prüfung jeder PE-Datei darf nur einen Sekundenbruchteil und so wenig Speicher- und CPU-Kapazität wie möglich in Anspruch nehmen, denn nur so können schädliche Dateien vor der Ausführung blockiert werden.
  • Das ML-Modell sollte Konfigurationsoptionen haben, mit denen die Nutzer einstellen können, wie „misstrauisch“ die Analyse sein sollte. Wir vermuten, dass die meisten Nutzer Fehlalarme weitgehend vermeiden wollen. Doch wir wollen auch Nutzer unterstützen, die über jede verdächtig wirkende Datei informiert werden wollen und bereit sind, dafür mehr Fehlalarme in Kauf zu nehmen.

FireEye ist sehr gut aufgestellt, diese Ziele erfolgreich umzusetzen. In unserer langjährigen Arbeit bei der Reaktion auf die schwerwiegendsten Cyberbedrohungen haben wir Malware aller Art gefunden, analysiert und gesammelt. Damit meinen wir nicht nur herkömmliche Malware, sondern auch speziell für gezielte und APT-Angriffe entwickelte Malware, die wir bei Incident-Response-Einsätzen von Mandiant gefunden haben. Auch die Experten im FireEye Labs Advanced Reverse Engineering Team (FLARE) haben uns mit ihren umfassenden Kenntnissen unterstützt. Durch die Kombination aus Erfahrung und Bedrohungsdaten hatten wir einen einzigartigen Datensatz für unseren ML-Algorithmus. Bei der Entwicklung des ML-Modells haben Datenwissenschaftler und Spezialisten für Malware Reverse Engineering eng zusammengearbeitet.


Abbildung 1: Anfragen auf VirusTotal in der Woche vom 6. Mai bis zum 13. Mai 2018. Erwähnenswert sind hier die Windows PE-Dateitypen Win32 EXE und Win32 DLL.

Entwicklung

Als Erstes haben wir die Datenbasis zusammengetragen und Pipelines für das Einspeisen von PE-Dateien und der dazugehörigen Metadaten entwickelt. Für den Datensatz mit schädlichen Dateien haben wir zahlreiche Malware-Beispiele aus internen und externen Quellen zusammengetragen, in denen seit vielen Jahren Malware gesammelt wird. Dabei konnten wir zwei wichtige FireEye-Ressourcen nutzen: Zuerst haben wir mit der MVX-Engine einen Teil der Malware identifiziert und zur späteren Erkennung markiert, und dann die Berichte des FLARE-Teams mit den darin enthaltenen Erkenntnissen unserer Reverse-Engineering-Spezialisten in unsere Wissensdatenbank eingespeist.

Als nächstes brauchten wir einen Datensatz mit unschädlichen Dateien. Das erwies sich als echte Herausforderung. Zuerst nahmen wir Dateien aus bekannten, vertrauenswürdigen Quellen in diesen Datensatz auf. Doch angesichts der Vielfalt unschädlicher PE-Dateien wurde uns bald klar, dass wir viel mehr Beispiele brauchten, um die unzähligen und sehr verschiedenen legitimen Dateien widerzuspiegeln, die in der Praxis genutzt werden. Inzwischen enthält dieser Datensatz über 300 Millionen Beispieldateien. Beim Trainieren eines Modells wird jede Datei in Abhängigkeit von ihrem Erstellungsdatum einer von drei Teilmengen zugeteilt: Die ältesten Dateien kommen in den Trainingsdatensatz, die nächstältesten in den Validierungsdatensatz und die neuesten in den Testdatensatz. Durch diese Aufteilung können wir besser einschätzen, wie zukunftsfähig unsere Modelle sind.

Im nächsten Schritt mussten wir entscheiden, wie die PE-Dateien dem ML-Algorithmus präsentiert werden sollten. Uns standen zwei Optionen zur Auswahl:

  1. Für den beim konventionellen maschinellen Lernen genutzten Ansatz mussten wir die PE-Dateien statisch analysieren, eine Reihe von Merkmalen auswählen und diese für jede Datei ermitteln und zur Analyse in den Algorithmus eingeben.
  2. Für den beim sogenannten „Deep Learning“ genutzten Ansatz mussten wir die Dateien ohne vorherige Aufbereitung in den Algorithmus eingeben.

Bei der Auswahl der Indikatoren und Dateieigenschaften für die erste Option haben wir eng mit den Experten von FLARE zusammengearbeitet und unter anderem die folgenden Merkmale ausgewählt:

  • die Informationsdichte der Textabschnitte in der PE-Datei (Entropie)
  • die Anzahl der Abschnitte per PE-Datei
  • die An- oder Abwesenheit bestimmter API-Aufrufe

Diese Merkmale lassen Rückschlüsse auf die Struktur und den Inhalt der jeweiligen Datei zu. Wenn die richtigen Merkmale ausgewählt werden, lässt sich so vielleicht auch zuverlässig einschätzen, ob die Datei schädlich ist oder nicht. Die schrittweise Auswahl der zu analysierenden Merkmale (oder „Features“) wird auch „Feature Engineering“ genannt. „Feature Engineering“ unterscheidet sich grundlegend von „Deep Learning“, dem zweiten Ansatz, den wir ausprobiert haben. In den Deep-Learning-Algorithmus wurden die PE-Dateien einfach nur Byte für Byte eingespeist, denn bei diesem Ansatz bleibt es dem Algorithmus überlassen, die Bytes so umzuwandeln, dass schädliche und unschädliche Dateien voneinander unterschieden werden können. In diesem Bereich wird derzeit sehr viel Forschung betrieben, und das nicht nur im Kontext der Informationssicherheit. Wir haben unsere diesbezüglichen Forschungsergebnisse im vergangenen Jahr auch auf einer Konferenz über angewandtes maschinelles Lernen präsentiert. Letztendlich konnten wir mit beiden Ansätzen Erfolge verzeichnen.

Als nächsten Schritt erstellten wir verschiedene Modelle für überwachtes maschinelles Lernen, darunter sogenannte „Random Forests“, „Gradient Boosted Trees“, neuronale Netze, und logistische Regressionsmodelle für die in KMU identifizierten Merkmale. Für den Deep-Learning-Algorithmus haben wir faltende und rekurrente neuronale Netze erstellt. In einem typischen Experiment wurde das Modell mit den PE-Dateien im Trainingsdatensatz geschult, dann wurde der Validierungsdatensatz für die Feinabstimmung der Hyperparameter des Modells genutzt und danach wurde das Modell auf den Testdatensatz angewandt und dabei die Anzahl der richtigen Einstufungen sowie die Anzahl der fälschlicherweise als schädlich eingestuften legitimen Dateien (Fehlalarme) und die Anzahl der als harmlos eingestuften schädlichen Dateien gezählt. Zum Vergleich der Ergebnisse der verschiedenen Modelle haben wir die Fläche unter der ROC-Kurve (AUC, Area Under the Curve) genutzt. Dieser AUC-Wert liegt zwischen 0 und 1. Ein Wert von 0 würde bedeuten, dass sämtliche Vorhersagen des Modells falsch waren. Ein Wert von 1 würde bedeuten, dass alle Vorhersagen korrekt waren. Unser bester Algorithmus für die Malware-Erkennung erreichte einen AUC-Wert von 0,9998. Einige der besten Modelle werden derzeit noch eingehender geprüft.

Interne Bewertung

In den letzten zwölf Monaten hat Mandiant mehrere vielversprechende Modelle bei seinen Incident-Response- und Managed Defense-Einsätzen getestet, um Leistungskennzahlen in der Praxis zu messen. Zudem haben wir einen internen Service eingerichtet, den FireEye-Teams zur Bewertung von PE-Dateien mithilfe der neuen ML-Modelle nutzen können. Bisher wurden über 20 Millionen neue PE-Dateien mit diesem Service geprüft. Das Nutzerfeedback für diesen Service war extrem nützlich und hat es uns ermöglicht, Lücken in unseren Datensätzen zu erkennen und zu schließen. Die genauere Untersuchung der falsch eingestuften Dateien lieferte wertvolle Hinweise für gezielte Verbesserungen im „Feature Engineering“. Das gehört bei der schrittweisen Entwicklung zuverlässiger ML-Modelle alles dazu. Der letzte Schritt der internen Bewertung war die Auswahl des ML-Modells, das in MalwareGuard genutzt werden sollte. Dazu zogen wir den AUC-Wert heran.

Während unserer internen Bewertung haben wir auch die Infrastruktur für die langfristige Überwachung und Wartung von MalwareGuard entwickelt. Wir haben von Anfang an geplant, die Leistung des Modells in Echtzeit zu überwachen, damit es erneut trainiert werden kann, falls seine Leistung unter einen bestimmten Grenzwert abfällt. Dazu haben wir für jede Phase des ML-Prozesses Data Pipelines entwickelt, sodass das System vollständig automatisiert werden kann.

Nächste Schritte


MalwareGuard wird Kunden mit FireEye Endpoint Security, Network Security und Email Security zugute kommen und die Erkennung von Malware (inklusive Zero-Day-Bedrohungen) erheblich verbessern. Insbesondere für Kunden mit Endpoint Security ist MalwareGuard eine wichtige Ergänzung unserer integrierten Defense-in-Depth-Lösung. Diese Lösung beinhaltet bereits Funktionen für die Erkennung von Gefahrenindikatoren (IOC), die signaturbasierte Malwareerkennung und ‑abwehr sowie ExploitGuard zum Erkennen und Blockieren verdächtiger Aktivitäten. Mit der auf maschinellem Lernen basierenden Bedrohungserkennung und ‑abwehr von MalwareGuard kommt eine weitere Sicherheitsebene dazu.

Wir freuen uns, unseren Kunden dieses starke Tool präsentieren zu können, werden aber natürlich weiterhin an der Optimierung von MalwareGuard arbeiten. Die Bedrohungslage ändert sich fortwährend und wir sind der Meinung, dass neue Malware sich mit ML-Algorithmen schneller erkennen und blockieren lässt als mit konventionellen, signaturbasierten Methoden.