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

     2.1 --- a/Papers/Opensecurity - DACH Paper.tex	Tue Apr 08 18:38:44 2014 +0100
     2.2 +++ b/Papers/Opensecurity - DACH Paper.tex	Wed Apr 09 11:27:42 2014 +0200
     2.3 @@ -18,7 +18,7 @@
     2.4  \title{Security by Isolation Prinzipien in der öffentlichen Verwaltung \\[1em]
     2.5  \large{Sanfte Migration zu virtualisierten Anwendungen bei bestehenden Betrieb im Rahmen des Open Security Projekts}
     2.6  }
     2.7 -\author{Mihai Bartha, Oliver Maurhart\\
     2.8 +\author{Ross King, Mihai Bartha, Oliver Maurhart\\
     2.9  AIT Austrian Institute of Technology
    2.10  }
    2.11  
    2.12 @@ -58,31 +58,48 @@
    2.13  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.14  
    2.15  \section{Security by Isolation}
    2.16 -Im Open Security Projekt werden die ``Security by Isolation'' Konzepte angewendet um mögliche durch Malware verursachten Schaden entgegenzuwirken und die eine zentralisierte oder lokale Anti-Virus Architektur mittels Virtualisierung implementiert und durchsetz. 
    2.17 -The idea behind "Security by Isolation" consists in splitting a system into subsystems separated from oneanother so that the malfunction/failure of one subsystem does not affect the others. Partitioning the system into meaningfull subsystems and setting apropriate permissions is one of the main challenges. The OpenSecurity approach is to mediate user interactions with unsafe resources (internet, removable storage, viewing unsafe content) by means of subsystems isolated through virtualization. Making use of virtualization enables the implementation of a solution portable across most current desktop operating systems. 
    2.18 +
    2.19 +Heutige Mainstream-Betriebssysteme für den Desktop wie Apple Mac OS X, Microsoft Windows oder auch Linux, sind unzureichend, wenn es um die Datensicherheit geht. Ihr gemeinsames und unüberwindliches Problem liegt darin, dass sie nicht in der Lage sind, die verschiedenen Programme, die gleichzeitig auf einem Rechner laufen, ausreichend von einander zu isolieren. Wenn zum Beispiel der Browser einer Nutzerin oder eines Nutzers durch einen aus dem Netz geladenen Trojaner kompromittiert wird, ist das Betriebssystem normaler Weise nicht in der Lage, andere Software oder auch Daten davor zu schützen, ebenfalls kompromittiert zu werden. Besonders schwerwiegend wird das Problem, wenn wichtige Systemkomponenten, wie etwa die Gerätetreiber, kompromittiert wurden. In so einem Fall ist keines der genannten Betriebssysteme in der Lage, die übrige Software oder die Daten der NutzerInnen vor dem kompletten Kompromittieren zu schützen. Dieser kritische Zustand lässt sich direkt auf Designentscheidungen der Systemarchitekturen zurückführen. Diese schließen zu komplexe Programmierschnittstellen (API) ebenso ein wie unsichere graphische Nutzerschnittstellen (GUI) und monolithische Kernelarchitekturen.
    2.20 +
    2.21 +Bisher wird vor allem auf reaktive Ansätze zurückgegriffen. Viele Anbieter versuchen, jede bekannte Sicherheitslücke zu patchen. Solche Ansätze skalieren aber nicht nur nicht, sie funktionieren schon deshalb nicht, weil nur bekannte und vor allem viel genutzte Angriffe abgewehrt werden können. Vor neuen oder nicht so bekannten, gezielter ausgenutzten Sicherheitslücken kann so nicht geschützt werden.
    2.22 +
    2.23 +Die Alternative zu diesem als ``Security by Correctness'' bekannten Ansatz verfolgt eine ganz andere Herangehensweise: ``Security by Isolation'' (Sicherheit durch Isolation). 
    2.24 +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.25 +
    2.26 +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.27 +
    2.28 +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.29 +
    2.30 +Im Open Security Projekt werden die ``Security by Isolation'' Konzepte angewendet um mögliche durch Malware verursachten Schäden mittels einer in erster Linie hosted Virtualisierung entgegenzuwirken. Eine zentralisierte und im Fehlen einer Verbindung zum zentralen Dienst auch lokale Anti-Virus Architektur detektiert in einen eingegrenzten Bereich Malware bevor diese auf sensible Bereich des Systems übergreifen kann. Die dabei entstandenen Komponenten und Dienste lassen sich aber auch auf eine bare-metal Virtualisierung wie XEN implementieren.
    2.31 +
    2.32  
    2.33  \section{Architektur}
    2.34  
    2.35 -From the OpenSecurity perspective two main security zones can be identified and will be referred to throughout the present document. Safe Network (SN) is the corporate network of the demand carrier. The user’s interaction is currently limited to this network because of the sensible nature of the information and data he is dealing with. The SN is considered to be a trusted and secure through isolation from the outside world. Because of the sensible nature of the information (data), there are very strict access restrictions to external resources. Securing the interaction with unsafe resources (RSDs and internet) can be brought down to several main challenges.
    2.36 -1.	Mediate and orchestrate the interaction with unsafe resources.
    2.37 -2.	Protect the Safe Network from malware.
    2.38 -3.	Protect sensible information from theft or accidental loss of portable devices.
    2.39 +Aus der Perspektive von Open Security werden zwei Sicherheitszonen identifiziert: das sichere Netzwerk (SN) ist das zu schützende Unternehmensnetzwerk des Bedarfsträgers. Die Interaktion des Benutzers ist aufgrund der sensiblen Natur der Informationen und Daten zur Zeit auf dieses Netz begrenzt. Das SN gilt als vertrauenswürdige und wird durch Isolation von der Außenwelt getrennt. Es existieren sehr strenge Zugangsbeschränkungen zu externen Ressourcen um die Datensicherheit im SN nicht zu kompromittieren. Die Sicherung der Interaktion mit eben unsicheren oder zweifelhaften Ressourcen (mobile Datenträger und Internet) kann auf diese großen Herausforderungen heruntergebrochen werden:
    2.40  
    2.41 -From a virtualization technology standpoint bare-metal or user-space virtualization solutions can be used. The OpenSecurity project aims at providing a generic Virtual Machine (VM) orchestration layer that can be easily extensible to support further hypervisors. The current implementation is based on a user-space virtualisation solution (VirtualBox) on top of a native operating system (Windows). 
    2.42 +\begin{enumerate}
    2.43 +    \item Vermittlung und Steuerung des Zusammenspiels mit unsicheren Ressourcen.
    2.44 +    \item Schutz des SN vor Malware.
    2.45 +    \item Schutz sensibler Informationen vor Diebstahl oder durch Verlust von tragbaren Geräten.
    2.46 +\end{enumerate}
    2.47  
    2.48 -XEN based bare-metal hypervisors are also possible as the underlying framework for our implementation. QubesOS (XEN/Fedora based hypervisor) already implements the concept of ``Security by Isolation'' and will be used for scenarios where such an installation is feasible.
    2.49 +Prinzipiell kann eine bare-metal- als auch user-space- Virtualisierungslösungen verwendet werden. Im Open Security Projekt existiert eine generische Virtual Machine (VM) Orchestrierung Schicht, die leicht erweiterbar ist, um weitere Hypervisoren unterstützen können. Um eine fließende Migration einer bestehenden Infrastruktur zu ermöglichen basiert die aktuelle Implementierung auf einem user-space Virtualisierungslösung (VirtualBox) auf einem bereits existierenden Betriebssystem (Windows).
    2.50  
    2.51 -Architechture Figure 6 -  (Safe Internet Access)
    2.52 +\begin{center}\textbf{TBD:} Architechture Bild 6 - (Sichere Internet-Zugang)\end{center}
    2.53  
    2.54 -The main architectural components are the OpenSecurity Manager (OSM) and the Security Virtual Machine (SVM). The OpenSecurty system is built around the SVM which is a Linux based virtual machine and the actual subsystem that mediates the user's interaction with the unsafe resources. The OSM is a virtual machine management layer and user interface, responsible with processing user requests and hardware events. 
    2.55 -Upon request for a browsing session the OSM handles the instantiation, configuration and start of a new SVM responsible for the browsing session. The SVM instances are created as Disposable Virtual Machines (DVM) from an existing SVM template. 
    2.56 -DVMs are specialized virtual machines that can be easily instantiated or disposed and have very short startup times. The DVM concept is implemented by making use of immutable virtual disk images and differencing disks as well as having the template SVM in a hibernated state. This solution makes sure that any changes the browsing session (undetected malware) has made to the SVM instance are disposed upon session close.
    2.57 -In addition this solution has the advantage of minimizing disk usage and allowing for a simple SVM update. By updating the template the changes are reflected in all newly created SVM instances. The update mechanism is triggered by the OSM with the update backend in the form of a package repository hosted by the OpenSecurity project.
    2.58 -The reference SVM implementation is based on a minimal Debian installation. The installed software packages include a web browser, encryption engine, antivirus, SSH server and SAMBA server. 
    2.59 -From the OSM point of view starting a new browsing session involves multiple configuration tasks. 
    2.60 -During a browsing session the OSM starts an X11 server on the host OS and uses an SSH client with X-forwarding to execute the browser on the SVM. This allows for a seamless integration of the browser window within the host environment. In addition the browser’s Downloads folder exposed by the SVM as a SAMBA share is mounted as a network drive and is accessible by the host. 
    2.61 -The SVM instance is assigned a host-only network interface necessary for communication with the host on which only host outbound connections are allowed. In addition the SVM is assigned a NAT interface for accessing the internet. The SSH communication is secured by means of automatically generated public/private keys and attached ISO image containing the authorized_keys file.
    2.62 +Die wichtigsten architektonischen Komponenten sind der Open Security Manager (OSM) und die Security Virtual Machine (SVM). Das Open Security System ist rund um die SVM, eine auf Linux basierende virtuellen Maschine inklusive der tatsächlichen Subsystemen, welche die Interaktion des Benutzers mit den unsicheren Ressourcen vermittelt, gebaut. Der OSM ist eine Management Schichte zur Steuerung der Virtuellen Maschinen samt Benutzeroberfläche und ist für die Verarbeitung von Benutzeranforderungen sowie Hardware-Events (bsp. USB) verantwortlich.
    2.63  
    2.64 +Beim Start einer Browser-Sitzung kümmert sich der OSM um die Instanziierung, Konfiguration und Start einer neuen SVM, welche speziell nur für diese Browser-Sitzung verantwortlich ist. Die neue SVM-Instanz wird als Disposable Virtual Maschine (DVM - ``Wegwerf'' Virtuelle Maschine) aus einer vorhandenen SVM-Vorlage erstellt .
    2.65 +
    2.66 +DVMs sind eigens hergestellte virtuelle Maschinen, die leicht instanziiert und wieder entsorgt werden können, mit ebenfalls sehr kurzen Bootzeiten. Das DVM Konzept wird durch die Nutzung von unveränderlichen virtuellen Festplatten-Snapshots und differenzierender Festplatten-Abbildungen sowie mit einer SVM-Vorlage im Ruhezustand implementiert. Diese Lösung stellt sicher, dass alle Änderungen der Browser-Sitzung (wie auch möglicherweise unerkannte Malware) in der DVM an der neuen SVM-Instanz gemacht werden und bei Beendigung der Sitzung gelöscht werden.
    2.67 +
    2.68 +Außerdem hat diese Lösung den Vorteil der Minimierung an Plattenplatznutzung und ermöglicht eine einfache Aktualisierung der SVM Vorlage. Durch das Update der Vorlage wirken Änderungen in allen neu erstellten SVM Instanzen. Der Update-Mechanismus wird durch das OSM Update-Backend angestoßen, welcher auf ein Paket-Repository des Open Security Projekt zurückgreift.
    2.69 +
    2.70 +Die Referenz SVM-Implementierung basiert auf einer minimalen Debian Installation. Die installierten Software-Pakete enthalten einen Web-Browser, Verschlüsselungs-Software, Antiviresnsoftware, einen SSH-Server und einen SAMBA-Server.
    2.71 +
    2.72 +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ätzliche der Download-Ordner des Browsers von der SVM als SAMBA Netzlaufwerk im Hostsystem eingebunden.
    2.73 +
    2.74 +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. Zusätzlich wird der SVM eine NAT-Schnittstelle für den Zugriff auf das Internet zugewiesen, auf welcher die Kommunikation durch den Host durchgeleitet wird.
    2.75  
    2.76  
    2.77  \end{document}