Anomalie-Detektion in IoT-Traffic

"An outlier is an observation that deviates so much from other observations as to arouse suspicion that it was generated by a different mechanism." [1]

Der Definition von Hawkins nach stellen Anomalien (engl. Synonym "outlier") also Abweichungen von einem als Normalzustand definierten Beobachtungsrahmen dar. Es wird allgemein zwischen drei Arten von Anomalien unterschieden:

• Punkt-Anomalien: Zufällig und vereinzelt auftretende Abweichungen. Beispiel: Ein weißes Ei in einer Packung mit braunen Eiern.
• Kontextuelle Anomalien: Werden durch ihren Kontextrahmen bestimmt, in den sie nicht passen (häufig Zeit und/oder Raum). Beispiel: Temperaturen um 40 °C im Juni.
• Kollektive Anomalien: Abweichungen, die jeweils für sich genommen nicht als Abweichungen wahrgenommen werden müssen, als Gruppe jedoch schon. Beispiel: Bankbetrüger, der bei Überweisungen immer einen kleinen Teil für sich abzweigt.

In der Informationstechnologie sind Anomalien Abweichungen innerhalb eines Datensets: "Anomalies are patterns in data that do not conform to a well defined notion of normal behavior."[2] Die Muster der Datensets werden als Verhalten betrachtet, das einer Entität oder mehreren Entitäten innerhalb des beobachteten Systems zuzuordnen ist. Die Erkennung und Zuordnung dieser Muster wird entsprechend als Anomalie-Detektion bezeichnet: "Anomaly detection refers to the problem of finding patterns in data that do not conform to expected behavior."[2]

Was das konkret heißt, zeigt Abb. 1 mit den Fischen auf plakative Weise: Das menschliche Gehirn ist auf Anhieb dazu im Stande, den blauen Fisch in der Gegenrichtung von den gelben Fischen zu unterscheiden.

Was uns so einfach erscheint, ist in der Realisierung technischer Systeme jedoch weitaus schwieriger. Die Verfahrensweisen werden im Wesentlichen nach drei Modellen unterschieden: Beaufsichtigte Anomalie-Detektion (Engl.: supervised anomaly detection), teilbeaufsichtigte Anomalie-Detektion (Engl.: semi-supervised anomaly detection) und unbeaufsichtigte Anomalie-Detektion (Engl.: unsupervised anomaly detection).

Im Rahmen beaufsichtigter Anomalie-Detektion wird ein System mit Trainingsdatensätzen trainiert und getestet, die Anomalien enthalten; zudem ist jedes enthaltene Datenfragment zuvor analysiert und bezeichnet worden, so dass die Anomalien bekannt sind. Auf diese Weise wird ein Modell kreiert, mit dem Anomalien erkannt werden können. Dasselbe gilt für teilbeaufsichtigte Systeme, nur dass die Trainingsdatensätze hier keine Anomalien enthalten. Bei unbeaufsichtigter Anomalie-Detektion dagegen wird kein Modell gebildet, hier werden Daten ohne vorhergehende Analyse und Bezeichnung dem System übergeben, das die Anomalien anhand der Eigenschaften des Datensatzes insgesamt detektiert.

Für die beiden Ansätze mit Modellbildung kommen meist Verfahren der künstlichen Intelligenz zum Einsatz, während für das Letztere eher Data-Science-Verfahren eingesetzt werden. Die einzelnen Wertekategorien eines Datensets werden als Features bezeichnet. Jedes Element des Datensets verfügt über einen Wert pro Feature.

Wie Anomalie-Detektion konkret technisch verläuft, ist von dem verwendeten Verfahren abhängig, dem Verständnis halber aber ein einfaches Beispiel: Angenommen, die Elemente eines zweidimensionalen Datensets sollen auf Anomalien untersucht werden, dann wäre es zum Beispiel möglich, die Werte der Features gegeneinander abzutragen. Das Ergebnis eines solchen Verfahrens könnte dann wie in Abb. 3 aussehen. So wie wir die Regionen der größten Gruppierungen erkennen können, ist es auch möglich, diese durch einen Algorithmus bestimmen zu lassen und so Werte zu identifizieren, die außerhalb dieser als normal geltenden Bereiche liegen.

Aus diesem Beispiel können wir mitnehmen, dass es letztlich darum geht, anhand der Features und ihrer Werte entweder Wertebereiche, Kombinationen von Werten oder Beziehungen zwischen Werten zu ermitteln, durch welche die Normalität letztlich definiert wird. Die Ergebnisse von Anomalie-Detektion sind aber nicht immer so eindeutig, dass Anomalien klar unterschieden werden können oder eindeutig genug abgesetzt sind. Je nach Verfahren kann daher ein weiterer Analyse- bzw. Interpretationsschritt notwendig sein, um die Ergebnisse aufzuarbeiten.

Übertragen auf Netzwerktechnologie bedeutet das, dass Datenverkehr mitgelesen und/oder aufgezeichnet werden muss, um die Datensets zu erhalten. Die Features dieser Datensets können dann alle lesbaren Header-Informationen, sowie prinzipiell auch die Nutzlast einer PDU (Protocol Data Unit – Datenpaket) sein. Allein bei Auswertung aller Felder eines IPv4-Protokoll-Headers lägen demnach 12 Features vor, die verarbeitet werden müssten.

Sinnvoller erscheint dagegen eine gezielte Auswahl relevanter Features, um durch eine Beschränkung auf relevante Features die Rechenzeit möglichst gering zu halten (Bei der Entwicklung von KI- oder Data-Science-Modellen sind Feature-Selektion, Feature-Extraktion und eine Gewichtung von Features zwecks Optimierung des Prozesses nicht ungewöhnlich, gestützt auf mathematische Modelle, die dabei entstehende Fehler minimieren sollen). Genau diese Feature-Auswahl kann aber schon zu Problemen führen, da das Ziel wie anfangs beschrieben schließlich eine Erkennung von bisher unbekannten Anomalien ist.

Hierbei kann die Feature-Auswahl dazu führen, dass ganz im Gegenteil relevante Informationen nicht berücksichtigt werden. Dasselbe gilt auch für die Gewichtung von Features: Diese Gewichtung kann aber für bisher unbekannte Angriffsvektoren nur schwerlich getroffen werden, wodurch das Risiko sowohl der Überanpassung (overfitting) als auch der Unteranpassung (underfitting) besteht. Nehmen wir nun an, diese Faktoren wurden alle perfekt ausgewählt und eine valide Baseline definiert, dann besteht im nächsten Moment die Frage, über welchen Zeitraum bzw. über welche Datenmenge die Baseline definiert ist. In der Eigenschaft dieser Menge als zeit- und wertediskretes Signal besteht darüber hinaus die Frage, ob der zu analysierende Abschnitt in Teilschritten immer nur um einen kleinen Offset weitergeschoben wird, oder als voller Schritt um einen Abschnitt vollständiger Länge (vgl. Abb. 5).

Aus diesen Gründen wäre es wohl riskant, bei einem System allein auf ein einzelnes Verfahren zur Anomalie-Detektion zu setzen. Best Practice wäre ein kombinierter Ansatz, bei dem wenigsten sich zwei Verfahren gegenseitig ergänzen bzw. kontrollieren. Je nach Reifegrad des Systems ist es zudem sinnvoll, weiterhin parallel auf die klassischen statischen Methoden zu setzen, um eine weitere Kontrollinstanz zu haben.

Es gilt also einige Herausforderungen auf dem Weg zu einem Anomalie-Detektion-System zu meistern. Die Ergebnisse davon münden einerseits in interessanten wissenschaftlichen Arbeiten, andererseits in praktischen Lösungen in Form von Produkten, die mittlerweile von einer Vielzahl von Sicherheitslösungsherstellern angeboten werden, sei es in (N)IDS ((Network) Intrusion Detection System), SIEM (Security Information & Event Management), Netzwerk-Monitoring, NextGen-/UTM-Firewalls oder ähnlichen Systemen. Für solche Produkte gilt jedoch, dass sich aus Kundensicht nicht immer zweifelsfrei feststellen lässt, ob sich hinter einem "behavioral detection"-Feature wirklich ein dynamisches System befindet, oder doch ein statisches, solange der Hersteller hierzu keine eindeutigen Angaben macht.

Über die Frage von Verfahren/ Prozess/ Algorithmus hinaus stehen noch Entscheidungen an, wie das System ins Netzwerk zu integrieren ist, wie die Sensoren angelegt werden. Dies ist vor allem davon abhängig, um was für ein Netzwerk es sich handelt, bzw. aus was für Hosts es besteht. Besitzen die Hosts des Netzwerks über eine gewisse Rechenleistung bzw. über freie Kapazitäten, so können sie als Sensoren des Netzwerks eingesetzt werden; prinzipiell wäre es auch möglich, sie schon erste Teile der Datenverarbeitung erledigen zu lassen. Ist das nicht der Fall, wie zum Beispiel bei einer Vielzahl von IoT-Devices, so müssen sich die Sensoren an anderen Punkten des Netzwerks befinden. Sensoren können entweder Inline-Sensoren sein, wenn sie Teil eines Übertragungspunktes sind, oder Out-of-Line-Sensoren, an welche der Traffic gespiegelt wird.

Es kann zwischen den folgenden drei Gründen für die Entdeckung von Anomalien in Netzwerken unterschieden werden [3]:

• Angriff: Unautorisierter Zugriff auf das System/ Penetration des Systems/ Daten-Exfiltration.
• Systemmissbrauch: Autorisierter, aber missbräuchlicher Zugriff auf das System.
• Irreguläres Systemverhalten: Systemverhalten außerhalb vorgegebener Parameter.

Dementsprechend kann eine Anomalie auf einen Angriffsvektor hindeuten, muss aber keiner sein. Anomalie-Detektion kennt daher vier Zustände:

• True-Positive: Der Normalzustand wird korrekt erkannt.
• False-Positive: Ein Normalzustand wird fälschlich als Anomalie erkannt.
• True-Negative: Anomalien werden korrekt erkannt.
• False-Negative: Eine Anomalie wird fälschlich als Normalzustand erkannt.

Werden jeweils alle False-Positive- und alle False-Negative-Ergebnisse zu der Gesamtzahl positiver bzw. negativer Zustände in Relation gesetzt, ergeben sich daraus False-Positive- und False-Negative-Ratio. Die Qualität eines NBAD-Systems kann über diese beiden Parameter sowie über die notwendige Verarbeitungszeit beschrieben werden.

Ein NBAD-System mit gutem Design und potenter Hardware kann die Analyse nahe Echtzeit durchführen. Dabei gilt: Je größer der Beobachtungszeitraum und je größer die Feature-Auswahl, desto ressourcenintensiver die Detektion. Die Ressourcenanforderungen sind so hoch, dass aktuelle Midrange-Netzwerk-Hardware hiermit auf jeden Fall überfordert wäre – deshalb spricht vieles für ein dediziertes System als Out-Of-Line-Sensor.

Soll Anomalie-Detektion genutzt werden, um praktische Tätigkeiten der IT-Security im Netzwerk zu automatisieren, ist zusätzlich zur Erkennung ein weiteres System notwendig, dass darauf basierend Maßnahmen einleitet. Dies gehört nicht zum Standard-Umfang von NBAD-Systemen.

Ein grundsätzliches Problem verbleibt letztlich bei NBAD-Systemen: Es gibt Angriffsvektoren, die mit einer sehr kleinen Anzahl Datenpakete auskommen und kaum erkennbar sein werden, wenn nur eine Hand voll oder auch einige wenige PDUs innerhalb eines Datensets liegen. Schwierigkeiten haben NBAD-Systeme außerdem mit dynamischen Netzwerkumgebungen, Stichwort BYOD: Hier ist die Definition des Normzustandes starken Schwankungen unterworfen.