DE112021003315T5

DE112021003315T5 - Schnelles identifizieren von verstössen und angriffen in netzwerkverkehrsmustern

Info

Publication number: DE112021003315T5
Application number: DE112021003315.8T
Authority: DE
Inventors: Francis Wayne Tackabury; Bruno dos Santos Silva
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-06-18
Filing date: 2021-04-23
Publication date: 2023-04-20
Also published as: WO2021255534A1; AU2021291150B2; US11882138B2; CA3180874A1; KR20230005873A; GB2611922A; JP2023530828A; AU2021291150A1; US20210400063A1; IL297811A; CN115699680A; GB202300447D0

Abstract

Ein Verfahren, eine Vorrichtung und ein Computersystem zum Identifizieren von Bedrohungen in einem TCP/IP-gestützten Netzwerk. Der Ansatz nutzt einen Satz von Referenzmustern („Netzwerk-Spektralmustern“), die einem oder mehreren definierten Kompromittierungsindikatoren (IoCs) zugehörig sind. Mindestens ein Referenzmuster ist zeitlich begrenzt und erstellt ein Profil eines Netzwerkverkehrsmusters unter Verwendung eines Satzes von Sitzungsdaten (z.B. Volumen, Richtung, Verkehrsmetadaten), die nutzdatenneutral sind und teilweise durch Zeitreihenkomprimierung von mindestens einem nichtvariierenden Codierungsintervall abgeleitet werden können. Die einem zu prüfenden Datenverkehrsmuster zugehörigen Netzwerkverkehrsdaten werden empfangen und codiert, um ein Prüfspektralmuster zu erzeugen. Ein Echtzeitvergleich auf Grundlage eines Datenstroms wird durchgeführt, um zu ermitteln, ob das Prüfnetzwerk-Spektralmuster mit einem der Referenznetzwerk-Spektralmuster übereinstimmt. Als Reaktion auf das Identifizieren einer Übereinstimmung wird eine bestimmte Abhilfe- oder Schadensbegrenzungsmaßnahme ergriffen. Ein Referenzspektralmuster kann einen bi- oder multidirektionalen Datenfluss darstellen, und der multidirektionale Datenfluss kann mehrere Entitäten umfassen.

Description

HINTERGRUND
Technisches Gebiet
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf die Sicherheit von Netzwerken und im Besonderen auf Werkzeuge und Techniken, die Charakterisieren verschiedener Netzwerkbedrohungen und -angriffe bereitstellen, die in Datennetzwerken (z.B. TCP/IP-Netzwerken) auftreten.
Beschreibung des Standes der Technik
Im Hinblick auf eine Technik zum Einrichten von Netzwerk-Cybersicherheit oder anderen Anwendungen wie z.B. Datenverkehrsplanung können Netzwerke häufig überwacht werden, entweder durch Netzwerk-Taps im nichtvertraulichen Modus (alle empfangen) oder durch Empfangen von exportierten Netzwerk-Übersichtsinformationen von Multiport-Switches oder anderen Netzwerk-Weiterleitungseinheiten, die Flussdaten in unterschiedlicher Ausführlichkeit oder Einfachheit bereitstellen. Wenn eine Anwendung dieser Netzwerkverkehrsdaten auf eine Analyse der Cybersicherheit ausgerichtet ist, gibt es mehrere Möglichkeiten, wie die Daten verwendet werden können. Ein erster Anwendungsfall ist forensisches Sammeln, bei dem Rohpaketdaten zum Sortieren, Indizieren und Analysieren in einem Zeitrahmen nach einem Angriffsereignis gesammelt werden. Ein weiterer Anwendungsfall ist eine Angriffserkennung in Echtzeit, bei der Kombinationen von Metadaten eines Netzwerkflusses wie z.B. Quellenadressinformationen, Signaturen von Anwendungsdaten, die im Netzwerkverkehr integriert sind (z.B. Malware), und andere Muster erkannt werden, von denen (über Informationsquellen für Bedrohungen) bekannt ist, dass sie auf einen bestimmten Typ eines bekannten Angriffs hinweisen. Zwar hat sich um diese beiden Möglichkeiten ein reichhaltiges Produktsortiment entwickelt, doch haben beide Ansätze ihre Grenzen.
Insbesondere im Hinblick auf forensisches Sammeln ist der Ansatz per Definition erst nach einem Ereignis anwendbar, d.h. nur dann, wenn Spezialisten für Cyberbedrohungen (z.B. in einem Security Operations Center (SOC)) die Fähigkeiten und die Zeit haben, den Datenverkehr, der in der Vergangenheit tatsächlich stattgefunden hat, zu identifizieren, um ihn nach einem Vorfall zu untersuchen oder Beweise zu sammeln. Eine Angriffserkennung in Echtzeit kann einen erheblichen Verarbeitungsaufwand verursachen, und ein voll ausgelastetes Netzwerk-Backbone im Rechenzentrum kann leicht dazu beitragen, dass der Punkt der Paketaufzeichnung und/oder Flussanalyse überlastet ist. Selbst dort, wo für diese Funktion separate Einheiten vorgesehen werden können, beeinträchtigt die CPU-Belastung für die Flussanalyse häufig die Skalierbarkeit. Und wenn eine solche Verarbeitung im Datenverkehrsfluss stattfindet (z.B. in einer Switch), wird der Aufgabe, die die Funktion implementiert, eine niedrigere Priorität zugewiesen als der primären Aufgabe dieser Einheit (verlustfreie Weiterleitung von Paketen), wodurch die Leistung möglicherweise beeinträchtigt wird.
KURZDARSTELLUNG
Ein weiteres Hindernis für die Analyse des Anwendungsdatenverkehrs ist die Tatsache, dass verschlüsselter Datenverkehr ohne erhebliche betriebliche Investitionen und Maßnahmen, die außerhalb von hochsicheren Standorten als sehr störend angesehen werden, für diese Art von Analyse undurchschaubar ist. Da der gesamte Datenverkehrsmix im Internet derzeit einen erheblichen Anteil an HTTPS-Datenverkehr aufweist, ist dies zwangsläufig eine Hürde, die für eine realistische Analyse des Datenvolumens und der Effizienz des Datenverkehrs überwunden werden muss.
Zu bekannten Mechanismen zum Beheben dieser Mängel gehören die Verwendung von Netzwerk-Web-Proxys sowie ein Hinterlegen von HTTPS-Schlüsseln. Beide Ansätze sind mit einem erheblichen betrieblichen Aufwand verbunden. So ist beispielsweise das Verfahren des Proxy-Verkehrs eine kostspielige Operation in Bezug auf Speicher- und Weiterleitungsverarbeitungszyklen, vor allem weil jede Übertragung am Weiterleitungspunkt neu verschlüsselt werden muss. Schlüsselhinterlegungssysteme, die zusätzliche Sicherheitsvorkehrungen bereitstellen, können in der Regel nur an gegenseitig anerkannten sicheren Standorten von Unternehmensnetzwerken implementiert werden; andernfalls können Anbieter für ein Beeinträchtigen der Integrität eines sicheren Benutzerdatenverkehrs haftbar gemacht werden.
In der Technik werden nach wie vor neue Ansätze zum Erkennen von Malware und anderen Netzwerkbedrohungen benötigt, vorzugsweise in nahezu Echtzeit und unabhängig davon, ob die Nutzdaten unverschlüsselt oder verschlüsselt sind.
Ein Verfahren, eine Vorrichtung und ein Computersystem zum Identifizieren von Bedrohungen in einem TCP/IP-gestützten Netzwerk. Der Ansatz nutzt einen Satz von Referenz-„Netzwerk-Spektralmustern“, die einem oder mehreren definierten „Kompromittierungsindikatoren“ (Indicators of Compromise, loCs) zugehörig sind. Bei einem Netzwerk-Spektralmuster handelt es sich um eine Codierung einer Paketaufzeichnung. In der Regel enthält ein Netzwerk-Spektralmuster einen Satz von intervallgebundenen Messungen der Datenverkehrsrate für jede Paarung adressierbarer Netzwerkschnittstellen in diesem aufgezeichneten Datenverkehr, Daten zum Identifizieren einer Dauer des Messintervalls, Ausrichtungsdaten, andere erfassbare Metadaten wie z.B. Quellen- und Zielteilnehmer, IP-Träger- und Anwendungsprotokolle sowie optional zusammenfassende Flussmetadaten zur Messentropie. Ein Netzwerk-Spektralmuster erstellt somit in der Regel ein Profil eines Netzwerkverkehrsmusters zwischen zwei oder mehreren Teilnehmern unter Verwendung eines Satzes von nutzdatenneutralen Sitzungsdaten. Wenn der Verkehr während eines oder mehrerer Intervalle, die in dem Netzwerk-Spektralmuster codiert werden, inaktiv ist (nichtvariierend), kann eine Zeitreihenkomprimierung selektiv angewendet werden, um die codierte Datenmenge zu verringern und so eine kompaktere Darstellung bereitzustellen. Vorzugsweise wird eine Bibliothek von Netzwerk-Spektralmustern dieses Typs erzeugt und für eine Bewertung zur Verfügung gestellt.
Zu diesem Zweck werden die einem zu prüfenden Datenverkehrsmuster zugehörigen Netzwerkverkehrsdaten empfangen und in einem Prüfnetzwerk-Spektralmuster codiert. Anschließend wird ein Echtzeitvergleich durchgeführt, um zu ermitteln, ob das Prüfnetzwerk-Spektralmuster mit einem der Referenznetzwerk-Spektralmuster übereinstimmt. Dieser Vergleich wird vorzugsweise in einem kontinuierlichen Datenstrom durchgeführt, wobei jeder Satz von Referenznetzwerk-Spektralmustern zunächst als Übereinstimmungskandidat identifiziert wird. Wenn das Vertrauen in eine bestimmte Übereinstimmung zwischen dem Prüfnetzwerk-Spektralmuster und einem bestimmten Referenznetzwerk-Spektralmuster unter einen konfigurierbaren Schwellenwert sinkt, wird das Referenznetzwerk-Spektralmuster aus dem Satz entfernt. Der Prozess wird dann so lange fortgesetzt, bis mindestens ein Übereinstimmungskandidat übrig bleibt. Als Reaktion auf das Identifizieren des mindestens einen Übereinstimmungskandidaten ergreift das System dann eine bestimmte Abhilfe- oder Schadensbegrenzungsmaßnahme. In einem beispielhaften Anwendungsfall stellen die Referenznetzwerk-Spektralmuster einen Satz von Datenverkehrsmustern dar, vor denen gewarnt werden soll; sobald der Übereinstimmungskandidat gefunden wurde, stellt das System einem SIEM oder einer anderen Netzwerksicherheitseinheit oder einem solchen System eine Meldung bereit, dass die Übereinstimmung gefunden wurde.
Die vorstehenden Ausführungen haben einige der wichtigsten Merkmale des behandelten Gegenstands aufgezeigt. Diese Merkmale sind lediglich als Beispiele zu verstehen. Viele weitere vorteilhafte Ergebnisse lassen sich erzielen, wenn der offenbarte Gegenstand auf andere Weise angewendet wird oder wenn der Gegenstand wie im Folgenden beschrieben abgewandelt wird.
Figurenliste
Zum besseren Verständnis des Gegenstandes und seiner Vorteile wird nun auf die folgenden Beschreibungen in Verbindung mit den beigefügten Zeichnungen verwiesen, in denen:

1 ein beispielhaftes Blockschaubild einer verteilten Datenverarbeitungsumgebung zeigt, in der beispielhafte Aspekte der veranschaulichenden Ausführungsformen implementiert werden können;
2 ein beispielhaftes Blockschaubild eines Datenverarbeitungssystems ist, in dem beispielhafte Aspekte der veranschaulichenden Ausführungsformen implementiert werden können;
3 eine Sicherheitsinformationsplattform veranschaulicht, in der die Techniken dieser Offenbarung angewendet werden können;
4 ein System zum Sammeln von Netzwerkflussdaten zeigt, in dem die Technik dieser Offenbarung implementiert werden kann;
5 ein repräsentatives Netzwerk-Spektralmuster zeigt, das einen HTTPS-gestützten Datenverkehrsfluss darstellt;
6 ein weiteres repräsentatives Netzwerk-Spektralmuster zeigt, das einen Malware-Bot darstellt;
7 eine Technik zur Netzwerk-Spektralmusteranalyse dieser Offenbarung zeigt;
8 eine repräsentative Pseudocode-Liste für eine Spektralmuster-Abgleichroutine ist;
9 ein ausführlicheres Beispiel für die in 7 dargestellte Technik der Netzwerk-Spektralmusteranalyse ist;
10 ein beispielhaftes Netzwerk-Spektralmuster ist, das mithilfe einer Soft-Axis-Zeitreihenkomprimierung verarbeitet wird, um die Variabilität in (nichtentropischen) Null-Volumen-Codierungsintervallen zu berücksichtigen, die andernfalls die Genauigkeit des Spektralmusters beeinträchtigen könnten; und
11 ein repräsentatives Betriebsszenario mit mehreren Teilnehmern zeigt, in dem die Techniken dieser Offenbarung ebenfalls implementiert werden können.

AUSFÜHRLICHE BESCHREIBUNG EINER VERANSCHAULICHENDEN AUSFÜHRUNGSFORM
Mit Bezug nunmehr auf die Zeichnungen und insbesondere mit Bezug auf die 1 und 2 werden beispielhafte Darstellungen von Datenverarbeitungsumgebungen bereitgestellt, in denen veranschaulichende Ausführungsformen der Offenbarung implementiert werden können. Es sei darauf hingewiesen, dass die 1 und 2 nur beispielhaft sind und nicht darauf abzielen, Einschränkungen in Bezug auf die Umgebungen, in denen Aspekte oder Ausführungsformen des offenbarten Gegenstands implementiert werden können, geltend zu machen oder zu implizieren. Es können zahlreiche Änderungen an den dargestellten Umgebungen vorgenommen werden, ohne vom Erfindungsgedanken und Anwendungsbereich der vorliegenden Erfindung abzuweichen.
Mit Bezug auf die Zeichnungen zeigt 1 eine bildliche Darstellung eines beispielhaften verteilten Datenverarbeitungssystems, in dem Aspekte der veranschaulichenden Ausführungsformen implementiert werden können. Das verteilte Datenverarbeitungssystem 100 kann ein Netzwerk von Computern enthalten, in dem Aspekte der veranschaulichenden Ausführungsformen implementiert werden können. Das verteilte Datenverarbeitungssystem 100 enthält mindestens ein Netzwerk 102, das als Medium verwendet wird, um Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern bereitzustellen, die in dem verteilten Datenverarbeitungssystem 100 miteinander verbunden sind. Das Netzwerk 102 kann Verbindungen wie beispielsweise drahtgebundene, drahtlose Datenübertragungsverbindungen oder Lichtwellenleiterkabel enthalten.
In dem dargestellten Beispiel sind der Server 104 und der Server 106 zusammen mit der Speichereinheit 108 mit dem Netzwerk 102 verbunden. Die Clients 110, 112 und 114 sind darüber hinaus ebenfalls mit dem Netzwerk 102 verbunden. Bei diesen Clients 110, 112 und 114 kann es sich zum Beispiel um Personal Computer, Netzwerkcomputer oder Ähnliches handeln. In dem dargestellten Beispiel stellt der Server 104 den Clients 110, 112 und 114 Daten wie beispielsweise Boot-Dateien, Betriebssystembilder und Anwendungen bereit. Die Clients 110, 112 und 114 sind in dem dargestellten Beispiel Clients des Servers 104. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients und sonstige Einheiten enthalten, die nicht dargestellt sind.
In dem dargestellten Beispiel handelt es sich bei dem verteilten Datenverarbeitungssystem 100 um das Internet mit dem Netzwerk 102, das einen weltweiten Verbund von Netzwerken und Gateways darstellt, die die Protokollfamilie „Transmission Control Protocol/Internet Protocol“ (TCP/IP) verwenden, um Daten miteinander auszutauschen. Kernstück des Internets sind Hochgeschwindigkeits-Datenübertragungsleitungen zwischen großen Knoten oder Host-Computern, die aus Tausenden von gewerblichen, staatlichen, bildungsbezogenen und sonstigen Computersystemen bestehen, die Daten und Nachrichten weiterleiten. Das verteilte Datenverarbeitungssystem 100 kann natürlich auch so umgesetzt werden, dass es eine Reihe von verschiedenen Netzwerkarten enthält, so beispielsweise ein Intranet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN) oder Ähnliches. Wie vorstehend erwähnt, ist 1 als ein Beispiel zu verstehen und nicht als eine architektonische Beschränkung verschiedener Ausführungsformen des offenbarten Gegenstands, daher sind die in 1 gezeigten besonderen Elemente nicht als einschränkend in Bezug auf die Umgebungen anzusehen, in denen die veranschaulichenden Ausführungsformen der vorliegenden Erfindung implementiert werden können.
Mit Bezug nunmehr auf 2 wird ein Blockschaubild eines beispielhaften Datenverarbeitungssystems gezeigt, in dem Aspekte der veranschaulichenden Ausführungsformen implementiert werden können. Das Datenverarbeitungssystem 200 ist ein Beispiel für einen Computer wie beispielsweise der Client 110 in 1, in dem sich vom Computer verwendbarer Code oder Anweisungen befinden können, die die Prozesse für veranschaulichende Ausführungsformen der Offenbarung implementieren.
Mit Bezug nunmehr auf 2 wird ein Blockschaubild eines Datenverarbeitungssystems gezeigt, in dem veranschaulichende Ausführungsformen implementiert werden können. Das Datenverarbeitungssystem 200 ist ein Beispiel eines Computers wie beispielsweise der Server 104 oder der Client 110 in 1, in dem sich vom Computer verwendbarer Programmcode oder Anweisungen befinden können, die die Prozesse für die veranschaulichenden Ausführungsformen implementieren. In diesem veranschaulichenden Beispiel umfasst das Datenverarbeitungssystem 200 die Datenübertragungsstruktur 202, die Datenübertragungen zwischen der Prozessoreinheit 204, dem Arbeitsspeicher 206, dem permanenten Speicher 208, der Datenübertragungseinheit 210, der Eingabe/Ausgabe(E/A)-Einheit 212 und der Anzeige 214 bereitstellt.
Die Prozessoreinheit 204 dient zum Ausführen von Anweisungen für Software, die in den Arbeitsspeicher 206 geladen werden können. Bei der Prozessoreinheit 204 kann es sich je nach besonderer Implementierung um einen Satz von einem oder mehreren Prozessoren oder um einen Mehrprozessorkern handeln. Die Prozessoreinheit 204 kann des Weiteren mit einem oder mehreren heterogenen Prozessorsystemen implementiert werden, bei denen ein Hauptprozessor mit sekundären Prozessoren auf einem einzelnen Chip vorhanden ist. In einem weiteren veranschaulichenden Beispiel kann es sich bei der Prozessoreinheit 204 um ein symmetrisches Mehrprozessorsystem (SMP) mit mehreren Prozessoren desselben Typs handeln.
Der Arbeitsspeicher 206 und der permanente Speicher 208 sind Beispiele für Speichereinheiten. Eine Speichereinheit ist jede Art von Hardware, die in der Lage ist, Informationen entweder vorübergehend und/oder dauerhaft zu speichern. Bei dem Speicher 206 kann es sich in diesen Beispielen z.B. um einen Direktzugriffsspeicher oder eine andere geeignete flüchtige oder nichtflüchtige Speichereinheit handeln. Der permanente Speicher 208 kann je nach besonderer Implementierung verschiedene Formen aufweisen. Beispielsweise kann der permanente Speicher 208 eine oder mehrere Komponenten oder Einheiten enthalten. Der permanente Speicher 208 kann z.B. eine Festplatte, ein Flash-Speicher, eine wiederbeschreibbare optische Platte, ein wiederbeschreibbares Magnetband oder eine beliebige Kombination daraus sein. Die vom permanenten Speicher 208 verwendeten Medien können wechselbar sein. Für den permanenten Speicher 208 kann beispielsweise eine wechselbare Festplatte verwendet werden.
Die Datenübertragungseinheit 210 stellt in diesen Beispielen Datenübertragungen mit anderen Datenverarbeitungssystemen oder-einheiten bereit. In diesen Beispielen handelt es sich bei der Datenübertragungseinheit 210 um eine Netzwerkschnittstellenkarte. Die Datenübertragungseinheit 210 kann Datenübertragungen über physische und drahtlose Datenübertragungsverbindungen bereitstellen und zwar über eine von beiden oder aber über beide.
Die Eingabe-/Ausgabeeinheit 212 ermöglicht die Eingabe und Ausgabe von Daten mit anderen Einheiten, die mit dem Datenverarbeitungssystem 200 verbunden werden können. Beispielsweise kann die Eingabe-/Ausgabeeinheit 212 eine Verbindung für Benutzereingaben über eine Tastatur und eine Maus bereitstellen. Weiterhin kann die Eingabe-/Ausgabeeinheit 212 eine Ausgabe an einen Drucker senden. Die Anzeige 214 stellt einen Mechanismus bereit, um einem Benutzer Informationen anzuzeigen.
Anweisungen für das Betriebssystem und Anwendungen oder Programme befinden sich in dem permanenten Speicher 208. Diese Anweisungen können zum Ausführen durch die Prozessoreinheit 204 in den Arbeitsspeicher 206 geladen werden. Die Prozesse der verschiedenen Ausführungsformen können von der Prozessoreinheit 204 mithilfe von durch einen Computer implementierten Anweisungen durchgeführt werden, die sich in einem Speicher, z.B. dem Arbeitsspeicher 206, befinden können. Diese Programmanweisungen werden als Programmcode, durch einen Computer verwendbarer Programmcode oder durch einen Computer lesbarer Programmcode bezeichnet, der von einem Prozessor in der Prozessoreinheit 204 gelesen und ausgeführt werden kann. Der Programmcode kann in den verschiedenen Ausführungsformen auf verschiedenen physischen, durch einen Computer lesbaren Speichereinheiten, z.B. dem Arbeitsspeicher 206 oder dem permanenten Speicher 208, enthalten sein.
Der Programmcode 216 befindet sich in funktionaler Form auf einem durch einen Computer lesbaren Medium 218, das selektiv wechselbar ist und auf das Datenverarbeitungssystem 200 geladen oder übertragen werden kann, um von der Prozessoreinheit 204 ausgeführt zu werden. Der Programmcode 216 und das durch einen Computer lesbare Medium 218 bilden in diesen Beispielen das Computerprogrammprodukt 220. In einem Beispiel kann das durch einen Computer lesbare Speichermedium 218 in physischer Form wie beispielsweise als optische oder magnetische Platte vorliegen, die in ein Laufwerk oder eine andere Einheit, die Teil des permanenten Speichers 208 ist, zum Übertragen auf eine Speichereinheit, z.B. eine Festplatte, die Teil des permanenten Speichers 208 ist, eingelegt oder eingesetzt wird. In physischer Form kann das durch einen Computer lesbare Speichermedium 218 auch die Form eines permanenten Speichers haben, z.B. einer mit dem Datenverarbeitungssystem 200 verbundenen Festplatte, einem damit verbundenen Thumb-Drive oder Flash-Speicher. Die physische Form der durch einen Computer lesbaren Medien 218 wird auch als durch einen Computer beschreibbare Speichermedien bezeichnet. In manchen Fällen sind die durch einen Computer beschreibbaren Medien 218 nicht wechselbar.
Alternativ kann der Programmcode 216 von durch einen Computer lesbaren Medien 218 über eine Datenübertragungsverbindung zur Datenübertragungseinheit 210 und/oder über eine Verbindung zur Eingabe-/Ausgabeeinheit 212 auf das Datenverarbeitungssystem 200 übertragen werden. Die Datenübertragungsverbindung und/oder die Verbindung kann in den veranschaulichenden Beispielen physisch oder drahtlos sein. Bei den durch einen Computer lesbaren Medien kann es sich auch um nichtphysische Medien handeln, z.B. Datenübertragungsverbindungen oder drahtlose Übertragungen, die den Programmcode enthalten. Die verschiedenen Komponenten, die für das Datenverarbeitungssystem 200 veranschaulicht werden, sollen keine Architekturbeschränkungen der Art und Weise bereitstellen, wie verschiedene Ausführungsformen implementiert werden können. Die verschiedenen veranschaulichenden Ausführungsformen können in einem Datenverarbeitungssystem implementiert werden, das Komponenten zusätzlich zu den oder anstelle der für das Datenverarbeitungssystem 200 dargestellten Komponenten enthält. Weitere in 2 dargestellte Komponenten können von den veranschaulichenden Beispielen abweichen. Eine Speichereinheit im Datenverarbeitungssystem 200 ist beispielsweise eine beliebige Hardwarevorrichtung, die Daten speichern kann. Der Arbeitsspeicher 206, der permanente Speicher 208 und das durch einen Computer lesbare Speichermedium 218 sind Beispiele für Speichereinheiten in physischer Form.
In einem anderen Beispiel kann ein Bussystem zum Implementieren der Datenübertragungsstruktur 202 verwendet werden und aus einem oder mehreren Bussen bestehen, z.B. aus einem Systembus oder einem Eingabe-/Ausgabebus. Selbstverständlich kann das Bussystem mit jeder geeigneten Architektur implementiert werden, die eine Datenübertragung zwischen verschiedenen an das Bussystem angeschlossenen Komponenten oder Einheiten bereitstellt. Eine Datenübertragungseinheit kann darüber hinaus eine oder mehrere Einheiten wie ein Modem oder einen Netzwerkadapter aufweisen, die verwendet werden, um Daten zu übertragen und zu empfangen. Ferner kann es sich bei dem Arbeitsspeicher beispielsweise um den Arbeitsspeicher 206 oder einen Cache handeln, wie er in einer Schnittstelle und einem Arbeitsspeicher-Controller-Hub vorkommt, die in einer Datenübertragungsstruktur 202 vorhanden sein können.
Computerprogrammcode zum Ausführen von Operationen der vorliegenden Erfindung kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen geschrieben werden, zu denen eine objektorientierte Programmiersprache wie beispielsweise Java™, Smalltalk, C++ oder ähnliche sowie herkömmliche prozedurale Programmiersprachen wie beispielsweise die Programmiersprache „C“ oder ähnliche Programmiersprachen gehören. Der Programmcode kann ganz auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder ganz auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters).
Fachleute erkennen, dass die Hardware in den 1 und 2 je nach Implementierung variieren kann. Andere interne Hardware- oder periphere Einheiten wie ein Flash-Speicher, ein gleichwertiger nichtflüchtiger Speicher oder Laufwerke für optische Platten oder Ähnliches können zusätzlich oder anstelle der in den 1 und 2 dargestellten Hardware verwendet werden. Zusätzlich können die Prozesse der veranschaulichenden Ausführungsformen auf ein anderes Mehrprozessor-Datenverarbeitungssystem als das zuvor genannte SMP-System angewendet werden, ohne vom Erfindungsgedanken und Anwendungsbereich des offenbarten Gegenstands abzuweichen.
Wie ersichtlich werden wird, können die hier beschriebenen Techniken in Verbindung mit dem standardmäßigen Client-Server-Paradigma, z.B. wie in 1 dargestellt, funktionieren, bei dem Client-Maschinen mit einem über das Internet zugänglichen webgestützten Portal Daten austauschen, das auf einem Satz von einem oder mehreren Maschinen ausgeführt wird. Endbenutzer verwenden internetfähige Einheiten (z.B. Desktop-Computer, Notebook-Computer, internetfähige mobile Einheiten oder Ähnliches), die in der Lage sind, auf das Portal zuzugreifen und mit ihm zu interagieren. In der Regel handelt es sich bei jeder Client- oder Server-Maschine um ein Datenverarbeitungssystem, wie es in 2 dargestellt ist, das Hardware und Software aufweist, und diese Entitäten übertragen untereinander Daten über ein Netzwerk wie z.B. das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein anderes Datenübertragungsmedium oder eine andere Verbindung. Ein Datenverarbeitungssystem umfasst in der Regel einen oder mehrere Prozessoren, ein Betriebssystem, eine oder mehrere Anwendungen und ein oder mehrere Dienstprogramme. Die Anwendungen im Datenverarbeitungssystem stellen native Unterstützung für Webdienste bereit, darunter Unterstützung für unter anderem HTTP, SOAP, XML, WSDL, UDDI und WSFL, ohne auf diese beschränkt zu sein. Informationen zu SOAP, WSDL, UDDI und WSFL sind beim World Wide Web Consortium (W3C) erhältlich, das für das Entwickeln und Pflegen dieser Standards verantwortlich ist; weitere Informationen zu HTTP und XML sind bei der Internet Engineering Task Force (IETF) erhältlich. Die Kenntnis dieser Standards wird vorausgesetzt.
Sicherheitsinformationsplattform
Die Netzwerke von heute sind größer und komplexer als je zuvor, und der Schutz vor bösartigen Angriffen ist eine niemals endende Aufgabe. Unternehmen, die ihr geistiges Eigentum schützen, die Identität ihrer Kunden wahren, Unterbrechungen des Geschäftsbetriebs vermeiden wollen usw., müssen mehr tun, als nur Protokolle und Netzwerkflussdaten zu überwachen; viele Unternehmen erzeugen jeden Tag Millionen oder sogar Milliarden von Ereignissen, und es ist schwierig, diese Daten auf eine kurze Liste vorrangiger Verstöße zusammenzufassen.
Zu bekannten Sicherheitsprodukten gehören Security-Incident-and-Event-Management(SIEM)-Lösungen, die auf regelgestützten Mechanismen zum Bewerten beobachteter Sicherheitsereignisse aufbauen. SIEM-Systeme und -Verfahren sammeln, standardisieren und korrelieren verfügbare Netzwerkdaten. Ein Sicherheitsinformationsprodukt dieser Art ist IBM^® QRadar^® SIEM, das eine Reihe von Plattformtechnologien bereitstellt, die Netzwerkflussdaten überprüfen, um gültige Hosts und Server (Assets) im Netzwerk zu finden und zu klassifizieren und die von ihnen verwendeten Anwendungen, Protokolle, Dienste und Anschlüsse zu erfassen. Das Produkt sammelt, speichert und analysiert diese Daten und führt eine Ereigniskorrelation in Echtzeit durch, die zum Erkennen von Bedrohungen und Erstellen von Berichten und Audits über die Einhaltung von Vorschriften verwendet werden kann. Mithilfe dieser Plattform können Milliarden von Ereignissen und Datenflüssen entsprechend ihrer geschäftlichen Auswirkungen auf eine Handvoll verfolgbarer Verstöße verringert und priorisiert werden.
Netzwerk-Transaktionen bestehen in der Regel aus einer Reihe von mehreren Paketen zwischen einem Server und einem Client. Mit der Verbreitung der Sicherheitsüberwachung und der Verwendung von SIEMs entscheiden sich viele Unternehmen dafür, diese Datenflussinformationen zu sammeln, um Gefahren im Internet zu erkennen. Angesichts des ständig wachsenden Datenverkehrs im Netzwerk wird der Bedarf an Mechanismen, die eine schnelle Korrelation unterschiedlicher Datensätze ermöglichen, immer wichtiger. Eine solche Ansicht, die bei Sicherheitsoperationen nützlich ist, ist die Möglichkeit nachzuverfolgen, was in einer bestimmten Datenflusssitzung passiert ist. Derzeitige Mechanismen zum Definieren und Abfragen von Datenflüssen in einer bestimmten Datenflusssitzung sind jedoch in der Regel eng mit dem Wissen darüber verbunden, welcher Datenflusssammler den Datenverkehr gesehen hat, welches Protokoll verwendet wurde und welche Datenflussfelder vorhanden waren. Beispielsweise kann eine Korrelation zwischen zwei verschiedenen Netzwerk-Datenflusssammlern erforderlich sein, die unterschiedliche Hälften derselben Sitzung sehen (d.h. asymmetrisches Weiterleiten und Rekombinieren), oder es kann eine Korrelation zwischen einem Netzwerk-Datenflusssammler und einem Ereignisprotokollsammler erforderlich sein.
Ein bekannter Typ einer Sicherheitsinformationsplattform ist in 3 dargestellt. Im Allgemeinen stellt die Plattform suchgesteuerte Datenexploration, Sitzungsrekonstruktion und forensische Informationen bereit, um ein Untersuchen von Sicherheitsereignissen zu unterstützen. Die Plattform 300 weist genauer einen Satz von Paketaufzeichnungsgeräten 302, ein Ereignisforensik-Modulgerät 304, eine verteilte Datenbank 306 und eine Sicherheitsinformationskonsole 308 auf. Die Paketaufzeichnungs- und Modulgeräte sind entweder als Netzwerkgeräte oder als virtuelle Geräte konfiguriert. Die Paketaufzeichnungsgeräte 302 sind funktionsmäßig in der Lage, Pakete aus dem Netzwerk aufzuzeichnen (mithilfe bekannter Anwendungsprogrammierschnittstellen (APIs) für die Paketaufzeichnung (pcap) oder anderer bekannter Techniken) und solche Daten (z.B. Echtzeit-Protokollereignis und Netzwerkfluss) der verteilten Datenbank 306 bereitzustellen, wo die Daten gespeichert werden und für die Analyse durch das Forensikmodul 304 und die Sicherheitsinformationskonsole 308 zur Verfügung stehen. Ein Paketaufzeichnungsgerät arbeitet sitzungsorientiert, zeichnet alle Pakete in einem Datenfluss auf und indiziert Metadaten und Nutzdaten, um eine schnelle, suchgestützte Datenexploration zu ermöglichen. Die Datenbank 306 stellt eine Forensik-Datenablage mit verteilten und heterogenen Datensätzen bereit, die die von den Paketaufzeichnungsgeräten gesammelten Informationen aufweisen. Die Konsole 308 stellt eine Benutzerschnittstelle (UI) bereit, auf die über das Web oder die Cloud zugegriffen werden kann und die eine Dashboard-Registerkarte „Forensik“ enthält, um den Arbeitsablauf bei der Untersuchung eines Ereignisses durch einen Ermittler zu erleichtern. Über das Dashboard wählt ein Ermittler ein Sicherheitsereignis aus. Das Ereignisforensikmodul 304 ruft alle Pakete (einschließlich Metadaten, Nutzdaten usw.) für ein ausgewähltes Sicherheitsereignis ab und rekonstruiert die Sitzung zur Analyse.
Ein repräsentatives kommerzielles Produkt, das einen Arbeitsablauf zum Untersuchen von Ereignissen dieser Art implementiert, ist IBM^® Security QRadar^® Incident Forensics. Mithilfe dieser Plattform sucht ein Ermittler in den verteilten und heterogenen Datensätzen, die in der Datenbank gespeichert sind, und empfängt eine einheitliche Suchergebnisliste. Die Suchergebnisse können in einem Raster zusammengeführt und in einem Werkzeug für einen „digitalen Abdruck“ visualisiert werden, sodass der Benutzer Beziehungen zwischen Identitäten untersuchen kann.
Im Einzelnen wird nun eine typische forensische Untersuchung eines Ereignisses beschrieben, um relevante Daten aus einem Netzwerkdatenverkehr und Dokumenten in der Forensik-Datenablage zu extrahieren. Gemäß diesem Ansatz ermöglicht die Plattform einen einfachen allgemeinen Ansatz, bei dem zunächst viele Datensätze gesucht und gekennzeichnet werden. Anschließend kann sich der Ermittler auf die gekennzeichneten Datensätze konzentrieren, um einen endgültigen Satz von Datensätzen zu identifizieren. In einem typischen Arbeitsablauf bestimmt ein Ermittler, welches Material relevant ist. Er verwendet dieses Material dann, um eine Hypothese oder einen „Fall“ zu beweisen, um neue Hinweise zu entwickeln, die mithilfe anderer Verfahren in einem bestehenden Fall weiterverfolgt werden können. In der Regel grenzt der Ermittler seine Untersuchung zunächst durch allgemein definierte Maßnahmen ein, um dann diese Erkenntnisse zu verfeinern und zu einem relevanten endgültigen Satz von Ergebnissen zu entwickeln. Der untere Teil von 3 veranschaulicht diesen grundlegenden Arbeitsablauf. Visualisierungs- und Analysewerkzeuge der Plattform können dann genutzt werden, um die Ergebnisse manuell und automatisch auf ihre Relevanz zu prüfen. Die entsprechenden Datensätze können gedruckt, exportiert oder zum Verarbeiten übermittelt werden.
Wie bereits erwähnt, stellt die Plattformkonsole eine Benutzerschnittstelle bereit, die diesen Arbeitsablauf ermöglicht. So stellt die Plattform zum Beispiel eine Suchergebnisseite als Standardseite auf einer Registerkarte der Benutzeroberfläche bereit. Ermittler nutzen die Suchergebnisse, um nach Dokumenten zu suchen und darauf zuzugreifen. Der Ermittler kann weiterhin auf andere Hilfsmittel zurückgreifen, um die Untersuchung fortzusetzen. Bekannte Entitäten oder Personen, die im Netzwerkdatenverkehr und in Dokumenten gefunden werden, werden automatisch gekennzeichnet. Das Ereignisforensikmodul 304 ist funktionsmäßig in der Lage, markierte Kennungen, die miteinander interagieren, zu korrelieren. Die Sammelbeziehungen stellen in der Regel eine kontinuierlich gesammelte elektronische Präsenz dar, die einem Angreifer oder einer netzwerkbezogenen Entität zugehörig ist.
In der Regel wird ein Gerät zur Verwendung in dem vorstehend beschriebenen System als eine mit dem Netzwerk verbundene Einheit ohne Anzeige implementiert. So sind beispielsweise Geräte, die eigens zum Durchführen herkömmlicher Middleware-Funktionen einer serviceorientierten Architektur (SOA) entwickelt wurden, in bestimmten Computerumgebungen weit verbreitet. SOA-Middleware-Geräte können Implementierungen von XML- und Webdiensten vereinfachen, absichern oder beschleunigen, während sie eine bestehende SOA-Infrastruktur in einem Unternehmen erweitern. Durch den Einsatz von Middleware-Hardware und einem einfachen Middleware-Stack können die Leistungsprobleme herkömmlicher Softwarelösungen behoben werden. Darüber hinaus stellt der Geräteformfaktor eine sichere, verwendbare Paketierung zum Implementieren von Middleware-SOA-Funktionen bereit. Ein besonderer Vorteil, den diese Arten von Einheiten bereitstellen, ist ein Auslagern der Verarbeitung von Back-End-Systemen. Bei einem Netzwerkgerät dieses Typs handelt es sich in der Regel um eine Einschubeinheit. Die Einheit umfasst physische Sicherheitsvorkehrungen, die es ermöglichen, das Gerät als sicheren Ort für sensible Daten zu nutzen. In der Regel wird das Gerät hergestellt, Software darauf vorinstalliert und dann innerhalb eines Unternehmens oder in Verbindung mit einer anderen Netzwerk-Betriebsumgebung implementiert. Alternativ kann das Gerät auch lokal aufgestellt und dann mit standardmäßigen oder kundenspezifischen virtuellen Middleware-Abbildern ausgestattet werden, die sicher implementiert und verwaltet werden können, z.B. innerhalb einer privaten oder vor Ort befindlichen Cloud-Computing-Umgebung. Das Gerät kann kryptografische Unterstützung durch Hardware und Firmware umfassen, möglicherweise zum Verschlüsseln von Daten auf einer Festplatte. Kein Benutzer, auch kein Verwaltungsmitarbeiter, kann auf Daten auf der physischen Festplatte zugreifen. Das Betriebssystem (z.B. Linux) sperrt insbesondere vorzugsweise das Benutzerkonto mit Rootberechtigung und stellt keine Befehlsshell bereit, und der Benutzer hat keinen Zugriff auf das Dateisystem. In der Regel umfasst das Gerät keine Anzeigeeinheit, kein CD- oder anderes optisches Laufwerk und keine USB-, Firewire- oder anderen Anschlüsse, an die Einheiten angeschlossen werden können. Es ist als abgedichtete und sichere Umgebung mit begrenztem Zugang konzipiert, zu der nur authentifizierte und befugte Personen Zugang haben.
Ein Gerät dieses Typs kann das Security Information Event Management (SIEM) ermöglichen. IBM^® Security QRadar^® SIEM ist zum Beispiel eine Unternehmenslösung, die Paketdatenaufzeichnungsgeräte umfasst, die als Geräte dieser Art konfiguriert werden können. Eine solche Einheit ist funktionsmäßig z.B. in der Lage, Netzwerkflussdaten der Ebene 4 in Echtzeit aufzuzeichnen, aus denen dann Anwendungsnutzdaten der Ebene 7 analysiert werden können, z.B. mit einer umfassenden Paketprüfung und anderen Technologien. Sie sensibilisiert für die Situation und stellt Unterstützung bei der Einhaltung von Vorschriften bereit, indem sie eine Kombination aus datenflussgestütztem Netzwerkwissen, Korrelation von Sicherheitsereignissen und Asset-gestützter Schwachstellenbewertung nutzt. In einer grundlegenden QRadar-SIEM-Installation ist das System, wie es z.B. in 3 dargestellt ist, so konfiguriert, dass es Ereignis- und Flussdaten sammelt und Berichte erzeugt. Wie bereits erwähnt, kann ein Benutzer (z.B. ein SOC-Analyst) Verstöße untersuchen, um die Ursache für ein Netzwerkproblem zu ermitteln.
Generell stellen SIEM-Werkzeuge (SIEM - Security Information and Event Management) eine Reihe von Diensten zum Analysieren, Verwalten, Überwachen und Melden von IT-Sicherheitsereignissen und Schwachstellen bereit. Solche Dienste umfassen in der Regel Sammeln von Ereignissen in Bezug auf überwachte Zugriffe und unerwartete Vorkommnisse im gesamten Datennetzwerk sowie deren Analyse in einem korrelativen Kontext, um ihren Beitrag zu profilbezogenen Sicherheitsereignissen höherer Ordnung zu ermitteln. Sie können auch eine Analyse von Firewall-Konfigurationen, Werkzeugen zum Visualisieren von Netzwerktopologie und -verbindungen zur Ansicht aktueller und potenzieller Netzwerkverkehrsmuster, eine Korrelation von Asset-Schwachstellen mit der Netzwerkkonfiguration und dem Datenverkehr zum Identifizieren aktiver Angriffspfade und risikoreicher Assets sowie die Unterstützung eines Überwachens der Einhaltung von Richtlinien in Bezug auf Netzwerkverkehr, Topologie und Schwachstellen umfassen. Einige SIEM-Werkzeuge sind in der Lage, eine Topologie verwalteter Netzwerkeinheiten wie z.B. Router, Firewalls und Switches auf der Grundlage einer Transformationsanalyse von Einheitenkonfigurationen zu erstellen, die über ein gemeinsames Netzwerkinformationsmodell verarbeitet werden. Das Ergebnis ist eine Standortorganisation, die für Simulationen von Sicherheitsbedrohungen, Betriebsanalysen von Firewall-Filtern und andere Anwendungen verwendet werden kann. Die Hauptkriterien für die Einheit beruhen jedoch ausschließlich auf dem Netzwerk und der Netzwerkkonfiguration. Es gibt zwar eine Reihe von Möglichkeiten, eine Erkennungsfunktion für verwaltete Assets/Systeme zu starten, und auch wenn die Eingrenzung in der Benutzerschnittstelle halbautomatisch verwaltet wird (d.h., ein Ansatz über die Benutzerschnittstelle, der halbautomatische, auf menschlichen Eingaben gestützte Verteilungen ermöglicht, wobei die Topologie und ihre Anzeige und Formatierung datengestützt auf der Erkennung sowohl von Anfangskonfigurationen als auch von Änderungen/Löschungen im zugrunde liegenden Netzwerk erfolgt), wird nichts in Bezug auf Verteilungsanalysen bereitgestellt, die vollautomatische Verteilungsanalysen und -vorschläge erzeugen.
Bei diesem Ansatz werden daher ausführliche Informationen über einen Verstoß aus einem SIEM-System wie z.B. QRadar extrahiert. Die Einzelheiten umfassen in der Regel die Art des Verstoßes, Regeln, Kategorien, IP-Quellen- und Zieladressen sowie Benutzernamen. Ein Verstoß kann zum Beispiel ein Verstoß der Kategorie Malware sein, der anzeigt, dass auf einer Maschine bösartige Software entdeckt wurde. Die Aktivitäten der Maschine müssen daher im Zusammenhang mit dem Verstoß untersucht werden, um Infektionsvektoren und mögliche Datenlecks zu ermitteln. Die Art der zu untersuchenden Aktivitäten hängt natürlich von der Art des Verstoßes ab.
Es gibt viele verschiedene Arten von Netzwerkflusssammlern, und oft sind Sammler spezifisch für ein bestimmtes Netzwerkflussprotokoll. Ein Beispiel ist IPFIX, ein anderes NetFlow, wobei letzteres eine Router-gestützte Funktion ist, die die Möglichkeit bereitstellt, den Internet-Protocol(IP)-Netzwerkverkehr zu sammeln, sobald er an einer Router-Schnittstelle ein- oder ausgeht. Durch Analysieren der von solchen Werkzeugen gesammelten Daten kann ein Netzwerkadministrator Quelle und Ziel des Datenverkehrs, eine Dienstklasse und Ursachen von Überlastungen identifizieren. Wie in 4 dargestellt, weist eine typische Einrichtung zum Überwachen von Datenflüssen einen Datenflussexporteur 400 auf, der Pakete zu Datenflüssen zusammenfasst und Datenflusssätze zu einem oder mehreren Sammlern exportiert, einen Datenflusssammler 402, der die von einem Datenflussexporteur empfangenen Flussdaten empfängt, speichert und vorverarbeitet, sowie eine Analyseanwendung 404, die die empfangenen Flussdaten analysiert, z.B. zum Erkennen von Angriffen von außen oder zum Erstellen von Datenverkehrsprofilen. In der Regel ist ein Datenfluss 406 als eine unidirektionale Folge von Paketen definiert, die alle die folgenden Werte teilen: Eingangsschnittstelle, IP-Quellenadresse, IP-Zieladresse, IP-Protokoll, Quellenport für UDP/TCP (0 für andere Protokolle), Zielport für UDP/TCP (oder Typ und Code für ICMP oder 0 für andere Protokolle) und Art des Dienstes. Wie in 4 dargestellt, kann ein Datensatz 408 eine große Vielfalt von Informationen über den Datenverkehr in einem bestimmten Datenfluss enthalten, z. B. Eingangsschnittstellenindex, der von SNMP verwendet wird, Ausgangsschnittstellenindex (oder Null, wenn das Paket verworfen wurde), Zeitstempel für die Start- und Endzeit des Datenflusses (in der Regel in Millisekunden seit dem letzten Booten), Anzahl der Bytes und Pakete, die im Datenfluss beobachtet wurden, Ebene-3-Header (IP-Quellen- und Zieladressen, ICMP-Typ und -Code, IP-Protokoll, Diensttyp-Wert (Type of Service - ToS), Quellen- und Zielanschlussnummern für TCP, UDP, SCTP, für TCP-Datenflüsse, ein Verbund aller TCP-Merker, die während der Lebensdauer des Datenflusses beobachtet wurden, Ebene-3-Weiterleitungsinformationen (z.B. IP-Adresse eines unmittelbaren Next-Hop entlang einer Weiterleitung zum Ziel) und IP-Quellen- und Zielmasken (Präfixlängen in der CIDR-Notation).
Es gibt viele andere Arten von Exportprotokollen für Netzwerkdatenflüsse und zugehörige Sammelmechanismen. Ein weiteres Beispiel ist sFlow (Kurzform für „sampled flow“), ein Industriestandard für den Paketexport auf OSI-Ebene 2. Er stellt eine Möglichkeit bereit, abgeschnittene Pakete zusammen mit Schnittstellenzählern zum Überwachen des Netzwerks zu exportieren. Zu anderen Beispielen zählen wie bereits erwähnt IPFIX. Jedes der Datenfluss-Exportprotokolle erzeugt Datenfluss-Datensätze. Wie nachfolgend beschrieben, funktioniert die Technik dieser Offenbarung mit jedem Exportprotokoll für Netzwerkdatenflüsse, unabhängig von der Art und Semantik der erzeugten Datenfluss-Datensätze.
Die vorstehend beschriebenen Techniken zum Aufzeichnen von Paket- und Netzwerkdatenflüssen sind repräsentativ für die verschiedenen Betriebsumgebungen, in denen die Techniken dieser Offenbarung implementiert werden können. Wie beschrieben, kann der Ansatz zum schnellen Identifizieren und Erkennen hier mit verschiedenen Datenquellen (Echtzeitaufzeichnungen von Netzwerkaktivitäten) durchgeführt werden, darunter, ohne auf diese beschränkt zu sein, tatsächliche Paketaufzeichnungen, wobei zu Paketen eine Genauigkeit von Mikrosekunden (wenn nicht gar Nanosekunden) zum Aufzeichnen von Paketankunftszeiten gehört, sowie exportierte Netzwerkflüsse, bei denen Paketanzahl, Paketgrößen und andere Daten (z.B. Interframe Gaps, d.h. Ruheperioden zwischen dem Moment, in dem eine Quelle ein Datenpaket über ein Netzwerk sendet, und dem Zeitpunkt, zu dem ein Ziel antwortet) als Teil der exportierten Flussdaten gesammelt werden.
Damit Netzwerkdaten an einen Prozess weitergegeben werden können, der irgendeine Art von Analyse durchführt, muss es einen festgelegten Zeitraum geben, in dem Netzwerkdaten gesammelt und in Pakete gepackt werden (z.B. im Falle der Paketaufzeichnung immer in Form von PCAP und im Falle von Netzwerkflüssen als IPFIX-Nachrichten, die vom exportierenden Prozess oder der exportierenden Einheit gesendet werden). Im Rahmen der weiteren Offenbarung wird dieser festgelegte Zeitraum als „Sammelintervall“ bezeichnet. Bei der Analyse des Netzwerkverkehrs stellt das Sammelintervall eine übergeordnete Sammel- und Berichtseinheit von Interesse dar, z.B. wie der Datenflussexporteur seine Gesamtdaten bildet. Wie ersichtlich wird, kann das Vorhandensein und Einstellen dieses Intervalls ein Faktor für ein Abstimmen des Durchsatzes und der Echtzeit-Effektivität der hier beschriebenen Analysen sein.
Schnelles Identifizieren von Verstößen und Angriffen in Netzwerkverkehrsmustern
Vor dem Hintergrund der vorstehenden Ausführungen wird nun die Technik der vorliegenden Offenbarung beschrieben. Gemäß einem Aspekt werden die Datenverkehrsflüsse von Interesse, die sowohl den zu prüfenden Datenverkehr als auch einen Satz von Kandidaten-Datenverkehrsflüssen umfassen, mit denen das System versucht, diesen zu prüfenden Datenverkehr abzugleichen, in einem Darstellungsformat codiert. Wie bereits erwähnt, wird dieses Format hier als „Netzwerk-Spektralmuster“ bezeichnet. Der Grund für diesen Ansatz ist die Erkenntnis, dass der Netzwerkverkehr selbst konzeptionelle Ähnlichkeiten mit den Farben des sichtbaren Lichtspektrums und seinen spektralen Darstellungen aufweist. Während das sichtbare Spektrum zwar Merkmale oder Eigenschaften wie Helligkeit, Farbton, Pigmentierung und Ähnliches vermittelt, codiert der hier vorgestellte Ansatz in ähnlicher Weise einen Satz von Merkmalen oder Eigenschaften des Netzwerkverkehrs. Art und Typ dieser Merkmale/Eigenschaften können variieren, umfassen aber in der Regel Volumen, Protokollidentifizierung, Ausrichtung, nichtverschlüsselte Metadaten des Datenverkehrs (z.B. TCP-Protokoll- und Portäquivalenzen). Unter der Annahme eines Referenzmusters mit einigermaßen differenzierten Sammelintervallen und unabhängig von den tatsächlichen Nutzdaten und dem Inhalt des Datenverkehrs kann das Netzwerk-Spektralmuster für einen bestimmten Datenfluss einfach gestützt auf ein quantisiertes IP-Datenverkehrsvolumen (oder dessen Fehlen bei der Interframe-Übertragung), die Ausrichtung auf mehrere Teilnehmer und andere erfassbare Metadaten (z.B. das IP-Trägerprotokoll, d.h. TCP, UDP, ICMP, GGP usw.) abgeleitet werden. Dieses Muster (das Netzwerk-Spektralmuster) kann mehrdimensional sein oder sich einfach in der Anzahl der identifizierten Knoten in einem zusammengefassten Datenflusssatz wiederholen. Weiterhin kann dieser Ansatz wie nachfolgend beschrieben in einem einfachen Fall mit zwei Teilnehmern (z.B. ein Datenfluss zwischen zwei Endpunkten), aber auch in dem Fall, in dem mehrere Teilnehmer an dem Datenverkehrsfluss beteiligt sind, verwendet werden.
Formaler ausgedrückt ist ein Netzwerk-Spektralmuster eine Codierung einer Paketaufzeichnung. In der Regel enthält ein Netzwerk-Spektralmuster einen Satz von intervallgebundenen Messungen der Datenverkehrsrate für jede Paarung adressierbarer Netzwerkschnittstellen in diesem aufgezeichneten Datenverkehr, Daten zum Identifizieren einer Dauer des Messintervalls, Ausrichtungsdaten, andere erfassbare Metadaten wie z.B. Quellen- und Zielteilnehmer, IP-Träger- und Anwendungsprotokolle sowie optional zusammenfassende Flussmetadaten zur Messentropie. Auf der Grundlage dieser Codierung erstellt ein Netzwerk-Spektralmuster in der Regel ein Profil eines Netzwerkverkehrsmusters zwischen zwei oder mehreren Teilnehmern unter Verwendung eines Satzes von nutzdatenneutralen Sitzungsdaten. Wenn der Verkehr während eines oder mehrerer Intervalle, die in dem Netzwerk-Spektralmuster codiert werden, inaktiv ist (nichtvariierend), kann gemäß der nachfolgenden Beschreibung die Zeitreihenkomprimierung selektiv angewendet werden, um die codierte Datenmenge zu verringern und so eine kompaktere Darstellung bereitzustellen.
5 zeigt ein beispielhaftes Netzwerk-Spektralmuster 500 für einen einfachen Datenverkehrsfluss mit zwei Teilnehmern zwischen einer Quelle 502 und einem Ziel 504. Bei diesen Einheiten kann es sich um Datenverarbeitungssysteme handeln, wie z.B. in 2 dargestellt, die in einer Client-Server-Beziehung arbeiten, wie in 1 dargestellt.
Wie in 5 zu sehen ist, zeigt diese visuelle Darstellung die Datenverkehrsflüsse während der Dauer einer normalen HTTP-Sitzung mit dem Header „Connection: keep-alive“ in der ursprünglichen HTTP-Anforderung. Zwar gibt es keine völlig identischen Sitzungen dieses Typs, es gibt hier jedoch bestimmte erwartete Muster. Insbesondere überwiegt der Antwortdatenverkehr (unterhalb der Linie) bei Weitem das Volumen des anforderungsbezogenen Datenverkehrs (oberhalb der Linie). Wie ebenfalls ersichtlich ist, bilden die anfänglichen Antworten (links) den überwiegenden Teil der Übertragung, während kleinere Anforderungen folgen (z.B. parallel zum Abrufen einer Seite mit Multimedia-Inhalt, gefolgt vom integrierten Abrufen von Werbebannern, Ein-Pixel-Mechanismen zum Verfolgen von Anzeigen und Ähnliches). In dieser Darstellung sind zwei verschiedene identifizierte Protokolle zu sehen: TCP-Steuerungsdatenverkehr und TCP-Sitzungsdatenverkehr (fette Linien). Wie zu sehen ist, übermittelt das Netzwerk-Spektralmuster für diesen Datenfluss eine beträchtliche Menge an Informationen über die Sitzung insgesamt, jedoch auch ohne die Notwendigkeit einer Analyse des Inhalts (Nutzdaten) (z.B. durch einen Sicherheitsanalysten). Wenn es sich bei diesem Beispiel um eine HTTPS-Protokollsitzung handelt, wird sie mit dem Netzwerk-Spektralmusteransatz dieser Offenbarung analysiert, wobei gleichzeitig verwaltungstechnisch aufwändige Ansätze wie z.B. ein Hinterlegen von Schlüsseln am Datenverkehrsüberwachungspunkt oder die Verwendung spezieller Entschlüsselungseinheiten usw. vermieden werden.
6 zeigt ein weiteres Beispiel des Netzwerk-Spektralmusters 600, in diesem Fall ein Muster, das für ein potenzielles Sicherheitsereignis charakteristisch ist. Auch hier handelt es sich um einen Datenfluss zwischen zwei Teilnehmern, einer Quelle 602 und einem Ziel 604. In diesem Beispiel stellen die fettgedruckten Linien einen Zertifikatsaustausch und den Datenverkehr zum Steuern des Transports dar. Die Datenexfiltration wird mit der Bezugsziffer 606 und der Befehls- und Steuerungsdatenverkehr mit der Ziffer 608 dargestellt. Dieses Netzwerk-Spektralmuster ist demnach ein grafisches Muster, das für einen Malware-Bot repräsentativ ist. Wie im vorangegangenen Beispiel stellt das Netzwerk-Spektralmuster wichtige Informationen bereit, auch wenn der Datenverkehr anonymisiert ist und keine inhaltliche Transparenz besteht. Stattdessen werden die relevanten Informationen aus den verfügbaren Daten abgerufen, d.h. Datenmenge und -richtung, TCP-Paket-Header-Informationen, alternativer Protokollaustausch (z.B. X.509) und Ähnliches, und diese Informationen werden als charakteristisch für einen durch Malware verursachten Austausch identifiziert. In Anlehnung an die visuelle Spektralanalogie sind diese verfügbaren Datenelemente in diesem Beispiel vergleichbar mit den verschiedenen Farben oder Farbmerkmalen, die zusammen die visuelle Darstellung bilden.
Die Darstellungen in 5 und 6 sind Beispiele für Referenznetzwerk-Spektralmuster. Solche Darstellungen können z.B. zu einer Familie von Spektralmustern zusammengefasst werden, die einem allgemeineren Kompromittierungsindikator (loC) zugehörig sind. In diesem Fall können die Spektralmuster auch zugehörige „Vertrauenswerte“ (oder eine andere Priorisierung) aufweisen, die eine Ermittlung ihres relativen Potenzials zum Anzeigen des betreffenden loC widerspiegeln.
Im Allgemeinen werden die verschiedenen Datenelemente, die einen Datenverkehrsfluss von Interesse und insbesondere ein zu analysierendes Datenverkehrssegment aufweisen, hier manchmal als Dimensionen bezeichnet. Je nach Art und Typ des Datenflusses sowie der Anzahl der Teilnehmer am Datenfluss können die Dimensionen, die ein Netzwerk-Spektralmuster aufweisen, variieren, aber in der Regel sind sie nutzdatenneutral und auf der Ebene des Sitzungsdatenverkehrs definiert. Die Grenzen einer Sitzung werden durch ein Fünfer-Tupel des Datenflusses definiert, nämlich IP-Quellenadresse, IP-Zieladresse, Quellenport, Quellenziel und Protokoll. Hierbei handelt es sich um relevante Dimensionen, die in die Codierung einbezogen werden können. Andere umfassen Byteanzahl (Volumen), Paketanzahl, Sequenzierung der Byteanzahl, gepaarte Beobachtungen zur Paketanzahl, Richtung, nichtverschlüsselte Metadaten des Datenverkehrs (z.B. TCP-Protokoll und Portäquivalenzen) und Ähnliches, ohne auf diese beschränkt zu sein. Wie bereits erwähnt, kann ein bestimmtes Netzwerk-Spektralmuster auf einem bidirektionalen Netzwerk-Datenverkehrsmuster, einem multidirektionalen Netzwerk-Datenverkehrsmuster oder Kombinationen davon beruhen, wobei die Muster im Allgemeinen auf Signaturen für den Verbindungsaufbau und -abbruch für Verbindungen (in der Regel TCP-Transportverbindungen) beruhen, die diese Muster in einer zugrunde liegenden IP-Netzwerkstruktur übertragen. Wie zu sehen ist, kann mithilfe des Netzwerk-Spektralmusteransatzes ein Datenverkehrssegment von Interesse anhand eines Satzes von Referenzmustern analysiert werden, die (in der Regel in einem Offline-Prozess) codiert werden, um das Auftreten von Netzwerkbedrohungen und/oder anderen besonders relevanten Ereignissen im Netzwerk darzustellen, die auf potenzielle Sicherheitsverstöße oder -angriffe hinweisen. Diese Analyse kann in Echtzeit oder im Wesentlichen in Echtzeit durchgeführt werden, wodurch ein „schnelles Identifizieren“ von Sicherheits- oder anderen Bedrohungen, die dem Datenverkehrssegment zugehörig sind, ermöglicht wird. In einer beispielhaften (und nichteinschränkenden) Ausführungsform stellt der Vergleichssatz von Netzwerk-Spektralmustern eine sehr schnell auszuführende HiVE-Qualifizierung (HiVE - High Value Event) von Netzwerkereignissen in einem kundenseitigen Netzwerk bereit.
7 zeigt eine konzeptionelle Ansicht der grundlegenden Technik zum Aufzeichnen und Bewerten von Netzwerk-Spektralmustern gemäß dieser Offenbarung. Gemäß der Abbildung und dieser beispielhaften Ausführungsform ist die Funktionalität in einem Netzwerk-Spektralmusteranalysator 700 implementiert, der als eigenständige Anwendung, Bibliotheksebene oder andere Verarbeitungsfunktion paketiert werden kann (einschließlich, ohne darauf beschränkt zu sein, in einer nativen PCAP-Anwendung wie z.B. Wireshark). Der Analysator 700 umfasst einen Satz (eine Bibliothek) von Netzwerk-Spektralmustern 702 oder kann darauf zugreifen. Der zu prüfende Datenverkehr (z.B. ein PCAP-Datenstrom) wird aufgezeichnet und von einer Spektralmuster-Umwandlerkomponente 704 in ein Netzwerk-Spektralmuster codiert. Der zu prüfende Datenverkehr wird hier manchmal auch als zu analysierender Datenverkehr oder Prüfdatenverkehr bezeichnet. Die Codierung, mit der die Referenznetzwerk-Spektralmuster erzeugt werden, kann sich von der Codierung unterscheiden, mit der der zu prüfende Datenverkehr codiert wird, oder die Codierungstechniken können dieselben sein. Der Ausgang der Umwandlerkomponente 704 ist ein Netzwerk-Spektralmuster 706, das dann in einer Vergleichskomponente 708 mit den Referenznetzwerk-Spektralmustern verglichen wird, was einen Spektralmusterabgleich bereitstellt. Die Vergleichskomponente 708 arbeitet vorzugsweise in einem kontinuierlichen Datenstrom, wobei jedes Referenznetzwerk-Spektralmuster (von einer bestimmten Anzahl solcher Referenzspektralmuster) als übereinstimmend angesehen wird. Im Verlauf des Abgleichprozesses erzeugt die Vergleichskomponente 708 eine Ausgabe 710, die einen Überschneidungsgrad zwischen dem aufgezeichneten Datenverkehr und einem oder mehreren Referenznetzwerk-Spektralmustern anzeigt. Wenn das Vertrauen in eine bestimmte Übereinstimmung zwischen dem Prüfnetzwerk-Spektralmuster und einem bestimmten Referenznetzwerk-Spektralmuster so abnimmt, dass das Referenznetzwerk-Spektralmuster nicht mehr als (potenzielle) Übereinstimmung angesehen wird, wird dieses Referenznetzwerk-Spektralmuster von der weiteren Betrachtung ausgeschlossen. Der Abgleichprozess wird dann so lange fortgesetzt, bis mindestens ein Übereinstimmungskandidat übrig bleibt. Auf der Grundlage des Musterabgleichs charakterisiert das System dann den zu prüfenden Datenverkehr und ergreift möglicherweise eine bestimmte Abhilfe- oder Schadensbegrenzungsmaßnahme, wenn der Datenfluss (wie durch das abgeglichene Netzwerk-Spektralmuster dargestellt) verdächtig ist. Obwohl im Normalfall ein oder mehrere Netzwerk-Spektralmuster gefunden werden, die mit dem zu prüfenden Datenverkehr übereinstimmen, kann es auch vorkommen, dass beim Musterabgleich kein Übereinstimmungskandidat übrig bleibt. In diesem Fall sendet das System eine Meldung zurück, dass der zu prüfende Datenverkehr entweder unbestimmt ist oder nicht erkannt wurde.
Generell wird die Bewertung des Netzwerk-Spektralmusters (Codieren des zu prüfenden Datenverkehrs und Musterabgleich) von einem System (in der Regel einem Softwaresystem) durchgeführt, dem entweder der aufgezeichnete Datenpaketverkehr (z.B. einer PCAP-Datei) oder Daten aus dem direkt aufgezeichneten Datenverkehr (z.B. IPFIX-Nachrichten) zugeführt werden.
Der folgende Abschnitt stellt weitere ausführliche Details zum Implementieren des vorstehend beschriebenen Ansatzes bereit.
Überwachen von Datenverkehr, Mustern und Datenflüssen
Wie hier verwendet und in 7 dargestellt, werden ein oder mehrere Referenzspektralmuster (s_ref) mit einem zu bewertenden Datenverkehrssegment (s_eval) verglichen. In einem typischen Anwendungsfall berücksichtigt der Netzwerk-Spektralmusteranalysator die im Netzwerk-Spektralmuster codierten Informationen, z. B. eine oder mehrere Dimensionen des Datenverkehrsflusses, z.B. Paketanzahl, Byteanzahl und Metadaten des Netzwerkverkehrs (z.B. primäres IP-Trägerprotokoll, Quellen-/Zielanschlüsse) in den beobachteten Datenverkehrsmustern als Stichproben über ein bestimmtes Sammelintervall. Für jedes bestimmte zeitlich begrenzte Intervall (z.B. alle fünf (5) Sekunden) wird eine formalisierte Analyse des Vergleichs durch folgende Gleichung dargestellt: $\prod_{0}^{n} i (\in M \cup M') = ƒ (i n t e r v a l^{i}, M'_{(i - 1)} = \sum_{j = 0}^{n} m (j) [i])$
Diese Gleichung, die eine Formel m zum Abgleichen aller Kandidaten-Referenznetzwerk-Spektralmuster darstellt, wird in einem Abgleichintervall i ausgeführt. Formal stellt das Abgleichintervall in der Regel eine bestimmte Unterteilung innerhalb des Sammelintervalls (und vor dessen Ende) dar. Das Abgleichintervall ist in der Regel eine ganze Zahl von Codierungsintervallen. Ein Codierungsintervall ist die kürzeste Dauer innerhalb eines Sammelintervalls, um das Vorhandensein und die Übereinstimmung eines loC wie in einem Referenznetzwerk-Spektralmuster dargestellt mit dem gleichen Abgleichintervall für den zu analysierenden Datenverkehr zu qualifizieren und abzuleiten. Das Codierungsintervall ist die atomare Dauer-Einheit des Vergleichs. Die oben dargestellte Formel wird vorzugsweise iterativ bei allen Abgleichintervallen in einem Abgleichraum (in einem PCAP oder bei der aktuellen Grenze des aufgezeichneten Datenverkehrs) ausgeführt, wobei jede Iteration einen Satz übereinstimmender Spektralmuster und einen Satz teilweise übereinstimmender Spektralmuster M' ergibt, wobei M' ∋ (s_x, o_sx) M' ∋ (s_x, o_sx) eine Verbindung zwischen der Identifizierung eines (teilweise übereinstimmenden) Spektralmusters und einer Codierung eines Versatzes in diesem Spektralmuster ist, in dem die Übereinstimmung bis zum Ende eines Abgleichintervalls identifiziert wurde. Beim Musterabgleich auf der Grundlage eines Datenstroms sind zu Beginn eines Abgleichs im Abgleichintervall 0 vorzugsweise alle möglichen Referenzspektralmuster in Frage kommende Übereinstimmungskandidaten (d.h., es wurden keine eliminiert). Beim Auswerten des Datenverkehrs in einem Abgleichintervall berücksichtigt das System die aktuellen Übereinstimmungskandidaten ab ihrem Versatz 0.
Gewichten des Vertrauensintervalls
Wie vorstehend beschrieben, wird während des Musterabgleichs auf der Grundlage eines Datenstroms die Codierung des zu prüfenden Datenverkehrs mit der Codierung jedes Referenznetzwerk-Spektralmusters verglichen, bei dem es sich um einen Übereinstimmungskandidaten für den Prüfdatenverkehr handeln könnte. Im Verlauf des Musterabgleichs variiert das Vertrauen des Datenpaketanalysators in den Grad der Übereinstimmung in der Regel in Bezug auf ein bestimmtes Vertrauensintervall. Formal gesehen ist das Vertrauensintervall eine Anzahl aufeinanderfolgender positiver Vergleiche von Abgleichintervallen, die dazu dienen, eine Schwellenwertwahrscheinlichkeit für den Vergleich anhand eines loC wie im Sammelintervall des Referenznetzwerk-Spektralmusters dargestellt zu qualifizieren oder zu bestätigen. In der Regel ist diese Zahl eine Eigenschaft des Referenznetzwerk-Spektralmusters, eventuell teilweise gestützt auf das Vertrauen in die Genauigkeit des durch das Referenznetzwerk-Spektralmuster dargestellten loC; in einer alternativen Ausführungsform wird die Zahl durch eine System- oder Benutzerpräferenz auf der Grundlage externer oder anderer Faktoren (z.B. Tageszeit, IP-Quellen- oder Zieladresse usw.) angepasst.
Wie vorstehend erwähnt, hängt in einer Ausführungsform das, was abgeglichen wird, von der Codierungsimplementierung ab, umfasst aber normalerweise: Anschlüsse, Byteanzahl, Paketanzahl und die Abfolge von gepaarten Beobachtungen <Byteanzahl, Paketanzahl> im Verlauf des Abgleichintervalls. Es gibt jedoch eine Reihe von Faktoren, die dazu führen können, dass ein Referenzspektralmusterabgleich an den verschiedenen Abgleichpunkten abweicht, was sich auf die Analyse auswirken kann. Zu diesen Faktoren gehören z.B. Änderungen des Anschlusses für ein Muster, das möglicherweise in allen anderen Aspekten mit einem Spektralmuster übereinstimmt (insbesondere für alle Anschlüsse > 1024), Änderungen des Nutzdatenvolumens der Pakete aufgrund der Variabilität der darin enthaltenen Argumente usw. Beispielsweise könnte eine Phishing-Übereinstimmung bei einem Kompromittierungsindikator (loC) eine HTTP-Umleitung mit einer 78-Byte-Ziel-URL in der Referenz enthalten, jedoch mit einer 112-Byte-Übereinstimmung im beobachteten Datenverkehr (eventuell aufgrund einer dynamischen Änderung des Hostings für ein Command-and-Control(C&C)-Zentrum, das den Phishing-Angriff orchestriert). Um diesen Arten von Fehlern entgegenzuwirken, leitet der Netzwerk-Spektralmusteranalysator vorzugsweise eine zusätzliche Vertrauensintervallgewichtung ab und behält sie bei, wie im Folgenden beschrieben wird.
Der Analysator zeichnet insbesondere an jedem Punkt, an dem er eine Übereinstimmung in einem Referenzspektralmuster für gegeben ansieht, vorzugsweise die folgenden Zustandsinformationen auf (die wie oben dargestellt einen Teil von M oder M' bilden): (i) Identifizieren des betrachteten Netzwerk-Spektralmusters, (ii) Zuordnen der im Datenverkehr beobachteten Endpunkt-Identitäten zu den im Netzwerk-Spektralmuster dargestellten, (iii) einen Versatz in dem bis dahin erfolgreich durchgeführten Abgleich und (iv) ein verbleibender Vertrauensanteil im Abgleichintervall. Der zweite Punkt (ii) wird beibehalten, da sich das Netzwerk-Spektralmuster auf zwei beliebige IP-Adressen beziehen kann und nicht nur auf die, die im Referenznetzwerk-Spektralmuster beobachtet wurden. Der dritte Punkt (iii) gibt an, dass jeder Abgleich mit einer „Vertrauensreserve“ beginnt, die im Verlauf eines bestimmten Abgleichs verringert werden kann. Als Beispiel soll eine willkürliche Anzahl von 100 Vertrauenspunkten angenommen werden. Ein Unterschied zwischen den Anschlüssen > 1024 kann eine vernachlässigbare Verminderung dieses Anteils darstellen, z.B. 1 Punkt. Ein Unterschied zwischen den Anschlüssen < 1024 kann jedoch eine schwerwiegendere Abweichung von der Referenz darstellen, z.B. 10 Punkte. Eine Größenänderung zwischen zwei erwarteten Paketen in der Abgleichsequenz kann in einem definierten Abweichungsbereich variabel gewichtet werden, z.B. $\frac{+ (s_{r e f} - s_{e v a l})}{s_{r e f}} [+ (s_{r e f} - s_{e v a l}) / s_{r e f}]$
Punkte, die von der Gesamtübereinstimmung abgezogen werden. Ein weiteres Beispiel ist die Ausschöpfung des Referenzabgleichraums (z.B. Transportverbindung) mit einem erheblichen Rest auf der Transportverbindung des Bewertungsabgleichraums, der so gewichtet werden könnte, dass die Vertrauenspunkte bei einem Abgleich sehr schnell ausgeschöpft sind. Dies sind lediglich repräsentative Beispiele.
Durch Anwenden der vorstehend beschriebenen Vertrauensintervallgewichtung kann die Spektralmuster-Vergleichskomponente des Analysators schnell Unterschiede zwischen dem Spektralmuster des bewerteten Datenverkehrssegments und dem Satz der Referenznetzwerk-Spektralmuster identifizieren. Insbesondere kann schnell ermittelt werden, ob ein bestimmtes Netzwerk-Spektralmuster nicht in Frage kommt, sodass nur die Netzwerk-Spektralmusterkandidaten übrig bleiben, die eine gewisse Wahrscheinlichkeit einer Übereinstimmung aufweisen.
Auch wenn dies nicht erforderlich ist, kann es wünschenswert sein, den zu betrachtenden Abgleichraum einzuschränken, z.B. durch Protokollgrenzen auf Netzwerkebene.
Bilden des Netzwerk-Spektralmusters
Die Form und Codierung des Netzwerk-Spektralmusters nimmt vorzugsweise einen anderen Intervallwert an, der wie oben als Codierungsintervall bezeichnet wird. Wie beschrieben, stellt das Codierungsintervall den kleinsten Punkt eines bestimmten Spektralmusters dar, für den das Datenverkehrsvolumen für einen bestimmten Akteur bei der zugrunde liegenden Netzwerkaktivität, die das Spektralmuster modelliert und abbildet, identifiziert und bewertet werden kann. Vorzugsweise und während des Codierens des Netzwerk-Spektralmusters (z.B. durch die Umwandlerkomponente 704 in 7) gibt das System diesen Wert an, um sicherzustellen, dass die Vertrauensintervalle in jedem Abgleichprozess für jede bestimmte Vergleichsdatenverkehrsmessung entsprechend angepasst werden. Wie nachstehend beschrieben, ermöglicht das Codierungsintervall dem System auch, die Datenverkehrsmessung mit derjenigen des Netzwerk-Spektralmusters abzugleichen. Vorzugsweise stellt das Netzwerk-Spektralmuster mit dem kleinsten Codierungsintervall (und daher mit den meisten potenziellen Beispielwerten codiert) das Netzwerkverkehrsmuster mit der größten Entropie bereit, das der spezifischen Netzwerk-Spektralmustermessung zugrunde liegt.
Spektralmusterabgleich
Wie bereits erwähnt, ermöglicht das Codieren (sowohl des Prüfdatenverkehrs als auch jeder Referenz) den Vergleich des beobachteten Netzwerkverkehrs mit dem/den Referenzspektralmuster(n). In 7 und wie vorstehend beschrieben, wird dieser Vergleich durch die Vergleichskomponente 708 implementiert. In der Praxis erfordert dieser Vergleich in der Regel Abgleichen und Abstimmen der Messungen pro Codierungsintervall, damit sie mit denen des zu vergleichenden Datenverkehrsmusters übereinstimmen. Der Grund dafür ist, dass der Musterabgleich nur dann leistungsfähig ist, wenn davon ausgegangen wird, dass eine solche Unterschiedlichkeit bei der Unterteilung der Intervallgrenzen die Regel und nicht die Ausnahme ist. Um einen effizienten Musterabgleich zu ermöglichen, werden daher vorzugsweise mehrere zusätzliche Operationen durchgeführt; zu diesen gehören eine anfängliche Glättung und Interpolation. Glätten wird vorgenommen, um eng zusammenhängende Datenverkehrsspitzen zu streuen; bei dieser Operation werden die Daten verarbeitet, z.B. mithilfe einer Fourier-Analyse, um eine Reihe von Spitzen in eine eher kontinuierliche Wellenform umzuwandeln. Der Grad der Glättung (bzw. die Glättungstoleranz) kann variieren und ist vorzugsweise zum Beispiel ein vom System oder vom Benutzer konfigurierbarer Parameter. Interpolation bezieht sich auf einen Prozess, der eine statistisch lineare und diskrete Eingabe für den Glättungsprozess bereitstellt. Interpolation und Glätten werden vorzugsweise so implementiert, dass die fraglichen Intervallabschnitte zunächst mit dem Referenzspektralmuster und dem zu vergleichenden Paketfluss/der zu vergleichenden Paketaufzeichnung abgeglichen werden. Das Abgleichen selbst wird dann zu einer herkömmlichen Suche, wenn auch mit interpolierten Abgleichzellen pro Codierungsintervall. 8 zeigt eine repräsentative Pseudocodeliste für einen Musterabgleichalgorithmus auf der Grundlage eines Datenstroms gemäß diesem Ansatz.
Spektralmusterberichte
Wie vorstehend beschrieben und in 7 dargestellt, stellt der Spektralmusteranalysator im Verlauf des Abgleichs auf der Grundlage eines Datenstroms eine Ausgabe bereit, die eine Übereinstimmung (eines bestimmten Referenznetzwerk-Spektralmusters) mit dem zu prüfenden Datenverkehr darstellt. Ein direkter Abgleich (Abgleich (spektral, binär)) ermöglicht ein einfaches Ergebnis (z.B. Ausgabe 710 in 7). Wie bereits beschrieben, wird der Musterabgleich vorzugsweise nahezu in Echtzeit und kontinuierlich in Bezug auf den zu analysierenden Datenverkehr durchgeführt; in diesem Sinne ist das Codieren des Datenverkehrs selbst dynamisch (je mehr Daten empfangen werden). Da der zu prüfende Datenverkehr mit den Referenznetzwerk-Spektralmustern verglichen wird, ändert sich der Grad der Übereinstimmung in der Regel kontinuierlich (je mehr Daten empfangen werden), wodurch verschiedene Referenzspektralmuster wegfallen (als nichtübereinstimmend). Zu einem bestimmten Zeitpunkt gibt der Musterabgleich eine Antwort zurück, in der Regel mindestens eine Übereinstimmung, und diese Übereinstimmung stellt dann die beste Charakterisierung des zu prüfenden Datenverkehrs durch das System dar. Dieses Endergebnis kann dann je nach Implementierung anschließend für andere Zwecke verwendet werden. Die Ausgabe des Vergleichs kann beispielsweise dazu verwendet werden, ein Verarbeiten der Berichte über Bedrohungen auf höherer Ebene (SIEM, IPS oder ähnliches) auszulösen. Darüber hinaus kann der Spektralmuster-Abgleichalgorithmus (8) so verbessert werden, dass er mehr als nur ein Ergebnis von Übereinstimmung/Nichtübereinstimmung ausgibt. Auf diese Weise sind vielseitigere oder detaillierte loC-Analysen möglich.
So gibt es beispielsweise eine Reihe von Punkten, an denen die entropischen Bedingungen der Netzwerk-Stichprobennahme zu Störungen führen können, deren Toleranz dann durch ein kumulatives zulässiges Vertrauensintervall übermittelt werden kann. Formal betrachtet, kann einem Netzwerk-Spektralmuster eine Messentropie zugehörig sein. Eine Entropieberechnung wird normalerweise in einem Sammelintervall vorgenommen, das im Referenznetzwerk-Spektralmuster vorhanden ist. Ein stark abweichender Entropiewert stellt dem System einen unmittelbaren Hinweis auf einen negativen Vergleich bereit, wodurch das System in die Lage versetzt wird, das Referenznetzwerk-Spektralmuster als übereinstimmend abzulehnen, ohne Verarbeitungszyklen für rechenintensivere Prozesse beim Vergleich im Sammelintervall aufwenden zu müssen, und möglicherweise auch ein Berechnen von Codierungsintervallen zu vermeiden.
Die Entropieberechnung kann wie folgt durchgeführt werden. Eine zusätzliche Funktion match_interval (in der Vergleichskomponente 708) nimmt ein bestimmtes Vertrauensintervall und passt es während des Verarbeitens des Abgleichs an. Zu diesem Zweck misst eine Codezeile „compare spectral against next measure“ (in 8) dieses kumulative Intervall und vergleicht es mit einem konfigurierten (oder pro Spektralmuster) höchsten Wert. Mit dieser Operation wird dann ein „bedingter Entropiewert“ wie folgt angenähert: $H (Y_{v} X) = \sum_{(x \in X)} \sum_{(y \in Y)} p (x, y) l o g (p (y_{v} x)) .$
Anders ausgedrückt können partielle Übereinstimmungen, die durch den Spektralmustervergleich erzeugt werden, ihre eigenen Maßzahlen für die Übereinstimmung übermitteln. Diese Maßzahlen können ebenfalls von Interesse sein, insbesondere für Musterräume mit hoher Interpolation und nativer Entropie. Diese Entropiemessungen können auch als Eingabe für den Spektralmusteranalysator bereitgestellt werden, damit dieser die „maximale“ Entropieabweichung berechnen kann, die beim Ermitteln einer Übereinstimmung zulässig ist. Eine Anwendung dieser Art der Erstellung von Berichten über Spektralmuster umfasst, ohne darauf beschränkt zu sein, Erkennen von Anomalien im Vergleichsraum der Codierungsintervallgrenzen der Netzwerk-Spektralmuster selbst.
Im Folgenden werden zusätzliche Angaben zu einer Implementierung des Netzwerk-Spektralmusteranalysators gemäß einer beispielhaften Ausführungsform bereitgestellt. Wie vorstehend beschrieben und mit Bezug auf 9, verwendet der Netzwerk-Spektralmusteranalysator ein Referenznetzwerk-Spektralmuster 900 als eine Eingabe und die Ausgabe 902 der PCAP-Spektralmuster-Umwandlerkomponente und führt einen Vergleich durch. Wie gezeigt und vorstehend beschrieben, führt die Referenzspektralmusterkomponente vorzugsweise Abgleichen des Codierungsintervalls, Glätten, Interpolation (Verringern von Ausreißern) und Berechnen der Entropieabweichung (z.B. perfekte Übereinstimmung = 0; absolute Unterschiedlichkeit = 1) durch. Das Glätten und die Interpolation sind optional. Das Endergebnis 904 stellt einen Grad der Überschneidung zwischen dem aufgezeichneten Datenverkehr und dem Referenznetzwerk-Spektralmuster bereit, optional zusammen mit der Notation und der Dauer jeder genauen Überschneidung, die durch den Vergleich erkannt wurde.
Glätten, Interpolation und Entropieberechnung (treten während des Abgleichs auf), vorzugsweise für jedes Codierungsintervall.
Aufbau einer Bibliothek mit Referenzspektralmustern
Angesichts des Formats des bestehenden Netzwerk-Spektralmusters (z.B. aus einem pcap-umgewandelten Spektralmuster) wird im Folgenden ein Dienstprogramm beschrieben, mit dem die Bibliothek der Referenzspektralmuster 702 wie in 7 dargestellt erzeugt werden kann. Wie bereits beschrieben, kann der Analysator die Bibliothek nativ speichern oder auf die Bibliothek von einem externen Repository oder einer anderen Datenquelle aus zugreifen. Die Bibliothek kann in regelmäßigen Abständen oder bei Empfang von neuen Referenznetzwerk-Spektralmustern aktualisiert werden. In einer Implementierung (z.B. mit PCAP-Datenströmen) verwendet das Dienstprogramm einen pcap-Dateinamen und einen ausgegebenen Dateinamen des Netzwerk-Spektralmusters. Dieses Dienstprogramm führt dann mehrere Funktionen durch. Insbesondere wertet es die Interframe Gaps in einem Datenstrom aus, um ein optimal nutzbares Codierungsintervall zu ermitteln. Das Dienstprogramm passt dann dieses Intervall an, z.B. auf der Grundlage einer beliebigen Überschreibung durch den Benutzer (obwohl auch eine unbeaufsichtigte Operation unterstützt wird, z.B. für automatisierte Prüfanwendungen), und codiert die Spektralmusterintervalle und Frame-Ebenen auf der Grundlage des Codierungsintervalls, einschließlich aller erforderlichen Glättungs-, Interpolations- und anderer Funktionen, um eine intervallgebundene Berichterstellung über das Datenverkehrsaufkommen zu ermöglichen. Während dieses Prozesses kann das Dienstprogramm auch andere Spektralmuster-Metadaten bereitstellen, z.B. Entropieberichte. Gemäß einem weiteren Aspekt dieser Offenbarung stellt das Dienstprogramm vorzugsweise auch eine zusätzliche Codierungsoption für das Spektralmuster bereit, die hier als „Soft Axis“ bezeichnet wird.
Das System verfügt vorzugsweise über eine verfügbare Bibliothek von Netzwerk-Spektralmustern, die auf der Grundlage von Messungen des ermittelten oder simulierten Angriffsverkehrs erstellt werden. Netzwerk-Spektralmuster können von einer vertrauenswürdigen externen Quelle bereitgestellt werden, z.B. über ein Verteilungsmodell einer Sicherheitsgemeinschaft.
Ein alternativer Codierungsansatz zum Erzeugen eines Referenzspektralmusters kann auf der Grundlage von pro Paket aufgezeichneten Flussdaten beruhen, z.B. in IPFIX und OASIS STIX. Bei IPFIX kann der Austausch pro Intervall mit grundlegenden Listenvorlagenstrukturen (wie in RFC 6313 definiert) codiert werden. Die grundlegende Übermittlung pro Intervall (wobei die Intervalle hier durch die Berichtsintervalle des IPFIX-Exporteurs definiert sind) gibt einen Bericht aus, der einer allgemeinen Metadatenvorlage entspricht, und anschließend n Listenelemente, wobei n = Anzahl der Stichprobenintervalle innerhalb des IPFIX-Berichtsintervalls ist. STIX nutzt ähnliche Mechanismen, wie sie in den Mehrelement-Listenstrukturen in Teil 5 des STIX-Standards 2.0 definiert sind.
Soft-Axis-Zeitreihenkomprimierung
Wie bereits ausgeführt, wird ein Referenznetzwerk-Spektralmuster vorzugsweise sehr kompakt codiert (um den Musterabgleich zu ermöglichen), indem die Codierung so verarbeitet wird, dass Intervalle, in denen der Verkehr inaktiv ist (nichtvariierend), ignoriert oder ausgelassen werden. Wenn der Verkehr während eines oder mehrerer Intervalle, die in dem Netzwerk-Spektralmuster codiert werden, inaktiv ist (nichtvariierend), wird vorzugsweise eine Zeitreihenkomprimierung verwendet, um die codierte Datenmenge zu verringern und so eine kompaktere Darstellung bereitzustellen. Dieser Prozess wird hier manchmal auch als Soft-Axis-Codierung bezeichnet. Diese Codierung stellt sicher, dass ein zu analysierendes Datenverkehrsmuster aufgrund von Umgebungseinflüssen (auf den Datenfluss) erkannt werden muss, die auf inaktiven Verkehr zurückzuführen sind, d.h. durch eine Inaktivität, die ansonsten keinen sinnvollen Verkehr darstellt. Art und Ursache der Inaktivität können variieren, umfassen aber in der Regel Interframe Gaps, Anwendungsprotokollaktivitäten wie z.B. Keepalives in Intervallen und Ähnliches. Diese realen Bedingungen können sich negativ auf intervallübergreifende Messungen von Werten auswirken, die ansonsten für ein Erstellen eines Profils des durch ein Netzwerk-Spektralmuster dargestellten loC nützlich sind, und der Soft-Axis-Ansatz entfernt diese Aktivität aus der Codierung.
Für einen typischen loC weist ein repräsentatives Netzwerk-Spektralmuster eine gewisse Anzahl von Nichtnull-Messungen des Datenverkehrsaufkommens von einem Teilnehmer zum anderen sowie Intervalle auf, die Null-Datenverkehrsaufkommen in beiden Richtungen darstellen. Dieses Null-Datenverkehrsaufkommen kann Verarbeiten und die Startzeit eines Mikrodienstes auf Seiten eines Spektralmuster-Teilnehmers darstellen, oder er kann Übertragungslatenzen darstellen, insbesondere entlang langer Übertragungsstrukturen, bei denen das Stichprobenintervall detailliert ist. Der hier beschriebene Soft-Axis-Vergleich und das Codieren verringern die Zahl der falsch-negativen Ergebnisse, die andernfalls aus diesen Intra-Nichtnull-Messlücken resultieren könnten. Mit Bezug nunmehr auf 10 gibt es in dieser vereinfachten Darstellung eines Netzwerk-Spektralmusters 1000 mehrere Null-Messintervalle 1002. In diesem bidirektionalen Datenverkehrsmuster zwischen zwei Teilnehmern stellen die leeren Dreiecke 1004 den Datenverkehr von A → B und die ausgefüllten Dreiecke den Datenverkehr von B → A dar. Es ist zwar möglich, das Spektralmuster der tatsächlichen Datenverkehrsmesswerte an beiden Endpunkten des Datenflusses effektiv abzugleichen, doch bleiben diese Werte in der Regel relativ konstant, sowohl in Bezug auf das Referenz-Spektralmuster als auch auf den gemessenen aufgezeichneten Datenverkehr (wobei der diesem Spektralmuster zugehörige loC dargestellt wird). Das Vertrauen in diese Messung (wenn nicht sogar die allgemeine Fähigkeit zum Abgleichen des Spektralmusters) kann jedoch durch das Vorhandensein einer definierten Folge (z.B. größer als 2) von Null-Messintervallen beeinträchtigt werden, deren Vorhandensein zu Ungenauigkeiten im aufgezeichneten Datenverkehr führt, z.B. aufgrund vorübergehender Bedingungen bei der Systemverarbeitung oder aufgrund von Latenzzeiten im Netzwerk. Deshalb stellt die Soft-Axis-Codierung eine Zeitreihenkomprimierung entlang nichtvariierender Codierungsintervalle (inaktiver Datenverkehr) bereit. Diese Komprimierung kann immer und überall dort eingesetzt werden, wo das Spektralmuster eine bestimmte Folge von Null-Messintervallen umfasst. Ein bevorzugter Ansatz besteht jedoch darin, die Komprimierung je nach Art des Datenverkehrsflusses und den Bedingungen, die die Genauigkeit der Darstellung beeinträchtigen können, selektiver zu konfigurieren. Beispielsweise kann eine Komprimierung der Null-Messintervalle von Abgleichelementen regulärer Ausdrücke gesteuert werden, die das Vorhandensein einer oder mehrerer Bedingungen prüfen, wie z.B. Transportschwankungen (z.B. Keepalives), Interframe Gaps usw., die die Messgenauigkeit beeinträchtigen können. Um ein konkretes Beispiel bereitzustellen, kann ein regulärer Ausdruck einen Typ des Abgleichelements regelmäßiger Ausdrücke „Übereinstimmung mit einem oder mehreren“ implementieren; bei einer Übereinstimmung wird die Zeitreihenkomprimierung für die Folge von Null-Messintervallen implementiert. Diese Codierung ist vorteilhaft, da sie die Variabilität in (nichtentropischen) Null-Volumen-Codierungsintervallen berücksichtigt.
Verallgemeinernd lässt sich sagen, dass die Soft-Axis-(Zeitreihen-)Codierung einen Mechanismus bereitstellt, um (aus der Codierung) Messwerte herauszufiltern, die keine aussagekräftigen Verkehrsdaten darstellen, die für Vergleichszwecke nützlich sind.
Datenverkehrsmuster in Netzwerken mit mehreren Teilnehmern und in mehrere Richtungen
Die vorstehend beschriebenen Techniken ermöglichen die Formulierung und Verwendung von bidirektionalen Netzwerkmustern zwischen Entitäten. 5 and 6 stellen typische Datenflüsse zwischen zwei Teilnehmern dar. Gemäß einem weiteren Aspekt lassen sich die hier beschriebenen Techniken auch ohne Weiteres auf multidirektionale Datenverkehrsmuster anwenden, darunter solche, an denen mehrere Teilnehmer beteiligt sind. Dies ist wünschenswert, da nicht alle loCs dem Paradigma mit zwei Teilnehmern (z.B. Client-Server) entsprechen. Dies ist beispielhaft in 11 dargestellt, die ein Szenario mit mehreren Teilnehmern und einem Paar von Datenverkehrsmustern und Bytes zeigt, die einem primären Client-Sender und mehreren Peers entsprechen, die über TOR (The Onion Router) Daten über dessen Peer-Weiterleitungsstrukturen austauschen. Dieser Anwendungsfall ist nicht als Einschränkung zu verstehen. Das endgültige Ziel ist, sobald es identifiziert und anonymisiert ist, ansonsten nicht sichtbar. In diesem Szenario gibt es mehrere am Austausch Beteiligte. Beim Vergleichen der beiden Diagramme ist zu erkennen, dass allein das Vorhandensein dieses Peering-Satzes innerhalb eines kurzen Intervalls ein gewisses Indiz für die Übereinstimmung mit einem Referenzspektralmuster darstellt, dass jedoch die Identität dieser Peers für die Zwecke des Abgleichs abstrahiert und mit einem bestimmten Bewertungskandidaten abgeglichen werden muss, z.B. wenn ein bestimmter Satz von Peering-Akteuren a ... e einer entstehenden Identitäts-IP-Adresse für ein bestimmtes Spektralmuster zugeordnet wird. Für den Fall, dass ein abzugleichendes Spektralmuster aus einer Verteilung in einem öffentlichen IP-Adressraum erzeugt wird, im Gegensatz zu beispielsweise einem Bewertungskandidaten hinter einer NAT-Firewall, ist der Abgleich (in diesem Fall b ... e → ein einzelnes IP) robuster und lässt mehrere Abgleichoptionen offen, ohne dass sich das Vertrauensabgleichintervall signifikant verringert.
Die hier vorgestellten Techniken können verallgemeinert werden, um einen Vergleich von Netzwerk-Spektralmustern zwischen mehreren Teilnehmern zu ermöglichen. Vergleiche werden vorzugsweise unter Verwendung der vorstehend beschriebenen Funktionalität durchgeführt, und gegebenenfalls werden die Datenverkehrsflüsse von jedem Paar von Entitäten (z.B. [a,b]...[b,c]...[a.c]}, die den fraglichen Datenfluss aufweisen, bewertet. Auf diese Weise ermöglicht der hier beschriebene Ansatz Erkennen von Mustern für Forwarding Proxys, eine Man-in-the-Middle-Übersetzung und andere Peer-Beziehungs-Weiterleitungs- oder Datenbereitstellungsprotokolle (z.B. BitTorrent).
Schadensbegrenzung und Abhilfe
Wie vorstehend ausgeführt, ermöglichen die hier beschriebenen Techniken ein schnelles und effizientes Charakterisieren von Bedrohungen und Angriffen auf Datennetzwerke. Wie bereits beschrieben, wird in dem grundlegenden Anwendungsfall versucht, (über die Netzwerk-Spektralmuster) den Zustand eines Netzwerks mit einem Satz von charakterisierten und erkennbaren Bedrohungen abzugleichen. Auf der Grundlage eines solchen Abgleichs gibt das System Informationen aus, die nützlich sind, um Schadensbegrenzung oder Abhilfe in Bezug auf die Bedrohung einzuleiten oder zu steuern. Die Art der Schadensbegrenzung oder Abhilfe kann je nach Schwere der Bedrohung, dem Grad der Übereinstimmung, externen Faktoren (z.B. Tageszeit, Angriffsziel usw.) oder einer anderen in einer Sicherheitsrichtlinie festgelegten Bedingung variieren. Eine repräsentative Schadensbegrenzungs- oder Abhilfemaßnahme kann darin bestehen, eine Firewall-Sperre zu aktualisieren, eine Verbindung zu trennen, eine Verbindung abzuschotten, einen Alarm auszugeben, eine Protokollierung vorzunehmen oder ein Steuersignal oder einen anderen Hinweis an eine andere Sicherheitseinheit, eine Anwendung oder ein System bereitzustellen.
Die hier vorgestellten Techniken stellen erhebliche Vorteile bereit. Wie vorstehend ausgeführt, ermöglichen die hier beschriebenen Techniken ein schnelles und effizientes Charakterisieren von Bedrohungen und Angriffen auf Datennetzwerke. In erster Linie stellt die Technik Erzeugen und Verwenden von Netzwerk-Spektralmustern bereit, anhand derer bi- und multidirektionale Datenverkehrsmuster im Netzwerk analysiert und charakterisiert werden können. Der Ansatz ermöglicht es einem Netzwerk-Spektralmusteranalysator, auf der Grundlage der in einem Referenzspektralmuster codierten Daten eine Musteranalyse des Datenverkehrs in Echtzeit oder nahezu in Echtzeit bereitzustellen, wobei diese Daten das Datenvolumen, die Richtung und nichtverschlüsselte Datenverkehrsmetadaten (z.B. TCP-Protokoll- und Portäquivalenzen) umfassen und nichtverschlüsselte Muster, z.B. auf der Grundlage von Signaturen für den Verbindungsaufbau und -abbruch für Verbindungen, die diese Muster zwischen den zugrunde liegenden IP-Strukturen übertragen, verwenden. Die hier vorgestellten Techniken ermöglichen einen Echtzeitvergleich dieser Datenverkehrsmuster mit Referenzmustern, die das Auftreten von Netzwerkbedrohungen oder anderen herausragenden Ereignissen des Netzwerks zu Sicherheitszwecken darstellen. Der hier vorgestellte Ansatz (insbesondere der Begriff der „Soft Axis“) stellt sicher, dass der Referenz-Spektralmustervergleich robust und genau ist, wenn der zu prüfende Datenverkehr ansonsten durch Umgebungsbedingungen des Netzwerks, wie z.B. Interframe Gap, die Keepalive-Aktivität des Anwendungsprotokolls in den Intervallen usw., beeinträchtigt werden könnte. Der Ansatz ist auch leicht skalierbar, um mehrere Teilnehmer zu modellieren (p > 2), wodurch das System in der Lage ist, komplexe Muster von Forwarding Proxys, Man-in-the-Middle-Übersetzungsentitäten und andere Weiterleitungs- oder Datenbereitstellungsszenarien mit Peer-Beziehungen zu erkennen.
Ohne eine Einschränkung zu beabsichtigen, kann der hier beschriebene Ansatz in Verbindung mit anderen Techniken zum Überwachen des Netzwerkflusses und zur Paketanalyse verwendet werden. Der Netzwerk-Spektralmusteranalysator dieser Offenbarung kann auf verschiedene Weise implementiert werden, und er kann vor Ort, netzwerkgestützt oder cloud-gestützt konfiguriert werden.
Der vorliegende Gegenstand des Netzwerk-Spektralmusteranalysators kann als Dienst implementiert werden. Der Gegenstand kann auch innerhalb oder in Verbindung mit einem Rechenzentrum implementiert werden, das cloud-gestützte Datenverarbeitung, Datenspeicherung oder verwandte Dienste in Verbindung mit anderen Netzwerksicherheitsprodukten und -diensten bereitstellt. Das Dienstprogramm zum Erzeugen von Spektralmustern (zum Erzeugen von Referenzspektralmustern) und die Spektralmuster-Analysatorfunktion (zum Durchführen eines schnellen Identifizierens und einer Analyse in Echtzeit) können jeweils als eigenständige Funktionen bereitgestellt werden, oder sie können Funktionen anderer Produkte und Dienste nutzen, darunter, ohne auf diese beschränkt zu sein, anderer Sicherheitsüberwachungs- und -Analysesysteme, Produkte, Einheiten, Programme oder Prozesse.
In einem typischen Anwendungsfall ist einem SIEM oder einem anderen Sicherheitssystem eine Schnittstelle zugehörig, die dazu verwendet werden kann, die Datenflussinformationen visuell darzustellen, relevante Informationen aus einer Warnmeldung oder einer anderen Datenbank zu suchen und abzurufen und andere bekannte diesbezügliche Eingabe- und Ausgabefunktionen durchzuführen.
Wie vorstehend erwähnt, ist der hier beschriebene Ansatz so ausgestaltet, dass er automatisiert innerhalb eines Sicherheitssystems oder in Zugehörigkeit zu einem Sicherheitssystem, z.B. einem SIEM oder einer Cyber-Sicherheitsanalyseplattform, oder auf andere Weise implementiert werden kann.
Die in dieser Offenbarung beschriebene Funktionalität kann ganz oder teilweise als eigenständiger Ansatz implementiert werden, z.B. als softwaregestützte Funktion, die von einem Hardwareprozessor ausgeführt wird, oder sie kann als verwalteter Dienst verfügbar sein (z.B. auch als Webdienst über eine SOAP/XML-Schnittstelle). Die hier beschriebenen Einzelheiten der Hardware- und Softwareimplementierung dienen lediglich der Veranschaulichung und sollen den Umfang des beschriebenen Gegenstands nicht einschränken.
Allgemeiner ausgedrückt, handelt es sich bei den Datenverarbeitungseinheiten im Rahmen des offenbarten Gegenstands jeweils um ein Datenverarbeitungssystem (wie z.B. in 2 dargestellt), das Hardware und Software aufweist, und diese Entitäten übertragen untereinander Daten über ein Netzwerk, z.B. das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder jedes beliebige andere Datenübertragungsmedium oder eine beliebige Verbindung. Die Anwendungen im Datenverarbeitungssystem stellen native Unterstützung für Web- und andere bekannte Dienste bereit, darunter Unterstützung für unter anderem HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI und WSFL, ohne auf diese beschränkt zu sein. Informationen zu SOAP, WSDL, UDDI und WSFL sind beim World Wide Web Consortium (W3C) erhältlich, das für das Entwickeln und Pflegen dieser Standards verantwortlich ist; weitere Informationen zu HTTP, FTP, SMTP und XML sind bei der Internet Engineering Task Force (IETF) erhältlich. Die Kenntnis dieser bekannten Standards und Protokolle wird vorausgesetzt.
Die hier beschriebene Strategie kann in oder in Verbindung mit verschiedenen serverseitigen Architekturen implementiert werden, darunter einfache n-Tier-Architekturen, Webportale, Verbundsysteme usw. Die hier beschriebenen Techniken können in einer lose verbundenen Serverumgebung (einschließlich einer „cloud“-gestützten Umgebung) eingesetzt werden.
Noch allgemeiner kann der hier beschriebene Gegenstand die Form einer kompletten Hardware-Ausführung, einer kompletten Software-Ausführung oder einer Ausführungsform haben, die sowohl Hardware- als auch Software-Elemente enthält. In einer bevorzugten Ausführungsform ist die Funktion in Software implementiert, die Firmware, residente Software, Mikrocode und Ähnliches umfasst, ohne auf diese beschränkt zu sein. Darüber hinaus kann die identitätskontextgestützte Zugriffssteuerungsfunktionalität wie vorstehend erwähnt die Form eines Computerprogrammprodukts annehmen, auf das von einem durch einen Computer verwendbaren oder durch einen Computer lesbaren Medium zugegriffen werden kann, das Programmcode zur Verwendung mit oder in Verbindung mit einem Computer oder einem beliebigen Anweisungsausführungssystem bereitstellt. Für die Zwecke dieser Beschreibung kann ein durch einen Computer verwendbares oder durch einen Computer lesbares Medium jede Vorrichtung sein, die das Programm zur Verwendung mit oder in Verbindung mit dem System, der Vorrichtung oder der Einheit zur Anweisungsausführung enthalten oder speichern kann. Bei dem Medium kann es sich um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem (oder eine Vorrichtung oder Einheit) handeln. Zu Beispielen für ein durch einen Computer lesbares Medium gehören ein Halbleiterspeicher, ein Magnetband, eine austauschbare Computerdiskette, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), eine starre Magnetplatte und eine optische Platte. Aktuelle Beispiele für optische Platten umfassen Compact Disk - Nur-Lese-Speicher (CD-ROM), Compact Disk - Lesen/Schreiben (CD-R/W) und DVD. Das durch einen Computer lesbare Medium ist ein physisches Objekt.
Bei dem Computerprogrammprodukt kann es sich um ein Produkt mit Programmanweisungen (oder Programmcode) zum Implementieren einer oder mehrerer der beschriebenen Funktionen handeln. Diese Anweisungen oder Codes können in einem durch einen Computer lesbaren Speichermedium in einem Datenverarbeitungssystem gespeichert werden, nachdem sie über ein Netzwerk von einem entfernt angeordneten Datenverarbeitungssystem heruntergeladen wurden. Oder diese Anweisungen oder Codes können in einem durch einen Computer lesbaren Speichermedium in einem Server-Datenverarbeitungssystem gespeichert werden und so ausgelegt sein, dass sie über ein Netzwerk auf ein entfernt angeordnetes Datenverarbeitungssystem zur Verwendung in einem durch einen Computer lesbaren Speichermedium innerhalb des entfernten Systems heruntergeladen werden.
In einer repräsentativen Ausführungsform sind die Techniken zur Bedrohungsbeseitigung und -modellierung in einem speziellen Computer implementiert, vorzugsweise als Software, die von einem oder mehreren Prozessoren ausgeführt wird. Die Software wird in einem oder mehreren Datenspeichern oder Arbeitsspeichern, die dem einen oder mehreren Prozessoren zugehörig sind, gespeichert, und die Software kann als ein oder mehrere Computerprogramme implementiert werden. Zusammengenommen weist diese spezielle Hardware und Software die oben beschriebene Funktionalität auf.
Zwar wird vorstehend eine bestimmte Reihenfolge von Operationen beschrieben, die von bestimmten Ausführungsformen der Erfindung durchgeführt werden, doch sei darauf hingewiesen, dass diese Reihenfolge nur beispielhaft gewählt wurde, denn andere Ausführungsformen können die Operationen auch in einer anderen Reihenfolge durchführen, bestimmte Operationen kombinieren, bestimmte Operationen überlappend durchführen oder Ähnliches. Verweise in der Beschreibung auf eine bestimmte Ausführungsform bedeuten, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft umfassen kann, jedoch nicht jede Ausführungsform notwendigerweise das bestimmte Merkmal, die bestimmte Struktur oder Eigenschaft umfassen muss.
Schließlich wurden zwar bestimmte Komponenten des Systems getrennt beschrieben, für einen Fachmann ist jedoch offensichtlich, dass einige der Funktionen in bestimmten Anweisungen, Programmsequenzen, Codeabschnitten usw. kombiniert oder gemeinsam genutzt werden können.
Die hier vorgestellten Techniken stellen Verbesserungen gegenüber einer anderen Technologie oder einem anderen technischen Gebiet bereit, z.B. SIEM-Systeme (Security Incident and Event Management), anderen Sicherheitssystemen sowie Verbesserungen der automatisierungsgestützten Cybersicherheitsanalyse.
Der Begriff „Echtzeit“ oder „nahezu Echtzeit“ wie er hier verwendet wird, bedeutet nicht, dass eine absolute Zeit relativ zu einem bestimmten Zeitwert erforderlich ist; vielmehr kann „Echtzeit“ relativ sein. Im Zusammenhang mit dem beschriebenen Spektralmusterabgleich bedeutet Echtzeit, dass der Abgleichprozess in dem Moment durchgeführt wird, in dem der zu prüfende Datenverkehr empfangen und codiert wird. Wie vorstehend beschrieben, wird der Datenverkehr beim Codierungsvorgang mit den Referenzspektralmustern abgeglichen. Dieser Musterabgleich eines Datenstroms (des zu prüfenden Datenverkehrs) erfolgt in Echtzeit oder nahezu in Echtzeit.

Claims

Verfahren zum Identifizieren von Bedrohungen in einem TCP/IP-gestützten Netzwerk, wobei das Verfahren aufweist: Abrufen eines Satzes von Referenzmustern, die einem oder mehreren definierten Kompromittierungsindikatoren (IoCs) zugehörig sind, wobei es sich bei einem Referenzmuster um eine Codierung einer Paketaufzeichnung handelt und einen Satz von intervallgebundenen Datenverkehrsmessungen für jede Paarung von einem oder mehreren adressierbaren Netzwerkschnittstellen in der Paketaufzeichnung zusammen mit anderen erfassbaren Sitzungsdaten aufweist; Empfangen von Netzwerkverkehrsdaten, die einem Datenverkehrsmuster zugehörig sind, als Datenstrom; Codieren des empfangenen Netzwerkverkehrs, um ein Netzwerk-Spektralmuster zu erzeugen; beim Empfangen des Datenstroms Vornehmen eines Musterabgleichs des Netzwerk-Spektralmusters mit einem Satz von Referenzmustern in Echtzeit, die das Referenzmuster aufweisen; und als Reaktion auf ein Identifizieren einer Übereinstimmung zwischen dem Netzwerk-Spektralmuster und mindestens einem aus dem Satz von Referenzmustern Ergreifen einer bestimmten Abhilfe- oder Schadensbegrenzungsmaßnahme.
Verfahren nach Anspruch 1, wobei das Vornehmen des Musterabgleichs in Echtzeit aufweist: Identifizieren jedes Satzes von Referenzmustern als eine Übereinstimmung mit dem Netzwerk-Spektralmuster; wenn das Vertrauen in eine Übereinstimmung zwischen dem Netzwerk-Spektralmuster und einem bestimmten Referenzmuster unter einen konfigurierbaren Schwellenwert sinkt, Ausschließen des bestimmten Referenzmusters von der weiteren Betrachtung.
Verfahren nach Anspruch 1, wobei das mindestens eine Referenzmuster durch Codieren der Paketaufzeichnung und Filtern eines oder mehrerer zeitlich begrenzter Intervalle erzeugt wird, die einen inaktiven Datenverkehr aufweisen.
Verfahren nach Anspruch 1, wobei die eine oder mehreren adressierbaren Netzwerkschnittstellen mindestens zwei (2) unterschiedlichen Datenverarbeitungsentitäten zugehörig sind.
Verfahren nach Anspruch 4, wobei das mindestens eine Referenzmuster ein multidirektionales Datenverkehrsmuster ist, an dem mehr als zwei (2) unterschiedliche Datenverarbeitungseinheiten beteiligt sind.
Verfahren nach Anspruch 1, wobei das Codieren auch einschließt: Datenverkehrsvolumen und/oder Ausrichtungsdaten und/oder nichtverschlüsselte Datenverkehrsmetadaten, die einer Transportverbindung zugehörig sind.
Verfahren nach Anspruch 1, wobei es sich bei den empfangenen Netzwerkverkehrsdaten handelt um: aufgezeichneten Paketdatenverkehr und/oder Daten, die aus direkt aufgezeichnetem Datenverkehr abgeleitet wurden.
Vorrichtung, die aufweist: einen Prozessor; einen Computerspeicher mit Computerprogrammanweisungen, die von dem Prozessor ausgeführt werden, um Bedrohungen in einem TCP/IP-gestützten Netzwerk zu identifizieren, wobei die Computerprogrammanweisungen Programmcode aufweisen, der so konfiguriert ist, dass er: einen Satz von Referenzmustern abruft, die einem oder mehreren definierten Kompromittierungsindikatoren (IoCs) zugehörig sind, wobei es sich bei einem Referenzmuster um eine Codierung einer Paketaufzeichnung handelt und einen Satz von intervallgebundenen Datenverkehrsmessungen für jede Paarung von einem oder mehreren adressierbaren Netzwerkschnittstellen in der Paketaufzeichnung zusammen mit anderen erfassbaren Sitzungsdaten enthält; Netzwerkverkehrsdaten, die einem Datenverkehrsmuster zugehörig sind, als Datenstrom empfängt; den empfangenen Netzwerkverkehr codiert, um ein Netzwerk-Spektralmuster zu erzeugen; beim Empfangen des Datenstroms einen Musterabgleich des Netzwerk-Spektralmusters mit einem Satz von Referenzmustern in Echtzeit vornimmt, die das Referenzmuster aufweisen; und als Reaktion auf das Identifizieren einer Übereinstimmung zwischen dem Netzwerk-Spektralmuster und mindestens einem aus dem Satz von Referenzmustern eine bestimmte Abhilfe- oder Schadensbegrenzungsmaßnahme ergreift.
Vorrichtung nach Anspruch 8, wobei die Computerprogrammanweisungen für den Musterabgleich in Echtzeit Programmcode enthalten, der weiterhin so konfiguriert ist, dass er: jeden Satz von Referenzmustern als eine Übereinstimmung mit dem Netzwerk-Spektralmuster identifiziert; wenn das Vertrauen in eine Übereinstimmung zwischen dem Netzwerk-Spektralmuster und einem bestimmten Referenzmuster unter einen konfigurierbaren Schwellenwert sinkt, das bestimmte Referenzmuster von der weiteren Betrachtung ausschließt.
Vorrichtung nach Anspruch 8, wobei das mindestens eine Referenzmuster durch Codieren der Paketaufzeichnung und Filtern eines oder mehrerer zeitlich begrenzter Intervalle erzeugt wird, die einen inaktiven Datenverkehr aufweisen.
Vorrichtung nach Anspruch 8, wobei die eine oder mehreren adressierbaren Netzwerkschnittstellen mindestens zwei (2) unterschiedlichen Datenverarbeitungsentitäten zugehörig sind.
Vorrichtung nach Anspruch 11, wobei das mindestens eine Referenzmuster ein multidirektionales Datenverkehrsmuster ist, an dem mehr als zwei (2) unterschiedliche Datenverarbeitungseinheiten beteiligt sind.
Vorrichtung nach Anspruch 8, wobei das Codieren auch einschließt: Datenverkehrsvolumen und/oder Ausrichtungsdaten und/oder nichtverschlüsselte Datenverkehrsmetadaten, die einer Transportverbindung zugehörig sind.
Vorrichtung nach Anspruch 8, wobei es sich bei den empfangenen Netzwerkverkehrsdaten handelt um: aufgezeichneten Paketdatenverkehr und/oder Daten, die aus direkt aufgezeichnetem Datenverkehr abgeleitet wurden.
Computerprogrammprodukt in einem nichtflüchtigen, durch einen Computer lesbaren Medium zur Verwendung in einem Datenverarbeitungssystem, um Bedrohungen in einem TCP/IP-gestützten Netzwerk zu identifizieren, wobei das Computerprogrammprodukt Computerprogrammanweisungen aufweist, die, wenn sie von dem Datenverarbeitungssystem ausgeführt werden, so konfiguriert sind, dass sie: einen Satz von Referenzmustern abrufen, die einem oder mehreren definierten Kompromittierungsindikatoren (IoCs) zugehörig sind, wobei es sich bei einem Referenzmuster um eine Codierung einer Paketaufzeichnung handelt und einen Satz von intervallgebundenen Datenverkehrsmessungen für jede Paarung von einem oder mehreren adressierbaren Netzwerkschnittstellen in der Paketaufzeichnung zusammen mit anderen erfassbaren Sitzungsdaten aufweist; Netzwerkverkehrsdaten, die einem Datenverkehrsmuster zugehörig sind, als Datenstrom empfangen; den empfangenen Netzwerkverkehr codieren, um ein Netzwerk-Spektralmuster zu erzeugen; beim Empfangen des Datenstroms einen Musterabgleich des Netzwerk-Spektralmusters mit einem Satz von Referenzmustern in Echtzeit vornehmen, der das Referenzmuster aufweist; und als Reaktion auf das Identifizieren einer Übereinstimmung zwischen dem Netzwerk-Spektralmuster und mindestens einem aus dem Satz von Referenzmustern eine bestimmte Abhilfe- oder Schadensbegrenzungsmaßnahme ergreifen.
Computerprogrammprodukt nach Anspruch 15, wobei die Computerprogrammanweisungen für den Musterabgleich in Echtzeit Programmcode enthalten, der weiterhin so konfiguriert ist, dass er: jeden Satz von Referenzmustern als eine Übereinstimmung mit dem Netzwerk-Spektralmuster identifiziert; wenn das Vertrauen in eine Übereinstimmung zwischen dem Netzwerk-Spektralmuster und einem bestimmten Referenzmuster unter einen konfigurierbaren Schwellenwert sinkt, das bestimmte Referenzmuster von der weiteren Betrachtung ausschließt.
Computerprogrammprodukt nach Anspruch 15, wobei das mindestens eine Referenzmuster durch Codieren der Paketaufzeichnung und Filtern eines oder mehrerer zeitlich begrenzter Intervalle erzeugt wird, die einen inaktiven Datenverkehr aufweisen.
Computerprogrammprodukt nach Anspruch 15, wobei die eine oder mehreren adressierbaren Netzwerkschnittstellen mindestens zwei (2) unterschiedlichen Datenverarbeitungsentitäten zugehörig sind.
Computerprogrammprodukt nach Anspruch 18, wobei das mindestens eine Referenzmuster ein multidirektionales Datenverkehrsmuster ist, an dem mehr als zwei (2) unterschiedliche Datenverarbeitungseinheiten beteiligt sind.
Computerprogrammprodukt nach Anspruch 15, wobei das Codieren auch einschließt: Datenverkehrsvolumen und/oder Ausrichtungsdaten und/oder nichtverschlüsselte Datenverkehrsmetadaten, die einer Transportverbindung zugehörig sind.
Computerprogrammprodukt nach Anspruch 15, wobei es sich bei den empfangenen Netzwerkverkehrsdaten handelt um: aufgezeichneten Paketdatenverkehr und/oder Daten, die aus direkt aufgezeichnetem Datenverkehr abgeleitet wurden.
System zum Erkennen von Netzwerkbedrohungen, das aufweist: ein erstes softwaregestütztes Dienstprogramm, das auf Hardware ausgeführt wird und so konfiguriert ist, dass es eine Paketaufzeichnung abruft und eine erste Codierung erzeugt, wobei die erste Codierung einen Satz von intervallgebundenen Datenverkehrsmessungen für jede Paarung einer oder mehrerer adressierbarer Netzwerkschnittstellen in der Paketaufzeichnung zusammen mit anderen erfassbaren Sitzungsdaten aufweist; und ein zweites softwaregestütztes Dienstprogramm, das auf Hardware ausgeführt wird und so konfiguriert ist, dass es einen Datenstrom empfängt, und beim Empfangen des Datenstroms einen Musterabgleich in Echtzeit einer Codierung des empfangenen Datenstroms mit einem Satz von Codierungen vornimmt, der die erste Codierung aufweist.