Differences between revisions 16 and 17
Revision 16 as of 2011-01-19 18:55:10
Size: 20237
Editor: UrsLerch
Comment: oops, forgot to delete the original text of Grenzen
Revision 17 as of 2011-01-19 19:19:38
Size: 20298
Editor: UrsLerch
Comment: added link to syslog-ng and some minor corrections
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:

Line 49: Line 47:
 * ''Insink'' ist das Sammelbecken, das all die unterschiedlichen einkommenden Meldungen in Apache ALOIS aufnimmt. Es basiert teilweise auf der weit verbreiteten Software {{{syslog-ng}}}. Das Modul Insink nimmt Nachrichten entgegen (UDP), wartet auf Meldungen (TCP), kann komplexe Nachrichten (Dateien, Mails) entgegennehmen und führt eine vorgängige Filterung durch, um einen Überfluss an Nachrichten zu verhindern.  * ''Insink'' ist das Sammelbecken, das all die unterschiedlichen einkommenden Meldungen in Apache ALOIS aufnimmt. Es basiert teilweise auf der weit verbreiteten Software {{{syslog-ng}}}. [5] Das Modul Insink nimmt Nachrichten entgegen (UDP), wartet auf Meldungen (TCP), kann komplexe Nachrichten (Dateien, Mails) entgegennehmen und führt eine vorgängige Filterung durch, um einen Überfluss an Nachrichten zu verhindern.
Line 92: Line 90:
Also Open Source Software ist ALOIS selbstverständlich Work-In-Progress. Die aktuelle Version verfügt über die Mehrzahl der oben erwähnten Eigenschaften, aber wir rufen hiermit auch zur Mitarbeit an Konzept, Iechnologie, Integration auf, ebenso wie zu Diskussion sinnvoller Einsatzszenarien - sei es im Bereich VDS, Data Leakage Detection oder andere. Als Open Source Software ist ALOIS selbstverständlich Work-In-Progress. Die aktuelle Version verfügt über die Mehrzahl der oben erwähnten Eigenschaften, aber wir rufen hiermit auch zur Mitarbeit an Konzept, Technologie und Integration auf, ebenso wie zur Diskussion sinnvoller Einsatzszenarien - sei es im Bereich VDS, Data Leakage Detection oder andere.
Line 115: Line 113:

[5] http://www.balabit.com/network-security/syslog-ng/

[This is working paper in German for the "Chemnitzer Linux Tage", taking place in Chemnitz, Germany on the weekend of March 19/20 2011. Deadline for the paper is January 19th, 2011. Find more details here: http://chemnitzer.linux-tage.de/2011/vortraege/proceedings/.]

Umgekehrte Vorratsdatenspeicherung

Urs Lerch & Marcus Holthaus

Abstract: Ob Vorratsdatenspeicherung zur Beweisführung für eine Straftat Sinn macht, ist umstritten. Könnte Sie allenfalls zur Entlastung einer davon betroffenen Person verwendet werden? Dies läge klar im Interesse jedes einzelnen Computernutzers. Diskutiert wird allerdings nur über eine zentrale vorrätliche Datenspeicherung durch Provider zur Ermittlung von Straftaten durch Polizeibehörden. Wieso also die Diskussion nicht umkehren, und über eine lokale, dezentrale, transparente Vorratsdatenspeicherung diskutieren, allenfalls mit Hinterlegung bei einem Anwalt? Apache ALOIS ist ein offenes Tool zur Sammlung und Analyse von Logdaten, das die technische Seite der Aufgabe übernehmen könnte.

Einleitung

Die Vorratsdatenspeicherung (VDS) ist gerade in Deutschland ein politisch "heisses Eisen". Es geht dabei nicht um eine technologische Debatte, sondern ganz grundsätzlich um das politische Abwiegen von (gemeinschaftlicher) Sicherheit gegenüber (individueller) Freiheit. Es überrascht deshalb auch nicht weiter, dass die Positionen weitgehend bezogen sind und es in der ausführlich, bisweilen hitzig geführte Diskussion kaum mehr inhaltliche Bewegung gibt. Sie gleicht mehr einem Stellungskrieg, in dem mitunter neue Akteure auftauchen, z.B. die EU-Kommission, und Begriffe inhaltlich umgedeutet werden wie z.B. "Quick Freeze".

Dieser Text hat nicht zum Ziel, die bisherige Diskussion zu protokollieren. Und wir möchten ganz bewusst auch nicht Stellung für oder gegen die VDS beziehen. Wir stellen jedoch nüchtern fest, dass jede Person bei der Benutzung eines Computers Spuren in dessen Log-Dateien hinterlässt - dazu sind Logs ja da, und das hat aus technischer Sicht auch Vorteile. Das Problem ist, dass die Spuren, die im Sinne einer Vorratsdatenspeicherung aufgezeichnet und aufbewahrt werden, den davon Betroffenen nicht zur Verfügung stehen, oder allenfalls nur stark verzögert unter Wahrnhemung des Einsichtsrechts des Datenschutzes verfügbar gemacht werden können. Wer kennt schon die Spuren, die er hinterlässt? In diesem Zusammenhang stellen wir die Software Apache ALOIS vor, die technologisch eine Basis darstellen könnte, um die eigenen Datenspuren aufzuzeichnen und auszuwerten.

Vorratsdatenspeicherung

Wie bereits erwähnt, wollen wir nicht die bisherige Diskussion zur Vorratsdatenspeicherung erneut aufrollen. Auch nehmen wir keinen Bezug auf den juristischen Bereich der Debatte. In der Folge wollen wir jedoch drei Aspekte aufgreifen, die aus unserer Sicht eine nähere Betrachtung verdienen.

Transparenz

Der einzelne Nutzer hat keine Ahnung, welche Daten konkret von ihm gespeichert werden. Wüsste er es, könnte das zweierlei bewirken:

  • Erstens können allfällige Datenflüsse und Online-Aktivitäten, die vom Nutzer gar nicht gewollt sind, so eruiert wurden. Z.B. bietet das Firefox-Plugin NoScript [1] durch das Blocken von nicht explizit bewilligten Javascripts nicht nur eine zusätzliche Sicherheit vor Viren etc., sondern es können so auch sehr einfach (unerwünschte) Datenflüsse wie etwa diejenigen von Google-Analytics eruiert und darauf blockiert werden. Dem Nutzer würde durch diese Identifikation also einen Anhaltspunkt zur Selbstkontrolle in die bekommen, den er nutzen oder ignorieren kann. Er kann zum Beispiel einen darin kompetenten Bekannten bitten, ein solches Plug-In oder eine lokale Firewall-Software so zu konfigurieren, dass solche Verbindungen verhindert werden.

  • Zweitens würde der Aspekt der "Security by Obscurity" aufgelöst, welcher der Vorratsdatenspeicherung innewohnt: Da niemand weiss, was über konkret ihn aufgezeichnet wird oder wurde, kann auch niemand wissen, ob in diesen Daten nicht irgendwo etwas Verbotenes beschrieben wird oder sich daraus herleiten lässt. Auch wer immer seinen moralischen Grundsätzen folgt, ist angesichts der Flut bestehender Ge- und Verbote nicht immer unschuldig im juristischen Sinn. Wer sich mit VDS beschäftigt, muss also zurecht befürchten, dass aus Vorratsdaten Fälle konstruiert werden, die eine Selbstverteidigung erfordern - und das schreckt schon ab, unabhängig davon, ob diese Verteidigung erfolgreich wäre, und erzeugt eine unangemessene Selbstzensur, die gesellschaftlich schädlich ist. Stünden dem Nutzer seine eigenen Log-Daten zur Verfügung und könnte er prüfen, ob sie etwas Fragwürdiges beschreiben - z.B. durch Vergleich mit einer Liste von URLs, die auf verbotene Inhalte verweisen (Verherrlichung von Nationalsozialismus etc.) - so könnte der Nutzer seine Aktivität überdenken und in Zukunft vermeiden. Zudem wäre er gewarnt, dass er sich unter Umständen verteidigen müsste - die eigentliche Verfolgung von potentiellen Straftaten wird also nicht behindert, sondern es wird mehr Fairness erzeugt. Um einen Vergleich eigener Online-Zugriffe mit einer Sperrliste anzustellen, müsste man solche Listen natürlich zur Verfügung haben... einige solcher ursprünglich geheimen Listen sind inzwischen öffentlich bekannt geworden und können verwendet werden.

Wir erachten es deshalb als sinnvoll, lokal eine Software zur Aufzeichnung des Datenverkehrs zu installieren. Wenn dies auf allen verwendeten elektronischen Geräten oder einer lokalen Proxy vorhanden ist und die Aufzeichnungskriterien denjenigen der Provider entsperchen, ist eine weitgehende Transparenz gewährt.

Dezentrale Speicherung

Es wäre auch möglich, die in eigener Regie gesammelten Daten nicht selbst zu bevorraten, sondern diese bei einem Treuhänder oder Notar individueller Wahl zu lagern - in diesem Fall betriebe der Notar das System zur Sammlung der Daten. Dies könnte mit einer clientseitigen Proxy verbunden werden, um Vollständigkeit zuzusichern und mit einer Client-seitigen Verschlüsselung kombiniert werden, so dass der Zugriff auf die Daten auch für den Treuhänder erst nach Öffnung eines versiegelten Umschlags möglich ist, welcher den Schlüssel enthält, oder überhaupt nur in Mitwirkung des Dateninhabers. Der Zugriff auf die Daten kann dann also zur Verteidigung desjenigen erfolgen, der sie hinterlegt hat. Damit ein solches Vorgehen hinsichtlich Manipulation nicht ähnliche Qualitäten wie eine zentrale VDS bekommt, müssen Schlüsselmanagement und notarielle Pflichten angemessen definiert werden.

Content Logging

VDS beschränkt sich explizit "nur" auf die Rahmendaten. Das ist aus Gründen des Datenschutzes und der benötigten Speichermenge nachvollziehbar, stellt aber auch aus kriminalistischer Sicht eine enorme Einschränkung dar. Werden die Logdaten lokal und geschützt aufgezeichnet, können diese Vorbehalte allerdings vernachlässigt werden. Die so gewonnenen Daten wären in einem allfälligen Fall hingegen von grosser Bedeutung.

Apache ALOIS

Wie wir oben aufgeführt haben, erscheint es uns sinnvoll, die Vorratsdatenspeicherung dezentral zu organisieren. Dass ein solches Vorhaben technologisch nicht unmöglich ist, zeigt das aus ähnlichen Überlegungen entstandene Diaspora [2], ein Konkurrenzprojekt zu Facebook. Nicht zuletzt da auch immer noch das Schreckgespenst eines "Bundestrojaners" im Raume steht, muss ein solches Vorhaben zwingend mit Werkzeugen durchgeführt werden, die einer respektierten Open Source Umgebung entstammen, wie es z.B. die Apache Software Foundation (ASL) [3] darstellt.

Wofür steht Apache ALOIS?

Apache ALOIS [4] ist eine Software für die Sammlung, Aufsplittung und Korrelation von (Log-)Meldungen mit einer integrierten Reporting- und Alarmierungsfunktionalität. Die Akronym ALOIS steht für "Advanced Log Data Insight System". Apache ALOIS ist ein „Security Information & Event Manager“ (SIEM). Darunter versteht man ein EDV-Toolset, das innerhalb eines (Unternehmens-)Netzwerks Meldungen von unterschiedlichsten Geräten und Software sammelt und zentral abspeichert, um darauf aufbauend diese Meldungen zu interpretieren, zu analysieren, zusammenzufassen, zu korrelieren und allenfalls zu alarmieren. Ein SIEM wird dabei nie als vollständig automatisiertes System verstanden, es benötigt immer Menschen, die mit dem System interagieren und entsprechendes Know-how haben.

Der Begriff SIEM ist eine Kombination aus SIM ("Security Information Management") und SEM ("Security Event Management"), was zwei unterschiedliche Produktkategorien sind. Während SIMs eine Langzeitspeicherung, Analyse und Reporting von Logdaten bieten, stehen SEMs in erster Linie für ein Monitoring in Echtzeit, der Korrelation von Ereignissen und der Notifikation von als kritisch erachteten Begebenheiten. Ein SIEM vereint die Langzeitarchivierung von Logdaten mit der Korrelation von Ereignissen in einem einzigen Tool.

Während sich die meisten anderen SIEMs, ob Open Source oder propietär, primär um das technologische Sicherheits-Monitoring kümmern, konzentriert sich Apache ALOIS auf das Monitoring von sicherheitsrelevanten Inhalten. Es will dabei eine pro-aktive Rolle spielen in der Erkennung von potentiellem Datenverlust oder -Diebstahl, irrtümlichen Modifikationen von Dateien sowie unerlaubtem Zugriff.

Seit dem Herbst 2010 ist Apache ALOIS in Inkubation bei der Apache Software Foundation. Die Inkubationsphase verschafft einem Softwareprojekt eine Stabilität, die mit dejenigen anderer erfolgreicher ASF-Projekten vergleichbar ist. Projekte der Apache Software Foundation definieren sich durch einen kollaborativen, konsens-orientierten Entwicklungsprozess, kombiniert mit einer pragmatischen, geschäftsfreundlichen Lizenz. Apache-Projekte sind bestrebt, Software von höchster Qualität zu erstellen, die zu den Leadern im jeweiligen Feld gehören. Diese Eigenschaften sind auch bekannt als der "Apache way".

Die Aufnahme in den Inkubationsprozess setzt voraus, dass die Software einen stabilen Zustand erreicht und das Potential dazu hat, als vollwertiges Apache-Projekt aufgenommen zu werden. Apache ALOIS hat denn auch bereits über mehrere Jahre seine Stabilität im produktiven Einsatz bewiesen. Während die Software zwar schon immer Open Source war, wurde sie bisher in erster Linie durch eine einzelne Firma gewartet. Mit der Aufnahme in die Apache-Gemeinschaft soll der Entwicklungsprozess nun geöffnet werden. Dabei werden nicht nur neue Mitwirkende gesucht, das Projekt ist auch offen gegenüber Entwicklungen in Richtungen, die bisher nicht vorgesehen wurden.

Architektur von Apache ALOIS

Apache ALOIS besteht aus fünf interagierenden Modulen, die durch ihre weitgehende Unabhängigkeit die Skalierbarkeit eines SIEM sicherstellen:

  • Insink ist das Sammelbecken, das all die unterschiedlichen einkommenden Meldungen in Apache ALOIS aufnimmt. Es basiert teilweise auf der weit verbreiteten Software syslog-ng. [5] Das Modul Insink nimmt Nachrichten entgegen (UDP), wartet auf Meldungen (TCP), kann komplexe Nachrichten (Dateien, Mails) entgegennehmen und führt eine vorgängige Filterung durch, um einen Überfluss an Nachrichten zu verhindern.

  • Pumpy als teil von Insink stellt den FIFO-Buffer für eingehende Nachrichten dar. Implementiert als relationale Datenbank, welche die Originalmeldungen im RAW-Format enthält. In einer komplexen Umgebung kann es durchaus aus mehrere Instanzen von Insink und Punpy geben, z.B. für Gruppen von Hosts, für spezifische Meldungstypen oder zur Erhöhung der Ausfallsicherheit.

  • Prisma enthält die Funktionalität und Logik zur Aufsplittung der Meldungen in separate Felder, basierend auf regulären Ausdrücken. Prisma besteht eigentlich aus einem Satz aus "Prismi", welches jedes ein Prisma für einen Nachrichtentyp (Cisco, Apache httpd, etc.) steht. Auf eine Nachricht können auch mehrere Prismi angewendet werden. Dies ermöglicht die Verarbeitung von gestapelten Nachrichten, also z.B. weitergeleitete E-Mails, die komprimierte Dateien enthalten. Die so verarbeiteten Nachrichten werden in einer Datenbank namens Dobby abgespeichert. Aufgrund der Tatsache, dass Prisma in Ruby geschrieben ist, können Prismi interaktiv hinzugefügt und modifiziert werden (sofern die entsprechenden Berechtigungen vorhanden sind).

  • Dobby ist die zentrale Datenbank und enthält die Meldungen aufgesplittet nach Typen (pro Typ eine Tabelle) und Feldern. In einer produktiven Umgebung ist Dobby gewöhnlich getrennt von Pumpy installiert, um eine optimale Performance und Verfügbarkeit zu gewährleisten. Die aktuelle Implementierung basiert auf MySQL.

  • Der Analyzer enthält die beiden Subsysteme Lizard und Reptor. Lizard ist die Analyse-Engine inkl. Benutzeroberfläche von Apache ALOIS, in Ruby on Rails unter Verwendung von AJAX implementiert. Durch Lizard wird das interaktive Surfen auf den gesammelten Daten ermöglicht. Die Standard-Funktionalität beinhaltet Exklusion/Inklusion/Selektion, Sortieren, Filterung, das Erstellen von Ansichten sowie die ad-hoc Erstellung von textlichen und grafischen Reports. Reptor auf der anderen Seite ermöglicht die automatische Benachrichtigung bei Ereignissen aufgrund von vordefinierten Sichten, Filtern und Übereinstimmung von Pattern in diesen. Dies kann interaktiv im Browserinterface oder durch E-Mail geschehen.

Abbildung 1 zeigt eine Übersicht über den Datenfluss zwischen den Modulen:

http://incubator.apache.org/alois/images/overview-3tier-flowchart.png

[Abbildung 1. Komponenten und Datenfluss von Apache ALOIS]

Die Installation von Apache ALOIS ist sehr einfach. Zur Integration in eine bestehende Umgebung müssen einerseits die vorhandenen Systeme, Geräte und Applikationen angschlossen werden. Das geschieht im einfachsten Fall dadurch, dass deren syslog-Ziel auf die ALOIS-Instanz zeigt. Für einige komplexere Applikationen gibt es bereits Connectoren, weitere können einfach in verschiedenen Programmiersprachen hinzugefügt werden. Andererseits sind Filter und Berichte zu erstellen. Apache ALOIS verwendet dazu SQL und reguläre Ausdrücke. Es gibt ebenfalls bereits zahlreiche vorderfinierte Filter und Berichte.

Dank seiner modularen Architektur kann Apache ALOIS auf einem oder mehreren Servern installiert werden. Skalierbarkeit ist denn auch integrativer Bestandteil der Software. Auch ein Dienst in der Cloud ist einfach zu realisieren. Aber auch eine Installation auf dem persönlichen Desktopcomputer oder Laptop ist out-of-the-box möglich. Eine typische produktive Umgebung zeigt Abbildung 2.

http://incubator.apache.org/alois/images/DesignArchitecture.png

[Abbildung 2. Exemplarisches Setting von Apache ALOIS]

Apache ALOIS ist grundsätzlich offen für jede Art von Input, es müssen also nicht zwingend Logdaten sein. Die Standardschnittstellen sind syslog, SMTP und ein Datei-Upload. Im SIEM-Umfeld spricht man dabei von "Agenten", welche als Schnittstelle für spezifische Datenformate dienen und auch wieder verwendet werden können. Durch das Hinzufügen von weiteren Agenten kann Apache ALOIS sehr einfach für beinahe beliebige Datenformate erweitert werden. Die Nutzung von Apache ALOIS ist deshalb nicht auf ein SIEM beschränkt, sondern kann für jede Anforderungen konfiguriert werden, bei der das Sammeln, Analysieren, Korrelieren und Auswerten von Daten wichtig ist.

Zur erleicherten Anbindung von Software von Dritten, sei sie proprietär oder Open Source, beabsichtigt das Apache ALOIS Projekt einen "Service-Bus" mit standardisierten Schnittstellen zu implementieren. Die vorgeschlagene Architektur ist in Abbildung 3 aufgezeigt.

http://incubator.apache.org/alois/images/Apache ALOIS Service Bus_small.png

[Abbildung 3. Apache ALOIS Service Bus]

Somit wird es nicht nur einfach sein, ein weiteres System anzuhängen, sondern es können auch sehr einfach einzelne Bestandteile mit für eine bestimmte Anforderung besser geeigneten Tools zu ersetzen.

Das Web-Frontend

Das Webfrontend bietet ein einfaches Dashboard, das eine Übersicht in den aktuellen Stand gibt. Abbildung 4 zeigt eine Momentaufnahme dieser Übersicht.

http://incubator.apache.org/alois/images/KaLoOverview.png

[Abbildund 4. Dashboard von Apache ALOIS]

Sämtliche Filter und Berichte können interaktiv im Browser definiert werden. Es gibt auch die Möglichkeit, in der sogenannten Forensischen Konsole ad-hoc Abfragen auf Basis von SQL und regulären Ausdrücken vorzunehmen. Für jeden, der bereits mit Datenbanken gearbeitet hat, dürfte diese Konsole keine Einstiegshürde darstellen, wie Abbildung 5 aufzeigt.

http://incubator.apache.org/alois/images/forensicConsole.png

[Abbildung 5. Die Forensische Konsole von Apache ALOIS]

Als Open Source Software ist ALOIS selbstverständlich Work-In-Progress. Die aktuelle Version verfügt über die Mehrzahl der oben erwähnten Eigenschaften, aber wir rufen hiermit auch zur Mitarbeit an Konzept, Technologie und Integration auf, ebenso wie zur Diskussion sinnvoller Einsatzszenarien - sei es im Bereich VDS, Data Leakage Detection oder andere.

Schlussfolgerung

Zu Beginn haben wir aufgezeigt, dass sich die erhitzte Diskussion zur Vorratsdatenspeicherung durch den Aspekt der Denzentralisierung unter Umständen entpolarisieren liesse. Voraussetzung dafür ist allerdings eine transparente Software, die auf allen Geräten läuft und die Daten zu einem Treuhänder übermittelt. Technologisch ist dies realisierbar, wenn es sicherlich auch noch einige herausfordernde Probleme zu lösen gilt.

Als Grenzen der vorgeschlagenen "umgekehrten" Vorratsdatenspeicherung sehen wir insbesondere folgende Punkte:

  • Alois löst das Problem nicht, dass immer der Missbrauchsverdacht durch Regierungsstellen oder Unternehmen besteht. Aus Sicht des Einzelnen müsste eine persönliche Log-Datensammlung natürlich in dem Moment vernichtet werden, in welchem es strafbar wird, sie einer strafrechtlichen Untersuchung vorzuenthalten - sie soll schliesslich nicht zusätzlich belastend wirken.
  • Auch dass grosse zentrale Datensammlungen ein attraktives Ziel für Cyberkriminelle sind, kann Alois nicht lösen, sondern fügt dem zusätzliche dezentrale Datensammlungen hinzu. Alois muss daher selbstverständlich geschützt betrieben werden, stellt aber aufgrund der Verteilung ein weniger attraktives Ziel dar.
  • Schliesslich liegt es im Interesse des Einzelnen, seine Daten vollständig oder eben nur teilweise selbst zu sammeln. Hier sind neben rechtlichen und praktischen Erwägungen auch technische Restriktionen relevant: Beispielsweise ist es heute noch kaum möglich, die Rahmendaten der eigenen UTMS- und GSM-Nutzung zu erhalten. Hier sind aber Werkzeuge denkbar, die auf den moderenen Smartphones implementiert werden können.

Dessen ungeachtet erfüllt das Projekt Apache ALOIS bereits viele der Anforderungen, die für ein solches Vorgehen notwendig wären. Da es sich um ein Open Source Projekt mit offener Community handelt, ist die Transparenz gewährleistet und die fehlende Funktionalität liesse sich hinzufügen. Dieser Aufwand kann nicht - und sollte auch gar nicht - durch eine einzelne Person oder Organisation getragen werden. Die Apache Software Foundation als Host von Apache ALOIS bietet sowohl für Einzelpersonen, Regierungsstellen, Non-profit-Organisationen als auch Unternehmen gerade auch aus juristischer Sicht eine hervorragende Plattform dafür dar.

Wir verstehen diesen Text als Anreiz und nicht als Lösung. Einserseits sind viele politische und juristische Fragen noch nicht bis ins Detail durchdacht. Andererseits fehlt auch noch Funktionalität. Wir möchten deshalb alle Interessierten dazu einladen, an der Diskussion teilzunehmen sowie an Apache ALOIS mitzuwirken. Die Homepage des Projekts bietet dazu einige Einstiegspunkte.

Literatur

[1] http://noscript.net/

[2] https://joindiaspora.com/

[3] http://www.apache.org

[4] http://incubator.apache.org/alois/

[5] http://www.balabit.com/network-security/syslog-ng/

CLT2011 (last edited 2011-01-19 19:19:38 by UrsLerch)