Fortschritte bei SSL

Drei primär browserbasierte Weiterentwicklung in Bezug auf SSL, die aus meiner Sicht mehr zum Einsatz kommen sollten: SNI, HSTS und DNSSEC-basierte Validierung von SSL-Zertifikaten.

SNI

Server Name Indication (vgl. RFC 3546, Kapitel 3.1) ermöglicht das Bereitstellen von SSL-gesicherten Webseiten über HTTPS unter einer IP-Adresse. Ohne SNI benötigt man für jede SSL-gesicherte Webseite eine eigene IP-Adresse. Das ist aktuell mit IPv4 bei vielen Anbietern nicht möglich oder mit zusätzlichen Kosten verbunden. IPv6 wird dieses Problem lösen, das kann aber noch ein wenig dauern.

SNI wird von vielen Browsern unterstützt, aber noch nicht von allen. Nutzer des Internet Explorers unter Windows XP sowie beispielsweise auch Nutzer von Android-basierten Geräten, die nicht bereits Version 4 installiert haben, bekommen weiterhin eher abschreckende Zertifikatswarnungen. Dieses Problem wird sich erfahrungsgemäß innerhalb der kommenden Jahre lösen, schöner wäre es aber, wenn Hersteller grundsätzlich hachhaltig arbeiten würden und auch bei älteren Plattformen noch Aktualisierungen einpflegen würden.

HSTS

HTTP Strict Transport Security (vgl. RFC 6797) ermöglicht es, für Domänen die Nutzung von HTTPS zu erzwingen und gleichzeitig die zu akzeptierenden Zertifikate festzulegen.

Dies kann zum einen auf Browser-Seite konfiguriert werden. Benutzt man Google Chrome, so kann man diesen Mechanismus über die Eingabe von "chrome://net-internals/#hsts" manuell konfigurieren.

Zum anderen kann dies die Betreiberin einer Webseite einfach durch zusätzliche Header aktivieren, z.B. "Strict-Transport-Security: max-age=16070400; includeSubDomains"

Firefox, Chrome und Opera unterstützten HSTS schon seit mehreren Jahren, für den "typischen Endanwender" ist diese Funktion jedoch immer noch zu schwierig zu konfigurieren. Der Internet-Explorer unterstützt dies leider noch nicht. Wünschenswert wäre eine einfach Einbindung in die "Smartbar" der Browser. Ein einfacher Rechts-Klick auf "Feste SSL-Sicherheit aktivieren" und sprechende Warnmeldungen, wenn sich das SSL-Zertifikat ändert, wären ein Schritt in die richtige Richtung. Momentan bieten Plugins wie HTTPS-Everywhere oder NoScript ähnliche Funktionen.

DNSSEC-basierte Validierung von SSL-Zertifikaten

Noch nicht standardisiert und auch bisher nur als Prototyp umgesetzt ist die Validierung von SSL-Zertifikaten auf Basis von DNSSEC (vgl. Blog-Beitrag von Jan-Piet Mens).

Momentan verlässt man sich auf "vertrauenswürdige Stammzertifizierungsstellen", die auf mehr oder minder nachvollziehbare Art ihre eigene Vertrauenswürdigkeit nachweisen und dies dann auch für die Betreiber von Webseiten anbieten, die SSL-Zertifikate verwenden wollen. Aktuell zeigen alle Browser eine Warnmeldung an, wenn die Betreiberin einer Webseite ein Zertifikat einsetzt, welches nicht von einer "vertrauenswürdigen Stammzertifizierungstelle" bestätigt wurde. Eine detaillierte Auseinandersetzung mit den Vorteilen und Nachteilen dieses "Vertrauens"-Modells würde diesen Blog-Beitrag sprengen, deswegen nur soviel: Das muss auch anders gehen. Ich hatte hierzu auch was für die bpb geschrieben.

Ein Weg wäre die Nutzung von DNSSEC. Die Betreiber von Webseiten könnten im DNS die Prüfsummen Ihrer Zertifikate veröffentlichen. Browser prüfen dann beim Aufbau einer HTTPS-Verbindung, ob die Prüfsumme des aktuellen Zertifikats mit der im DNS veröffentlichten Prüfsumme übereinstimmt. Wenn dies der Fall ist, sind auch "selbst-signierte" Zertifikate vertrauenswürdig.

Aktuell ist dies in den Browsern noch nicht umgesetzt. Es gibt aber schon einzelne Plugins, die dies ermöglichen würden. Dies wäre meiner Meinung nach ein guter Weg, um die Nutzung von SSL weiter voranzutreiben. Ob dies mit den Geschäftsinteressen der Betreiber von "vertrauenswürdigen" Zertifizierungsstellen vereinbar ist, ist fraglich, aber letztendlich auch: egal.

Umgang mit Sicherheitsvorfällen

Häufig geht im täglichen Datenschutz- und Datensicherheits-Geschäft ein Bereich ein wenig unter, der einen wesentlichen Einfluss auf das wirklich erreichte Sicherheits- und Datenschutzniveau hat: der Umgang mit Sicherheits- und Datenschutzvorfällen.

In der Praxis fehlt es leider an mustergültigen, öffentlich einsehbaren Vorfällen, an denen man lernen und seine eigene Organisation trimmen kann. Aktuell gibt es ein gutes Beispiel, an dem man einiges lernen kann:

Am 17. November 2012 hat der FreeBSD Security Officer einen Sicherheitsvorfall veröffentlicht: http://www.freebsd.org/news/2012-compromise.html

FreeBSD ist ein freies Unix, dass von einer Vielzahl von Entwicklern weiterentwickelt wird. Hierzu werden zentrale Systeme zur Quellcodeverwaltung und zur Koordinierung der Entwicklungsarbeit betrieben. Zwei von diesen Systemen sind kompromittiert worden.

Die genaueren Umstände der Sicherheitslücke kann man im Report nachlesen. Anhand des guten Reports kann man einige wesentliche Erfolgsfaktoren herausarbeiten, die man beachten sollte, wenn man als Sicherheits- oder Datenschutzbeauftragter einen Sicherheitsvorfall bearbeiten muss.

Vorab: Der Baustein 1.8 "Behandlung von Sicherheitsvorfällen" der IT-Grundschutz-Kataloge des Bundesamts für Sicherheit in der Informationstechnologie (BSI) ist eine gute Ausgangsbasis.

Kein Fingerpointing, keine Zuweisung von Schuld: Natürlich hat irgendjemand einen Fehler gemacht, wenn es einen Vorfall gab. Sich primär auf die Schuld-Frage zu konzentrieren behindert jedoch ein erfolgreiches Sicherheits- und Datenschutzmanagement. Wenn die "schuldige Person" ordentlich "eins auf den Deckel" bekommt, man evtl. sogar das Verhalten noch innerhalb der Organisation "an den Pranger" stellt dann erreicht man genau eins: Eine Kultur des Vertuschens und "unter-den-Teppich-kehrens". Natürlich ist es wichtig, die Ursachen des Vorfalls so klar und deutlich wie möglich herauszuarbeiten. Aber nicht auf Kosten der betroffenen Mitarbeiterinnen und Mitarbeiter. Das korrekte Melden und saubere Bearbeiten eines Vorfalls muss honoriert und nicht bestraft werden.

Kultur der kontinuierlichen Verbesserung: Vorfälle sind ein wichtiger Indikator, wo es technische und häufiger: organisatorische Mängel gibt. Ziel der Bearbeitung des Vorfalls ist die Mängelbehebung. Hier ist es wichtig, dass man bei jedem Vorfall prüft, ob es ein Einzelfall ist oder ob dahinter ein grundsätzlicheres Problem besteht. Als Sicherheits- oder Datenschutzbeauftragter, aber auch als Vorgesetzter muss man diese Kultur des Hinterfragens und Analysierens unterstützen. Natürlich ist es wichtig, die Lücke schnell zu schließen und weitere, schadhafte Auswirkungen eines Vorfalls zu begrenzen. Das Ergreifen von Sofortmaßnahmen ist aber nur der erste Schritt. Wirkliche Tiefenwirkung erreicht man erst durch eine umfassende Analyse.

Aufklärung so detailliert wie möglich: Für die Bewertung und das Ergreifen von wirksamen Sofortmaßnahmen ist es wichtig, den Sicherheitsvorfall so genau wie möglich zu analysieren. Es ist wichtig, alle Ereignisse möglichst genau zeitlich einzuordnen. Erst mit einer zeitlichen Komponente findet man Abhängigkeiten und auch mögliche Drittwirkungen auf andere Systeme und Komponenten. Gerade die "Zeitfindung" führt bei Sicherheitsvorfällen zu einer ersten, entscheidenden Abgrenzung und ist eine gute Ausgangsbasis für die Bewertung möglicher Auswirkungen.

Abgrenzung, Abgrenzung, Abgrenzung: Zur Bewertung eines Sicherheits- oder Datenschutzvorfalls muss man ein Modell über die möglichen Auswirkungen des Vorfalls erarbeiten. Diese Modellbildung funktioniert nur, wenn man die Grenzen des Vorfalls und seiner möglichen Auswirkungen klar umreissen kann. Erst durch das Festlegen auf möglicherweise betroffene Komponenten, Systeme, Daten, Personen... kann man die weiteren Schritte zur Mängelbehebung und Information planen. Die Kernfrage hierbei ist nicht, welche Systeme möglicherweise betroffen sind, sondern vielmehr, für welche Systeme man nachweisen kann, dass sie nicht betroffen sind.

Wiederholbare Installation- und Konfiguration von Systemen: Ist für ein System nicht nachweisbar, ob es von einem Sicherheitsvorfall betroffen ist oder nicht, muss das System neu aufgesetzt werden. Dies ist umso schmerzhafter, je weniger Dokumentation vorhanden ist und je mehr händische Arbeit notwendig ist. Organisationen, die ihre Systeme als "dokumentationsfreie Manufaktur" betreiben, tun sich hiermit erfahrungsgemäß sehr schwer. Für Organisationen, die verlässliche Build- und Restore-Prozesse haben, ist die Neu-Installation und Neu-Konfiguration von Systemen nur lästig, aber nicht existenziell bedrohend. Aus der Erfahrung mehrerer Sicherheitsvorfälle: Es ist einfacher neu aufzusetzen als zu flicken.

Fokus auf Maßnahmenenpfehlung: Die korrekte Aufarbeitung des Vorfalls ist wichtig, keine Frage. Wichtiger ist jedoch, konkrete Handlungsempfehlungen auszusprechen. Je konkreter, desto besser. Das gilt insbesondere für die Fälle, wo es eine Plicht zur Information der Betroffenen gibt (vgl. z.B. § 42a BDSG oder § 27a LDSG Schleswig-Holstein

Und abschließend noch eine Klarstellung zu einem häufigen Mythos: Die Anzahl der Vorfälle ist keine geeignete Kennzahl für ein Managementsystem. Weder die absolute Anzahl, noch die Tendenz ("10% weniger Vorfälle als im Vorjahr") sagt etwas über das Niveau und das Funktionieren des Datenschutz- oder Sicherheitsmanagements aus. Wenn man dringend Kennzahlen hierzu braucht, sollte man diese eher auf die Qualität der Sicherheitsvorfälle beziehen, z.B. die durchschnittliche Anzahl der betroffenen Systeme, ob personenbezogene Daten von Kunden betroffen waren,....

Die bisherige Erfahrung zeigt, dass die Qualität im Umgang mit Sicherheits- und Datenschutzvorfällen ein guter Indikator dafür ist, wie gut das Datenschutz-. und Sicherheitsmanagement einer Organisation funktioniert.


Datenthemen: Und so fängt es an.

Ein neues Projekt, neue Ideen und gute Vorsätze.

Datenthemen soll Neuigkeiten und interessante Themen rund um den Umgang mit Daten zusammenfassen und darstellen.

Ein Schwerpunkt wird auf dem Bereich der informationellen Selbstbestimmung liegen. Der zweite Schwerpunkt wird auf dem Bereich der offenen, freien Datenbereitstellung und -verarbeitung (Open Data und Informationsfreiheit) liegen. Diese beiden Themen liegen häufig in einem Spannungsfeld. Hier hoffe ich, beide Themenbereiche bedienen zu können.

Ich befasse mich beruflich mit diesen beiden Themenbereichen, möchte auf diesen Seiten aber die Aspekte etwas genauer darstellen, die in der beruflichen Praxis häufig zu kurz kommen oder dann doch nicht genau den eigenen Aufgabenbereich treffen.

Fester Bestandteil dieses Blogs wird ein Podcast sein. Der Podcast wird regelmäßig einen Überblick über Themen und Neuigkeiten aus den Bereichen Datenschutz, Datensicherheit und Informationsfreiheit bieten. Unregelmäßig werde ich einzelne Themen vertiefen und hierzu eventuell Kollegen zum Interview bitten.

Also: Ich habe viel vor. Ein Anfang ist hiermit gemacht.