maschinelle lernverfahren zur anomalie-erkennung aus...
TRANSCRIPT
April 2018 – September 2018
Erstgutachter: Prof. Dr. Sebastian Abeck
Zweitgutachter: Prof. Dr. Bernhard Neumair
Betreuender Mitarbeiter: Michael Schneider
Cooperation & Management (C&M, Prof. Abeck)
Institut für Telematik, Fakultät für Informatik
www.cm.tm.kit.edu
KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft
Masterarbeit
Patrick Glück
Maschinelle Lernverfahren zur Anomalie-Erkennung aus Aufzeichnungsdaten von Web-Anwendungen
Ehrenwörtliche Erklärung iii
Ehrenwörtliche Erklärung
Ich erkläre hiermit, die vorliegende Arbeit selbstständig verfasst und keine anderen als die an-
gegebenen Quellen und Hilfsmittel verwendet zu haben.
Karlsruhe, den 30. September 2018
Patrick Glück
Inhaltsverzeichnis v
Inhaltsverzeichnis
1 Einleitung 1
1.1 Einführung in das Themengebiet .......................................................................................... 1
1.1.1 Projektszenario ....................................................................................................... 2
1.1.2 C&M-Software-Entwicklung ................................................................................. 3
1.2 Behandelte Fragestellungen in dieser Arbeit ......................................................................... 4
1.3 Demonstrator und dessen Komponenten ............................................................................... 4
1.3.1 Allgemeine Beschreibung der Demonstrator-Komponenten ................................. 5
1.3.2 Feature-Beschreibung der wichtigsten Komponenten ........................................... 6
1.4 Gliederung der Arbeit ............................................................................................................ 8
2 Grundlagen 11
2.1 Account Misuse ................................................................................................................... 11
2.2 Anomalien ........................................................................................................................... 11
2.2.1 Was sind Anomalien? .......................................................................................... 11
2.2.2 Arten von Anomalien ........................................................................................... 11
2.2.3 Anomalie-Erkennung ........................................................................................... 12
2.3 Intrusion Detection (Systeme) ............................................................................................. 12
2.3.1 Ausprägungen von Intrusion Detection Systemen ............................................... 13
2.4 Maschinenlernen ................................................................................................................. 14
2.4.1 Arten von Maschinenlernen ................................................................................. 14
2.4.2 Prozess des Maschinenlernens ............................................................................. 15
2.5 Aufzeichnungsdaten ............................................................................................................ 15
2.5.1 Log-Formate ......................................................................................................... 15
2.5.2 Vorverarbeitung ................................................................................................... 16
2.5.3 Feature-Extraktion / -Selektion ............................................................................ 16
2.6 Application Programming Interfaces .................................................................................. 16
2.6.1 OpenAPI Spezifikation & Swagger ..................................................................... 17
2.7 Microservice(-Architektur) ................................................................................................. 17
2.8 Python.................................................................................................................................. 17
2.8.1 Flask & Flask-RESTful ........................................................................................ 17
2.8.2 Flasgger ................................................................................................................ 18
2.8.3 Nameko ................................................................................................................ 18
2.9 RabbitMQ ............................................................................................................................ 20
2.10 Elasticsearch ........................................................................................................................ 20
2.11 Wahrscheinlichkeitsdichte-Verteilung ................................................................................ 20
3 Stand der Technik / Forschung 23
3.1 Architektur des Kooperationspartners und Integrationsansatz der Anomalie-Erkennung.. 23
3.1.1 Aufbau der Technologie-Umgebung ................................................................... 23
3.1.2 Integrationsansatz für die Anomalie-Erkennung ................................................. 25
3.2 Betrachtete Verfahren ......................................................................................................... 27
3.2.1 Bag of Words-Ansatz .......................................................................................... 27
3.2.2 NNIDS ................................................................................................................. 28
3.2.3 Anomalie Erkennung von Nutzerverhalten zur Datenbank-
sicherheitsüberprüfung basierend auf OCSVM .................................................................. 28
4 Prozessmodell für die Anomalie-Erkennung 29
4.1 Erläuterung des Einsatzumfelds ......................................................................................... 29
4.2 Definition der Artefakte ...................................................................................................... 29
4.3 Schnittstellen-Kommunikation ........................................................................................... 29
4.4 Orchestrierung der Komponenten....................................................................................... 29
5 Komponenten des Erkennungsprozesses 31
5.1 Erzeugung von Nutzermodellen ......................................................................................... 31
5.1.1 Notwendigkeit ..................................................................................................... 31
5.1.2 Aufbau der Verhaltensmodelle ............................................................................ 31
5.1.3 Anomalien ........................................................................................................... 33
5.1.4 Aufbau und Funktionsweise des Generators ....................................................... 33
5.1.5 Umwandlung in einen Microservice ................................................................... 34
5.2 Verarbeitung der Aufzeichnungsdaten ............................................................................... 34
5.2.1 Daten-Bereinigung .............................................................................................. 34
5.2.2 Aggregation in IP/User-Packete .......................................................................... 34
5.2.3 Erzeugung von Sitzungen .................................................................................... 34
5.3 Anwendung des maschinellen Lernverfahren .................................................................... 34
5.3.1 Erklärung des Verfahren...................................................................................... 34
5.3.2 Umsetzung in diesem Umfeld ............................................................................. 34
5.4 Visualisierung ..................................................................................................................... 34
6 Einsatz in der Betriebsumgebung 35
6.1 Aufbau der Testumgebung ................................................................................................. 35
6.2 Umsetzung der Erweiterungen ........................................................................................... 35
6.3 Betrieb der Lösung ............................................................................................................. 35
6.4 Evaluation der Ergebnisse .................................................................................................. 35
6.5 Inbetriebnahme beim Kooperationspartner ........................................................................ 35
Inhaltsverzeichnis vii
7 Projektteam-Arbeiten 37
7.1 Zusammensetzung des Projektteams ................................................................................... 37
7.2 Zu bearbeitendes Themengebiet .......................................................................................... 37
7.2.1 Aufgabenstellungen .............................................................................................. 38
7.2.2 Zielsetzungen ....................................................................................................... 38
7.3 Einarbeitung des Projektteams ............................................................................................ 39
7.4 Bearbeitung der Aufgabenstellungen .................................................................................. 39
7.5 Ergebnisse der Projektteam-Arbeit ..................................................................................... 40
7.6 Evaluation der Zusammenarbeit .......................................................................................... 40
8 Zusammenfassung und Ausblick 41
Anhänge XLIII
A Beiträge zu WASA-Kurseinheiten ................................................................................ XLIII
B Literaturanalysen ............................................................................................................ XLV
C Literatur ........................................................................................................................ XLVII
Einleitung 1
1 Einleitung
Dieses erste Kapitel gewährt zunächst einen groben einführenden Einblick in die behandelte
Thematik. Hierbei wird zuerst motiviert, weshalb die Anomalie-Erkennung aus Aufzeichnungs-
daten von Web-Anwendungen mit Hilfe von maschinellen Lernverfahren interessant und wün-
schenswert ist. Anschließend folgen eine Beschreibung des Projektszenarios, auf welchem diese
Arbeit aufbaut sowie eine Erläuterung zur Vorgehensweise für die Entwicklung eines Software-
Systems bei C&M unter Verwendung von Behavior-Driven Development und Domain-Driven
Design. Aufbauend auf der zuvor beschriebenen Thematik werden die Fragestellungen, die für
die Umsetzung des in der Arbeit beschriebenen Projekts relevant sind, erläutert. Aus den Frage-
stellungen lässt sich anschließend die dabei entstehende Demonstrator-Anwendung ableiten und
beschreiben. Dieser Demonstrator ist für die Umsetzung und Visualisierung der Verarbeitung
der Aufzeichnungsdaten sowie der betrachteten Lernverfahren zuständig. Den Abschluss dieses
ersten Kapitels bildet ein Überblick über die folgenden Kapitel und die dadurch entstehende
Struktur dieser Arbeit.
1.1 Einführung in das Themengebiet
Durch die fortschreitende Digitalisierung und die damit einhergehende Auslagerung von Ver-
waltungs- und Anwendungsprozessen in Web-Applikationen gewinnt der Schutz dieser Soft-
ware-Systeme immer mehr an Bedeutung. Hierbei ist der Schutz nicht nur für den Nutzer, des-
sen Informationen und Nutzungsverhalten erhoben werden, relevant. Auch Organisationen, die
diese Web-Anwendungen anbieten, müssen Maßnahmen für die Sicherheit ihrer Nutzer umset-
zen. Das Vertrauen der Nutzer ist eines der wichtigsten Güter für diese Organisationen und da-
her müssen die Daten und Konten bestmöglich vor Missbrauch und Kompromittierung ge-
schützt werden. [MV-AMD]
Um Anwendungen oder Netzwerke und deren Bestandteile vor Kompromittierung zu schützen,
entwickelten sich über die letzten Jahrzehnte hinweg sogenannte Intrusion Detection Systeme
oder kurz IDS. Erste Schritte in Richtung eines Intrusion Detection Systems machte James An-
derson von der National Security Agency in seiner Arbeit. Zu Beginn dienten Intrusion Detec-
tion Systeme, als Werkzeug für Administratoren, um Logs besser prüfen zu können. Über die
Jahre hinweg war es nötig diese Systeme und deren Fähigkeiten weiterzuentwickeln, um den
sich wandelnden Anforderungen anzupassen. Heutzutage ist die Verwendung solcher Intrusion
Detection Systeme in nahezu jeder größeren Organisation zu finden. Hauptunterscheidungs-
Merkmal von IDS ist die unterschiedliche Methodik. Unterscheiden lässt sich hier hauptsächlich
die Verwendung von Missbrauchs-Erkennung und Anomalie-Erkennung. Es existieren noch
weitere Methodiken, welche allerdings eher selten verwendet werden. Eine genauere Erläute-
rung zu IDS und deren Ausprägungen wird im Grundlagen-Kapitel gegeben.
Bei der Nutzung einer jeden Web-Anwendung werden auf einem Server Aufzeichnungsdaten,
sogenannte Log-Dateien, erstellt. Diese Dateien beinhalten jegliche Aktionen und Zugriffe, die
ein Nutzer tätigt. Access-Logs dokumentieren beispielsweise die IP-Adresse, den Zeitstempel
und die Ressource, auf die zugegriffen wurde. Die Aufzeichnungsdaten enthalten jedoch weitere
Details mit denen letztendlich über einen gewissen Zeitraum ein Verhaltensprofil des Nutzers
gebildet werden kann.
2 Einleitung
Anhand dieses Verhaltens können mit verschiedenen Technologien Anomalien und eventuell
eine Kompromittierung des Nutzerkontos festgestellt werden. Beispielsweise würde bei einem
Benutzerkonto, welches ausschließlich von einem Gerät an einem festen Ort verwendet wird,
ein Login von einem unüblichen Ort als Anomalie im Nutzerverhalten erkannt werden.
Allerdings sind die Zusammenhänge zwischen "echtem" und "böswilligem" Nutzerverhalten
nicht immer trivial und einfach erkennbar, sondern erfordern die Bildung eines Netzes aus Ab-
hängigkeiten zwischen einer Vielzahl von Variablen, sodass ein Einsatz von Technologien die
über einfache "wenn-dann-oder"-Logik hinausgehen, notwendig ist.
Um nun Anomalien in einem Datenstrom von Aufzeichnungsdaten zu erkennen, erfolgt im
Rahmen dieser Arbeit in Zusammenarbeit mit einem Projektteam die Entwicklung einer De-
monstrator-Web-Anwendung, die ein Intrusion Detection System modellieren soll. Mit dieser
im Folgenden Demonstrator genannten Anwendung, soll die Möglichkeit geboten werden, einen
aus realen Aufzeichnungsdaten generierten Datenstrom mit verschiedenen Maschinenlern-
Verfahren auf Anomalien zu untersuchen und sich anschließend die erzielten Ergebnisse über-
sichtlich und kompakt anzeigen lassen zu können.
1.1.1 Projektszenario
Dieses Projekt wird in Zusammenarbeit mit der Firma iC-Consult GmbH aus Stuttgart durchge-
führt. iC-Consult ist ein Dienstleister für Identitäts- und Zugangsmanagement-Dienste und stellt
beispielsweise Authentifizierungs- und Autorisierungslösungen für Firmen wie Daimler und
Porsche. Dadurch wird es den Mitarbeitern dieser Firmen ermöglicht sich mit einem zentralen
Nutzerkonto bei verschiedenen Diensten und Webanwendungen anzumelden und die vereinbar-
ten Rechte für die derzeitige Anwendung zu erhalten. Der Aufbau dieser Beziehung wird in
Abbildung 1 dargestellt.
Abbildung 1: Aufbau der IAM-Struktur zwischen bspw. iC-Consult und einer Firma die deren
Dienste in Anspruch nimmt
Hierdurch wecken diese Konten allerdings auch das Interesse von Angreifern. Vor allem Kon-
ten von Personen mit Zugriff auf höhere Rechteebenen fallen ins Auge von Angreifern. Um
schnellstmöglich auf kompromittierte oder unter Angriff befindliche Nutzerkonten reagieren zu
können, möchte iC-Consult im Rahmen dieses Projekts die eigens erzeugten Aufzeichnungsda-
ten auf Anomalien im Benutzerverhalten mittels maschinellem Lernen untersuchen. Ein Bei-
spiel für diesen Anwendungsfall ist Kompromittierung und Verwendung eines Kontos durch
einen Angreifer von innerhalb oder außerhalb, mit anschließendem auffälligem Nutzungsverhal-
Einleitung 3
ten, wie das Ändern von Passwort, E-Mail und anderen persönlichen Daten. Ein Verhalten das
nur in seltenen Fällen von einem Nutzer innerhalb einer Sitzung durchgeführt wird.
1.1.2 C&M-Software-Entwicklung
Der Software-Entwicklungsprozess der Forschungsgruppe basiert auf einer agilen Vorgehens-
weise, die sich auf das Modellieren des gewünschten Verhalten (Behavior-Driven) und der rele-
vanten Domäne (Domain-Driven) fokussiert. Durch den Verhaltens-basierten Entwicklungsan-
satz erhält man einzelne sogenannte Features, welche später dem konkreten Entwicklungszyklus
den Ablauf vorgeben. Hierbei wird das Projektteam in Front- und Backend-Teams aufgeteilt. In
Abbildung 2 wird der Entwicklungsprozess von C&M in einer vereinfachten Form dargestellt.
Schritt 1 – Ziele und Features der Software
Grundsätzlich wird ein Feature nach dem anderen implementiert. Bevor allerdings mit der Im-
plementierung der Features begonnen werden kann, müssen die Ziele und Fähigkeiten der zu
entwickelnden Software definiert werden. Hierfür beschreibt man Geschäftsziele, welche den
Nutzen des Systems beschreiben, sowie die Funktionalität, um diese Geschäftsziele zu errei-
chen.
Abbildung 2: Vereinfachte Darstellung des C&M-Entwicklungsprozess [CM-AD]
Im nächsten Zwischenschritt leitet man aus der zuvor gewonnenen ersten Beschreibung die
Features ab, welche später implementiert werden. Sollte bereits ein Modell der relevanten Do-
mäne existieren, so muss dieses bei der Spezifizierung der Features mit einbezogen werden.
Schritt 2 – Initiales Domänenmodell
Nachdem die notwendigen Features festgelegt wurden, wird ein initiales Domänenmodell er-
stellt. Dieses Modell beschreibt die Domäne, in der das System agiert und das benötigte Domä-
nenwissen für jedes Feature.
Schritt 3 – Implementierung Domänenmodell und Feature
In diesem Schritt beginnt der eigentliche Zyklus der Software-Entwicklung. Hier wird mit der
Implementierung des Domänenmodells und des ersten Features sowie der relevanten Architek-
tur und zugehörigen Interfaces begonnen.
Schritt 4 – Testen
4 Einleitung
Nachdem die Implementierung des Domänenmodells und des ersten Features abgeschlossen
wurde, kann der entstandene Code mit Unit-Tests auf Fehler und Bugs untersucht werden. Zu-
sätzlich ist es notwendig, dass das Feature auch auf benutzerorientierter Ebene getestet wird, um
eine einwandfreie Funktionsweise sicherzustellen. Die folgenden zwei Schritte werden nur
durchgeführt, insofern noch weitere Features zur Implementierung vorhanden sind.
Schritt 5 – Spezifikation nächstes Feature
Nachdem das vorherige Feature vollständig implementiert und erfolgreich getestet wurde, muss
anhand der Priorität das nächste zu entwickelnde Feature gewählt und spezifiziert werden.
Schritt 6 – Anpassung Domänenmodell
Bevor das im vorherigen Schritt gewählte Feature implementiert werden kann, ist eine Anpas-
sung bzw. Erweiterung des Domänenmodells um die Informationen des Features notwendig.
Anschließend kann der Entwicklungszyklus, beginnend mit Schritt 3, erneut durchgeführt wer-
den, bis schlussendlich alle Features implementiert wurden. [CM-AD]
1.2 Behandelte Fragestellungen in dieser Arbeit
Im Rahmen dieser Arbeit soll wie im zuvor beschriebenen Szenario ein modellhaftes Intrusion
Detection System unter Verwendung von Anomalie-Erkennung mit Maschinenlern-Verfahren
konzipiert und umgesetzt werden. Hierfür müssen verschiedene Fragestellungen rund um die
Verarbeitung von Aufzeichnungsdaten, der Verwendung von verschiedenen Lernverfahren,
sowie das Zusammenspiel dieser Teil-Komponenten beantwortet werden. Einige dieser Frage-
stellungen werden nachfolgend aufgelistet.
1. Welche Daten werden betrachtet und wie werden sie verarbeitet?
a. Welche Arten von Aufzeichnungsdaten sind vorhanden?
b. Wie sind die Aufzeichnungsdaten strukturiert?
c. Welchen Daten werden für die Anomalie-Erkennung benötigt bzw. verwendet?
d. Wie müssen die Aufzeichnungsdaten für die Verwendung mit Maschinenlern-Verfahren
verarbeitet werden?
2. Welche Maschinenlernverfahren werden betrachtet?
a. Welche Verfahren eignen sich für die Anomalie-Erkennung?
b. Wie funktionieren die jeweiligen Verfahren?
c. Gibt es spezielle Anforderungen oder Randbedingungen?
3. Eigenschaften der gewünschten Erkennungs-Ergebnisse
d. Für jeden Nutzer oder über die Gesamtheit?
e. Welche Eigenschaften zur Erkennung?
1.3 Demonstrator und dessen Komponenten
Wie im einleitenden Text bereits erwähnt, soll im Rahmen dieser Arbeit ein modellhaftes Intru-
sion Detection System in Form einer Demonstrator-Web-Anwendung entwickelt werden. Die
Einleitung 5
Möglichkeiten, die dieser Demonstrator besitzen soll, werden nachfolgend in textueller sowie in
Form von Gherkin-Features näher beschrieben.
Abbildung 3: Mock-Up des Demonstrator-Interfaces
Abbildung 3 gibt bereits einen Ausblick auf das Interface des Demonstrators. Hierbei gibt es
Menü-Punkte für die Generierung und Anzeige der Nutzer-Verhaltens-Modelle sowie für die
Durchführung und Anzeige von Analysen auf Anomalien sowie eine Informations-Rubrik mit
Erklärungen zum Ablauf und der Funktionsweise der Lernverfahren.
1.3.1 Allgemeine Beschreibung der Demonstrator-Komponenten
Der Gesamtprozess, den der Demonstrator anbieten soll, wird in Abbildung 4 beispielhaft dar-
gestellt. Aus diesem lassen sich die einzelnen Teilprozesse ableiten und in einzelne Komponen-
ten abgrenzen. Das Zusammenspiel dieser Teilkomponenten wird in Kapitel 4 im Detail erklärt,
bevor die einzelnen Komponenten in den darauffolgenden Kapiteln einzeln in Unter-
Komponenten zerlegt und näher beleuchtet werden.
Komponente 1: Nutzerverhalten-Modell-Generator
Im ersten Schritt wird zunächst der Datenstrom von Aufzeichnungsdaten vorbereitet. Hierfür
werden mit Daten aus der Industrie Aufzeichnungsdaten-Modelle erzeugt. Bestandteil dieser
Modelle sind speziell generierte Aufzeichnungsdaten für modelhafte Benutzer. Hierbei wird
beispielsweise parametrisiert, inwiefern die Aktionen verteilt sind, wie hoch der Anteil von
Anomalien ist sowie die Größe der Zeitspanne und die Anzahl von Einträgen pro Zeiteinheit.
Diese Modelle dienen anschließend als Input für die Transformation in ein Format, welches von
den Maschinenlern-Verfahren im nächsten Schritt aufgenommen und verarbeitet werden kann.
Komponente 2: Nutzerverhalten-Vorverarbeitung
Um eine Anomalie-Analyse auf den generierten Modellen durchführen zu können, ist es not-
wendig, die erzeugten Logs von unnötigen Features und Zeichen zu befreien, Größe der Logs zu
minimieren (z.B. Entfernung von Leerzeichen, etc.) und abschließend spezifische Anpassungen
für die Lernverfahren durchzuführen (z.B. Umwandeln von Text-Werten in numerische Werte,
etc.).
Komponente 3: Nutzerverhalten-Anomalie-Analyse
6 Einleitung
Nach der Generierung und Transformation der Log-Daten, können diese auf Anomalien unter-
sucht werden. Dafür werden die Log-Daten mit Hilfe von mehreren Lernverfahren analysiert.
Die verwendeten Lernverfahren, sowie deren Funktionsweise werden in Kapitel 6 beschrieben.
Abbildung 4: Mockup des entstehenden Prozesses
Komponente 4: Analyse-Ergebnis-Anzeige
Abschließend findet die Anzeige der Ergebnisse der Anomalie-Analyse im Demonstrator statt,
sodass die Resultate der verschiedenen Lernverfahren verglichen werden können.
1.3.2 Feature-Beschreibung der wichtigsten Komponenten
In diesem Abschnitt wird eine Beschreibung der wichtigsten Funktionalitäten der Demonstrator-
Anwendung in Form von Gherkin-Features geliefert. Anhand dieser Features findet die Imple-
mentierung sowie das Testen innerhalb des Projektteams statt.
Feature 1 beschreibt das Durchführen einer auf Anomalie-Erkennung basierenden IDS Simula-
tion mit Nutzerverhaltens-Modell. Hierbei unterscheidet man innerhalb des Features zwischen
verschiedenen Szenarien. Das erste Szenario beschreibt den Anwendungsfall, dass Parameter
für die Maschinenlern-Verfahren gesetzt wurden und bereits ein Nutzerverhaltens-Modell exis-
tiert, auf dem das System die Simulation ausführen kann. Somit wählt der Nutzer das Modell,
sowie die zu verwendeten Lernverfahren aus. Anschließend führt das System die Analyse durch
und zeigt deren Ergebnisse an. Im darauffolgenden Szenario existiert kein Modell auf dem eine
Simulation durchgeführt werden könnte, somit bietet das System dem Benutzer die Möglichkeit,
ein Modell zu generieren, auf welchem es anschließend die Simulation durchführt. Möchte der
Nutzer eine Analyse durchführen ohne eigene Parameter für die Lernverfahren gesetzt zu haben,
so weist das System ihn im letzten Szenario darauf hin und bietet die Möglichkeit an, eigene
Parameter einzugeben oder bereits vorhandene Standard-Parameter zu verwenden.
Einleitung 7
In Feature 2 wird das Verhalten des Systems bei der Verwaltung von Nutzerverhaltens-
Modellen beschrieben. Dabei muss zwischen verschiedenen Fällen für die Erstellung, Bearbei-
tung, Löschung von eigenen Modellen sowie dem Kopieren und Abwandeln von Modellen an-
derer Nutzer unterschieden werden.
Feature 1: Durchführung einer IDS-Simulation
Im Szenario, bei dem ein Benutzer ein Nutzerverhaltens-Modell erzeugen möchte, bietet das
System diesem Benutzer eine Eingabemaske für die Parameter und Meta-Daten des zu erzeu-
genden Modells an. Nach der Eingabe dieser Informationen generiert das System das spezifi-
zierte Modell, insofern kein identisches Modell existiert.
Möchte der Nutzer ein bereits existierendes Modell bearbeiten, wird davon ausgegangen, dass
der Benutzer bereits mindestens ein eigenes Modell erzeugt hat. Das System bietet ihm in die-
sem Fall eine Eingabemaske mit den Parametern, die bearbeitet werden können und passt an-
schließend das Modell mit den eingegebenen Parametern an.
Ähnlich ist es im Fall des Löschens eines existierenden Modells. Auch hier liegt die Annahme
vor, dass der aktuelle Benutzer bereits eigene Verhaltens-Modelle erzeugt hat. Wählt er nun ein
Modell zur Löschung aus, so fragt das System nach einer Bestätigung, bevor es das Modell im
Anschluss löscht.
Im letzten Szenario möchte ein Benutzer ein Modell, eines anderen Nutzers, an seine Bedürfnis-
se anpassen und vom System erzeugen lassen. Hierfür wird angenommen, dass andere Nutzer
bereits mindestens ein Modell erzeugt haben, welches der Nutzer auswählt. Anschließend wird
dem Nutzer eine Eingabemaske präsentiert, in welcher er die Parameter, die er abändern möchte
eingeben kann. Das System erzeugt schließlich ein neues Modell mit den gegebenen Parametern
für den aktuellen Nutzer.
Diese beiden Features sollen nur einen groben Überblick über die Haupt-Funktionen des De-
monstrators geben. Eine nähere Beschreibung der Funktionsweise der einzelnen Komponenten
der Demonstrator-Anwendung findet sich in Kapitel ?.
1. Feature: Run an anomaly IDS simulation on a user behavior model 2. As a (model) IDS operator 3. I want to detect deviations from normal user behavior in access logs 4. So that potential misuses can be detected and treated accordingly 5. 6. Scenario: Run IDS simulation on already generated user behavior data 7. Given I have already generated model user behavior data 8. And I have already set the parameters for the machine learning techniques 9. When I run a simulation on a user behavior data model 10. And select some machine learning techniques 11. Then the system shows me the results for these techniques 12. And gives a summary of the differences between them 13. 14. Scenario: Run IDS simulation with no pre-generated user behavior data 15. Given there is are no pre-generated user behavior models 16. And the parameters for the machine learning techniques are set 17. When I want to run a simulation on a user behavior data model 18. Then the system tells me that there are no models available 19. And gives me the option to generate a new user behavior model 20. And runs the simulation on that model 21. 22. Scenario: Run IDS simulation without custom parameters for the ML techniques 23. Given there are no parameters set for the ML techniques 24. When I want to run a simulation on a user behavior data model 25. Then the system tells me that there are no parameters set for the ML techniques 26. And gives me the option to enter custom parameters or use a set of default parameters
8 Einleitung
Feature 2: Verwaltung von Nutzerverhaltens-Modellen
1.4 Gliederung der Arbeit
In diesem Kapitel wird der Aufbau der weiteren Arbeit in Form der Kapitelstruktur aufgezeigt.
Zusätzlich wird eine kurze Beschreibung des Inhalts der jeweiligen Kapitel gegeben.
Kapitel 1: EINLEITUNG
Das einleitende Kapitel motiviert, weshalb Anomalie-Erkennung in Aufzeichnungsdaten mit
Hilfe von maschinellen Lernverfahren interessant und nützlich ist. Weiterhin wird ein kurzer
Einstieg in die Thematik rund um Intrusion Detection Systeme, Anomalie-Erkennung, Auf-
zeichnungsdaten, sowie Maschinen-Lernverfahren geliefert. Zusätzlich wird die Vorgehenswei-
se von C&M bei der Softwareentwicklung und der entstehende Demonstrator kurz beschrieben.
Kapitel 2: GRUNDLAGEN
Dieses Kapitel beinhaltet Informationen, die zum grundlegenden Verständnis der Inhalte der
Arbeit erforderlich sind. Hierzu zählen die Einführung in Intrusion Detection Systeme und die
verschiedenen Ausprägungen, die diese annehmen können. Weiterhin muss ein Grundverständ-
nis über Anomalien, maschinelle Lernverfahren, sowie deren Arten und Funktionsweise ge-
schaffen werden.
Kapitel 3: STAND DER TECHNIK
Im dritten Kapitel findet sich ein Überblick über die aktuell und in näherer Vergangenheit ver-
wendeten Verfahren zur Anomalie-Erkennung, sowie zur Analyse und Verarbeitung von Auf-
zeichnungsdaten.
Kapitel 4: PROZESSMODELL FÜR DIE ANOMALIE-ERKENNUNG (+)
27. Feature: Manage user behavior models 28. As a (model) IDS operator 29. I want to create, edit and delete user behavior models with different properties 30. So that I can run simulations on these models 31. 32. Scenario: Create model user behavior data 33. Given I have entered the user behavior data section of the application 34. When I want to create user behavior data model 35. Then the system gives me the possibility to enter the parameters for the model 36. And afterwards generates the model if there is not already an identical model 37. 38. Scenario: Edit model user behavior data 39. Given I have created model user data before 40. When I want to edit one of my user behavior models 41. Then the system shows me a form with the changeable parameters of the model 42. And changes the model accordingly to the new parameters 43. 44. Scenario: Delete model user behavior data 45. Given I have created model user data before 46. When I want to delete one of my user behavior models 47. Then the system gives me a prompt whether I want to delete the model or not 48. And afterwards deletes the model from the application 49. 50. Scenario: Copy model user behavior data of another user 51. Given other users have already created model user data 52. And I have chosen an existing user behavior model of another user 53. When I want to copy the properties of that model 54. Then the system gives me the possibility change parameters for the model 55. And afterwards generates the model with the given parameters
Einleitung 9
In diesem ersten Inhaltskapitel wird das Prozessmodell für die Anomalie-Erkennung bei Auf-
zeichnungsdaten mit Hilfe von maschinellen Lernverfahren beschrieben. Dabei handelt es sich
um das Zusammenspiel der zuvor beschriebenen Komponenten im Hintergrund der Demonstra-
tor-Anwendung. Hierzu zählt die Generierung von Verhaltens-Modellen mit Hilfe von echten
Aufzeichnungsdaten, die Vorbereitung dieser Aufzeichnungsdaten für die Verwendung mit
Lernverfahren, sowie die eigentliche Anwendung der Lernverfahren.
Kapitel 5: KOMPONENTEN DES ERKENNUNGSPROZESS (+)
Kapitel 6: EINSATZ IN DER BETRIEBSUMGEBUNG (+)
Kapitel 7: PROJEKTTEAM-ARBEITEN
Kapitel 8: ZUSAMMENFASSUNG UND AUSBLICK
10 Einleitung
Grundlagen 11
2 Grundlagen
Im folgenden Kapitel werden relevante Techniken, Konzepte und Technologien, die für das
weitere Verständnis dieser Arbeit notwendig sind, vertieft. Beginnend mit einer Beschreibung
von Account-Missbrauch, der die Motivation für die Thematik dieser Arbeit darstellt, werden
anschließend Anomalien definiert und erläutert. Darauffolgend wird ein Einblick in Intrusion
Detection Systeme gegeben, bevor weitere relevante Konzepte beschrieben werden können.
Technologien, die in diesem Zusammenhang beschrieben werden müssen, sind Maschinenlern-
verfahren und deren mögliche Arten. Abschließend werden der generelle Aufbau von Aufzeich-
nungsdaten von Web-Anwendungen sowie deren Verarbeitung und Transformation näher erläu-
tert.
2.1 Account Misuse
2.2 Anomalien
Da Anomalien im Großteil der Grundlagen eine gewisse Relevanz haben, wird mit der Be-
griffsbildung dieser begonnen. Weiterhin existieren verschiedene Arten von Anomalien, die im
Anschluss an die Definition erläutert und an Beispielen verdeutlicht werden. Abschließend wird
auf die Erkennung von Anomalien und die damit verbundenen Techniken eingegangen.
2.2.1 Was sind Anomalien?
In Bezug auf Anomalien existieren mehrere plausible Definitionen. Beispielsweise beschreibt
[GD+09] eine Anomalie, eher aus technischer Sicht, als ein Ereignis, welches auffällig im Kon-
text der Sicherheit ist. [CB+09] geht mehr in die mathematische Richtung und erklärt eine
Anomalie als ein Muster, welches von einem festgelegten normalen Verhalten abweicht. Als
konkretes Beispiel wird hierbei angenommen, dass man zwei Mengen 𝑋1 und 𝑋2 innerhalb der
Daten hat, in denen sich die Datenpunkte im Normalfall befinden. Existieren nun zwei Punkte
𝑦1 und 𝑦2, die fernab der beiden Mengen liegen, so können diese beiden Punkte als Anomalien
angesehen werden. Dies wird in Abbildung ? dargestellt. Allgemein lässt sich eine Anomalie als
etwas beschreiben, das von der gestellten Erwartung in einem gewissen Maße abweicht.
2.2.2 Arten von Anomalien
Es existieren verschiedene Arten von Anomalien, die unterschieden werden können. Hauptsäch-
lich differenziert man zwischen den drei Arten von Punkt-Anomalien, Kontext-Anomalien und
Kollektiv-Anomalien. Diese werden im Folgenden näher erläutert.
Punkt-Anomalien
Eine Punkt-Anomalie ist ein einzelner Punkt in der Datenmenge, der sich vom Rest der Daten
abhebt. In Abbildung 5 zeigt das Diagramm oben links eine Punkt-Anomalie, die man am Bei-
spiel von Kreditkarten-Einkäufen beschreiben kann. Hierbei bilden die schwarzen Punkte auf
der linken Seite des Diagramms die normalen Einkäufe in einem gewissen Betrags-Bereich.
Einkäufe, die sich in diesem Bereich befinden oder sehr nahe zu diesem sind, werden als normal
angesehen. Ein Einkauf mit einem Wert, der nicht unmittelbar in der Nähe des „Normalbe-
reichs“ liegt (roter Punkt im Diagramm) wird als Anomalie angesehen [Zw14].
12 Grundlagen
Kontext-Anomalien
Bei Kontext-Anomalien handelt es sich um Datenpunkte, die sich zwar in einem gewissen ak-
zeptablen Intervall befinden, allerdings im Kontext der Datenreihe einen unnatürlichen Wert
besitzen. Ein passendes Beispiel hierfür ist, der Verlauf einer Temperatur-Kurve über ein gan-
zes Jahr. Diese ist beispielhaft in Abbildung 5 (Abbildung muss noch angepasst werden) darge-
stellt. Es ist normal, dass im Winter die Kurve nach unten geht. Würde die Kurve jedoch im
Sommer einen Sprung in die Minusgrade machen, so wäre dies eine Anomalie innerhalb dieser
Datenreihe [Zw14].
Kollektiv-Anomalien
Kollektiv-Anomalien sind vergleichbar mit Kontext-Anomalien, allerdings bestehen diese aus
einer Serie von Datenpunkten mit einem abnormalen Wert [Zw14]. Eine grafische Repräsenta-
tion einer kollektiven Anomalie findet sich in der unteren Hälfte von Abbildung 5. Ein Beispiel
für eine solche Anomalie könnte man evtl. in einem Elektrokardiogramm finden.
Abbildung 5: Beispiele für die verschiedenen Anomalie-Arten (links oben: Punkt-Anomalie, rechts
oben: Kontext-Anomalie, unten: Kollektiv-Anomalie)
2.2.3 Anomalie-Erkennung
Unter Anomalie-Erkennung versteht man die aktive Suche und Überwachung von Systemen auf
Anomalien jeglicher Art. Anomalien sind hierbei ein hilfreiches Mittel in einer Vielzahl von
Anwendungsbereichen. Beispielsweise werden Anomalie-Erkennung häufig zur Feststellung
von Kreditkarten-Betrug oder bei Einbrüchen in Computer-Systeme verwendet. Letzteres Bei-
spiel findet in dieser Arbeit Anwendung, wobei Anomalien zur Erkennung der Kompromittie-
rung von Nutzer-Konten verwendet werden, anstatt direkt Einbrüche in ein System zu erkennen.
2.3 Intrusion Detection (Systeme)
Bevor Intrusion Detection und die zugehörigen Intrusion Detection Systeme beschrieben und
deren Ausprägungen erläutert werden können, muss zu Beginn erst der Hauptbestandteil dieses
Bereichs, die Eindringung (engl. Intrusion), definiert werden.
Definition Intrusion
Eine Intrusion liegt immer dann vor, wenn ein Angreifer versucht unautorisierten Zugriff auf
ein System oder eine Ressource zu erhalten oder er unautorisiert Daten manipulieren oder lö-
schen möchte. Allgemein kann eine Eindringung als jede Aktion deklariert werden, die ver-
Grundlagen 13
sucht, die Integrität, Vertraulichkeit oder Verfügbarkeit einer Ressource zu beeinträchtigen
[MG+02].
Da nun bekannt ist, was unter einer Intrusion verstanden wird, können die Erkennung solcher
Intrusions, die Intrusion Detection und die zugehörigen Systeme beschrieben werden.
Definition Intrusion Detection
Unter Intrusion Detection wird der Prozess des Überwachens eines Systems oder Netzwerks,
sowie der zugehörigen Objekte, auf Anzeichen eines Eindringens, verstanden [LL+13].
Für die Umsetzung dieser Intrusion Detection sind spezielle Systeme, sogenannte Intrusion De-
tection Systeme, entwickelt worden. Diese stehen indirekt mit Intrusion Prevention Systemen
(kurz IPS) oder auch Intrusion Detection and Prevention Systemen zusammen. Während IDS
nur für die Erkennung und das Melden von Intrusions zuständig sind, versuchen IPS, welche ein
IDS beinhalten, Intrusions zu erkennen und anschließend aktiv diesen entgegenzuwirken
[LL+13].
2.3.1 Ausprägungen von Intrusion Detection Systemen
Im Folgenden werden die verschiedenen Ausprägungsformen von Intrusion Detection Systemen
erläutert und ihre Stärken und Schwächen hervorgehoben. Hierbei gibt es verschiedene Ausprä-
gungsmöglichkeiten bei der Erkennungs-Methodik, der Herangehensweise für die jeweilige
Methodik, sowie bei der Technologie, die auf Eindringungen untersucht wird.
Methodik
Bei der verwendeten Methodik von Intrusion Detection Systemen unterscheidet man hauptsäch-
lich zwischen zwei Formen. Die Wissens-basierte Erkennung, auch Signatur-basierte Erken-
nung oder Missbrauchs-Erkennung genannt, vergleicht aufgezeichnete Ereignisse mit Mustern
oder Zeichenketten die einen bekannten Angriff oder eine bekannte Bedrohung beschreiben.
Dies ermöglicht eine einfache und effektive Erkennung von bereits bekannten Angriffsmustern.
Durch das Vergleichen mit bereits bekannten Bedrohungen ist es allerdings nur schwer möglich
unbekannte Angriffe oder Varianten dieser zu erkennen. Zusätzlich entsteht ein hoher Aufwand
durch das aktuell Halten der Muster und Signaturen [LL+13].
Anomalie-basierte Erkennung versucht zwischen normalem und davon abweichendem Verhal-
ten zu unterscheiden, um Angriffe aufzudecken. Hierzu überwacht das System beispielsweise
Aktivitäten oder Netzwerk-Verbindungen von Hosts oder Nutzern über einen gewissen Zeit-
raum für die Bildung eines Profils, welches das normale Verhalten beschreibt. Anschließend
werden aufgezeichnete Events mit dem beobachteten Profil abgeglichen und bei einer Abwei-
chung ein Alarm ausgegeben [LL+13].
Vorgehensweisen
• Statistisch-basiert
• Muster-basiert
• Regel-basiert
• Zustands-basiert
• Heuristik-basiert
Technologie
14 Grundlagen
Bei der zu überwachenden Technologie innerhalb eines Intrusion Detection Systems, kann man
zwischen verschiedenen Möglichkeiten wählen. Nachfolgend findet sich eine Auflistung und
Erläuterung der wichtigsten Ausprägungen.
• Host-basierte Intrusion Detection
• Network-basierte Intrusion Detection
• Mixed Intrusion Detection
• Distributed Intrusion Detection
2.4 Maschinenlernen
Unter maschinellem Lernen oder auch Maschinenlernen versteht man den Vorgang der Ent-
wicklung von Systemen, die eine Simulation des menschlichen Lernprozesses anstreben. Das
bedeutet, dass diese Systeme versuchen, sich automatisch selbst in der ihnen zugeteilten Aufga-
be zu verbessern. Hierfür werden die Ergebnisse und Erfahrungen vorheriger Durchläufe ver-
wendet. Zusätzlich dient diese Art von Verfahren zur Lösung einer Vielzahl von Problemen.
Dazu zählen die automatische Extraktion von bekannten oder auch unbekannten Strukturen
sowie Clustering, Klassifikation, Regression und Dimensionsreduktion. Maschinelles Lernen ist
in einer Vielzahl von Anwendungsgebieten einsatzfähig. Hierzu gehören beispielsweise Sprach-
erkennung, Verarbeitung von natürlicher Sprache, Steuerung von Robotern oder autonome
Fahrzeuge.
2.4.1 Arten von Maschinenlernen
Innerhalb des Maschinenlernens lassen sich grundsätzlich zwei Arten unterscheiden. Durch
verschiedene Vorgehensweisen sind beide Bereiche für unterschiedliche Anwendungsgebiete
anwendbar.
Überwachtes Lernen
Bei überwachten Lernverfahren existiert eine Trainings-Phase vor der eigentlichen Anwendung
des Verfahrens auf das Problem. Hierbei wird dem System ein Trainingsdatensatz übergeben,
welcher Beispiel-Inputs und die dazugehörigen Labels, also die gewünschten Outputs zu den
Beispielen, enthält. Dadurch soll das System Regeln, auch Model genannt, ermitteln. Mit die-
sem Model können später die Inputs auf die Outputs abgebildet werden. Weiterhin existieren
drei Unterkategorien des überwachten Lernens. Bei Teilüberwachtem Lernen arbeitet das Sys-
tem mit einer unvollständigen Label-Menge in der Trainingsphase [Mi08]. Eine weitere Unter-
art des überwachten Lernens ist das bestärkende Lernen. Hier wird dem System anstelle von
Outputs zu den Trainingsdaten entweder Belohnung oder Bestrafung für die Einordnung der
Inputs gegeben. Anschließend führt das System eine Anpassung durch, welche davon abhängig
ist, ob es belohnt oder bestraft wurde. Die letzte Form von überwachtem Lernen wird aktives
Lernen genannt. In dieser Unterkategorie kann das System mit einem gewissen Budget einen
Teil der Labels erfragen und muss für die Wahl der Labels den Erwartungswert maximieren.
Unüberwachtes Lernen
Anders als bei überwachtem Lernen bekommen unüberwachte Lernverfahren in der Trainings-
phase nur die Input-Beispiele ohne die zugehörigen Labels. Das bedeutet, dass das System al-
leine mit einer Feedback-Funktion arbeiten muss um eine unbekannte Struktur in den Daten zu
erkennen und diese in eine gewünschte Aufteilung von Untermengen sortiert.
Grundlagen 15
2.4.2 Prozess des Maschinenlernens
2.5 Aufzeichnungsdaten
Aufzeichnungsdaten (engl. Logs), sind automatisch generierte Protokoll-Dateien die von nahezu
jeder Anwendung, die mit einem Computersystem in Verbindung steht, erzeugt werden. Beim
sogenannten Logging protokollieren Anwendungen bzw. Systeme verschiedene Events. Diese
können beispielsweise Fehler, Nachrichten oder sonstige Geschehnisse sein, die für die Nach-
vollziehbarkeit und Analyse von Problemen aufgezeichnet werden.
2.5.1 Log-Formate
Es existieren verschiedene Log-Formate die für Logging-Aktivitäten verwendet werden können.
Im Folgenden wird eine Auflistung von häufig verwendeten Formaten und eine Beschreibung
deren Aufbau gegeben.
NCSA Common Log Format
Das NCSA Common Log Format ist ein standardisiertes Textformat, welches häufig von Webs-
ervern verwendet wird um eingehende Anfragen zu protokollieren. Abbildung 6 zeigt den
schematischen Aufbau dieses Formats.
Abbildung 6: Schematischer Aufbau des NCSA Common Log Format
• IP – Adresse des anfragenden Clients, z.B.: 152.241.141.023
• identd – Identität des Clients nach Identification Protocol, z.B.: "stfranks"
• uid – Benutzername der von HTTP-Authentifizierung festgestellt wird, z.B.: "frank"
• timestamp – Zeitstempel bei dem die Anfrage beim Server eingegangen ist, z.B.:
[10/Oct/2000:13:55:36 -0700]
• request – Anfrage des Clients bestehend aus HTTP-Methode, der angefragten Res-
source und dem Protokoll, z.B.: "GET /apache_pb.gif HTTP/1.0"
• status – Statuscode mit dem der Server geantwortet hat, z.B.: 200
• bytes – Größe des Objekts, welches vom Server an den Client gesendet, gemessen in
Bytes, z.B.: 2623
Combined Log Format
Das Combined Log Format ist beinahe identisch zum Common Log Format, mit der Erweite-
rung um zwei weitere Felder. Der Aufbau dieses Formats wird in Abbildung 7 dargestellt.
Abbildung 7: Schematischer Aufbau des Combined Log Format
• referer – URL der Webseite, die die Ressource beinhaltet, z.B.:
"http://www.example.com/start.html"
16 Grundlagen
• user-agent – Identifikations-Merkmale die vom Client an den Server übermittelt wer-
den, z.B.: "Mozilla/4.08 [en] (Win98; I ;Nav)"
2.5.2 Vorverarbeitung
2.5.3 Feature-Extraktion / -Selektion
2.6 Application Programming Interfaces
Application Programming Interfaces, heutzutage besser bekannt als APIs, sind Schnittstellen
zwischen Software-Komponenten die für die Bereitstellung des Zugriffs auf Dienste oder Da-
ten-Güter verantwortlich sind. Dabei beschreiben diese Schnittstellen die notwendige Kommu-
nikation, um mit dieser zu interagieren. APIs sind beliebt für die Orchestrierung von komplexen
Software-Prozessen, sodass die Abläufe im Hintergrund dem Nutzer verborgen bleiben. Die
Verwendung von APIs für den Zugriff auf Dienste bzw. Daten soll dabei so einfach wie mög-
lich gestaltet sein, sodass eine Nutzung ohne jegliche Kenntnis des Codes der Komponente
möglich ist. Bei der öffentlichen Bereitstellung von APIs werden sogenannte Service Level
Agreements, kurz SLAs, eingesetzt. Eine SLA legt die Randbedingungen für die Benutzung
einer API fest. Diese beinhalten beispielsweise Punkte wie die Verfügbarkeit der API und die
Preise für die Nutzung (evtl. pro Aufruf oder Datenvolumen-abhängig).
Die am weitesten verbreiteten und bekanntesten APIs heute sind die über das HTTP-Protokoll
kommunizierenden sogenannten Web-APIs. Oft auch einfach nur als REST-APIs bezeichnet, da
die Verwendung von SOAP-basierten Architekturen, zugunsten des steigenden Einsatzes von
REST-basierten APIs, abnimmt.
APIs existieren aber auch in anderen Anwendungsbereichen, wie zum Beispiel in Betriebssys-
temen oder innerhalb von Microservice-Anwendungen zwischen einzelnen Komponenten über
beispielsweise Remote Procedure Calls, also dem Aufruf eines entfernen Prozess. Eine Be-
schreibung der, auch in dieser Arbeit angewendeten, Microservice-Architektur wird in Ab-
schnitt 2.7 geliefert.
Ein modellhaftes Beispiel für die Anwendung einer API wird in Abbildung 8 dargestellt. Hier
interagiert der Nutzer mit einer lokalen Anwendung auf seinem Computer. Beim Aufruf einer
Funktion, beispielsweise dem Kauf eines Produkts, wird im Hintergrund die Ausführung dieser
Funktion in Teilschritte unterteilt. In diesem Beispiel könnte ein API-Aufruf die Überprüfung
der vom Benutzer eingegebenen Kreditkarte darstellen. Ein weiterer Aufruf speichert den getä-
tigten Kauf in der Datenbank des Verkäufers über eine API. So lässt sich ein komplexer Prozess
durch die Verwendung von APIs aufbauen.
Abbildung 8: Beispiel für den Einsatz von APIs
Grundlagen 17
2.6.1 OpenAPI Spezifikation & Swagger
OpenAPI definiert einen Standard für die Spezifizierung von RESTful Web APIs. Mit Hilfe
dieser Spezifizierung können die bereitgestellten Schnittstellen beschrieben werden. Dies dient
zur einfachen und verständlichen Darstellung der API für Entwickler und Personen, die mit
dieser API interagieren müssen, ohne dass diese den Code des Service bzw. der Anwendung
betrachten müssen. Die entstehende API-Spezifikation kann dabei entweder in YAML- oder
JSON-Format abgebildet werden.
Entstanden ist die OpenAPI-Spezifikation aus der vorherigen Swagger 2.0 Specification. Diese
wurde von der Software-Firma SmartBear als Teil der Entstehung der OpenAPI Initiative im
Jahr 2015 gespendet und anschließend in OpenAPI Specification, kurz OAS, umbenannt.
SmartBear stellt mit Swagger eine Sammlung von Werkzeugen zur einfachen Erstellung von
API-Spezifikationen nach dem OpenAPI-Standard zur Verfügung. Zu diesen Werkzeugen gehö-
ren unter anderem die Swagger UI zur kompakten und verständlichen Veranschaulichung von
API-Schnittstellen sowie dem Swagger Editor zur komfortablen Erzeugung von OpenAPI-
konformen Schnittstellen-Beschreibungen mit gleichzeitiger Visualisierung durch Swagger UI.
2.7 Microservice(-Architektur)
Das Gegenteil von monolithischen Systemen sind Microservices. Diese kleinen, eigenständigen
Dienste erbringen jeweils eine Funktionalität. Eine vollständige Anwendung erhält man durch
die Zusammenarbeit dieser unabhängigen Dienste.
Eigenschaften die einen guten Microservice auszeichnen sind lose Kopplung und hohe Kohäsi-
on. Lose Kopplung sorgt dafür, dass Änderungen an einzelnen Microservices keine Auswirkung
auf andere Dienste hat, die Ausrollung vereinfacht und die Anzahl der Aufrufe zwischen Diens-
ten verringert wird. Hohe Kohäsion vereint zusammenhängende Funktionalität in einen Dienst,
sodass eine Änderung dieser Funktionalität durch die Anpassung eines einzigen Dienstes mög-
lich ist.
Die Kommunikation zwischen Microservices lässt sich in zwei Arten einteilen. Mit Anfra-
ge/Antwort-Technologien können Dienste bereitgestellte Funktionalität über die angebotenen
Schnittstellen gegenseitig aufrufen und die Ergebnisse zurückgeben. Beispiele für beliebte
Technologien die dieses Konzept nutzen sind Remote Procedure Calls und REST.
2.8 Python
2.8.1 Flask & Flask-RESTful
Bei Flask handelt es sich um ein kompaktes Framework für Python, welches auf Technologien
wie Werkzeug und Jinja2 basiert. Dadurch lassen sich einfach minimalistische Web-
Anwendungen mit Hilfe des bereits integrierten Entwicklungsserver und Debugger erzeugen.
Durch Jinja2-Templates und das damit verbundene Routing-Konzept werden RESTful-
Schnittstellen nachgeahmt.
Mit der auf Flask basierenden Erweiterung Flask-RESTful ist es möglich, Swagger-definierte
API-Schnittstellen innerhalb des Programmcodes zu definieren. Ein Beispiel für eine solche
Schnittstelle wird in Abbildung ? dargestellt.
18 Grundlagen
Die minimalistische Natur von Flask zur Bereitstellung eines ausführbaren Produkts und die
Integration von Swagger-APIs durch die Erweiterung Flask-RESTful bilden in Kombination
eine exzellente Grundlage für kompakte Microservices.
2.8.2 Flasgger
Mit Flask und der darauf basierenden Erweiterung Flask-RESTful lassen sich in kurzer Zeit
minimalistische APIs und Microservices erzeugen. Zur Vereinfachung der Verwendung der
angebotenen Schnittstellen dieser Komponenten kann eine weitere Flask-Erweiterung namens
Flasgger genutzt werden. Flasgger ermöglicht die Verwendung von Swagger- bzw. OpenAPI-
Spezifikation, um anschließend eine Swagger UI-Ansicht bereitzustellen, mit der die Dokumen-
tation der verfügbaren Schnittstellen verständlich visualisiert und Möglichkeit zur Interaktion
angeboten werden.
Swagger- bzw. OpenAPI-Spezifikationen können dabei in verschiedenen Formen verwendet
werden. Es bestehen beispielsweise die Möglichkeiten eine YAML-Datei einzubinden und die
Spezifikation aus dieser Datei zu extrahieren, die Spezifikation aus einem JSON-Objekt zu ent-
nehmen oder die Schnittstellen direkt im Code selbst zu spezifizieren. Anschließend kann mit
der URL http://localhost:5000/apidocs die Swagger UI angezeigt und durch die Schnittstellen-
Spezifikationen navigiert werden. Ein Beispiel für eine solche Spezifikation und die zugehörige
Swagger UI-Ansicht veranschaulicht Abbildung ?.
2.9 Nameko
Das auf Python basierende Framework Nameko, benannt nach einer beliebten japanischen Pilz-
Art namens Pholiota nameko, die in kleinen Kolonien von einzelnen Pilzen wächst, dient der
Definition und Ausführung von leichtgewichtigen Microservices. Nameko gibt Entwicklern die
Möglichkeit sich auf die Anwendungslogik zu konzentrieren und fördert die Testbarkeit der
Services.
1. from nameko.rpc import rpc 2. class GreetingService: 3.
4. name = "greeting_service" 5.
6. @rpc 7. def hello(self, name): 8. return "Hello, {}!".format(name)
Code-Schnipsel 1: Definition eines minimalistischen Microservice mit Nameko in helloworld.py
In Code-Schnipsel 1 wird ein einfacher „Hello, World!“-Microservice dargestellt, der über eine
Remote Procedure Call-Schnittstelle mit einem Parameter angesprochen werden kann. Für die
Ausführung von Nameko Microservices wird eine aktive Instanz des RabbitMQ-Server benö-
tigt. RabbitMQ ist ein Open Source Message Broker und wird im folgenden Abschnitt beschrie-
ben. Um einen Nameko Microservice zu starten, führt man im vorliegenden Beispiel den Befehl
nameko run helloworld aus, woraufhin der Service seine Funktion aufnimmt und über die
konfigurierte Adresse und den zugehörigen Port verfügbar ist. Standardmäßig werden die Ser-
vices zu Entwicklungszwecken lokal ausgeführt (localhost) und lauschen auf Port 8000 für ein-
gehende Anfragen. Die Kommunikation über Remote Procedure Calls
Grundlagen 19
Nameko stellt nicht nur Schnittstellen über Remote Procedure Calls bereit, sondern bietet noch
eine Reihe von anderen Kommunikations-Technologien an. Zu diesen Technologien gehören
die ereignisbasierte Kommunikation, auch bekannt als Publish/Subscriber-Muster, die http-
basierte Kommunikation mittels den bekannten Anfrage-Methoden (GET, POST, PUT,
DELETE) sowie die Definition von zeitbasierten Eintrittspunkten in die zugehörige Methode,
bei der diese nach einem festgelegten Intervall von Sekunden periodisch auf allen Instanzen des
Service ausgeführt wird.
1. class EventService: 2. 3. name = "event_service" 4. 5. dispatch = EventDispatcher() 6. 7. @rpc 8. def dispatching_method(self, payload): 9. self.dispatch("test_event", payload) 10. 11. class ListeningService: 12. 13. name = "listener_service" 14. 15. @event_handler("event_service", "test_event") 16. def handle_event(self, payload): 17. print("Received event with message:", payload)
Code-Schnipsel 2: Definition zweier Services, die das Publish/Subscribe-Muster darstellen
Code-Schnipsel 2 zeigt ein Beispiel für die Umsetzung des ereignisgesteuerten Pub-
lish/Subscribe-Musters. Hier abonniert der listener_service die Events der Kategorie
test_event. Sendet der event_service nun ein solches Event, dann wird die handle_event-
Funktion des listener_service ausgelöst.
1. class TimerService: 2.
3. name ="timer_service" 4.
5. @timer(interval=1) 6. def ping(self): 7. print("pong")
Code-Schnipsel 3: Definition eines zeitbasierten Service
Ein Exemplar eines zeitbasierten Service zeigt Code-Schnipsel 3. Dieser Service führt die ping-
Methode in einem sekündlichen Intervall periodisch aus. Schlussendlich wird in ein http-
basierter Microservice abgebildet. Dieser Service stellt Endpunkte für eine GET- und eine
POST-Operation auf der URL http://localhost:8000/ zur Verfügung.
1. class HttpService: 2. 3. name = "http_service" 4. 5. @http('GET', '/get/<int:value>') 6. def get_method(self, request, value): 7. return json.dumps({'value': value}) 8. 9. @http('POST', '/post') 10. def do_post(self, request): 11. return u"received: {}".format(request.get_data(as_text=True))
Code-Schnipsel 4: Definition eines http-basierten Service
20 Grundlagen
Diese Art der Kommunikation zwischen Services findet auch Anwendung in dieser Arbeit und
wird bei der Umsetzung der Komponenten für den Betriebseinsatz in Kapitel 35 genauer be-
schrieben.
2.10 RabbitMQ
RabbitMQ ist ein Open Source Message Broker. Dieser ist, wie die Bezeichnung andeutet, ein
Vermittler von Nachrichten. Beispielsweise verteilen Nameko Microservices ihre Nachrichten
über einen RabbitMQ-Server untereinander. Dabei setzt RabbitMQ hauptsächlich das Advanced
Message Queuing Protocol, kurz AMQP, ein. Es können jedoch noch weitere Protokolle, wie
das Streaming Text Oriented Messaging Protocol (STOMP) oder das Message Queuing Tele-
metry Transport-Protokoll (MQTT), über Plugins eingesetzt werden.
Abbildung 9: Schematischer Ablauf des Message Queuing
Für die Umsetzung der Nachrichten-Vermittlung bei RabbitMQ mit AMQP kommt das Konzept
der Message Queues zum Einsatz. Ein Beispiel für den Ablauf dieses Konzeptes wird in Abbil-
dung 9 veranschaulicht. Hierbei existieren Producer und Consumer. Producer senden Nachrich-
ten an die zuvor festgelegt Message Queue. Consumer, die Nachrichten einer spezifischen
Queue erhalten möchten, müssen eine Callback-Funktion für diese Queue beim Server registrie-
ren. Wird nun eine neue Nachricht in die Queue geschrieben, so wird diese an die Callback-
Funktionen der Consumer gesendet.
Für die Kommunikation mit RabbitMQ-Servern existiert für nahezu jede gängige Programmier-
sprache ein RabbitMQ-Client.
2.11 Elasticsearch
Elasticsearch ist die zentrale Anwendung der Produktpalette der Firma Elastic. Elastic selbst
betitelt Elasticsearch als das Herz des Elastic-Anwendungsstapels, weswegen es auch als zentra-
ler Datenspeicher für jegliche Art von Daten dient. Zusätzlich zur Speicherung der Daten bietet
Elasticsearch eine auf REST basierende Such- und Analyse-Engine zur Bewältigung einer stei-
genden Anzahl von Anwendungsfällen. Mit der X-Pack-Erweiterung lassen sich eine Vielzahl
von zusätzlichen Features in Elasticsearch einfügen. Zu diesen Features gehören beispielsweise
Alerts, Reports, Graphen oder die Umstellung auf Anfragen mit SQL-Syntax.
Wie für RabbitMQ existiert auch für die Interaktion mit Elasticsearch, für fast jede moderne
Programmiersprache, eine Bibliothek zur Einbindung der Elasticsearch-Funktionalität. Zusätz-
lich kann sie auch über REST-Schnittstellen genutzt werden.
2.12 Wahrscheinlichkeitsdichte-Verteilung
Grundlagen 21
22 Grundlagen
Stand der Technik / Forschung 23
3 Stand der Technik / Forschung
Dieses Kapitel bietet eine Übersicht über den Architekturaufbau beim Kooperationspartner iC
Consult sowie die allgemeine Vorgehensweise in den Schwerpunktthemen dieses Projekts.
Hierzu zählen unter anderem die Vorverarbeitung der Aufzeichnungsdaten und die Anwendung
von maschinellen Lernverfahren zur Identifikation von Anomalien im Verhalten von Nutzern.
Zunächst werden die Betriebsumgebung und die damit verbundenen Technologien des Koope-
rationspartners und ein erster abstrakter Ansatz zur Integration der entwickelten Lösung be-
schrieben. Anschließend werden jeweils die Umsetzung sowie die erzielten Ergebnisse betrach-
teter Forschungsprojekte in diesen Themenbereichen erläutert und in einer analytischen Diskus-
sion die Anwendbarkeit der zuvor beschriebenen Verfahren auf den Kontext dieses Projekts
überprüft.
3.1 Architektur des Kooperationspartners und Integrationsan-satz der Anomalie-Erkennung
Wie bereits in der Einleitung erwähnt handelt es sich bei der Firma iC-Consult GmbH um einen
Dienstleister für Identity- and Accessmanagement-Lösungen, welcher zusätzlich auch API-
Lösungen anbietet. Der generelle Aufbau der IAM-Architektur zwischen Nutzern, Web-
Anwendungen und iC-Consult als Mittelsmann dazwischen wurde bereits in der Einleitung grob
umschrieben. An dieser Stelle soll zusätzlich die interne Struktur von iC-Consult näher betrach-
tet und ein eventueller Ansatzpunkt für die Integration der in diesem Projekt entstehenden Lö-
sung identifiziert und beschrieben werden.
3.1.1 Aufbau der Technologie-Umgebung
Im Folgenden wird zunächst der Aufbau und die verwendeten Technologien der CIAM-
Komponente der Firma iC-Consult näher beschrieben. Dieser Aufbau wird in Abbildung ?
schematisch dargestellt. Die CIAM-Komponente setzt sich zunächst einmal aus dem IAM-
Portal und dem dahinter befindlichen Webserver zusammen. Das IAM-Portal ist dafür zustän-
dig, den Firmenkunden von iC-Consult ein zentrales Anmeldungssystem für ihre Dienste zur
Verfügung zu stellen. Hier können sich die Benutzer mittels einer Web-Oberfläche in ihrem
Browser mit ihren Zugangsdaten anmelden und anschließend auf die ihnen verfügbaren Dienste
zugreifen.
Abbildung 10: Beispiel für zufällige Aufzeichnungsdaten mit der verwendeten Struktur
Um dies zu realisieren muss im Hintergrund eine Überprüfung dieser Zugangsdaten und eine
Abfrage der vereinbarten Zugangsrechte vorgenommen werden. Weiterhin findet eine Auf-
zeichnung der Zugriffe von allen Nutzern durch den Webserver, der diese Komponente betreibt,
statt. Diese Zugriffe werden in Form von Logs für Analyse- und Kontrollzwecke erhoben. Die
24 Stand der Technik / Forschung
derzeitige Struktur dieser Log-Dateien wird in Abbildung 10 verdeutlicht und setzt sich wie
folgt zusammen:
• Zeitstempel an dem der Zugriff erfolgt
• Anfrage-ID die einem Zugriff einen eindeutigen Identifier zuordnet
• IP-Adresse von der der Zugriff durchgeführt wurde
• Status-Code der Antwort (http-Statuscode, z.B.: 200)
• Bisher nicht verwendeter interner Status-Code
• User-ID, die einem Nutzer einen eindeutigen zufälligen Identifier zuordnet
• Einer Aktion die im Zuge des Zugriffs erfolgt (z.B.: Login, Logout, Passwort-
Änderung)
• JSON-Objekt, welches Freitext zur Aktion enthält (z.B.: Ob Aktion erfolgreich
war)
Weiterhin lassen sich in diesen Aufzeichnungsdaten verschiedene Aktionen, die ein Nutzer
durchführen kann, unterscheiden. Wie in Abbildung 10 ersichtlich, existieren Aktionen wie
„LOGIN“, welche offensichtlich den Login eines Nutzers am System darstellt, sowie „PW-
CHANGE“, die eine Passwort-Änderung eines Benutzers signalisiert. Neben diesen beiden Ak-
tionen existieren noch Weitere, die ebenfalls interessant für das Verhalten eines Nutzers sind.
Diese Aktionen werden in Tabelle 1 mit ihrer jeweiligen Bedeutung aufgelistet.
Der Aufbau dieser Log-Dateien und die enthaltenen Aktionen nehmen eine wichtige Rolle bei
der Generator- und Vorverarbeitungskomponente ein. Diese Komponenten und die Verwendung
der Log-Struktur werden in Kapitel 5 beschrieben.
Anhand dieser Log-Dateien soll versucht werden, Anomalien im Verhalten von Nutzern der
CIAM-Komponente zu finden und als Alarm, etwa per E-Mail oder per Push-Nachricht, zu
melden. Nachdem die im Rahmen dieser Arbeit entwickelten Verfahren zur Anomalie-
Erkennung auf selbstgenerierten Beispiel-Aufzeichnungsdaten angewendet wurden, sollen diese
bei Beispieldaten von iC Consult und schlussendlich in der realen Betriebsumgebung Anwen-
dung finden. Für die Anwendung in der Betriebsumgebung wird nachfolgend ein grober Ansatz
für die Integration beschrieben.
Aktion Beschreibung
LOGIN Signalisiert einen Login eines Nutzers am System
LOGOUT Signalisiert einen Logout eines Nutzers vom System
PW-CHANGE Signalisiert eine Passwort-Änderung eines Nutzers im System
EMAIL-CHANGE Signalisiert eine Änderung der E-Mail eines Nutzers im System
REGISTRATION Signalisiert eine Registrierung eines neuen Nutzers am System
PROFILE Signalisiert den Aufruf eines Profils durch einen Nutzer
MOBILE Signalisiert eine Verwendung eines Mobilgeräts eines Nutzers
Tabelle 1: Auflistung einer Teilmenge der in den Aufzeichnungsdaten enthaltenen Aktionen
Stand der Technik / Forschung 25
3.1.2 Integrationsansatz für die Anomalie-Erkennung
Für die Inbetriebnahme der zu entwickelnden Lösung in der realen Betriebsumgebung müssen
eventuell Anpassungen bzw. Erweiterungen vorgenommen und eventuell sogar neue Schnitt-
stellen geschaffen werden. Ein Vorschlag für eine theoretische Integration der Anomalie-
Erkennungskomponente geht aus dem Aufbau des im Rahmen der Projektarbeit entstandenen
Demonstrators aus Abbildung ? hervor. Der dadurch entstehende Architekturaufbau wird in
Abbildung 11 visualisiert und im Folgenden erläutert. Die dabei beschriebenen Komponenten
agieren jeweils als selbstständige Microservices. Dies ermöglicht den einfachen Austausch von
existierenden Services sowie die Ergänzung von neuen Services. Somit lassen sich neue Ano-
malie-Erkennungskomponenten einfach hinzufügen und testen.
Um nicht nur ein initiales Wahrscheinlichkeits-Modell für die Erkennung von Anomalien eines
jeden Nutzers zu haben und dieses permanent zu verwenden, ist eine Art von Modell-
Verwaltung notwendig. Diese Verwaltung berechnet das Modell eines Nutzers in einem gewis-
sen Rahmen (vergangene Zeit oder getätigte Aktionen) neu und vergisst dadurch veraltetes Ver-
halten und bezieht neues Verhalten in das Modell mit ein. Zusätzlich wird hierfür eine Daten-
bank benötigt, in der das aktuelle Modell jedes Nutzers abgelegt werden kann. Für die typischen
CRUD-Funktionen (Create, Read, Update, Delete) zur Interaktionen mit den Modellen benötigt
die Modell-Verwaltung eine Schnittstelle, die sie den anderen Komponenten bereitstellt.
Dadurch können die anderen Komponenten neue Modelle abspeichern oder Modelle für die
Anomalie-Erkennung anfordern.
Als Hauptbestandteil des geplanten Vorgehens muss auch die Anomalie-Erkennung in die Be-
triebsumgebung eingebracht werden. Hierfür soll die Anomalie-Erkennungskomponente eine
Schnittstelle bereitstellen, mit der die Analysen durchgeführt werden können. Benötigte Daten
dafür sind beispielsweise das Modell des Nutzers sowie die zu überprüfende Verhaltenshistorie.
Zusätzlich sollen die erkannten potenziellen Anomalien in einer Datenbank abgelegt und für
spätere Inspektion durch einen System-Admin, in einem Web-Interface zusammengefasst wer-
den.
Für die Darstellung der Anomalien und die Benachrichtigung von relevanten Personen beim
Auftreten einer Anomalie ist jeweils eine eigene Komponente notwendig. Für die Darstellung
ist ein minimalistisches Web-Interface, welches über eine zentrale Komponente auf die Daten-
bank mit den Anomalien zugreift, ausreichend. Für die Benachrichtigung können E-Mails oder
Push-Nachrichten verwendet werden. Für die Verwendung dieser Funktionalität muss diese
Komponente eine Schnittstelle bereitstellen, sodass bei einer potenziellen Anomalie eine Mel-
dung gesendet werden kann.
Für das Zusammenspiel all dieser Teil-Komponenten ist eine Controller-Komponente, die den
Ablauf koordiniert, notwendig. Dieser Controller veranlasst beispielsweise Updates der Nut-
zermodelle über die Schnittstelle der Modell-Verwaltung, startet eine Anomalie-Analyse durch
Ansprechen der Schnittstelle der Anomalie-Erkennung, gibt eine Benachrichtigung an eingetra-
gene Personen über die Schnittstelle des Benachrichtigungsservice heraus oder stellt dem Web-
Interface die in der Datenbank abgelegten Anomalien zur Verfügung.
26 Stand der Technik / Forschung
Abbildung 11: Schematischer Entwurf des Integrationsansatzes
Zur Verdeutlichung des geplanten Einsatzszenarios wird im Folgenden ein exemplarischer
Durchlauf des theoretischen Ablaufs anhand von Abbildung 12 erläutert. Hierbei unterscheidet
man zwischen zwei Fällen. Im ersten Fall findet der Einsatz mittels einer initialen Inbetrieb-
nahme dieses modellhaften Intrusion Detection System statt. Der zweite Fall beschreibt den
Normalbetrieb des Modell-IDS.
Initiale Inbetriebnahme der Komponente
Bei der initialen Inbetriebnahme der entwickelten Lösung müssen zunächst die Aufzeichnungs-
daten eines bestimmten Zeitrahmens erfragt werden. Anschließend findet eine Identifizierung
der vorhandenen Nutzer in diesen Logs statt. Existieren genügend Verhaltensdaten für die je-
weiligen Benutzer, so wird ein initiales Modell zur Klassifizierung einer Verhaltenshistorie
berechnet und in einer Datenbank ablegt. Anschließend kann mit dem Normalbetrieb fortgefah-
ren werden.
Abbildung 12: Theoretischer Ablauf der entwickelten Lösung
Stand der Technik / Forschung 27
Normalbetrieb der Komponente
Im Normalbetrieb arbeitet die Komponente in einer zyklischen Vorgehensweise. Hierbei prüft
die potenzielle Controller-Komponente im ersten Schritt periodisch, ob neue Log-Einträge auf
dem CIAM-Webserver vorhanden sind. Im nächsten Schritt sortiert der Controller diese Auf-
zeichnungsdaten nach Nutzern und prüft, ob die vorhandenen Einträge für eine Anomalie-
Erkennung ausreichen. Für die Benutzer deren Aktivität in diesem Log enthalten ist und für die
genügend Log-Einträge existieren muss zunächst eine Überprüfung stattfinden, ob bereits ein
Modell zur Klassifizierung des Verhaltens dieses Nutzers existiert. Hierzu sendet der Controller
eine Anfrage and einen Endpunkt der für einen User-Identifier zurückliefert, ob ein Modell un-
ter diesem Nutzer bereits existiert. Im Fall, dass kein Modell vorhanden sein sollte wird zu-
nächst ein initiales Modell für diesen Nutzer berechnet und in der Datenbank abgelegt. Bei ei-
nem bereits existenten Modell erfragt der Controller dieses für den nächsten Schritt. Hier findet
nun die Anomalie-Erkennung für jeden identifizierten Nutzer statt. Dafür ruft der Controller die
Anomalie-Erkennungskomponente mit einem Nutzer-Modell und der Verhaltenshistorie die
untersucht werden soll auf. Sobald die Anomalie-Erkennung beendet ist, kann die Anomalie-
Erkennung durch den Controller bei einer potenziellen Anomalie eine Benachrichtigung ver-
schicken lassen und/oder einen Eintrag im Web-Interface vornehmen.
Die Realisierung der Lösung in einer Testumgebung, die weitestgehend der Betriebsumgebung
von iC Consult ähneln soll, wird detailliert in Kapitel 6 beschrieben. Zusätzlich findet dort auch
eine Beschreibung der Voraussetzungen und verwendeten Technologien statt.
3.1.3 Zukünftige Entwicklung
Transfer von Logs in ein Elasticsearch-Cluster
3.2 Betrachtete Verfahren
In diesem Abschnitt sollen die im Rahmen dieser Arbeit untersuchten maschinellen Lernverfah-
ren zur Anomalie-Erkennung grob vorgestellt werden. Ergänzend dazu wird eine mögliche An-
wendung auf den vorliegenden Anwendungsfall erläutert. In einer anschließenden Diskussion
wird das gewählte Verfahren herausgestellt.
Durch die Unbekanntheit der Anomalien, die in den Daten erwartet werden und das Vorhanden-
sein von nicht-markierten Log-Daten wurde der Bereich der zu verwendeten Verfahren auf un-
überwachte Maschinenlernverfahren beschränkt.
3.2.1 Bag of Words-Ansatz
Beim Bag of Words-Ansatz handelt es sich um ein beliebtes Verfahren in der Verarbeitung von
natürlicher Sprache. Er wird häufig zum Trainieren eines Klassifizierers, beispielsweise zur
Unterscheidung zwischen legitimen und spambehafteten E-Mails, eingesetzt.
Funktionsweise
Zentraler Bestandteil des Ansatzes ist, wie der Name schon sagt, der sogenannte Bag of Words.
Ein Bag of Words, kurz BoW, ist bei der Anwendung auf natürliche Sprache eine Histogramm-
ähnliche Repräsentation eines Textes.
Beispiel: „John likes to watch movies. Mary likes movies too.”
28 Stand der Technik / Forschung
Der zum Beispiel gehörende BoW sieht wie folgt aus:
[1, 2, 1, 1, 2, 1, 1]
Hierbei entspricht der Wert des ersten Index, also „1“, der Häufigkeit des Wortes „John“, der
Wert des zweiten Index „2“ der des Wortes „likes“ und so weiter. Im Falle von mehreren Zei-
chenketten kann es sein, dass ein Wort nicht in jeder Zeichenkette enthalten ist, wodurch ein
Index auch den Wert 0 haben kann. Die Reihenfolge der Indexe zu den Wörtern entsteht durch
die Reihenfolge des Auftretens der einzelnen Wörter in den Zeichenketten.
Wie bereits erwähnt wird dieser Ansatz häufig als Grundlage für die Erkennung von spambehaf-
teten E-Mails eingesetzt. Spam-Mails sind hierbei nichts anderes als eine Anomalie. Eine Ab-
weichung von den E-Mails, die ein Nutzer normalerweise erwartet. In Kombination mit bei-
spielsweise einem Bayesian-Klassifizierer kann anhand zweier Bags of Words, einer für Wörter,
die in legitimen E-Mails vorhanden sind und einem Bag für Wörter, die in Spam-Mails vor-
kommen, eine Wahrscheinlichkeit berechnet werden, mit der ein Text einer E-Mail entweder in
den Spam-Bag oder in den Bag der legitimen Mails eingeordnet wird.
Eine ähnliche Vorgehensweise beschreiben [KF+05] in ihrer Forschungsarbeit zu Anomalie-
Erkennung mittels eines sogenannten Bag of System Calls und lernenden Klassifizierern. Hier-
bei findet die Erzeugung der Bags durch die Aufzeichnung der Häufigkeit von verschiedenen
Systemaufrufen statt. Anschließend werden mittels k-Means Clustering mit einem k-Wert von
zwei, also ein Cluster für normale Datenpunkte und einem Cluster für Anomalien, die Bags
versucht in normal und anomal zu unterscheiden.
Applikation
Eine weitere ähnliche Vorgehensweise beschreibt [?] in seinem Artikel zu unüberwachter Ano-
malie-Erkennung mittels des Bag of Words-Modells. Dieser Ansatz sieht je Bag eine Berech-
nung der durchschnittlichen Distanz zu jedem anderen verfügbaren Bag vor. Anschließend fin-
det eine Schätzung einer Wahrscheinlichkeitsverteilung durch einen bestimmten Algorithmus
(hier: EM-Algorithmus) statt. Mit dieser Verteilung und einem festzulegenden Sensitivitäts-
Faktor wird ein Threshold berechnet, mit dem später festgestellt werden kann, ob es sich bei
einem Bag um eine Anomalie oder Normalität handelt. Um einen Wert zu erhalten, der mit dem
Threshold verglichen werden kann, berechnet man für einen neuen Bag die durchschnittliche
Distanz und verwendet diese als Eingabe für die Funktion der Wahrscheinlichkeitsverteilung.
Der resultierende Wert dient zum Vergleich mit dem Threshold. Für die Anwendung auf den
vorliegenden Anwendungsfall verwendet man anstatt Bag of Words dann Bag of Actions, wel-
che das Histogramm von Aktionen eines Nutzers abbilden. Diese Bag of Actions können an-
schließend mit der weiteren Vorgehensweise genutzt werden.
3.2.2 NNIDS
3.2.3 Anomalie Erkennung von Nutzerverhalten zur Datenbank-sicherheitsüberprüfung basierend auf OCSVM
Prozessmodell für die Anomalie-Erkennung 29
4 Prozessmodell für die Anomalie-Erkennung
In diesem Kapitel soll nun der Gesamtprozess der für die Anomalie-Erkennung durchlaufen
wird genauer betrachtet werden. Aus diesem Prozessmodell lassen sich zusammen mit dem
C&M-Entwicklungsprozess die notwendigen Services deren Schnittstellen und die dabei entste-
henden Artefakte bei der Umsetzung für den Produktiv-Einsatz identifizieren. Bevor die Be-
schreibung und Veranschaulichung der einzelnen Teile, die den Gesamtprozesses formen, statt-
finden kann, muss zunächst der angestrebte Prozessablauf näher beleuchtet werden. Nachdem
der gewünschte Ablauf bekannt ist, können die Vision und die Geschäftsziele, zur Verdeutli-
chung des erwarteten Mehrwerts, erläutert werden. Anschließend folgt eine Beschreibung der
Fähigkeiten und Features, die das entstehende Intrusion Detection System zur Realisierung der
Vision und der Geschäftsziele benötigt. Anschließend können die einzelnen Komponenten, die
eigenständige Microservices darstellen, identifiziert und eingegrenzt werden. Für die Kommu-
nikation zwischen den einzelnen Komponenten werden Schnittstellen benötigt. Diese sollen im
Anschluss an die Identifizierung der notwendigen Services beschrieben werden. Bei der Kom-
munikation über diese Schnittstellen ist eine Übertragung von Daten in Form von Artefakten
unvermeidbar. Diese Artefakte lassen sich auch grob aus den Features herauslesen und werden
nach den Schnittstellen erläutert. Im letzten Abschnitt dieses Kapitels wird das Big Picture des
Gesamtprozesses anhand einer Context Map betrachtet.
4.1 Angestrebter Prozess
4.2 Einsatzumfelds und Zielsetzung
4.3 Fähigkeiten und Features
4.4 Identifizierung der notwendigen Komponenten
4.5 Schnittstellen-Kommunikation
4.6 Definition der Artefakte
4.7 Orchestrierung der Komponenten
30 Prozessmodell für die Anomalie-Erkennung
Abbildung 13: Visualisierung des Prozessmodells für die Anomalie-Erkennung
Komponenten des Erkennungsprozesses 31
5 Komponenten des Erkennungsprozesses
Im vorherigen Kapitel wurde bereits das Zusammenspiel der einzelnen Komponenten darge-
stellt. Hierbei wurden die Komponenten als Blackboxes betrachtet. In diesem Kapitel findet nun
die Erläuterung des Aufbaus und der Funktionsweise der einzelnen Komponenten, die für die
Realisierung der Erkennung von Anomalien in Aufzeichnungsdaten benötigt werden, statt. Zu
diesen Komponenten gehören der Verhaltensmodell-Generator, die Vorverarbeitung als Teil des
Lernverfahrensprozesses, die maschinellen Lernverfahren zur Anomalie-Erkennung sowie die
Visualisierung von Steuerung und Ergebnissen in Form einer Demonstrator-Anwendung.
5.1 Erzeugung von Nutzermodellen
Die Generator-Komponente zur Erzeugung von Nutzermodellen ist lediglich innerhalb dieses
Projekts ein Teil des Prozesses. Bei einem potenziellen Produktiv-Einsatz der Ergebnisse dieser
Arbeit ist ein Austausch des Generators durch eine Anbindung an eine potenzielle Log-
Datenbank notwendig. Der Generator dient der Erzeugung von modellhaftem Verhalten von
fiktiven Nutzern. Mit diesen Modellen soll eine Untersuchung der Komponenten der Vorverar-
beitung und der Anomalie-Erkennung auf korrekte Funktionsweise stattfinden. Vor der Be-
schreibung des Aufbaus der Modelle und des Generators muss zunächst die Notwendigkeit für
diese Komponente erläutert werden.
5.1.1 Notwendigkeit
Die Erzeugung dieses modellhaften Verhalten ist notwendig, da für die Durchführung der Ano-
malie-Erkennung zwar Aufzeichnungsdaten der Firma iC Consult zur Verwendung vorhanden
sind, jedoch ist nicht bekannt, ob in diesen Daten bereits Anomalien vorhanden sind oder nicht.
Zusätzlich enthalten diese Aufzeichnungsdaten personenbezogene Informationen der Kunden
des Unternehmens. Diese Informationen dürfen aus Datenschutzgründen die Hardware von iC-
Consult nicht ohne vorherige Anonymisierung verlassen. Weiterhin ist es für Testzwecke in
dieser Arbeit notwendig, ausreichend Daten für einzelne Nutzer zu haben. Für den späteren
Testlauf der Gesamt-Komponente sind Daten über einen Zeitraum von mehreren Wochen wün-
schenswert. Um jedoch dem Konzept der Datensparsamkeit zu folgen, wurden daher so wenig
wie möglich Daten des Unternehmens angefordert und primär selbstgenerierte Aufzeichnungs-
daten, bis die entwickelte Architektur einsatzbereit ist, verwendet. Der Generator ermöglicht
zudem die Einbettung von eigens definierten Anomalien. Da nicht genau bekannt ist, wie Ano-
malien in diesem Anwendungsumfeld aussehen, ist es zu Testzwecken notwendig, Verhalten zu
erzeugen, dass als abnormal angesehen werden könnte. Diese selbstdefinierten Anomalien kön-
nen mit dem Generator in ein Verhaltensmodell eingefügt werden, um diese anschließend in
einem Testdurchlauf mit den Anomalie-Erkennungskomponenten erkennen zu lassen. Eine Be-
schreibung dieser Anomalie-Prototypen befindet sich in Abschnitt 5.1.3.
5.1.2 Aufbau der Verhaltensmodelle
Beschreiben lassen sich die durch den Generator erzeugten Benutzermodelle mit einer kleinen
Anzahl von ausgewählten Parametern, die das Verhaltensmodell bilden und den daraus gene-
rierten Log-Dateien. Die Parameter gibt der Nutzer zu Beginn der Verwendung des Generators
ein. Die exakte Verwendung der im Folgenden erläuterten Parameter wird im nächsten Ab-
32 Komponenten des Erkennungsprozesses
schnitt ausführlich dargestellt. Ein Beispiel für ein Verhaltensmodell eines fiktiven Nutzers wird
in Tabelle 2 dargestellt
Parameter Beispielwert
Anzahl Logs / Anzahl Tage 3
Aktionen 20
Verteilung der Aktionen [0.7, 0.2, 0.1]
Anomalie-Typen [1, 0, 1]
Tabelle 2: Beispielwerte für ein Verhaltensmodell
Der erste Parameter des Verhaltensmodells, der für die Generierung von Logs eines Benutzer-
modells benötigt wird, ist die Anzahl von Log-Dateien, in denen Aktionen des fiktiven Nutzers
vorhanden seien sollen. Da Logs üblicherweise für einen spezifischen Tag erstellt werden, ist
dieser Parameter gleichbedeutend mit der Anzahl von Tagen, an denen der fiktive Nutzer aktiv
war.
Einer der wesentlichen Parameter des Nutzerverhaltens ist die Anzahl der Aktionen, also der
Log-Einträge, die der potenzielle Benutzer pro Tag bzw. pro Log-Datei durchführt. Nutzer von
Web-Anwendungen und dem zugehörigen Login-Portal führen nicht jeden Tag die exakt selbe
Anzahl von Aktionen durch. Um dies in die Modelle einzubringen und dadurch eine gewisse
Dynamik zu erzeugen, besteht die Möglichkeit durch Konfigurations-Variablen des Generators
ein Intervall für eine zufällige Abweichung bei der Anzahl der durchgeführten Aktionen pro
Tag zu definieren.
Ein weiterer Parameter bzw. Array von Parametern für die Beschreibung des Verhaltens eines
Benutzers ist die Verteilung der durchgeführten Aktionen. (+Ausschnitt der verfügbaren Aktio-
nen) Diese Aktionen können beispielsweise Logins, Logouts, Passwort-Änderungen oder eine
Änderung der E-Mail sein. Ein Teil der verfügbaren Aktionen wurde bereits in Tabelle 1 aufge-
listet. Um diese im zu erzeugenden Verhalten abbilden zu können, muss angegeben werden, wie
hoch der Anteil der am Tag durchgeführten Aktionen von welcher Art sind. Angenommen es
existieren die Aktionstypen Login, Passwort-Änderung sowie E-Mail-Änderung und der fiktive
Nutzer tätigt zwanzig Aktionen an einem Tag, dann hätte man mit einem Array von [0.7, 0.2,
0.1] vierzehn Logins, vier Passwort-Änderungen und zwei E-Mail-Änderungen. Die Summe der
Verteilungs-Werte muss offensichtlich eins sein.
Der nächste Parameter ist zuständig für die Einbettung von Anomalien im Verhalten des fikti-
ven Nutzers und ist daher optional, sodass eine Erzeugung von Anomalie-freien Benutzermo-
dellen ebenfalls möglich ist. Dieser letzte Parameter gibt durch ein Array an, von welcher Art
und mit welcher Häufigkeit Anomalien in das Verhaltensmodell des fiktiven Nutzers eingefügt
werden sollen. Ein Array mit den Werten [1, 0, 1] bedeutet, dass eine Anomalie von Typ 1 und
eine Anomalie von Typ 3, in Summe zwei Anomalien, in das Verhalten des fiktiven Benutzers
eingefügt werden.
Anhand dieser Parameter lässt sich ein grundlegendes Verhalten definieren, welches der Gene-
rator im nächsten Schritt zur Erzeugung der Aufzeichnungsdaten des Benutzermodells verwen-
det.
Komponenten des Erkennungsprozesses 33
5.1.3 Anomalien
Bruteforce-Angriff
Angreifer mit Zugriff auf E-Mail – Passwort-Rücksetzung, Passwort-Änderung und E-
Mail-Änderung
Viele Passwort-Änderungen an einem Tag
5.1.4 Aufbau und Funktionsweise des Generators
Im Folgenden wird zunächst der Aufbau des Generators beschrieben, bevor die Funktionsweise
an einem beispielhaften Ablauf erläutert wird.
Aufbau
Der Generator verwendet eine Model View Controller-Architektur (kurz: MVC) und soll für
den Einsatz in der Demonstrator-Anwendung sowie in der praktischen Testumgebung in einen
Microservice ausgelagert werden. Durch die Verwendung einer MVC-Architektur und deren
Ähnlichkeit zu einer Microservice-basierten Anwendung ist es möglich, die Funktionalität des
Generators einfach in einen Microservice umzuwandeln. Diese Umwandlung wird in Abschnitt
5.1.5 beschrieben. Eine vereinfachte Visualisierung des Aufbaus des Generators ist in Abbil-
dung ? zu sehen.
Durch die MVC-Architektur befinden sich die Interaktionsansicht für den Anwender, die Steue-
rung der Abläufe und die Daten bzw. Prozesse dieser Komponente in getrennten Ebenen. Die
Koordination erfolgt hierbei durch die Controller-Schicht, welche Eingaben des Anwenders
durch die View-Schicht interpretiert und damit die Verarbeitung der Daten in der Model-
Schicht in Gang setzt.
In der Controller-Schicht existiert der sogenannte maincontroller, der den Ablauf des Genera-
tors steuert. Beispielsweise lässt er die Generatoren der Model-Schicht Daten erzeugen oder
delegiert Eingabe-Abfragen an die Kommandozeilen-Ansicht. Die Model-Schicht besteht aus
zwei Generatoren zur Erzeugung von fiktiven Nutzern und deren Aufzeichnungsdaten. Der Ge-
nerator mit der Bezeichnung usergenerator ist für die Konstruktion der Nutzer und deren Ver-
haltensmodell zuständig. Der zweite Generator namens datagenerator verwendet die vom user-
generator erzeugten Objekte für die Generierung der Logs. Weiterhin existieren zwei Arten von
Datenobjekten namens Behavior und Action zur Beschreibung eines Nutzers. Hierbei beinhalten
Behavior-Objekte die im vorherigen Abschnitt beschriebenen Parameter des Verhaltensmodells
und die Action-Objekte definieren die bereits erläuterten Aktionen die ein Nutzer durchführen
kann.
Funktionsweise
Da der Generator zunächst Einsatz beim Testen des verwendeten Maschinenlernverfahren fin-
det, wird der Ablauf anhand des Kommandozeilen-Interface, welches die Parameter per Eingabe
vom Anwender erfragt und einige Informationen zu den erzeugten Logs ausgibt, beschrieben.
Nach dem Start der Komponente veranlasst der Controller die Eingabe der benötigten Parameter
durch den Nutzer. Hierzu fragt die Kommandozeilen-Ansicht die Parameter einzeln ab. In die-
sem Beispiel wird angenommen, dass der Anwender folgende Daten bereitgestellt hat:
• Anzahl Tage von Aufzeichnungsdaten: 3
• Einträge pro Tag: 20
34 Komponenten des Erkennungsprozesses
• Verteilung der Operationen: [0.7, 0.2, 0.1]
• Anomalien: [1, 0, 0]
Anschließend übergibt die Kommandozeilen-Ansicht die eingegebenen Parameter an den Con-
troller. Im nächsten Schritt kann der Controller nun die Routine zur Erzeugung der Aufzeich-
nungsdaten auslösen. Hier finden nun die Generatoren und Datenobjekte des Modells ihre An-
wendung. Zunächst veranlasst der Controller die Erzeugung eines initialen Benutzermodells mit
einer zufälligen IP-Adresse und einer User-ID. Diese ID ist ein Hashwert aus der zufällig er-
zeugten IP-Adresse. Zusätzlich findet die Erstellung des Verhaltensmodells bzw. des Behavior-
Objekts mit den eingegebenen Parametern des Anwenders statt. Dieses User-Objekt wird im
Anschluss an den datagenerator übergeben, welcher anhand dessen die Aufzeichnungsdaten
generiert und diese an den Controller zurückliefert. Abschließend lässt der Controller ausge-
wählte Informationen zu den erzeugten Daten über die Kommandozeile ausgeben.
5.1.5 Umwandlung in einen Microservice
5.2 Verarbeitung der Aufzeichnungsdaten
5.2.1 Daten-Bereinigung
5.2.2 Aggregation in IP/User-Packete
5.2.3 Erzeugung von Sitzungen
5.3 Anwendung des maschinellen Lernverfahren
5.3.1 Erklärung des Verfahren
5.3.2 Umsetzung in diesem Umfeld
5.4 Visualisierung
Einsatz in der Betriebsumgebung 35
6 Einsatz in der Betriebsumgebung
Wie bereits in Kapitel 4 erläutert, soll die entwickelte Komponente zur Anomalie-Erkennung in
der Produktivumgebung des Kooperationspartner iC-Consult eingesetzt werden. Der Abschluss
der technischen Umsetzung beinhaltet deswegen eine Erweiterung des zuvor entwickelten De-
monstrators um die dafür notwendigen Konzepte. Diese Konzepte wurden schon in der Be-
schreibung des Integrationsansatzes in Kapitel 3 angedeutet und sollen in diesem Kapitel näher
betrachtet, umgesetzt und in einer weitestgehend ähnlichen Umgebung, wie der bei iC-Consult,
eingesetzt werden.
6.1 Aufbau der Testumgebung
6.2 Umsetzung der Erweiterungen
6.3 Betrieb der Lösung
6.4 Evaluation der Ergebnisse
6.5 Inbetriebnahme beim Kooperationspartner
36 Einsatz in der Betriebsumgebung
Projektteam-Arbeiten 37
7 Projektteam-Arbeiten
Abschlussarbeiten in der C&M-Forschungsgruppe finden häufig in Zusammenhang mit einem
Projekt statt. Teil dieses Projekts ist die Zusammenarbeit mit einem Team aus Praktikums- bzw.
Seminararbeitern bei C&M. Diese sind während ihrer Beschäftigung bei C&M einem solchen
Projektteam zugeordnet und erbringen zusätzlich zu ihrer eigenen Ausarbeitung hilfreiche Bei-
träge, die für das übergeordnete Projekt relevant sind.
Im Rahmen der Zusammenarbeit zwischen den Studierenden und dem Abschlussarbeiter, nimmt
dieser, zusätzlich zu den Mitarbeitern der Forschungsgruppe, eine anleitende und betreuende
Rolle ein. In diesem Kapitel soll nun die Zusammenarbeit mit dem Projektteam beschrieben
werden. Hierfür wird zunächst die Struktur erläutert und die Beteiligten des Teams vorgestellt.
Anschließend muss die zu bearbeitende Thematik, der Bezug zur vorliegenden Abschlussarbeit,
die Aufgaben der Projektarbeit sowie das Ziel der mitwirkenden Studierenden beschrieben wer-
den. Danach kann die Erläuterung der Einarbeitungs- und der Bearbeitungsphase des Projekt-
teams stattfinden. Bevor der Abschluss dieses Kapitels eine Bewertung der Zusammenarbeit mit
den Beteiligten des Teams liefert, werden die erreichten Ergebnisse der Projektteam-Arbeit
dargestellt.
7.1 Zusammensetzung des Projektteams
Das zugehörige Projektteam dieser Arbeit, getauft auf den Namen Log_iCC, besteht insgesamt
aus drei Mitwirkenden. Dabei sind zwei der Beteiligten, Tobias Röddiger und Jan-Philip
Quirmbach, Master-Studenten der Informatik-Richtung. Diese müssen im Rahmen ihres Studi-
ums eine gewisse Anzahl von ECTS verpflichtend in Praktika erbringen. Zusammen bringen sie
bereits Erfahrungen im den Bereichen der Webanwendungs-Entwicklung und des Maschinen-
lernens mit, was im Rahmen der Projektarbeit sehr hilfreich ist. Der dritte Mitwirkende in die-
sem Projektteam und gleichzeitig auch Betreuer der Praktikanten ist der Verfasser der vorlie-
genden Arbeit. Zur Abstimmung der anliegenden Aufgaben und Richtungsweisung der Umset-
zung werden wöchentliche Treffen des Projektteams, geleitet durch den Verfasser dieser Arbeit,
abgehalten
7.2 Zu bearbeitendes Themengebiet
Die von den Projektteam-Teilnehmern zu bearbeitende Thematik setzt sich zusammen aus ei-
nem theoretischen und einem praktischen Teil, wobei die Teilnehmer mit den Bereichen des
Maschinenlernens und der Entwicklung von Software unter Anwendung des BDD/DDD-
Entwicklungsprozess von C&M in Berührung kommen sollen. Hierbei liegt der Fokus auf der
Zusammenarbeit und Entwicklung im Team, aber auch auf der Forderung von Eigeninitiative
durch die geschickte Aufteilung und Bearbeitung der anfallenden Aufgaben. Zusätzlich üben
sich die Team-Mitglieder im wissenschaftlichen Schreiben durch die Anfertigung einer Ausar-
beitung zur Dokumentation der inhaltlichen Konzepte, der verwendeten Technologien, der
durchgeführten Arbeit und den Ergebnissen.
Der zur späteren praktischen Aufgabenstellung des Teams zugehörige Bereich dieser Arbeit ist
der in der Einleitung bereits beschriebene Demonstrator in Form einer Web-Anwendung.
38 Projektteam-Arbeiten
7.2.1 Aufgabenstellungen
Wie bereits einleitend erwähnt setzt sich die Aufgabenstellung an die Projektteam-Teilnehmer
aus einer theoretischen sowie einer praktischen Aufgabenstellung zusammen. Die theoretische
Aufgabenstellung für beide Mitwirkenden ist die Analyse von jeweils zwei wissenschaftlichen
Papers, die verschiedene Verfahren zur Anomalie-Erkennung beschreiben. Diese Publikationen
sollen dahingehend analysiert werden, ob eine Kompatibilität mit dem in dieser Arbeit vorlie-
genden Anwendungsfall existiert. Falls eine Kompatibilität möglich ist, soll eine grobe Be-
schreibung der notwendigen Abwandlung der beschriebenen Verfahren zur Anwendung im
vorliegenden Kontext geliefert werden. Diese Teilaufgabe wurde notwendig, da zu diesem Zeit-
punkt der verfolgte Ansatz (Bag of Actions) noch unbekannt war. Die Ergebnisse dieser Unter-
suchung finden sich auch teilweise in Kapitel 3 wieder.
Nach der Identifizierung und Festlegung auf das Bag of Actions-Verfahren sowie der grundle-
genden Implementierung dessen, kann die Bearbeitung des praktischen Teils stattfinden. Die
praktische Aufgabenstellung ist die Umsetzung der Demonstrator-Webanwendung unter Appli-
kation des C&M-Entwicklungsprozess. Dies beinhaltet die Ansteuerung der bereits vorhande-
nen Komponenten der Log-Generierung, der Anomalie-Erkennung nach dem Bag of Actions-
Ansatz sowie dem Gateway zum Aufruf der beiden zuvor genannten Funktionalitäten.
7.2.2 Zielsetzungen
Das Ziel der Untersuchung von verschiedenen Verfahren zur Anomalie-Erkennung durch die
Projektteam-Teilnehmer ist die Identifikation von Vorgehen, die in diesem Anwendungsumfeld
angewendet werden können. Diese zusätzlichen Ansätze können eventuell nach der vollständi-
gen Umsetzung des geplanten Prozessmodells als optionale Module implementiert oder in wei-
terführenden Arbeiten als Erweiterung der entwickelten Grundlage umgesetzt und evaluiert
werden.
Das angestrebte Ergebnis bei der Umsetzung der Demonstrator-Anwendung ist eine moderne
und intuitive Web-Oberfläche zur Steuerung einer Teilmenge der in Kapitel 5 beschriebenen
Komponenten. Dadurch soll es Nutzern dieses Demonstrators möglich sein Nutzermodelle, also
das Verhaltensmodell eines Nutzers und die dazugehörigen Aufzeichnungsdaten, zu erzeugen
und anschließend eine Anomalie-Erkennung auf diesen Daten durchführen zu können. Weiter-
hin ist die Realisierung der Demonstrator-Anwendung mit Hilfe des bei C&M etablierten agilen
Entwicklungsprozesses durchzuführen. Hierbei wird Behavior-Driven Development und das
von Evans beschriebene Domain-Driven Design praktiziert. Aus diesem Prozess sollen die zu-
gehörigen Artefakte wie beispielsweise Vision, Geschäftsziele, Features, Context Map und Re-
lation View hervorgehen, um anschließend eine Auflistung der notwendigen Funktionalität und
einen Ablaufplan für die Implementierung zu erhalten. Der Architektur-Aufbau der sich für die
Entwicklung nach der BDD/DDD-Vorgehensweise anbietet und auch für die Umsetzung des
Demonstrators angestrebt wird, ist die Aufteilung in Microservices (Kapitel 2.9). Der grobe
Aufbau wird in Abbildung ? dargestellt. Die Verknüpfung der Dienste durch APIs ist elementa-
rer Bestandteil einer Microservice-Architektur. Die für die Realisierung des Demonstrators
notwendigen APIs sollen dabei ausreichend dokumentiert werden sodass eine Erweiterung und
Interaktion mit diesen mit geringstmöglichen Aufwand möglich ist. Weiterhin ist die Verwen-
dung von Python als Programmiersprache und Flask als Framework für die Web-Oberfläche
vorgesehen.
Projektteam-Arbeiten 39
7.3 Einarbeitung des Projektteams
Für die Orientierung in den relevanten Themenbereichen des Projekts, also der Entwicklung von
Anwendungen nach dem C&M-Entwicklungsprozess, dem maschinellen Lernen und den
Frameworks zur Umsetzung der gestellten Aufgabenstellungen sowie der grundlegenden Kon-
zepte dieser Arbeit, ist eine Einarbeitung in diese Thematiken notwendig. Diese Einarbeitungs-
phase teilt sich hierbei in zwei Teile auf.
Im ersten Schritt sollen sich die Projektteam-Teilnehmer intensiver mit dem BDD/DDD-
basierten Entwicklungsprozess auseinandersetzen und diesen in ihrer eigenen Ausarbeitung
zusammenfassend beschreiben. Für die Konzepte dieser Vorgehensweise von C&M finden die
Studierenden ausreichend Literatur in den Folien der zum Praktikum gehörenden Vorlesung
WASA2. Dort wird die Vorgehensweise Schritt für Schritt anhand von Beispielen beschrieben.
Nach der Einarbeitung in den Entwicklungsprozess wird dieser anhand eines praktischen Bei-
spiels, der Spring Boot Demo, verdeutlicht. Hier veranschaulicht eine Beispiel-Anwendung in
Form einer ToDo-Liste, die mit dem C&M-Entwicklungsprozess angefertigt wurde, die zuvor
erlernten Konzepte. Die Erfahrungen aus diesem Workshop sollen ebenfalls in der jeweiligen
Ausarbeitung festgehalten werden.
Anschließend beginnen die Teilnehmer mit der Einarbeitung in die Grundlagen dieser Arbeit
und den fundamentalen Konzepten des maschinellen Lernens sodass die Analyse der zugeteilten
Paper der Anomalie-Erkennung stattfinden kann. Hierfür bekommt jeder Studierende jeweils
zwei Paper zugeordnet. Nach der Analyse der Publikationen und der Einigung auf ein Verfahren
mit dem Verfasser dieser Arbeit kann die Einarbeitung in die zu verwendenden Frameworks
stattfinden. Da im Voraus bereits bekannt war, dass die Studierenden an Front- und Backend
arbeiten möchten, konnten sie sich bei der Einarbeitung in Python und Flask gegenseitig unter-
stützen. Im Anschluss an diese finale Einarbeitungsphase kann mit der Bearbeitung der Haupt-
aufgabe des Praktikums, der Realisierung des Demonstrators, begonnen werden.
7.4 Bearbeitung der praktischen Aufgabenstellung
Im Folgenden soll die strukturierte Vorgehensweise des Projektteams bei der Umsetzung der
praktischen Aufgabenstellung beschrieben werden. Den hierbei verfolgten Prozess veranschau-
licht ?. Der Demonstrator dient in dieser Arbeit als Fundament für die später entstehende Integ-
rationsarchitektur und operiert durch die manuelle Bedienung in einer anderen Domäne als die
zu integrierende Lösung. Dadurch wird die Aufgabe, der Erstellung der Artefakte aus dem
C&M-Entwicklungsprozess, an die Studierenden übertragen. Für die Erstellung der Features
standen allerdings die exemplarischen Features aus der Einleitung als Orientierungshilfe zur
Verfügung.
Bevor mit der eigentlichen Durchführung der Implementierung begonnen wird, muss eine Auf-
teilung der Funktionen stattfinden. Da beide Studierende im Front- und Backend-Bereich arbei-
ten möchten bietet sich eine Zuweisung jeweils eines Features an einen Studierenden an.
Dadurch ist es möglich, dass beide Beteiligten die ersten Schritte des Entwicklungsprozesses,
also Beschreibung von Vision, Geschäftszielen und Fähigkeiten, gemeinsam durchführen kön-
nen. Anschließend extrahiert jeder Mitwirkende ein Feature, verfeinert dieses und implementiert
die zugehörige Logik in der Demonstrator-Anwendung. Parallel zum Entwurf der ersten Arte-
fakte des Entwicklungsprozesses durch die Projektteam-Teilnehmer werden die Komponenten
für die Hauptfunktionalität des Demonstrators, die Anomalie-Erkennung und der Log-
40 Projektteam-Arbeiten
Generator, vom Betreuer entworfen, umgesetzt und dem Projektteam zur Integration zur Verfü-
gung gestellt.
Bei der Umsetzung der Features werden den Studierenden keinerlei Vorgaben zur Arbeitsweise
gemacht und weitestgehend freie Hand gewährt. Lediglich bei den wöchentlichen Treffen gibt
es richtungsweisende Hinweise sofern nötig.
7.5 Ergebnisse der Projektteam-Arbeit
In diesem Abschnitt sollen lediglich die Ergebnisse des praktischen Aufgabenteils vorgestellt
werden. Die Ergebnisse der Paper-Analyse werden soweit wie möglich in die untersuchten Ver-
fahren in Kapitel 3 integriert.
Durch die, parallel zum Praktikum stattfindende, WASA2-Vorlesung sind bereits Grundlagen
zur Anwendung von BDD und DDD vorhanden. Dadurch und die eigenständige Vertiefung
dieser Konzepte können die Projektteam-Teilnehmer schnell relevante Features identifizieren
und ausarbeiten. Die dabei entstandenen Features sind in Abbildung ? zu sehen.
Mit dem vorgegebenen Framework Flask und dessen geringen Einarbeitungsaufwand ist es den
Studierenden möglich, in Kombination mit dem HTML-Framework Bootstrap, in kurzer Zeit
ein anschauliches Grundgerüst des Demonstrators zu entwickeln. Durch weiteren Input des Be-
treuers bezüglich der notwendigen Funktionalität aus den Features implementieren die Projekt-
team-Teilnehmer die erwartete Funktionalität zu voller Zufriedenheit und bringen sogar eigene
sinnvolle Ideen für weitere Features in den Entwicklungsprozess mit ein.
Das Gesamtergebnis des Projektes ist eine moderne und einfach zu bedienende Web-Oberfläche
zur Erstellung von Verhaltensmodellen und Durchführung der Anomalie-Erkennung mit den
erzeugten Modellen. Zusätzlich existiert eine gut lesbare und verständliche API-Dokumentation
durch die Verwendung von Swagger UI. Die Oberflächen der Hauptfunktionalitäten werden in
den Abbildungen ? & ? dargestellt.
7.6 Evaluation der Zusammenarbeit
Die Kooperation mit den Projektteam-Teilnehmern war sehr angenehm und produktiv. Man
verstand sich von Anfang an sehr gut und konnte dadurch einen konstruktiven Diskussions- und
Feedbackaustausch abhalten.
Durch die Erfahrung in den relevanten Bereichen konnten die Studierenden sogar sinnvolle
Beiträge für die vorliegende Arbeit beisteuern. Anregungen und Versuche optionale Features
umzusetzen, die den zeitlichen Umfang des Praktikums überschritten hätten, wurden durch den
Betreuer in ihrem Ausmaß eingegrenzt.
Im Rahmen der wöchentlichen Treffen waren die Studierenden stets pünktlich anwesend und
nahmen aktiv an diesen Teil. In der praktischen Phase zeigten die Projektteam-Teilnehmer
durch die Freiheiten in der Umsetzung ein hohes Maß von Selbstorganisation und Eigeninitiati-
ve sodass aufgekommene Fragestellungen zuerst untereinander kommuniziert wurden, bevor
der Betreuer hinzugezogen wurde.
Zusammenfassung und Ausblick 41
8 Zusammenfassung und Ausblick
Zusammenfassung:
Ausblick:
- Verschiedene andere Lernverfahren (unüberwacht) ausprobieren
- Arbeiten mit Referenzmodellen von Nutzerarten
- Deployment und Evaluation des Einsatz in der Produktiv-Umgebung
42 Zusammenfassung und Ausblick
Anhänge XLIII
Anhänge
A Beiträge zu WASA-Kurseinheiten
Hinweis: Im PDF-Dokument der finalen Ausarbeitung sind nach dieser Seite die im Rahmen der
Bachelor-/Masterarbeit erstellten (und zuvor in PDF umgewandelten) WASA-Kurseinheiten-
Seiten einzufügen. Die Reihenfolge ergibt sich aus der nachfolgenden Zusammenfassung.
Zu den folgenden bestehenden WASA-Kurseinheiten wurden Beiträge geleistet:
WASA COURSE TITLE
Kurze Erklärung der inhaltlichen Beiträge und ggf. eine Angabe, wie diese zu den bestehenden
Inhalten stehen (z.B. Ergänzung, Ersatz).
WASA COURSE TITLE
…
Optional
Es wurden die folgenden Kursinhalte erstellt, die keiner bestehenden WASA-Kurseinheit zuge-
ordnet werden können: ...
XLIV Anhänge
Anhänge XLV
B Literaturanalysen
Angabe der Literaturanalyse zu den wichtigsten Dokumenten, die in der Diplomarbeit referen-
ziert wurden. Die analysierten Dokumente sind gemäß ihrer Relevanz zu ordnen. Die Literatur-
analysen zu den drei ersten Dokumenten gehen verstärkt in die Bewertung der Diplomarbeit ein.
Titel der analysierten Publikation
[AB0x] Vorname Name: Titel der analysierten Publikation, weitere Angaben.
Inhalte
Was sind die zentralen Inhalte (Themen, interessante Aussagen, Botschaften, Fragestellungen),
die in der Arbeit (d.h., in der analysierten Literatur) behandelt werden?
(I1)
(I2)
(I3)
Defizite
Welche Defizite bestehender Arbeiten und Lösungen werden als Motivation der eigenen Lösun-
gen genannt?
(D1)
(D2)
(D3)
Prämissen
Welche Einschränkungen und Vorgaben werden hinsichtlich der eigenen Lösungen gemacht?
(P1)
(P2)
(P3)
Lösungen
Was sind die eigenen Lösungen?
(L1)
(L2)
(L3)
Nachweise
Welche Nachweise (Evidence) werden hinsichtlich der Tragfähigkeit der eigenen Lösungen
geliefert?
(N1)
(N2)
(N3)
XLVI Anhänge
Offene Fragen
Welche Fragen sind noch ungelöst geblieben bzw. stellen sich dem Leser?
(O1)
(O2)
(O3)
Sonstiges
Punkte, die in keine der oben genannten Kategorien passen
Anhänge XLVII
C Literatur
[MV-AMD] Muralikrishna Venugopal: ACCOUNT MISUSE DETECTION, 2017.
[CM-AD] Cooperation & Management: C&M-APPLICATION-DEVELOPMENT,
Karlsruher Institut für Technologie (KIT), C&M (Prof. Abeck). C&M-
Teamserver > Mitglieder > 2-1.WASA.
[CM-CMT]
Cooperation & Management: C&M-TEAMARBEIT, Karlsruher Institut
für Technologie (KIT), C&M (Prof. Abeck). C&M-Teamserver > Mitglie-
der > 1-1.Teamarbeit.
[MG+02]
Mukkamala, S., Janoski, G. and Sung, A., 2002. Intrusion detection using
neural networks and support vector machines. In Neural Networks, 2002.
IJCNN'02. Proceedings of the 2002 International Joint Conference
on (Vol. 2, pp. 1702-1707). IEEE.
[LL+13]
Liao, H.J., Lin, C.H.R., Lin, Y.C. and Tung, K.Y., 2013. Intrusion detec-
tion system: A comprehensive review. Journal of Network and Computer
Applications, 36(1), pp.16-24.
[GD+09] Garcia-Teodoro, P., Diaz-Verdejo, J., Maciá-Fernández, G. and Vázquez,
E., 2009. Anomaly-based network intrusion detection: Techniques, sys-
tems and challenges. computers & security, 28(1-2), pp.18-28.
[Zw14] Zwietasch, T., 2014. Detecting anomalies in system log files using ma-
chine learning techniques (bachelor’s thesis).
[CB+09] Chandola, V., Banerjee, A. and Kumar, V., 2009. Anomaly detection: A
survey. ACM computing surveys (CSUR), 41(3), p.15.
[Ay10] Ayodele, T.O., 2010. Machine learning overview. In New Advances in
Machine Learning. InTech.
[CM+83] Carbonell, J.G., Michalski, R.S. and Mitchell, T.M., 1983. An overview of
machine learning. In Machine Learning, Volume I (pp. 3-23).
[Ki15] Kicanaoglu, B., 2015. Unsupervised Anomaly Detection in Unstructured
Log-Data for Root-Cause-Analysis.
[Mi08] Mikut, R., 2008. Data Mining in der Medizin und Medizintechnik (Vol.
22). KIT Scientific Publishing.
[SrM] Srihari, S.N., Machine Learning Overview. Letzter Zugriff: 30.04.18,
15.10 Uhr
[KF+05] Kang, D.K., Fuller, D. and Honavar, V., 2005, June. Learning classifiers
for misuse and anomaly detection using a bag of system calls representa-
tion. In Information Assurance Workshop, 2005. IAW'05. Proceedings
from the Sixth Annual IEEE SMC (pp. 118-125). IEEE.
[BR18] Rocha, B., 2018 Flasgger: Easy Swagger UI for your Flask API (Flasgger
Github-Dokumentation), https://github.com/rochacbruno/flasgger. [Letzter
Zugriff: 30.06.2018]
XLVIII Anhänge
[BC+18] Burke, K., Conroy, K., Horn, R., Stratton, F. and Binet, G., 2018, Flask-
RESTful Documentation, https://flask-restful.readthedocs.io/en/latest.
[Letzter Zugriff: 30.06.2018]
[Ro18] Ronacher, A., 2018, Flask – web development, one drop at a time,
http://flask.pocoo.org/. [Letzter Zugriff: 30.06.2018]
[AD-CLF] Apache Documentation: Common Log Format,
https://httpd.apache.org/docs/1.3/logs.html#common. [Letzter Zugriff:
30.06.2018]
[AD-CBLF] Apache Documentation: Combined Log Format,
https://httpd.apache.org/docs/1.3/logs.html#combined. [Letzter Zugriff:
30.06.2018]
[SB-SED] SmartBeart, Swagger Editor, https://swagger.io/tools/swagger-editor/.
[Letzter Zugriff: 30.06.2018]
[SB-SUI] SmartBear, Swagger UI, https://swagger.io/tools/swagger-ui/. [Letzter
Zugriff: 30.06.2018]
[WP-API] Wikipedia, Application Programming Interface,
https://en.wikipedia.org/wiki/Application_programming_interface. [Letz-
ter Zugriff: 01.07.2018]
[De17] De, B., 2017, API Management : An Architects Guide to Developing and
Managing APIs for Your Organization. Apress Berkeley.
[BS16] Borys, J. and Szotten, D., 2016, Nameko
http://nameko.readthedocs.io/en/stable/. [Letzter Zugriff: 09.07.2018]
[PS-RMQ-INT] Pivotal Software, RabbitMQ Introduction,
https://www.rabbitmq.com/tutorials/tutorial-one-python.html. [Letzter
Zugriff: 10.07.2018]
[PS-RMQ] Pivotal Software, RabbitMQ Homepage, https://www.rabbitmq.com/.
[Letzter Zugriff: 10.07.2018]
[EL-ES] Elastic, Elasticsearch product page, 2018,
https://www.elastic.co/products/elasticsearch. [Letzter Zugriff:
10.07.2018]
[EL-XP] Elastic, X-Pack product page, 2018, https://www.elastic.co/products/x-
pack. [Letzter Zugriff: 10.07.2018]