DE112021004293T5

DE112021004293T5 - Mining und integration von kontextinformationen auf programmebene in low-level-systemprovenienzgraphen

Info

Publication number: DE112021004293T5
Application number: DE112021004293.9T
Authority: DE
Inventors: Xiao Yu; Haifeng Chen; Fei Zuo
Original assignee: NEC Laboratories America Inc
Current assignee: NEC Laboratories America Inc
Priority date: 2020-08-14
Filing date: 2021-08-11
Publication date: 2023-07-06
Also published as: WO2022035954A1; JP2023537815A; US11741220B2; US20220050895A1; JP7489495B2

Abstract

Es wird ein computerimplementiertes Verfahren zur Computereindringerkennung bereitgestellt. Das Verfahren enthält ein Erstellen (1010) einer Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen. Die Benutzerfunktionen laufen in einem Benutzerbereich eines Betriebssystems bzw. werden dort ausgeführt. Das Verfahren enthält weiterhin ein Identifizieren (1020), unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, irgendeiner bzw. jeder der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Das Verfahren enthält weiterhin ein Durchführen (1030), durch eine Prozessorvorrichtung, einer Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten. Der Provenienzgraph hat Knoten, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Kanten im Provenienzgraph haben Kantenbeschriftungen bzw. -labels, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.

Description

INFORMATION ÜBER VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht die Priorität der am 10. August 2021 eingereichten US-Patentanmeldung Nr. 17/398,514 und der am 14. August 2020 eingereichten vorläufigen US-Patentanmeldung Nr. 63/065,530 , die beide hierin in ihrer Gesamtheit durch Bezugnahme enthalten sind.
HINTERGRUND
Technisches Gebiet
Die vorliegende Erfindung betrifft ein Verarbeiten von Graphen und insbesondere Mining und Integration von Kontextinformationen auf Programmebene in Low-Level-Provenienzgraphen.
Beschreibung des zugehörigen Standes der Technik
Ein Erfassen und Verstehen von Programm- und Systemverhalten ist eine übliche Aufgabe, die viele Anwendungen in den Bereichen von Systemsicherheit, Wartung, Überwachung und Management hat. Eine hochmoderne Praxis, um diese Aufgabe zu erledigen, erfolgt durch Erfassen und Verarbeiten bzw. Aufschließen von Systemaufrufen auf niedriger Ebene. Solche Systemaufrufe sind die Mittel, die ein Benutzerprogramm für Betriebssystemdienste aufrufen kann, wie beispielsweise ein Lesen einer Datei auf der Festplatte, und sie spiegeln direkt Interaktionen mit dem Betriebssystem oder externe Verhaltensweisen wider, die ein Programm zur Laufzeit zeigt. Moderne Betriebssysteme verfügen in der Regel über integrierte Mechanismen für eine Erfassung von Systemaufrufen, z.B. Audit bei Linux und Event Tracing for Windows (ETW) bei Windows®, wodurch diese Vorgehensweise einfach allgemein und programmunabhängig implementiert werden kann. Die erfassten Systemaufrufdaten ermöglichen eine Reihe von Anwendungen.
Im Laufe der Jahre hat es Fortschritte beim Anreichern von Systemaufrufdaten gegeben, um anspruchsvollere Anwendungen zu unterstützen. Eine „horizontale“ Anreicherung besteht insbesondere darin, Provenienzgraphen aus Low-Level-Systemaufrufdaten zu erstellen, um eine ganzheitliche Sicht auf Programm- und Systemverhaltensweisen und ihre Interaktionen zu bieten. In Provenienzgraphen kann ein Knoten bei unterschiedlichen Ausführungsformen solcher Graphen ein Prozess (eine Laufzeitinstanz eines Programms), eine Datei, ein Netzwerk-Endpunkt oder auf andere Weise definiert sein; und Kanten sind Systemaufruf- und Zeitstempel-Labels bzw. Beschriftungen, die sich auf die Knoten beziehen, z.B. „ein Prozess schreibt eine Datei“ würde in einem Prozessknoten und einem Dateiknoten resultieren, die durch eine Schreib-Kante mit dem Zeitstempel von dieser Schreiboperation verbunden sind; und auf ähnliche Weise „ein Prozess startet einen anderen Prozess“ in zwei Prozessknoten mit einer Start-Kante. Mit unterschiedlichen Knoten und Kanten sollen solche Graphen scheinbar getrennte Systemaufrufdaten über Zeit und Prozesse hinweg „horizontal“ miteinander verbinden. Anwendungen, die auf Provenienzgraphen basieren, arbeiten in einigen Szenarien effektiver als diejenigen, die rohe Systemaufrufdaten verwenden. Zum Beispiel kann eine Eindringerkennung unter Verwendung von Graphen mehr Kontextinformationen (d.h. benachbarte Knoten und Kanten in einem Graphen) enthalten, um zwischen ungewöhnlichen Systemaufrufen, die lediglich Ausreißer sind, und echten Bedrohungen zu unterscheiden.
Während sich die graphenbasierte „horizontale“ Anreicherung in einigen Szenarien als effektiv erwiesen hat, leidet sie unter Herausforderungen sowohl bei einer Graphenkonstruktion als auch bei weiterer Anreicherung von Kontextinformationen auf hoher Ebene. In einer Graphenkonstruktion kann ein Umwandeln von Systemaufrufdaten in Graphen ohne richtiges Beschneiden bzw. Pruning in dem Problem von sogenannter „Abhängigkeitsexplosion“ resultieren, was bedeutet, dass sowohl relevante als auch irrelevante Knoten und Kanten zusammengefügt und verbunden werden, was zu einer großen Graphengröße sowie zu Rauschen führt, was die darauf aufbauenden Anwendungen stört. Das Beschneiden von Knoten und Kanten ist oft auch schwierig, da es keine Kontextinformationen auf hoher Ebene (Programmebene) als definitive Anleitung gibt. Das Beschneiden erfolgt normalerweise mit angenäherten Abhängigkeiten basierend auf Zeitnähe unter Verwendung von Zeitstempeln oder bestimmten sich wiederholenden Graphenmustern. Sollten Kontextinformationen auf hoher Ebene einbezogen werden, wäre das Beschneiden effektiver mit substanziellen Beweisen für echte Abhängigkeiten im Programm. Das führt natürlich zur zweiten Herausforderung, Provenienzgraphen mit High-Level-Kontextinformationen weiter anzureichern. Die aktuelle Graphenkonstruktion basiert ausschließlich auf Low-Level-Systemaufrufdaten, was die konstruierten Graphen im Wesentlichen darauf beschränkt, nur Low-Level-Verhalten aufzudecken. Es ist nicht einfach, High-Level-Informationen in diesen Prozess zu integrieren, da es keine bereits vorhandene Abbildung von Low-Level-Systemaufrufen auf High-Level-Programmlogik gibt. Ein Erstellen dieser Abbildung würde entweder eine umfangreiche Programmausstattung erfordern, die von realen Systemeinsätzen stark missbilligt wird, oder Unsicherheiten und Ungenauigkeiten einführen, wenn es auf andere Weise mit anderen vorhandenen Methoden durchgeführt wird.
ZUSAMMENFASSUNG
Gemäß einem Aspekt der vorliegenden Erfindung wird ein computerimplementiertes Verfahren zur Computereindringerkennung bereitgestellt. Das Verfahren enthält ein Erstellen einer Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen. Die Benutzerfunktionen laufen in einem Benutzerbereich eines Betriebssystems bzw. werden dort ausgeführt. Das Verfahren enthält weiterhin, unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, ein Identifizieren von jeder bzw. irgendeiner der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Das Verfahren enthält weiterhin ein Durchführen, durch eine Prozessorvorrichtung, einer Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten. Der Provenienzgraph hat Knoten, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Kanten im Provenienzgraphen haben Kanten-Labels bzw. -Beschriftungen, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.
Gemäß anderen Aspekten der vorliegenden Erfindung wird ein Computerprogrammprodukt zur Computereindringerkennung bereitgestellt. Das Computerprogrammprodukt enthält ein nichtflüchtiges computerlesbares Speichermedium mit damit verkörperten Programmanweisungen. Die Programmanweisungen sind durch einen Computer ausführbar, um zu veranlassen, dass der Computer ein Verfahren durchführt. Das Verfahren enthält ein Erstellen, durch eine Prozessorvorrichtung des Computers, einer Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen. Die Benutzerfunktionen laufen in einem Benutzerbereich eines Betriebssystems bzw. werden dort ausgeführt. Das Verfahren enthält weiterhin, durch die Prozessorvorrichtung unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, ein Identifizieren von jeder bzw. irgendeiner der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Das Verfahren enthält auch ein Durchführen, durch die Prozessorvorrichtung, einer Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten. Der Provenienzgraph hat Knoten, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Kanten im Provenienzgraphen haben Kanten-Labels bzw. -Beschriftungen, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.
Gemäß noch anderen Aspekten der vorliegenden Erfindung wird ein Computerverarbeitungssystem zur Computereindringerkennung bereitgestellt. Das Computerverarbeitungssystem enthält eine Speichervorrichtung zum Speichern von Programmcode. Das Computerverarbeitungssystem enthält weiterhin einen Hardwareprozessor, der operativ mit der Speichervorrichtung gekoppelt ist, zum Ausführen des Programmcodes, um eine Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen zu erstellen. Die Benutzerfunktionen laufen in einem Benutzerbereich eines Betriebssystems bzw. werden dort ausgeführt. Der Hardwareprozessor führt weiterhin den Programmcode aus, um unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, jede bzw. irgendeine von Benutzerfunktionen zu identifizieren, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen.
Der Hardwareprozessor führt auch den Programmcode aus, um eine Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten durchzuführen. Der Provenienzgraph hat Knoten, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen. Kanten im Provenienzgraphen haben Kanten-Labels bzw. -Beschriftungen, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.
Diese und andere Merkmale und Vorteile werden aus der folgenden detaillierten Beschreibung illustrativer Ausführungsformen davon offensichtlich werden, die in Verbindung mit den beigefügten Zeichnungen zu lesen ist.
Figurenliste
Die Offenbarung wird Details in der folgenden Beschreibung bevorzugter Ausführungsformen unter Bezugnahme auf die folgenden Figuren bereitstellen, wobei:

1 ein Blockdiagramm, das eine beispielhafte Computervorrichtung zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
2 ein Flussdiagramm, das einen beispielhaften System-Arbeitsablauf zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
3 ein Blockdiagramm, das einen beispielhaften Provenienzgraphen mit Informationsanreicherung auf Programmebene 388 zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
4 ein Flussdiagramm für ein Verfahren zum Extrahieren von Information aus Programm-Binärdateien für einen späteren Suchschritt gemäß einer Ausführungsform der vorliegenden Erfindung ist;
5 ein Kontrollflussgraph (CFG (= Control-Flow Graph)) gemäß einer Ausführungsform der vorliegenden Erfindung ist;
6 ein Blockdiagramm ist, das ein Beispiel eines aus dem in 5 gezeigten CFG reduzierten Funktionsaufrufgraphen zeigt;
7 ein Flussdiagramm für eine Systemaufruf-zu-Benutzerfunktion-Suche gemäß einer Ausführungsform der vorliegenden Erfindung ist;
8 ein Blockdiagramm, das ein Beispiel einer Kandidatensuche und eines Auswahlblocks 750 der 7 zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
9 ein Flussdiagramm, das einen beispielhaften Provenienzgraphen-Erstellungsprozess mit durch den Block 250 der 2 angereicherten Systemaufrufverfolgungen zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung ist; und
10 ein Flussdiagramm, das ein beispielhaftes High-Level-Verfahren bzw. Verfahren auf hoher Ebene zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung ist.

DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
Ausführungsformen der vorliegenden Erfindung sind auf Mining und Integration von Kontextinformationen auf Programmebene in Low-Level-Provenienzgraphen gerichtet.
Ausführungsformen der vorliegenden Erfindung sind so konfiguriert, dass sie Informationen auf Programmebene mit Low-Level-Systemaufrufdaten integrieren, um eine „vertikale“ Anreicherung für Provenienzgraphen zu erreichen. Anstelle eines Durchführens umfangreicher Programminstrumentierung oder komplexer Programmanalyse, um eine genaue Abbildung zwischen unterschiedlichen Informationsebenen zu erhalten, verwenden Ausführungsformen der vorliegenden Erfindung eine leichte binäre Analyse und datengesteuerte Techniken, um das Problem auf ein Suchproblem zu reduzieren.
Bei einer Ausführungsform kann die vorliegende Erfindung die folgenden zwei Komponenten einer obersten Ebene enthalten: (1) ein Verfahren zum Erstellen einer Abbildung von Low-Level-Systemaufrufen auf Benutzerfunktionen (die sich auf Funktionen beziehen, die eher im Benutzerbereich als im Kernelbereich des Betriebssystems ausgeführt werden) in einzelnen Programmen; und (2) einen Suchalgorithmus, der die erstellte Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung verwendet, um Benutzerfunktionen zu identifizieren, die die erfassten Low-Level-Systemaufrufe bei der Verfolgung auslösen.
Um die Abbildung zu erstellen, führt die Erfindung eine binäre Analyse und Maschinenlernen an Benutzerprogrammen von Interesse in drei Schritten durch, um (1) Kontrollflussgraphen (CFGs) aus einzelnen Benutzerfunktionen zu extrahieren und CFG-Knoten zu identifizieren, die entweder Systemaufrufe auslösen oder Funktionsaufrufe zu anderen Benutzerfunktionen machen; (2) Graphen-Spaziergänge bzw. -Durchläufe durch die identifizierten einen Systemaufruf auslösenden Knoten auf jedem Benutzerfunktions-CFG und allen relevanten CFGs durchzuführen, die durch Funktionsaufrufe zugehörig bzw. verbunden sind, um eine Systemaufrufsequenz zu erzeugen und zu sammeln, die die Funktion auslösen kann; (3) unter Verwendung der gesammelten Sequenzen ein Systemaufrufsequenz-Einbettungsmodell zu trainieren, das eine Systemaufrufsequenz in eine Vektorraumdarstellung umwandeln bzw. konvertieren kann.
Eine Ausführungsform eines Suchalgorithmus gemäß der vorliegenden Erfindung enthält die folgenden drei Hauptkomponenten: (1) ein heuristisches Verfahren, um eine eingegebene Systemaufrufverfolgung zu segmentieren, um den Suchraum für eine Identifizierung von Benutzerfunktionen zu reduzieren; (2) ein Suchverfahren, das das Einbettungsmodell, von den CFGs gesammelte Systemaufrufsequenzen und eine Gruppe von Heuristiken nutzt, um Kandidaten möglicher Benutzerfunktionen innerhalb eines Segments der eingegebenen Systemaufrufverfolgung einzeln zu benennen; (3) eine Qualitätsmessfunktion, um unterschiedliche Kandidaten zu vergleichen und den (die) wahrscheinlichsten Kandidaten als Suchergebnis auszuwählen.
Im Lösungsbereich beruhen Ausführungsformen der vorliegenden Erfindung auf viel weniger Annahmen über einen Systemeinsatz und unterstützende Komponenten, um das Ziel zu erreichen, verglichen mit möglichen Techniken des Standes der Technik, die zur Lösung desselben Problems angewendet werden können. Insbesondere beruht die Erfindung nicht auf schweren Laufzeitinstrumenten oder einer komplexen Programmanalyse, die zwei gängige Techniken darstellen, die angewendet werden können, um ebenenübergreifende Informationen auf exakte Weise zu sammeln und zu integrieren. Diese gängigen Techniken würden Änderungen am Zielsystem einführen, die von Kunden nicht bevorzugt werden, einen Laufzeit-Overhead verursachen, der sich negativ auf eine Systemleistung auswirkt, und den Skalierbarkeitsherausforderungen komplexer Programme und Systeme erliegen, die untersucht werden.
Stattdessen reduzieren Ausführungsformen der vorliegenden Erfindung das Problem auf ein Suchproblem und lösen es, indem sie ein Systemaufrufsequenz-Einbettungsmodell und einen Suchalgorithmus mit einem Systemaufrufverfolger als beim Zielsystem eingesetzte einzelne Komponente kombinieren. Die Erstellung des Einbettungsmodells verwendet nur eine minimale binäre Analyse, um CFGs auf Funktionsebene zu extrahieren, und abstrahiert dann komplexe Programmlogik in Systemaufrufsequenzen, die später vom Suchalgorithmus verwendet werden, um eine Ähnlichkeitssuche durchzuführen. Als Ergebnis ersetzt das Einbettungsmodell effektiv eine komplexe Programmanalyse, die versuchen würde, genau machbare Systemaufrufsequenzen durch Lösen einer Pfaderfüllbarkeit zu bekommen, aber nicht gut auf große Programme skalieren würde.
Durch Verwenden eines Suchalgorithmus zum „Durchsuchen“ wahrscheinlicher Benutzerfunktionen entsprechend Low-Level-Systemaufrufen beseitigen Ausführungsformen der vorliegenden Erfindung auch effektiv die Notwendigkeit einer Laufzeitinstrumentierung, die jedes Programm zur Laufzeit instrumentieren und jedes Mal dann, wenn ein Systemaufruf ausgelöst wird, einen vollständigen Aufrufstapel (einschließlich Benutzerfunktionsnamen) erfassen würde, was zu einem erheblichen Leistungsaufwand führt.
1 ist ein Blockdiagramm, das eine beispielhafte Computing- bzw. Computer- bzw. Rechenvorrichtung 100 zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Die Rechenvorrichtung 100 ist für Mining und Integration von Kontextinformationen auf Programmebene in Low-Level-System-Provenienzgraphen konfiguriert.
Die Computing- bzw. Rechenvorrichtung 100 kann als irgendein Typ von Berechnungs- oder Computervorrichtung verkörpert sein, die die hierin beschriebenen Funktionen durchführen kann, einschließlich, ohne Beschränkung, eines Computers, eines Servers, eines auf einem Rack basierenden Servers, eines Blade-Servers, einer Workstation, eines Desktop-Computers, eines Laptop-Computers, eines Notebook-Computers, eines Tablet-Computers, einer mobilen Computingvorrichtung, einer tragbaren Computingvorrichtung, eines Netzwerkgeräts, eines Webgeräts, eines verteilten Computingsystems, eines prozessorbasierten Systems und/oder einer Unterhaltungselektronikvorrichtung. Zusätzlich oder alternativ kann die Computingvorrichtung 100 als ein oder mehrere Rechenschlitten, Speicherschlitten oder andere Racks, Schlitten, Computing-Gehäuse oder andere Komponenten einer physikalisch disaggregierten Computingvorrichtung verkörpert sein. Wie es in 1 gezeigt ist, enthält die Computingvorrichtung 100 illustrativ den Prozessor 110, ein Eingabe-/Ausgabe-Untersystem 120, einen Speicher 130, eine Datenspeichervorrichtung 140 und ein Kommunikations-Untersystem 150 und/oder andere Komponenten und Vorrichtungen, die üblicherweise in einem Server oder einer ähnlichen Computingvorrichtung zu finden sind. Natürlich kann die Computingvorrichtung 100 bei anderen Ausführungsformen andere oder zusätzliche Komponenten enthalten, wie beispielsweise diejenigen, die üblicherweise in einem Servercomputer zu finden sind (z.B. verschiedene Eingabe-/Ausgabe-Vorrichtungen). Zusätzlich kann oder können bei einigen Ausführungsformen eine oder mehrere der illustrativen Komponenten in eine andere Komponente eingebaut sein oder anderweitig einen Teilbereich davon bilden. Zum Beispiel kann der Speicher 130, oder können Teilbereiche davon, bei einigen Ausführungsformen im Prozessor 110 eingebaut sein.
Der Prozessor 110 kann als irgendein Typ von Prozessor verkörpert sein, der die hierin beschriebenen Funktionen durchführen kann. Der Prozessor 110 kann als einzelner Prozessor, mehrere Prozessoren, zentrale Verarbeitungseinheit(en) (CPU(s)), Grafikverarbeitungseinheit(en) (GPU(s)), Einzel- oder Mehrkern-prozessor(en), Digitalsignalprozessor(en), Mikrosteuerung(en) oder anderer Prozessor (andere Prozessoren) oder Verarbeitungs-/Steuerungs-Schaltung(en) verkörpert sein.
Der Speicher 130 kann als irgendein Typ von flüchtigem oder nichtflüchtigem Speicher oder Datenspeicher verkörpert sein, der die hierin beschriebenen Funktionen durchführen kann. Im Betrieb kann der Speicher 130 verschiedene Daten und Software speichern, die während des Betriebs bzw. einer Operation der Computingvorrichtung 100, wie beispielsweise von Betriebssystemen, Anwendungen, Programmen, Bibliotheken und Treibern, verwendet werden. Der Speicher 130 ist kommunikativ mit dem Prozessor 110 über das I/O-Untersystem 120 gekoppelt, das als Schaltung und/oder Komponenten verkörpert sein kann, um Eingabe-/Ausgabe-Operationen mit dem Prozessor 110, dem Speicher 130 und anderen Komponenten der Computingvorrichtung 100 zu ermöglichen. Zum Beispiel kann das I/O-Untersystem 120 als Speichersteuerungs-Hubs, Eingabe-/Ausgabe-Steuerungs-Hubs, Plattformsteuerungs-Hubs, integrierte Steuerschaltung, Firmware-Vorrichtungen, Kommunikationsverbindungen (z.B. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen der Leiterplatten etc.) und/oder andere Komponenten und Untersysteme verkörpert sein oder diese anderweitig enthalten, um die Eingabe-/Ausgabe-Operationen zu ermöglichen bzw. zu erleichtern. Bei einigen Ausführungsformen kann das I/O-Untersystem 120 einen Teilbereich eines Systems auf einem Chip (SOC (= System-On-a-Chip)) bilden und zusammen mit dem Prozessor 110, dem Speicher 130 und anderen Komponenten der Computingvorrichtung 100 auf einem einzigen integrierten Schaltungschip eingebaut sein.
Die Datenspeichervorrichtung 140 kann als irgendein Typ von Vorrichtung oder Vorrichtungen verkörpert sein, die für die kurzfristige oder langfristige Speicherung von Daten konfiguriert ist oder sind, wie zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeichervorrichtungen. Die Datenspeichervorrichtung 140 kann einen Programmcode für Mining und Integration von Kontextinformationen auf Programmebene in Low-Level-System-Provenienzgraphen speichern. Das Kommunikations-Subsystem 150 der Computingvorrichtung 100 kann als irgendeine Netzwerkschnittstellensteuerung oder irgendeine andere Kommunikationsschaltung, -vorrichtung oder -sammlung bzw. -kollektion davon verkörpert sein, die Kommunikationen zwischen der Computingvorrichtung 100 und anderen entfernten Geräten bzw. Vorrichtungen über ein Netzwerk ermöglichen bzw. freigeben kann. Das Kommunikations-Subsystem bzw. -Untersystem 150 kann konfiguriert sein, um irgendeine oder mehrere Kommunikationstechnologien (z.B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte bzw. zugehörige Protokolle (z.B. Ethernet, InfiniBand®, Bluetooth®, Wi-Fi®, WiMAX usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
Wie es gezeigt ist, kann die Computingvorrichtung 100 auch eine oder mehrere periphere Vorrichtungen 160 enthalten. Die peripheren Vorrichtungen 160 können irgendeine Anzahl zusätzlicher Eingabe-/Ausgabe-Vorrichtungen, Schnittstellenvorrichtungen und/oder anderer peripherer Vorrichtungen enthalten. Zum Beispiel können die peripheren Vorrichtungen 160 bei einigen Ausführungsformen eine Anzeige, einen Berührungsbildschirm, eine Grafikschaltung, eine Tastatur, eine Maus, ein Lautsprechersystem, ein Mikrofon, eine Netzwerkschnittstelle und/oder andere Eingabe-/Ausgabe-Vorrichtungen, Schnittstellenvorrichtungen und/oder periphere Vorrichtungen enthalten.
Natürlich kann die Computingvorrichtung 100 auch andere Elemente (nicht gezeigt) enthalten, wie es von einem Fachmann auf dem Gebiet leicht in Betracht gezogen wird, sowie bestimmte Elemente weglassen. Zum Beispiel können verschiedene andere Eingabevorrichtungen und/oder Ausgabevorrichtungen in der Computingvorrichtung 100 enthalten sein, und zwar abhängig von der bestimmten Implementierung derselben, wie es von einem Fachmann auf dem Gebiet leicht verstanden wird. Zum Beispiel können verschiedene Typen von drahtlosen und/oder drahtgebundenen Eingabe- und/oder Ausgabevorrichtungen verwendet werden. Darüber hinaus können zusätzliche Prozessoren, Steuerungen, Speicher und so weiter bei verschiedenen Konfigurationen auch verwendet werden. Diese und andere Variationen des Verarbeitungssystems 100 werden angesichts der hierin bereitgestellten Lehren der vorliegenden Erfindung von einem Fachmann auf dem Gebiet leicht in Betracht gezogen.
Wie er hierin verwendet wird, kann sich der Begriff „Hardwareprozessor-Untersystem“ oder „Hardwareprozessor“ auf einen Prozessor, einen Speicher (einschließlich RAM, Cache(s) und so weiter), Software (einschließlich Speichermanagementsoftware) oder Kombinationen davon beziehen, die zusammenarbeiten, um eine oder mehrere spezifische Aufgaben durchzuführen. Bei nützlichen Ausführungsformen kann das Hardwareprozessor-Untersystem ein oder mehrere Datenverarbeitungselemente (z.B. Logikschaltungen, Verarbeitungsschaltungen, Anweisungsausführungsvorrichtungen etc.) enthalten. Das eine oder die mehreren Datenverarbeitungselemente kann oder können in einer zentralen Verarbeitungseinheit, einer Grafikverarbeitungseinheit und/oder einer separaten prozessor- oder computingelementbasierten Steuerung (z.B. Logikgatter etc.) enthalten sein. Das Hardwareprozessor-Untersystem kann einen oder mehrere integrierte Speicher bzw. Onboard-Speicher (z.B. Caches, bestimmte bzw. dedizierte Speicherarrays, einen Nurlesespeicher etc.) enthalten. Bei einigen Ausführungsformen kann das Hardwareprozessor-Untersystem einen oder mehrere Speicher enthalten, die onboard oder offboard sein können oder die zur Verwendung durch das Hardwareprozessor-Untersystem bestimmt bzw. dediziert sein können (z.B. ROM, RAM, BIOS (Basic Input/Output System (= Grundlegendes Eingabe-/Ausgabe-System)) etc.).
Bei einigen Ausführungsformen kann das Hardwareprozessor-Untersystem ein oder mehrere Softwareelemente enthalten und ausführen. Das eine oder die mehreren Softwareelemente kann oder können ein Betriebssystem und/oder eine oder mehrere Anwendungen und/oder einen spezifischen Code enthalten, um ein spezifiziertes bzw. bestimmtes Ergebnis zu erreichen.
Bei anderen Ausführungsformen kann das Hardwareprozessor-Untersystem eine dedizierte, spezialisierte Schaltung enthalten, die eine oder mehrere elektronische Verarbeitungsfunktionen durchführt, um ein bestimmtes Ergebnis zu erreichen. Eine solche Schaltung kann eine oder mehrere anwendungsspezifische integrierte Schaltungen (ASICs), FPGAs und/oder PLAs enthalten.
Diese und andere Variationen eines Hardwareprozessor-Untersystems werden gemäß Ausführungsformen der vorliegenden Erfindung auch in Betracht gezogen.
2 ist ein Flussdiagramm, das einen beispielhaften Systemarbeitsablauf 200 zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung.
Der Systemarbeitsablauf 200 enthält die folgenden Blöcke: Programm-binärdateien 210; binäre Analyse und Systemaufruf-Abbildungs-Lernen 220; Systemaufrufsequenz-Korpusse und Einbettungsmodelle 230; Systemaufrufverfolgungen 240; Systemaufruf-zu-Benutzerfunktion-Suche 250; Systemaufrufverfolgungen, angereichert mit Benutzerfunktionsinformationen 260; Provenienzgraphen-Konstruktion 270; und Provenienzgraphen, angereichert mit Benutzerfunktionsinformationen.
Eine Programmbinärdatei 210 ist eine physische Datei, die Metadaten und Anweisungen enthält, die für ein Computersystem nötig sind, um das Programm auszuführen. Programmbinärdateien sind die erforderliche Eingabe des Systems der vorliegenden Erfindung, da das System auf Informationen beruht, die aus einer oder mehreren Programmbinärdateien extrahiert sind, um Systemaufrufverfolgungen anzureichern. Nur diejenigen Laufzeit-Systemaufrufverfolgungen von Prozessen, deren Programmbinärdateien vom System analysiert werden, können angereichert werden.
Der Block binäre Analyse and Systemaufruf-Abbildung-Lernen 220 führt eine Analyse der Binärdateien des Eingabeprogramms durch und extrahiert Systemaufruf- und Benutzerfunktionsinformationen. Insbesondere erzeugt es für jede in den Programmbinärdateien identifizierte Benutzerfunktion einen Systemaufrufsequenz-Korpus. Ein solcher Korpus stellt die möglichen Systemaufrufsequenz-Muster für jede Benutzerfunktion dar. Unter Verwendung von Korpussen aus allen analysierten Benutzerfunktionen trainiert der Block 220 ein Einbettungsmodell, das eine Systemaufrufsequenz in eine Vektorraumdarstellung konvertieren kann. Darüber hinaus sammelt der Block 220 auch Aufrufbeziehungen zwischen Benutzerfunktionen für nachgelagerte Schritte.
Systemaufrufsequenz-Korpusse und Einbettungsmodelle 230 sind die wichtigsten Ergebnisse der binären Analyse und des Systemaufruf-Abbildung-Lernens 220. Für jede in einer Programmbinärdatei identifizierte Benutzerfunktion erzeugt 220 einen Korpus einschließlich einiger möglicher Systemaufrufsequenzen, die das Ergebnis eines Ausführens der Funktion sein können. Systemaufrufsequenzen im Korpus können von unterschiedlicher Länge sein, dürfen aber eine vordefinierte maximale Länge nicht überschreiten. Ein Beispiel für eine Systemaufrufsequenz könnte „getsockname sendto recvmsg recvmsg“ sein, die einem Satz in natürlicher Sprache ähnelt, während jedes Wort im Satz der Name eines Systemaufrufs ist, der durch das zugrunde liegende Betriebssystem vordefiniert ist. Ein Einbettungsmodell kann eine solche Systemaufrufsequenz in einen Vektor fester Länge konvertieren, der die Sequenz in einem mathematischen Raum für Berechnungen eines Abstands zwischen unterschiedlichen Sequenzen darstellt.
Systemaufrufverfolgungen 240 sind die Eingabe, für die das System versucht, sie mit Informationen auf Programmebene anzureichern. Typischerweise können solche Verfolgungen durch vorhandene Mechanismen in modernen Betriebssystemen und unterstützenden Tools von Drittanbietern, wie beispielsweise sysdig, erhalten werden. Bei einer Systemaufrufverfolgung enthält jeder Eintrag typischerweise Informationen bezüglich des Systemaufrufs, der gerade aufgerufen ist, des aufrufenden Prozesses und Threads sowie Argumenten, die zum Systemaufruf übergeben werden und einen Wert von diesem zurückbringen. Das System der vorliegenden Erfindung geht davon aus, dass die eingegebenen Verfolgungen durch Prozess und Thread getrennt sind, weshalb jede Verfolgung nur Systemaufrufinformationen von einem einzelnen Thread eines einzelnen Prozesses ohne Verflechtung enthalten wird.
In Bezug auf ein Systemaufruf-zu-Benutzerfunktion-Suche 250, für jede Systemaufrufverfolgung führt der Block 250 mehrere und iterative Suchen durch, die einige Segmente der Ablaufverfolgung bzw. Verfolgung als Abfragen über die durch 220 extrahierten und erzeugten Informationen verwenden. Während der Suchen nutzt der Block 250 die Einbettungsmodelle aus dem Block 220, um Systemaufrufabfragen in Vektordarstellungen umzuwandeln bzw. zu konvertieren, und führt Ähnlichkeitssuchen im Einbettungsraum durch, um ähnliche Systemaufrufsequenzen in einigen im Block 220 erzeugten Korpussen zu identifizieren. Da solche ähnlichen Sequenzen von einigen Benutzerfunktionen gesammelt werden, betrachtet unser System diese Funktionen als wahrscheinliche Quellen von Systemaufrufen bei der Verfolgung. Der Block 250 enthält auch einige Heuristiken, um den Suchumfang einzugrenzen, um präzisere Benutzerfunktionen zu bekommen. Nach den Suchen identifiziert der Block 250 die wahrscheinlichsten Benutzerfunktionen, die einige Segmente von Systemaufrufen bei der Verfolgung auslösen.
Systemaufrufverfolgungen, angereichert mit Benutzerfunktionsinformationen, 260 ist die Ausgabe vom Block 250, die die eingegebenen Systemaufrufverfolgungen mit Benutzerfunktionsinformationen anreichert. Insbesondere werden die ursprünglichen Systemaufrufverfolgungen in Segmente aufgeteilt, von denen jedes von derselben Benutzerfunktion stammen kann und von denen jedes mit der (den) wahrscheinlichen Benutzerfunktion(en) bezeichnet ist. Zum Beispiel kann das vorgenannte Beispiel einer Systemaufrufsequenz „getsockname sendto recvmsg recvmsg recvmsg“ durch den Block 250 als wahrscheinlich aus der Funktion getaddrinfo in der Programmbinärdatei libc.so.6 von einem typischen Linux-System identifiziert werden. In einigen Fällen kann die Bezeichnung bzw. das Label eine Vielzahl wahrscheinlicher Benutzerfunktionen enthalten.
Die Provenienzgraphen-Konstruktion 270 verwendet einige Systemaufrufverfolgungen als Eingabe und konstruiert einen Provenienzgraphen durch iteratives Hinzufügen von Knoten und Kanten, die Systementitäten (z.B. Prozesse, Dateien, Sockets und andere) und durch bestimmte Systemaufrufe reflektierte Entitätsbeziehungen (z.B. ein Prozess liest eine Datei) darstellen. Dieser Prozess startet von bestimmten benutzerdefinierten Entitäten, wie beispielsweise einigen Dateien von Interesse, und identifiziert iterativ andere Entitäten, die über Systemaufrufe mit den bereits im Graphen enthaltenen Entitäten assoziiert sein können. Obwohl diese Graphen-Konstruktion nicht Teil der vorliegenden Erfindung ist, wird sie durch Informationen auf Programmebene erweitert, die durch das ursprüngliche Verfahren in dieser Erfindung für Systemaufrufe bezeichnet sind, was in angereicherten Graphen resultiert.
Eine Beschreibung wird nun in Bezug auf Provenienzgraphen, die mit Benutzerfunktionsinformationen angereichert sind, gemäß einer Ausführungsform der vorliegenden Erfindung gegeben.
3 ist ein Blockdiagramm, das einen beispielhaften Provenienzgraphen 300 mit Informationsanreicherung auf Programmebene 388 zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung.
Wie es hierin verwendet ist, bezieht sich „Informationen auf Programmebene“ auf Informationen auf hoher Ebene bzw. High-Level-Informationen, wie beispielsweise Namen von Benutzerfunktionen und Bibliotheken/binären Objekten, die die gesammelten und gezeigten Systemaufrufe auslösten.
Der Graph stellt einen Prozess dar, der aus zwei Sockets liest und zu diesen schreibt. Wenn man verstehen würde, ob es irgendeinen Unterschied zwischen den zwei Sockets und den mit ihnen verbundenen Operationen geben würde, oder eine auf Provenienz basierende Anwendung bestimmen müsste, ob die zwei Sockets alle normal wären oder einer von ihnen abnormal wäre, wäre ein sich Verlassen ausschließlich auf den Provenienzgraphen ohne die Benutzerfunktionsinformationen („Im Kontext von getaddrinfo@libc.so.6“) 388 nicht ausreichend, da es keinen Indikator gibt, um die beiden zu unterscheiden. Andererseits enthält die Benutzerfunktionsinformation 388 eine zusätzliche Bezeichnung bzw. ein zusätzliches Label, die bzw. das aus angereicherten Systemaufrufverfolgungen konstruiert bzw. erstellt wurde, die zeigen, dass einer der Sockets und seine zugehörigen Operationen im Kontext der Funktion getaddrinfo sind, von der bekannt ist, dass sie „Domänennamen, Hostnamen und IP-Adressen zwischen menschenlesbaren Textdarstellungen und strukturierten Binärformaten für die Netzwerk-API des Betriebssystems konvertiert“. Mit diesem Stück von High-Level-Informationen (Informationen auf Programmebene) kann man die reale Programmsemantik von Low-Level-Socket-Operationen bestimmen, wodurch effektiv mehr Kontextinformationen in den Verständnis- und Entscheidungsprozess auf dem Provenienzgraphen integriert wird. Darüber hinaus kann der Graph mit diesen Funktionsinformationen 388 sogar komprimiert werden, indem die zwei Kanten zwischen P1 und Socket1 zusammengeführt werden, um die Größe des Graphen zu reduzieren. Es soll der Beispielgraph 300 in 3 betrachtet werden. Ein solcher Low-Level-Provenienzgraph hat Kanten, die durch Systemaufrufe bezeichnet sind. Wenn ein Prozess sehr aktiv wäre, würde der Graph sehr groß sein und viele Kanten enthalten, von denen jede einem Systemaufruf entspricht. Wie es bereits demonstriert ist, können mehrere Systemaufrufe durch eine einzige Benutzerfunktion ausgelöst werden. Daher können Benutzerfunktionen ihre ausgelösten Systemaufrufe (d.h. Kanten des Graphen) effektiv gruppieren, um die Anzahl von Kanten und Knoten in einem Provenienzgraphen zu reduzieren (auch Komprimierung genannt). Komprimierte Kanten in der resultierenden Gruppe würden durch Benutzerfunktionen anstelle von Systemaufrufen bezeichnet sein. Eine solche Komprimierung ist auch in vielen Szenarien nützlich, in denen die Größe des Graphen zu einem Problem wird, das auf Provenienzgraphen basierende Anwendungen behindert.
4 ist ein Flussdiagramm für ein Verfahren 400 zum Extrahieren von Informationen aus Programmbinärdateien für einen späteren Suchschritt gemäß einer Ausführungsform der vorliegenden Erfindung. Das Verfahren 400 benötigt Programmbinärdateien als Ein- und Ausgabe-Systemaufrufsequenz-Korpusse und Einbettungsmodelle für einzelne Programmbinärdateien.
Das Verfahren 400 enthält die folgenden Blöcke: Programmbinärdateien 210; CFG-Extraktion und -Reduktion 410; Durchlaufen des Graphen 420; Systemaufrufsequenz-Korpusse 430; Systemaufrufsequenz-Einbettungstraining 440; und Systemaufrufsequenz-Korpusse und Einbettungsmodelle 230.
In Bezug auf die CFG-Extraktion und -Reduktion 410 startet Block 410 mit einer Ausführung eines Tools bzw. Werkzeugs für binäre Analyse, um einen Kontrollflussgraphen (CFG) für jede Funktion in der eingegebenen Programmbinärdatei zu extrahieren. Verwendbare Tools enthalten, sind aber nicht darauf beschränkt, angr, radare2 und IDA-Disassembler. 5 ist ein Kontrollflussgraph (CFG) 500 gemäß einer Ausführungsform der vorliegenden Erfindung. Bei einem typischen CFG aus solchen Werkzeugen bzw. Tools, wie es in 5 gezeigt ist, stellt jeder Knoten im CFG einen Block von Programmanweisungen dar, die mit einer Änderung des Ausführungsflusses enden; und jede Kante zwischen zwei Knoten kann unterschiedliche Bedeutungen haben, aber alle zeigen potenzielle Ausführungsflüsse von einem Knoten zu einem anderen an. Mögliche Kanten können Funktionsaufrufe, Funktionsrückgaben, bedingte Sprünge und unbedingte Sprünge enthalten.
Für jeden extrahierten CFG führt der Block 410 zwei zusätzliche Nachbearbeitungsoperationen durch. Erstens identifiziert der Block 410 Knoten (Anweisungsblöcke), die mit einem Funktionsaufruf enden, und identifiziert weiterhin, ob solche Knoten ein Funktionsaufruf zu einer anderen Benutzerfunktion oder zu einem Systemaufruf sind. Tools für eine binäre Analyse können normalerweise Aufrufziele für diesen Block zur Verwendung bereitstellen, aber in den Fällen, in denen die Tools aufgrund der nicht konstanten Adresse in der Aufruf-Anweisung keine Aufrufziele bereitstellen, wird der Block 410 heuristische Regeln anwenden, um die mögliche Adresse zu erraten und jede Funktion zu durchsuchen, die von der erratenen Adresse aus startet. Nach einer Identifizierung aller Funktionsaufrufknoten führt der Block 410 eine CFG-Reduktion durch, indem er so viele Knoten ohne Funktionsaufruf wie möglich entfernt, während wesentliche Strukturen des Graphen beibehalten werden, die Beziehungen zwischen Funktionsaufrufknoten beibehalten. Der resultierende CFG wird zu einem Funktionsaufrufgraphen, in welchem ein Knoten entweder einen Funktionsaufruf darstellt oder leer ist. Solche Graphen können mit weniger Knoten und Kanten im Vergleich zu den entsprechenden vollständigen CFGs viel einfacher sein, und sie sollen beschreiben, wie Funktionsaufrufe (sowohl Benutzerfunktionen als auch Systemaufrufe) während Programmausführungen durchgeführt werden würden. 6 zeigt ein Beispiel eines Funktionsaufrufgraphen 600, reduziert von dem in 5 gezeigten CFG 500. Sie zeigt, dass zwei Funktionsaufrufe (bezeichnet mit Namen von Aufrufzielen) im ursprünglichen CFG 500 sowie ihre programmlogischen Beziehungen erhalten bleiben.
Der Graphen-Durchlaufschritt 420 durchquert die von 410 erzeugten Graphen und extrahiert Systemaufrufsequenzen entsprechend Pfaden, die nur Systemaufrufknoten in diesen Graphen enthalten. Der Block 420 verwendet unterschiedliche Durchlaufstrategien, einschließlich Random Walk bzw. zufälliger Schrittfolge bis zu einer bestimmten Länge und N-Gramm-Enumeration bzw. -Aufzählung, um Graphen zu durchqueren, die durch Funktionsaufrufe in Beziehung gesetzt sein können. Da Systemaufrufe normalerweise in einigen gängigen Programmbibliotheken ausgelöst werden, wie beispielsweise der C-Standardbibliothek libc, und es mehrere Ebenen von Funktionsaufrufen von einer Benutzerfunktion zu libc-Funktionen geben kann, die Systemaufrufe auslösen, führt der Block 420 basierend auf der Grenze von Benutzerfunktionen höherer Ebene, die Systemaufrufe nicht direkt auslösen, und Benutzerfunktionen niedrigerer Ebene, die Systemaufrufe auslösen, ein zweischichtiges Durchlaufen durch. Insbesondere führt der Block 420 an Graphen von Benutzerfunktionen höherer Ebene eine N-Gramm-Aufzählung aller Funktionsaufrufe zu Benutzerfunktionen niedrigerer Ebene durch, die Systemaufrufe weiter auslösen können (solche Benutzerfunktionen niedrigerer Ebene sind typischerweise libc-Funktionen). Dann führt der Block 420 innerhalb der Graphen jeder aufgezählten Benutzerfunktion niedrigerer Ebene und von ihr aufgerufenen zugehörigen Funktionen weitere zufällige Schrittfolgen beginnend von jedem Systemaufrufknoten bis zu einer benutzerspezifizierten Länge für bis zu einer benutzerspezifizierten Zeit durch, um Systemaufrufsequenzen zu sammeln. Die Kombination aus N-Gramm-Enumeration und Random Walks bzw. zufälligen Schrittfolgen löst das Problem einer Pfadexplosion, wobei alle Zielgraphen kombiniert zu groß und komplex werden, um vollständig durchquert zu werden.
Nun werden Systemaufrufsequenz-Korpusse 430 beschrieben werden. Das Ergebnis des Durchlaufen von Graphen 420 enthält zwei Teile: einen Systemaufrufsequenz-Korpus für jede Benutzerfunktion niedrigerer Ebene (extrahiert durch zufällige Schrittfolgen in 420) und Metadaten von Aufrufmustern von Benutzerfunktionen niedrigerer Ebene mit Kontext von Benutzerfunktionen höherer Ebene (extrahiert durch N-Gramm-Enumeration in 420). Jeder Systemaufrufsequenz-Korpus enthält eine oder mehrere Systemaufrufsequenzen, die aus einer variablen Anzahl von Namen von Systemaufrufen bis zu der Länge bestehen, die für zufällige Schrittfolgen in 420 spezifiziert ist. Jeder Korpus stellt mögliche aus der zugehörigen Benutzerfunktion niedrigerer Ebene abgetastete Systemaufrufmuster dar. Die Metadaten von Aufrufmustern stellen Aufrufmuster einer Benutzerfunktion niedrigerer Ebene in Form von N-Grammen dar. Wenn zum Beispiel im Benutzerprogramm einem Aufruf zu tzset ein Aufruf der libc-Funktion niedrigerer Ebene getaddrinfo vorausgeht, werden dann das Aufrufmuster getaddrinfo und tzset mit ihrem (ihren) aufrufenden Benutzerfunktionen) höherer Ebene in den Metadaten aufgenommen.
In Bezug auf ein Systemaufrufsequenz-Einbettungstraining 440, für jede analysierte Programmbinärdatei, trainiert der Block 440 ein Einbettungsmodell unter Verwendung vom von unterschiedlichen Benutzerfunktionen abgetasteten Systemaufrufsequenz-Korpus. Das resultierende Einbettungsmodell kann eine Sequenz von Systemaufrufen (genauer gesagt, Namen von Systemaufrufen) in einen Vektor fester Länge (Einbettung) mit der Eigenschaft konvertieren, dass ähnliche Sequenzen nahe beieinander liegen. Diese Einbettungseigenschaft ermöglicht es abwärts gerichteten Schritten ungenaue Suchen nach ähnlichen Systemaufrufsequenzen durchzuführen. Die Einbettungstechnik in Block 440 ist allgemein als Dokumenteneinbettung bei einer Verarbeitung natürlicher Sprache bekannt. Alle derartigen Techniken zum Einbetten von Dokumenten, die die vorgenannte Eigenschaft erfüllen können, sind verwendbar, z.B. sent2vec und doc2vec.
7 ist ein Flussdiagramm für eine Systemaufruf-zu-Benutzerfunktion-Suche 700 gemäß einer Ausführungsform der vorliegenden Erfindung. Insbesondere zeigt 7 das Flussdiagramm zur Modellierung einer eingegebenen Systemaufrufverfolgung als mehrere Abfragen und zur Durchführung von Abfragesuchen über Systemaufrufsequenz-Korpusse unter Verwendung der vortrainierten Einbettungsmodelle, um eine Benutzerfunktion für eingegebene Systemaufrufe zu identifizieren. Das System der vorliegenden Erfindung geht davon aus, dass die eingegebenen Verfolgungen durch Prozess und Thread getrennt sind, weshalb jede Verfolgung nur Systemaufrufinformationen von einem einzelnen Thread eines einzelnen Prozesses ohne irgendeine Verflechtung enthalten wird. Alle Beschreibungen der folgenden Schritte basieren auf einer einzelnen (Ablauf-)Verfolgung (d.h. einer einzelnen Sequenz von Systemaufrufen) aus einem einzelnen Programm, das unter dem Prozessnamen in der Verfolgung bekannt ist.
Die Systemaufruf-zu-Benutzerfunktion-Suche 700 enthält die folgenden Blöcke: Systemaufrufverfolgungen 240; erste Verfolgungssegmentierung 710; lange Verfolgungssegmente 720; kurze Verfolgungssegmente 730; zweite Verfolgungssegmentierung 740; Systemaufrufsequenz-Korpusse und Einbettungsmodelle 230; Kandidatensuche und -auswahl 750; Kandidatenqualitätsbewertung 760; und Systemaufrufverfolgungen, angereichert mit Benutzerfunktionsinformationen 260.
In Bezug auf eine erste Verfolgungssegmentierung 710 versucht Block 710, da die eingegebene Systemaufrufverfolgung von 240 beliebig lang sein kann, eine lange Verfolgung in kürzere Segmente zu segmentieren, die für spätere Schritte leichter zu handhaben sind. Um die Segmentierung durchzuführen, sucht der Block 710 nach bestimmten Orientierungshilfen-Systemaufrufen in der eingegebenen Verfolgung und segmentiert die Verfolgung an diesen Orientierungspunkten. Orientierungshilfen-Systemaufrufe beziehen sich in diesem Zusammenhang auf Systemaufrufe, die eindeutig und ausschließlich durch einige Benutzerfunktionen niedrigerer Ebene ausgelöst werden. Solche Benutzerfunktionen niedrigerer Ebene werden durch den Block 120 im Benutzer- bzw. Anwenderprogramm identifiziert. Das Ergebnis des Blocks 710 enthält mehrere Verfolgungssegmente variabler Längen. Abhängig von der im Block 420 definierten Länge für ein Durchlaufen des Graphen können diese Segmente in zwei Arten klassifiziert werden: lange Verfolgungssegmente (Block 720) und kurze Verfolgungssegmente (Block 730).
Ein langes Verfolgungssegment 720 ist ein Segment einer Systemaufrufverfolgung, die die Länge für ein Durchlaufen des Graphen überschreitet.
Ein kurzes Verfolgungssegment 730 ist ein Segment einer Systemaufrufverfolgung, die innerhalb der Länge für ein Durchlaufen des Graphen ist.
Die zweite Verfolgungssegmentierung 740 führt eine weitere Segmentierung an langen Verfolgungssegmenten (Block 720) durch, die durch den Block 710 erzeugt sind, da durch den Block 750 durchgeführte Suchen möglicherweise nicht wirksam sind, wenn die Verfolgungslänge länger als die Länge für ein Durchlaufen des Graphen ist. Diese zweite Segmentierung versucht, ein langes Verfolgungssegment an jedem Punkt weiter zu unterteilen, an dem es einen wahrscheinlichen Übergang von einer Benutzerfunktion niedrigerer Ebene zu einer anderen gibt, d.h. die Systemaufrufe vor und nach dem Punkt stammen wahrscheinlich von zwei unterschiedlichen Benutzerfunktionen niedrigerer Ebene. Zu diesem Zweck führt der Block 740 zwei Teilschritte durch: (1) Ähnlichkeitssuchen unter Verwendung eines größer werdenden bzw. zunehmenden Fensters über einem langen Verfolgungssegment, um Kandidaten von Benutzerfunktionen wahrscheinlich niedrigerer Ebene für Unter- bzw. Subsequenzen unterschiedlicher Längen zu identifizieren, und (2) Messungen vom Jaccard-Ähnlichkeitsindex $J (A, B) = \frac{| A \cap B |}{| A \cup B |} = \frac{| A \cap B |}{| A | + | B | - | A \cap B |}$
zwischen den identifizierten Kandidaten aus Suchen unterschiedlicher Fenstergrößen, um geeignete Schnittpunkte zu identifizieren. Die wichtigste Erkenntnis ist, dass dann, wenn der gemessene Jaccard-Ähnlichkeitsindex an einem Punkt signifikant abfällt, dieser Punkt wahrscheinlich ein Übergangspunkt sein wird, an dem alle seine vorangehenden Systemaufrufe von einer anderen Benutzerfunktion niedrigeren Ebene stammen können.
Als Anschauungsbeispiel für den Block 740 führt der Block 740 unter der Voraussetzung eines Systemaufrufsegments „getsockname sendto recvmsg recvmsg recvmsg“ zunächst eine Ähnlichkeitssuche beginnend von einer vordefinierten minimalen Länge einer Systemaufruf-Untersequenz als Suchabfrage durch, z.B. „getsockname sendto recvmsg“. Beim Durchführen der Ähnlichkeitssuche verwendet der Block 740 das Einbettungsmodell aus dem Block 230, um die Unter- bzw. Subsequenz in eine Vektordarstellung umzuwandeln, und sucht dann im Einbettungsraum nach den obersten k nächstgelegenen Systemaufrufsequenzen (in den Korpussen aus dem Block 230). Mit dem Suchergebnis erstellt der Block 740 eine Kandidatengruppe C₁ von Benutzerfunktionen niedrigerer Ebene, aus denen identifizierte nächste Sequenzen stammen. Nach der ersten Iteration erhöht der Block 740 das Fenster, damit es ein mehr an Systemaufruf(en) enthält, z.B. erfolgt ein Erhöhen des Fensters um 1, um eine neue Suchabfrage „getsockname sendto recvmsg recvmsg“ zu bilden, und wiederholt die Suche, um eine weiter Kandidatengruppe C₂ zu bekommen. Der Block 740 bleibt bei einem Wiederholen von solchen Ähnlichkeitssuchen, um mehr Kandidatengruppen C₃, C₄, ..., C_n zu bekommen, bis die Suchabfrage eine vordefinierte Länge oder die Länge des gesamten Segments erreicht, je nachdem, welche kleiner ist. Bei allen Kandidatengruppen berechnet der Block 740 den Jaccard-Ähnlichkeitsindex zwischen Kandidatengruppen aus benachbarten Iterationen, d.h. zwischen C₁ und C₂, C₂ und C₃ und so weiter. Für n Iterationen berechnet der Block 740 n - 1 Jaccard-Ähnlichkeitsindizes und der kleinste Wert unterhalb eines benutzerspezifizierten Schwellenwert zeigt an, dass der wahrscheinlichste Schnittpunkt im inkrementellen Teil der beiden entsprechenden Suchabfragen liegt. Somit segmentiert der Block 740 des langen Verfolgungssegment bei diesen Systemaufrufen weiter und wiederholt dann den gesamten Prozess beginnend ab dem letzten Schnittpunkt, um alle verbleibenden langen Verfolgungssegmente in kurze Verfolgungssegmente zu segmentieren.
Für jedes kurze Verfolgungssegment 730 identifiziert ein Block Kandidatensuche und -auswahl 750 die wahrscheinlichsten Benutzerfunktionen niedrigerer Ebene, die jeden der Systemaufrufe im Segment auslösen. Mit Metadaten vom Block 230 listet der Block 750 auch Benutzerfunktionen höherer Ebene auf, die diese identifizierten Benutzerfunktionen niedrigerer Ebene aufrufen. Der Block 750 geht davon aus, dass Systemaufrufe im Segment von unterschiedlichen Benutzerfunktionen niedrigerer Ebene stammen können. Daher zählt er zunächst alle möglichen Segmentierungen von Systemaufrufen im Segment auf. Für n Systemaufrufe gibt es 2^n-1 unterschiedliche Segmentierungen. Zum Beispiel zählt in einem Segment von „getsockname sendto recvmsg“ mit der Annahme, dass sie von unterschiedlichen Funktionen stammen können, dieser Schritt 4 verschiedene Fälle auf: (1) „getsockname“, „sendto“, „recvmsg“, (2) „getsockname sendto“ und „recvmsg“, (3) „getsockname“ und „sendto recvmsg“ und (4) „getsockname sendto recvmsg“. Für jeden von solchen Fällen führt der Block 750 dann eine Ähnlichkeitssuche (die auch im Block 540 beschrieben ist) an jeder Systemaufruf-Untersequenz durch, um eine Kandidatengruppe wahrscheinlicher Funktionen zu bekommen. Als Ergebnis gibt es eine Liste von Kandidatengruppen entsprechend Systemaufruf-Untersequenzen in jedem Fall, und insgesamt 2^n-1 von solchen Listen, die unterschiedliche Auswahlen von Benutzerfunktionen für ein Segment mit n Systemaufrufen darstellen. Unter all diesen Listen (Auswahlen) ruft der Block 750 dann den Block 760 auf, um die Wahrscheinlichkeit jeder einzelnen Auswahl zu bewerten, und wählt die wahrscheinlichste Auswahl mit den wahrscheinlichsten Benutzerfunktionskandidaten als seine Ausgabe aus. 8 ist ein Blockdiagramm, das ein Beispiel für einen Block Kandidatensuche und -auswahl 750 der 7 zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung.
Der Kandidatenqualitäts-Bewertungsblock 760 bewertet die Wahrscheinlichkeit einer Auswahl (d.h. einer spezifischen Segmentierung an n Systemaufrufen mit Kandidatenfunktionen für jede Sub- bzw. Untersequenz aus der Segmentierung) aus dem Block 750 durch Zuordnen eines relativen Werts zur Auswahl. Während allen Auswahlen entsprechende Werte zugeordnet sind, kann der Block 750 die Auswahl mit dem signifikantesten Wert auswählen. Dieser Schritt bestimmt den Wert durch mehrere messbare Faktoren bezogen auf die Auswahl vom Block 750. Erstens nutzt er die Aufrufmuster von Benutzerfunktionen niedrigerer Ebene mit einem Kontext von Benutzerfunktionen höherer Ebene. Diese Stück von Informationen bietet im Wesentlichen eine Filterleistung, die mitteilen kann, welche für benachbarte Untersequenzen identifizierte Kandidatenfunktionen wahrscheinlicher sind, da sie möglicherweise Aufrufmuster im Benutzerprogramm haben. Daher werden diese Kandidatenfunktionen, die in solchen Mustern erscheinen, nach oben gewichtet, während die anderen nach unten gewichtet werden. Zweitens nutzt dieser Schritt auch Einbettungsraumabstände der obersten k nächsten Systemaufrufsequenzen, die bei Ähnlichkeitssuchen identifiziert sind, da erwartet wird, dass Abstände einer bestimmten Verteilung folgen, die zwischen guten und schlechten Auswahlen unterscheidet. Insbesondere sollten für eine guten Auswahl der Durchschnitt und die Streuung solcher Abstände von Suchen in allen Untersequenzen niedriger bleiben als diejenigen einer schlechten Auswahl.
9 ist ein Flussdiagramm, das einen beispielhaften Provenienzgraphen-Konstruktionsprozess 900 mit Systemaufrufverfolgungen zeigt, angereichert durch den Block 250 der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Mit angereicherten Systemaufrufverfolgungen präsentieren die resultierenden Graphen nützliche Informationen auf Programmebene für andere nachgelagerte Aufgaben. Dieser Graphen-Konstruktionsprozess führt im Wesentlichen eine Suche und eine Verfolgung in Systemaufrufverfolgungen für spezifische Systementitäten (Prozesse, Dateien und Sockets) und ihre zugehörigen Operationen in Bezug auf spezifische Systemaufrufe (Lesen, Schreiben und so weiter) durch.
Der Provenienzgraphen-Konstruktionsprozess 900 enthält die folgenden Blöcke: Systemaufrufverfolgungen, angereichert durch Benutzerfunktionsinformationen 260; Kriterien zur Auswahl von Startpunkten 910; iteratives Verfolgen und Graphen-Konstruktion 920; Kriterien zum Stoppen der Verfolgung 930; Nachbearbeitung mit Benutzerinformationen-Bezeichnung 940; und Provenienzgraphen, angereichert durch Benutzerfunktionsinformationen 280.
In Bezug auf Kriterien zur Auswahl von Startpunkten 910 sind Startpunkte einer Graphenkonstruktion in der Regel benutzerdefinierte Systementitäten von Interesse mit einem spezifizierten Startzeitstempel. Solche Systementitäten können Prozesse bestimmter Programme sein, und Dateien, die zu bestimmten Namensmustern passen.
In Bezug auf iteratives Verfolgen und Graphen-Konstruktion 920 führt der Verfolgungsprozess ausgehend von den Ausgangspunkten iterativ eine Vorwärts- und Rückwärtsverfolgung durch Systementitäts-Interaktionen und Zeit durch. Wenn der Startpunkt zum Beispiel eine Datei ist, dann identifiziert eine Vorwärtsverfolgung in den Verfolgungen alle Prozesse, die die Datei nach dem spezifizierten Zeitstempel lesen; und identifiziert eine Rückwärtsverfolgung alle Prozesse, die vor dem spezifizierten Zeitstempel in die Datei schreiben. Die identifizierten Entitäten und Operationen werden jeweils Knoten und Kanten eines Provenienzgraphen.
In Bezug auf Kriterien zum Stoppen der Verfolgung 930 ist es, da ein System in Betrieb bleiben und eine beliebige Anzahl zugehöriger Systementitäten und Operationen erzeugen kann, notwendig, die Verfolgung an irgendeinem Punkt zu stoppen, um zu verhindern, dass ein Graph unbegrenzt anwächst. Solche Kriterien können auf einem Zeitbereich basieren, sind aber nicht darauf beschränkt, d.h. nur für einen bestimmten Zeitbereich vom Startzeitstempel aus verfolgen; oder der Anzahl der Hops vom Startpunkt aus.
In Bezug auf eine Nachbearbeitung mit Benutzerfunktionsinformationen-Bezeichnung 940 bietet, da der Graphen-Konstruktionsprozess Systemaufrufverfolgungen durchsucht und Entitäten und Operationen von Interesse identifiziert, ein angehängt haben von Programminformationen auf Benutzerebene an Verfolgungen natürlich eine weitere Schicht von Informationen, die in Knoten-/Kantenbezeichnungen bzw. -labels in Provenienzgraphen integriert werden können. Daher fügt dieser Schritt in den vorherigen Schritten erstellten bzw. konstruierten Graphen mehr Beschriftungen bzw. Bezeichnungen bzw. Labels auf Programmebene hinzu. Weiterhin komprimiert dieser Schritt auch Knoten und Kanten basierend auf Beschriftungen auf Programmebene, um präzisere Graphen zu erstellen. Wenn zum Beispiel eine Reihe aufeinanderfolgender Operationen (Kanten) und Subjektentitäten (Knoten) alle mit derselben Bezeichnung auf Programmebene bezeichnet sind, können diese entsprechenden Kanten zusammengeführt werden, da sie als Ganzes eine gesamte Einheit einer Programmlogik darstellen.
Es wird nun eine Beschreibung bezüglich einer Eindringerkennung und -untersuchung gemäß einer Ausführungsform der vorliegenden Erfindung angegeben.
Bei einer Ausführungsform würde ein die Erfindung anwendendes Eindringerkennungssystem Systemaufrufsequenzen als Eingabe empfangen und irreguläre Systemaufrufe für potenzielle Eindringsignale erkennen. Zur Veranschaulichung kann die Erfindung auf zwei unterschiedliche Weisen angewendet werden, um eine Eindringerkennung und/oder eine Eindringuntersuchung zu verbessern.
In der Situation eines Verbesserns einer Eindringerkennung können Ausführungsformen der vorliegenden Erfindung als Vorverarbeitungsmodul für Systemaufrufsequenzen installiert werden. Diese Vorverarbeitung würde Low-Level- und ausführliche Systemaufrufsequenzen in Provenienzgraphen mit Kantenbeschriftungen, die Systemoperationen hoher Ebene beschreiben, konvertieren. Die Provenienzgraphen können dann in einen auf Graphen basierten Eindringerkennungs-AIgorithmus eingespeist werden. Eine durch Ausführungsformen der vorliegenden Erfindung gegenüber herkömmlichen Provenienzgraphen eingeführte wesentliche Verbesserung besteht darin, dass die resultierenden Graphen viel kompakter und weniger ausführlich sind, was mehr Skalierbarkeit bietet und einen viel größeren Ausführungskontext codiert, in welchem sich einige komplexe Angriffe für eine effektive Erkennung erstrecken können.
In der Situation eines Verbesserns der Eindringuntersuchung können Ausführungsformen der vorliegenden Erfindung als Nachbearbeitungsmodul installiert sein, um erkannte Systemaufrufanomalien auf einer höheren Systemebene zu erklären. Ausführungsformen der vorliegenden Erfindung würden Systemaufrufsequenzen aufnehmen, in welchen Anomalien erkannt werden, und Low-Level-Systemaufrufe auf High-Level-Provenienzgraphen mit Programmkontexten abbilden, um Sicherheitsanalysten zu helfen, zu verstehen, was passiert ist. Die resultierenden High-Level-Graphen machen eine Untersuchung und ein Verstehen einfacher als Low-Level-Systemaufrufsequenzen.
10 ist ein Flussdiagramm, das ein beispielhaftes Verfahren 1000 zur Eindringerkennung zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung.
Bei einem Block 1010 erfolgt ein Bilden einer Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen.
Bei einem Block 1020 erfolgt unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, ein Identifizieren jeder der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen.
Bei einem Block 1030 erfolgt ein Durchführen einer Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten, wobei der Provenienzgraph Knoten hat, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen, wobei Kanten im Provenienzgraphen Kantenbeschriftungen bzw. -labels haben, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.
Die vorliegende Erfindung kann ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen technischen Detailebene einer Integration sein. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder Medien) mit computerlesbaren Programmanweisungen darauf enthalten, um zu veranlassen, dass ein Prozessor Aspekte der vorliegenden Erfindung auszuführt.
Das computerlesbare Speichermedium kann ein konkretes Gerät sein, das Anweisungen zur Verwendung durch ein Anweisungs- bzw. Befehlsausführungsgerät beibehalten und speichern kann. Das computerlesbare Speichermedium kann zum Beispiel eine elektronische Speichervorrichtung, eine magnetische Speichervorrichtung, eine optische Speichervorrichtung, eine elektromagnetische Speichervorrichtung, eine Halbleiterspeichervorrichtung oder eine geeignete Kombination aus dem Vorstehenden sein, ist aber nicht darauf beschränkt. Eine nicht erschöpfende Liste spezifischerer Beispiele für das computerlesbare Speichermedium enthält das Folgende: eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Nurlese-Speicher (ROM), einen löschbaren programmierbaren Nurlese-Speicher (EPROM- oder Flash-Speicher), einen statischer Direktzugriffsspeicher (SRAM), einen tragbaren CD-Nurlese-Speicher (CD-ROM), eine digitale vielseitige Diskette (DVD), einen Speicherstick, eine Diskette, eine mechanisch codierte Vorrichtung, wie beispielsweise Lochkarten oder erhöhte Strukturen in einer Rille mit darauf aufgezeichneten Anweisungen, und irgendeine geeignete Kombination von dem Vorstehenden. Ein computerlesbares Speichermedium, wie es hierin verwendet wird, ist nicht derart auszulegen, dass es für flüchtige Signale perse steht, wie beispielsweise Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, sich durch einen Hohlleiter oder andere Übertragungsmedien ausbreitende elektromagnetische Wellen (z.B. Lichtimpulse, die durch ein Glasfaserkabel laufen) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene computerlesbare Programmanweisungen können zu jeweiligen Computing-/Verarbeitungsvorrichtung von einem computerlesbaren Speichermedium oder zu einem externen Computer oder einer externen Speichervorrichtung über ein Netzwerk, zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, optische Übertragungsfasern, eine drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server umfassen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Computing-/Verarbeitungsvorrichtung empfängt computerlesbare Programmanweisungen aus dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium innerhalb der jeweiligen Computing-/Verarbeitungsvorrichtung weiter.
Computerlesbare Programmanweisungen zum Ausführen von Operationen der vorliegenden Erfindung können Assembler-Anweisungen, Befehlssatz-Architektur-(ISA(= Instruction-Set-Architecture)-)Anweisungen, Maschinenanweisungen, maschinenabhängige Anweisungen, ein Mikrocode, Firmware-Anweisungen, Zustandseinstellungsdaten sein, oder entweder ein Quellcode oder ein Objektcode, der in irgendeiner Kombination von einer oder mehreren Programmiersprachen geschrieben ist, einschließlich einer objektorientierten Programmiersprache, wie beispielsweise SMALLTALK, C++ oder dergleichen, und konventionellen prozeduralen Programmiersprachen, wie beispielsweise der Programmiersprache „C“, oder ähnlichen Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer eines Anwenders, teilweise auf dem Computer eines Anwenders, als eigenständiges Softwarepaket, teilweise auf dem Computer eines Anwenders und teilweise auf einem entfernten Computer bzw. Remotecomputer oder vollständig auf dem entfernten Computer bzw. Remotecomputer oder einem Server ausgeführt werden. Im letzteren Szenario kann der Remotecomputer mit dem Computer des Benutzers über irgendeinen Typ von Netzwerk verbunden sein, einschließlich eines lokalen Netzwerks (LAN) oder eines Weitverkehrsnetzwerks (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). Bei einigen Ausführungsformen kann eine elektronische Schaltung, einschließlich zum Beispiel einer programmierbaren Logikschaltung, feldprogrammierbarer Gate-Arrays (FPGA) oder programmierbarer Logikarrays (PLA), die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformation der computerlesbaren Programmanweisungen verwendet, um die elektronische Schaltung zu personalisieren, um Aspekte der vorliegenden Erfindung auszuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Flussdiagrammdarstellungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß den Ausführungsformen der Erfindung beschrieben. Es wird verstanden werden, dass jeder Block der Flussdiagrammdarstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammdarstellungen und/oder Blockdiagrammen durch computerlesbare Programmanweisungen implementiert werden können.
Diese computerlesbaren Programmanweisungen können einem Prozessor eines allgemeinen Computers, eines speziellen Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zur Verfügung gestellt werden, um eine Maschine herzustellen, so dass die Anweisungen, die über den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung ausführen, Mittel zum Implementieren der im Flussdiagramm und/oder im Block oder in Blöcken des Blockdiagrammblocks spezifizierten Funktionen/Handlungen schaffen. Diese computerlesbaren Programmanweisungen können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Vorrichtungen anweisen kann, auf eine bestimmte Weise zu funktionieren, so dass das computerlesbare Speichermedium mit darin gespeicherten Anweisungen einen Herstellungsgegenstand einschließlich Anweisungen umfasst, die Aspekte der im Flussdiagramm und/oder im Block oder in Blöcken des Blockdiagramms spezifizierten Funktion/Handlung implementieren.
Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Vorrichtung geladen werden, um zu veranlassen, dass eine Reihe von Betriebs- bzw. Operations- bzw. Arbeitsschritten auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Vorrichtung durchgeführt wird, um einen computerimplementierten Prozess zu erzeugen, so dass die Anweisungen, die auf dem Computer, einer anderen programmierbaren Vorrichtungen oder einer anderen Vorrichtung ausführen, die im Flussdiagramm und/oder im Block oder in Blöcken des Blockdiagramms spezifizierten Funktionen/Handlungen implementieren.
Das Flussdiagramm und die Blockdiagramme in den Figuren stellen die Architektur, die Funktionalität und eine Operation bzw. einen Betrieb von möglichen Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung dar. In diesem Zusammenhang kann jeder Block im Flussdiagramm oder in den Blockdiagrammen ein Modul, ein Segment oder einen Teilbereich von Anweisungen darstellen, das oder der eine oder mehrere ausführbare Anweisungen zum Implementieren der spezifizierten logischen Funktion(en) umfasst. Bei einigen alternativen Implementierungen können die im Block vermerkten Funktionen außerhalb der in den Figuren angegebenen Reihenfolge auftreten. Zum Beispiel können zwei Blöcke, die nacheinander angezeigt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, und zwar abhängig von der beteiligten Funktionalität. Es wird bemerkt werden, dass jeder Block der Blockdiagramme und/oder der Flussdiagrammdarstellung und Kombinationen von Blöcken in den Blockdiagrammen und/oder der Flussdiagrammdarstellung durch spezielle hardwarebasierte Systeme implementiert werden kann oder können, die die spezifizierten Funktionen oder Handlungen durchführen oder Kombinationen von spezieller Hardware und Computeranweisungen ausführen.
Eine Bezugnahme in der Spezifikation auf „eine einzelne Ausführungsform“ oder „eine Ausführungsform“ der vorliegenden Erfindung sowie andere Variationen davon bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur, eine bestimmte Charakteristik und so weiter, das oder die in Verbindung mit der Ausführungsform beschrieben wird, bei wenigstens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit beziehen sich die Erscheinungen der Formulierung „bei einer einzelnen Ausführungsform“ oder „bei einer Ausführungsform“ sowie irgendwelche anderen Variationen, die an verschiedenen Stellen in der gesamten Spezifikation erscheinen, nicht notwendigerweise alle auf dieselbe Ausführungsform.
Es ist einzusehen, dass die Verwendung von irgendetwas von dem folgendem „/“, „und/oder“ und „wenigstens eines von“, wie zum Beispiel in den Fällen von „A/B“, „A und/oder B“ und „wenigstens eines von A und B“, nur die Auswahl der ersten aufgelisteten Option (A) oder die Auswahl der zweiten aufgelisteten Option (B) oder die Auswahl von beiden Optionen (A und B) umfassen soll. Als ein weiteres Beispiel soll eine solche Formulierung in den Fällen „A, B und/oder C“ und „wenigstens eines von A, B und C“ nur die Auswahl der ersten aufgelisteten Option (A) oder nur die Auswahl der zweiten aufgelisteten Option (B) oder nur die Auswahl der dritten aufgelisteten Option (C) oder nur die Auswahl der ersten und zweiten aufgelisteten Optionen (A und B) oder nur die Auswahl der ersten und dritten aufgelisteten Optionen (A und C) oder nur die Auswahl der zweiten und dritten aufgelisteten Optionen (B und C) oder die Auswahl aller drei Optionen (A und B und C) umfassen. Dies kann, wie es für Fachleute auf dem Gebiet ohne weiteres offensichtlich ist, für so viele Elemente ausgeweitet werden, wie sie aufgelistet sind.
Das Vorstehende ist in jeder Hinsicht als illustrativ und beispielhaft, aber nicht als einschränkend, zu verstehen, und der Schutzumfang der hierin offenbarten Erfindung ist nicht aus der detaillierten Beschreibung zu bestimmen, sondern vielmehr aus den Ansprüchen, wie sie gemäß der vollständigen Breite interpretiert werden, die durch die Patentgesetze zulässig ist. Es ist zu verstehen, dass die hierin gezeigten und beschriebenen Ausführungsformen nur illustrativ für die vorliegende Erfindung sind und dass Fachleute auf dem Gebiet verschiedene Modifikationen implementieren können, ohne vom Schutzumfang und Sinngehalt der Erfindung abzuweichen. Fachleute auf dem Gebiet könnten verschiedene andere Merkmalskombinationen implementieren, ohne vom Schutzumfang und Sinngehalt der Erfindung abzuweichen. Nachdem somit Aspekte der Erfindung mit den von den Patentgesetzen geforderten Details und Besonderheiten beschrieben sind, wird das, was beansprucht und durch das Patent geschützt erwünscht wird, in den beigefügten Ansprüchen dargelegt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 17/398514 [0001]
US 63/065530 [0001]

Claims

Computerimplementiertes Verfahren zur Computereindringerkennung, umfassend: Erstellen (1010) einer Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen, wobei die Benutzerfunktionen in einem Benutzerbereich eines Betriebssystems laufen bzw. ausgeführt werden; Identifizieren (1020), unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, irgendeiner bzw. jeder der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen; und Durchführen (1030), durch eine Prozessorvorrichtung, einer Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten, wobei der Provenienzgraph Knoten hat, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen, wobei Kanten im Provenienzgraph Kantenbeschriftungen bzw. -labels haben, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.
Computerimplementiertes Verfahren nach Anspruch 1, wobei ein Erstellen der Abbildung ein Durchführen von binärer Analyse und Maschinenlernen an den Computerprogrammen umfasst, um Kontrollflussgraphen (CFGs) aus den Benutzerfunktionen zu extrahieren und CFG-Knoten zu identifizieren, die Systemaufrufe auslösen oder Funktionsaufrufe zu anderen Benutzerfunktionen vornehmen; ein Durchführen von Graphen-Durchläufen durch die CFGs, um Systemaufrufsequenzen zu sammeln, die die Funktionsaufrufe auslösen können; Trainieren, unter Verwendung der Systemaufrufsequenzen, eines Systemaufrufsequenz-Einbettungsmodells, das eine Systemaufrufsequenz aus den Systemaufrufsequenzen in eine Vektorraumdarstellung konvertieren kann.
Computerimplementiertes Verfahren nach Anspruch 2, wobei ein Trainieren, unter Verwendung der Systemaufrufsequenzen, eines Systemaufrufsequenz-Einbettungsmodells folgendes umfasst: Erzeugen eines Systemaufrufsequenz-Korpus für jede der Benutzerfunktionen, der die möglichen Systemaufrufsequenzmuster für jede der Benutzerfunktionen darstellt; und Trainieren des Systemaufrufsequenz-Einbettungsmodells unter Verwendung des für jede der Benutzerfunktionen erzeugten Korpus.
Computerimplementiertes Verfahren nach Anspruch 2, wobei das Einbettungsmodell Systemaufrufsequenzen unterschiedlicher Länge in einen Vektor fester Länge als Vektorraumdarstellung umwandelt.
Computerimplementiertes Verfahren nach Anspruch 1, wobei der Suchalgorithmus ein heuristisches Verfahren umfasst, um die Systemaufrufverfolgung zu segmentieren, um einen Suchraum für eine Identifizierung von Benutzerfunktionen zu reduzieren; wobei ein Suchverfahren das Systemaufrufsequenz-Einbettungsmodell, die aus den CFGs gesammelten Systemaufrufsequenzen und eine Gruppe von Heuristiken nutzt, um Kandidaten von möglichen der Benutzerfunktionen innerhalb eines Segments der Systemaufrufverfolgung einzeln zu benennen; und eine Qualitätsmessfunktion, um unterschiedliche der Kandidaten zu vergleichen und eine Gruppe wahrscheinlichster Kandidaten als Suchausgabe auszuwählen.
Computerimplementiertes Verfahren nach Anspruch 1, wobei die beliebigen der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen, in einem Einbettungsraum identifiziert werden.
Computerimplementiertes Verfahren nach Anspruch 1, das weiterhin ein Anreichern der Systemaufrufverfolgung mit Benutzerfunktionsinformationen umfasst.
Computerimplementiertes Verfahren nach Anspruch 1, das weiterhin ein Zusammenführen von zweien der Kanten des Provenienzgraphen basierend auf Benutzerfunktionsinformationen umfasst.
Computerimplementiertes Verfahren nach Anspruch 1, das weiterhin ein Durchführen einer CFG-Reduktion an wenigstens einem der CFGs durch Entfernen von Nicht-Funktionsaufrufknoten daraus, um einen Funktionsaufrufgraphen zu bilden, umfasst.
Computerimplementiertes Verfahren nach Anspruch 1, das weiterhin ein Durchführen eines zweischichtigen Durchlaufens von Graphen umfasst, um Systemaufrufsequenzen zu extrahieren, wobei eine erste Schicht des zweischichtigen Durchlaufens von Graphen auf einer Grenze von Benutzerfunktionen höherer Ebene, die Systemaufrufe nicht direkt auslösen, und von Benutzerfunktionen niedrigerer Ebene, die Systemaufrufe auslösen, basiert.
Computerprogrammprodukt zur Computereindringerkennung, wobei das Computerprogrammprodukt ein nichtflüchtiges computerlesbares Speichermedium mit damit verkörperten Programmanweisungen umfasst, wobei die Programmanweisungen von einem Computer ausführbar sind, um zu veranlassen, dass der Computer ein Verfahren durchführt, das folgendes umfasst: Erstellen (1010), durch eine Prozessorvorrichtung, einer Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen, wobei die Benutzerfunktionen in einem Benutzerbereich eines Betriebssystems laufen bzw. ausgeführt werden; Identifizieren (1020), durch die Prozessorvorrichtung unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, irgendeiner bzw. jeder der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen; und Durchführen (1030), durch die Prozessorvorrichtung, einer Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten, wobei der Provenienzgraph Knoten hat, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen, wobei Kanten im Provenienzgraph Kantenbeschriftungen bzw. -labels haben, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.
Computerprogrammprodukt nach Anspruch 11, wobei ein Erstellen der Abbildung ein Durchführen von binärer Analyse und Maschinenlernen an den Computerprogrammen umfasst, um Kontrollflussgraphen (CFGs) aus den Benutzerfunktionen zu extrahieren und CFG-Knoten zu identifizieren, die Systemaufrufe auslösen oder Funktionsaufrufe zu anderen Benutzerfunktionen vornehmen; ein Durchführen von Graphen-Durchläufen durch die CFGs, um Systemaufrufsequenzen zu sammeln, die die Funktionsaufrufe auslösen können; Trainieren, unter Verwendung der Systemaufrufsequenzen, eines Systemaufrufsequenz-Einbettungsmodells, das eine Systemaufrufsequenz aus den Systemaufrufsequenzen in eine Vektorraumdarstellung konvertieren kann.
Computerprogrammprodukt nach Anspruch 12, wobei ein Trainieren, unter Verwendung der Systemaufrufsequenzen, eines Systemaufrufsequenz-Einbettungsmodells folgendes umfasst: Erzeugen eines Systemaufrufsequenz-Korpus für jede der Benutzerfunktionen, der die möglichen Systemaufrufsequenzmuster für jede der Benutzerfunktionen darstellt; und Trainieren des Systemaufrufsequenz-Einbettungsmodells unter Verwendung des für jede der Benutzerfunktionen erzeugten Korpus.
Computerprogrammprodukt nach Anspruch 12, wobei das Einbettungsmodell Systemaufrufsequenzen unterschiedlicher Länge in einen Vektor fester Länge als Vektorraumdarstellung umwandelt.
Computerprogrammprodukt nach Anspruch 11, wobei der Suchalgorithmus ein heuristisches Verfahren umfasst, um die Systemaufrufverfolgung zu segmentieren, um einen Suchraum für eine Identifizierung von Benutzerfunktionen zu reduzieren; wobei ein Suchverfahren das Systemaufrufsequenz-Einbettungsmodell, die aus den CFGs gesammelten Systemaufrufsequenzen und eine Gruppe von Heuristiken nutzt, um Kandidaten von möglichen der Benutzerfunktionen innerhalb eines Segments der Systemaufrufverfolgung einzeln zu benennen; und eine Qualitätsmessfunktion, um unterschiedliche der Kandidaten zu vergleichen und eine Gruppe wahrscheinlichster Kandidaten als Suchausgabe auszuwählen.
Computerprogrammprodukt nach Anspruch 11, wobei die beliebigen der Benutzerfunktionen, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen, in einem Einbettungsraum identifiziert werden.
Computerprogrammprodukt nach Anspruch 11, wobei das Verfahren weiterhin ein Anreichern der Systemaufrufverfolgung mit Benutzerfunktionsinformationen umfasst.
Computerprogrammprodukt nach Anspruch 11, wobei das Verfahren weiterhin ein Zusammenführen von zweien der Kanten des Provenienzgraphen basierend auf Benutzerfunktionsinformationen umfasst.
Computerprogrammprodukt nach Anspruch 11, wobei das Verfahren weiterhin ein Durchführen einer CFG-Reduktion an wenigstens einem der CFGs durch Entfernen von Nicht-Funktionsaufrufknoten daraus, um einen Funktionsaufrufgraphen zu bilden, umfasst.
Computerverarbeitungssystem zur Computereindringerkennung, umfassend: eine Speichervorrichtung (140) zum Speichern von Programmcode; und einen Hardwareprozessor (110), der operativ mit der Speichervorrichtung gekoppelt ist, zum Laufenlassen bzw. Ausführen des Programmcodes, um eine Abbildung von Low-Level-Systemaufrufen zu Benutzerfunktionen in Computerprogrammen zu erstellen, wobei die Benutzerfunktionen in einem Benutzerbereich eines Betriebssystems laufen bzw. ausgeführt werden; unter Verwendung eines Suchalgorithmus, der die Abbildung und eine zur Laufzeit erfasste Systemaufrufverfolgung eingibt, jede bzw. irgendeine der Benutzerfunktionen zu identifizieren, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen; und eine Eindringerkennung in Reaktion auf einen Provenienzgraphen mit Programmkontexten durchzuführen, wobei der Provenienzgraph Knoten hat, die aus den Benutzerfunktionen gebildet sind, die die Low-Level-Systemaufrufe in der Systemaufrufverfolgung auslösen, wobei Kanten im Provenienzgraphen Kantenbeschriftungen bzw. -labels haben, die High-Level-Systemoperationen für eine Eindringerkennung korrelationsbasiert zu einem Low-Level-Systemaufruf zu einer High-Level-Systemoperation beschreiben.