Schlagwort-Archive: Regulierung

Sicherheitstechnik gehört nicht ins Gesetz

Anforderungen – Requirements, By Design, Regierungsviertel, Security, , , , , ,

Die SPD-Bundestagsfraktion hat ein Positionspapier zum IT-Sicherheitsgesetz 2.0 beschlossen. Da stehen einige sinnvolle Forderungen drin, etwa nach Verbesserungen im Opferschutz und bei den zuständigen Behörden. Andere sind Blödsinn, allen voran jene nach einer Verpflichtung von Dienstanbietern zu spezifischen Sicherheitsmaßnahmen wie 2-Faktor-Authentisierung.

Sicherheit sei kein Zustand, lautet ein geflügeltes Wort, sondern ein Prozess. Dies gilt nicht nur für den Betrieb von IT-Systemen, sondern auch für ihre Entwicklung und Gestaltung. Konkrete Ausprägungen von Sicherheitsfunktionen stehen am Ende einer langen Folge von Entwurfsentscheidungen.

Viele dieser Entscheidungen sind das Resultat von Abwägungen zwischen verschiedenen Entwurfszielen auf verschiedenen Gebieten, zum Beispiel Funktionalität, Usability und Usability. Noch mehr Entscheidungen treffen gar nicht die Entwickler selbst, sondern der Markt und der Stand der Technik, der sich ständig weiterentwickelt.

In diesem Kontext einen sinnvollen und lange haltbaren Fixpunkt zu setzen, ist schwierig, und Politiker sind für diese Aufgabe noch weniger qualifiziert als jene, die wenigstens das Problem verstehen. Die besten Lösungen entstehen vielmehr durch fortwährende Evolution.

Ein Beispiel: Die URL-Zeile im Webbrowser begann ihre Karriere vor mehr als einem Vierteljahrhundert als einfaches Eingabefeld für Web-Adressen. Im Laufe der Zeit stellte sich heraus, dass gefälschte Websites für allerlei Angriffe benutzt werden können und man daher gut daran tut, die Benutzer eines Browsers so gut wie möglich bei der Erkennung solcher Täuschungsversuche zu unterstützen.

Dabei müssen gleichzeitig andere Ziele berücksichtigt werden, wenn die URL-Zeile dient weiterhin auch ihrem ursprünglichen Zweck. Über die Jahre haben die Browser-Entwickler gelernt, auf welche Einzelheiten es ankommt und wie man die verschiedenen Ziele gut unter einen Hut bekommt, und daraus Empfehlungen formuliert.

Diese Empfehlungen repräsentieren den aktuellen Stand; die Entwicklung wird weitergehen, die Anforderungen werden sich ändern und man wird für neue Aspekte des Problems neue Lösungen finden. Evolution eben. „Security by Design“ klingt zwar gut, aber Design ist nichts anderes als forcierte Evolution.

Spezifische Entwurfsvorgaben von Gesetzesrang grenzen diese Evolution willkürlich ein. Sie machen aus einem Lern- und Innovationsproblem eine Compliancefrage und eine bürokratische Angelegenheit. Damit erreichen sie genau das Gegenteil des Gewollten: Die Sicherheit erhöht sich nicht, sondern alle sind nur noch damit beschäftigt, gesetzliche Vorgaben einzuhalten, seien sie nun sinnvoll oder nicht.

Tatsächlich ist liegt simple 2-Faktor-Authentisierung alleine sogar schon hinter dem Stand der Technik. Wer sich moderne, das heißt nichtdeutsche Websites oder gar „die Cloud“ anschaut, findet dort ausgefeilte Systeme zum Identitäts- und Rechtemanagement, in denen die unmittelbare Benutzerauthentisierung nur ein Baustein ist.

Einige andere Bausteine sind an der Benutzerschnittstelle zum Beispiel die Verwaltung von Clientgeräten (Funktionen wie: „Alle angemeldeten Geräte abmelden“), Benachrichtigungsfunktionen („Jemand hat Ihr Passwort dreizehnmal falsch eingegeben.“), die Nichtbehinderung von Passwortmanagern sowie Recovery-Funktionen, mit denen Benutzer in verschiedenen Situationen (Passwort vergessen, gehackt, E-Mail-Adresse verändert) wieder Zugang zu ihrem Account bekommen. All diese Bausteine sind sicherheitsrelevant und jeder von ihnen sowie ihr Zusammenspiel unterliegt ebenso wie die Gestaltung der URL-Zeile im Browser der fortlaufenden Evolution.

Gesetzestexte können schon die statische Komplexität des Themas nicht fassen, von der Weiterentwicklung gar nicht zu reden. Konkrete gesetzliche Vorgaben zur Gestaltung von Authentisierungsfunktionen wären schon bei Inkrafttreten des Gesetzes veraltet oder unvollständig. Sogar als rein wirtschaftlich motivierte Marktregulierung taugt der Ansatz wenig: Ausgerechnet heimische Anbieter wie GMX und Web.de tun sich schwer mit der Zwei-Faktor-Authentisierung, während sie bei den Großen aus Amerika längst Standard ist. Ganz ohne Gesetz übrigens.

Ich wäre der Politik dankbar, wenn sie sich auf das Formulieren von User Stories* beschränken und die Technik den ITlern überlassen würden. Glauben Sie mir, meine Damen und Herren, und das möchte ich hier in aller Deutlichkeit betonen: Es ist besser so. Wer die Evolution der Technik wirklich beeinflussen möchte, sollte das indirekt über die Anreize tun.

*) Eigentlich: Anforderungen, aber die Erklärung, warum Lösungsvorschläge schlechte Anforderungen sind, wäre mir hier zu lang geworden.

 

PS: Jemand hat mir dieses Video zum Thema zugespielt, das ich nachträglich im Text mit verlinkt habe.

Nur eine Frage der Zeit?

Geschäft, Propaganda, Psycho, Risiko, Safety, Security, security-industrial complex, , , ,

„Es ist nur eine Frage der Zeit, bis etwas passiert“ – diese Vorhersage liegt immer richtig. Irgendwann wird irgend etwas passieren, worin der der jeweilige Gegenstand verwickelt ist, ganz gleich ob es sich um Atombomben oder um Trinkwasser handelt. Kein Wunder also, dass der Plakettenkonzern TÜV mit einer Variante dieses Spruchs versucht,  sich das neue Geschäftsfeld der Sicherheit von Windkraftanlagen zu erschließen. Gewiss wird es irgendwann einmal zu einem Ereignis kommen, bei dem Menschen durch ein unglückliches Zusammentreffen mit einer Windkraftanlage zu Schaden kommen.

Aus der bloßen Möglichkeit folgt jedoch noch lange nicht die Notwendigkeit, etwas dagegen zu tun. Für sinnvollen Schutz muss man Risiken betrachten und nicht nur bloße Möglichkeiten. Der Unterschied: Risikobetrachtungen berücksichtigen die Häufigkeit bzw. Wahrscheinlichkeit von Ereignissen und deren Schadenshöhe. Auf dieser Grundlage lässt sich diskutieren, wie schwer eine Gefahr wiegt und welcher Aufwand für welche Risikoreduktion angemessen erscheint. Die prinzipielle Möglichkeit hingegen bleibt stets erhalten, so dass mit Ausnahme des Totalausstiegs keine Maßnahme je genug ist.

Fielen beispielsweise Jahr für Jahr im Mittel fünf Windräder um und eins davon erschlüge Menschen, so ließe sich diskutieren, ob wir als Gesellschaft dieses Risiko tragen oder ob wir etwas tun, um es zu reduzieren. Könnte man mit einer Plakettenpflicht erreichen, dass nur noch halb so viele Windräder umfielen und entsprechend seltener Menschen zu Schaden kämen, so handelte es sich vielleicht um einen guten Deal. Jedoch erreichen die tatsächlichen Risiken bei weitem nicht jene, die dieses hypothetische Szenario unterstellt. Die Produkte des Plakettenkonzerns bleiben daher an diese Stelle voraussichtlich nutzlos, denn es gibt kaum ein Potenzial zur Risikoreduktion.

Geht es um Windräder, so liegt alles klar auf der Hand. Alltagserfahrung und gesunder Menschenverstand genügen für eine fundierte Einschätzung.

In der Cybersicherheit zeigt sich eine ähnliche Situation: Mahner drängen die Gesellschaft, mehr für die Cybersicherheit zu tun, um zunehmenden Bedrohungen nicht hilflos ausgeliefert zu sein. Die Einschätzung solcher Forderungen fällt jedoch viel schwerer. Auf der einen Seite hat ein wohlgenährter sicherheitsindustrieller Komplex das Interesse, Gefahren möglichst groß erscheinen zu lassen. Auf der anderen Seite kommt es tatsächlich zu spektakulären Angriffen mit beträchtlichen Schäden. Stehen wir vor der Cyberapokalypse oder werden wir wie im vergangenen Vierteljahrhundert auch in Zukunft vor allem die Segnungen des Internets genießen, ohne große Schäden zu erleiden?

In beide Richtungen lässt sich argumentieren, ohne dass man mit Alltagswissen entscheiden könnte, wer Recht hat. Das Internet ist weit komplexer als ein Windrad oder auch ein ganzes Stromnetz.Zu welchen Angriffen es kommt, hängt nicht nur von Sicherheitslücken ab, sondern auch von den Zielen und Interessen der Angreifer, die solche Lücken ausnutzen – oder eben auch nicht. Informationen über Angriffe bleiben häufig im Verborgenen, so dass niemand weiß, was wirklich passiert. Stattdessen nimmt man gerne die argumentative Abkürzung von bekannten oder vermuteten Verwundbarkeiten zu einem Worst-Case-Szenario eines Angriffs, dessen Eintreten „nur eine Frage der Zeit“ sei.

Tatsächliche Ereignisse wie der der NotPetya-Befall beim Konzern Maersk mit geschätzten 300 Millionen Dollar Schaden liefern scheinbar den Beleg: Man tue zu wenig für die Cybersicherheit und wenn der Markt dies nicht von sich aus ändere, müsse man regulierend eingreifen. Unterschlagen wird dabei freilich, dass gerade Konzerne durchaus ernsthaft in Sicherheit investieren – „Big Tech“ sowieso, aber auch zum Beispiel Siemens, wo man die Wirkung des Stuxnet-Schocks an der Zahl der gemeldeten Verwundbarkeiten pro Jahr ablesen kann.

Dass der Markt beim Thema Sicherheit gänzlich versage, kann man angesichts dessen kaum behaupten. Unternehmen können es sich nicht leisten, ihre Sicherheit zu vernachlässigen. Mit wenigen Ausnahmen können sie es sich jedoch auch nicht leisten, mehr als nötig und wirtschaftlich vertretbar in Sicherheit zu investieren. Allen Eventualitäten vorzubeugen ist nicht realistisch, deshalb werden stets Risiken bleiben und es wird zu Vorfällen kommen. Selbst bei großen Schäden wie im Fall von Maersk kann es am Ende die günstigste Lösung sein, das Risiko zu tragen statt es vorbeugend abzuwehren. Jedenfalls ist es nicht per se falsch, so zu entscheiden, oder zumindest nicht falscher als im Fall des psychisch kranken Germanwings-Piloten, der mit dem von ihm herbeigeführten Absturz einen ähnlich hohen Schaden verursachte und der aufgrund von Sicherheitsmaßnahmen zur Terrorabwehr von seinen Opfern nicht daran gehindert werden konnte.

Mag sein, dass in bestimmten Konstellationen regulierende Eingriffe nötig sind. Für Sicherheit schlechthin gilt dies jedoch nicht, denn wo reale Schäden entstehen, gehen sie mit Anreizen zur Risikoreduktion einher.

(Inspiriert von einer Diskussion auf Google+.)

Cookies, Clients und die Cloud

Datenkrake, Datenschutz, Forschung, Freundlich zum Nutzer, Regierungsviertel, Spackeria, Wolkenkuckucksheim, Zeitmaschine, , , , , , , , ,

Politiker und Bürokraten wollen die Verwendung von Cookies gesetzlich regulieren, erst die EU (mit unklarem Regelungsgehalt und schleppender Umsetzung), ein paar Jahre später nun auch die SPD. Warum ist das blöd? Ich hole mal etwas weiter aus:

Persönliche Computer, PCs, waren in den 70er und 80er Jahren des letzten Jahrhunderts eine große Sache. Jedem seinen eigenen Computer, klein genug für den Schreibtisch und mit verschiedenen Anwendungsprogrammen für vielerlei Zwecke einsetzbar, das hatte es vorher höchstens als Vision gegeben. Aus dieser Frühzeit der Jedermann-IT stammen viele Vorstellungen, die wir noch heute hegen, darunter die Wurzeln unseres Datenschutzes.

Auf den ersten Blick hat sich seitdem wenig geändert. Aus dem PC auf Arbeit wurde ein Gerätezoo für alle Lebenslagen aus PCs, Note- und Netbooks, Smartphones, Tablets, Internetradios, Spiekonsolen und so weiter, technisch im Grunde genommen immer noch persönliche Computer, nur schöner und kleiner und schneller. Seit den 90er Jahren folgte dem Jedermann-Computer das Jedermann-Netz und im folgenden Jahrzehnt wurde dieses Netz mobil und sozial. Allen Schichten gemein ist, dass ihre Nutzer in Selbstbedienung nach Bedarf Dienste einkaufen, die nach dem Umfang der Nutzung bzw. den zugesicherten Ressourcen abgerechnet werden. Dienstanbieter stellen aus einem Pool an Ressourcen ohne Zeitverzug die jeweils nachgefragten Dienste bereit.

Die jetzige Dekade wird das Jahrzehnt des Cloud Computing. So wie der PC in den 70ern entstand und in den 80ern seinen Namen bekam und sich verbreitete, ist Cloud Computing keine ganz neue Sache, sondern längst erfunden, einsatzbereit und zum Teil auch schon etabliert. Neu ist nur, dass es jetzt einen Namen dafür gibt und alle ein Geschäft wittern, nachdem die Early Adopters vorgemacht haben, dass es funktioniert.

Cloud Computing bedeutet, dass ein Großteil der IT als Dienst ins Netz wandert. Das kann auf verschiedenen Abstraktionsebenen geschehen. Infrastructure as a Service (IaaS) bietet virtuelle Maschinen und Speicher, Platform as a Service (PaaS) liefert Anwendungsplattformen und Software as a Service (SaaS) schließlich macht Anwendungssoftware zu einem Dienst. Ein Beispiel für SaaS ist wordpress.com, wo dieses Blog gehostet wird. Die Schichten lassen sich stapeln, ein SaaS-Anbieter kann auf PaaS-Dienste zurückgreifen, die sich ihrerseits auf IaaS stützen. Die unteren Schichten IaaS und PaaS sind vor allem für Unternehmen interessant, während SaaS in Form von allerlei Webdiensten längst Teil unseres Alltags ist und die klassische Nutzung von Anwendungssoftware auf einem PC teils ersetzt, teils ergänzt.

Geht es um Sicherheit und Datenschutz im Cloud Computing, starren alle wie gebannt auf die Dienstseite. Daten wandern ins Netz, ob aus dem Rechenzentrum eines Unternehmens oder vom heimischen PC, und man weiß nicht genau, wo sie eigentlich gespeichert und verarbeitet werden. Das macht Angst und wirft technische, organisatorische und rechtliche Fragen auf. Hinzu kommt, dass der Übergang von Software in Kartons zu Diensten im Netz in Verbindung mit agilen Entwicklungsmethoden die Softwareentwicklungs- und -lebenszyklen verändert. Es gibt kein Google 3.0, das ich kaufen und dann ein paar Jahre verwenden könnte, sondern Änderungen am Dienst im Wochen-, Tage-, Stunden- und sogar Minutentakt. Continuous Deployment und DevOps nennen wir diese bewusste Vermischung von agiler Entwicklung und Produktivbetrieb.

Ein SaaS-Dienst ist nicht in sich abgeschlossen und unabhängig vom Rest des Netzes, sondern es handelt sich, für Nutzer manchmal schwer erkennbar, um eine Aggregation mehrerer Anwendungs- und Hilfsdienste, ergänzt um spezifische Funktionen des aggregierenden Hauptdienstes. Like-Buttons, Widgets, Videos, RSS-Feeds, Analytics, Werbebanner, Nutzerkommentare, Payment, Fonts und so weiter stützen sich auf Fremddienste, die, oft clientseitig, in den Hauptdienst integriert werden. Hilfsdienste haben meist ihren eigenen Betreiber und sie werden in viele verschiedene SaaS-Dienste eingebunden.

Weniger Aufmerksamkeit erhält beim Blick auf die Cloud die irdische Hälfte des Systems, die Client-Seite. Cloud-Dienste besitzen praktisch immer ein Webinterface, mindestens fürs Management, oft auch – und bei SaaS sowieso – für den eigentlichen Dienst. Der Nutzer bekommt damit eine universelle Client-Umgebung, bestehend aus einem Browser mit generischen Plugins (Flash, Java, Silverlight) und Unterstützungsanwendungen (PDF-Viewer, Office, iTunes) auf dem klassischen PC oder aus einem Browser und anwendungsspezifischen Apps auf mobilen Gadgets wie Smartphones oder Tablets.

Nach dieser langen Vorrede nun zurück zu den Cookies. Das Konzept des Cookies wird demnächst volljährig, es handelt sich ursprünglich um kleine Datenhäppchen, die eine Website einer Browserinstanz zur Speicherung übermittelt. Der Browser merkt sich diese Daten und schickt sie für einen festgelegten Zeitraum bei jeder weiteren Interaktion mit der Website dorthin zurück. Heute gibt es darüber hinausgehende Persistenzmechanismen auch für größere Datenmengen im Browser selbst sowie in verbreiteten Plugins, zum Beispiel im Flash Player.

Jeder Dienst in einer SaaS-Aggregation kann Cookies setzen und mit Hilfe dieser Cookies Daten über das Nutzerverhalten über alle Dienstnutzungen hinweg erfassen und sammeln. Die aggregierten Hilfsdienste erhalten dabei Daten aus verschiedenen SaaS-Anwendungskontexten verschiedener Anbieter und sind gleichzeitig für den Nutzer schwer zu identifizieren. Datenschützer stellen zu Recht die Frage, wie die Dienstnutzer unter diesen Bedingungen wirksam von ihrem Recht auf informationelle Selbstbestimmung Gebrauch machen können. Sie geben darauf aber die falschen Antworten.

De jure und traditionell wäre das Problem durch Kommunikation und Vereinbarungen des Nutzers mit jedem einzelnen involvierten Dienstanbieter zu lösen. Aggregierte Hilfsdienste als Auftragsdatenverarbeitung unter einer Vereinbarung zwischen dem Nutzer und dem Anbieter des Hauptdienstes zu subsumieren, wie es etwa für Analytics-Dienste diskutiert wurde,  vereinfacht die Sache wegen der Mehrfacheinbettung der Hilfsdienste in verschiedenste SaaS-Anwendungen nur scheinbar. Außerdem ändert sich permanent irgendwo irgendwas, so dass wir als Nutzer am Ende nur noch mit Zustimmen beschäftigt wären, wenn uns keine Generalvollmacht diese Mühe abnimmt. Erforderlich sind Lösungen, die die Architektur von SaaS-Mashups und der Client-Plattform als gegeben hinnehmen und darauf effektive Mechanismen für den technischen Datenschutz bereitstellen.

Cookies sind dabei nur ein wenig kritisches Randphänomen. Da sie clientseitig gespeichert werden, lässt sich ihre Speicherung und Übermittlung auch clientseitig effektiv steuern. Verbesserungsbedarf gibt es dabei vor allem in der Usability. Wünschenswert wäre zum Beispiel ein einheitliches User Interface für Einstellungen über alle Teilsysteme (Browser, Plugins, Apps, etc.) des Clientsystems hinweg anstelle getrennter, inkonsistenter Management-Schnittstellen für Cookies, Persistent DOM Storage und Flash-Cookies. Sinnvoll fände ich auch eine Möglichkeit, meine Datenschutzeinstellungen zwischen meinen fünf regelmäßig genutzten Clientsystemen zu synchronisieren statt fünfmal dasselbe konfigurieren zu müssen. Aber Clientsysteme und ihre Eigenschaften kommen in der Diskussion oft gar nicht vor. Soll ich ernsthaft mit dreiundzwanzig Diensten Vereinbarungen treffen, statt mir einmal eine Policy zusammenzuklicken, die meine eigene Technik für mich durchsetzt? P3P hatte zwar Schwächen und hat sich nicht durchgesetzt, aber damals hat man doch immerhin noch das Gesamtsystem angeschaut und eine Komponente an die richtige Stelle gesetzt, nämlich in den Client.

Mit formalisierten Rechtsritualen aus der Frühzeit der Alltags-IT ist das Problem nicht in den Griff zu bekommen. Gesucht sind effektive und benutzbare Mechanismen. Das ist die technische Sicht, die politische Dimension hat Benjamin Siggel vor einiger Zeit im Spackeria-Blog betrachtet.