De Maizières IT-Sicherheitssimulationsgesetz

Vor ein paar Tagen wurde der Entwurf eines IT-Sicherheitsgesetzes von von Innenminister Thomas de Maizière vorgestellt. Wir wollen das zum Anlass nehmen, um uns hier in loser Folge ein wenig über mögliche gesetzliche Regelungen auszulassen, die der Verbesserung der Sicherheit von IT-Systeme dienen können. Anna hat hier vor ein paar Tagen schon ausführlicher darüber geschrieben, hier soll es noch mal speziell um Meldepflichten und die Verteilung von Verantwortung gehen.

Das Ziel: Die signifikante Verbesserung der IT-Sicherheit

Die Einleitung des Entwurfes klingt eigentlich erst einmal vielversprechend:

„Mit dem Gesetz soll eine signifikante Verbesserung der Sicherheit informationstechnischer Systeme in Deutschland erreicht werden. Die vorgesehenen Neuregelungen dienen dazu, den Schutz der Verfügbarkeit, Integrität und Vertraulichkeit datenverarbeitender Systeme zu verbessern und der gestiegenen Bedrohungslage anzupassen.“

Leider wird in dem Entwurf sehr schnell deutlich, dass dieses Gesetz seinem Anspruch nicht mal im Ansatz gerecht werden kann. Einer der Kernaspekte des Entwurfs, über die auch schon länger diskutiert wird, bildet die Meldepflicht bei sicherheitsrelevanten Vorfällen. Das Innenministerium scheint aber gar nicht daran gelegen zu sein, dass diese Meldungen einen sinnvollen Zweck erfüllen können. Dass die vorgestellte Form der Meldepflicht dies nicht tun wird sieht man daran, dass es eine Möglichkeit der anonymen Meldung geben soll und die Betroffenen gar nicht zwangsläufig erfahren, was passiert ist. Man muss sich das dann wohl so vorstellen, dass man vielleicht irgendwo zu lesen bekommt, das irgendwer irgendein Problem hatte und das irgendwie gefixt wurde. Das kann man sich meines Erachtens vollkommen schenken, denn das sorgt nicht für mehr Sicherheit, nicht für ein besseres Problembewusstsein, es sorgt für genau gar nichts ausser einer oder mehrerer Stellen in einer Behörde, die das in Excelsheets eintragen und irgendwelche Zahlen präsentieren können.

Meldepflichten, aber richtig!

Meldepflichten ergeben nur Sinn, wenn Unternehmen ihre Kunden bzw. Behörden die Öffentlichkeit über alle Vorfälle ohne Ausnahmen unterrichten. Das muss in erster Linie für all jene Unternehmen und Behörden gelten, die personenbezogene Daten verarbeiten, denn Betroffene müssen wissen, wo ihre Daten abgeflossen sind. Das Argument der Industrielobby, die Unternehmen würden damit zusätzlich belastet, ist schon im Kern kaputt: Wessen Geschäft die Entwicklung von Software oder das Betreiben von Services ist und keine Strukturen hat, um mit sicherheitsrelevanten Problemen entsprechend umgehen, der sollte so ein Geschäft nicht betreiben oder zumindest zur ehrlichen Aussage gezwungen werden, dass er das nicht kann, so dass Kunden die Wahl haben, sich ein anderes Unternehmen zu suchen, mit dem sie Geschäfte machen. Was meines Erachtens grundsätzlich fehlt in diesem Entwurf ist die Verpflichtung für Unternehmen, überhaupt einen Kontakt für Sicherheitsfragen einzurichten. Wer schon mal versucht hat, Sicherheitsschwankungen bei einem Unternehmen zu melden, der wird erlebt haben, was das für ein Trauerspiel werden kann. Aber auch die weit vertreitete Betrachtung, ein Sicherheitsvorfall sei in erster Linie ein PR-GAU, den es zu fixen gilt, verniedlicht Ernsthaftigkeit und Tiefe des Problems.

„Klassische“ Kriminalität und Internetkriminalität unterscheiden sich in ihren Folgen ganz gravierend. Gucken wir uns kurz an, was das bei Einbrüchen bedeutet: Ein Wohnungseinbruch wird deutlich erkannt, der nominelle Schaden ist der Verlust plus die Reparatur und wird über Versicherungen reguliert. Bei Einbrüchen in technische Systeme äussert sich der Schaden aber ganz anders (und wird auch nicht immer erkannt). Um ein extrem vereinfachtes Beispiel zu nehmen, um das zu verdeutlichen: Jemandem werden Zugangsdaten zum Email-Account gestohlen. Mit Zugriff auf diesen Account kann der Angreifer Daten finden, um weitere Angriffe durchzuführen. So kann eine Sicherheitsschwankung in einem Unternehmen sehr schnell zu einem Problem für andere werden, die gar keine Verbindung zu diesem Unternehmen haben. Den Schaden tragen also oft Dritte, nicht der, der den Schaden letztendlich zu verantworten hat. Das Problem verschärft sich aber ganz erheblich, wenn der Kunde nicht weiss, dass seine Daten kompromittiert wurden und kann auch keinerlei Gegenmaßnahmen, wie z.B. den Wechsel eines Passwortes, einleiten oder seinerseits Betroffene warnen.

Der unglückliche Hase

Ross Anderson hat es vor einiger Zeit schön auf den Punkt gebracht: „If Alice guards a system and Bob pays the cost of failure, then Bob will not be a very happy bunny“. Genau so sieht es heute aus, und das ist auch einer der Gründe für die weit verbreitete technische Unsicherheit. Dieses sehr einfache Beispiel zeigt aber auch einen möglichen Ansatz, in welche Richtung Überlegungen gehen können, nämlich in eine, die mit „Liabilities“ bezeichnet wird, also der Verantwortung zum ordentlichen Umgang mit Fragen der technischen Unsicherheit. Dazu gehört z.B., neben vernünftigen Meldepflichten, bei Software eine Verpflichtung, gefundene und gemeldete Sicherheitslücken schnellstmöglich zu fixen und könnte darüber hinaus mit der Möglichkeit einhergehen, bei Nichtbeachtung mit einer Strafe geahndet oder mit Möglichkeiten zum Schadensersatz versehen zu werden. Richtig sinnvoll ist das allerdings nur für Closed Source Software, da im Falle von Open Source Software die Betroffenen das entweder selbst fixen oder jemanden dazu beauftragen können, also anderes als bei geschlossener Software, wo dies der Anbieter tun muss.

Entsprechende Regeln könnte es auch für Services geben, die personenbezogene Daten verarbeiten, wobei man fairerweise zugeben muss, dass da eine Menge Detaildiskussion nötig ist. Denn es könnte natürlich auch darum gehen, Nutzern Verpflichtungen aufzubürden, um überhaupt einen Schaden geltend machen zu können (z.B. der Verpflichtung zur Durchführung von Sicherheitsupdates).

Der Weg ist hier also nicht, IT-Sicherheit für so wenig Geld und Aufwand wie möglich zu bekommen, sondern technische Unsicherheit über kurz oder lang teurer zu machen als technische Sicherheit, in dem künstliche Anreize für technische Verlässlichkeit geschaffen werden.

Ich hätte gerne diese und eine Reihe daran angelehnte Fragen am Rande der Telemedicus Sommerakademie nächstes Wochenende in Berlin mit einigen der dort anwesenden Fachjuristen diskutiert, auch wenn der thematische Hauptschwerpunkt ein anderer ist, nämlich Überwachung. Aber ich sehe hier einen Zusammenhang und mögliche Wege, das Problem zu adressieren. Denn Überwachung ist nicht zuletzt auch ein Problem von IT-Unsicherheit. Leider musste ich aus persönlichen Gründen absagen, aber Interessierte an der Veranstaltung können sich noch anmelden (und sollten sich damit beeilen, denn die Plätze sind sehr begrenzt).