1.1 Binary file Architecture.doc has changed

     2.1 --- a/Papers/Opensecurity - DACH Paper.tex	Tue Apr 08 13:45:49 2014 +0200
     2.2 +++ b/Papers/Opensecurity - DACH Paper.tex	Tue Apr 08 18:38:44 2014 +0100
     2.3 @@ -53,21 +53,35 @@
     2.4  
     2.5  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.6  
     2.7 -Die Innovation von Open Security besteht in der Verbindung des DLP\footnote{ERKLÄRUNG}-Ansatzes mit einer zentralen Management-Lösung und einer ``Sicherheit durch Isolation'' Architektur.
     2.8 +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.9  
    2.10  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.11  
    2.12 -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. 
    2.13 -
    2.14 -
    2.15  \section{Security by Isolation}
    2.16 -
    2.17 -TBD: Was ist eigentlich Security By Isolation ...
    2.18 -
    2.19 +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.20 +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.21  
    2.22  \section{Architektur}
    2.23  
    2.24 -TBD: Was ist unsere Architektur ...
    2.25 +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.26 +1.	Mediate and orchestrate the interaction with unsafe resources.
    2.27 +2.	Protect the Safe Network from malware.
    2.28 +3.	Protect sensible information from theft or accidental loss of portable devices.
    2.29 +
    2.30 +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.31 +
    2.32 +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.33 +
    2.34 +Architechture Figure 6 -  (Safe Internet Access)
    2.35 +
    2.36 +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.37 +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.38 +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.39 +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.40 +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.41 +From the OSM point of view starting a new browsing session involves multiple configuration tasks. 
    2.42 +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.43 +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.44  
    2.45  
    2.46