Die Tragödie der Sicherheit entscheidet sich am Prüfstein DevOps

Sicherheit ist nicht mehr das, was sie einmal war. Oder vielleicht war sie immer schon so und wirkt nur anders, weil mein jugendlicher Idealismus langsam abgenutzt ist.

Sicherheit ist zweigeteilt. Auf dem einen Weg bemühen wir uns, unsere Organisationen sicher zu halten: Angreifer zu stoppen, Daten und Assets zu schützen und Anwender vor Bedrohungen und sogar vor ihren eigenen Fehlern zu bewahren. Auf dem anderen Weg liegt Compliance: sicherzustellen, dass die Organisation regulatorische, vertragliche und andere Vorgaben erfüllt. Auf beiden Wegen steuern wir Risiken – die Risiken von Sicherheitsvorfällen und Ausfallzeiten oder die Risiken regulatorischer Bußgelder.

Die Tragödie der Sicherheit ist ein Spiegelbild der Tragik der Allmende. Aus Wikipedia:

Der größte Teil der Sicherheits-Compliance ist darauf ausgelegt, Sicherheitsrisiken zu verringern. Zumindest auf dem Papier. Doch im Lauf der Zeit haben wir erlebt, wie Standard um Standard, Vorschrift um Vorschrift Risiko und Compliance voneinander entkoppelt hat. Schon das Wesen von Compliance-Standards hindert Organisationen daran, Sicherheitsmaßnahmen auf die eigenen Risiken zuzuschneiden. Ich behaupte nicht, dass das immer zutrifft, aber weitgehend – insbesondere bei zunehmender Größe der Organisation. Es gibt keinen Beleg dafür, dass ein erzwungener Passwortwechsel alle 90 Tage bei Anwendern mit MFA oder anderen heute üblichen bedingten Einschränkungen die Sicherheit erhöht. Die Person, die Anforderungen an die Passwortkomplexität erfunden hat, bedauert dies buchstäblich und sagt, dass sie nicht funktionieren. Es gibt weder Belege noch eine solide wissenschaftliche Grundlage für die Forderung nach nicht standardmäßiger Verschlüsselung sämtlicher Speicher-Volumes bei einem Cloud-Anbieter.

Sicherheit ist eine gemeinsam genutzte, endliche Ressource. Wir haben nur ein bestimmtes Budget, eine bestimmte Zahl an Sicherheitsfachleuten und nur so viel Zeit, die Mitarbeitende außerhalb der Sicherheit zulasten ihrer übrigen Ziele für Sicherheit aufwenden können. Je stärker wir in Richtung Compliance ziehen, desto weniger bleibt von diesem Vorrat für Sicherheit. Je weniger Compliance mit Sicherheit übereinstimmt, desto weniger Maßnahmen verringern Sicherheitsrisiken.

Das ist die Tragödie der Sicherheit. Wir haben Risiko und Compliance entkoppelt und damit die fehlende Compliance selbst zum Risiko gemacht. Je stärker die tatsächlichen Risiken von der Compliance entkoppelt sind, desto starrer das Compliance-Regime, desto weniger Sicherheitsressourcen stehen für die Verteidigung zur Verfügung und desto weniger Unterstützung erhalten Sicherheitsmaßnahmen von anderen Teams.

Ein gutes Beispiel kam in einem Gespräch mit Chris Farris auf. Sinngemäß:

Entwicklern ist Sicherheit durchaus wichtig. Compliance ist das, was sie stört. Helfen Sie ihnen, ihre Anwendung abzusichern, und sie ziehen mit. Verlangen Sie von ihnen eine vierstündige Ausfallzeit am Wochenende, um ihre Datenbank mit Verschlüsselung neu aufzubauen, weil ein Compliance-Bürokrat es so will, verärgern Sie sie nur.

Ich behaupte nicht, dass Compliance ausschließlich aus unsinnigen Regeln besteht, aber manche Compliance-Regeln sind unsinnig, und die falsche Anwendung guter, von Risiken entkoppelter Regeln ist wirklich unsinnig.

DevOps wird zum Prüfstein für die Zukunft der Sicherheit, denn in der Welt von Cloud und DevOps werden einzelne Anwendungsteams für den gesamten Stack verantwortlich, einschließlich eines großen Teils der Sicherheit. Neue Server, Netzwerke und Firewalls sind nur einen git commit und einige API-Aufrufe entfernt. Das legt diesen Teams zugleich eine größere Last auf, ihre eigene Sicherheit und Compliance zu verwalten. Wir haben nach wie vor zentrale Sicherheit und gemeinsam genutzte Sicherheitsressourcen, aber an der Speerspitze verlassen wir uns eindeutig stärker auf die DevOps-Teams. Wir können keine große DMZ für die Cloud errichten. Die Grenzen zwischen internen und externen Netzwerken lassen sich nicht länger in vorgefertigte Zonen einteilen. Viele Anwendungen, die auf nativen Cloud-Diensten aufbauen, haben überhaupt kein Netzwerk mehr und stützen sich auf IAM-Regeln und Ressourcenrichtlinien in JSON, die Anwendungsteams über Infrastructure as Code ausrollen.

Bei etlichen meiner jüngeren Compliance-Projekte mit Cloud- und DevOps-Schwerpunkt geht es daher zunächst darum, gute Sicherheit umzusetzen, und anschließend darum, einen Bericht zu formulieren, der so aussieht, als erfülle er den Buchstaben der Compliance, obwohl er es nicht tut – selbst wenn das Ergebnis sicherer ist.

Es gibt zwei mögliche Lösungen.

Die erste besteht darin, Sicherheitsstandards zu überarbeiten, damit sie besser zu Cloud und DevOps passen, und die Zahl unsinniger oder unpassender Regeln zu verringern. Ein Teil dieser Arbeit findet bereits statt, doch ich bin zu der Überzeugung gelangt, dass dafür ein Generationswechsel nötig ist, auf den wir nicht warten können. Geben wir das nicht auf, aber warten müssen wir nicht.

Die zweite besteht darin, mit Automatisierung so viel wie möglich der Sicherheits- und Compliance-Last von den Einzelnen zu nehmen und ihnen zugleich die Freiheit und Kontrolle zu lassen, schnell zu entwickeln. Ich schlage nicht vor, den Gesamtumfang der Sicherheit zu verkleinern, sondern Automatisierung und andere Technologien zu nutzen, um den Aufwand des Einzelnen für die weniger wertvollen Dinge zu reduzieren.

Es geht um Zeit und um den Fokus begrenzter Ressourcen. Und ganz ehrlich: Was ist wertvoller – ein guter Penetrationstest oder ein Compliance-Audit? Sehen Sie sich nun an, wie viel Sie für Penetrationstests ausgeben und wie viel Sie für ein Audit zahlen.