Selbstbewusste Entscheidungen statt CRA-Compliance-Panik [German]
Beim CRA tragen Sie selbst die Verantwortung. Und das ist gut so.
Das Jahr 2025 endete mit einem Cybersecurity-Vorfall: In Polen griffen Hacker die Energie-Infrastruktur an und versuchten, einen Blackout herbeizuführen. Bei Minusgraden draußen.
Der Angriff konnte abgewehrt werden, der Strom fiel nicht aus. Cybersecurity-Experten wollten aber natürlich trotzdem wissen, was passiert war.
Die Antworten kamen schnell: Standardbenutzernamen und -passwörter, keine Multi-Faktor-Authentifizierung. Das polnische CERT empfahl Energieversorgern, künftig bessere OT-Sicherheitsmaßnahmen einzuführen.
Die Geschichte ist soweit klar: Mal wieder ein Betreiber, der keine ausreichende Cybersecurity hatte.
Aber die Sache ist die:
Sollte 2028 etwas Ähnliches passieren, nachdem der Cyber Resilience Act (CRA) in Kraft getreten ist, wird der öffentliche Diskurs ganz anders aussehen.
„Welches Produkt hatte denn bitte noch Standardzugangsdaten?“ „Und verstößt das nicht gegen die CRA-Anforderungen?“
Solche Fragen wird vermutlich die Marktaufsicht stellen, aber noch eher Menschen wie Sie und ich. Eine Kundin, ein Konkurrenzunternehmen, ein Sicherheitsforscher — alle haben das Recht dazu (und können Beschwerden wegen Nichteinhaltung einreichen), sobald der CRA in Kraft ist.
Und je nachdem, wie die Antwort auf diese Fragen ausfällt, können die Konsequenzen schmerzhaft sein. Der CRA sieht Bußgelder von bis zu 15 Millionen Euro bzw. 2,5 % des weltweiten Jahresumsatzes vor. Oder was noch schlimmer wäre: Das Produkt muss vom Markt genommen werden. Deshalb werden alle Hersteller ihr Möglichstes tun, solche Fragen gar nicht erst aufkommen zu lassen.
Vor Marktaufsichtsbehörden müssen Sie sich weniger fürchten als vor Fagen stellenden Kunden, Wettbewerbern und der Öffentlichkeit.
Denn der CRA ist anders als Sie es vielleicht von anderen Regelwerken kennen. Den CRA einzuhalten, bedeutet nicht, nur einen Audit zu bestehen oder eine schicke Dokumentation zu erstellen. Den CRA hält man ein, indem man ein sicheres Produkt hat und das seinen Kunden und allen anderen, die es interessiert, immer wieder beweist.
Anders ausgedrückt: Beim CRA geht es nicht um Audits, sondern darum, Verantwortung zu übernehmen.
Er bringt keine neuen Anforderungen mit sich, sondern eine neue Verantwortlichkeit.
Hersteller sind jetzt per Gesetz für die Cybersecurity ihrer Produkte verantwortlich.
SIE sind jetzt für die Cybersecurity Ihrer Produkte verantwortlich. Punkt.
Verantwortung lässt sich nicht auf den Gesetzgeber abwälzen
Wie wird man dieser Verantwortung gerecht?
Das Stichwort lautet „Risiko“.
Sie sind für die Cybersecurity Ihrer Produkte verantwortlich, oder genauer gesagt: für das Cybersecurity-Risiko Ihrer Produkte. Der risikobasierte Ansatz strömt beim CRA wirklich aus jeder Pore.
Der CRA gehört zum New Legislative Framework. Das ist der Rechtsrahmen, der Grundregeln für alle Produktregularien in der Europäischen Union definiert. Damit gilt auch er für alle Produkte, die eine CE-Kennzeichnung tragen müssen. Diese Kennzeichnung gibt es schon seit Jahrzehnten für Produkte wie Krane, Druckbehälter, Sonnenbrillen und Kinderspielzeug.
Was alle diese Produkte gemeinsam haben? Wenn sie gewisse Anforderungen nicht erfüllen, können Menschen zu Schaden kommen.
Das ist kein Zufall, sondern Bedingung für die rechtliche Anwendbarkeit. Entgegen dem herrschenden Vorurteil hat die EU hier nämlich genau darauf geachtet, Überregulierung zu vermeiden. Ein Grundsatz lautet: Reguliert werden dürfen Produktmerkmale nur dann, wenn sie für die Risikovermeidung entscheidend sind. Alles andere bleibt dem freien Markt überlassen.
Deshalb wurde auch der CRA so formuliert, dass das Produktdesign nicht eingeschränkt wird, wenn kein Risiko besteht.
In Anhang I gibt es zwar grundlegende Anforderungen, aber die sind allgemein gehalten.
Wer bestimmt, wie die grundlegenden Anforderungen in Ihrem Produkt umgesetzt werden?
Sie selbst. Je nach Risiko.
Es gibt die Anforderung, dass keine Produkte mit ausnutzbaren Schwachstellen ausgeliefert werden dürfen. Wer bestimmt, was eine ausnutzbare Schwachstelle ist?
Sie selbst. Je nach Risiko.
Ältere Produkt fallen nur dann unter den CRA, wenn eine wesentliche Änderung stattgefunden hat. Wer bestimmt, was eine wesentliche Änderung ist?
Sie selbst. Je nach Risiko.
Dass all das so vage bleibt, ist kein Fehler in der Gesetzgebung. Es ist auch kein Versehen, das Schlupflöcher lässt.
Es ist Absicht.
Würde der CRA konkrete Anforderungen nennen, die die Produkte einhalten müssen, läge die ganze Verantwortung für die Cybersecurity des Produkts bei den Gesetzgebern (und Innovationen würden vermutlich im Keim erstickt).
Die Verantwortung soll aber beim Hersteller bleiben, also bei Ihnen. Der CRA zwingt Sie, risikobasierte Entscheidungen zu treffen — und verdammt gut darin zu werden, denn nur so werden Sie dieser Verantwortung gerecht.
Verantwortung lässt sich nicht auf Normungsorganisationen abwälzen
Aber was ist mit den harmonisierten Normen? Sind die nicht genau das, was ich gerade beschrieben habe — eine Liste von Maßnahmen, die für bestimmte Produkte umzusetzen sind?
Geht es bei der Konformitätsvermutung für harmonisierte Normen nicht genau darum? Wenn eine Norm die Konformitätsvermutung auslöst, bedeutet das: Wer die Norm einhält, hält den CRA ein. Ist das dann nicht eine Abkürzung zur CRA-Compliance?
Nein. Zum einen wird es für die meisten Produkte so bald keine harmonisierte Norm mit Konformitätsvermutungswirkung geben, auf jeden Fall nicht rechtzeitig bis zum Fristablauf im Dezember 2027.
Aber wir können zu Erklärungszwecken ja für einen Moment mal davon ausgehen, es gäbe rechtzeitig harmonisierte Normen für alle Ihre Produkte:
Wer bestimmt dann, ob die Konformitätsvermutung einer harmonisierten Norm auf Ihr Produkt zutrifft?
Inzwischen können Sie es sich wahrscheinlich denken: Sie selbst. Je nach Risiko. Die Konformitätsvermutung gilt, wenn die harmonisierte Norm alle relevanten Cybersecurity-Risiken abdeckt, die mit Ihrem Produkt verbunden sind.
Das geht schon aus dem CRA hervor, aber die EU-Kommission hat es in ihrer letzten Guidance zur CRA-Implementierung noch einmal ganz klar gesagt (Ziffern 134 und 138, wenn Sie nachschauen möchten).
Auch wenn es eine harmonisierte Norm gibt, müssen Sie eine Risikoanalyse durchführen. Sie müssen trotzdem noch prüfen, ob die Norm wirklich alle Risiken Ihres jeweiligen Produkts abdeckt.
Die Risikoanalyse bleibt Ihnen also nicht erspart, selbst wenn sich eine harmonisierte Norm anwenden lässt. Und auch das ist so gewollt.
Denn sonst würde die Verantwortung für das Cybersecurity-Risiko Ihres Produkts auf die Organisationen übergehen, die die Normen schreiben. Bei denen liegt sie aber nicht.
Die Verantwortung für die Cybersecurity Ihres Produkts — oder genauer, für das Cybersecurity-Risiko des Produkts — bleibt immer bei Ihnen.
Verantwortung lässt sich nicht auf Lieferanten abwälzen
Vielleicht erinnern Sie sich noch an den Ripple20-Vorfall 2020. Ganze 19 Schwachstellen gab es in der weitverbreiteten TCP/IP-Bibliothek eines kleinen US-Herstellers. Es war das reinste Chaos. Viele Hersteller haben Wochen oder gar Monate gebraucht, um herauszufinden, ob sie betroffen sind.
Im Jahr 2028 werden die Erwartungen andere sein. Wenn Sie Monate bräuchten, um herauszufinden, ob Ihr Produkt eine bestimmte TCP/IP-Bibliothek verwendet, kämen wieder unbequeme Fragen auf:
Warum braucht der Hersteller so lang, gibt es denn keine SBOM, wie der CRA vorschreibt? Warum wurde für diese Schwachstelle noch kein Advisory und kein Patch veröffentlicht? Dachten die nicht, dass sie ausnutzbar wäre? Dürfen die ihre Produkte so überhaupt ausliefern?
„Aber es ist wirklich schwer, das herauszufinden“ gilt als Entschuldigung nicht mehr. Hersteller sind für das Cybersecurity-Risiko Ihrer Produkte verantwortlich, und das schließt auch zugekaufte Komponenten ein. Wenn Sie die Verantwortung tragen, müssen Sie wissen, welche Drittanbieterkomponenten Sie nutzen, BEVOR eine davon in die Luft fliegt.
Sonst würden Sie die Verantwortung für das Cybersecurity-Risiko Ihres Produkts auf Ihre Lieferanten übertragen. Das dürfen Sie aber nicht.
Wer entscheidet, ob Sie Komponenten wie diese TCP/IP-Bibliothek von einem kleinen Lieferanten trotzdem weiter nutzen können? Wer hätte es gedacht: Sie selbst. Sie entscheiden. Je nach Risiko.
Bevor Sie jetzt in Schockstarre verfallen, richten Sie Ihre Aufmerksamkeit doch auf konstruktive Mittel und Wege, dieses Risiko zu managen. Natürlich kann niemand erwarten, dass Sie alle Schwachstellen in allen Drittanbieterkomponenten finden und patchen.
Aber Sie können Ihre Komponenten sorgfältig auswählen.
Bei kommerziellen Komponenten können Sie die CRA-Anforderungen an Ihre Lieferanten weiterreichen. Bei Open-Source-Komponenten können Sie deren Maintainer dabei unterstützen, die Infrastruktur zum Finden und Beheben von Schwachstellen aufzubauen, oder Sie werden gleich selbst Contributor.
Und wenn wir wieder an Ripple20 denken: Sie können in das Ökosystem investieren, mit dem SBOMs und Schwachstelleninformationen entlang der Lieferkette schnell durchgereicht werden können. Der CRA gibt Ihnen dafür einen finanziellen Anreiz, denn Sie und Ihre Lieferkette, Sie sitzen jetzt im gleichen Boot. Sie haben die Verantwortung für alle Komponenten, die in Ihren Produkten eingesetzt werden.
Grenzen Ihrer Verantwortung
Man kann also ganz klar sagen: Beim CRA dreht sich alles um das Risiko. Egal was Sie tun, Sie sind verantwortlich für das Cybersecurity-Risiko Ihrer Produkte.
Wenn Sie etwas vorhaben und sich fragen, ob das gegen den CRA verstößt, stellen Sie sich einfach vor, der CRA würde zurückfragen: „Haben Sie alle Cybersecurity-Risiken adressiert, die das für Ihr Produkt mit sich bringt?“
Falls ja, dann nur zu! Die CE-Kennzeichnung dürfen Sie behalten. Falls nein, war es das mit der Compliance.
Bevor Sie jetzt auf mich losgehen: Ich weiß, dass es in der Praxis nicht immer so einfach ist. Sehen wir uns ein Beispiel an, das vielen OT-Herstellern Kopfschmerzen bereitet und zur gebotenen Relativierung des Themas taugt: unsichere Legacy-Protokolle.
Wir wissen alle, dass die OT in großen Teilen noch mit unsicheren älteren Protokollen arbeitet. Ohne Authentifizierung und ohne Verschlüsselung.
Das Problem ist spätestens seit Dale Petersons Project Basecamp 2012 bekannt, und Anfang des Jahres hat die CISA mit ihrem Whitepaper „Why Johnny Can’t Authenticate“ daran erinnert, dass es immer noch nicht gelöst ist. Das Paper geht auch darauf ein, wie Hersteller und Betreiber gemeinsam zur Lösung des Authentifizierungsproblems beitragen können. Eine spannende Lektüre, aber hier nicht das Thema.
Tatsache ist, dass unsichere Protokolle in der OT immer noch der Status quo sind.
Wer entscheidet nun, ob Sie ein Produkt mit einem unsicheren Legacy-Protokoll verkaufen dürfen? Sie kennen die Antwort: Natürlich tun Sie das selbst. Je nach Risiko.
Und nein, ganz einfach ist das nicht. Denn selbstverständlich sind unsichere Protokolle mit Risiken verbunden. Je nachdem, wo genau sie eingesetzt werden, sogar mit erheblichen Risiken.
Bedeutet das, Sie dürfen keine OT-Produkte mit unsicheren Legacy-Protokollen verkaufen?
Nein. Es bedeutet nur, dass Sie für das Risiko verantwortlich sind. Und das bedeutet: Sie müssen das Risiko bewerten und adressieren.
Auch das ist kein Grund zur Panik. Sehen wir uns erst einmal an, was Sie für Optionen haben:
Im Idealfall bedeutet „adressieren“, dass Sie grundlegende Anforderungen umsetzen, die das Risiko beheben. Das heißt in diesem Fall: Sie implementieren statt dem unsicheren ein sicheres Protokoll.
Aber Sie dürfen die Betriebsumgebung Ihres Produkts und die möglichen Einschränkungen berücksichtigen. Das ist der erste Faktor, der Ihre Verantwortung für das Cybersecurity-Risiko relativiert.
Eine Einschränkung könnte die Interoperabilität sein. Vielleicht wird das ältere Protokoll gebraucht, weil Ihr Produkt mit Komponenten einer Anlage kommunizieren soll, die nur dieses Protokoll verstehen. In diesem Fall sind Sie zwar immer noch dafür verantwortlich, dieses Risiko zu adressieren — aber vielleicht nicht mit einer grundlegenden Anforderung, sondern mit ausgleichenden oder alternativen Maßnahmen. Der CRA sagt das nirgendwo ausdrücklich, die Guidance der EU-Kommission hingegen schon (Ziffer 29).
Wichtig ist aber: Die Verantwortung für das Cybersecurity-Risiko Ihres Produkts behalten Sie während der gesamten Nutzungsdauer des Produkts. Nur weil die Interoperabilität heute eine Einschränkung ist, heißt das nicht, dass sie das zwingend für immer bleibt. Sie haben die Verantwortung, das Risiko und die Einschränkung zu überwachen und die nötigen Anpassungen vorzunehmen.
Als es vorhin um neu aufgetretene Schwachstellen ging, wurde es schon klar: Die Verantwortung für ein Produktrisiko ist keine einmalige Aufgabe, sondern eine kontinuierliche Tätigkeit.
Der zweite relativierende Faktor für Ihre Verantwortung ist die Zweckbestimmung Ihres Produkts.
Sie könnten das Risiko des Legacy-Protokolls auch so adressieren, dass Sie die Zweckbestimmung des Produkts exakter definieren. Vielleicht wäre das Risiko kleiner, wenn Sie sicherstellen könnten, dass die Komponente nur in der Industrieautomation eingesetzt wird und beispielsweise nicht in der Gebäudeautomation, wo die Wahrscheinlichkeit höher ist, dass sie mit kommerziellen IT-Standardkomponenten mit Internetzugang interagiert.
Fazit:
Verantwortung lässt sich nicht auf Kunden oder Versicherungen abwälzen
An dieser Stelle müssen wir eines unmissverständlich klarstellen: Für das Cybersecurity-Risiko Ihrer Produkte verantwortlich zu sein, bedeutet, dass Sie etwas tun, um das Risiko auf ein akzeptables Niveau zu reduzieren.
Das hat zwei Seiten: Zuerst müssen Sie etwas TUN. Wenn für Ihre Kunden ein Cybersecurity-Risiko besteht, können Sie das nicht einfach hinnehmen.
Wissen Sie noch, was wir über das New Legislative Framework gesagt hatten, in dem definiert ist, warum Produkte CE-Kennzeichnungen tragen? Es geht darum, dass der Produktnutzer das Produkt gefahrlos nutzen kann.
Wer entscheidet, was ein akzeptables Risiko ist? Sie selbst. Je nach Risiko. ABER Sie gehen dabei bitte nicht vom Risikoappetit Ihrer eigenen Organisation aus, sondern von der Sicht Ihrer Kunden. Das Risiko für Ihre Kunden muss auf ein akzeptables Niveau reduziert werden. Ein Restrisiko darf bleiben, aber erst, wenn Sie zuvor auch etwas GETAN haben. Sie können das Risiko nicht einfach für Ihre Kunden akzeptieren, denn damit würden Sie die Verantwortung auf sie übertragen.
Und das dürfen Sie nicht. Nur Sie sind verantwortlich für das Cybersecurity-Risiko Ihrer Produkte.
Das bedeutet also, dass Sie etwas gegen das Risiko TUN, bis es akzeptabel ist. Betonung auf TUN.
Auf der anderen Seite liegt die Betonung auf SIE: Für das Cybersecurity-Risiko Ihres Produkts verantwortlich zu sein, bedeutet auch, dass SIE etwas tun. Betonung auf SIE.
Wenn Ihre einzige Maßnahme zum Adressieren des Risikos etwas ist, das Ihre Kunden tun müssen, überlegen Sie bitte noch einmal. Denn auch das würde die Verantwortung für das Cybersecurity-Risiko auf Ihre Kunden abwälzen.
Sie können das Risiko übrigens auch nicht übertragen, indem Sie eine Cyber-Versicherung abschließen. Das würde bedeuten, dass ein Versicherer die Verantwortung übernimmt — was, wie Sie inzwischen wissen, nicht im Sinne des CRA ist. Die Verantwortung für das Cybersecurity-Risiko Ihres Produkts bleibts immer bei Ihnen.
Sie können frei entscheiden, wie Sie diese Cybersecurity-Risiken adressieren, aber es liegt in Ihrer Verantwortung, das zu tun. SIE müssen Ihren Teil TUN.
Fazit:
Risiken kommunizieren
Es gibt noch einen letzten wichtigen Aspekt, um Ihrer Verantwortung für das Cybersecurity-Risiko gerecht zu werden.
Rufen wir uns noch einmal in Erinnerung, welche Möglichkeiten es gibt, das Risiko des Legacy-Protokolls zu adressieren:
Nur Kompensationsmaßnahmen zu treffen, ist in Ordnung — solange Sie das Ihren Kunden klar kommunizieren.
Vielleicht können manche Kompensationsmaßnahmen nicht im Produkt umgesetzt werden, sondern müssen vom Kunden in der Produktumgebung implementiert werden. Auch das ist in Ordnung — solange Sie das klar kommunizieren.
Es ist okay, die Zweckbestimmung Ihres Produkts einzuschränken. Solange Sie das Ihren Kunden transparent kommunizieren und es der tatsächlichen Nutzung des Produkts (der vernünftigerweise vorhersehbaren Verwendung) entspricht, werden Sie damit Ihrer Verantwortung gerecht.
Es wird auch ein Restrisiko geben. Das ist in Ordnung — solange Sie es Ihren Kunden klar kommunizieren.
Transparente Kommunikation gehört unbedingt dazu, wenn man für das Cybersecurity-Risiko verantwortlich ist.
In anderen Regelwerken ist Compliance eine Sache zwischen Ihnen und irgendeiner Stelle. Kunden oder die Öffentlichkeit bemerken es in der Regel gar nicht, wenn Sie gegen eine Vorschrift verstoßen.
Beim CRA ist die Compliance eine öffentliche Sache. Für die Cybersecurity Ihres Produkts Verantwortung zu übernehmen, bedeutet auch, Verantwortung für die Cybersecurity-Kommunikation gegenüber Kunden und Lieferanten zu übernehmen.
Fazit:
Sie müssen lernen, gute risikobasierte Entscheidungen zu treffen
Wenn wir uns all das ansehen, wird klar: Der CRA regelt alles so, dass Sie als Produkthersteller für die Cybersecurity Ihres Produkts verantwortlich sind. Und es gibt keine Möglichkeit, sich dieser Verantwortung zu entziehen.
Wann immer Sie versuchen, die Verantwortung auf Gesetzgeber, Normierungsorganisationen, Lieferanten, Kunden oder Versicherungen abzuwälzen, geht das nach hinten los.
Das Gute daran ist: Sobald Sie das verstanden haben, wird der Weg zur CRA-Einhaltung viel leichter.
Wenn Sie eine schwierige Frage zur CRA-Umsetzung umtreibt, stellen Sie sich immer vor, der CRA würde zurückfragen: „Haben Sie alle Risiken adressiert?“
Sie können tun, was Sie wollen … solange alle Cybersecurity-Risiken Ihrer Produkte adressiert sind. Das gibt Ihnen einen großen Gestaltungsspielraum.
Ihre oberste Priorität für die CRA-Umsetzung sollte also sein, erfolgreiche risikobasierte Entscheidungen zu treffen — und zu kommunizieren.
Wie das geht, erfahren Sie jetzt.
So werden Sie Ihrer Verantwortung gerecht: 6 Schritte
Definieren wir erst einmal, was wir mit „erfolgreich“ meinen. Sie treffen erfolgreich risikobasierte Entscheidungen, wenn Sie diese drei Dinge erreichen:
- Alle Risiken sind adressiert.
- Der CRA wird eingehalten.
- Sie finden die schlanksten Anforderungen für die beiden ersten Dinge — den wirtschaftlichsten Weg zur CRA-Compliance.
Es gibt drei Erfolgsfaktoren, die Ihnen helfen, das zu schaffen:
Erfolgsfaktor 1: Business- und Cyberkontext verstehen
Sie müssen natürlich erst einmal Ihr Produkt (das Cybersystem) verstehen, um das Cyber-Risiko ermitteln zu können.
Aber in diesem ersten Schritt müssen Sie auch den Business-Kontext verstehen — und zwar den Ihrer Kunden. Das sorgt dafür, dass Ihre risikobasierte Entscheidungsfindung den CRA-Vorgaben genügt. Sie wissen ja noch: Es geht darum, dass Ihre Kunden Ihre Produkte gefahrlos nutzen können.
Der erste Erfolgsfaktor besteht deshalb darin, nicht nur das Cybersystem zu verstehen, sondern auch dessen Kontext.
Die zentrale Frage lautet: „Wie könnte das Cybersystem an Risiken (für die echte Welt) beteiligt sein?“. Das müssen Sie beantworten können, um die wirklich relevanten Risiken anzugehen. Meist ist das nur eine Teilmenge der endlosen Liste ALLER Cybersecurity-Risiken. Ein klares Verständnis von Ihrem Business- und Cyberkontext spart Ihnen also jede Menge Arbeit.
Erfolgsfaktor 2: Systematische Risikologik
Wie Sie jetzt wissen, gibt Ihnen der CRA keine konkrete Liste von Cybersecurity-Anforderungen, die Sie einhalten müssen. Er enthält grundlegende Anforderungen, die Sie berücksichtigen müssen, und vielleicht gibt es auch zusätzliche harmonisierte Normen, die Sie verwenden können. Aber am Ende entscheiden Sie allein, welche Maßnahmen zu treffen sind. Je nach Risiko.
Deshalb ist eine systematische Risikologik nötig: Damit ermitteln Sie, welche Security-Anforderungen wirklich relevant sind — für Ihre Cybersecurity und für Ihre CRA-Compliance. Eine systematische Risikologik etabliert eine direkte Argumentationslinie vom Businesskontext über das Cybersicherheitsrisiko bis hin zu den Cybersecurity-Anforderungen. Je klarer Ihre Risikologik ist, desto kürzer fällt die Liste Ihrer Cybersecurity-Anforderungen aus.
Erfolgsfaktor 3: Erklärbare Compliance
Wie wir vorhin bereits besprochen haben, schließt die Verantwortung für das Cybersecurity-Risiko auch dessen transparente Kommunikation ein. Sie müssen Ihre Kunden über die Risiken informieren, auf Anfrage die Marktaufsicht und bei einer Konformitätsbewertung durch Dritte auch Konformitätsbewertungsstellen.
Natürlich erfordert der CRA einen schriftlichen Nachweis für die Compliance.
Ein schriftlicher Nachweis, der Ihre systematische Risikologik genau erklärt, ist für die Rechtssicherheit unerlässlich. Die gute Nachricht: Wenn Sie die Erfolgsfaktoren 1 und 2 gemeistert haben, ist die Grundlage schon da. Sie wissen, dass Sie genau die realen Risiken adressieren, um die es dem Regelwerk geht, und Sie können für diese Auswirkungen die logisch passenden Security-Maßnahmen benennen.
Jetzt fehlt nur noch eines: Sie müssen das Ganze so dokumentieren, dass die Behörden (und Sie selbst in 3 Jahren) alles gut nachvollziehen können.
Als Nächstes möchte ich Ihnen sechs Schritte an die Hand geben, die nach meiner Erfahrung am besten funktionieren, um diese drei Erfolgsfaktoren zu meistern. Mit diesem Prozess können Sie erfolgreich risikobasierte Entscheidungen treffen:
Schritt 1: Business-Ziele
Alles fängt mit Ihren geschäftlichen Zielen an. Das ist der „Business“-Teil von Erfolgsfaktor 1.
Das Wichtigste hierbei: Schadensszenarien. Das sind die realen Auswirkungen, die für Ihre Kunden wirklich relevant sind. Es sind meist nur ein oder zwei Handvoll, und sie haben nichts mit Ihren Cybersystemen zu tun. Das muss gar nicht kompliziert sein.
Die Schadensszenarien sind der erste von fünf Filtern, mit denen Sie dafür sorgen, dass Sie sich auf die entscheidenden Anforderungen konzentrieren. Wenn Sie die jetzt klar festlegen, sparen Sie später viel Zeit.
In diesem Schritt legen Sie auch Schutzziele und Ihre Risikomatrix fest.
Schritt 2: Cyber-Systemmodell
Das ist der „Cyber“-Teil von Erfolgsfaktor 1. Sie müssen klar definieren, welche Cybersysteme beteiligt sind und wie sie mit Ihrem Businesskontext zusammenhängen.
Es bietet sich an, in Funktionen oder Use-Cases zu denken, um das Cybersystem zu beschreiben und gleichzeitig den Bezug zum Businesskontext zu behalten. Und vergessen Sie nicht, auch die Menschen zu modellieren, die mit Ihrem System interagieren. Ein gutes Beispiel für eine Funktion ist die Programmierung einer SPS.
Das Cybermodell sollte auf eine Seite passen, das ganze System auf den ersten Blick erfassbar sein. Das ist NICHT die Zeichnung, anhand der Ihre Admins das ganze Cybernetzwerk aufbauen und betreiben, sondern die Übersicht, mit der Sie später Angriffsszenarien ermitteln werden.
Schritt 3: Business Impact
Das ist der erste Schritt für Erfolgsfaktor 2. Er führt Business- und Cyberkontext zusammen. An dieser Stelle beantworten Sie auf systematische Art und Weise die Frage, welche Teile/Funktionen der Cybersysteme welchen Business Impact verursachen können, falls die Integrität, Verfügbarkeit oder Vertraulichkeit verletzt wird.
Widerstehen Sie der Versuchung, den Business Impact für jedes Cyber-Asset einzeln zu bewerten. Es ist sinnvoller, die Cyberfunktionen oder -dienste anzuschauen — denn wie sich der Ausfall von Funktionen oder Diensten auswirkt, lässt sich viel einfacher beantworten als was passiert, wenn ein Cyber-Asset ausfällt.
Das ist der zweite von fünf Filtern, der Ihnen hilft, am Ende die schlanksten Anforderungen zu haben: Er bewertet die Kritikalität Ihrer Funktionen, sodass sie sich auf die kritischsten Funktionen und für jede Funktion auf das kritischste Schutzziel konzentrieren können. Die SPS-Programmierfunktion beispielsweise ist kritisch — aber nur ihre Integrität. Wenn sie eine Zeitlang nicht verfügbar ist, ist das nicht kritisch.
Außerdem geht es hier nur um die schlimmstmöglichen Auswirkungen, und es ist egal, wovon diese verursacht werden könnten.
Schritt 4: Cyber-Risikoanalyse
Hier entsteht Ihre systematische Risikologik. Dafür sind die ersten drei Schritte unverzichtbar, denn sonst setzt Ihre Risikologik im Cybersystem an und kann keinen Bezug zu echten/geschäftlichen Auswirkungen herstellen.
Bei der Risikoanalyse wählen Sie die relevantesten Business Impacts aus. Dann modellieren Sie Bedrohungsszenarien, die erklären, wie ein Missbrauch Ihres Cybersystems zu einem dieser Impacts führen kann. Sie bewerten die Eintrittswahrscheinlichkeit und den Schaden, aus denen sich das Risiko ergibt, und definieren die Security-Anforderungen, die dieses Risiko mindern.
Jetzt verstehen Sie, warum die ersten beiden Filter — die relevantesten Schadensszenarien und die kritischsten Funktionen — so wichtig waren: Die Bedrohungsmodellierung kann unheimlich viel Zeit verschlingen, wenn wir nicht wissen, wo wir aufhören sollen. Wenn Sie Ihrem Bedrohungsmodell zu viele Schadensszenarien und Funktionen füttern, steigt der Aufwand schnell ins Unermessliche.
Für möglichst schlanke Security-Maßnahmen sind in die Risikoanalyse noch zwei weitere Filter eingebaut: Bislang hatten wir uns vor allem mit dem möglichen Schaden beschäftigt. Jetzt, da Sie auch die Wahrscheinlichkeit kennen, können Sie sich auf die wahrscheinlichsten Risikoszenarien konzentrieren — und natürlich das höchste Gesamtrisiko — und für jeden Risikoszenario-Schritt, den Sie bei der Bedrohungsmodellierung ermittelt haben, ganz gezielt die wirksamstem Security-Anforderungen auswählen.
Nach Schritt 4 sollten Sie jede Security-Anforderung bis zur Cybersystem-Funktion und den zugehörigen Business-Zielen zurückverfolgen können. Auf dieser Grundlage können Sie später für jede Security-Anforderung erklären, warum Sie sie ausgewählt haben — oder nicht. Das ist die Methode, mit der Sie erfolgreich risikobasierte Cybersecurity-Entscheidungen treffen und verteidigen.
Noch eine Bemerkung zur Bedrohungsmodellierung. Die Begriffe „Bedrohungsmodellierung“ und „Risikoanalyse“ werden oft synonym verwendet, aber der Unterschied ist jetzt klar: Die Bedrohungsmodellierung ist ein Teil der Risikoanalyse. Ein wichtiger Teil — aber nicht alles. Für risikobasierte Entscheidungen ist eine Bedrohungsmodellierung notwendig, aber zuvor muss der Business-Kontext stehen, und danach müssen noch die Security-Anforderungen ausgewählt werden.
Wenn der Ausgangspunkt Ihrer Bedrohungsmodellierung die Bits und Bytes Ihres Cybersystems sind, verschwenden Sie zum einen Zeit und werden zum anderen Ihrer CRA-Verantwortung nicht gerecht.
Denn vergessen Sie nicht: Der Kern des CRA ist, dass Sie dafür verantwortlich sind, die Cybersecurity-Risiken Ihres Produkts — und die Risiken für Ihre Kunden — zu adressieren. Sie brauchen eine systematische Argumentationslinie vom Risiko Ihrer Kunden bis hin zu den Cybersecurity-Anforderungen und den von Ihnen ausgewählten Maßnahmen.
Stellen Sie sich die Schadensszenarien Ihrer Kunden auf der einen Seite und Ihre Security-Anforderungen auf der anderen Seite als die zwei Buchstützen Ihrer risikobasierten Entscheidung vor. Wenn Sie eine dieser Stützen entfernen, kippt das Ganze, und Ihr Bedrohungsmodell ist für die CRA-Compliance nicht mehr zu gebrauchen.
Schritt 5: Compliance Check
Der letzte Erfolgsfaktor ist die erklärbare Compliance.
Nach den Schritten 1 bis 4 können Sie sich sicher sein, die relevanten Risiken für den CRA adressiert zu haben.
Schritt 5 hat das einfache Ziel, dass Sie sich absolut sicher sind, alle grundlegenden Anforderungen beachtet zu haben. „Beachtet“ heißt dabei nicht unbedingt, dass Sie alle umgesetzt haben, aber mindestens sollten Sie sich alle einmal einzeln vorgenommen und überlegt haben, ob sie auf Ihre Organisation zutreffen. Falls ja, dokumentieren Sie, welche Ihrer Cybersecurity-Anforderungen an deren Umsetzung beteiligt sind. Falls nein, dokumentieren Sie, warum sie nicht zutreffen. Als Vollständigkeitsprüfung, sozusagen.
Das ist der letzte von fünf Filtern, die dafür sorgen, dass Sie am Ende die schlanksten Security-Anforderungen haben. Ich empfehle den Compliance-Check bewusst am Ende der Risikoanalyse und nicht am Anfang. Wenn Sie so vorgehen, kommen hier nur noch minimale Security-Maßnahmen hinzu — nur die, die für die Compliance absolut unerlässlich sind.
Schritt 6: Berichte
Die risikobasierte Entscheidung ist jetzt getroffen — aber Ihr Weg zu erfolgreichen risikobasierten Entscheidungen ist noch nicht zu Ende, und dafür gibt es einen Grund: So gut Ihre risikobasierte Entscheidung auch sein mag, sie ist nicht viel wert, wenn Sie sie Ihren Kunden und den Behörden nicht vermitteln können. Sie wissen ja, dass Ihre Verantwortung für das Cybersecurity-Risiko Ihrer Produkte auch die transparente Kommunikation dieses Risikos einschließt.
Sie brauchen eine technische Dokumentation für Behörden sowie Informationen und Anleitungen für den Nutzer, die allen formalen Anforderungen des CRA genügen und Ihre glasklare, risikobasierte Argumentationslinie in eine Sprache übersetzt, die Behörden und Ihre Kunden verstehen.
Ein guter Bericht ist einer, den Sie auf Anfrage siegessicher hervorholen, weil alle Ihre Cybersecurity-Entscheidungen gründlich durchdacht und logisch nachvollziehbar sind und Sie keinen Zweifel haben, dass Sie alle regulatorischen Anforderungen einhalten.
So etwas entsteht nicht aus dem Nichts.
Sie müssen wissen, welche realen Risiken Sie gemäß CRA zu adressieren haben (Schritt 1).
Sie müssen sich sicher sein, dass Sie Ihr Cybersystem hinreichend verstanden haben (Schritt 2).
Sie müssen wissen, wie Ihr Cybersystem an den Risiken für die echte Welt beteiligt sein kann (Schritt 3).
Sie müssen entlang einer eindeutigen Argumentationslinie erklären, welche Security-Anforderungen Sie angewendet haben, um diese Risiken zu mindern (Schritt 4).
Und Sie müssen sich sicher sein, keine grundlegenden CRA-Anforderungen übersehen zu haben (Schritt 5).
Doch wenn all das einmal steht, dann wissen Sie genau, was Sie in Schritt 6 in Ihren Bericht schreiben müssen, und können jedes einzelne Wort darin souverän begründen.
Und dann können Sie sogar Ihre ganze risikobasierte Entscheidung auf einer Seite darstellen. Hier ein Beispiel:
Sie sehen die relevanten Schadensszenarien — das Risiko Ihrer Kunden.
Sie sehen Ihr Cybersystem, hier die SPS-Programmierfunktion.
Für das Risiko sehen Sie das Bedrohungsmodell (die drei roten Schritte) und die Bewertung der Wahrscheinlichkeit, der Auswirkung und des Risikos.
Sie sehen die Security-Anforderungen, die Sie ausgewählt haben — und wo im Cybersystem Sie diese umsetzen müssen.
Und Sie sehen die grundlegenden CRA-Anforderungen, die dieses Risiko adressieren.
Der CRA macht Sie zum Verantwortlichen für das Cybersecurity-Risiko Ihrer Produkte. Allein Sie.
Wenn Sie für alle Ihre Cybersecurity-Risiken eine solche glasklare Argumentationslinie liefern können und Ihren Teil zum Adressieren der Risiken leisten, dann werden Sie dieser Verantwortung gerecht.
Auf diese Weise wird CRA-Compliance wirklich einfach.
Haben Sie Mut, sich Ihrer eigenen Risikoanalyse zu bedienen
Den CRA hält man nicht ein, indem man Checklisten abhakt, Dokumente erstellt und Audits besteht. Wenn Sie den CRA so betrachten, wird er Ihnen immer bürokratisch und unheimlich aufwendig vorkommen. Keine harmonisierte Norm wird ausreichend konkret sein, keine EU-Guidance praxisnah genug.
Die einzige Lösung besteht darin, dass Sie Ihre Einstellung ändern. Der Weg zur CRA-Compliance wird sofort klar, wenn Sie erst einmal akzeptiert haben, dass Sie die Verantwortung für die Cybersecurity Ihrer Produkte tragen. Und nur Sie.
Niemand wird Ihnen sagen, was genau Sie zu tun haben, um CRA-konform zu sein.
Niemand wird Ihnen sagen, was für Ihr Produkt die richtige Security ist.
Genauso wie niemand Ihnen sagt, welche Features in Ihrem Produkt am wichtigsten sind.
Sobald Sie akzeptieren, dass die Cybersecurity am Ende allein in Ihrer Verantwortung liegt, können Sie sich entspannen. Den CRA einzuhalten, wird leicht. Sie müssen nur lernen, erfolgreich risikobasierte Entscheidungen zu treffen. Statt auf sture Compliance fokussieren Sie sich einfach auf diese Entscheidungen.
Denn gerade mit guten, transparenten, gründlich dokumentierten risikobasierten Entscheidungen werden Sie so CRA-konform, wie es anders gar nicht möglich wäre.
Sie haben also gar keine andere Wahl, als das zu tun, was verantwortungsvolle Menschen seit 1784 tun:
Den Mut haben, sich des eigenen Verstandes zu bedienen.
„Habe Mut, dich deines eigenen Verstandes zu bedienen!“
— Immanuel Kant in Beantwortung der Frage: Was ist Aufklärung?, Berlinische Monatsschrift, 1784
Oder übertragen auf den CRA: Haben Sie Mut, sich Ihrer eigenen Risikoanalyse zu bedienen.
Dieser Beitrag ist als Teil des monatlichen „Security-Briefing für Hard Hats“ erschienen. Das können Sie hier auf Englisch oder hier auf Deutsch abonnieren.
Mit dem Security Engineering Tool haben wir eine Software gebaut, die Sie Schritt für Schritt durch diese 3 Erfolgsfaktoren und die praktische Umsetzung führt.
