Master - Thesis in Advanced Computer Science. Benutzerauthentizierung anhand von Web-Interaktion. Prof. Dr. Christoph Reich

Transkript

1 Master - Thesis in Advanced Computer Science Benutzerauthentizierung anhand von Web-Interaktion Referent: Korreferent: Prof. Dr. Christoph Reich Thomas Rübsamen (M.Sc.) vorgelegt am: 26. November 2012 vorgelegt von: Stephan Probst Lörracher Straÿe Steinen

2

3

4

5 Abstract I Abstract Der Autor dieser Master-Thesis befasst sich mit Benutzer-Authentizierung im Rahmen einer Cloud-Sicherheitsarchitektur für mobile Geräte. Die beschriebene Sicherheitsarchitektur nutzt die vollen Vorteile einer Cloud-Umgebung und versucht, anders als viele andere Produkte (z.b. Anti-Virus Lösungen), alle möglichen Angrispunkte bei mobilen Endgeräten abzudecken. Solch eine Architektur benötigt transparente und nicht aufdringliche Authentizierungsmechanismen. Heutzutage existieren allerdings hauptsächlich nicht transparente Mechanismen mit Nutzerbeteiligung. Untersucht wird in dieser Arbeit die Möglichkeit, die Web- Interaktion von Nutzern als Basis für eine Authentizierung zu etablieren. Bei der Web-Interaktion werden die Informationen untersucht, welche bei der Kommunikation via HTTP entstehen. Diese Daten werden mittels künstlichen neuronalen Netzen untersucht und analysiert. Diese Vorgehensweise würde eine transparente Authentizierung ermöglichen, welche das mobile Gerät nicht belastet. Um die Daten aufzuzeichnen wird ein Squid-Proxy verwendet und für den Einsatz von künstlichen neuronalen Netzen wird die Software Membrain genutzt. Die Ergebnisse zeigen, dass eine Authentizierung anhand der Kommunikationsdaten nicht nur möglich ist sondern, unabhängig von der Menge der Daten, sehr gute Ergebnisse liefert.

6

7 Inhaltsverzeichnis III Inhaltsverzeichnis Abstract Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis I III V VII 1 Einleitung Motivation Ziele Gliederung der Arbeit Verwandte Arbeiten Biometriedaten erfassen Sicherheitsarchitekturen User-Identication/Authentication Cloud Computing Grundlagen On-demand self-service Breitband Netzwerkzugang Ressourcen-Pooling Schnelle Elastizität Measured Service Service-Modelle Virtualisierung Auslieferungsmodelle Datenschutz in der Cloud Vor- und Nachteile Zusammenfassung Sicherheitsarchitektur Mobile Security by Cloud - Architektur Mobile Security Taxonomy Sicherheitslevels Komponenten Behavioral Analysis Pool Anwendungsfälle Datenschutz

8 IV Inhaltsverzeichnis 4.4 Zusammenfassung Künstliche neuronale Netze Was sind künstliche neuronale Netze? Das Neuron Architektur Vernetzungsstrukturen Beispiel Lernverfahren Der Backpropagation-Algorithmus Resilient Backpropagation Einsatzgebiete von neuronalen Netzen Geschichtliche Aspekte Zusammenfassung Ergebnisse Proof-of-Concept-Anwendung Clients Hypertext Transfer Protocol Squid-Proxy Membrain Das künstliche neuronale Netz Die.NET-Anwendung Resultate Fazit Literaturverzeichnis Index Anhang A Anhang

9 Abbildungsverzeichnis V Abbildungsverzeichnis Abbildung 1.1 Schichtenansicht auf mobile Geräte Abbildung 2.1 SenGuard Architektur Abbildung 2.2 Parandoid Android Architektur Abbildung 3.1 Der Cloud-Stack mit den unterschiedlichen Service-Modellen 21 Abbildung 3.2 Beispiele für Virtualisierungsarten Abbildung 3.3 Unterschiedliche Cloud-Auslieferungsmodelle Abbildung 3.4 Rechenleistung in klassischem Rechenzentrum Abbildung 3.5 Rechenleistung bei Cloud Computing Abbildung 4.1 Abstrahierte Sicherheitsarchitektur Abbildung 4.2 Mobile Security Taxonomy Abbildung 4.3 Security Levels Abbildung 4.4 Detaillierter Aufbau der Sicherheitsarchitektur Abbildung 4.5 ANN Lifecycle Abbildung 5.1 Vorstellung eines biologischen Neurons Abbildung 5.2 Schichten eines künstlichen neuronalen Netzes Abbildung 5.3 Matrixdarstellung vom Aufbau eines neuronalen Netzes. 60 Abbildung 5.4 Exemplarische Direct Feedback-Verbindung Abbildung 5.5 Exemplarische Indirect Feedback-Verbindung Abbildung 5.6 Exemplarische Lateral Feedback-Verbindung Abbildung 5.7 Exemplarisches Hopeld-Netz mit bidirektionalen Verbindungen Abbildung 5.8 UND-Gatter als LTU Abbildung 5.9 Das Perzeptron Abbildung 5.10 Mehrschichtiges Feedforward-Netz Abbildung 5.11 Lokales Minimum der Fehlerfunktion Abbildung 6.1 Proof-of-Concept Architektur Abbildung 6.2 HTTP-Header Beispiel Abbildung 6.3 Beispiel Log-Zeile des Squid-Logs Abbildung 6.4 Membrain-Editor Abbildung 6.5 Das künstliche neuronale Netz Abbildung 6.6 SFTP Client Instanziierung Abbildung 6.7 Abrufen des Proxy-Logs über SFTP Abbildung 6.8 Extrahieren von Client-OS aus HTTP-Header mittels Regex 86 Abbildung 6.9 Beispiel: Berechnete Lerndaten Abbildung 6.10 Auszug aus Membrain Wrapper Abbildung 6.11 Screenshot der Proof-of-Concept-Anwendung

10

11 Tabellenverzeichnis VII Tabellenverzeichnis Tabelle 3.1 Vorteile einer Public Cloud Tabelle 6.1 ISO/OSI-Schichtenmodell Tabelle 6.2 Squid Log Informationen Tabelle 6.3 Eingeossene Daten-Zeilen von Nutzern Tabelle 6.4 Ergebnisse

12 1 Einleitung 1 1. Einleitung Die vorliegende Master-Thesis wurde an der Hochschule Furtwangen im Studiengang Advanced Computer Science erstellt. Als Referent fungierte Prof. Dr. Christoph Reich und als Korreferent Thomas Rübsamen (beide Hochschule Furtwangen). Dieses Kapitel beschreibt die Motivation (siehe Kapitel 1.1) für diese Master-Thesis und die Ziele, die damit erreicht werden sollen (siehe Kapitel 1.2). Auÿerdem wird auf die weitergehende Gliederung der Arbeit eingegangen (siehe Kapitel 1.3) Motivation Mobile Geräte wie Notebooks, Handys und insbesondere Smartphones und Tablets haben in den letzten Jahren eine rasante Verbreitung 1 erfahren. Auch im Geschäftsumfeld erhalten sie eine immer gröÿere Bedeutung. Das hat weitreichende Folgen auf mehrere Bereiche. Die mobilen Geräte sind meist teure Geräte und somit attraktive Ziele für Diebe. Aber, vor allem für Unternehmen, weitreichendere Konsequenzen würde ein Verlust oder eine Einsicht durch Dritte in Daten auf den Geräten bedeuten. Da die Geräte immer mehr Daten speichern oder Zugri auf diese erhalten, ist der Zugri auf Telefonnummern, Adressen und s teils noch das geringste Übel. Aber nicht nur für Unternehmen, sondern auch im privaten Umfeld haben die Geräte Zugri auf sensible Daten auf den Geräten, so nahm unter anderem der Zugri auf das eigene Bankkonto von Smartphones in Europa alleine im letzten Jahr um 85% zu 2. Die Geräte selber allerdings, die diese sensiblen Daten enthalten, sind oft nur sehr schlecht geschützt. So sind weitergehende Sicherheitsmechanismen, die über eine Einmal-Authentizierung hinausgehen, eine Seltenheit. Eine einmalige PIN oder ein Passwort-Eingabe gewährleistet keine andauernde Sicherheit. Wird das Gerät liegen gelassen, kann jeder, der es ndet, auf alle Daten zugreifen. Existierende Projekte/Lösungen in diesem Bereich behandeln entweder nur eine spezielle Authentizierungsmöglichkeit oder beschreiben separate Sicherheitsarchitekturen, die meist zu viel auf dem Gerät ausführen, trotz begrenzter Ressourcen auf allen Ebenen. Nachfolgend sind eine Reihe von Angrispunkten/Schwachstellen von mobilen Endgeräten aufgelistet, um das Gefahrenpotenzial zu verdeutlichen. Die Punkte sind nach den in Abbildung 1.1 gezeigten Schichten sortiert, die der entsprechende Angri als Ziel hat. Die Bedrohungen lassen sich grob in zwei Kategorien ein- 1 comscore (2012b), Getting Smart: U.S. Smartphone Population Reaches 110 Million Consumers, getting-smart-u-s-smartphone-population-reaches-110-million-consumers/. 2 comscore (2012a), European Mobile Banking Users Get Smarter, comscoredatamine.com/2012/09/european-mobile-banking-users-get-smarter/.

13 2 1 Einleitung Abbildung 1.1: Schichtenansicht auf mobile Geräte 3 teilen: Bedrohungen, bei denen der Angreifer das Gerät in den Händen hält und in denen er aus der Ferne attackiert. Dabei ist es nicht unbedingt nötig, dass der Angreifer unbegrenzte Zeit einen direkten Zugri auf das Gerät erhält. Oft kann es schon ausreichen, wenn das Gerät entwendet und nach kurzem Aufspielen der Modizierungen wieder zurückgesteckt wird. Die in Abbildung 1.1 gezeigten Schichten: Anwendungen, Dienste und Middleware, Betriebssystem, Kommunikationsinfrastruktur und Infrastruktur und Zubehör stellen die unterschiedlichen Angrispunkte dar. Aber das Gerät an sich kann nicht nur das Ziel eines Angris darstellen, sondern durch ein inzierten Gerät an sich können auch Infrastrukturen angegrien werden. 4 ˆ Geräte Hardware Die Hardware eines Geräts bietet nur insofern eine Angrisäche, wenn es im Besitz des Angreifers ist. Hardwaremanipulation Ist der Angreifer im Besitz des Geräts und hat, kann er auf Hardware- Ebene den Speicher direkt auslesen und beschreiben. So kann Schadsoftware eingeschleust werden oder geheime Daten ausgelesen werden. Die Schadsoftware könnte beim Einschalten des Geräts unbemerkt bleiben und dem Angreifer für weitere Angrie eine Hintertür önen o.ä.. Klonen des Geräts Dem Angreifer ist es möglich, das Gerät nachzubauen, sodass es dem Besitzer auf den ersten Blick nicht auällt, dass es nicht das Original 3 vgl.: Bundesamt für Sicherheit in der Informationstechnik (2006), Mobile Endgeräte und mobile Applikationen: Sicherheitsgefährdungen und Schutzmaÿnahmen, S vgl.: Bundesamt für Sicherheit in der Informationstechnik (2006) S. 15.

14 1 Einleitung 3 darstellt. Sollte es ihm doch auallen, hat er meist schon das Passwort eingegeben, welches an den Angreifer gesendet wird. Mehrbenutzerbetrieb Wird das Gerät mit mehreren Nutzern geteilt, besteht die Möglichkeit, dass eine Schwachstelle bei einem bestimmten Nutzer das ganze System kompromittiert, zum Beispiel, wenn der Angreifer Zugri, über ein schlechtes Passwort oder kein Passwort eines Nutzers, erhält. Wartungsarbeiten & Diebstahl Wird ein Gerät zur Reparatur gegeben oder gestohlen und keine bestimmten Sicherungsmaÿnahmen, wie eine Verschlüsselung der Daten, vorgenommen, kann der Dritte auf alle Daten zugreifen. Besonders einfach ist es, ohne Verschlüsselung, an die Daten eines externen Speichermediums, wie z.b. einer MicroUSB-Karte zu kommen. 5 ˆ Betriebssystem und Dienste Das Betriebssystem und andere Dienste bieten nicht nur einen Angrispunkt, wenn das Gerät in den Händen des Angreifers ist, auch aus der Ferne ist ein Angri möglich. Systemzustand Besitzt ein Unternehmen Security Policies, in denen z.b., verschiedene Softwareversionen vorausgesetzt werden, kann ein Angreifer bei einem Systemtest Rückschlüsse auf diese ziehen. Viren, Würmer & Trojaner Durch ein Einschleusen von Schädlingen können Sicherheitsmaÿnahmen ausgehebelt werden und auf bestimmte Daten zugegrien werden. Diese können aber auch Passwörter und sonstige Eingaben aufzeichnen, ungenügende Authentizierungsmethoden und -kontrollen umgehen. Denial-of-Service Ein Denial-of-Service-Angri auf ein bestimmtes Gerät oder auf einen Dienst kann zu einem Absturz und andauernder nicht Erreichbarkeit dessen führen. Puerüberlauf Der Angreifer verursacht absichtlich nicht korrekte Eingaben, um bestimmte Seiteneekte zu erreichen, die nicht von einer Prüfung abgefangen werden. 5 vgl.: Bundesamt für Sicherheit in der Informationstechnik (2006) S. 17.

15 4 1 Einleitung Aufzeichnen von Netzwerk-Trac Durch die Aufzeichnung der Netzwerk-Kommunikation ist die Ermittlung von Passwörtern und anderen sensiblen Daten möglich. Unterschiedliche Entschlüsselungsverfahren kommen je nach Verschlüsselung zum Einsatz. Auÿerdem ermöglicht dies ein Man-in-the-middle-Angri auszuführen. Kryptograe-Verfahren Die Verschlüsselungsverfahren selbst stellen einen Schwachpunkt dar, wenn eine bekannte Schwachstellen ausgenutzt werden können. 6 ˆ Anwendungen Die Angrispunkte in installierten Anwendungen kommen meist durch Fehler bei der Implementierung zustande und können von Anwendung zu Anwendung unterschiedlich sein. Ist der Angreifer nicht im Besitz des Gerätes, handelt es sich generell um die gleichen Punkte wie bei dem Betriebssystem und bei den Diensten. Authentizierungen Wird eine Authentizierung von einer Anwendung durchgeführt, kann ein Angreifer, der im Besitz des Gerätes ist, diese umgehen, da diese im Speicher stattnden und er Zugri darauf hat. Puerüberlauf & andere Programmierfehler Sind Anwendungen nicht sorgfältig implementiert, können Fehler in ihnen ausgenutzt werden, um Authentizierungen zu übergehen. Protokolle Protokolliert eine Anwendung das Vorgehen eines Angreifers auf dem Gerät, kann dieser seine Spuren durch ein Löschen oder Manipulieren der Dateien verwischen. 7 ˆ Infrastruktur Mit einem kompromittierten Gerät ist es möglich, eine Infrastruktur anzugreifen. Handelt es sich um ein Gerät, welches auch sonst mit dieser Infrastruktur kommuniziert und eventuell sogar als vertrauenswürdig eingestuft wird, lassen sich eektive Angrie ausführen. Einschleusen von Schadsoftware DoS Mit einem gekaperten Gerät in einem Sicherheitsbereich können Diens- 6 vgl.: Bundesamt für Sicherheit in der Informationstechnik (2006) S. 19f. 7 vgl.: Bundesamt für Sicherheit in der Informationstechnik (2006) S. 20f.

16 1 Einleitung 5 te von Innen mit einem DoS-Angri attackiert werden, die von auÿen geschützt sind. Diebstahl von Daten & unrechtmäÿige Nutzung von Diensten Durch das Gerät kann eventuell auf sonst gesicherte Informationen zugegrien werden, da dem Gerät vertraut wird. Auÿerdem ist es so möglich, Dienste zu nutzen, die anders nicht zugänglich wären. 8 In einer Sicherheitsarchitektur reicht es nicht aus, wenn die oben beschriebenen Punkte verhindert werden. Sicherheit stellt einen Prozess dar, der immer und immer wieder überarbeitet werden muss und neue Sicherheitslücken und Angrisarten erkannt und verhindert werden müssen. Besonders bei der Einführung von neuen Technologien muss beachtet werden, dass viele neue, noch nicht entdeckte Sicherheitslücken Angrie ermöglichen. Um in diesen Fällen eine schnelle Reaktion zu gewährleisten, ist ein sicherer Rahmen in Form einer guten Sicherheitsarchitektur nötig. Diese Sicherheitsarchitektur muss auf bestehende Authentizierungsmethoden zurückgreifen. Da heutzutage allerdings hauptsächlich Methoden angewandt werden, welche eine direkte Interaktion des Nutzers benötigen und so störend sind bei andauernder Anwendung, fehlt es vor allem an transparenten und robusten Authentizierungsmethoden Ziele Das Ziel der Arbeit ist es, eine Sicherheitsarchitektur beschreiben, die einerseits transparent für den Nutzer ist, d.h. er gar nicht mitbekommt, wenn er sich authentiziert, andererseits aber auch die Akkulaufzeit so schonend wie möglich beeinusst. Um unter anderem die in Kapitel 1.1 beschriebenen Angrispunkte zu schlieÿen und auf neue Gefahren reagieren zu können, muss die Architektur modular und erweiterbar sein. Auÿerdem soll auch eine fortlaufende Authenti- zierung gewährleistet werden. Als Authentizierungsgrundlage sollen nicht nur klassische Mechanismen wie die Passwort-Eingabe, sondern auch biometrische Daten gesammelt und genutzt werden. Es gilt einen hohen Grad an Sicherheit zu gewährleisten und trotzdem eine hohe Nutzerakzeptanz zu erreichen. Am sichersten wäre es, wenn alle 30 Sekunden eine starke Authentizierungsmethode wie Sprachanalyse oder PIN-Eingabe erfolgen würde. Allerdings würde dies kein hohe Akzeptanz erzielen und wäre in der Praxis nicht brauchbar. Gesucht werden deshalb auch robuste und transparente Wege zur Authentizierung. In dieser Arbeit soll untersucht werden, ob Nutzer durch das alleinige Verhalten im Netz identiziert werden können. Dabei sollen die Informationen über das Verhalten 8 vgl.: Bundesamt für Sicherheit in der Informationstechnik (2006) S. 21.

17 6 1 Einleitung eines Nutzers nicht über die grasche Oberäche, sondern alleinig über die entstehende Kommunikation gewonnen werden. Diese Methode hat den Vorteil, dass sie keinerlei zusätzlichen Aufwand auf dem Gerät vonnöten wäre und somit keinen Einuss auf den Akku hat und komplett ausgelagert werden kann und voll von z.b. der Cloud protieren kann. Eine geeignete Sicherheitsarchitektur muss auf verschiedene biometrische Algorithmen für die Authentizierung zurückgreifen, so stellt das Verfahren anhand der Web-Interaktion einen Baustein für diese dar und hat das Ziel, die Ergebnisse im Bereich der transparenten Methoden zu verbessern Gliederung der Arbeit In Kapitel 2 werden verwandte Arbeiten zum Thema der Master-Thesis, in den Bereichen der Datenerfassung, der Authentizierungsalgorithmen und verwandte Sicherheitsarchitektur-Konzepte beschrieben. In Kapitel 3 wird auf die für die in Kapitel 4 beschriebene MoSeC-Sicherheitsarchitektur zu Grunde liegende Technologie Cloud Computing eingegangen. In Kapitel?? werden die Grundlagen zu künstlichen neuronalen Netzen beschrieben, welche zur Analyse der anfallenden Daten zur Authentizierung genutzt werden. Die Ergebnisse der Arbeit und die Beschreibung des Proof-of-Concept-Implementierung sind in Kapitel 6 zu nden und in 7 wird ein Fazit gezogen.

18 2 Verwandte Arbeiten 7 2. Verwandte Arbeiten In diesem Kapitel werden verwandte Arbeiten in Bezug auf das Thema dieser Master-Thesis vorgestellt. Da diese Arbeit mehrere Themenbereiche abdeckt, ist dieses Kapitel in mehrere Unterkapitel unterteilt. In 2.1 geht es vor allem um Arbeiten, welche sich mit unterschiedlichen Methoden zur Informationsbeschaffung befassen. In Unterkapitel 2.2 werden verwandte Sicherheitsarchitekturen mit anderen Ansätzen beschrieben und in 2.3 geht es verwandte Ansätze zur Benutzer- Authentizierung Biometriedaten erfassen Im Bereich der mobilen Sicherheit beschreiben R. Guo et al. 9 mit MobileSens ein Framework, um die gesamte Interaktion vom Nutzer mit seinem mobilen (Android) Gerät aufzuzeichnen. MobileSens zeichnet von der Kommunikation über GPRS, den Browser, usw. bis zu System Events, wie z.b.: Bildschirm an/aus oder WLAN an/aus, alles auf. Die gesammelten Daten werden, da das Hochladen sehr viel Energie verbraucht, erst dann auf einen Server hochgeladen, wenn das mobile Gerät seinen Akku lädt und der Bildschirm ausgeschaltet ist. MobileSens stellt ein interessantes Logging-Framework dar, welches fast alles aufzeichnet, was aufzuzeichnen ist. Aufgrund der verschiedenen erhobenen Daten könnte es als Grundlage für eine Menge unterschiedlicher Authentizierungsmethoden etabliert werden. Ein Problem stellt allerdings das Hochladen der Daten dar. Da dies erst zeitverzögert geschieht, wäre eine fortlaufende Authentizierung nicht gewährleistet oder müsste auf dem Gerät selbst stattnden, was aus naheliegenden Gründen des Energieverbrauchs keine Option darstellt. Weitere Probleme stellt der Datenschutz und der Umstand, dass dafür uneingeschränkte Root-Rechte vonnöten wären, dar. Mit SystemSens beschreiben H. Falaki, R. Mahajan und D. Estrin in SystemSens: A Tool for Monitoring Usage in Smartphone Research Deployments 10 ein System, um Daten der Smartphone-Sensoren aufzuzeichnen. SystemSens wurde für Android geschrieben und sollte Anfangs nur den Batterie- und Bildschirm-Status aufzeichnen. Mittlerweile ist es zu einer Anwendung geworden, um alle möglichen Sensoren aufzuzeichnen und hochzuladen. Auÿerdem erlaubt es Drittapplikatio- 9 Guo, R./Zhu, T./Wang, Y./Xu, X. (2011), MobileSens: A framework of behavior logger on Andriod mobile device, In: Pervasive Computing and Applications (ICPCA), th International Conference on, IEEE. 10 Falaki, H./Mahajan, R./Estrin, D. (2011), SystemSens: a tool for monitoring usage in smartphone research deployments, In: Proceedings of the sixth international workshop on MobiArch, ACM.

19 8 2 Verwandte Arbeiten nen via SytsemSens Sensor-Daten zu loggen. Aufgrund der erhobenen Daten könnte SystemSens oder eine ähnliches Framework als Datenlieferant für eine Sicherheitsarchitektur dienen Sicherheitsarchitekturen In User Modelling for Exclusion and Anomaly Detection:A Behavioural Intrusion Detection System 11 veröentlichen G. Panell und H. Ashman eine Ansatz um automatisierte Verhaltensanalyse für ein Intrusion Detection System, kurz IDS, zu nutzen. Simpliziert ist die Idee, User Models zu bilden, die das zu erwartende Verhalten des Nutzers beinhalten, und dann gegen diese User Models zu testen, ob ein Eindringling im System ist. Es geht also nicht darum, einen Nutzer einem User Model zuzuordnen, sondern zu schauen, ob er nicht in diese Verhaltensweisen hineinpasst. Um gute User Models zu bilden und dagegen zu testen, setzen die Autoren nicht nur Tastenanschlagsanalysen, sondern auch andere Metriken und Algorithmen ein. So werden die laufenden Programme überwacht, die Ressourcennutzung der einzelnen Programme (wie CPU- und RAM-Auslastung ), der Webverlauf, das Verhalten beim Spielen am Rechner, aber auch GUI-basierte Metriken, wie die Anzahl der oenen Fenster. Getestet wurde ein Prototyp an verschiedenen Rechnern, deren Nutzer diese unterschiedlich verwenden: An einem Oce-Rechner hauptsächlich für Textverarbeitungsprogramme genutzt, an einem Computer, an dem hauptsächlich im Internet gesurft wurde, an einem Spiele-Rechner, einem Entertainment-Computer und an einem Rechner eines Power-Users der alles miteinander kombinierte. Daten wurden durch das System in einem 30 Sekunden Intervall aufgezeichnet. In der Lernphase des IDS, dem Aufbauen der User Models, wurde zehn Tage lang Datensätze gespeichert. Nach Bildung der User Models wurde untersucht, wie das System auf die eigentlichen Nutzer und auf Eindringlinge, andere Nutzer, die versucht haben, das Verhalten zu imitieren, reagiert. Getestet wurde unter anderem auch, welche Art von Analyse wie schnell auf ein Eindringen reagiert. Am schnellsten waren die Verfahren, die das Verhalten des Nutzer direkt reektierten, wie z.b.: Die Tastenanschlagsanalyse mit 120 Sekunden im Durchschnitt. Die Langsamsten waren die, die anwendungsspezischen Charakteristika mit einbeziehen, wie z.b.: Die Anzahl der oenen Fenster mit im Schnitt 180 Sekunden. Das IDS wurde nur auf Windows-Desktop-Rechnern getestet und ist weniger relevant für 11 Pannell, Grant/Ashman, Helen (2010), User Modelling for Exclusion and Anomaly Detection: A Behavioural Intrusion Detection System, In: De Bra, Paul/Kobsa, Alfred/Chin, David (Hrsg.), User Modeling, Adaptation, and Personalization, Band 6075, Springer Berlin / Heidelberg, ISBN

20 2 Verwandte Arbeiten 9 den mobilen Bereich, allerdings ist die Vorgehensweise und die Untersuchung der unterschiedlichen Algorithmen in Bezug auf die Zeit sehr aufschlussreich. Verschiedene Ansätze könnten für eine Sicherheitsarchitektur adaptiert werden. Shi et al. stellen in SenGuard: Passive User Identication on Smartphones Using Multiple Sensors 12 ein Framework zur Nutzeridentizierung auf Smartphones vor. SenGuard setzt auf eine fortlaufende und nicht störende Nutzerauthentizierung. Hierfür nutzt SenGuard mehrere Sensoren des Smartphones, aufgezeichnet werden z.b. Ton, Standort, Multitouch und die Bewegung. SenGuard wurde für das mobile Betriebssystem Meego 13 entwickelt, welches auf den Architekturen X86/Intel-Atom und ARM läuft. Um die fortlaufende Nutzerauthentizierung zu erreichen setzt SenGuard auf Virtualisierung. Auf der Hardware wird ein Abbildung 2.1: SenGuard Architektur Shi, W./Yang, J./Jiang, Y./Yang, F./Xiong, Y. (2011), SenGuard: Passive user identication on smartphones using multiple sensors, In: Wireless and Mobile Computing, Networking and Communications (WiMob), 2011 IEEE 7th International Conference on, IEEE. 13 Linux Foundation, Meego, 14 Shi/Yang/Jiang (2011) S. 3.

21 10 2 Verwandte Arbeiten Xen Hypervisor 15 ausgeführt, welcher als Schnittstelle zur Hardware dient (Abbildung 2.1 zeigt die beschriebene Architektur). MeeGo läuft als Xen Guest OS mit wenig Rechten. Der Nutzer sieht nur sein MeeGo Betriebssystem, welches im Vollbild läuft, parallel läuft eine versteckte Domain 0. Diese führt den SenGuard-Service aus und besitzt I/O-Rechte, d.h., sie kann auf alle Sensoren und Geräte zugreifen und führt die Geräte Treiber aus. Das MeeGo OS greift via virtualisierte Geräte/Sensoren auf die Daten, die von der Domain 0 kommen, zu. Der Datenaustausch geschieht über einen gemeinsamen Speicher. Die Domain 0 fängt die Daten von den Geräte Treibern ab und speist sie in die sogenannten Classier ein. Diese treen eine Aussage anhand der erhaltenen Daten, ob diese zum Eigentümer des Geräts passen. Um Strom zu sparen, werden erstmal auf die Daten der Sensoren gesetzt, die einen geringen Stromverbrauch haben. Reichen die Daten aus, um eine gute Aussage zu treen, werden andere Sensoren mit hohem Stromverbrauch, nicht aktiviert. Sollten die Daten nicht ausreichen, werden nach und nach, dem Stromverbrauch entsprechend, mehr Sensoren zugeschaltet. Die Autoren haben die gleichen Ziele, eine Systemarchitektur zu schaen, die fortlaufende, nicht störende, robuste Authentizierung auf mobilen Geräten. Allerdings verhindert die Fokussierung auf MeeGo ein stabiles Betriebssystemumfeld. MeeGo selber wird nicht mehr weiterentwickelt und ist in Tizen 16 aufgegangen. Und auch bei Tizen gibt es immer wieder Gerüchte über eine Verschmelzung mit anderen Projekten. Ein weiterer negativer Punkt stellt die Virtualisierung dar, auÿerdem laufen alle Funktionen direkt auf dem mobilen Gerät. Es darf bezweifelt werden, ob der Energieverbrauch nicht zu hoch für einen intensiven und täglichen Gebrauch ist, vor allem, wenn komplexe und aufwendige Algorithmen in den Classiers zum Einsatz kommen. In der Arbeit InfoSec-MobCop - Framework for Theft Detection and Data Security on Mobile Computing Devices 17 beschreiben Anand, Deepank und Nidhi Gupta eine Sicherheitsframework, um im Falle eines Diebstahls wichtige Daten und zu schützen und den Dieb anhand von geändertem Nutzerverhalten aufzuspüren. Bei Feststellung und/oder Meldung eines Diebstahls, wird dies via SMS gemeldet. Auch der Fall, dass ein Dieb die SIM nach dem Diebstahl entnimmt, soll abgedeckt sein. InfoSec-MobCop beschreibt eine mehrschichtige 15 Citrix, Welcome to xen.org, home of the Xen hypervisor, the powerful open source industry standard for virtualization Linux Foundation, Tizen An open source, standards-based software platform for multiple device categories Gupta, Anand/Gupta, Deepank/Gupta, Nidhi (2009), InfoSec-MobCop - Framework for Theft Detection and Data Security on Mobile Computing Devices, In: Ranka, Sanjay et al. (Hrsg.), Contemporary Computing, Band 40, Springer Berlin Heidelberg, ISBN

22 2 Verwandte Arbeiten 11 Sicherheitsarchitektur, die auf dem ROM des Mobilgeräts installiert wird. Durch eine Abspeicherung der aktuellen Position ist es möglich, die IMEI-Nummer bei einem Diebstahl via SMS an den Service Provider zu senden. Bei der IMEI-Nummer handelt es sich um eine eindeutig identizierbare Nummer eines GSM- oder UMTS-Geräts. InfoSec-MobCop soll den Ansatz vorhandener Diebstahlschutzsoftware mit Nutzerauthentizierung verbinden. Dabei stützt es sich hauptsächlich auf die Analyse des Tipp- und Schreibverhaltens des Nutzers. N.L. Clarke und S.M. Furnell beschreiben in Advanced user authentication for mobile devices 18 eine Sicherheitsarchitektur, deren Ziele mit der in Kapitel 4 weitgehend übereinstimmt, d.h. eine Architektur zu etablieren, welche eine fortlaufende, nicht aufdringliche und transparente Authentizierung auf mobilen Endgeräten ermöglicht. Clarke und Furnell gehen unter anderem auch auf eine Umfrage 19 unter 230 Geschäftsleuten ein, von denen 81% angegeben haben, dass sie wertvolle Informationen auf ihren PDAs gespeichert hätten. 70% wären an einem Sicherheitssystem interessiert und 69% wären bereit mehr Geld für das Gerät auszugeben, wenn ein solches Sicherheitssystem vorinstalliert wäre. Die Sicherheitsarchitektur berücksichtigt und integriert biometrische Verfahrensweisen, wie z.b.: Die Stimmanalyse oder Tastenanschlagsanalyse. Auÿerdem beinhaltet die Architektur ein System Integritäts-Level, das die aktuelle Integrität des Geräts mit einem Level zwischen -5 und +5 beschreibt. Beim Einschalten des Geräts bendet sich das Level bei 0. Ein weiterer wichtiger Faktor stellt das Alert Level dar. Das Alert Level kann Zustände, wie z.b. Normal, authentizieren beim nächsten Input, mit starkem biometrischem Verfahren authentizieren und Gerät sperren annehmen. Das Alert Level wird hoch gestuft, wenn ein Authentizierungsversuch fehlschlägt. Gehen mehrere Versuche schief, wird das Gerät gesperrt und kann nicht weiter genutzt werden. Ein erhöhtes Alert Level hat Einuss auf die System Integrität. An diese lassen sich dann verschiedene Dienste oder Anwendungen koppeln, welche nur mit einer bestimmten Integrität des Systems verwendet werden können. Sollte ein Gerät gesperrt werden, kann es nur noch via PUK-Nummer oder mit Hilfe eines Administrators wieder freigeschaltet werden. Bei einem niedrigen Alert Level und einer guten System Integrität werden fortlaufende und periodische Authentizierungsversuche vollführt. Die Ziele der Architektur decken sich in vielen Bereichen zwar mit der in Kapitel 4 beschriebenen, allerdings nutzt sie nicht die Ressourcen einer Cloud-Infrastruktur. Um 18 Clarke, N.L./Furnell, S.M. (2007), Advanced user authentication for mobile devices, Computers & Security, 26, Nr. 2 S , ISSN Shaw, K. (2004), Data on PDAs mostly unprotected, Network World Fusion. Available from nwfusion. com.

23 12 2 Verwandte Arbeiten auf Netzausfall zu reagieren, existiert eine redundantes Server-System auf dem Gerät, welches voll genutzt wird, wenn der Netzempfang ausfällt. Mit Paranoid Android 20 veröentlichten Portokalidis et al ein Intrusion Detection System für Android-basierende Geräte. Wie die Sicherheitsarchitektur, die in Kapitel 4 beschrieben wird, nutzt Paranoid Android Cloud-Dienste, um seine Ziele umzusetzen. Abbildung 2.2 zeigt die Paranoid Android-Architektur. Abbildung 2.2: Parandoid Android Architektur 21 Sie weist durchaus Ähnlichkeiten mit der in Kapitel 4 beschriebenen Architektur, z.b. die Kommunikation des Gerätes über einen Proxy, die Weiterleitung der aufgezeichneten Verbindungsdaten und die Nutzung der Vorteile des Cloud Computings. Der groÿe Unterschied liegt allerdings darin, dass Paranoid Android das komplette Android-Gerät in der Cloud spiegelt, bzw. in einer virtuellen Maschine emuliert. So können auf dem Cloud-Abbild aufwendige Sicherheitsmechanismen zum Einsatz kommen, welche auf dem Gerät selbst undenkbar wären. Dies hat trotzdem den entscheidenden Nachteil, dass das andauernde Emulieren die Akkulaufzeit des mobilen Geräts mit ca. -30% zu sehr negativ beeinusst, da jede Aktion, die auf dem mobilen Gerät ausgeführt wird, auch in die Cloud übermittelt werden muss. Die Autoren beschreiben zwar einen Weg durch einen Eingri in den Android-Kernel, um dies zu verbessern. Allerdings stellt das einen sehr groÿen Eingri in Android selbst dar. In den wissenschaftlichen Arbeiten Cost-aware systemwide intrusion defense 20 Portokalidis, Georgios/Homburg, Philip/Anagnostakis, Kostas/Bos, Herbert (2010), Paranoid Android: versatile protection for smartphones, In: Proceedings of the 26th Annual Computer Security Applications Conference, New York, NY, USA: ACM, ACSAC '10 ISBN Portokalidis/Homburg/Anagnostakis (2010) S. 349.

24 2 Verwandte Arbeiten 13 via online forensics and on-demand detector deployment 22 und A cloud-based intrusion detection and response system for mobile phones 23 wird ein ähnlicher Ansatz wie bei (Portokalidis/Homburg/Anagnostakis, 2010) verfolgt. Es wird ein Software-Agent auf dem mobilen Gerät installiert, der Sensor-, Nutzer- und Eingabeinformationen sammelt. Über einen Proxy wird die Kommunikation überwacht. Die Daten werden gesammelt in der Cloud in einem Emulator analysiert. Gegenmaÿnahmen werden an den Agenten auf dem Gerät weitergeleitet und von ihm ausgeführt. Allerdings wird nur die Intrusion Detection behandelt und nicht alle nötigen Aspekte, um ein Gerät rundum abzusichern. A. Shabtai et al. präsentieren mit Andromaly 24 ein Malware Detection Framework für Android Geräte. Sie portieren den Ansatz von klassischen Host-basierenden Intrusion Detection Systemen auf die Android Plattform. Durch den Einsatz von künstlicher Intelligenz werden Attacken erkannt und Gegenmaÿnahmen eingeleitet. Allerdings dadurch, dass die Analysen auf dem Gerät selbst ausgeführt werden, wird die Verwendung von aufwendigen Untersuchungen und Algorithmen verhindert, da die mobilen Geräte nicht in der Lage sind, diese zu stemmen oder es zu sehr auf die Akkuleistung durchschlägt User-Identication/Authentication Es existieren verschiedene Ansätze zur Identizierung oder zum Clustern von Nutzern, welche zur fortlaufenden Authentizierung genutzt werden könnten. So beschreiben D. Yinan, Y. Hao und L. Zhenming 25 einen Ansatz, um das Verhalten bei der Nutzung des Internets zu interpretieren und die Nutzer in verschiedene Gruppen einzuteilen. Gesammelt wurden die Daten von über Haushalten. Diese Daten sollen zur Verbesserung des Netzwerkes und zur Anpassung der Strategien des jeweiligen Internet Service Providers genutzt 22 Zonouz, Saman A./Joshi, Kaustubh R./Sanders, William H. (2010), Cost-aware systemwide intrusion defense via online forensics and on-demand detector deployment, In: Proceedings of the 3rd ACM workshop on Assurable and usable security conguration, New York, NY, USA: ACM, SafeCong '10 ISBN Houmansadr, A./Zonouz, S.A./Berthier, R. (2011), A cloud-based intrusion detection and response system for mobile phones, In: Dependable Systems and Networks Workshops (DSN-W), 2011 IEEE/IFIP 41st International Conference on,. 24 Shabtai, A./Kanonov, U./Elovici, Y./Glezer, C./Weiss, Y. (2012), Andromaly: a behavioral malware detection framework for android devices, Journal of Intelligent Information Systems,. 25 Yinan, D./Hao, Y./Zhenming, L. (2009), Broadband dial-up user behavior identication and analysis, In: Broadband Network & Multimedia Technology, IC-BNMT'09. 2nd IEEE International Conference on, IEEE.

25 14 2 Verwandte Arbeiten werden. Die Arbeit zeigt, dass es möglich ist, Menschen anhand der Analyse von bestimmtem Netznutzungsattributen in verschiedene Gruppen einzuteilen. J. R. Kwapisz, G. M. Weiss und S. A. Moore beschreiben in ihrer wissenschaftlichen Ausarbeitung Cell Phone-Based Biometric Identication 26 die Möglichkeit Smartphone-Nutzer anhand ihres Ganges zu identizieren und erzielen dabei sehr gute Ergebnisse. Genutzt wird dabei der Bewegungssensor. Er wird mittlerweile in fast jedem Smartphone verbaut ist, um die sogenannte Screen-Rotation, also das Wechseln von der Hochkant-Anzeige zu einer Queransicht, bei entsprechender Neigung des Geräts durchzuführen. Ein weiterer Anwendungsfall stellt die Verbesserung der Spiele-Erfahrung dar. Die Autoren zeigen, welche Daten erhoben und wie diese weiterverarbeitet werden. Getestet wurde in vier unterschiedlichen Disziplinen: Dem normalen Laufen, dem Joggen, Treppen hochsteigen und dem Treppen runtersteigen. In jedem Bereich wurden 10 Sekunden Abschnitte aufgezeichnet, anhand derer eine Berechnung weiterer Daten erfolgte. Zur Identizierung wurden unter anderem neuronale Netze verwendet mit einer Identizierungswahrscheinlichkeit von 69% bis 92,2%. Die Ergebnisse sind erstaunlich, unter Beachtung dessen, dass diese nur anhand 10 Sekunden erzielt wurden. Diese Arbeit macht sich den medizinischen Umstand zunutze, dass der Gang eines Menschen von einem anderen unterschieden werden kann. Bei einer robusten Verwendungsmöglichkeit dieser Vorgehensweise abseits der gestellten Laborbedingungen könnte sie als zusätzliche Authentizierungsmethode innerhalb einer Sicherheitsarchitektur (siehe Kapitel 4) zum Einsatz kommen. Auch Wong et al. versuchen in ihrer Arbeit 27 die normale Einmal-Passwort- Authentizierung zu verbessern. Die Autoren konzentrieren sich hierbei um die Analyse der Tastenanschläge. Verwendet werden hierfür künstlich neuronale Netzen und der K-Nearest Neighbor-Alhorithmus. Die Charakteristika, die untersucht werden, sind z.b.: Die Zeit zwischen den Tastenanschlägen, der Tastendruck und wie lange eine Taste gedrückt ist. Mit einem in C++ geschrieben Prototypen wurden im Schnitt 84,63% der Nutzer zugelassen und 98,97% der Versuche, das gleiche Passwort von einer anderen Person einzugeben, abgelehnt. Das Vorgehen würde nur die Sicherheit der Passwort-Authentizierung erhöhen, 26 Kwapisz, J.R./Weiss, G.M./Moore, S.A. (2010), Cell phone-based biometric identication, In: Biometrics: Theory Applications and Systems (BTAS), 2010 Fourth IEEE International Conference on, IEEE. 27 Wong, Fadhli Wong Mohd Hasan/Supian, A.S.M./Ismail, A.F./Kin, Lai Weng/Soon, Ong Cheng (2001), Enhanced user authentication through typing biometrics with articial neural networks and k-nearest neighbor algorithm, In: Signals, Systems and Computers, Conference Record of the Thirty-Fifth Asilomar Conference on, Band 2,, ISSN

26 2 Verwandte Arbeiten 15 allerdings ermöglicht es keine fortlaufende Authentizierung. E. S. Imsand und J. A. Hamilton Jr. setzen in User Identication Using GUI Manipulation Patterns and Articial Neural Networks 28 die Art und Weise, wie ein Nutzer die grasche Oberäche benutzt, ein und kombinieren dies mit dem Einsatz von künstlichen neuronalen Netzwerken. Sie präsentieren die Resultate einer Analyse von GUI-based Intrusion Detection (GUIID) Systemen. GUIID macht sich zunutze, dass viele verschiedene Wege existieren, um eine Aufgabe über die GUI zu lösen. Z.B.: Das Kopieren von Daten kann zum einen über eine Tastenkombination geschehen, über ein entsprechenden Button oder via eines Befehls im Context-Menü. Hierzu entwickelten sie eine eigene Monitoring-Software, da keine andere ihren Ansprüchen genügte. 31 Teilnehmer mussten bestimmte Aufgaben nacheinander abarbeiten, dann eine halbe Stunde Pause machen und den Vorgang wiederholen. Diese Daten wurden dann von einem künstlichen neuronalen Netz analysiert. Als Eingangsparameter wurden z.b. die Anzahl der verschiedenen Nutzeraktionen wie links-klick, Doppel-Klick oder eine bestimmte Taste oder wie oft ein bestimmtes GUI-Element genutzt wurde, verwendet. Aber auch die Anzahl, wie oft ein bestimmter Prozess genutzt wurde, ieÿt ins neuronale Netz. 45 Neuronen wurden in einer versteckten Schicht verwendet (siehe Kapitel 5.2). Für jeden der Nutzer existierte ein Ausgangsneuron, welches die Identizierung eines Menschen anzeigt. Von 31 Teilnehmern konnten nur 12 Nutzer wirklich identiziert werden, das entspricht einer Identizierungsrate von 38,7%. Die Autoren haben sich Mühe gegeben, das System in der realen Welt zu testen, was die etwas schlechten Ergebnisse erklären könnte. Auch die geringe Anzahl von Daten könnte einen negativen Einuss auf das Resultat gehabt haben. 28 Imsand, E.S./Garrett, D./Hamilton, J.A. (2009), User identication using GUI manipulation patterns and articial neural networks, In: Computational Intelligence in Cyber Security, CICS '09. IEEE Symposium on,.

27

28 3 Cloud Computing Cloud Computing Cloud Computing dient als Basis für die in Kapitel 4 beschriebene Sicherheitsarchitektur, in diesem Kapitel wird ein Einblick gewährt. Eine allgemeine und eine klare Denition von Cloud Computing existiert nicht. Das National Institute of Standards and Technology, kurz NIST, aktualisierten ihre Denition 2011, wie folgt: Denition 1 (Cloud Computing - NIST). Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of con- gurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management eort or service provider interaction. [...] 29 Eine weitere Denition von (Metzger/Reitz/Villar, 2011), beschreibt Cloud Computing so: Denition 2 (Cloud Computing - Metzger et al.). Cloud Computing (deutsch etwa Rechenleistung aus der Wolke) verfolgt den Ansatz, abstrahierte IT- Infrastrukturen - z.b. Rechenkapazität, Datenspeicher [...], fertige Software [...] und Programmierumgebungen [...] - dynamisch an den Bedarf angepasst über ein Netzwerk zur Verfügung zu stellen. 30 Die Denition des NIST sieht zusätzlich zur gezeigten Denition noch fünf essenzielle Charakteristiken (siehe Kapitel 3.1, drei Service-Modelle (siehe Kapitel 3.2) und vier Auslieferungsmodelle (siehe Kapitel 3.4). In Kapitel 3.3 wird kurz auf Virtualisierung eingegangen, da dies eine der Technologien ist, der das Cloud Computing eine Vielzahl seiner Eigenschaften verdankt. Der Datenschutz in der Cloud wird separat in Kapitel 3.5 behandelt. In 3.6 wird auf die Vorteile von Cloud Computing und dessen Risiken eingegangen Grundlagen Dieses Kapitel beschreibt und erläutert die grundlegenden Eigenschaften des Cloud Computings On-demand self-service Es ist keine menschliche Interaktion nötig, um einen Service (wie z.b. mehr Festplattenspeicher) in Anspruch zu nehmen. Werden z.b. mehr Ressourcen benötigt, 29 Mell, Peter/Grance, Timothy (2011), The NIST denition of cloud computing, NIST special publication, Metzger, Christian/Reitz, Thorsten/Villar, Juan (2011), Cloud Computing: Chancen und Risiken aus technischer und unternehmerischer Sicht, München: Carl Hanser Verlag GmbH & Co. KG, ISBN S. 11.

29 18 3 Cloud Computing werden diese ohne Interaktion genutzt. Aber auch bei einer durch eine Buchung bedingten Interaktion müssen Leistungen zeitnah zur Verfügung stehen, ohne dass der Anbieter eingreifen, bzw. diese freischalten muss Breitband Netzwerkzugang Da beim Cloud Computing viel Daten über das Netz versendet und empfangen werden und alle Ressourcen über das Internet nutzbar sein sollten, wird ein guter Netzanschluss benötigt Ressourcen-Pooling Ressource wie: Rechenleistung, Speicherplatz, Netzwerkbandbreite oder virtuelle Maschinen, seien sie virtuell oder physisch, müssen jederzeit dynamisch zur Verfügung stehen. Sie werden durch eine Technologie wie die Virtualisierung zusammengefasst und dynamisch, bei Bedarf, einem Nutzer zugewiesen oder anderweitig verteilt/genutzt. Durch das Pooling von Ressourcen ist oft der physikalische Standort der Ressourcen transparent und es kann oft nur wenig Einuss darauf genommen werden. Hier bieten manche Anbieter von Cloud-Diensten eine Auswahl von Rechenzentren, deren physikalischen Grenzen nicht überschritten werden, d.h. die Ressourcen nur dort allokiert werden. Handelt es sich bei der Ressource um verwendeten Speicher, verlässt der Inhalt dieses Speichers das Rechenzentrum nicht. Im Speziellen bei Daten kann dies einen enormen Einuss auf den Datenschutz haben (siehe Kapitel 3.5) Schnelle Elastizität Die für den Nutzer unendlich wirkenden Ressourcen müssen sehr schnell zugewiesen und wieder neu verteilt werden können, im Optimalfall passiert das automatisch. Eine Voraussetzung dafür, um eine gute Skalierbarkeit für den Kunden und eine guten Ressourcenausnutzung gewährleisten zu können. Eine Allokation von Ressourcen muss jederzeit und über jeden Zeitraum hinweg möglich sein. D.h. ein Nutzer von Cloud-Services muss sich keine Gedanken machen, wie viel Ressourcen er zu welcher Zeit benötigt. Er hat jederzeit automatisch soviel, wie er benötigt vgl.: Mell/Grance (2011) S vgl.: Mell/Grance (2011) S vgl.: Mell/Grance (2011) S vgl.: Mell/Grance (2011) S. 1.

30 3 Cloud Computing Measured Service Cloud-Systeme kontrollieren, protokollieren und optimieren jederzeit die Ressourcennutzung. Hier können zum Beispiel die Gröÿe des genutzten Speichers, die Anzahl der CPU-Zyklen oder die genutzte Bandbreite protokolliert werden. Dies geschieht nicht nur zur Optimierung, sondern ermöglicht auch eine Ressourcenabhängige Abrechnung der erbrachten Cloud-Dienste Service-Modelle (Mell/Grance, 2011) beschreiben drei Service-Modelle: SaaS, PaaS und IaaS. In diesem Unterkapitel werden diese kurz erläutert und einige Anbieter für die entsprechenden Service-Modelle angeben. Die Service-Modelle beschreiben im Cloud Computing, welche Art von Diensten eine Cloud anbietet. ˆ Software as a Service (SaaS) Vereinfacht beschrieben, wird eine bestimmte Software über das Internet in der Cloud genutzt. Dies hat den Vorteil, dass die Software nicht mehr auf dem Rechner installiert werden muss und von überall zugänglich ist. Auch Dokumente, die mit der Software eventuell erstellt worden sind, sind von überall erreichbar. Die als SaaS angebotene Software wird meist über den installierten Browser bedient. Dadurch wird der genutzte Rechner weitgehend entlastet und ermöglicht auch auf weniger leistungsstarken Geräten ein üssiges Arbeiten. Dabei, wie bei Cloud-Diensten üblich, ist für den Nutzer der Speicher- und Ausführort transparent. Beispiele für SaaS sind: Goodle Docs 36 Microsoft Oce Salesforce 38 ˆ Platform as a Service (PaaS) Bei Platform as a Service werden verschiedene Programmierplattformen für Entwickler angeboten. Dies ermöglicht ein Veröentlichen oder Entwickeln von Software die als Basis die angebotenen Plattformen nutzen. Der Entwickler veröentlicht seine Software in die Cloud und hat automatisch die 35 vgl.: Mell/Grance (2011) S Google, Willkommen bei Google Drive, 37 Microsoft, Microsoft Oce Zusammenarbeit und Kommunikation mit Exchange, SharePoint, Lync aus der Cloud für Unternehmen jeder Gröÿe, de-de/oce365/resources/default.aspx. 38 Salesforce, CRM Software & Online CRM System - Salesforce.com Deutschland,

31 20 3 Cloud Computing nötige Infrastruktur, um die er sich nicht kümmern muss. Kontrolle besteht nur über eigene Anwendungen. Die entwickelte Software nutzt die als Service vorhandenen Schnittstellen in der Cloud für Datenbanken, Reporting, Sicherheit und die Programmiersprachen-Frameworks. 39 Beispiele für PaaS: Facebook Platform 40 Google App Engine 41 Microsoft Azure 42 Salesforce Force.com 43 ˆ Infrastructure as a Service (IaaS) Infrastructure as a Service bietet, wie der Namen schon aussagt, die reine IT-Infrastruktur in der Cloud. Hierzu zählen Speicherplatz in der Cloud, Netzwerke, virtuelle Telefonanlagen oder über das Internet erreichbare Backup-Services. In manchen Fällen werden auch Datenbank-Services als IaaS bezeichnet. Hierbei hat der Nutzer keinerlei Kontrolle über die Cloud- Hardware, aber über z.b. Betriebssysteme, Speicher, Applikationen usw. hat er volle Kontrolle. 44 Beispiele für IaaS: Amazon Elastic Computing Cloud (EC2) 45 Amazon Dynamo 46 Amazon Simple Storage Service (S3) 47 GoGrid 48 Google Big Table 49 Abseits der Denition des NIST tauchen immer andere und unterschiedliche as-a- Service Denitionen auf. Bei einer Komplett-Cloud-Lösung wird von Everythingas-a-Service gesprochen: 39 vgl.: Mell/Grance (2011) S Facebook, Home - Facebook-Entwickler, 41 Google, Google App Engine - Google Developers, 42 Microsoft, Windows Azure: die Cloud-Plattform von Microsoft Cloud-Hosting Cloud- Dienste, 43 Salesforce, Social & Mobile Application Developement Platform - Force.com, force.com. 44 vgl.: Metzger/Reitz/Villar (2011) S Amazon, Amazon Elastic Compute Cloud (Amazon EC2), 46 Amazon, Amazon DynamoDB, 47 Amazon, Amazon Simple Storage Service (Amazon S3), 48 GoGrid, Welcome to GoGrid GoGrid, 49 Chang, F. et al. (2008), Bigtable: A distributed storage system for structured data, ACM Transactions on Computer Systems (TOCS), 26, Nr. 2.

32 3 Cloud Computing 21 ˆ Everything as a Service (XaaS) XaaS geht davon aus, dass alle bisher beschriebenen Modelle miteinander kombiniert und gegebenenfalls ergänzt werden können. D.h., dass eine komplette Applikationslandschaft in die Cloud ausgelagert werden kann von der zugrundeliegenden Infrastruktur über Plattformen und evtl. ergänzende Software. Der Begri XaaS wird oft bei Komplettleistungen im Cloudbereich verwendet. 50 Zu Werbezwecken werden beliebige Dienste mit dem as-a-service ergänzt. Oft lassen sich diese in die vorhandenen Modell-Denitionen eingliedern. Abbildung 3.1 zeigt unter anderem einen Überblick über die bisher beschriebenen Service- Modelle und die hauptsächliche Zielgruppe der Modelle. Abbildung 3.1: Der Cloud-Stack mit den unterschiedlichen Service-Modellen 51 Als normaler Endnutzer verwendet man in der Regel nur SaaS-Dienste. Als Anwendungsentwickler passt PaaS am Besten, da hier bestimmte Plattformen bereitgestellt werden, die benötigt werden. Soll sogar die Netzwerk-Infrastruktur bestimmt werden, müssen IaaS-Dienste genutzt werden. Die unterschiedlichen Modelle bauen aufeinander auf und können in manchen Angeboten verschmelzen oder kombiniert werden, um einen gewissen Dienst zu ermöglichen. Je niedriger das Level, desto mehr Kontrolle hat der Nutzer des Cloud-Dienstes. Allerdings steigt dadurch auch das Arbeitspensum. 50 vgl.: Metzger/Reitz/Villar (2011) S Schuller, Sinclair, SaaS, PaaS, IaaS Dierences, Cloud Diagram & Examples SaaS Blogs, demystifying-the-cloud-where-do-saas-paas-and-other-acronyms-t-in/.

33 22 3 Cloud Computing 3.3. Virtualisierung Die Virtualisierungstechnik stellt die wichtigste Grundlage für die meisten Cloud-Dienste dar, bzw. ist die Technologie, die dies erst ermöglicht. Virtualisierung wird, ähnlich wie bei Cloud Computing, immer wieder anders deniert oder verstanden. Dies liegt auch daran, dass Virtualisierung in vielen Bereichen unterschiedlich zum Einsatz kommt. Metzger/Reitz/Villar (2011) denieren Virtualisierung, passend, wie folgt: Denition 3 (Virtualisierung). Mit Virtualisierung werden die Mittel bezeichnet, die es erlauben - vor allem in der Serverwelt - Ressourcen von Computern zusammen zu fassen bzw. aufzuteilen und Nutzern als Service zur Verfügung zu stellen. 52 Virtualisierung ermöglicht die Einführung einer neuen Abstraktionsebene, losgelöst von spezischer Hardware oder Betriebssystemen. Durch die Abstraktion wird die tatsächliche Hardware vor dem Nutzer verborgen. Dieser erhält eine logische bzw. virtualisierte Zwischenschicht, die auch verschiedene Hardware- Gruppen beinhalten kann. So ist es möglich, jedem Anwender zu vermitteln, er wäre der einzige Nutzer auf dem System. Obwohl es auf verschiedenen Hardware- und Software-Ebenen/Technologien oder Ressourcen aufbaut, erscheint es für den Nutzer wie ein homogenes System. Abbildung 3.2: Beispiele für Virtualisierungsarten 53 Abbildung 3.2 zeigt zwei Beispiele, wie virtualisiert werden kann. Eine genauere Beschreibung weiterer Virtualisierungsmöglichkeiten und -konzepte sind in 52 Metzger/Reitz/Villar (2011) S nach Metzger/Reitz/Villar (2011) S. 16.

34 3 Cloud Computing 23 (Baun/Kunze/Nimis, 2010, S. 7) zu nden. Bei den in der Abbildung gezeigten Beispielen handelt es sich einmal um eine Virtualisierung von Betriebssystemen und Anwendungen mittels Software auf einem bestehenden Betriebssystem und einmal um die Virtualisierung auf Hardware-Ebene, bei der kein Gast- Betriebssystem gebraucht wird. Einige Vor- und Nachteile von Virtualisierung 54 : Vorteile: ˆ Ressourcen-Nutzung Durch ein Zusammenlegen von verschiedenen Servern kann die unterliegende Hardware besser ausgenutzt werden. ˆ Kostensenkung Dadurch, dass die vorhandenen Ressourcen besser ausgenutzt werden, können Kosten in vielen Bereichen wie für die Hardware, für Strom, Kühlung und Raum eingespart werden. ˆ Management Mit guten und ausgereiften Verwaltungstools und durch die Reduktion physischer Rechner sinkt der Managementaufwand. Das Bereitstellen von neuen Servern und Infrastrukturen kann sehr schnell und teils automatisch vorgenommen werden. ˆ Wartung Der Wartungsaufwand sinkt immens durch die Flexibilität von virtuellen Maschinen, die teils im laufenden Betrieb, unbemerkt vom Benutzer, den physischen Rechner wechseln können. Dadurch stellen Hardwarewartungen kein Problem dar und die Dienste können in dieser Zeit weiterlaufen. Aber nicht nur die Hardwarewartung protiert von der Virtualisierung. Auch Technologiewechsel und Softwarewartungen gehen so leichter vonstatten. ˆ Flexibilität Da virtuelle Maschinen in ein paar Dateien abgelegt sind, ist eine Sicherung und Vervielfältigung sehr einfach. Durch sogenannte Snapshots, Abbilder von laufenden VMs, kann jeglicher Systemstand gesichert und jederzeit wieder geladen werden. ˆ Sicherheit Da die virtuellen Maschinen von anderen VMs und dem physischen 54 vgl.: Baun, Christian/Kunze, Marcel/Ludwig, Thomas (2009), Servervirtualisierung, Informatik-Spektrum, 32 ISSN S. 198.

35 24 3 Cloud Computing System isoliert sind, erhöht sich die Sicherheit. Kritische Anwendungen können durch VMs in einer sichereren Umgebung gekapselt werden. ˆ Verfügbarkeit Kommt es zu Problemen beim physischen System, auf dem eine bestimmte VM läuft, kann diese auf einem anderen System neu-gestartet oder übertragen werden und so eine höhere Verfügbarkeit gewährleistet werden. ˆ Kompatibilität Oft existieren sogenannte Legacy-Systeme innerhalb von Unternehmen. Diese können durch die Virtualisierung weiter betrieben werden, auch wenn die moderne Hardware nicht mehr unterstützt wird. ˆ Tests Durch das im Idealfall vereinfachte Management können Testumgebung sehr schnell realisiert werden und so neue Software z.b. auf verschiedenen Infrastrukturen oder Betriebssystemen getestet werden. 55 Nachteile: ˆ Leistung Die Leistung stellt einen Nachteil von Virtualisierung dar. Durch die Umsetzung von Zugrien auf die Hardware besitzen virtuelle Maschinen eine geringere Leistung als eine reale Maschine. Durch moderne Virtualisierungstechnologien und eine immer bessere Unterstützung von Virtualisierung durch neue Hardware liegt die geringere Leistung in einem Bereich von 5-10% und kann somit verschmerzt werden. ˆ Spezielle Hardwareanforderungen Systeme mit speziellen Hardwareanforderungen eignen sich nicht für eine Virtualisierung, da diese oft nicht unterstützt werden können. So z.b. bei Hardwareschlüsseln (dongles) Auslieferungsmodelle Dieses Kapitel beschreibt die unterschiedlichen Liefermodelle von Cloud- Lösungen. Im Gegensatz zu den Service-Modellen (siehe Kapitel 3.2) handelt es sich nicht um die Ebene des Cloud-Dienstes, sondern es wird eher beschrieben 55 vgl.: Baun/Kunze/Ludwig (2009) S vgl.: Baun/Kunze/Ludwig (2009) S. 198.

36 3 Cloud Computing 25 wer Zugri auf die Cloud hat. Nach der NIST Denition von Cloud Computing existieren vier verschiedene Liefermodelle: ˆ Public Cloud Beim Public Cloud-Modell ist der Cloud-Dienst dazu bestimmt, von der Öentlichkeit genutzt zu werden. Sie können von Privatpersonen sowie von beliebigen Unternehmen genutzt werden. Hier unterscheidet Metzger/Reitz/Villar (2011) S. 19 zwischen zwei weiteren Unter-Arten: Exclusive Cloud Bei der Exclusive Cloud kennen sich der Nutzer und der Anbieter des Cloud-Dienstes. Nutzer müssen meist einen Vertrag mit dem Unternehmen eingehen. Daher existieren keine zufälligen Nutzer. Open Cloud Bei Open Cloud-Modellen ist dies nicht der Fall. Der Anbieter und der Nutzer kennen sich vor der Nutzung des Angebots nicht. Die erbrachten Leistungen werden über Service Level Agreements geregelt. ˆ Private Cloud Bei diesem Modell beschränkt sich die Nutzung auf ein einziges Unternehmen. Private Clouds werden oft vom nutzenden Unternehmen selbst oder von einem Anbieter verwaltet. Hier kann, wie bei Public Cloud s, eine Unterteilung stattnden: Exploratory Cloud Ein Cloud-System zum Testen von generellen Cloud-Funktionen bzw. Vor- und Nachteilen sowie situationsbedingtem Verhalten. Die Exploraty Cloud hat meist eine feste Gruppe von Testern und ist, wie der Name schon sagt, nicht für den Produktiveinsatz geeignet. Departmental Cloud Die Departmental Cloud stellt eine Cloud-Lösung für eine Abteilung innerhalb eines Unternehmens dar, die durchaus für den Produktiveinsatz geeignet ist. Sie ist für Abteilungen geeignet, die z.b. weltweit agieren. Enterprise Cloud Bei der Enterprise Cloud handelt es sich um eine Departmental Cloud, die aus einer anderen Unternehmensabteilung stammt. Dies hat unter anderem Vorteile beim Datenschutz, da es feststeht, wo und wie die Daten gespeichert werden. ˆ Community Cloud Community Cloud-Dienste sind oft Dienste, die aus mehreren Private

37 26 3 Cloud Computing Clouds zusammengeschlossen wurden. Diese werden oft von einer Gruppe von Unternehmen mit den gleichen Interessen in Bezug auf diese Dienste verwendet. So teilen sich die entstehenden Kosten auf die mehrere Unternehmen auf, und es ist möglich, ein günstigeres Angebot zu oerieren. Als Anbieter kommt ein Unternehmen dieser Gruppe oder eine dritte Partei in Frage. ˆ Hybrid Cloud Die Hybrid Cloud verbindet mehrere der oben beschriebenen Modelle. Diese bleiben Clouds werden nur genutzt und bleiben bestehen, um so die angebotenen Dienste zu verbinden und neue, darauf basierende Dienste zu ermöglichen. Der Zusammenhang und der Unterschied zwischen den einzelnen Cloud-Arten wird in Abbildung 3.3 verdeutlicht. Abbildung 3.3: Unterschiedliche Cloud-Auslieferungsmodelle Datenschutz in der Cloud Der Datenschutz oder auch die Datensicherheit, welche nicht nur den Missbrauch personenbezogener Daten beinhaltet, sondern auch die Vertraulichkeit und Integrität von Daten, wird oft als gröÿter Kritikpunkt von Cloud Computing aufgeführt. In Deutschland wird dies oft dierenzierter gesehen als im Ausland, da es sich beim deutschen Datenschutzgesetz (Bundesdatenschutzgesetz: BDSG) im internationalen Vergleich um ein strenges Gesetz handelt. Ob es sich um wichtige Forschungs-, Kunden- oder Mitarbeiterdaten handelt, es sind Daten, welche 57 Baun, Christian/Kunze, Marcel/Nimis, Jens/Tai, Stefan; Güther, O./Karl, W./Lienhart, R./ Zeppenfeld, K. (Hrsg.) (2010), Springer Berlin Heidelberg, Informatik im Fokus, ISBN S. 26.

38 3 Cloud Computing 27 für den Fortbestand und wirtschaftlichen Erfolg verantwortlich sind. Es besteht also ein Interesse von der Unternehmensseite, die Daten vor Verlust und vor dem Zugri Dritter zu schützen. Das in Deutschland geltende BDSG erfuhr 2009 die letzte Änderung und ist bewusst sehr wage formuliert, um dem technischen Fortschritt mithalten zu können, sind diese als Ziele formuliert. 58 So heiÿt es in Paragraph 9 des BDSG: Öentliche und nicht-öentliche Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzen, haben die technischen und organisatorischen Maÿnahmen zu treen, die erforderlich sind, um die Ausführung der Vorschriften dieses Gesetzes, insbesondere die in der Anlage zu diesem Gesetz genannten Anforderungen, zu gewährleisten. Erforderlich sind Maÿnahmen nur, wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht. Nimmt man die einfache Denition von Cloud Computing, weiÿ der Nutzer eigentlich nicht, von wo der Cloud-Dienst erbracht wird. So ist es wichtig zu wissen, wo die entsprechenden Daten abgelegt sind. Bei seriösen Anbietern wird angegeben, wo sich die Rechenzentren benden, und im Idealfall können diese ausgewählt werden, bzw. bestimmt werden, welche Rechenzentren die Daten nicht verlassen dürfen. Gerade das Wo ist eine sehr wichtiger Aspekt, da in in anderen Ländern andere Datenschutz Bestimmungen gelten können, die nicht dem BDSG entsprechen und damit eine Speicherung von sensiblen Daten nach deutschem Recht nicht in Frage kommt. Ein weiterer wichtiger Aspekt stellt die Verbindung zu einem Cloud-Dienst dar, da diese anders als bei einem lokalen Server immer über eine Internetverbindung erfolgt und oft nicht verschlüsselt wird. Der letzte Punkt betrit die Datenhaltung, bei der die Cloud-Anbieter meist keine Informationen herausgeben. Ein Kunde eines Cloud- Dienstes kann sich also nicht sicher sein, wie und vor allem wie sicher seine Daten abgelegt sind. 59 Zusammenfassend lässt sich sagen, dass die Kontrolle über die Art der Speicherung, die Verbindung zum Cloud-Dienst und der Speicherort der Daten aus der Hand gegeben werden. Bei lokalen Servern und Diensten besteht eine hohe Wahrscheinlichkeit, sollte es zu einer Verletzung des BDSG kommen, dass dieser bemerkt und aufgedeckt werden kann. Durch die Auslagerung der Daten und Dienste sinkt diese drastisch. Deswegen muss ein Unternehmen bei der Auslagerung von Diensten und Daten in die Cloud sehr sorgfältig einen seriösen Anbieter auswählen, der z.b. Einblick in die geograsche Position seiner Rechenzentren und die Art der Datenlagerung gibt und eine verschlüsselte Verbindung bereitstellt. Aber nicht nur der Anbieter ist wichtig, auch die Auswahl der Daten, welche wirklich ausgelagert werden müssen, z.b. bei einer hybrid-lösung, ist wichtig, damit der Datenschutz und -sicherheit gewährleistet werden kann. 58 vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S. 50.

39 28 3 Cloud Computing 3.6. Vor- und Nachteile Cloud Computing bietet viele Vorteile, von denen viele erst durch die Virtualisierung (siehe Kapitel 3.3) ermöglicht werden. Die Vor- und Nachteile, bzw. die Chancen und Risiken, die Cloud Computing bietet, variieren je nach Service-, Liefermodell, Unternehmensgröÿe und weitere Punkten. Eine detaillierte Auistung nach diesen Kriterien ist in in (Metzger/Reitz/Villar, 2011, S. 29) zu nden. In diesem Kapitel werden in erster Linie die allgemeinen Vorteile und Risiken beschrieben 60. ˆ Risikominimierung und Time-To-Market Das Risiko wird deutlich minimiert, da nicht jedes Projekt eine Vorabinvestition in die Infrastruktur benötigt. Da auÿerdem die Infrastruktur meist nicht betreut werden muss, verringert dies auch die Kosten und den Zeitaufwand. Dies wirkt sich natürlich sehr positiv auf die Time-to-Market aus. 61 ˆ Kosten Durch das Entfallen von Kosten für die Beschaung neuer Hardware, Wartung und den Betrieb können sich Cloud-Lösungen bei immer gewährleisteter Skalierbarkeit als sehr kostengünstig herausstellen. Bei einer komplexen Anwendungslandschaft, bei der eine Vielzahl unterschiedlicher Produkte eingesetzt werden, entfällt zusätzlich der Aufwand, alle Systeme auf dem neusten Stand und Kompatibel zu halten. 62 ˆ Innovationen Da sich der Cloud-Anbieter um die Bereitstellung von neuen Updates kümmert, entfallen hier nicht nur die Kosten für den Aufwand es selbst zu tun, sondern es kann von neuen Features protiert werden. Da sich der Anbieter auch darum kümmern muss, dass die Kompatibilität gewährleistet ist zum früheren Update-Stand und unter den einzelnen Update-Ständen von verschiedenen Lösungen, können neue Features ohne Bedenken genutzt werden. 63 ˆ Support/Service Dadurch, dass sich der Cloud-Anbieter auf die Bereitstellung seiner Cloud- Infrastruktur/Dienste spezialisieren und konzentrieren kann, wirkt sich dies positiv auf den angebotenen Service und Support aus. Da ein Cloud- Anbieter seine Dienste meist mehreren Kunden zur Verfügung stellt, wür- 60 vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S. 39.

40 3 Cloud Computing 29 de ein Ausfall oder eine Sicherheitslücke sich auf alle Kunden niederschlagen. Geschieht dies, würden viele Kunden, ein Vorteil eines On-Demand- Zahlungsmodell, zu einem anderen Anbieter wechseln. Es hat also für den Anbieter höchste Priorität, ein gutes Produkt in Sachen Verfügbarkeit, Sicherheit, Skalierbarkeit und Service zu bieten. 64 ˆ Skalierbarkeit Die Skalierbarkeit stellt einen der Hauptvorteile von Cloud-Computing dar, der hauptsächlich durch den Einsatz von Virtualisierungstechnologien erreicht wird. Cloud-Lösungen bieten oft On-Demand Skalierung an, welche entweder automatisch vonstatten geht bei einer erhöhten Nachfrage oder auf Knopfdruck innerhalb von Sekunden oder Minuten. Den Grad an Skalierung bei klassischen Lösungen zu erreichen, ist oft nicht möglich oder sehr kostenintensiv. 65 Abbildung 3.4: Rechenleistung in klassischem Rechenzentrum 66 Abbildung 3.4 zeigt, wie sich die Rechenleistung in einem klassischen Rechenzentrum verhält. Sie skaliert nicht mit den anstehenden Aufgaben, bzw. mit den benötigten Ressourcen, sondern verhält sich statisch. Das führt dazu, dass ein Rechenzentrum so geplant werden muss, dass es auch bei Spitzen die nötige Leistung bringen kann. Dies hat den Nachteil, dass die vorhandenen Ressourcen nur sehr schlecht ausgelastet werden. Sollte die benötigte Leistung, ob konstant benötigt oder für Spitzenzeiten, einmal steigen, muss das Rechenzentrum teuer aufgerüstet werden. Beim Cloud 64 vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S. 63.

41 30 3 Cloud Computing Computing verhält es sich wie in Abbildung 3.5 gezeigt. Die gelieferte Rechenleistung passt sich immer an den aktuellen Bedarf an. Abbildung 3.5: Rechenleistung bei Cloud Computing 67 ˆ Flexibilität Bei einem eigenen Rechenzentrum sind Anpassungen jeglicher Art mit einer aufwendigen Wartung verbunden. Bei einem Cloud-Dienst sind Modi- kationen oft sehr einfach über ein Web-Interface möglich, bei dem keine Programmierkenntnisse nötig sind. So lassen sich komplexe Systeme, für die normalerweise eine Menge Wissen vorausgesetzt wären, sehr schnell erstellen und Änderungen lassen sich ebenso sehr leicht vollziehen. 68 Die den oben beschriebenen Punkten handelt sich um gewichtige und bedeutsame Vorteile. Allerdings gibt es beim Cloud Computing nicht nur Vorteile, sondern auch mit einhergehende Nachteile, beziehungsweise Risiken, die mit einer richtigen Vorgehensweise sehr gering gehalten werden können. Meist bestehen die Risiken in der Auslagerung der Dienste selbst. Dadurch ist der Kunde darauf angewiesen, dass der Anbieter seine Aufgabe entsprechend erfüllt. Auÿerdem bieten diese Risiken Cloud-Anbietern Aspekte mit denen sie ihr Angebot verbessern und in Vorteile verwandeln können. (Baun/Kunze/Nimis, 2010) beschreibt unter anderem folgende Risiken oder Nachteile beim Cloud Computing: ˆ Verfügbarkeit Die Verfügbarkeit stellt ein eigentlichen Vorteil des Cloud Computings dar, da ein Unternehmen mit dem entsprechenden Know-How sich um diese kümmert und so der Kunde, mit eventuell weniger Wissen in diesem Bereich 67 vgl.: Metzger/Reitz/Villar (2011) S vgl.: Metzger/Reitz/Villar (2011) S. 39.

42 3 Cloud Computing 31 entlastet wird. Kommt es allerdings zu Problemen beim Cloud-Anbieter, z.b. durch eine Sicherheitslücke oder ein Software-Bug, kann sich das sehr schnell auf die Verfügbarkeit auswirken. Selbst bei groÿen Anbietern kann es jederzeit dazu kommen, dass Dienste nicht mehr verfügbar sind. Die Computerwoche 69 fasst die zehn schlimmsten Ausfälle zusammen. Darunter Anbieter, wie Amazon, Google, Microsoft und Salesforce.com. Durch die Nutzung mehrerer Anbietern kann das Risiko verringert werden 70. ˆ Lock-In Durch die Auslegung auf nur einen Anbieter kann es dazu kommen, dass es zu einem Lock-In kommt. D.h., dass es die Kosten für einen Wechsel zu einem Anbieter zu teuer ist und es so sich nicht lohnt zu wechseln, selbst wenn der Anbieter seiner Leistung nur ungenügend nachkommt. Es entsteht eine zu starke Bindung zu diesem speziellen Anbieter. ˆ Vertraulichkeit und Nachvollziehbarkeit Mit der Auswahl eines seriösen Anbieters kann hier im schon im Vorfeld das Risiko drastisch reduziert werden. Allerdings ist auch hier oft vieles nebulös und wenig nachvollziehbar, so ist eine genaue Selektion zu Beginn noch wichtiger werden lässt. Durch eine Verschlüsselung und andere Sicherheitsmechanismen kann hier auch gut vorgebeugt werden. ˆ Engpässe beim Datentransfer Engpässe beim Datentransfer können vor allem beim ersten Umzug in die Cloud vorkommen, da das Übertragen einer groÿen Menge an Daten via Internet oft zu lange dauert. Hier ist es bei vielen Anbietern bereits gängige Praxis, dass Festplatten auf dem Postweg zum Cloud-Anbieter verschickt werden 71. ˆ Fehler in groÿen verteilten Systemen Die entsprechenden Werkzeuge zum Debuggen in verteilten Systemen werden sich, auch durch die Verbreitung von Cloud-Technologien, weiter verbessern und die Entwicklung vorantreiben. 72 ˆ Schnelles Skalieren Um die Zeiten zu verkleinern, welche benötigt werden, um auf gestiegene oder gefallene Anforderungen zu reagieren, werden immer bessere Tech- 69 Computerwoche, Amazon, Microsoft & Google: Die schlimmsten Cloud-Ausfälle - computerwoche.de, 70 vgl.: Baun/Kunze/Nimis (2010) S vgl.: Baun/Kunze/Nimis (2010) S vgl.: Baun/Kunze/Nimis (2010) S. 97.

43 32 3 Cloud Computing nologien und Vorgehensweisen, vor allem mit dem Einsatz von Machine- Learning-Methoden, entwickelt. ˆ Reputation und Haftpicht Durch den Einsatz von Drittanbietern kann hier vorgebeugt werden, z.b. durch und bei dem Einsatz verschlüsselter s. ˆ Software-Lizenzen Mit Software-Lizenzen in der Cloud verhält es sich teils schwierig, da eine Software nicht auf einen physikalischen Rechner gebunden ist, und manche Anbieter ihr Angebot noch nicht angepasst haben oder es nicht wollen. Aber auch hier stellen sich die Anbieter immer mehr darauf ein, dass ihre Software möglicherweise in der Cloud laufen könnte und bieten spezielle Angebote an. Eine Möglichkeit stellt das Pay-per-Use-Prinzip dar Zusammenfassung Bei der Rechenleistung aus der Wolke, existieren verschiedene Arten von Clouds (siehe Kapitel 3.4) und unterschiedliche Servicemodelle (siehe 3.2). Es werden IT- Infrastrukturen auf jeder Ebene und in abstrahierter Form ausgelagert, was vor allem Skalierbarkeit, Flexibilität und das Wegfallen eines Up-Front-Investments mit sich bringt. Das Cloud Computing an sich protiert immens durch den Einsatz von Virtualisierung aller Arten. Die generellen Vorteile gegenüber einem klassischen Rechenzentrum sind in Tabelle 3.1 zusammengefasst und genauer in Kapitel 3.6 beschrieben. Cloud Computing dient als Grundlage für die in Kapitel 4 beschriebene MoSeC-Architektur, welche eben diese beschriebenen Vorteile des Cloud Computings nutzt. Ein weiterer Vorteil, der sich aus einer Auslagerung in die Cloud ergibt, ist die Schonung von Batterieleben von mobilen Geräten, was ein erklärtes Ziel der MoSeC-Architektur darstellt. Viele weiterführende Informationen sind zum Beispiel in (Baun/Kunze/Nimis, 2010), (Armbrust et al., 2010) und/oder (Metzger/Reitz/Villar, 2011) zu nden. 73 vgl.: Baun/Kunze/Nimis (2010) S vgl.: Armbrust, Michael et al. (2010), A view of cloud computing, Communications of the ACM, 53, Nr. 4 S. 53.

44 3 Cloud Computing 33 Vorteil Public Cloud Normales Rechenzentrum Nahezu unendliche On-Demand- Rechenleistung Keine Up-Front-Investments für Cloud Nutzer Abrechnung der exakten Ressourcennutzung in kurzfristigem Zeitraum Skalierbarkeit durch riesige Rechenzentren Höhere Auslastung durch die Bearbeitung von mehreren Aufgaben Vereinfachung von Vorgängen und erhöhte Ressourcenausnutzung durch Virtualisierung Ja Ja Ja Ja Nein Nein Nein normal nicht Ja Abhängig von Unternehmensgröÿe Ja Nein Tabelle 3.1: Vorteile einer Public Cloud 74

45

46 4 Sicherheitsarchitektur Sicherheitsarchitektur Dieses Kapitel beschreibt eine Konzept für Sicherheitsarchitektur aus (Ruebsamen/Reich, 2012) und (Reich, 2013). Auÿerdem wird diese Arbeit in Kapitel in diese Architektur eingeordnet. Als erstes wird die Architektur an sich in Kapitel 4.1 beschrieben, inklusive deren genauen Ziele, die einzelnen Komponenten (siehe Kapitel 4.1.3) und Sicherheitslevels (siehe Kapitel 4.1.2). Abschlieÿend werden in Kapitel 4.2 einige Anwendungsfälle beschrieben und in Kapitel 4.3 wird auf den Datenschutz in der Architektur bzw. im Speziellen auf den Datenschutz im Ergebnis dieser Arbeit eingegangen Mobile Security by Cloud - Architektur Die Mobile Security by Cloud -Architektur, folgend MoSeC genannt, deckt die in Kapitel aufgezeigten Aspekte ab. Abbildung 4.1 zeigt die abstrahierte Idee hinter MoSeC. Die eigentliche Sicherheitsfunktionalität wird, nicht wie in anderen Architekturen (siehe Kapitel 2), in ein Cloud-System verlagert. So können die vollen Vorteile des Cloud Computings (siehe Kapitel 3) genutzt werden. Mobile Device Mobile Device Mobile Mobile Proxy Device Proxy Device Proxy Internet Access Control Abbildung 4.1: Abstrahierte Sicherheitsarchitektur vgl.: Ruebsamen, Thomas/Reich, Christoph (2012), Enhancing Mobile Device Security by Security Level Integration in a Cloud Proxy, In: CLOUD COMPUTING 2012, The Third International Conference on Cloud Computing, GRIDs, and Virtualization, S. 3.

47 36 4 Sicherheitsarchitektur Was einen sehr wichtigen Punkt darstellt, da mobile Endgeräte nicht so belastbar (Akkuleistung) sind und nicht mit der Rechenleistung usw. der Cloud konkurrieren können. Dies ermöglicht Sicherheitsmechanismen zu etablieren, die auf mobilen Endgeräten nicht denkbar wären oder die Akkulaufzeit zu sehr belasten würden. Wie in Abbildung 4.1 gezeigt, ist ein mobiles Gerät über einen gesicherten Kanal mit dem in der Cloud bendlichen Mobile Device Proxy verbunden. Dieser regelt die weitere Verbindung in das Internet. Auÿerdem beinhaltet das Cloud-System eine Komponente, welche den Zugang regelt. Das System besteht also aus dem Benutzer, dem mobilen Endgerät, der Verbindung zum Proxy und dem Backend (den Modulen in der Cloud). Die Gesamtsicherheit des Systems basiert auf diesen einzelnen Bestandteilen. Der Proxy zeichnet Daten auf, die zur Gewährleistung der Sicherheit und System-Integrität genutzt und analysiert werden können Mobile Security Taxonomy In diesem Kapitel werden alle Aspekte einer Cloud-Sicherheitsarchitektur im mobilen Bereich vorgestellt, die beachtet und abgedeckt werden müssen und wie diese in der MoSeC-Architektur behandelt werden. Das Klassikationsschema in Abbildung 4.2 zeigt eine Übersicht über diese Punkte. Mobile Security Taxonomy User Device Communication Channel Backend (Cloud) Technical Configuration Access Point Non-technical Device Properties Encryption Runtime Information Abbildung 4.2: Mobile Security Taxonomy 77 Angefangen beim Nutzer des mobilen Endgeräts, über das Gerät selbst, einer sicheren Verbindung bis zu dem Backend in der Cloud selbst muss alles beachtet 76 Ruebsamen/Reich (2012) S. vgl.:. 77 vgl.: Ruebsamen/Reich (2012) S. 3.

48 4 Sicherheitsarchitektur 37 werden, um eine möglichst hohe Sicherheit und System-Integrität zu gewährleisten: 78 ˆ Benutzer Durch die Portabilität existiert bei mobilen Geräten ein erhöhtes Risiko für Diebstahl oder unautorisierten Zugri. Deswegen stellt die Authentizierung des Nutzers des Geräts einen der wichtigsten Punkte der Sicherheitsarchitektur dar. Besonders wenn auf wichtige Daten zugegrien werden muss, ist es unabdingbar zu wissen, dass es sich tatsächlich um den richtigen Nutzer handelt. Eine einmalige Authentizierung durch eine PIN stellt keine zufriedenstellende Methode dar, um einen Nutzer zu identizieren. Biometrische Mechanismen (Fingerabdruck-Scan, Iris-Scan, Stimm- Analyse, usw.) zählen zu den stärkeren Authentizierungsmethoden und erhöhen die Vertrauenswürdigkeit des Nutzers nach erfolgreicher Identikation um ein Vielfaches. Bei der Authentizierung kann auf technische oder nicht-technische Informationen zurückgegrien werden: Technisch: Die technischen Informationen hängen sehr stark vom Gerät selber ab. Die meisten Geräte unterstützen mittlerweile neben der PIN ein eigenes Benutzerpassword. Eine weitere Möglichkeit stellt die Verwendung von bei Bedarf generierten Einmal-Passwörtern dar. Hierfür existieren unabhängige Hardware Lösungen (in der Gröÿe eines USB-Sticks), die diese Passwörter generieren. Dies ist solange sicher, bis beide Geräte gestohlen werden. Abhängig von der Hardware des Gerätes kann auf unterschiedliche biometrische Informationen zurückgegrien werden. Da biometrische Verfahren meist sicherer als die einfache Passwort- Eingabe sind, kann damit die Vertrauenswürdigkeit des Nutzers um ein Vielfaches erhöht werden und so unter gewissen Umständen der Zugri auf sicherheitsrelevante Daten gewährleistet werden. Weitere technische Informationen, die gesammelt werden können und deren Basis Authentizierungen stattnden können, sind die GPS-Daten. Der Abgleich von GPS-Prolen kann dabei helfen, herauszunden, ob ein Gerät gestohlen wurde. Eine weitere Möglichkeit stellt die implizite Authentizierung dar, z.b. die Tastenanschlagsanalyse und die Authentizierung mittels Web-Interaktion in dieser Arbeit zählen hierzu. Sie haben den Vorteil, dass die Methoden im Hintergrund laufen können. Nicht-technisch: 78 vgl.: Ruebsamen/Reich (2012) S. 3.

49 38 4 Sicherheitsarchitektur Nicht-technische Informationen sind zum Beispiel Information über die Unternehmensstruktur bzw. Organisationsstruktur. Die ermöglicht unter anderem temporäre Mitarbeiter weniger vertrauenswürdig zu behandeln als langjährige Mitarbeiter oder Führungskräfte vertrauenswürdig zu behandeln, damit sie Zugri auf wichtige und evtl. geheime Dienste und Dokumente erhalten. Erst die Kombination von mehreren technischen und nicht-technischen Informationen ermöglicht eine gute und sichere Identikation von Mitarbeitern anhand mehrerer Kriterien. ˆ Endgerät Das mobile Endgerät wird aus technischer Sicht betrachtet und dessen Sicherheit beurteilt. Es existieren in der technischen Sicht unterschiedliche Aspekte, die zu betrachten sind: Konguration: Die Konguration muss überwacht und analysiert werden. Dies beinhaltet z.b. die Betriebssystemversion und den aktuellen Patchstand, aber auch Informationen über aktuell installierte Apps. Dies ermöglicht, eventuelle Sicherheitsrisiken durch Drittanbieter-Software zu identizieren. Geräte-Eigenschaften: Jedes Gerät besitzt meist unterschiedliche Hardware. Z.B. können unterschiedliche Hardwareschnittstellen entweder zur Sicherheit beitragen oder aber auch Angrispunkte bieten. Deswegen ist es wichtig, über die einzelnen Ausstattungen informiert zu sein und diese unterschiedlich zu behandeln. Viele mitgelieferte Sicherheitsmechanismen sind z.b. auch vom Betriebssystem abhängig. Laufzeitinformationen: Die Laufzeitinformationen beinhalten hauptsächlich die Ressourcennutzung wie z.b.: CPU-, RAM- und Akku-Auslastung. Zusätzlich müssen die aktuell laufenden Prozesse und Hintergrund-Services aufgezeichnet werden. In regelmäÿigen Abständen werden die Laufzeitinformation an den Proxy gesendet. Der Cloud-Proxy kann diese Daten zur Sicherheitsanalyse nutzen. Da jeglicher Trac, ob ins Intranet oder ins Internet, über den Proxy geht, können diese Daten auch genutzt werden, ohne dass die Erhebung der Daten das Gerät belasten würde. Via Deep-Packet-Inspection kann verdächtige Kommunikation von Trojanern und Viren entdeckt und verhindert werden. Da es durchaus vorkommen kann, dass die Verbindung zum Proxy abbricht, muss ein

50 4 Sicherheitsarchitektur 39 Gerät nach einer bestimmten Zeit ohne Verbindung als nicht vertrauenswürdig eingestuft werden. ˆ Die Verbindung Was für eine Verbindung zwischen dem mobilen Gerät und dem Cloud- Proxy besteht, stellt einen sehr wichtigen Punkt dar. Allerdings ist die Absicherung nicht immer leicht, da die Kontrolle nicht unbedingt beim Unternehmen selbst liegt. Verbindet sich ein Gerät z.b. in einem öentlichen WLAN zu einem Proxy, muss dies anders eingestuft werden als wenn er sich im Firmeneigenen Netzwerk bendet. Öentlicher Zugang muss grundsätzlich als unsicher betrachtet werden. Nur beim Zugang über einen Access Point, über den alles bekannt ist und der vom Unternehmen selbst kontrolliert wird, kann die maximale Sicherheit gewährleistet werden. Muss eine Verbindung über das Internet aufgebaut werden, reicht das Wissen über einen bekannten Access Point nicht mehr aus. Bei einer Verbindung über mehrere Stationen muss grundsätzlich eine Ende-zu-Ende Verschlüsselung stattnden, oder die Sicherheit ist gefährdet. Es existieren zwei Methoden für eine sichere Verbindung: Virtual Private Networks Mit VPNs kann die maximale Sicherheit gewährleistet werden, da der Trac zwischen zwei Parteien verschlüsselt wird. Selbst wenn es sich um einen unbekannten und öentlichen Access Point handelt, kann eine sichere Verbindung etabliert werden. Die Sicherheit hängt von der verwendeten VPN-Technologie ab. Nachrichtenverschlüsselung Die Nachrichtenverschlüsselung stellt eine Alternative zu den VPNs dar. Hier werden allerdings nur die einzelnen und relevanten Nachrichten verschlüsselt. Der einzige Fall, bei dem eine hohe Sicherheit attestiert werden kann, obwohl die Verbindung nicht verschlüsselt wird, ist eine nur im Unternehmensnetzwerk stattndende Kommunikation. ˆ Cloud-Backend Der letzte Punkt stellt das Cloud-Backend dar. Auch hier müssen Maÿnahmen unternommen werden, um dieses abzusichern und die einzelnen Module (siehe Kapitel 4.1.3) sicher zu gestalten.

51 40 4 Sicherheitsarchitektur Sicherheitslevels Die Sicherheitslevels stellen einen essenziellen Bestandteil von MoSeC dar. Sie ermöglichen eine dierenzierte Behandlung von Diensten und Anwendungen jeglicher Art und in erster Linie eine abgestufte Einschätzung der System- Integrität. Abbildung 4.3 zeigt die existierenden Sicherheitslevels. Die Einstufung des Gesamt-Systems besteht aus der Einschätzung von Teilsystemen wie dem Benutzer, dem Gerät und der Kommunikation. Diesen drei Teilen werden separat auf Basis von kontinuierlichen Einschätzungen ein Sicherheitslevel (von 0 bis 4) zugeordnet. Das Sicherheitslevel für das Gesamtsystem stellt das niedrigste der Teilsysteme dar. Mit der Kombination von klassischen Zugriskontrollkonzepten wie RBAC (Role Based Access Control) lässt sich der Zugang fein abgestuft regeln. Level 4: Highly Secure Level 3: Secure Level 2: Baseline Level 1: Severe Level 0: Critical Abbildung 4.3: Security Levels 79 Folgend sind die unterschiedlichen Sicherheitslevels aus Abbildung 4.3 beschrieben: ˆ Level 0 (Critical) Level 0 stellt das niedrigste Sicherheitslevel dar. Im Falle eines Diebstahls oder bei Verlust des Geräts wird es auf dieses Sicherheitslevel runter gestuft. 79 vgl.: Ruebsamen/Reich (2012) S. 5.

52 4 Sicherheitsarchitektur 41 Der Zugang zum Unternehmensnetzwerk und sicherheitsrelevanten Diensten und Daten wird geblockt. Ein weiterer Schritt stellt das Löschen aller Daten dar. Dies kann der Proxy initialisieren, sollte noch eine Verbindung bestehen. Das weitere Vorgehen hängt vom einzelnen Unternehmen ab. Es ist möglich, das mobile Gerät durch das Blocken aller Kommunikation nutzlos zu machen oder die GPS-/Kamera-/Video-Daten an das Unternehmen zu schicken. Letzteres kann ein Aunden des Geräts und/oder des Diebes ermöglichen. ˆ Level 1 (Severe) Auf Level 1 wird noch davon ausgegangen, dass sich das Gerät im Besitzt des rechtmäÿigen Nutzers bendet. Allerdings wurde durch die Cloud- Sicherheitsdienste herausgefunden, dass ein Sicherheitsverstoÿ stattgefunden hat. Z.B. kann das Intrusion Detection System einen Verstoÿ melden oder der Anti-Virus-Pool erkennt eine Malware-Infektion. Level 1 bedeutet nicht nur, dass es einen Sicherheitsvorfall gegeben hat, er wird auch als kritisch eingestuft. Installiert der Nutzer eine unbekannte App, muss dies nicht unbedingt ein Herunterstufen auf Level 1 bedeuten, auÿer diese App wird als Sicherheitsrisiko eingestuft. Die Kommunikation zu Diensten und Daten wird stark eingeschränkt und die Daten auf dem Gerät bereinigt. ˆ Level 2 (Baseline) Auf Level 2 (Baseline) wurde kein kritisches Sicherheitsrisiko, weder für das Gerät noch für den Kommunikationskanal, entdeckt. Es besteht ein Basiszugri auf Dienste und Daten, und das Gerät ist mit dem Proxy verbunden. Ein Zugri auf sicherheitsrelevante Dienste ist allerdings nicht möglich, da die volle Vertrauenswürdigkeit des Nutzers/des Geräts und der Verbindung nicht garantiert werden kann. Dies kann der Fall sein, wenn der Nutzer das Gerät eingeschaltet hat und noch keine ausreichende starke Authentizierung genutzt hat oder Apps installiert sind, die ein potenzielles Sicherheitsrisiko darstellen. Ist das Gerät über ein öentliches Netzwerk ohne weitergehende Sicherheitsmechanismen (z.b.: VPN) mit dem Cloud Proxy verbunden, wird auch Level 2 angewandt. In Level 2 ist der Zugri auf s, den Kalender und Dokumente ohne Sicherheitsfreigabe möglich. ˆ Level 3 (Secure) Für Level 3 müssen alle Richtlinien gelten, die auch für Level 2 gelten. Zusätzlich wird eine sichere Kommunikation benötigt, und das Gerät muss nach den spezizierten Unternehmensrichtlinien konguriert sein. Letzteres kann zum Beispiel die installierten Anwendungen betreen. Die Authenti- zierung des Nutzers durch starke Methoden ist ebenfalls nötig. In Level 3

53 42 4 Sicherheitsarchitektur ist erstmal der Zugri auf wichtige und gesicherte Dienste und Dokumente möglich, die eine höhere Freigabe als Level 2 benötigen. ˆ Level 4 (Highly Secure) Level 4 stellt die höchste Stufe dar. Hierfür müssen alle Security-Policies ohne Einschränkung erfüllt werden und zusätzliche Sicherheitsmechanismen zur Anwendung kommen. Dies bezieht die Verwendung von biometrischen Authentizierungsmethoden, eine sichere Datenverschlüsselung und eine sichere Verbindung über einen internen Access Point mit ein. Mit Level 4 ist der uneingeschränkte Zugri auf alle Dienste und Dokumente möglich. Natürlich kann der Benutzer nur auf diese zugreifen, wenn er (oder seine Rolle) die nötigen Rechte besitzt. Level-Übergänge Der Wechsel der Sicherheitslevels geschieht nicht linear, d.h. es wird nicht immer von Level 4 in Level 3 und von Level 3 in Level 2 heruntergestuft. Nachfolgend wird beschrieben, wie die Level wechseln und welche Bedingungen dafür eintreten müssen. ˆ Level 0 Level 2 und höher Dieser Fall tritt nur ein, wenn ein mobiles Gerät abhanden kommt und dann wieder aufgefunden wird. Es darf kein Sicherheitslevel über Level 2 erreichen. Um das Gerät wieder für den vollen Gebrauch freizuschalten, muss ein Administrator es gründlich untersuchen oder ein Zurücksetzen vornehmen. ˆ Level 1 Level 2 Mit Level 1 wurde eine Kompromittierung festgestellt. D.h. um wieder auf das Baseline Level zu kommen, muss auch bei diesem Übergang das Gerät einem nicht automatisierten Audit von einem qualizierten Administrator unterzogen werden oder ein volles Zurücksetzen des Geräts initialisiert werden. ˆ Level 2 Level 3 Level 4 Der Wechsel zwischen diesen Sicherheitsstufen passiert automatisch. Hier müssen je nach Anwendungsfall bestimmte Anforderungen erfüllt werden, um Stufen aufzusteigen. Diese Anforderungen bestehen aus Punkten, die die Sicherheit des Geräts oder der Verbindung erhöhen oder/und den Nutzer stärker authentizieren. ˆ Level 2, 3, 4 Level 1 Bei einem Übergang von irgendeinem Level in Level 1 wurde ein kritisches Sicherheitsrisiko festgestellt. In diesem Fall wird der Benutzer

54 4 Sicherheitsarchitektur 43 darüber informiert und sofort in Level 1 versetzt. ˆ Level X Level 0 Wird ein Diebstahl festgestellt oder geht das Gerät verloren, wird das Gerät in Level 0 versetzt. In Kapitel 4.2 (Anwendungsfälle) sind Beispielszenarien beschrieben, die eine Veränderung der Sicherheitsstufen hervorrufen Komponenten Ein Ziel der MoSeC-Architektur besteht darin, so viele Anwendungsszenarien abzudecken wie nur möglich. Dabei ist es irrelevant, ob die Architektur im Kleinen oder bei über 200 Menschen eingesetzt wird. Und unabhängig davon, wie streng die Security Policies aussehen, sie soll funktionieren. Deswegen stellt sich die Architektur im Detail als sehr modular dar. Durch die Anpassung oder das Austauschen von Modulen kann die Architektur auf alle Anwendungsszenarien angepasst werden. Abbildung 4.4: Detaillierter Aufbau der Sicherheitsarchitektur 80 Die in Abbildung 4.4 gezeigte Architektur beinhaltet folgende Komponenten: ˆ Cloud-based Proxy Es existiert für jedes mobile Gerät, welches mit der MoSeC-Architektur geschützt werden soll, ein Cloud-based Proxy. Der Proxy überwacht das mobile 80 To be published in Reich, Christoph (2013), MoSeC (Mobile Security by Cloud) - Cloudbasierender Proxy für mobile Geräte mit Benutzer-Proling für sichere Unternehmensumgebungen, International Journal On Advances in Intelligent Systems,.

55 44 4 Sicherheitsarchitektur Gerät und sammelt die zu dem Gerät anfallenden Daten. Für jedes Protokoll (z.b.:http, SMTP, IMAP), über das kommuniziert wird, existiert ein weiterer transparenter Proxy, der die Daten überwacht. Dies ermöglicht eine schnelle Reaktion, z.b. die Unterbindung oder Einschränkung der Kommunikation auf erkannte Sicherheitsprobleme. Unternehmens-Policies werden durch die Module Policy Enforcement und Mobile Device Management überwacht und durchgesetzt. ˆ Data Bei der Data-Komponente handelt es sich um einen Cloud-Speicher, in dem Daten wie z.b. Dokumente und Kontaktinformationen gesichert werden. Hierbei handelt es sich hauptsächlich um Daten, welche nicht auf dem Gerät selbst gespeichert werden und nur in der Cloud verfügbar sein sollen. Policies und das Authorization & Authentication-Modul regeln den Zugri auf die vorhandenen Daten. Jegliche Daten bekommen eine Sicherheitsstufe zugeordnet, welche die Zugrisbedingungen bestimmt. ˆ Management Center Im Gegensatz zu dem Cloud-based Proxy, für den pro mobiles Gerät eine Instanz existiert, gibt es nur eine Management Center Instanz für mehrere Proxys. Es kontrolliert und steuert die verschiedenen Cloud-Proxy- Instanzen und stellt somit die höchste Instanz der Architektur dar. Das Management Center ermöglicht eine Security-Policy-Verwaltung und die Steuerung der Analyse Pools (siehe unten). Ein weiterer Aufgabenpunkt stellt das Monitoring aller Proxy-Instanzen dar. Die Kommunikation zwischen verschiedenen MoSeC-Management Centern ist denkbar um die Sicherheit durch eine Zusammenarbeit zu verbessern. ˆ Analyse Pools Die Analyse Pools beinhalten verschiedene Komponenten wie Anti-Virusoder IDS-Applikationen. Die Pools können je nach Bedarf skaliert werden und andere Komponenten oder Analyse-Arten beinhalten. Sie benden sich auch in der Cloud und werden durch das Management Center gesteuert bzw. parametrisiert. Die Ergebnisse dieser Pools haben einen enormen Einuss auf die Entscheidungen über die System-Integrität, bzw. den aktuellen Status der Geräte. Sie ermöglichen die Erkennung von Attacken wie Malware, Netzangrien usw.. Im Behavioral Analysis-Pool können biometrische Verfahren zum Einsatz kommen, die das Benutzerverhalten am mobilen Gerät einschätzen. ˆ Mobile Device Agent

56 4 Sicherheitsarchitektur 45 Der Mobile Device Agent ist die einzige Komponente, die sich nicht in der Cloud bendet und direkt auf dem mobilen Gerät platziert ist. Sie stellt für die Cloudarchitektur die Schnittstelle auf das Gerät dar. Diese wird vor allem von dem Mobile Device Management-Modul genutzt. Der Agent soll keine schwergewichtige Anwendung sein, sondern nur die absolut nötigen Aufgaben übernehmen. Zu diesen Aufgaben zählen unter anderem die Übermittlung anfallender Daten, zu prüfende Dokumente und Log-Dateien sowie das Durchsetzen von übermittelten Security-Policies Behavioral Analysis Pool In diesem Kapitel wird der Behavioral Analysis Pool näher beschrieben, bzw. ndet die Einordnung der Arbeit statt in die vorhandene Sicherheitsarchitektur. Dieses Konzept der Benutzerauthentizierung stellt nicht das komplette Behavioral Analysis Pool dar, parallel können weitere Benutzerverhaltens-abhängige Verfahren existieren. Die Daten erhält das Modul aus dem vorangehenden Kapitel beschriebenen Cloud-based Proxy und liefert die Ergebnisse an selbigen zurück. Es wird der Lifecycle des Systems, welches das künstlichen neuronale Netz enthält, beschrieben. Da ein wesentliches Ziel der Sicherheitsarchitektur in der Flexibilität besteht, in so vielen Anwendungsfällen wie möglich zu funktionieren, sind hier unterschiedliche Vorgehensweisen (Szenarien) erläutert. Situationsbedingt kann jedes dieser Szenarien gute Ergebnisse liefern, deshalb muss dies von Anwendungsfall zu Anwendungsfall entschieden werden. Abbildung 4.5 zeigt das Konzept des generellen Lifecycles, nachfolgend sind die einzelnen Zustände und Phasen beschrieben. Abbildung 4.5: ANN Lifecycle 81 Reich (2013).

57 46 4 Sicherheitsarchitektur Data-Collection-Phase In der Data-Collection-Phase ist die Initialisierungsphase, in der die ersten Daten des Nutzers gesammelt werden. In dieser Phase können keine Angaben über die Echtheit des Nutzers gemacht werden und somit keine Ergebnisse geliefert werden. Die Dauer der Phase hängt von Erfahrungswerten ab und muss variierbar sein. Möglich wäre eine Dauer von drei bis sechs Wochen. Ziel der Phase ist es, genug Daten zu sammeln, mit denen ein künstliches neuronales Netz (siehe Kapitel??) aussagekräftige Resultate liefern kann. In diesem Zeitraum muss gewährleistet sein, dass das System gute Daten erhält. D.h., dass nur Daten aufgezeichnet werden, die wirklich vom aktuellen bzw. dem zukünftigen zu authentizierenden Nutzer stammen. Um qualitativ gute Daten zu erhalten und die System-Integrität in diesem Zeitraum zu sichern, kommen mehrere Szenarien oder Möglichkeiten in Frage: ˆ Szenario I: Das Verwenden von starken und nicht transparenten Authentizierungsmethoden für alle Funktionen/Dienste/Applikationen jeglicher Sicherheitslevels. Das garantiert das gröÿte Maÿ an Sicherheit und unverfälschte Lerndaten. Allerdings ist diese Vorgehensweise sehr aufdringlich und die Nutzerakzeptanz dürfte, trotz kurzer Laufzeit, sehr niedrig sein. ˆ Szenario II: Szenario II sieht die Verwendung von starken, nicht transparenten Authentizierungsmethoden nur für Dienste höherer und kritischer Sicherheitslevels vor. Dies garantiert die Sicherheit für wichtige Dienste, allerdings könnte es zu einer Verfälschung der Daten kommen. Qualitativ hochwertige Daten könnten erhalten werden, wenn nur nach der Verwendung starker Authentizierungen aufgezeichnet wird. Das hätte allerdings einen immensen Einuss auf die Dauer der Phase. Die Nutzerakzeptanz dürfte in diesem Fall recht hoch sein, da sich die Vorgehensweise nicht groÿ von klassischen Sicherheitssystemen, die eine PIN-Authentizierung bei kritischen Diensten vorsehen, unterscheidet. ˆ Szenario III: Die dritte Möglichkeit kann die Qualität der Daten nicht garantieren. Hier werden über den bestimmten Zeitraum einfach die Daten aufgezeichnet. Mit dieser Möglichkeit ist nur die Standardsicherheit (über PIN/Muster-Eingabe) möglich.

58 4 Sicherheitsarchitektur 47 Qualitativ schlechte Lerndaten führen nicht zu einem Versagen des Systems. Sie haben nur einen Einuss darauf, wie oft nicht transparente, sichere und aufdringliche Verfahren zum Einsatz kommen. D.h., entsprechen die Daten dem Nutzer, wird weniger oft z.b. eine PIN abgefragt. Entsprechen die Daten jedoch überhaupt nicht dem Nutzer, könnte es bei jeder Dienstnutzung zu einer starken Authentizierung kommen. Irgendwann pendelt sich das System ein und normalisiert sich, da eine Phase eingeplant ist, in der das Netz im laufenden Betrieb (Monitoring-Phase siehe unten) weiter lernt (siehe Subsequent-Learn-Phase unten). Ist der Zeitraum vorbei, geht der Zustand in die Kicko-Learn-Phase über. Natürlich können die Mitarbeiter darauf hingewiesen werden, dass nur sie das Gerät in diesem Zeitraum nutzen sollten, allerdings garantiert dies nicht, dass auch so vorgegangen wird. Kicko-Learn-Phase Unabhängig von der Qualität der Daten aus der Data-Collection-Phase wird in diesem Zustand das neuronale Netz gelernt. Hierfür sind aber nicht nur die Daten des eigentlichen Nutzers nötig, sondern auch negative Daten von anderen Nutzern, da das künstliche neuronale Netz sowohl positive wie auch negative Daten zum Lernen benötigt. Sind keine anderen Daten vorhanden, müssen diese generiert werden. Durch empirische Tests müssen auÿerdem Werte wie der erwünschte Netzfehler und/oder die Anzahl der Lerniterationen herausgefunden werden. Eine höhere Anzahl von Lerniterationen ist normalerweise gleichbedeutend mit immens höherer Gesamtlernzeit. Da das Lernen allerdings in einer Cloud-Umgebung stattndet mit nahezu unendlicher Rechenkraft, kann hier eine Konzentration auf Qualitätsmerkmale stattnden. Ist das Lernen abgeschlossen, wird das Netz für den Einsatz freigeschaltet und geht in die Monitoring-Phase über. Monitoring-Phase In der Monitoring-Phase wird das Netz mit aktuellen Daten des Nutzers parametrisiert und gibt als Resultat, auf Basis der gelernten Daten, eine Einschätzung zurück, ob es sich um den berechtigten Nutzer handelt. Kommt es zu Auälligkeiten bei der Authentizierung durch das künstliche neuronale Netz, kann die MoSeC-Architektur starke Authentizierungsmethoden, wie z.b. Fingerabdruck, Stimme, Irisscan, Gesichtserkennung einsetzen. Da ein Mensch seine Verhaltensweise im Laufe der Zeit ändert, sei es durch äuÿerliche Umstände, hinzugewonnenes Know-How oder andere Ursachen, muss das System auch darauf reagieren können. Hierfür existiert die Subsequent- Learn-Phase (SLP, siehe unten). Es existieren verschiedene Möglichkeiten,

59 48 4 Sicherheitsarchitektur wann von dieser Phase in die SLP übergangen wird. ˆ Szenario I: Das erste Szenario sieht vor, die SLP nach jeder Anwendung einer vertrauenswürdigen Verfahrens zu initialisieren. Danach ist für einen bestimmten Zeitraum relativ sicher, dass es sich um den gewünschten Nutzer handelt. In diesem Fall passt sich das neuronale Netz durch das sofortige Nachlernen schneller an neue Situationen an. Beachtet werden muss auch hier, dass bei jedem Lernen auch negative Lerndaten benötigt werden. ˆ Szenario II: Szenario II ähnelt Szenario I, allerdings wird die SLP nur nach jeder n-ten sicheren und erfolgreichen Authentizierung gestartet. Dieses Vorgehen bietet eine höhere Toleranz für Ausnahmen im Verhalten des Nutzers, aber reagiert dafür nicht so schnell auf neue Verhaltensweisen. Gegenüber Szenario I ist es zudem ressourcenschonender, was allerdings in der Cloud zu vernachlässigen ist. ˆ Szenario III: Diese Vorgehensweise sieht vor, andauernd transparent Lerndaten zu generieren und in festen Intervallen die SLP auszulösen. Gegenüber den ersten zwei Szenarien kann nicht sichergestellt werden, dass qualitativ hochwertige Daten erhalten werden, allerdings sollte dies in der Menge der Daten untergehen. ˆ Szenario IV: Eine andere Möglichkeit stellt das Ignorieren der SLP dar. Wenn die Einsatzzeit auf einen kurzen Zeitraum begrenzt ist, kann ein Verzicht die beste Möglichkeit darstellen. ˆ Szenario V: Manuelles Starten der SLP durch z.b. den Administrator oder nach Identitätssicherstellung. ˆ Szenario VI: In bestimmten Abständen mit zufälligen Samples die SLP initiieren. D.h. nicht alle erhaltenen Daten verwenden, sondern lediglich eine zufällig Anzahl derer. Wichtig ist, dass eine Zurücksetzung durch z.b. einen System-Administrator in die Data-Collection-Phase möglich ist. Welches der beschriebenen Szenarien die besten Ergebnisse liefert, kann in der Praxis abweichen, und von Fall zu Fall kann eine andere Vorgehensweise bessere Ergebnisse liefern.

60 4 Sicherheitsarchitektur 49 Subsequent-Learn-Phase Die Subsequent-Learn-Phase bezeichnet die Phase, in der das bereits gelernte künstliche neuronale Netz mit neuen Daten nachgelernt wird. Dieses Vorgehen soll die Ergebnisse verbessern, da so auf aktuelle Verhaltensänderungen oder Gewohnheiten besser reagiert werden kann bzw. wird. Das Ziel ist es also, dass generelle Verfahren robuster und trotzdem sicher zu gestalten. Auch in dieser Phase kann es Sinn machen, unterschiedlich vorzugehen, um in unterschiedlichen Anwendungsfällen geeignete Ergebnisse zu erzielen: ˆ Szenario I: Diese Vorgehensweise sieht vor, dass alle bisher erhaltenen Daten zum Lernen genutzt werden. Dies hat den Nachteil, dass neue Verhaltensweisen nur gering ins Gewicht fallen. Radikale Veränderungsweisen, die vom richtigen Nutzer ausgehen, müssen von einem System-Administrator abgesegnet werden, bzw. das System aus der Monitoring-Phase in die Data-Collection-Phase zurückgesetzt werden. Es besteht die Gefahr, dass das künstliche neuronale Netz überlerntund so den Vorteil der Reaktion auf neue Dinge verliert. ˆ Szenario II: Die zweite Variante stellt eine agilere dar. Es wird nur mit aktuellen Daten gelernt. Das Netz vergisst das bereits gelernte nicht, lernt die neuen Daten hinzu. Dieses Szenario bietet die beste Reaktion auf Neues, allerdings besteht hier die Gefahr, dass altes Verhalten zu schnell vergessen wird. ˆ Szenario III: Die letzte Vorgehensweise sieht vor, das bestehende Netz vergessen zu lassen und neue und alte Daten in einem gewissen Zeitfenster neu anzulernen. Dies stellt eine Kombination aus den ersten beiden Möglichkeiten dar und bietet 2 Variationspunkte: Die Zeit und wie viel von welchen Daten genutzt werden. Daraus muss das beste Verhältnis aus Erfahrungswerten ermittelt werden. Die Anzahl der Lerndurchgänge muss empirisch ermittelt werden oder das Netz kann solange gelernt werden, bis ein bestimmter gewünschter Netzfehler erreicht wird. Hier kommt es vor allem darauf an wie stark das Netz lernen und auf neue Dinge reagieren soll. Da der Ressourcenverbrauch in der Cloud eher zu vernachlässigen ist, kann auch hier eine Fokussierung auf Qualitätsmerkmale Sinn machen. Sleep-Mode

61 50 4 Sicherheitsarchitektur Der Sleep-Mode stellt einen Zustand dar, indem die Ergebnisse dieses Moduls nicht genutzt werden. D.h. es kommt zu keiner Einschätzung, ob der aktuelle Nutzer der Richtige ist. Essentiell für diesen Modus ist es, dass er nur unter ganz bestimmten Bedingungen genutzt werden kann. Es kann durchaus Sinn machen, dass der Nutzer selber in diesen Modus eintreten kann, zum Beispiel um einer anderen Person das Telefonieren zu erlauben. Wird dieser Modus aktiviert, werden alle Sicherheitsrelevanten Dienste nicht mehr zugänglich und es werden keinerlei Daten mehr für das Netz aufgezeichnet. Das Sicherheitslevel, ab dem die Dienste gesperrt werden, muss System-seitig bestimmt werden. Auÿerdem sollte auf jeden Fall eine zeitliche Begrenzung des Modus stattnden. Diese Begrenzung sollte keine Dauer von über zehn Minuten erhalten. Das Backup-Netz Das Backup-Netz stellt eine zweites paralleles künstliches neuronales Netz dar, welches nicht mit aktuellen Daten parametrisiert wird, um eine Aussage zu treen. Es hat primär das Ziel, einem Überlernen des Netzes entgegenzuwirken, indem es nach einem ausgewählten Zeitraum und bei geeigneter Qualität das richtige ersetzt. Würde es zu einem Überlernen kommen, würde das Ergebnis der Authentizierung, egal auf welchen Daten basierend, fast immer positiv oder fast immer negativ sein. Ein paralleles Netz würde bei einer kürzeren Zeitspanne auch die Deaktivierung der SLP ermöglichen Anwendungsfälle In diesem Kapitel werden Anwendungsfälle oder Angrisszenarien beschrieben und wie sich die Architektur daraufhin verhält. Zu den unterschiedlichen Fällen werden die Sicherheitslevels zum Benutzer (B), dem Gerät (G) und zur Verbindung (V) mitangegeben. Das Gesamtsicherheitslevel ist wie in Kapitel beschrieben immer das Niedrigste der drei. ˆ (B:3 G:3 V:3) (B:0 G:3 V:3) Der Besitzer eines Geräts, welches mit MoSeC gesichert ist, authentiziert sich mit einer PIN und zusätzlich mit einem Nutzernamen und einem extra Passwort. Das Gerät entspricht den generellen Sicherheitsrichtlinien seines Unternehmens. Allerdings hat der Nutzer eine Spiele-Anwendung installiert, die kein direktes Sicherheitsrisiko darstellt, aber für ihren geringen Datenschutz bekannt ist. Die Verbindung zum Proxy wird über UMTS und ein Unternehmes-VPN aufgebaut. Der Benutzer erreicht Sicherheitslevel 3, das

62 4 Sicherheitsarchitektur 51 Gerät Level 3 und die Verbindung ebenfalls Level 3. Daraus folgt die Gesamtsicherheitsstufe mit Stufe 3. Nun wird das Gerät gestohlen. Der Dieb gibt drei mal in Folge ein falschen Benutzernamen und falsches Passwort im Sperrbildschirm ein. Das Gerät meldet diese Verstöÿe an den Cloud-Proxy, welcher Gegenmaÿnahmen, die den gegebenen Richtlinien für gestohlenen Geräte folgen, ausführt. ˆ (B:3 G:4 V:3) (B:3 G:1 V:3) Der Besitzer eines Smartphones authentiziert sich mit einer PIN und zusätzlich mit einem Nutzernamen und einem extra Passwort. Das Gerät ist entspricht den strikten Sicherheitsrichtlinien des Unternehmens. Der Benutzer und die Verbindung benden sich auf Level 3 und das Gerät auf dem Hochsicherheitslevel 4. Der Nutzer installiert nun eine App aus dem Appstore. Diese wird von einem entsprechenden Cloud-Dienst analysiert und das Resultat an den Proxy zurückgegeben. Dieses Resultat ergibt, dass die App einen Trojaner enthält. Der Proxy unternimmt nun Gegenmaÿnahmen, um das Unternehmensnetzwerk zu schützen und das Sicherheitslevel des Geräts wird auf 1 heruntergestuft. ˆ (B:3 G:4 V:3) (B:3 G:2 V:3) Die Vorbedingungen entsprechen denen der ersten zwei Szenarien. Der Nutzer installiert eine unbekannte App. Die Malware-Untersuchung in der Cloud ergibt nichts Negatives. Die Sicherheitsstufe des Geräts wird jedoch trotzdem aus Level 4 auf 2 runter gestuft, um sich vor eventuellen bisher unbekannten Sicherheitslücken der App zu schützen. ˆ (B:3 G:4 V:4) (B:4 G:4 V:4) Der Benutzer hat sich mit Benutzernamen und Passwort authentiziert. Das Gerät entspricht komplett den Security-Policies. Um sich zum Proxy zu verbinden wird ein Unternehmens-internes WLAN und ein VPN genutzt. Von der technologischen Seite aus, ist die volle Sicherheit garantiert und es gibt keine Restriktionen. Der Benutzer will nun auf Dokumente zugreifen, die die Sicherheitsstufe 4 benötigen. Um Zugri zu erhalten authentiziert sich der Nutzer mit einem biometrischen Fingerabdruckscanner. Nach der Authentizierung wird das Gesamtsicherheitslevel auf 4 hochgestuft und die Dokumente können eingesehen werden. ˆ (B:3 G:2 V:3) (B:3 G:3 V:3) Der Benutzer hat sich mit Benutzernamen und Passwort authentiziert. Das Gerät entspricht den normalen Sicherheitsrichtlinien, allerdings hat der Nutzer eine unbekannte App installiert. Um jetzt Zugri auf Dienste, die

63 52 4 Sicherheitsarchitektur eine Freigabe auf Level 3 benötigen, zu bekommen, deinstalliert der Benutzer diese App. Der Proxy registriert die Deinstallation und stuft das Gerätesicherheitslevel hoch und somit auch das Gesamtlevel auf 3. ˆ (B:4 G:4 V:2) (B:4 G:4 V:3) Der Benutzer hat sich mit zusätzlichen biometrischen Verfahren authentiziert. Das Gerät entspricht vollkommen den Sicherheitsrichtlinien. Zur Verbindung zum Proxy wird ein öentlicher Zugang und kein Unternehmens- VPN genutzt. Es werden nur Anwendungsabhängige Mechanismen, wie HTTPS oder IMAPS, verwendet. Der Benutzer will Zugri auf interne Dokumente, die Minimum Level 3 benötigen. Hierfür etabliert er eine VPN- Verbindung, welche ein Heraufstufen auf Level 3 zur Folge hat und bekommt den gewollten Zugri Datenschutz Der Datenschutz in Cloud-Architekturen stellt zur Zeit einen groÿen und viel diskutierten Streitpunkt in der Öentlichkeit dar. Um den Schutz der Nutzerdaten zu gewährleisten, ist dieser Aspekt von groÿer Relevanz und muss von Anfang an in die Architektur einieÿen und transparent vermittelt werden, um das Vertrauen der Nutzer zu gewinnen. ˆ Ein Rechtesystem, welches gewährleistet, dass nur der explizite Nutzer auf seine erhobenen Daten zugreifen kann und eine generelle Verschlüsselung der anfallenden Daten, legt den unverzichtbaren Grundstein für ein Vertrauensverhältnis mit dem Nutzer. ˆ Es muss clientseitig die Möglichkeit existieren, die eigenen Daten einzusehen und ggf. einen unverschlüsselten Zugri seitens der System-Administratoren zu ermöglichen oder zu widerrufen. ˆ Technologiebedingt ist das Speichern von Daten nicht über einen längeren Zeitraum nötig. Einmal gelernte Daten werden gelöscht, da sie sich in das Netz eingelernt haben. Ein Rückschluss auf die ursprünglichen Daten ist danach nicht mehr möglich. Bei dem Einsatz eines Backup-Netzes und eines entsprechenden Ersetzungsalgorithmus beschränkt sich der Zeitraum auf eine Ersetzungsperiode (z.b.: ca. 2-5 Wochen). Lernt dieses Netz andauernd mit, z.b. immer die Daten eines Tages, kann die Dauer immens reduziert werden. Dies hat den Nachteil, dass bei Verlust des neuronalen Netzes die bereits gelernten Informationen nicht wiederherstellbar sind.

64 4 Sicherheitsarchitektur 53 ˆ Ein weiterer wichtiger Punkt ist eine Garantie des Server-Standorts, da je nach Land die gesetzlichen Richtlinien für Datenschutz stark variieren. ˆ Negative Lerndaten könnten von anderen Proxys bezogen werden. Da keinerlei persönliche Daten enthalten sein müssen, können sie vollständig anonymisiert werden. Damit ein System heutzutage eine Chance erhält, müssen alle Vorbehalte der Nutzer schon im Voraus zerstreut werden Zusammenfassung Die MoSeC-Architektur stellt eine Sicherheitsarchitektur für mobile Endgeräte dar, welche versucht, jedem möglichen Angrisszenario entgegenzuwirken. Dabei nutzt sie die Vorteile des Cloud Computings. Die Architektur konzentriert sie sich nicht nur auf einen Aspekt wie Virus-Infektionen und untersucht nicht nur das Gerät selbst, sondern beachtet auch den Benutzer und die Kommunikationsverbindung. Durch die Auslagerung in die Cloud wird versucht, das Gerät selbst so wenig wie möglich zu belasten und die geringen verfügbaren Ressourcen zu umgehen und so auch anspruchsvolle Sicherheitsmaÿnahmen zu ermöglichen. Durch den modularen Aufbau der Architektur lässt sie sich an viele Anwendungsfälle anpassen, sowohl für wenige Personen in einem Hochsicherheitsbereich als auch für viele Personen, bei denen eine geringere Sicherheit benötigt wird. Ein weiterer Punkt, den die Modularität mitbringt, ist der Einsatz von allen möglichen Sicherheits- und Authentizierungsmechanismen. Somit kann der Vorteil aus allen möglichen, für die Situation passenden Methoden gezogen werden. Damit ist MoSeC zukunftssicher, denn auch neue Methoden können einfach integriert werden. So stellt sie auch die perfekte Umgebung für eine Authentizierung mittels Web-Interaktion dar, welche ihren Beitrag zur Sicherheit leisten kann.

65

66 5 Künstliche neuronale Netze Künstliche neuronale Netze Der Begri Künstliche Intelligenz wurde von John McCarthy 1956 während der Dartmoud Conference geprägt. John McCarthy gilt deswegen als Vater des Begris künstliche Intelligenz und deniert den Begri KI wie folgt: Denition 4 (Künstliche Intelligenz). It is the science and engineering of making intelligent machines, especially intelligent computer programs. It is related to the similar task of using computers to understand human intelligence, but AI does not have to conne itself to methods that are biologically observable. 82 Die künstlichen neuronalen Netze stellen eine besondere Art der künstlichen Intelligenz dar, welche nicht nur nach vorher festgelegten Regeln funktioniert, sondern auch auf neue und noch nicht bekannte Szenarien reagieren können. Diese Stärke machen künstliche neuronale Netze zur perfekten Methode für die Analyse der anfallenden Daten. In diesem Kapitel wird die generelle Funktionsweise von dieser Art der KI erklärt und beschrieben sowie die verschiedenen Arten von neuronalen Netzen. Zuerst wird auf die Frage eingegangen, was überhaupt künstliche neuronale Netze sind (Kapitel 5.1), dies beinhaltet auch die Beschreibung von Neuronen (Kapitel 5.1.1). Danach wird in Kapitel 5.2 auf die einzelnen Verbindungsstrukturen und Möglichkeiten eingegangen. In 5.3 wird ein kleines Beispiel erläutert und danach in Kapitel 5.4 auf Lernverfahren für künstliche neuronale Netze eingegangen. Abschlieÿend werden noch die verschiedenen Einsatzgebiete (Kapitel 5.5) und geschichtliche Aspekte (Kapitel 5.6) beschrieben Was sind künstliche neuronale Netze? Künstliche neuronale Netze sind eine Form von künstlicher Intelligenz, die die Konzepte aus der Natur, insbesondere das des menschlichen Gehirns, zu adaptieren versuchen. Ein neuronales Netz besteht aus einer Vielzahl von einzelnen und vernetzten Neuronen Das Neuron Ein einzelnes künstliches Neuron besteht aus mehreren Komponenten seines biologischen Vorbilds. Abbildung 5.1 zeigt die einzelnen Bestandteile: Die Dendriten, den Zellkörper und das Axon. 84 Die Dendriten beschreiben die Eingänge des 82 McCarthy, John (2007), Basic Questions, node1.html. 83 Lippe, Wolfram-Manfred (2007), Soft-Computing: mit Neuronalen Netzen, Fuzzy-Logic und Evolutionären Algorithmen (examen.press), Secaucus, NJ, USA: Springer-Verlag New York, Inc., ISBN S vgl.: Lippe (2007) S. 45.

67 56 5 Künstliche neuronale Netze Abbildung 5.1: Vorstellung eines biologischen Neurons 83 Zellkörpers, und das Axon ist der Ausgang. Das Axon ist mittels Synapsen an die Dendriten eines anderen Zellkörpers verbunden. Eine ausführliche Beschreibung der biologischen Sichtweise wird in (Schöneburg/Hansen/Gawelczyk, 1992, S. 35) beschrieben.(lämmel/cleve, 2008) denieren ein Neuron wie folgt: Denition 5 (Das Neuron). Ein Neuron ist eine Verarbeitungseinheit, die über die gewichteten Verbindungen eingehenden Werte geeignet zusammenfasst [...] und daraus mittels einer Aktivierungsfunktion unter Beachtung eines Schwellenwertes einen Aktivierungszustand ermittelt. Aus dieser Aktivierung bestimmt eine Ausgabefunktion die Ausgabe des Neurons. 85 Hieraus ergeben sich die unterschiedlichen mathematischen Komponenten eines künstlichen Neurons: 86 Eingabevektor Der Eingabevektor beinhaltet alle Eingangswerte, die entweder vom Netzwerk-Eingang stammen oder von anderen Neuronen innerhalb des Netzes. e = Gewichtsvektor Der Gewichtsvektor beinhaltet alle Gewichte der einzelnen Verbindungen zwischen den Neuronen. Jede Verbindung besitzt ein Gewicht. 85 vgl.: Lämmel, U./Cleve, J. (2008), Künstliche Intelligenz, München: Hanser Verlag, ISBN S vgl.: Lippe (2007) S. 46. e 1 e 2. e n

68 5 Künstliche neuronale Netze 57 w = w 1 w 2. w n Aktivierungsfunktion Die Aktivierungsfunktion ist in der Regel eine Summenfunktion, die alle Eingabewerte einer Verbindung mit dem Gewicht der Verbindung multipliziert und die Ergebnisse summiert. f Aktiverung ( x, w) := n x j i j Ausgabefunktion Bei der Ausgabefunktion handelt es sich um eine Funktion, die das Aktivierungspotenzial des Neurons aus dem Ergebnis der Aktivierungsfunktion berechnet. j=1 f Ausgabe (f Aktivierung ) Bei der Ausgabefunktion handelt es sich in der Regel um sigmoide oder auch s-förmige Funktionen, die den Ausgabe-Wertebereich zwischen [0,1] oder [- 1,1] begrenzen. Generell kann hier jegliche Funktion als Ausgabefunktion dienen. In der Praxis werden folgende eingesetzt: ˆ Lineare Funktion mit Schwellenwert Bei linearen Funktionen kommt oft die Identität zum Einsatz, d.h. die Eingabe wird direkt weitergereicht: f(x) = x Des weiteren werden auch lineare Funktionen mit einer Sättigung verwendet, um den Wertebereich zu begrenzen bei Netzen, die mit Wertebereichen [0,1] oder [-1,1] arbeiten. Ausgabefunktion: f(x) = 1, falls x 1+a s s x a, falls a s x < 1+a s 0, sonst Diese Funktion wird durch die Parameter a und s bestimmt. a bildet s 1+a den unteren Schwellenwert, ab dem die Ausgabe gröÿer 0 wird. s bilden den oberen Schwellenwert, ab dem das Ergebnis nur noch 1 wird. Zwischen diesen Schwellenwerten verläuft die Funktion linear, abhängig von den beiden Parametern a und s.

69 58 5 Künstliche neuronale Netze ˆ Binäre Schwellenwertfunktion Die binäre Schwellenwertfunktion stellt die schärfste und einfachste sigmoide Funktion dar. Liegt das Ergebnis der Aktivierungsfunktion über einem Schwellenwert θ, ist die Ausgabe 1, ansonsten 0. Die binäre Schwellenwertfunktion eignet sich allerdings nur bedingt um die Realität abzubilden. Ausgabefunktion: f(x) = 1, x θ 0, sonst ˆ Logistische Funktion Die logistische Funktion ist die am meisten eingesetzte Schwellenwertfunktion. Es gibt Algorithmen zum Lernen von neuronalen Netzen die den Einsatz von logistischen Funktionen oder den Tangens Hyperbolicus voraussetzen. 87 Ausgabefunktion: f(x) = 1 1+e c x Mit dem Parameter c lässt sich die Steilheit der Kurve bestimmen. ˆ Tangens Hyperbolicus Der Tangens Hyperbolicus ist die am zweitmeisten verwendete Schwellenwertfunktion. Allerdings nur wenn im neuronalen Netz ein Wertebereich von [-1,1] eingesetzt wird. Ausgabefunktion: f(x) = tanh(x) Die oben beschriebene Schwellenwert wird auch als bias oder Threshold bezeichnet und kann nicht nur bei der binären Schwellenwertfunktion eingesetzt werden, sondern wird auch bei anderen Verfahren verwendet. Die Wahl der Ausgabefunktion hängt vor allem von der Art des Lernalgorithmus (siehe Kapitel 5.4) ab. Das häug sigmoide Funktionen eingesetzt werden, liegt am verbreiteten Backpropagation-Algorithmus (Siehe Kapitel??). Der Verlauf von sigmoiden Funktionen entspricht meist dem von natürlichen Vorgängen, d.h. es wird ein besseres Resultat bei der Abbildung von natürlichen Vorgängen erzielt. (Schöneburg/Hansen/Gawelczyk, 1992, S. 93f) beschreibt die folgende Vorteile von sigmoiden Funktionen: ˆ Jeder Eingangswert wird zwischen Null und eins abgebildet. ˆ Die Werte, die nahe Null liegen, werden gestreckt durch die Steilheit der Kurve, d.h. sie sind besser dierenzierbar. 87 vgl.: Lämmel/Cleve (2008) S. 198.

70 5 Künstliche neuronale Netze 59 ˆ Extrem hohe oder niedrige Werte landen automatisch nahe Null oder nahe eins. Durch den achen Kurvenverlauf in diesen Bereichen ist die Gröÿe verhältnismäÿig unerheblich. Es existieren auch Neuronen, die einen inneren Zustand besitzen, diese werden zum Beispiel in (Lippe, 2007, S. 47) beschrieben. Zu beachten ist auÿerdem, dass in der Literatur oft die einzelnen Funktionsnamen voneinander abweichen. So heiÿen in (Lippe, 2007) die Funktionen, wie in diesem Dokument beschrieben, in (Lämmel/Cleve, 2008), jedoch existiert noch eine Propagierungsfunktion. Die Funktionsweise entspricht der hier beschriebenen Aktivierungsfunktion. Die Aktivierungsfunktion wird dann zu der hier beschriebenen Ausgabefunktion. Die Propagierungsfunktion wird als Funktion beschrieben, die in den meisten Fällen die Identität weitergibt. Wenn also von der Aktivierung eines Neurons gesprochen wird, ist in den meisten Fällen die Ausgabe des Neurons gemeint Architektur Wie bereits beschrieben, besteht ein künstliches neuronales Netz aus einer Vielzahl von einzelnen Neuronen. Bei der Anzahl der Neuronen sind keinerlei Grenzen nach oben gesetzt. Entscheidend ist neben der Anzahl der Neuronen vor allem die Struktur des Netzes, beziehungsweise die Anordnung der Neuronen. Soll ein Problem mit einem neuronalen Netz gelöst werden, muss eine geeignete Architektur mit einer geeigneten Anzahl von Neuronen gefunden werden. Grundlegend kann man die Neuronen eines Netzes in drei Kategorien einteilen: ˆ Eingabe-Neuron Ein Eingabe-Neuron (Input-Neuron) ist ein Neuron innerhalb eines neuronalen Netzes, zu dem kein anderen Neuron eine Ausgangsverbindung hat. Über diese Neuronen lässt sich das Netz parametrisieren. ˆ Versteckes-Neuron Ein verstecktes Neuron (Hidden-Neuron) ist ein Neuron, welches nach auÿen hin nicht sichtbar ist. Es existieren Verbindungen von anderen Neuronen zu diesem Neuron, und der Ausgang des Neurons ist mit anderen Neuronen verbunden. ˆ Ausgabe-Neuron Der Ausgang eines Ausgabe-Neuron (Output-Neuron) ist nicht mit anderen Neuronen verbunden. Die Aktivierung des Ausgabe-Neurons stellt die Ausgabe bzw. das Ergebnis des Netzes dar.

71 60 5 Künstliche neuronale Netze Abbildung 5.2: Schichten eines künstlichen neuronalen Netzes Alle Neuronen eines Typs werden in Schichten zusammengefasst. Abbildung 5.2 zeigt ein neuronales Netz mit drei Eingangs-Neuronen in der Eingangsschicht (Input-Layer), drei Ausgabe-Neuronen in der Ausgangsschicht (Output-Layer). Bei den gezeigten sechs Hidden-Neurons verhält es sich unterschiedlich. Diese können im Hidden-Layer noch in verschiedene Unterschichten unterteilt werden, deren Verbindungen voneinander abweichen. So muss nicht jedes Neuron mit jedem Neuron der nächsten Schicht verbunden sein (siehe Kapitel 5.2.1). Ein neuronales Netz kann nicht nur grasch, sondern auch als Matrix dargestellt werden (siehe Abbildung 5.3). Diese Abbildung beschränkt sich auf die Darstellung von den Gewichten der Verbindungen. Die Struktur des Netzes ergibt sich durch die Position der Gewichte in der Matrix. Fehlt ein Gewicht an einer bestimmten Stelle in der Matrix, bedeutet dies, dass hier keine Verbindung zwischen den entsprechenden Neuronen existiert. Abbildung 5.3: Matrixdarstellung vom Aufbau eines neuronalen Netzes Rey, Günter D./Beck, Fabian (2008), Neuronale Netz: Eine Einführung, neuronalesnetz.de/downloads/neuronalesnetz_de.pdf S. 12.

72 5 Künstliche neuronale Netze Vernetzungsstrukturen Die Struktur der neuronalen Netze unterscheidet sich vor allem in der Art und Weise, wie einzelne Neuronen miteinander verbunden werden. Bei Netzen, bei denen die Neuronen einer Schicht keine Verbindungen zu vorhergehenden Schichten besitzen, spricht man von sogenannten Feedforward-Netzen (vorwärtsgerichtetes Netz). Diese lassen sich wiederum in drei unterschiedliche Netze unterteilen: 89 ˆ Ebenenweise verbundene Feedforward-Netze In dieser Netzart gibt es nur Verbindungen zwischen den einzelnen Schichten und der nächsten Schicht. ˆ Vollständig verbundene Netze Bei vollständig verbundenen oder auch total verbundenen Netzen ist jedes Neuron einer Schicht mit allen Neuronen der nächsten Schicht verbunden. Bei dem in Abbildung 5.2 gezeigten Netz handelt es sich um ein vollständig verbundenes Feedforward-Netz. ˆ Allgemeine Feedforward-Netze Allgemeine Feedforward-Netze erlauben bei Verbindungen zwischen Neuronen auch das Überspringen von einzelnen Schichten. Diese Verbindungen werden Shortcuts genannt. Wird das Netz, d.h. die einzelnen Gewichte der Verbindungen, als Matrix dargestellt, wird eine obere Dreiecksmatrix erzeugt, in der unterhalb der Diagonalen und in der Diagonalen selbst die Gewichte entweder den Wert Null oder keine Gewichte existieren. Gibt es Verbindungen nicht nur zu nachfolgenden Schichten, wird das Netz rekurrent genannt. Rekurrente Netze können verschiedene rekurrente Verbindungen (Shortcuts) beinhalten: 90 ˆ Direct Feedback Direct Feedback bezeichnet Verbindungen innerhalb eines Netzes, wenn der Ausgang einen Neurons mit dem Eingang des selben Neurons verbunden ist. Direct Feedback-Verbindungen bewirken, dass das Neuron seine Aktivierung selbst hemmt oder verstärkt. Das heiÿt, dass die Aktivierung eher Werte nahe Null oder nahe eins annimmt. In der oben beschriebenen Matrix-Darstellung würden diese Werte in der Diagonalen auftauchen. Abbildung 5.4 zeigt exemplarisch eine solche Verbindung (rot). ˆ Indirect Feedback Indirect Feedback beschreibt Verbindungen, welche von höheren Ebenen 89 vgl.: Lippe (2007) S vgl.: Lippe (2007) S. 53.

73 62 5 Künstliche neuronale Netze Abbildung 5.4: Exemplarische Direct Feedback-Verbindung zu einer niedrigeren Ebenen führen (siehe Abbildung 5.5). Dies wird unter anderem deswegen gemacht, um sich auf gewisse Eingabeneuronen oder Aspekte zu fokussieren und diese zu verstärken. In der Matrixdarstellung würden die Gewichte dieser Verbindungen unter der Diagonalen eingetragen werden. Abbildung 5.5: Exemplarische Indirect Feedback-Verbindung ˆ Lateral Feedback Beim Lateral Feedback handelt es sich um Verbindungen von Neuronen aus einer Schicht (siehe Abbildung 5.6). Hiermit können Winner-Takes-It-All- Netze umgesetzt werden. D.h., dass das Neuron mit der höchsten Aktivierung die anderen Neuronen hemmt und die eigene Aktivierung verstärkt und so ein klares Ergebnis herauskommt. Dies ist nicht auf einzelne Neuronen beschränkt, sondern lässt sich auf Gruppen von Neuronen anwenden. Abbildung 5.6: Exemplarische Lateral Feedback-Verbindung ˆ Vollständig verbundene Netze

74 5 Künstliche neuronale Netze 63 Bei vollständig verbundenen Netzen ist jedes Neuron des Netzes mit allen anderen Neuronen verbunden (siehe Abbildung 5.7). Verbindungen zum eigenen Neuron, wie beim Direct Feedback, sind nicht erlaubt. Diese Netze werden auch Hopeld-Netze genannt. Abbildung 5.7: Exemplarisches Hopeld-Netz mit bidirektionalen Verbindungen Für Feedforward-Netze ist der wahrscheinlich häugste Anwendungsfall die Klassizierung von Daten und Mustern, bzw. die Mustererkennung. Sie werden aber auch zur Prognose und zur Steuerung z.b. in der Robotik eingesetzt. 91 Rekurrente Netze werden häug zur Prognose über die Zukunft und zur Simulation menschlichen Verhaltens genutzt. Ein weiterer Anwendungsfall sind die sogenannten Attraktorennetze, neuronale Netze, welche in Zyklen solange arbeiten, bis ein stabiler Ausgangszustand erreicht worden ist. Diese werden in (Rey/Beck, 2008) genauer beschrieben. Zwei sehr bekannte Netzstrukturen, die sich nicht nur auf die Verbindungen beziehen, sind die Linear Threshold Unit und das Perzeptron: ˆ Linear Threshold Unit Das simpelste künstliche neuronale Netz stellt eine Linear Threshold Unit 92, kurz LTU, oder Adaline, Adaptive linear element dar. Abbildung 5.8 zeigt eine solche LTU, die als UND-Gatter fungiert. In diesem Beispiel sind die Gewichte und der Schwellenwert θ bereits festgelegt, sodass sie die logische UND-Funktion nachbilden können. 93 ˆ Das Perzeptron Eine weitere sehr bekannte Netzstruktur ist das Perzeptron. Beim Perzeptron handelt es sich um ein Feedforward-Netz, das keine versteckten Neuronen besitzt. Es hat also nur eine trainier- oder lernbare Schicht von Gewichten. Jegliche mit einem Perzeptron realisierbare Funktion lässt sich zwar in 91 vgl.: Lämmel/Cleve (2008) S. 227f. 92 Nilsson, N.J. (1998), Articial intelligence: a new synthesis, San Francisco: Morgan Kaufmann. 93 vgl.: Lämmel/Cleve (2008) S. 200f. 94 vgl.: Lämmel/Cleve (2008) S. 200.

75 64 5 Künstliche neuronale Netze Abbildung 5.8: UND-Gatter als LTU 94 endlicher Zeit antrainieren, eine bekannte Grenze stellt jedoch bereits das XOR -Problem dar. 95 Das XOR-Problem, also die Unfähigkeit, die logische XOR-Funktion abzubilden, ist Schuld an einem Dämpfer für die Forschung Ende der 60er-Jahre. Minsky und Papert 96 bewiesen 1969, dass Perzeptrons nicht in der Lage sind, das XOR-Problem zu lösen. Auÿerdem schlossen sie vom Perzeptron auf mehrlagige Netze, ein Fehler, wie sich später herausstellte 97. Aber erst die Erndung des Backpropagation-Algorithmus (siehe Kapitel 5.4.1) 1986 ermöglichte es, künstliche neuronale Netze mit einer beliebigen Anzahl von verdeckter Neuronen-Schichten zu konstruieren. 98 Abbildung 5.9 zeigt ein einfaches Perzeptron mit drei Eingangs- und drei Ausgangsneuronen. Abbildung 5.9: Das Perzeptron 95 vgl.: Lämmel/Cleve (2008) S. 208f. 96 Minsky, Marvin/Papert, Seymor (1969), Perceptron, Cambridge, Massechusetts: MIT Press. 97 Papert, Seymor/Graubard, Stephen R. (Hrsg.) (1998), Verstehen von Dierenzen, In: Probleme der Künstlichen Intelligenz, Eine Grundlagendiskussion, Cambridge, Massechusetts: MIT Press. 98 vgl.: Schöneburg, Eberhard/Hansen, Nikolaus/Gawelczyk, Andreas (1992), Neuronale Netzwerke: Einführung, Überblick und Anwendungsmöglichkeiten, Haar bei München: Marktu.-Technik-Verlag, ISBN S. 72.

76 5 Künstliche neuronale Netze Beispiel In diesem Kapitel wird ein kleines und einfaches Beispiel beschrieben, um die Funktionsweise von künstlichen neuronalen Netzen zu verdeutlichen. Das Ziel ist es, dass von diesem Beispiel auf die Funktionsweise von groÿen und komplexen Netzen geschlossen werden kann. Abbildung 5.10: Mehrschichtiges Feedforward-Netz Um die Funktionsweise zu demonstrieren, ist folgender Anwendungsfall gegeben: In einem Auto ist ein Bremsassistent verbaut, der den Fahrer beim Bremsen unterstützen soll. Als Eingabeparameter erhält das System von im Auto verbauten Sensoren den Abstand zum nächsten Auto und die aktuelle Nässe der Fahrbahn. Abbildung 5.10 zeigt das künstliche neuronale Netz, welches zum Einsatz kommt. Es besitzt zwei Eingangsneuronen in der Eingangsschicht, ein Ausgangsneuron und ein verstecktes Neuron (siehe Kapitel 5.2). Ein Eingangsneuron wird mit dem Abstand zum nächsten Neuron parametrisiert (Neuron 1) und das andere mit der Nässe der Fahrbahn (Neuron 2). Beide Werte werden in den Bereich zwischen 0 und 1 normalisiert. Der Wert 1 bei der Distanz bedeutet, dass das nächste Auto weit entfernt ist bzw. alle Entfernungen über einem gewissen Schwellenwert bekommen den Wert 1 zugeteilt. Je niedriger der Wert ist, desto näher bendet sich das nächste Auto. Ähnlich verhält es sich mit der Nässe. Der Wert 1 bedeutet eine nasse Fahrbahn, je trockener die Fahrbahn ist, desto niedriger wird der Wert bis zu dem Wert 0, einer komplett trockenen Fahrbahn. Die Aktivierung des Ausgangsneurons beschreibt, wie stark gebremst wird, dabei ist der Wert 1 eine sehr starke Bremsung und der Wert 0 keine Bremsung. Die Eingangsneuronen sind mit dem versteckten Neuron verbunden und mit dem Ausgangsneuron. Das versteckte Neuron besitzt eine ausgehende Verbindung zum Ausgangsneuron. Es handelt sich also um ein Feedforward-Netz mit zwei Shortcuts (siehe Kapitel 5.2.1). Das Netz hat bereits auf Basis von Erfahrungswerten gelernt und die Gewichte der Verbindungen angepasst (siehe Kapitel 5.4). Die Gewichte sind in folgender Matrixdarstellung, welche sich aus der Netzstruktur ergibt, eingetragen:

77 66 5 Künstliche neuronale Netze w 13 w 14 w W = 23 w 24 w 34 = 0, 63 2, 75 0, 11 0, 12 3, 2 Das versteckte Neuron(3) und das Ausgangsneuron(4) nutzen als Ausgabefunktion die logistische Funktion (siehe Kapitel Abschnitt: Logistische Funktion). Die Eingangsneuronen(1 und 2) nutzen die Identität der Eingangswerte für Werte zwischen 0 und 1. Das neuronale Netz lässt sich auÿerdem als Formel darstellen, welche sich aus den in Kapitel beschriebenen Funktionen und den oben dargestellten Gewichten herleiten lässt: f(distance, wetness) = f Ausgabe4 (f Aktivierung4 ) = f Ausgabe4 (w 14 f Ausgabe1 (distance) + w 24 f Ausgabe2 (wetness) + w 34 f Ausgabe3 (f Aktiverung3 ) = f Ausgabe4 (w 14 distance + w 24 wetness + w 34 f Ausgabe3 (w 13 distance + w 23 wetness)) 1 = 1 + e c (w 1 14 distance+w 24 wetness+ 1+e c (w 13 distance+w 23 wetness) ) 1 = 1 + e c ( 2,75 distance+0,12 wetness+ 1 1+e c ( 0,63 distance+0,11 wetness) ) Als Parameter c wurde der Wert 3 gewählt. Mit der angegebenen Formel lässt sich die Bremsstärke für alle Werte für Distanz und Nässe berechnen. Beispiel: Ein Auto fährt hinter einem anderen Auto mit einer mittleren Distanz (0,5), während die Straÿe trocken ist (0). Das neuronale Netz ermittelt einen Bremswert von 0,19. Setzt ein starker Regen ein (1) und verringert sich die Distanz zum nächsten Auto (0,25,) wird nun stark abgebremst (0,94). Wird das Netz mit den Werten 0,5 Distanz und 0 für die Nässe parametrisiert, liegen diese Werte an den jeweiligen Eingangsneuronen an. Bei den Eingangsneuron entspricht der Wert der Aktivierung des Neurons. Das dritte und versteckte Neuron nimmt diese zwei Werte und multipliziert sie mit dem dazugehörigen Gewicht (0,5 * w 13 und 1 * w 23 ) und bildet die Summe dieser Werte. Als Ausgangsfunktion kommt die logistische Funktion zum Einsatz, welche den Ausgangswert wieder in den Bereich [0,1] abbildet. Das Ausgangsneuron nimmt die Aktivierung aller anderen Neuronen und multipliziert diese wieder mit dem entsprechenden Gewicht (0,5 * w 14, 1 * w 24 und Ausgabe Neuron 3 * w 34 ) und bildet wiederum die Summe dieser Werte. Das Ergebnis erhält man nach einer wiederholten Anwendung durch die sigmoide Funktion. Da es sich um ein exemplarisches Beispiel handelt, welches nur

78 5 Künstliche neuronale Netze 67 die Funktionsweise verdeutlichen soll, wird bewusst auf die Angabe von konkreten Werten verzichtet Lernverfahren In diesem Kapitel wird beschrieben, was Lernen bei künstlichen neuronalen Netzen bedeutet und welche Arten des Lernens es gibt. Auÿerdem werden die gängigsten und bekanntesten Lernalgorithmen vorgestellt. Das Lernen in neuronalen Netzen wird mit einer Anpassung der Gewichte der einzelnen Verbindungen zwischen den Neuronen assoziiert. Gelernt wird aufgrund von Erfahrungswerten, die zum gewünschten Ergebnis führen. Die existierenden Lernalgorithmen lassen sich in drei Kategorien einteilen: 99 Überwachtes Lernen (supervised learning) Bei überwachtem Lernen wird das neuronale Netz parametrisiert und dann die Dierenz zu den Soll-Ausgabewerten gemessen. Anhand der Dierenz werden dann Schritte unternommen, um das Netz anzupassen bzw. zu lernen. Unüberwachtes Lernen (unsupervised learning) Bei unüberwachtem Lernen lernt das Netz selbst, und es existieren keine Soll-Ausgabewerte, die zu prüfen sind. Hierzu teilt das Netz die Ausgabewerte in unterschiedliche Klassen auf, um davon Schlüsse ziehen zu können. Bestärkendes Lernen (reinforcement learning) Das bestärkende Lernen ähnelt dem überwachten Lernen. Allerdings wird nach einem Durchgang nur unterschieden, ob die Ausgangswerte richtig oder falsch sind. Und danach werden Schritte in die entsprechende Richtung unternommen. Die ersten und einfachsten Lernregeln sind die Hebb- und die Delta-Regel: Hebb-Regel Die Hebb-Regel wurde bereits 1949 vom Psychologen Donald O. Hebb vorgestellt 100. Der Algorithmus wurde wie folgt beschrieben: Denition 6 (Hebb'sche-Lernregel). Wenn ein Axon der Zelle A [...] Zelle B erregt und wiederholt und dauerhaft zur Erzeugung von Aktionspotentialen in Zelle B beiträgt, so resultiert dies in Wachstumsprozessen oder metabolischen Veränderungen in einer oder in beiden Zellen, die bewirken, dass die 99 vgl.: Lippe (2007) S Hebb, Donald O. (1949), The Organization of Behavior, New York.

79 68 5 Künstliche neuronale Netze Ezienz von Zelle A in Bezug auf die Erzeugung eines Aktionspotentials in B gröÿer wird. 101 Vereinfacht beschreibt die Denition, dass ein Gewicht zwischen zwei Neuronen genau dann geändert wird, wenn beide Neuronen aktiv sind. Die daraus abgeleitete Formel für den Betrag der Gewichtsänderung: w ij = ηa i a j Wobei w ij die Gröÿe der Gewichtsänderung ist. η stellt einen vorher bestimmten, positiven Lernparameter dar. a i und a j sind die Ausgangswerte bzw. das Aktivitätslevel beider Neuronen. Ein Nachteil der Hebb-Regel ist, dass es zu einem Überlauf der Gewichte kommen kann, bzw. sie sich zu extrem entwickeln. 102 Delta-Regel Die Delta-Regel ist der Hebb-Regel sehr ähnlich. Allerdings wird hier kein Produkt gebildet, sondern es wird der Soll- und Ist-Wert der Ausgabe verglichen und die Dierenz daraus berechnet. Delta-Regel: w ij = ηδ i a j Wobei δ i die oben beschriebene Dierenz der Soll- und Ist-Ausgabewerte ist, also: δ i = a isoll a iist. η stellt, wie auch bei der Hebb-Regel, einen konstanten Lernparameter dar, durch den beeinusst werden kann, wie stark sich das Lernen auf die Gewichte auswirkt. Die Formel stellt sicher, dass sich die Gewichtsänderung proportional zum Fehler verhält. Auÿerdem werden die Gewichte stärker verändert, die einen gröÿeren Einuss auf den Fehler des Netzes haben. 103 Die oben beschriebenen Lernverfahren zählen zum überwachten Lernen und sind leicht zu verstehen. Allerdings haben sie einen groÿen Nachteil: Sie funktionieren nur in künstlichen neuronalen Netzen, die keine Hidden-Neurons aufweisen. Dieses Problem entsteht daraus, dass kein Fehler ermittelt werden kann für die Hidden-Neuronen, da die Ausgangswerte dieser Neuronen nicht bekannt ist. Im folgenden Kapitel wird der mächtigere Backpropagation-Algorithmus vorgestellt, welcher auch mit versteckten Neuronen funktioniert. 101 Übersetzung nach Kandel, E. R./Schwartz, J. H./Jessel, T. M. (Hrsg.) (1995), Neurowissenschaften. Eine Einführung, Heidelberg: Spektrum Akademischer Verlag S vgl.: Rey/Beck (2008) S vgl.: Rey/Beck (2008) S. 17.

80 5 Künstliche neuronale Netze Der Backpropagation-Algorithmus Abbildung 5.11: Lokales Minimum der Fehlerfunktion 104 Der Backpropagation-Algorithmus wurde bereits 1974 von von Paul Werbos entwickelt. Richtig bekannt wurde er aber erst 1986, als eine Verallgemeinerung der Delta-Regel, von Rumelhart, Hinten und Williams. 105 Heutige Netze greifen meist auf den Backpropagation-Algorithmus oder eine Abwandlung zurück. Der Algorithmus zählt ebenfalls zu den überwachten Lernarten. Im ersten Schritt werden, wie auch bei anderen Lernalgorithmen, die gewollten Lerndaten in das Netz eingespeist, sodass das Netz ein Ergebnis berechnen kann. Auch der zweite Schritt stellt noch nichts Neues dar, hier wird das Ist- mit dem Soll-Ergebnis verglichen. Stellt sich der Fehler als zu groÿ heraus, wird der Fehler durch das Netz schichtenweise, also jede Hidden-Schicht nacheinander bis zur Eingangs-Schicht, zurück propagiert und die Gewichte angepasst. Zur Netzfehlerminimierung wird das Gradientenabstiegsverfahren eingesetzt. Jeder Fehler am Ausgang eines Neurons wird als Funktion der eingehenden Gewichte angesehen. 106 Abbildung 5.11 zeigt eine mögliche Fehlerkurve von nur zwei Gewichten, ein Punkt entspricht im Diagramm einer Einstellung von Gewichten und die Höhe den Wert der Fehlerfunktion. Gesucht werden nun Gewichte, mit denen die Fehlerfunktion ein Minimum annimmt. Dies entspricht dem tiefsten Tal im Schaubild. Da sich der Algorithmus immer auf den steilsten Anstieg konzentriert, kann es schwierig sein das globale Minimum der Funktion zu nden. Es kann passieren, dass nur ein lokales Minimum gefunden wird. Die Form einer Lernkurve kann meist nicht vorausgesagt werden um auf die Lösbarkeit des Problems zu schlieÿen. 107 Eine ausführliche und mathematische Beschreibung des Backpropagation-Algorithmus ist in (Lämmel/Cleve, 2008, S. 218), (Schöneburg/Hansen/Gawelczyk, 1992, S. 90) und in (Rey/Beck, 2008, S. 18) zu nden. 104 Rojas, R. (1996), Neural networks: a systematic introduction, Springer S vgl.: Rey/Beck (2008) S. 18f. 106 vgl.: Lämmel/Cleve (2008) S vgl.: Schöneburg/Hansen/Gawelczyk (1992) S. 99f.

81 70 5 Künstliche neuronale Netze Resilient Backpropagation Der Resilient Backpropagation-Algorithmus, kurz RPROP, ist eine Modikation des klassischen Backpropagation-Algorithmus. RPROP nutzt nicht mehr die Gradienten, sondern nutzt das Vorzeichen des Gradienten. Es werden die Vorzeichen des Gradienten zu einem Zeitpunkt t und zu einem Zeitpunkt t-1 der Fehlerkurve (in Abhängigkeit der Gewichte) S ermittelt. Wenn die Anstiege an beiden Punkten die gleiche Richtung einschlagen, wird eine gröÿere Änderung vorgenommen, welche in diese Richtung geht. Sind beide Vorzeichen und damit die Anstiege unterschiedlich, wird die jeweils letzte Änderung rückgängig gemacht und es kommen kleine Änderungen zum Einsatz. Der RPROP-Algorithmus trennt die Ermittlung von des Gewichtsänderungsbetrags und Vorzeichen. Hier werden zur Bestimmung dies folgenden zwei Formeln eingesetzt. Formel zur Bestimmung des Vorzeichens: w ij (t) = ij (t), falls S(t 1) > 0 und S(t) > 0 ij (t), falls S(t 1) < 0 und S(t) < 0 ij (t 1), falls S(t 1) S(t) < 0 sgn(s(t)) ij (t), sonst Die Formel für den Betrag der Gewichtsänderung: ij (t) = ij (t 1) η +, falls S(t 1) S(t) > 0 ij (t 1) η, falls S(t 1) S(t) < 0 ij (t 1), sonst Für die Parameter η + und η + gilt: 0 < η < 1 < η +. Laut Lämmel/Cleve (2008) werden meist die Werte η = 0, 5 und η + = 1, 2 verwendet Einsatzgebiete von neuronalen Netzen Der Einsatz von künstlichen neuronalen Netzen setzt genau da an, wo die klassische regelbasierte künstliche Intelligenz nicht mehr weiterkommt. Die Gebiete in denen künstliche neuronalen Netze Anwendung nden können, ist schier endlos. Sie reichen vom Versuch, das menschliche Gehirn zu verstehen und abzubilden bis hin zu theoretischen und praktischen Anwendungen in der Industrie. In der Industrie können neuronale Netze in vielen Bereichen eingesetzt werden: vgl.: Lämmel/Cleve (2008) S vgl.: Schöneburg/Hansen/Gawelczyk (1992) S. 179.

82 5 Künstliche neuronale Netze 71 ˆ Luft- und Raumfahrt Fehlertolerante Systeme, Flugüberwachung, Autopiloten, autonome Fluggeräte ˆ Medizin Auswertung von Langzeit-EKGs, Blutdrucküberwachung ˆ Meteorologie Wettervorhersage, Luftbildauswertung ˆ Automobilindustrie akustische Rundlaufdiagnostik von Motoren ˆ Sicherheitstechnik Sprengsto-Detektoren, Personenidentikation ˆ Militär Objekterkennung, Auswertung von Sonarsignalen ˆ Kommunikationstechnik Rauschunterdrückung, Echounterdrückung, Signallter, Spracherkennung, usw. ˆ Banken Aktienprognosen, Kreditrisikoabschätzungen, Datenanalysen, usw. ˆ Post Handschrifterkennung, Postleitzahlerkennung ˆ Werbung Adressatenauswahl für Serienbriefe 5.6. Geschichtliche Aspekte 1943 wurde der erste Grundstein für die künstlichen neuronalen Netze gelegt. W. McCulloch und Walter Pitts beschrieben die ersten Netze und bewiesen, dass schon einfache Netze arithmetische und logische Funktionen lösen konnten. Die ersten neuronalen Netze waren allerdings nicht in der Lage zu lernen. Erst 1949 entwickelte Donald O. Hebb die Hebb'sche Lernregel (siehe Kapitel 5.4). Er ermöglichte damit eine einfache Selbstmodikation von Netzen und legte die Grundlage für die heutigen gängigen Lernverfahren. In den folgenden Jahren wurden mehrere Computer auf Basis künstlicher neuronaler Netze entwickelt, z.b. Mark I perceptron von F. Rosenblatt und C. Wightman am MIT, 1957 und Dieser war bereits in der Lage 20*20 Pixel groÿe Ziern zu erkennen.

83 72 5 Künstliche neuronale Netze 1959 bewies Frank Rosenblatt mit dem Perceptron-Konvergenz-Theorem, dass ein Perzeptron alles lernen kann, was es repräsentieren kann. Es erscheinen viele wissenschaftliche Arbeiten zu unterschiedlichen Arten von künstlichen neuronalen Netzen bis bewiesen M. Minsky und S. Papert in Perceptrons 110, dass ein einlagiges Perzeptron nicht in der Lage ist, viele Probleme zu lösen (z.b. das XOR-Problem). Sie schlussfolgerten allerdings, dass dies für alle Arten von Netzen gelte, stellte sich jedoch später als falsch heraus. Dies hatte als Folge, dass kaum noch im Bereich der neuronalen Netze geforscht wurde. Im Jahre 1986 wurde von Rumelhart, Hinten und Williams mit ihren Veröentlichungen über den Backpropagation-Algorithmus (siehe Kapitel 5.4.1) das Forschungsgebiet wiederbelebt. Mit diesem Verfahren war es möglich, mehrschichtige künstliche neuronale Netze Probleme anzulernen. Danach entwickelte sich das Gebiet explosionsartig Zusammenfassung Künstliche neuronale Netze stellen eine Form der künstlichen Intelligenz dar, welche über klassische Regelbasierte KIs hinausgeht. Sie können auch auf Basis des bereits gelernten ein Resultat auf noch nicht dagewesene Situationen ermitteln. Das biologische Vorbild dieser Netze stellt das menschliche Gehirn dar. Künstliche neuronale Netze lassen sich wie folgt denieren: Denition 7 (Künstliches neuronales Netz). Ein neuronales Netz besteht aus einer Menge von Neuronen, die durch gerichtete und gewichtete Verbindungen miteinander verknüpft sind. Durch die Menge der Verbindungen werden unterschiedliche Architekturen deniert. 112 Die Netze bestehen folglich aus einer Vielzahl von einzelnen und simplen Neuronen, welche durch ihr Zusammenspiel Groÿes ermöglichen. Künstliche neuronale Netze wurden schon erfolgreich in anderen Fällen zum Analysieren von Daten und somit zum Identizieren von Menschen genutzt (siehe Kapitel 2). Durch diese besondere Eignung stellen sie das Mittel der Wahl in dieser Arbeit dar. Verwendet werden mehrschichtige rekurrente neuronale Netze, da diese bekannt sind, auch eventuelle zeitliche Muster identizieren zu können. Die Modellierung des richtigen neuronalen Netzes stellt allerdings einen Prozess von empirischen Versuchen dar und eine genaue Voraussage, welche Netzstruktur die besten Ergebnisse in einer annehmbaren und endlichen Zeit liefert, kann im vornherein nicht getroen werden. Aber nicht nur die unterschiedlichen Netzarchitekturen spielen 110 Minsky/Papert (1969). 111 vgl.: Lippe (2007) S vgl.: Lämmel/Cleve (2008) S. 201.

84 5 Künstliche neuronale Netze 73 eine groÿe Rolle, die Qualität der Lerndaten ist fast noch wichtiger. Als Lernalgorithmus kommt der Resilient Backpropagation-Algorithmus zum Einsatz, welcher auch mit rekurrenten Verbindungen zurecht kommt (siehe Kapitel 5.4.2) und zuverlässiger ist, als das klassische Backpropagation-Verfahren.

85

86 6 Ergebnisse Ergebnisse In diesem Kapitel werden die Ergebnisse und das Vorgehen erklärt. Eine mögliche Einordnung der Arbeit in die in Kapitel 4 beschriebenen MoSeC-Architektur ist in zu nden. Anhand der Web-Interaktion der Nutzer von mobilen Endgeräten sollen die fortlaufenden und robusten Authentizierungsergebnisse der MoSeC-Architektur verbessert werden. Bei der Interaktion mit dem Web können entweder GUI-basierte Aspekte untersucht werden, z.b. wie der Browser genutzt wird oder z.b. das Surfverhalten anhand der besuchten Websites oder Dienste im Netz. Je nach Kriterien, die analysiert werden sollen, müssen die Daten auf dem Gerät direkt oder in der Cloud aufgezeichnet werden. Da ein Ziel der MoSeC-Architektur der möglichst schonende Umgang mit dem Batterieleben des Geräts darstellt, ist das Aufzeichnen auÿerhalb des Gerätes naheliegend, da so das Gerät überhaupt nicht beeinusst wird. Allerdings werden so die Anzahl der Kriterien, die untersucht werden können, eingeschränkt. Naheliegend ist hier die Untersuchung des Netzwerktracs. Als grundlegendes Netzwerkprotokoll, auf dem andere Protokolle basieren und zum Surfen im Internet genutzt wird, stellt HTTP dar. In Kapitel werden die Informationen erläutert, die aus dem Protokoll entnommen und untersucht werden können. Eine zusätzliche Herausforderung stellt die Simplizität des HTTP-Protokolls dar, da es relativ wenig Informationen enthält, die untersucht werden können. Ist es möglich, Menschen anhand des HTTP-Tracs zu identizieren, bzw. zwischen ihnen zu dierenzieren, ist eine Erweiterung auf andere komplexere Protokolle ohne weiteres möglich und bietet zusätzliche Parameter. D.h. ein Hinzuziehen von anderen Datenquellen würde eine Verbesserung der Resultate bedeuten. Im Rahmen der Master-Thesis wurde eine Proof-of-Concept-Anwendung implementiert, um zu untersuchen, ob durch die Analyse der Web-Interaktion die Authentizierungsergebnisse verbessert werden können. In 6.1 werden diese Anwendung und ihre Komponenten und verwendete Software beschrieben. In Kapitel 6.2 werden die Resultate aufgezeigt Proof-of-Concept-Anwendung Ein groÿer Vorteil bei der Analyse des Netzwerktracs stellt die Tatsache dar, dass damit nicht nur mobile Geräte als Clients in Frage kommen, sondern auch alle anderen Geräte, welche über HTTP kommunizieren. Ziel der Anwendung ist es in erster Linie, aufzuzeigen, ob eine Analyse des HTTP-Tracs mittels eines künstlichen neuronalen Netzes einen Vorteil bei der unaufdringlichen und fortlaufenden Autorisierung ergeben kann. Ist dies möglich, kann die MoSeC- Architektur durch eine Eingliederung der Analyse einen wertvollen Mehrwert bei der Autorisierung erwarten. Wie bereits beschrieben, ist ein Hauptbestandteil das

87 76 6 Ergebnisse HTTP-Protokoll. Um hier Daten zu erhalten, wurden eine Reihe von Testpersonen dazu angehalten, über einen eingerichteten Proxy zu surfen. Der Proxy-Log wird dann via SFTP vom Proxy heruntergeladen und entsprechende Werte aus dem Log berechnet. Für jeden im Log auftauchenden Nutzer wird ein separates neuronales Netz angelegt. Da bei der Benutzung durch mehrere Benutzer diese unterschieden werden müssen, müssen sich die Nutzer beim Proxy authentizieren, um die Daten dierenzieren zu können. Dieser Schritt würde im Einsatz in der MoSeC-Architektur entfallen, da dort jedem Gerät ein Proxy zugewiesen ist und so immer feststeht, um welchen Nutzer es sich handeln sollte. Bei Bedarf werden aus den heruntergeladenen Daten Lerndaten generiert, welche in einer.csv-datei abgespeichert werden. Diese Daten müssen die Informationen des entsprechenden Nutzers enthalten und mit negativ Daten von anderen Nutzern aufgefüllt werden, damit das neuronale Netz damit gelernt werden kann. Hierbei wird auf ein 1:1 Verhältnis von eigenen Daten und Fremddaten abgezielt. Die Anwendung kann diese CSV-Dateien einlesen und über die Membrain API die entsprechenden Netze mit den dazugehörigen Lerndaten bis zu einem vorher angegebenen Netzfehler lernen. Dieser Schritt kann beliebig oft wiederholt werden. Nachdem ein Netz den Lernvorgang abgeschlossen hat, kann gegen heruntergeladene Log-Daten eines Nutzers geprüft werden. Dabei kann es sich um Daten eines beliebigen Nutzers und um Daten einer beliebigen Menge handeln. Auch hier werden die Log-Zeilen des gewünschten Nutzers umgewandelt und über die Membrain API das ausgewählte Netz parametrisiert. Die entsprechende Reizung der Ausgangsneuronen, und damit das Resultat wird nach diesem Vorgang ausgeben. Dieser Vorgang stellt den allgemeinen Ablauf dar, die implementierte Anwendung bietet noch andere Funktionen, welche mit den verwendeten Technologien in den folgenden Kapiteln genauer beschrieben werden. Die entsprechende Architektur, die aus diesem Vorgang herausgeht, ist in Abbildung 6.1 dargestellt. In Kapitel wird auf die Clients eingegangen, in auf das HTTP-Protokoll, vorrangig, welche Informationen daraus gewonnen werden können. Danach in wird auf den Proxy-Server eingegangen und welche Informationen dessen Log hergibt. Des weiteren wird noch auf die.net-anwendung an sich eingegangen (Kapitel 6.1.6) und Membrain (Kapitel 6.1.4), die Software zur Modellierung künstlicher neuronaler Netze. Ergänzend wird auf das modellierte und zum Einsatz kommende neuronale Netz in eingegangen Clients Durch die Fokussierung auf HTTP-Übertragungen spielt es keine Rolle, was für Geräte zum Einsatz kommen, Hauptsache sie nutzen HTTP. In diesem Fall waren mehrere Testpersonen für rund 6 Monate über einen Squid-Proxy im Netz un-

88 6 Ergebnisse 77 Abbildung 6.1: Proof-of-Concept Architektur terwegs. Um geeignete Testdaten zu produzieren, mit denen ein neuronales Netz gelernt werden kann, sind auch negative Daten notwendig. Mit negativen Daten sind Daten gemeint, welche nicht zu der spezischen Person gehören, die authentiziert werden soll. In der MoSeC-Architektur würde jedes Gerät seinen eigenen Cloud-Proxy bekommen. Deswegen ist eine Kommunikation der verschiedenen Cloud-Proxys vonnöten, um hier Daten auszutauschen. Bei diesem Austausch können und müssen die Daten anonymisiert werden. Das stellt allerdings kein Problem dar, da es nicht wichtig ist, von wem die Daten ursprünglich stammen, solange sie nicht von der zu authentizierenden Person stammen. In diesem Fall wurde dies simuliert, da jeder Client den gleichen Proxy verwendete. Als Clients kamen verschiedene Notebooks und Desktop-Rechner mit unterschiedlichen Betriebssystemen und Browsern zum Einsatz. Manche Benutzer verwendeten ein Notebook und einen Desktop-Rechner. Die Teilnahme fand auf freiwilliger Basis statt Hypertext Transfer Protocol Das Hypertext Transfer Protocol, kurz HTTP, ist ein statusloses, auf Frageund Antwort-basierendes Protokoll, über welches sich jegliche Dateien (so auch HTML-Seiten) von einem Server abrufen lassen. Es ist in den Standards RFC vgl. ISO Norm 7498

89 78 6 Ergebnisse OSI-Schicht-Nr. OSI-Schicht Protokoll-Bsp. 7 Anwendung HTTP, HTTPS, SMTP, 6 Darstellung POP, Telnet 5 Sitzung 4 Transport UDP, TCP 3 Vermittlung IP 2 Sicherung Ethernet, Token Ring 1 Bitübertragung Tabelle 6.1: ISO/OSI-Schichtenmodell 113 (HTTP 1.0) 114 und RFC2616 (HTTP 1.1) 115 deniert worden. Im ISO-OSI- Schichtenmodell (siehe Tabelle 6.1) ist HTTP auf Ebene 5-7 angeordnet und in der Anwendungsschicht im TCP/IP-Modell. Als unterliegendes Transport- Protokoll wird meist TCP verwendet. Da die HTTP-Kommunikation vom Proxy aufgezeichnet wird, können diese Informationen analysiert werden. Da es sich um ein hinlänglich bekanntes Protokoll handelt, wird hier nicht genauer darauf eingegangen. Nähere Informationen sind z.b. in (Gourley/Totty/Sayer, 2002) oder in den oben angegebenen Standards zu nden. Host: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/ Firefox/12.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*\ *;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Proxy-Connection: keep-alive Proxy-Authorization: Basic c3byb2jzddpzchjvynn0 If-None-Match: W/%224a0ae815acf16352cb350fc379235ef6%22 HTTP/ Not Modified Date: Mon, 30 Apr :11:38 GMT Content-Type: text/html; charset=utf-8 Expires: Mon, 30 Apr :16:38 GMT ETag: W/%224a0ae815acf16352cb350fc379235ef6%22 Age: 168 X-Cache: HIT from webproxy X-Cache-Lookup: HIT from webproxy:8080 Via: 1.0 webproxy:8080 (squid/2.7.stable7) Connection: keep-alive Proxy-Connection: keep-alive Abbildung 6.2: HTTP-Header Beispiel Für diese Arbeit sind vor allem die Daten interessant, welche aus dem HTTP- Header ausgelesen und analysiert werden können. Abbildung 6.2 zeigt einen Beispiel-HTTP-Header, der vom Proxy aufgezeichnet wurde und das Ergebnis einer Anfrage der Website darstellt. Wie gerade beschrieben, erkennt man die angefragte URL in der ersten Zeile. In der Zeile 2 erkennt man den genutzten Browser (Firefox 12) und die genutzte Browser-Engine (Gecko). Auÿerdem ist das Client-Betriebssystem eingetragen (Windows NT 6.1, entspricht 114 Berners-Lee, et al. (1996), Hypertext Transfer Protocol HTTP/1.0 (IETF RFC 1945), Mai Fielding, et al. (1999), Hypertext Transfer Protocol HTTP/1.1 (IETF RFC 2616), Juni 1999.

90 6 Ergebnisse 79 in diesem Fall Windows 7). Eine weitere verwertbare Information stellt der Zeitpunkt der Anfrage dar (Montag, 30. April 2012 um 11:16:38 GMT). Auch wenn der HTTP-Header weitere Informationen hergibt, sind diese jedoch weniger relevant für weitere Analysen, da sie keine Auskünfte über das Nutzerverhalten geben. Die angegeben Informationen können je nach genutztem Browser, Betriebssystem und unterschiedlicher HTTP-Nachricht abweichen oder in einer anderen Reihenfolge eingetragen sein Squid-Proxy Squid 116 ist ein Proxy, der unter GNU GPL steht. Unterstützt werden unter anderem HTTP, HTTPS und FTP. Auÿerdem verfügt er über die Möglichkeit, auch als Proxy-Cache zu fungieren und so Websites zu beschleunigen und die Serverlast zu reduzieren. Squid basiert auf dem im Jahre 1990 entwickelten Harvest Cache 117 und ist eines von zwei Projektabspaltungen. Die zweite Abspaltung stellt die kommerzielle Variante NetCache 118 von NetApp dar. Für die Tests lief der Squid-Proxy auf einem Ubuntu-Server. Der Proxy wurde so konguriert, dass sich Nutzer authentizieren müssen und dass er jegliche HTTP-Kommunikation aufzeichnet. Die Authentizierung ist hier nötig, da für die Entwicklung und die Tests sichergestellt werden musste, welche Nutzer welcher ist. Könnte dies nicht sichergestellt werden, wäre eine korrekte Entwicklung nicht möglich, da sie auf falschen Daten vonstatten gegangen wäre. In der MoSeC-Architektur wäre die separate Authentizierung mit hoher Wahrscheinlichkeit nicht nötig, da jeder Nutzer eine eigenen Proxy-Instanz besitzt und er somit nicht von anderen Nutzern verwendet wird. Sollte dies doch der Fall sein, authentiziert sich der Nutzer ohnehin beim Cloud-Proxy, und somit wäre auch hier eine separate Authentizierung unnötig fhf-home151.fhf-home.fh-furtwangen.de /Apr/2012:13:14: /Apr/2012:11:14: Host:%20www.heise.de%0D%0AUser-Agent:%20Mozilla/5.0%20(Windows%20NT%206.1;%20WOW64;%20rv:12.0) %20Gecko/ %20Firefox/12.0%0D%0AAccept:%20text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8%0d%0 AAccept-Language:%20de-de,de;q=0.8,en-us;q=0.5,en;q=0.3%0D%0AAccept-Encoding:%20gzip,%20deflate%0D%0ADNT:%201%0D%0AProxy- Connection:%20keep-alive%0D%0AProxy-Authorization:%20Basic%20c3Byb2JzdDpzcHJvYnN0%0D%0AIf-None-Match:%20W/%224 a0ae815acf16352cb350fc379235ef6%22%0d%0a HTTP/1.0%20304%20Not%20Modified%0D%0ADate:%20Mon,%2030%20Apr%202012%2011:11:38%20 GMT%0D%0AContent-Type:%20text/html;%20charset=utf-8%0D%0AExpires:%20Mon,%2030%20Apr%202012%2011:16:38%20GMT%0D%0AETag:%20W /%224a0ae815acf16352cb350fc379235ef6%22%0D%0AAge:%20168%0D%0AX-Cache:%20HIT%20from%20webproxy%0D%0AX-Cache-Lookup:%20HIT%20 from%20webproxy:8080%0d%0avia:%201.0%20webproxy:8080%20(squid/2.7.stable7)%0d%0aconnection:%20keep-alive%0d%0aproxy- Connection:%20keep-alive%0D%0A%0D sprobst 304 TCP_IMS_HIT NONE text/html GET / Abbildung 6.3: Beispiel Log-Zeile des Squid-Logs Abbildung 6.3 zeigt, wie eine Log-Zeile aussieht. Welche Daten der Log allgemein enthält, ist in Tabelle 6.2 ersichtlich. Daten, die älter als einen Tag sind, 116 Squid Software Foundation, squid : Optimising Web Delivery, Mitchell, Graham, The Harvest Cache: A Heirarchical Internet Object Cache suited to HTTP, NetApp, NetApp - Netzwerkspeicher, Cloud Computing, Big Data, Virtualisierung, Storage- Ezienz,

91 80 6 Ergebnisse werden komprimiert und müssen beim Herunterladen zum Analysieren wieder dekomprimiert werden. Nr. Information Beispiel 1 Client Quell-IP Adresse Client FQDN fhf-home151.fhfhome.fhfurtwangen.de 3 Client Quell-Port Server IP-Adresse oder Peer-Name 5 Lokale IP-Adresse Lokale Port-Nummer 80 7 Ausgehende IP-Adresse des Proxys Zeit in Sekunden seit Millisekunden Lokale Zeit 30/Apr/2012:13:14: GMT-Zeit 30/Apr/2012:11:14: Antwort Zeit in ms 2 13 Anfrage-Header Siehe HTTP-Header 14 Antwort-Header Siehe HTTP-Header 15 Benutzername bei Autorisierung sprobst 16 HTTP-Status Code Squid Anfrage Status 18 Squid Hierarchie Status NONE DEFAULT_PARENT 19 MIME content type text/html 20 Anfrageart GET 21 Angefragte URL 22 Angefragter URL-Pfad ohne Hostname \ 23 Protokoll Version Log-String von einer externen ACL 25 Antwort-Gröÿe Antwort-Gröÿe inklusive HTTP-Header Anfrage-+Antwort-Gröÿe inklusive 807 HTTP-Header 28 Einzigartige Sequenz-Nummer pro Log- Eintrag 108 Tabelle 6.2: Squid Log Informationen vgl.: squid-cache.org, Squid 2.6.STABLE21 Conguration File: logformat, squid-cache.org/versions/v2/2.6/cfgman/logformat.html

92 6 Ergebnisse Membrain Bei Membrain 120 handelt es sich um eine Software, welche für die Modellierung und Simulation von künstlichen neuronalen Netzen eingesetzt wird. Für die nichtkommerzielle Nutzung ist die Verwendung kostenlos. Entwickelt wurde es von Thomas Jetter. Abbildung 6.4 zeigt den visuellen Editor von Membrain. Für den Einsatz in dieser Architektur bietet Membrain wertvolle Funktionen, unabhängig von der visuellen Erstellung der neuronalen Netze. Die Lerndaten (Lessons), bestehend aus mehreren Patterns, also den zu lernenden Eingangsneuronen-Werte plus den dazugehörigen Soll-Ausgangswerten, lassen sich aus CSV-Dateien importieren und exportieren. Das wichtigste Feature stellt allerdings die C++ API dar, mit der sich neuronale Netze erstellen, laden, lernen und parametrisieren lassen. Und somit fast alle Funktionen, die auch über die grasche Oberäche möglich sind. Da in diesem Fall mittels C# und.net eine Anwendung implementiert wurde, wurde ein entsprechender C# Wrapper implementiert, um auf die C++-DLL zugreifen zu können. Membrain bietet zwar auch einen entsprechenden Wrapper an, herunterladbar unter allerdings entsprach diese in der damaligen Version nicht den Wünschen des Autors und wurde deshalb angepasst. Für einen Einsatz unter Java bietet Membrain auch einen JNI-Wrapper an. Membrain hat von Haus aus verschiedenen Lernalgorithmen integriert, von denen in dieser Arbeit der RPROP-Algorithmus (siehe Kapitel 5.4.2) verwendet wurde. Die Systemanforderungen sind sehr moderat mit einer 1 GHz CPU, 256 MB RAM und 20 MB Festplattenspeicher unter einem Windows (2000 aufwärts) Betriebssystem. Weitere Informationen über die Systemvoraussetzungen, den Membrain DLLs, den angebotenen Lernalgorithmen, aber auch weiteren Features, wie der automatischen Code-Generierung, der Membrain-eigenen objektorientierten Scriptsprache AngelScript usw. sind auf der Website von Membrain 121 abrufbar Das künstliche neuronale Netz Verwendet wurde das künstliche neuronale Netz (siehe Kapitel??), welches in Abbildung 6.5 dargestellt ist. Es besitzt 192 Neuronen, davon zehn Eingangs- Neuronen und zwei Ausgangs-Neuronen. Die restlichen 180 benden sich in drei versteckten Schichten mit jeweils 60 Neuronen. Es besitzt auÿerdem über 8040 Verbindungen. Das Netz weist alle Merkmale eines vollständig verbundenen Feedforward-Netzes auf, d.h. alle Neuronen einer Schicht sind mit allen Neuronen 120 Jetter, Thomas, MemBrain Neuronale Netze Editor und Simulator, membrain-nn.de. 121 Jetter, Thomas, MemBrain Neuronale Netze Editor und Simulator, membrain-nn.de/german/details_de.htm.

93 82 6 Ergebnisse Abbildung 6.4: Membrain-Editor der folgenden Schicht verbunden. Hierfür sind 7920 Verbindungen vonnöten. Allerdings handelt es sich bei gezeigtem und beschriebenen Netz um keines dieser Art, da die zwei Ausgangs-Neuronen rekurrente Verbindungen zu jedem Neuron in der ersten verdeckten Schicht besitzt. Hierfür werden die restlichen 120 Verbindungen gebraucht. Dies geschieht um eventuelle geringe zeitliche Muster erkennen zu können. Das beschriebene künstliche neuronale Netz wurde mit der in gezeigten Software, Membrain, modelliert. Jeder Nutzer des Proxys erhält ein eigenes Netz der oben beschriebenen Architektur. Diese werden im Membrain- Format.mbn gespeichert. Abbildung 6.5: Das künstliche neuronale Netz Im folgenden Abschnitt werden die Eingangsparameter für das Netz erläutert. Jeder dieser Parameter stellt einen Wert zwischen null und eins dar. Die Werte werden aus dem Proxy-Log von der implementierten Anwendung berechnet. Handelt es sich um Lerndaten werden diese in einer CSV-Datei abgespeichert und

94 6 Ergebnisse 83 bei Bedarf über die Membrain API gelernt. Bei Daten, die es zu überprüfen gilt (also die Simulation eines Authentizierungsvorgangs), werden die Daten umgewandelt und direkt über die Membrain API dem ausgewählten Netz eingespeist. Als Grundlage dienen alle Daten, welche der Proxy aufzeichnet. Dies entspricht den Daten aus Tabelle 6.2. Nicht alle Daten eignen sich direkt zur Analyse. Teils geben sie keinen oder keinen verlässlichen Aufschluss über das Nutzerverhalten oder es müssen erst aussagekräftigere Werte aus diesen Daten berechnet werden. Die nachfolgend beschriebenen Parameter können erweitert werden, wenn neue Daten andere Charakteristika bieten. Jede Log-Zeile entspricht einem Set von Eingangswerten. Momentan handelt es sich um zehn unterschiedliche Werte: 1. Aufgerufene URL Aus der vom Client angefragten URL wird ein Wert berechnet als erster Parameter für das Netz. Für diesen Wert wird nicht die gesamte URL analysiert. Es wird nur der Host der aktuellen Website betrachtet. Ein anderes Vorgehen würde bei derselben Website zu einer zu groÿen Streuung von unterschiedlichen Werten führen. Bei statischen Websites stellt dies eher ein kleines Problem darstellen, allerdings bei Websites mit dynamischen Inhalten wie bei Nachrichtenseiten oder in Foren (z.b. bei der Erstellung neuer Beiträge), würde dies kritisch und zu einem nicht analysierbaren Datensalat führen. 2. Anzahl der Aufrufe einer URL Als zweiten Parameter geht ein, wie oft ein Host durchschnittlich an einem Tag aufgerufen wurde. Dieser Wert wird bis zu einem Maximum von 150 Aufrufen/Tag berechnet. Dies ermöglicht es, eindeutige Favoriten und eher seltene, aber vielleicht konstante Aufrufe eines Nutzers zu identizieren. 3. Berechneter Wert aus den letzten fünf Websites Um Muster im Verhalten eines Nutzers zu identizieren, welche die Reihenfolge der aufgerufenen Seiten betrit, wird ein Wert aus den letzten fünf angefragten Seiten berechnet (Die Zahl 5 ist ein empirisch ermittelte Zahl, könnte aber von Fall zu Fall angepasst werden). Dieser Wert entspricht den Parametern sechs bis zehn, allerdings stellt er einen kompakteren und nicht so spezischen Wert dar. 4. Uhrzeit Als vierter Parameter iest der Zeitpunkt des Seitenaufrufs ein. 5. Durchschnittliche Zeitspanne Für diesen Wert wird der erste Aufruf einer Website an einem Tag und der letzte eines Tages genommen und daraus die Zeitspanne berechnet.

95 84 6 Ergebnisse Die letzten fünf Websites Die Parameter 6. bis 10. sind für die letzten fünf aufgerufenen Websites reserviert. Ähnlich dem dritten Parameter sollen damit zeitlich abhängiges Verhalten in der Reihenfolge bestimmter Aufrufe erkannt werden. Alle Parameter können einen Wert gröÿer 0 annehmen. Deswegen werden diese auf den Wertebereich zwischen null und eins normalisiert. Dieser Vorgang geschieht mit folgender einfacher Formel: normalisierter Wert = x Min Max Min Wobei x, dem umzuwandelnden Wert, Min dem kleinsten Wert und Max dem gröÿten Wert, den x annehmen kann, entspricht. Anfänglich wurden noch aus dem HTTP-Header extrahierte Werte für das Client- Betriebssystem und -Browser genutzt. Dies führt im kleineren Rahmen zu sehr guten Ergebnissen. Allerdings ändern sich diese Werte gerade auf mobilen Endgeräten nicht unbedingt, wenn zum Beispiel ein Dieb das Gerät nutzt. Dieser wird anfangs die vorhandenen Mittel nutzen und keinen neuen Browser installieren. Hätte dieser doch vor, so vorzugehen, dürfte es erst gar nicht dazu kommen. D.h., er hätte bereits zu viel Zeit, die ihm es ermöglichen würde, andere und wichtige Informationen abzurufen. Des weiteren wird es mit hoher Wahrscheinlichkeit andere Sicherheitsmechanismen in der MoSeC-Architektur (siehe Kapitel 4.1) geben, welche den Stand des Betriebssystems und der installierten Software (beinhaltet auch den aktuellen Browser) überwachen Die.NET-Anwendung Zur Programmierung der Proof-of-Concept-Anwendung wurde das.net Framework verwendet. Als Programmiersprache kam C# zum Einsatz. Die Proofof-Concept Anwendung stellt das Herzstück dar, die alle anderen Komponenten wie den Proxy und das neuronale Netz verbindet. Für den Einsatz der künstlichen neuronalen Netze wird die Membrain-DLL genutzt (siehe Kapitel 6.1.4). Die Daten für das neuronale Netz werden auf Grundlage des HTTP-Log des Squid- Proxys (siehe Kapitel und Tabelle 6.2) ermittelt. Über SFTP lädt das Programm die bestehenden Log-Dateien vom Proxy. Hierfür wird die Drittanbieter- DLL SSH.NET Library 123 genutzt, welche.net 4.0 unterstützt und sehr stabil 122 Microsoft, Download: Microsoft.NET Framework 4 (Webinstaller) - Microsoft Download Center - Download Details, Codeplex, SSH.NET Library - Home,

96 6 Ergebnisse 85 und zuverlässig funktioniert. Die Bibliothek kann von Codeplex 124 heruntergeladen werden und steht unter der BSD-Lizenz. Ergänzen Log herunterladen via SSH.NET Library Die SSH.NET Library lässt sich so nutzen, wie es erwartet wird. Die folgenden Code-Schnipsel (Abbildung 6.6) stellen die generelle Nutzung dar. Zuerst wird eine Client, indem die Klasse SftpClient instanziiert wird, erzeugt. Hierfür sind die Adresse des Servers, der Port, Login-Name und -Passwort nötig, welche dem Konstruktor übergeben werden. [...] var settings = Settings.Default; _instance = new SftpClient(settings.SftpHost, settings.sftpport, settings.sftpusername, settings.sftppasswort); [...] Abbildung 6.6: SFTP Client Instanziierung Abbildung 6.6 zeigt die Erstellung, welche im Rahmen eines Singleton- Patterns 125 passiert. Die weitere Verwendung und das Herunterladen eines Logs wird in Abbildung 6.7 dargestellt, wobei über SftpClientManager.Instance auf das Singleton zugegrien wird. Zuerst wird überprüft, ob der Client schon verbunden ist (IsConnected), wenn nicht, wird eine Verbindung aufgebaut (Connect()). Danach wird über die Methode Download- File(...) eine Log-Datei vom Proxy heruntergeladen. Über den FileStream werden die Daten in einer Datei abgelegt und durch ein Zurücksetzen des BueredStream können die Daten nach einer Umwandlung als String (Zeichenkette) weiterverarbeitet werden. Die Daten werden auf der Festplatte gespeichert, um eine spätere Weiterverarbeitung zu ermöglichen und nicht jedes Mal eine Verbindung zum Proxy aufgebaut werden muss. [...] using (var filestream = File.Create(Settings.Default.LogFilesPath + Path.GetFileName(file))) { using (var bstream = new BufferedStream(fileStream)) { if (!SftpClientManager.Instance.IsConnected) { SftpClientManager.Instance.Connect(); } SftpClientManager.Instance.DownloadFile(file, bstream); } } [...] [...] Abbildung 6.7: Abrufen des Proxy-Logs über SFTP 124 Codeplex, SSH.NET Library - Download: , view/ Nähere Informationen unter Microsoft, Implementing Singleton in C#, microsoft.com/en-us/library/ aspx

97 86 6 Ergebnisse Weiterverarbeitung des Logs zu Lerndaten Wurden die Daten vom Proxy oder von der Festplatte geladen, können diese analysiert werden. Für die Analyse werden wird jede Log-Zeile in einer eigene Datenklasse geladen, welche die Log-Zeile als privates Property beinhaltet und lesenden Zugri auf die einzelnen Eigenschaften des HTTP- Logs aus Tabelle 6.2 als einzelne und separate Propertys ermöglicht. Da die Daten, die ein HTTP-Header beinhaltet, variieren können, ist das Auslesen nicht ganz so einfach. Ein eleganter Weg zum Herausltern dieser Daten stellen Regular-Expressions (Regex) 126 dar. [...] private const string OS_REGEX_PATTERN [...] var match = Regex.Match(this.RequestHeader, OS_REGEX_PATTERN); if (match.success) { _os = HttpUtility.UrlDecode(match.Value); } [...] Abbildung 6.8: Extrahieren von Client-OS aus HTTP-Header mittels Regex Abbildung 6.8 zeigt das exemplarische Vorgehen, mittels Regex, um das Betriebssystem aus dem HTTP-Header herauszultern. Der HTTP-Header (this.requestheader ) wird mittels, der vom.net angebotenen Regex-Unterstützung (Regex.Match(...)) mit dem String OS_REGEX_PATTERN geprüft. Sollte die Überprüfung ein positives Resultat ergeben, wird es der Variablen _os zugewiesen. Enthält der Header kein Betriebssystem, schlägt die Überprüfung fehl und die Variable wird nicht gesetzt. Der Aufruf HTTPUtility.UrlDecode(...) dient dazu, das Ergebnis zu dekodieren und besser lesbar zu machen, d.h. zum Beispiel: %20 durch ein Leerzeichen zu ersetzen. Wurden alle benötigten Daten eingelesen, werden die zusätzlichen Eigenschaften berechnet, die sich nicht direkt aus den Log-Eigenschaften ergeben. So zum Beispiel, wie oft eine Seite aufgerufen wurde oder wie groÿ das Zeitfenster ist, indem ein Nutzer am Tag online ist. Auf die ausgewählten Eigenschaften, mit denen das neuronale Netz parametrisiert werden soll, wird zuerst ein Hash-Algorithmus angewandt um aus diesen eine Zahl zu gewinnen (z.b. aus der URL-Zeichenkette). Nachdem das hashen- angewandt wurde, wurde der Wert mit der aus angegebenen Formel auf einen Wert zwischen null und eins normalisiert. Aus den einzelnen Log-Zeilen wurden nun die Daten berechnet. Dies geschieht mit jedem im Log vorhandenen Nutzer. Auÿerdem werden um gute 126 Weitere Informationen z.b. in Stubblebine, T. (2007), Regular Expression Pocket Reference: Regular Expressions for Perl, Ruby, PHP, Python, C, Java and. NET, O'Reilly Media, Incorporated

98 6 Ergebnisse 87 Lerndaten zu erhalten, diese durch Daten anderer Nutzer ergänzt. In Abbildung 6.9 sind Beispiel-Lerndaten abgebildet und das Format der Daten, die aus einem Log (siehe Abbildung 6.3) berechnet wurden. URL;URLCount;URLSequence;Time;AVGTimeOnline;Seq0;Seq1;Seq2;Seq3;Seq4;to be;not to be 0,32175;0,275;0, ;0, ;0, ;0,32175;0,43325;0,32175;0,43325;0,32175;1;0 0,406;0,025;0, ;0, ;0, ;0,32175;0,43325;0,32175;0,43325;0,32175;1;0 0,44575;0,03;0,0958;0, ;0, ;0,43325;0,32175;0,43325;0,32175;0,406;1;0 0,406;0,025;0,096425;0, ;0, ;0,32175;0,43325;0,32175;0,406;0,44575;1;0 0,406;0,025;0, ;0, ;0, ;0,43325;0,32175;0,406;0,44575;0,406;1;0 0,6045;0,115;0, ;0, ;0, ;0,43325;0,32175;0,406;0,44575;0,406;1;0 0,51475;0,015;0,1092;0, ;0, ;0,32175;0,406;0,44575;0,406;0,6045;1;0 0,44575;0,03;0,11885;0, ;0, ;0,406;0,44575;0,406;0,6045;0,51475;1;0 Abbildung 6.9: Beispiel: Berechnete Lerndaten In der ersten Zeile der CSV-Datei sind die Namen der Eingangs- gefolgt von den Ausgangsneuronen. Diese müssen exakt denen, vom Membrain modellierten, Netz entsprechen, damit die Datei eingelesen werden kann. Gefolgt von den Namen, kommen die einzelnen gehashten und normalisierten Werte, welche in Kapitel beschrieben wurden. Die letzten zwei Spalten sagen aus, ob es sich um den spezischen Nutzer handelt oder um Daten eines anderen Nutzers. Die Daten die ergänzt werden, stammen nicht nur von einem anderen Nutzer, sondern es wird versucht von allen anderen Nutzern, in gleichen Teilen, die Daten zu ergänzen. Dabei wird ein 1:1-Verhältnis von eigenen und fremden Daten angestrebt. Membrain via C# Wrapper Wie über den visuellen Editor von Membrain lassen sich über die API vorhandene neuronale Netze laden und lernen. Da das Netz bereits mit der Editor modelliert wurde (siehe Kapitel 6.1.5), muss nur die entsprechende *.mbn-datei geladen werden. Da jeder Nutzer sein eigenes Netz erhält, kopiert die Anwendung die eigentliche Datei für jeden Benutzer und führt alle Operationen, wie das Lernen, auf der Kopie aus. So verfügt jeder Nutzer über die gleiche Netzarchitektur, aber über ein anderes Gedächtnis,also unterschiedlich gewichtete Verbindungen zwischen den Neuronen nach dem Lernen. Abbildung 6.10 zeigt exemplarisch eine Auswahl von wichtigen Methoden, die zur Verfügung gestellt werden. Die Lerndaten werden in Membrain in Lessons aus Patterns zusammengefasst, wobei ein Pattern einer Zeile in den Lerndaten entspricht, also Werte für alle Eingangs- und Ausgangsneuronen. Nach dem Starten des Lernvorgangs wird der Vorgang mit der aktuell geladenen Lesson so oft durchgeführt, bis der gewünschte Netzfehler erreicht wurde. Authentizierungssimulation Die Anwendung ermöglicht es auch, eine Authentizierungssimulation

99 88 6 Ergebnisse [...] /// Definition of the membrain integer as 32 bit integer using MB_INT = System.Int32; [...] /// Load the currently active neural net from the given *.mbn file (including path) [DllImport("MemBrainDLL.dll")] static extern EMBRetVal _MB_LoadNet(string pfilename); /// Apply an activation value to the input neuron at index <idx>. [DllImport("MemBrainDLL.dll")] static extern EMBRetVal _MB_ApplyInputAct(MB_INT idx, double act); /// Perform one think step of the net [DllImport("MemBrainDLL.dll")] static extern void _MB_ThinkStep(); /// Get index of the last output winner neuron of the net. Return -1 if unknown. Else /// return the output neuron index of the winner neuron. [DllImport("MemBrainDLL.dll")] static extern MB_INT _MB_GetOutputWinnerNeuron(); /// Import the currently active lesson from raw csv [DllImport("MemBrainDLL.dll")] static extern EMBRetVal _MB_ImportLessonRaw(string filepath); /// Get the number of patterns in the active lesson [DllImport("MemBrainDLL.dll")] static extern MB_INT _MB_GetLessonSize(); /// Think on all patters of the currently active lesson [DllImport("MemBrainDLL.dll")] static extern EMBRetVal _MB_ThinkLesson(); /// Perform one teach step (lesson run). Return result according to Teacher.h (TR_...) [DllImport("MemBrainDLL.dll")] static extern EMBTeachResult _MB_TeachStep(); /// Get the last known error of the currently active net [DllImport("MemBrainDLL.dll")] static extern double _MB_GetLastNetError(); [...] Abbildung 6.10: Auszug aus Membrain Wrapper durchzuführen, d.h. ein künstliches neuronales Netz mit Daten eines Nutzers zu parametrisieren und das Resultat ausgeben, welches das Netz ermittelt. Existiert ein Netz (im Optimalfall bereits gelernt) und wurde eine Log- Datei geladen, können diese beliebig gegeneinander getestet werden. Hier wird ähnlich vorgegangen wie beim Erzeugen von Lerndaten. Die Daten des ausgewählten Nutzers werden genauso umgewandelt, allerdings werden diese in keine Datei gespeichert und wieder eingelesen, sondern direkt an die Neuronen angelegt. Nach einem Denk-Durchgang wird das Ergebnis ausgegeben Resultate In diesem Kapitel wird auf die Ergebnisse der Authentizierungssimulation und deren Daten eingegangen. Die Vorgehensweise der Datenberechnung usw. sind in den bereits beschriebenen Kapiteln zu nden. Tabelle 6.3 zeigt die neun Teilnehmer als Benutzer und die Daten, welche aus ihrem Verhalten erzeugt wurden. Die Anzahl der Daten-Zeilen sind hierbei die Anzahl der Zeilen (siehe Abbildung 6.9), welche aus dem Proxy-Log des jeweiligen Nutzers berechnet werden konnten. Die Lerndaten ergeben sich aus ca. 40% dieser Daten, die

100 6 Ergebnisse 89 Abbildung 6.11: Screenshot der Proof-of-Concept-Anwendung mit Daten von den anderen Nutzern ergänzt worden sind. Hierbei wurde ein ungefähres Verhältnis von 1:1 angestrebt. Sowohl bei den Daten-Zeilen als auch bei den Lerndaten ergeben sich sehr groÿe Unterschiede zwischen den einzelnen Benutzern. So hat Person 9 nur 1700 Zeilen erzeugt, während aus den Daten von Person 3 ganze Zeilen herauskamen. Diese Diskrepanzen sind aus der unterschiedlich stark ausgeprägten Nutzung des Proxys herzuleiten. Benutzer Anzahl Daten- Zeilen Ge- Lerndaten samt Person Person Person Person Person Person Person Person Person Tabelle 6.3: Eingeossene Daten-Zeilen von Nutzern Die künstlichen neuronalen Netze aller Nutzer wurden solange gelernt, bis sie einen Netzfehler von 0,06 oder besser erreichten. Die Zeit, die ein Netz zum Lernen braucht, hängt stark von der Anzahl der Daten, der Qualität der Daten und dem abgezielten Netzfehler ab. Hierbei wurden so viele Lern-Iteration durchgeführt, bis der gewünschte Netzfehler erreicht wurde. Gelernt wurden die Netze