Thomas Fürling beschäftigt sich seit über 20 Jahren mit Data Loss Prevention und Cloud Security. Wir haben den CEO und Gründer der Firma e3 gefragt, wie der Bund den Datenverlust durch den Xplain-Hack hätte verhindern können und wie sich die Verwaltung jetzt aufstellen muss, damit vergleichbare Databreaches künftig nicht mehr passieren.

Durch den Hack auf Xplain sind Daten von zahlreichen Behörden der Bundesverwaltung im Darkweb gelandet. Was ist schiefgelaufen? Das primäre Problem war, dass Xplain überhaupt echte Kundendaten auf seinen Systemen speicherte. Es wundert mich, dass es intern offenbar keine Weisung gab, dass nicht mit "echten" Daten gearbeitet werden darf. Dass Daten in dieser Menge einem Dienstleister ohne Verarbeitungsaufgabe zur Verfügung gestellt werden, darf nicht passieren.

Die Verantwortung für das Desaster liegt also in erster Linie beim Bund? Der Bund hätte anonymisierte oder pseudonymisierte Testdaten herstellen und diese dem Dienstleister zur Verfügung stellen müssen. Dienstleister sollten nie mit produktiven Daten in Berührung kommen müssen. Das darf höchstens auf den Testsystemen des Kunden geschehen.

Die Herstellung von Testdaten ist teuer. Korrekt. Das ist teuer, aufwändig und kompliziert. Das ist deshalb eine typische Möglichkeit, um zu sparen beziehungsweise eine "Abkürzung" zu nehmen. Aber für die Zusammenarbeit zwischen dem Bund und externen IT-Dienstleistern wäre es aber essenziell. Es liegt definitiv am Auftraggeber, in diesem Fall am Bund, Testdaten zu liefern und entsprechenden Umgang damit einzufordern.

Im Idealfall werden solche Anforderungen schon in der Ausschreibung formuliert? Ja, denn Anbieter müssen das bei ihren Offerten einkalkulieren können.

Warum wird das nicht gemacht? Weil sich in der Bundesverwaltung offenbar niemand dafür verantwortlich fühlt. Jedes Departement ist sein eigenes Königreich und macht, wie es die handelnden Personen gerade für richtig halten. Hier wären Standards für alle Beteiligten "gesünder".

Ich behaupte, dass auch die Kosten eine Rolle spielen. Security ist teuer und man hat die Hoffnung, "uns passiert schon nichts" – solange nichts passiert. In erster Linie verkompliziert Security ein Projekt. Deshalb sagen viele Verantwortliche: "Das mache ich dann am Schluss noch", weil man sein Projekt nicht gefährden will. Zudem gibt's viel zu wenig Security-Spezialistinnen und -Spezialisten in den verantwortlichen Positionen, die gewisse Standards einfordern.

Security am Schluss noch hinzufügen ist doch eine denkbar schlechte Idee? Ja, sie muss von Anfang an mitgedacht werden. Das verlangen die Prinzipien des "Security by Design", die heute "State of the Art" sind.

Wie viel teurer wird ein Projekt, wenn das konsequent gemacht wird? Zwischen 5 und 20%, je nach genutzter Technologie. Das ist vertretbar und in jedem Fall günstiger, als im Nachhinein einen Breach aufräumen zu müssen.

Wie sicher muss ein System denn sein? Das ist schwierig zu sagen und hängt in erster Linie von den Daten ab, die bearbeitet werden. Kurz gesagt: Man muss selbst nur das schwierigere Ziel sein als alle anderen. Das genügt, solange das System nicht gezielt angegriffen wird.

Losgelöst vom Xplain-Fall: Es wird immer schwieriger, sicherer zu sein als alle anderen. Dies, weil alle ihre Daten in den gleichen Cloud-Lösungen speichern. Die Clouds der Hyperscaler sind alternativlos, das ist so. Sie müssen einfach unter vernünftigen Rahmenbedingungen genutzt werden.

Entsprechende Rahmenbedingungen scheinen auf gutem Weg zu sein. Zwischen der EU und den USA gibt es wieder ein Datenschutzabkommen. Die Schweiz hat noch kein entsprechendes Abkommen ratifiziert. Ausserdem hat der Bund auch mit einem chinesischen Cloud-Anbieter einen Vertrag unterzeichnet. Und nicht zuletzt finde ich, dass Verträge mit "Big Tech" generell nicht dabei helfen, sich gegen Datenverluste zu schützen. Dies, weil sie wohl nicht durchgesetzt würden.

Aber wenn Big Tech alternativlos, aber nicht vertrauenswürdig ist – was dann? Verschlüsseln.

Die Antwort überrascht nicht angesichts des Portfolios Ihrer Firma. Wenn es um die Verschlüsselung von E-Mails oder Dateien geht, braucht es uns nicht. Das geht zum Beispiel mit Rights Management problemlos. Bei der Verschlüsselung von Cloud-Anwendungen hingegen können wir helfen. Ziel ist, dass der Cloud Provider weder den Schlüssel, noch den Algorithmus oder den Ort der Verschlüsselung kontrollieren kann. Die Cloud-Schutzmassnahmen eines Cloud-Providers helfen in der Regel nicht gegen den Provider selbst. Umgesetzt haben wir, was wir "Bring your own Encryption" nennen, zum Beispiel mit dem Kantonsspital Graubünden.

Das heisst konkret, Sie schalten Ihren Dienst zwischen einen Cloud-Provider wie AWS, Azure oder Google Cloud und den Kunden und verschlüsseln die Verbindung? Genau, wahlweise gehostet beim Kunden selbst, bei einem lokalen Rechenzentrums-Anbieter oder direkt im Datacenter des Cloud-Providers. Durch die Verschlüsselung ist man dann auch nicht mehr zwingend auf den teureren Datenstandort Schweiz angewiesen, sondern kann seine Daten und Systeme irgendwo auf der Welt hosten.

Auch ohne Verschlüsselung ist eine Cloud-Lösung eines Big-Tech-Unternehmens immer noch sicherer, als Daten und Software selbst On-Premises zu hosten. Das zeigen ja unter anderem auch Rechtsgutachten. Die erste Aussage ist korrekt. Zur zweiten: Das Rechtsgutachten basiert auf einer statistischen Berechnung, die das Risiko eines möglichen Datenverlusts voraussagt. Ich halte das für spekulativ. Der grenzüberschreitende Datenverkehr ist ohne Verschlüsselung nicht geregelt.

Aber der Datenverkehr ist ja nicht grenzüberschreitend, wenn man seine Daten in den Schweizer Datacentern von AWS oder Microsoft hat. Rechtlich mag das korrekt sein, aber als Security-Spezialist fühle ich mich nicht wohl bei diesem Argument. Ich habe nicht das Gefühl, dass mich eine Landesgrenze bei einem globalen Big-Tech-Unternehmen speziell schützt. Der Schutzmechanismus muss von einem anderen Provider kommen als von jenem, der selbst die Dienstleistung erbringt.

Warum? Weil der Dienstleister die eigenen Schutzmechanismen immer umgehen kann, wenn er muss. Es ist wie die natürliche Gewaltentrennung in der Politik oder in Unternehmen, bei der Trennung von Geschäftsleitung und Verwaltungsrat. Diese sollte auch bei der Sicherung von Cloud-Diensten gelebt werden.