Archiv für die Kategorie: ‘Datensicherheit’

Ergänzung zum Artikel: „Hoffen, dass es keiner merkt…“

Samstag, 27. August 2011

Wie in einem Update auf Heise-Online zu lesen war, äußerte sich ein CDU-Sprecher im Gespräch mit heise online: „Der Hackerangriff 2009 sei zwar registriert worden, zum damaligen Zeitpunkt konnte aber kein Datenverlust festgestellt werden.“

Leider macht diese Aussage die im Blogeintrag „Hoffen, dass es keiner merkt: Datenpanne bei der CDU“ geschilderte Situation in keiner Weise besser: Hackerangriffe können, wenn die passende Infrastruktur installiert ist, relativ einfach bemerkt werden. So treten z. B. Login-Versuche von unzulässigen IP-Adressen auf etc., Aktionen, die häufig auch von Kontrollsystemen außerhalb des angegriffenen Systems bemerkt werden können. Da Daten jedoch bei einem „Datendiebstahl“ nicht abhanden kommen, sondern überlicherweise kopiert werden, ist ein konkreter „Diebstahl“ erheblich schwerer festzustellen. Spuren des Kopierens finden sich häufig nur auf dem befallenen System selbst und sind dort durch Manipulation von Log-Datien und History-Dateien etc. durch den Angreifer verwischbar. Insofern wird man bei vielen Hackerangriffen zwar feststellen, dass diese stattgefunden haben, jedoch die genauen Tätigkeiten des Angreifers nicht nachvollziehen, sondern lediglich vermuten können.

Vor diesem Hintergrund, sehe ich eine Aussage, man habe den Angriff zwar registriert, aber keinen Datenverlust festgestellt, für leichtsinnig.

Wem vertrauen Sie? S/MIME-Zertifikate in der Praxis

Dienstag, 26. Juli 2011

Erfreulicherweise nimmt der Einsatz von E-Mail-Verschlüsselung und E-Mail-Signierung zu. Es gibt keinen anderen Weg, die Vertraulichkeit von E-Mails zu gewährleisten. An dieser Stelle möchte ich nicht auf die prinzipiellen Möglichkeiten oder die unterschiedlichen Verfahren eingehen, sondern ausschließlich auf Risiken beim S/MIME-Verfahren hinweisen. S/MIME ist nicht prinzipiell schlecht; man darf diese Technik jedoch, wie jede Technik, nicht blind einsetzten, sondern muss sich auch als Benutzer und somit evtl. Laie der Schwächen des Prinzips bewußt sein.

Das Prinzip von S/MIME

Das S/MIME-Verfahren zur Verschlüsselung und Signierung von E-Mails ist in allen aktuellen Mailprogrammen vorhanden. Das Verfahren beruht auf einer Vertrauenshierarchie: Einige zentrale Instanzen, normale Firmen, gelten „per Definition“ als vertrauenswürdig. Dies sind die sogenannten CAs (Certificate Authorities). Diese vertrauen nun anderen Firmen, den Unter-CAs und diese ggf. wiederum Unter-Unter-CAs. Und irgendeine dieser Unter-Unter-CAs bestätigt in einem Zertifikat, dass Sie „Sie“ sind oder Ihr E-Mail-Partner derjenige ist, der er vorgibt, zu sein. Sie vertrauen nun der CA und damit automatisch allen Unter-CAs, Unter-Unter-CAs, etc. sowie allen Zertifikaten, die diese ausgestellt haben. Sie wissen genau, wie die Unter-Unter-CAs Ihre E-Mail-Partner geprüft haben? Sie kennen die internen Maßnahmen aller  (Unter-)CAs genau und sind sich sicher, dass keine „falschen“ Zertifikate ausgestellt werden? OK, damit haben Sie schon die große Schwäche dieses Verfahrens entdeckt. Sie können einem solchen Zertifikat nicht blind vertrauen. Hinzu kommt noch, dass es in den letzten Monate mehrfach „elektronische“ Einbrüche bei CAs und Unter-CAs gegeben hat und es so einen unbefugten Zugriff auf die Zertifizierungsinfrastrukturen gab.

In dem meisten E-Mail-Programmen sind die Zertifikate der CAs jedoch als „vertrauenswürdig“ eingetragen, es wird also eine trügerische Vertrauenswürdigkeit vorgetäuscht: Von E-Mails mit von diesen CAs „unterschriebenen“ Zertifikaten werden mit  einem „Siegel“-Symbol versehen. Sie wissen nun, dass Sie diesem Symbol nicht unüberprüft trauen können.

Es gibt noch einen weiteren Grund für das Misstrauen. Nahezu jede (Unter-)CA bietet verschiedene Qualitäten an: Das eine Zertifikat bestätigt nur, dass die angebliche  Absender-E-Mail-Adresse richtig ist, das andere Zertifikat, dass die E-Mail von der Person verschickt wurde, die im Namen des Zertifikates steht. An den Symbolen im E-Mailprogramm können Sie das nicht unterscheiden. Vielmehr müssen Sie sich die Details der Zertifikate ansehen und überprüfen, wass die CA dort reingeschrieben hat. Ein Text wie „Persona Not Validated“ sagt relativ eindeutig aus, dass die Person eben nicht überprüft wurde. Ein Text wie „Digital ID Class 1“ hat die selbe Bedeutung, ist aber erheblich weniger eindeutig. Und der Aufwand, an ein solches, faktisch nicht viel aussagendes Zertifikat zu kommen, entspricht 5 Minuten: Man braucht nur temporären Zugang zum E-Mail-Server und bekommt das Zertifikat zugeschickt.

Ihre Folgerungen

Die Folgerungen sind einfach:

  1. Vertrauen Sie keinen CAs und von diesen unterschriebenen Zertifikaten, die Sie nicht kennen. Am besten entfernen Sie die CAs aus der Liste vertrauenswürdiger CAs in Ihrem E-Mailprogramm. Dann können Sie gezielt die CAs aufnehmen, denen Sie vertrauen (z. B. Ihrem Arbeitgeber, wenn  dieser eine eigene PKI (Public-Key-Infrastruktur) betreibt und die Personen korrekt überprüft).
  2. Überprüfen Sie die Zertifikate, die an den E-Mails dranhängen. Bei jedem Zertifikat gibt es einen „elektronischen Fingerabdruck“, eine große Zahl. Gleichen Sie diese (einmalig) telefonisch mit Ihrem Partner ab, dann wissen Sie, dass E-Mails, die mit diesem Zertifikat signiert sind, „echt“ sind.
  3. Haben Sie die nicht-vertrauenswürdigen Zertifikate aus Ihrem E-Mailprogramm entfernt (siehe 1.), dann können Sie die telefonisch überprüften Zertifikate aus 2. Ihrem E-Mail-Programm hinzufügen: In Zukunft wird Ihr E-Mailprogramm nur bei genau diesen Absendern das „Siegel“ anzeigen – und Sie müssen den Fingerabruck in Zukunft nicht mehr manuell prüfen.
  4. Das gleiche gillt für die Verschlüssellung in umgekehrter Richtung: Schließlich sollen Ihre Mails ja für den Empfänger passend verschlüsselt sein und nicht für einen dubiosen E-Mail-Partner.

Wenn Sie Fragen haben oder Verschlüsselung bei sich oder Ihrem Unternehmen einführen wollen: Sprechen Sie mich an.

 

Nun ist es eindeutig: Cloud-Verarbeitung von personenbezogenen Daten bei US-Unternehmen unzulässig!

Freitag, 1. Juli 2011

US-Behörden, besonders die Strafverfolgungsbehörden, haben Zugriff auf Daten von Kunden, die bei US-Unternehmen gespeichert sind. Dies gilt auch, wenn die Daten in europäischen Rechenzentren gespeichert werden. Nach dem „Patriot Act“ müssen US-Firmen den US-Strafverfolgungsbehörden Zugriff auf die bei Ihnen gespeicherten Daten geben, unter Umständen sogar ohne die Kunden zu informieren. Microsoft, als ein Cloud-Anbieter, gibt dies z. B. offen zu: http://www.microsoft.com/online/legal/v2/?docid=23

Doch welche Auswirkungen hat dies für Nutzer von Cloud-Diensten? Die Auswirkungen sind einfach und eindeutig:

  1. Kein Nutzer von Cloud-Diensten kann sich auf die Vertraulichkeit seines Anbieters verlassen, wenn dieser unter US-Einfluss steht.
  2. Nach bundesdeutschem Datenschutzrecht dürfen keine personenbezogenen Daten ohne Zustimmung des Betroffenen in außereuropäische Länder übertragen werden. In §4b steht: „Die Übermittlung unterbleibt, soweit der Betroffene ein schutzwürdiges Interesse an dem Ausschluss der Übermittlung hat, insbesondere wenn bei den in Satz 1 genannten Stellen ein angemessenes Datenschutzniveau nicht gewährleistet ist.“ Die USA gelten als Land ohne angemessenes Datenschutzniveau. Hier widersprechen sich also US- und bundesdeutsches Recht. Da die Gefahr besteht, dass sich die US-Firmen als Cloud-Betreiber an US-Recht halten werden, scheiden US-Firmen als Datenverarbeitungsdienstleister für personenbezogene Daten für deutsche Firmen aus. Firmen, die also personenbezogene Daten in der Cloud bei US-Firmen speichern oder verarbeiten, verstoßen gehen das Bundesdatenschutzgesetz.

Fazit:

  1. Überprüfen Sie, ob Sie die Cloud-Dienste von Firmen nutzen, die unter US-Kontrolle stehen.
  2. Falls ja, übertragen Sie die Daten unverzüglich zu datenschutzrechtlich konformen Dienstleistern.
  3. Überprüfen Sie, ob Sie ggf. ein Sonderkündigungsrecht Ihres Vertrages mit dem US-Dienstleister haben, denn die öffentliche Aussage zu den Zugriffsmöglichkeiten ist relativ neu (28.6.2011).