1.1 Binary file Papers/Opensecurity - DACH Paper.pdf has changed

     2.1 --- a/Papers/Opensecurity - DACH Paper.tex	Thu Apr 10 11:33:01 2014 +0100
     2.2 +++ b/Papers/Opensecurity - DACH Paper.tex	Fri Apr 11 11:26:04 2014 +0200
     2.3 @@ -38,11 +38,8 @@
     2.4  
     2.5  Jede Organisation muss ihre IT-Infrastruktur vor internen und externen Gefahren schützen. Besonders davon betroffen sind auch öffentliche Institutionen, welche private Bürgerdaten wie Strafregister, Krankengeschichte und Meldedaten oder für die Staatssicherheit relevante Informationen verwalten. 
     2.6  
     2.7 -\begin{comment}
     2.8 -reformulate following and elliminate the Statistiken (as we have none reference)
     2.9 -\end{comment}
    2.10 -
    2.11 -Wie Einzelfälle und Statistiken belegen\footnote{WELCHE?}, kommt es aber immer wieder und zunehmend häufiger zu Vorfällen, bei denen private Daten in falsche Hände geraten. Solche Daten können in kürzester Zeit weltweit über das Internet verteilt werden, was schnell zu Worst-Case-Szenarien führen kann. So können beispielsweise private Adressen von Polizeibeamten ihren Weg zu kriminellen Organisationen finden oder private Gesundheitsdaten in die Hände potenzieller zukünftiger Arbeitgeber.
    2.12 +Wie Einzelfälle und Statistiken belegen\footnote{Darunter sind: \begin{itemize}\item https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/dbn/at\_download/fullReport \item http://gbr.pepperdine.edu/2010/08/the-cost-of-lost-data/ \item http://datalossdb.org \item http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/data-loss-prevention/white\_paper\_c11-499060.html \item https://www4.symantec.com/mktginfo/whitepaper/053013\_GL\_NA\_WP\_Ponemon-2013-Cost-of-a-Data-Breach-Report\_daiNA\_cta72382.pdf \end{itemize}}
    2.13 +, kommt es aber immer wieder und zunehmend häufiger zu Vorfällen, bei denen private Daten in falsche Hände geraten. Solche Daten können in kürzester Zeit weltweit über das Internet verteilt werden, was schnell zu Worst-Case-Szenarien führen kann. So können beispielsweise private Adressen von Polizeibeamten ihren Weg zu kriminellen Organisationen finden oder private Gesundheitsdaten in die Hände potenzieller zukünftiger Arbeitgeber.
    2.14  
    2.15  Durch die sensible Natur dieser Informationen, sind die Nutzer solcher öffentlichen Einrichtungen oft zu geschlossenen und sicheren lokalen Netzwerk gedrängt. Diese Systeme verfügen oft über keinen Zugang zum Internet (WWW) oder über Anschlüsse für tragbare  Speichermedien (TSM) um den sorgfältigen Umgang mit diesen Daten zu gewährleisten.
    2.16  
    2.17 @@ -54,11 +51,6 @@
    2.18  
    2.19  Im Fall, dass Hardware (z.B. ein Notebook) oder Speichermedien (z.B. ein USB-Stick) verloren gehen oder gestohlen werden, sind keine sensiblen unverschlüsselten Daten gefährdet. Wurden dennoch sensible Daten preisgegeben, was aufgrund von Richtlinien genehmigt werden kann, dann rekonstruiert die Kontrollkette aus den aufgezeichneten Datenströmen den Ereignispfad. Anhand der Informationen aus einem zentralisierten Logging kann nachvollzogen werden, welche Daten die Organisation verlassen haben und auf welchem Weg (z.B. durch welchen Benutzer, Medium).
    2.20  
    2.21 -\begin{comment}
    2.22 -reformulate and elliminate the DLP reference 
    2.23 -\end{comment}
    2.24 -Die Innovation von Open Security besteht in der Verbindung des DLP\footnote{ERKLÄRUNG}-Ansatzes mit einer zentralen Management-Lösung und einer ``Security by Isolation'' Architektur.
    2.25 -
    2.26  Das Internet, als dicht vernetztes Gefüge untereinander verbundener Geräte, bietet eine ideale Angriffsfläche für sich selbst replizierenden Schadcode. Aus diesem Grund ist Anti-Virensoftware ein zentraler Bestandteil jeder Sicherheitsstrategie. Eine solche Lösung ist stark abhängig von Signatur-Updates und schützt nur vor bekannten Malware. Nicht entdecktes Malware kann als erstes den Update-Mechanismus des Antivirus deaktivieren um später nicht entdeckt zu werden.
    2.27  
    2.28  \section{Security by Isolation}
    2.29 @@ -70,7 +62,7 @@
    2.30  Die Alternative zu diesem als ``Security by Correctness'' bekannten Ansatz verfolgt eine ganz andere Herangehensweise: ``Security by Isolation'' (Sicherheit durch Isolation). 
    2.31  Die Idee dabei ist, ein System in getrennte Untersysteme aufzuspalten so dass ein Fehlverhalten eines Teilsystems nicht andere Teilsysteme berührt. Die Aufteilung in sinnvolle Untersysteme und das Einrichten geeigneter Zugriffsrichtlinien ist einer der Hauptaufgaben und größten Herausforderungen. Dieser Ansatz vermittelt nun Anwenderzugriffe und -Umgang mit Ressourcen aus unsicheren oder zweifelhaften Quellen wie Internet oder Mobile Datenträger indem die dabei verwendete Teilsysteme durch Virtualisierung voneinander getrennt werden. Durch den Einsatz dieser Virtualisierungsschicht werden die darin gekapselten Systemkomponenten vom Trägersystem unabhängig und sind somit auf einer Vielzahl aktueller und moderner Desktop Betriebssysteme implementier- und ausführbar.
    2.32  
    2.33 -Es gibt zwei wichtige Projekte, die dieser Herangehensweise folgen: Ethos  ist ein sicheres Betriebssystem, das auf den Xen Hypervisor aufsetzt. Seine Entwicklung wird von Jon Solworth von der University of Illinois, Chicago, geleitet und von den Kryptographen Daniel Bernstein und einem Team von Mitwirkenden unterstützt. Qubes  wird von Joana Rutkowska, die durch ihre Arbeit an Rootkits bekannt ist, und von Rafal Woitcuk, beide vom Invisible Thing Lab, entwickelt.
    2.34 +Es gibt zwei wichtige Projekte, die dieser Herangehensweise folgen: Ethos\footnote{http://www.ethos-os.org/} ist ein sicheres Betriebssystem, das auf den Xen Hypervisor aufsetzt. Seine Entwicklung wird von Jon Solworth von der University of Illinois, Chicago, geleitet und von den Kryptographen Daniel Bernstein und einem Team von Mitwirkenden unterstützt. Qubes\footnote{http://qubes-os.org/trac}  wird von Joana Rutkowska, die durch ihre Arbeit an Rootkits bekannt ist, und von Rafal Woitcuk, beide vom Invisible Thing Lab, entwickelt.
    2.35  
    2.36  Beide Systeme setzen allerdings auf den Xen Hypervisor und damit auf ein Linux (bzw. BSD oder Solaris) Grundsystem, auf dem in Folge weitere Systeme aufgesetzt werden. Da das Open Security Projekt sich an den Einsatz im öffentlichen Bereich orientiert ist von einer großflächige Umstellung auf ein derartiges bare-metal Virtualisierungssystem abzusehen. 
    2.37  
    2.38 @@ -112,7 +104,7 @@
    2.39  
    2.40  Aus Sicht des OSM umfasst das Starten einer neuen Browser-Sitzung mehrere Konfigurationsaufgaben. Der OSM startet einen X11-Server auf dem Host-Betriebssystem und nutzt einen SSH-Client mit X-Weiterleitung um den Browser innerhalb der SVM auszuführen. Dies ermöglicht eine nahtlose Integration des Browserfensters innerhalb der Host-Umgebung und lässt die Anwendung, welche in einer DVM läuft, native in der gewohnten Umgebung erscheinen. Um auf mögliche heruntergeladene Dokumente zuzugreifen, nachdem diese geprüft wurden, wird zusätzlich der Download-Ordner des Browsers von der SVM als SAMBA Netzlaufwerk im Hostsystem eingebunden. 
    2.41  
    2.42 -Beim Zugriff auf heruntergeladene Inhalte wird die angesprochene Datei nicht direkt sofort auf das Hostsystem übermittelt, sondern duch den Einsatz von OsecFS automatisch mittels einer Anti-Virus Einheit auf Malware untersucht. Das OsecFS basiert dabei auf einen FUSE\footnote{Filesystem in user space} Ansatz und bietet somit ein virtuelles Dateisystem dem SAMBA Service innerhalb der SVM an. Das Backend des OsecFS bietet dabei generische Schnittstellen um adaptiv beliebige Anti-Viren Systeme anbinden zu können. Vorrangig gilt es dabei unternehmensweite Anti-Viren Server Systeme anzusprechen, allerdings sind auch lokale AV Prüfungssysteme integrierbar.
    2.43 +Beim Zugriff auf heruntergeladene Inhalte wird die angesprochene Datei nicht direkt sofort auf das Hostsystem übermittelt, sondern duch den Einsatz von OsecFS\footnote{Open Security File System} automatisch mittels einer Anti-Virus Einheit auf Malware untersucht. Das OsecFS basiert dabei auf einen FUSE\footnote{Filesystem in user space} Ansatz und bietet somit ein virtuelles Dateisystem dem SAMBA Service innerhalb der SVM an. Das Backend des OsecFS bietet dabei generische Schnittstellen um adaptiv beliebige Anti-Viren Systeme anbinden zu können. Vorrangig gilt es dabei unternehmensweite Anti-Viren Server Systeme anzusprechen, allerdings sind auch lokale AV Prüfungssysteme integrierbar.
    2.44  
    2.45  Der SVM-Instanz wird eine Host-Only-Netzwerkschnittstelle für die Kommunikation mit dem Host zugewiesen. Auf dieser sind nur vom Host initiierte Verbindungen zugelassen. Die SSH- Kommunikation wird durch automatisch generierte Public/Private Schlüsselpaare gesichert und der Verbindungsaufbau durch Bereitstellen der authorized\_keys Datei in einem spontan erzeugten ISO-Image ermöglicht. Diese Verbindung dient zum einen dem OSM die Virtuelle Maschine zu administrieren, zum anderen auch um das GUI der jeweiligen Anwendung innerhalb der SVM auf den Host darzustellen. 
    2.46  
    2.47 @@ -123,9 +115,9 @@
    2.48  
    2.49  Der Umgang mit Daten auf externen Trägern wie USB Sticks hat neben dem Ziel den Anwender und damit das Host System von Malware zu schützen auch die Intention sensible Daten nur verschlüsselt auf diese Medien abzulegen. 
    2.50  
    2.51 -Der OSM unterbindet das automatische Laden von Gerätetreiber und das Einhängen von geöffneten Dateisystemen am Hostsystem. Statt dessen wartet der OSM auf entsprechende Hardwareevents und leitet diese an neu instantiierte SVM Einheiten weiter. Diese SVMs binden nun die jeweiligen Gerätetreiber innerhalb ihres Systems ein, können damit die neu hinzugefügte Hardware ansprechen und öffnen den Datenträger. Analog zum Download Bereich aus vorigem Kapitel über das Sichere Surfen wird auch hier der Dateninhalt nicht unmittelbar über eine SAMBA Schnittstelle an das Hostsystem weitergeleitet. Vielmehr prüft auch hier eine OsecFS Instanz sämtliche open und read Anweisungen und leitet die betroffenen Dateiströme an ein Anti Viren System. Wird die betroffene Datei als kompromittiert erkannt, schlägt eine Öffnen dieser Datei somit mit einer entsprechenden Fehlermeldung fehl.
    2.52 +Der OSM unterbindet das automatische Laden von Gerätetreiber und das Einhängen von geöffneten Dateisystemen am Hostsystem. Statt dessen wartet der OSM auf entsprechende Hardwareevents und leitet diese an neu instantiierte SVM Einheiten weiter. Diese SVMs binden nun die jeweiligen Gerätetreiber innerhalb ihres Systems ein, können damit die neu hinzugefügte Hardware ansprechen und öffnen den Datenträger. Analog zum Download Bereich aus vorigem Kapitel über das Sichere Surfen wird auch hier der Dateninhalt nicht unmittelbar über eine SAMBA Schnittstelle an das Hostsystem weitergeleitet. Vielmehr prüft auch hier eine OsecFS Instanz sämtliche \emph{open} und \emph{read} Anweisungen und leitet die betroffenen Dateiströme an ein Anti Viren System. Wird die betroffene Datei als kompromittiert erkannt, schlägt eine Öffnen dieser Datei somit mit einer entsprechenden Fehlermeldung fehl.
    2.53  
    2.54 -Das Ablegen und Speichern von Dateien auf dem Medium erzwingt das Verschlüsseln dieser Dateien. Ein write auf den SAMBA Share im Hostsystem wird im OsecFS erkannt und stößt damit einen Verschlüsselungprozess an. Die aktuell verwendete Technologie dazu ist Truecrypt\footnote{http://www.truecrypt.org/}, es können aber auch andere Anbieter oder Technologien eingesetzt werden.
    2.55 +Das Ablegen und Speichern von Dateien auf dem Medium erzwingt das Verschlüsseln dieser Dateien. Ein \emph{write} auf den SAMBA Share im Hostsystem wird im OsecFS erkannt und stößt damit einen Verschlüsselungprozess an. Die aktuell verwendete Technologie dazu ist Truecrypt\footnote{http://www.truecrypt.org/}, es können aber auch andere Anbieter oder Technologien eingesetzt werden.
    2.56  
    2.57  Je nach eingesetzter Verschlüsselungstechnik kann in Folge der Datenträger auch von einem nicht Open Security System erkannt und geöffnet werden.
    2.58  
    2.59 @@ -155,4 +147,11 @@
    2.60  
    2.61  Ein Seiteneffekt dieses Migrationspfades ist daher auch die Lösung von unmittelbaren Abhängig-keiten proprietärer Software. Läßt sich eine Virtualsierungstechnik wie VirtualBox oder VMWare installieren dann kann prinzipiell jedes Hostsystem gewählt werden und dennoch stehen die gewohnten Applikationen in einer sicheren Umgebung zur Verfügung. Mehr noch: da die einzelnen SVMs voneinander unabhängig sind und über Repositories Updates erfahren, können diese umfassende System- und Anwendungsupdates erhalten ohne die restlichen Komponenten des Gesamtsystems zu berühren. Portable SVMs lassen sich auch von einer Maschine zur nächsten transferieren und erfüllen dann in einem physisch völlig anderen Umfeld dennoch die gleiche Funktionalität.
    2.62  
    2.63 +\section{Ausblick}
    2.64 +
    2.65 +Bei dem Unternehmen, ``Security by Isolation'' Ideen auf Windows zu implementieren, sind wir auf eine Reihe von Herausforderungen gestoßen. Besonders hervorzuheben ist dabei die Verwaltung der Zugriffsberechtigungen zur Installation, zur Laufzeit des OSM und während des Ausführens einer Applikation in einer SVM im möglichem Mehrbenutzerbetrieb. Unsere nächsten Schritte beinhalten die Stabilisierung und das Hardening der Code-Basis für unternehmensweite Roll-Outs. Auch arbeiten wir an Usability Erweiterungen wie etwa persistente Bookmarks in den Browsern einer SVM.
    2.66 +
    2.67 +Während der nächsten Monate wird das Ergebnis in abgegrenzten Umgebungen Projektbeteiligter installiert. Aus dieser Testphase verspricht sich das Team genügend Feedback um das Ergebnis des Open Security Projekts in Hinblick auf Stabilität und Anwenderfreundlichkeit weiter zu verbessern und dann gegebenenfalls das Paket online für den freien Download zur Verfügung zu stellen. 
    2.68 +
    2.69 +
    2.70  \end{document}