Weg mit den Security-Anforderungen! [German]

Drei Grundsätze für wirksame Cybersecurity-Regulierung

NIS-2, DORA, CRA, AI Act: Cybersecurity-Regulierungen haben Hochkonjunktur, nicht nur in der EU. Während wir uns meistens (verständlicherweise) mit der Frage beschäftigen, wie man jetzt die eine oder andere Regulierung am besten umsetzt, gibt es auch noch die übergreifende Frage:

Ist die Regulierung wirksam?

Also: Senkt sie tatsächlich die Cyber-Risiken der regulierten Unternehmen?

Im Mai gab es zwei interessante Artikel zu diesen Fragen. Beide kommen zum selben Schluss: Regulierung sorgt oft dafür, dass Unternehmen viel Energie in die Dokumentation der Einhaltung bestimmter Cybersecurity-Anforderungen stecken — statt diese Energie in die Reduktion tatsächlicher Cybersecurity-Risiken zu stecken. Checkbox-Compliance statt Risiko-Reduktion.

Niemand möchte Checkbox-Compliance.

Aber Cyber-Regulierungen enden am Ende immer in Checkbox-Compliance.

Warum? Und wie können wir das ändern?

Warum Checkbox-Compliance ein Problem ist

Der erste der beiden genannten Artikel stammt aus der Feder von Lim Thian Chin, der die Cyber-Regulierungen in Singapur mitgeprägt hat.

Den zweiten Artikel hat Dale Peterson geschrieben, der insbesondere US-Regulierungen schon lange beobachtet und deren Umsetzung bei Betreibern begleitet hat.

Beide sind sich einig, dass Regulierungen etwas bewirkt haben. Beide nutzen denselben Ausdruck dafür: Cyber-Regulierungen “have raised the floor” — also in etwa: Regulierungen haben “das Mindestniveau angehoben”.

Und beide nennen ein Aber.

Lim Thian Chin schreibt:

“we have raised the floor, but we have mistaken it for the ceiling”.

Was er damit meint: Regulierungen haben das Mindestniveau angehoben, aber der Fehler sei, zu glauben, damit sei ausreichende Security nachgewiesen.

Dale Peterson kritisiert die fehlende Effizienz bei der Erreichung des Mindestniveaus:

“NERC CIP did raise the OT cybersecurity floor. […] It was a hugely inefficient way of raising the floor and slowed progress for all but the laggards”

Er wählt ein Regulierungs-Beispiel, das ihm besser bekannt ist: NERC CIP, die Cybersecurity-Regulierung für die US-Amerikanische Energieinfrastruktur.

Die Reglierung habe sich an den Langsamsten orientiert, die noch gar nichts hatten — und für alle anderen die sinnvollen existierenden Security-Programme durch Compliance ausgebremst. Betreiber haben ihre risikobasierten Security-Programme eingestampft und durch reine NERC CIP-Compliance-Programme ersetzt.

“Regulatory Risk trumped OT Cyber Risk.”

Beide Beobachtungen könnte man zusammenfassen mit: Sobald Regulierungen darauf reduziert werden, die Erfüllung von Anforderungen abzuhaken (wir nennen das im Folgenden vereinfacht “Checkbox Compliance”) werden sie bürokratische Übungen mit fragwürdiger Wirksamkeit für die Risikoreduktion.

Der Grund, warum die Binsenweisheit “Compliance ist nicht gleich Security” in unserer Branche so populär ist.

Warum Regulierung so oft zur Checkbox-Übung wird

Wenn man Menschen fragt, will niemand Checkbox-Compliance. Nicht die regulierten Unternehmen, nicht die Gesetzgeber, nicht die Security-Industrie.

Warum landen wir dann trotzdem ständig da?

Lim Thian Chin nennt in seinem Text eine Reihe wichtiger Gründe aus drei Perspektiven:

Aus der Perspektive der regulierten Unternehmen:

Sobald es eine Anforderungs-Checkliste in einer Regulierung gibt, optimieren Unternehmen das Abarbeiten dieser Checkliste — klar, das ist ja der Schlüssel zur Compliance.

Aus der Perspektive der Gesetzgeber:

Auch Gesetzgeber arbeiten nicht im luftleeren Raum. Sie müssen ihr Vorhaben politisch verteidigen, und am besten kommen klar definierte, validierbare und bestenfalls messbare Anforderungen an.

Aus der Perspektive der Security-Industrie:

Beratung, Auditierung, Zertifizierung und Training — alles Branchen, die von Compliance profitieren. Und alle mögen klare, wiederverwendbare Schemata, aus denen man eine gut verkäufliche Lösung machen kann, und regelmäßig wiederholte Audits für regelmäßigen Umsatz.

Ich glaube, alle diese Punkte stimmen. Sie sind wichtige Gründe, warum jede Regulierung mit der Zeit zu einer Checkliste von Security-Anforderungen wird.

Aber es gibt noch zwei weitere Gründe, und die liegen tiefer.

Der Fokus auf Requirements-Checklisten ist nämlich keine Marotte von Cybersecurity-Gesetzgebern. Er ist eine Marotte der gesamten Cybersecurity-Industrie, und zwar aus zwei einfachen Gründen:

1. Anforderungslisten sind eine Abkürzung. Sie sind bequem. Sie bewahren davor, sich den Kopf über Cybersecurity-Risiken zerbrechen zu müssen.
2. Mit Anforderungslisten bekommt man seinen sprichwörtlichen “Hintern an die Wand”. Wer eine Anforderungsliste abarbeitet, muss keine schwierigen Entscheidungen treffen, für die er möglicherweise gefeuert oder verklagt werden kann.

Anforderungslisten in Regulierungen sind dahingehend besonders praktisch: Sie verlagern das unbequeme Thema der risikobasierten Entscheidungen zum Gesetzgeber (und ggf. Standardisierungsorganisationen). Oder kürzer: Sie verlagern die Verantwortung für die Cyberrisiken zum Gesetzgeber.

Weil das alles so bequem, risikoarm und umsatzträchtig ist, haben wir alle miteinander es geschafft, dass sogar Standards und Regularien, die eigentlich mal risikobasiert gedacht waren, zu Anforderungs-Checklisten umgebogen werden.

Nehmen wir die vielzitierte ISO/IEC 27001, die in der EU gleichzeitig die Allzweckwaffe für die Umsetzung jeglicher Regulierung kritischer Infrastrukturen ist.

Lim Thian Chin nennt sie als Beispiel für ein Regularium, für das man “Controls abhaken” muss. Und er hat recht, das ist, was Heerscharen an Security-Beratern und Auditoren daraus gemacht haben. Aber wer den Standard liest, sieht: eigentlich geht es in der ISO/IEC 27001 um Prozesse, allen voran: Risikomanagement. Die berühmten Controls? Ein Anhang. Jedes einzelne davon kann basierend auf der Risikoanalyse anwendbar sein oder nicht.

Aber so wird die ISO/IEC 27001 nicht genutzt. In Audits geht es um das Abfragen und Abhaken der Controls inklusive “dokumentierter Information”. Die Dokumentation des Einhaltens der Controls wird wichtiger, als das tatsächliche Risiko zu senken.

Ein anderes Beispiel ist der Cyber Resilience Act (CRA). Er läuft Gefahr, ähnlich zu enden.

Der CRA ist eigentlich strikt risikobasiert. Regulierte Hersteller müssen Cyber-Risiken ihrer Produkte adressieren. Und dann gibt es einen Anhang, in dem Security-Anforderungen stehen. Die Anforderungen sind bewusst recht allgemein gehalten, aber es kann harmonisierte Standards geben, die sie für bestimmte Produkttypen konkretisieren. Die Nutzung harmonisierter Standards ist immer optional, es geht ja eigentlich um die Risikominimierung.

Und was passiert momentan? Es geht nicht mehr um das Risiko. Alle stürzen sich auf die Security-Anforderungen im Anhang und die harmonisierten Standards. Es gibt noch keine Schemata für die CRA-Konformitätsbewertung, aber die Akkreditierungs- und Konformitätsbewertungsstellen verweisen auf die harmonisierten Standards.

Erkennt jemand Parallelen zur ISO / IEC 27001?

Wie sieht wirksame Regulierung aus?

Wie kommen wir aus dieser Misere wieder heraus?

Lim Thian Chins hat einen Vorschlag, der auf die Prüfmethoden von Regulierungen zielt.

Zusätzlich zu den bestehenden Prüfungen gegen Anforderungen sollten Penetrationstests oder anderen Methoden eingesetzt werden, die die Resilienz gegen tatsächliche Bedrohungen oder die Eliminierung tatsächlicher Risiken prüfen.

Beispiele: Penetrationstest (er nennt die EU DORA als Beispiel, den Digital Services Resilience Act der EU) oder ein Nachweis darüber, das Risiken für wichtige Funktionen gemanagt werden (hier nennt er UK CAF, das Cyber Assessement Framework Großbritanniens).

“A more honest regulatory architecture would treat certification as the floor, not the proof. It would layer outcome-based, threat-informed and continuously validated mechanisms on top. It would use threat-led mechanisms as one of the primary signals of whether controls actually work.”

Das ist eine gute Idee, weil sie die Wirksamkeit von Maßnahmen in den Fokus stellt, nicht das Umsetzen von Anforderungen.

Mein Bauchschmerz an diesem Ansatz: er würde die Checkbox-Compliance nicht ersetzen, sondern nur ergänzen — und damit Regulierungen und Nachweise weiter aufblähen.

Ich glaube, wir müssen noch früher ansetzen.

Die Beobachtung existierender Regulierungen — z. B. NERC CIP, NIS-1 basierend auf ISO/IEC 27001 und dem CRA zeigt:

Sobald eine Regulierung eine Anforderungscheckliste bietet, wird es in der Umsetzung über kurz oder lang um nichts anderes mehr gehen als diese Checkliste.

Egal, wie sehr die Autoren veruscht haben, die Wichtigkeit des risikobasierten Ansatzes zu betonen: Die Anziehungskraft der Anforderungslisten ist einfach zu stark. Sie sind bequem, risikoarm, umsatzträchtig und verlagern die Verantwortung zu den Autoren der Regulierung.

Und vielleicht haben wir uns über die Jahrzehnte auch einfach zu sehr an diese Listen von Anforderungen / Best Practices / Frameworks / Controls / …. gewöhnt.

Daher hier mein Gedankenanstoß zu drei Grundsätzen wirksamer Cybersecurity-Regulierung:

Grundsatz 1: Keine Security-Anforderungen in die Regulierung

Dieser erste Grundsatz ist der wichtigste.

Es klingt vielleicht radikal, aber ich meine es ernst:

Eine Regulierung, die Risikominimierung zum Ziel hat, darf keine Security-Anforderungen vorschreiben, also keine Anforderungen, die Security-Risiken minimieren sollen.

Klingt widersprüchlich, aber: Sonst nimmt sie sich selbst nicht ernst.

Sonst sendet sie das Signal, dass die Risikoanalyse Kosmetik ist, da die Security-Anforderungen eigentlich schon feststehen.

Oder dass Gesetzgeber die Risiken der regulierten Unternehmen besser einschätzen kann als sie selbst.

Jedes regulierte Unternehmen fühlt sich da zurecht nicht ernst genommen, und erwartet verständlicherweise, dass für die Einhaltung der Regulierung am Ende doch nur die Einhaltung der gelisteten Security-Anforderungen zählt.

Diesen Grundsatz umzusetzen, erfordert Mut und Entschiedenheit.

Ich weiß (und sehe es beim CRA) wie sehr dem Gesetzgeber der Gegenwind ins Gesicht bläst, wenn er keine (oder keine klaren) Security-Anforderungen in die Regulierung schreibt: Die regulierten Unternehmen schreien, die Rechtssicherheit fehle, die Security-Industrie schreit, die regulierten Unternehmen könnten sich herauswinden und zu wenig tun.

Grundsatz 2: Verantwortung für Security-Risiken in die Regulierung

Nur weil es keine Security-Anforderungen in Regulierungen geben sollte, heißt das natürlich nicht, dass es keine Anforderungen geben sollte. Ohne Anforderungen ist eine Regulierung zahnlos.

Sinnvoll sind:

• die Anforderung, Cybersecurity-Risiken zu managen.
• Anforderungen, die die Verantwortung für diese Risiken klar zuweisen und alle Verantwortungs-Schlupflöcher eliminieren.
• Anforderungen, die Kommunikation betreffen: Meldepflichten an den Staat oder Kommunikation an Lieferanten oder Kunden.

(Der CRA erfüllt die ersten drei Punkte sehr gut, siehe diesen oder diesen Blogpost für einen Überblick).

Theoretisch könnte es auch Anforderungen für unverhandelbare Mindeststandards geben, die völlig unabhängig vom Security-Risiko des regulierten Unternehmens sinnvoll sind — aber praktisch habe ich noch nie so eine Liste gesehen, die dann am Ende nicht doch sehr verhandelbar gewesen wäre.

Grundsatz 3: Nachweise fordern, die ein gutes Security-Projekt ohnehin braucht

Natürlich muss es für Regulierungen auch Nachweise geben. Ein bestimmtes Maß an Dokumentation ist nicht vermeidbar.

Aber Dokumentation ist ja auch nichts per se Schlechtes. Schreiben ordnet die Gedanken und es schafft klare Voraussetzungen für und unmissverständliche Kommunikation von Entscheidungen. Ohne einen gewissen Grad an Dokumentation ist kein Projekt umsetzbar, egal ob mit oder ohne Regulierung.

Die Kunst einer guten Regulierung ist, keine Dokumentation einzufordern, die ein gut umgesetztes Projekt nicht sowieso erfordert hätte.

Am liebsten wäre mir die Daumenregel “Regulierung darf nur Dokumentation fordern, die den Schreibenden zum Denken zwingt” — aber ich sehe ein, dass das ein ziemlich dehnbares Kriterium ist.

Die Dokumentation über die Erfüllung von Security-Anforderungen ist kein “Schreiben ordnet die Gedanken”. Es ist auch keine Dokumentation, die in einem sinnvollen Projekt ohnehin existiert hätte, denn da hätte es diese sehr konkreten Anforderungen ja nicht gegeben.

Welchen Nachweis kann eine Regulierung verlangen, die gar keine Security-Anforderungen enthält?

Ein paar Ideen, die auch die Vorschläge von Lim Thian Chin aufgreifen:

• System- und Business-Impact-Analysen: Was sind die grundlegenden Systemfunktionen? Wie kritisch sind sie für das Gesamtsystem?
• Risikoanalysen: Welche Risiken bestehen? Wie sind sie adressiert?
• Resilienztests: Wie gut hält das System tatsächlichen Bedrohungen stand? Penetrationstests oder Purple Teaming sind nur eine Option. Eine weitere ist zum Beispiel Chaos Engineering, bei dem gezielt bestimmte Systemfunktionen bestimmten Szenarien ausgesetzt werden, um ihre Resilienz zu testen.

Klar, für Auditoren ist das ungemütlicher: Wer auch immer diese Nachweise prüft, muss mehr technisches Wissen mitbringen — das Besitzen einer Checkliste mit Anforderungen reicht nicht aus. Aber für Auditoren, die das Wissen mitbringen, würden Audits plötzlich ungleich interessanter und erkenntnisreicher — für beide Seiten.

Stellen wir uns vor, Nachweisaudits wären nicht nur eine Kostenstelle, sondern ein Quality Gate, das dem Security-Projekt echte Nutzen brächte durch ein zusätzliches, versiertes Augenpaar, das die eigenen Systeme und Entscheidungen auf den Prüfstand stellt?

Ausblick

Bleiben wir realistisch: Dass in den nächsten zehn Jahren eine Cybersecurity-Regulierung entsteht, die die drei Grundsätze erfüllt, halte ich für unwahrscheinlich. Dafür gibt es in der Gesetzgebung zu viele Interessen auszugleichen, dafür müssen sich Gesetze zu sehr an der bestehenden Gesetzeslage orientieren, dafür müssten zu viele notorisch langsame Umdenk-Prozesse in unser aller Köpfen angestoßen werden. Dafür sind diese Änderungen zu unbequem — für Regulierer, für regulierte Unternehmen, für Auditoren und Zertifizierer.

Aber es geht auch nicht um Perfektion. Es geht um einen Gedankenanstoß und ein Nachjustieren des Kompasses, bevor wir morgen alle wieder die Nase tief in einzelne Cyber-Regulierungen stecken.

Viele Regulierungen sind gerade im Fluss, und es ist noch nicht klar, wie genau ihre Umsetzung aussehen wird.

Nehmen wir den Cyber Resilience Act: Er hat beides, den risiskobasierten Ansatz und den Anhang mit den Security-Anforderungen. Die harmonisierten Standards, die aus diesen Anfroderungen konkrete Checklisten machen, existieren noch nicht.

Damit steht der CRA an einem Scheidepunkt.

Wenn der CRA Hersteller ernsthaft dazu bringt, Verantwortung für die Cyberrisiken ihrer Produkte zu übernehmen, die Risiken selbst einzuschätzen und zu behandeln und die Energie in eine gute Dokumentation dieser risikobasierten Entscheidung zu stecken — dann wird er eine der wirksamsten Regulierungen der letzten Jahrzehnte, der uns alle gemeinsam auf ein völlig neues Level der Professionalität bei der Security von Produkte befördert.

Wenn er darin endet, dass Hersteller die Energie in die Dokumentation stecken, welche Anforderungen sie wie umgesetzt haben und dann in die Dokumentation einer kosmetischen Risikoanalyse “weil der CRA sie fordert” — dann wird er ein zeitraubendes Bürokratiemonster, das zwar irgendwie zum Umsetzen einiger Anforderungen führt, aber nicht unbedingt zu besseren Produkten.

Wer hat das in der Hand?

• Die Experten in der Standardisierung und die EU-Kommission, die mit Argusaugen darauf achten müssen, dass harmonisierte Standards den risikobasierten Ansatz nicht aushebeln können.
• Die Akkreditierungsstellen und die Marktaufsicht, die darauf achten müssen, dass es bei Konformitätsbewertungsverfahren nicht nur um das Abhaken von Security-Anforderungen geht.
• Aber am allerwirkungsvollsten wäre aus meiner Sicht: Eine beispielhafte technische Dokumentation, bereitsgestellt von der EU-Kommission, als Orientierungshilfe. Eine Dokumentation, die zeigt, wie man auch völlig ohne harmonisierten Standard risikobasiert erklären kann, wie man welche Anforderungen umsetzt — und dass dabei auch “setze ich nicht um” herauskommen kann, wenn es kein Risiko gibt. Eine Dokumentation, die zeigt: “uns ist wichtig, dass ihr Verantwortung für eure Risiken übernehmt — nicht, dass ihr blind die Umsaetzung aller Anforderungen dokumentiert”.

Wünschen kann man sich das ja mal.

Dieser Beitrag ist als Teil des monatlichen „Security-Briefing für Hard Hats“ erschienen. Sie können es hier auf Englisch oder hier auf Deutsch abonnieren.

Mit dem Security Engineering Tool haben wir eine Software entwickelt, um fundierte, risikobasierte Cyber-Sicherheitsentscheidungen zu treffen — und die Compliance mit EU-Regularien nebenbei zu erledigen.