Zwei frühere Beiträge in diesem Blog haben die CRA-Cybersicherheits-Risikobewertung als Methode und als Glied in der Dokumentationskette behandelt. Die Arbeitsmethodik zeigte, wie strukturierte Bedrohungsmodellierung sowie die Bewertung von Eintrittswahrscheinlichkeit und Auswirkung die Analyse liefern, die Artikel 13 verlangt, und die Artefaktkette zeigte, wo das Ergebnis zwischen Klassifizierung und technischer Dokumentation steht. Dieser Beitrag behandelt die operative Seite. Er geht Schritt für Schritt durch, wie die Bewertung im Produkt-Workspace von CRA Portal tatsächlich durchgeführt wird, und ordnet jeden Schritt der Verordnung (EU) 2024/2847 und dem Entwurf prEN 40000-1-2 zu, der horizontalen europäischen Norm, die genau für diesen Prozess geschrieben wird.
Der rechtliche Rahmen ist kurz. Artikel 13 Absatz 2 verlangt von Herstellern, die Cybersicherheitsrisiken eines Produkts mit digitalen Elementen zu bewerten und das Ergebnis in Planung, Entwurf, Entwicklung, Herstellung, Lieferung und Wartung zu berücksichtigen. Artikel 13 Absatz 3 verlangt, dass die Bewertung dokumentiert und während des Unterstützungszeitraums aktuell gehalten wird und dass sie angibt, welche der grundlegenden Anforderungen aus Anhang I anwendbar sind und wie sie umgesetzt werden. Artikel 13 Absatz 4 verortet das Ergebnis in der technischen Dokumentation nach Anhang VII. Alles Folgende ist eine Umsetzung dieser vier Sätze.
Wo der Entwurf prEN 40000-1-2 einzuordnen ist
Die Normenreihe EN 40000 ist der erste horizontale Satz europäischer Normen, der eigens für den CRA geschrieben wird, entwickelt von CEN und CENELEC im JTC 13, Arbeitsgruppe 9, auf Grundlage des Normungsauftrags der Kommission. Teil 1-1 definiert das Vokabular. Teil 1-2 beschreibt die Prinzipien und Prozesse der Cyberresilienz. Teil 1-3 behandelt die Schwachstellenbehandlung, weitere Teile mit generischen und produktspezifischen Sicherheitsanforderungen sind in Vorbereitung.
Teil 1-2 ist der Teil, der die Risikobewertung betrifft. Er formuliert vier Prinzipien, einen risikobasierten Ansatz, Security by Design, sichere Voreinstellungen und Transparenz, und beschreibt darauf aufbauend einen Produkt-Risikomanagementprozess aus sechs Aktivitäten. Den Produktkontext herstellen, Risikoakzeptanzkriterien festlegen, die Risiken über Asset-Identifikation, Bedrohungsidentifikation, Risikoabschätzung und Risikobewertung beurteilen, die Risiken behandeln, sie kommunizieren und sie so lange überprüfen, wie das Produkt unterstützt wird. Er beschreibt außerdem die Aktivitäten des sicheren Entwicklungslebenszyklus, die das Ergebnis der Bewertung weiterverarbeiten, und er ordnet seine Anforderungen den grundlegenden Anforderungen aus Anhang I zu, sodass die Befolgung des Prozesses Nachweise gegenüber der Verordnung erzeugt.
Ein Vorbehalt gehört an den Anfang. prEN 40000-1-2 ist ein Entwurf im CEN-Umfrageverfahren. Keine Norm der Reihe EN 40000 ist bislang im Amtsblatt der EU zitiert, keine von ihnen begründet heute eine Konformitätsvermutung, und Kommentare zur Reihe weisen darauf hin, dass der prinzipienorientierte Teil eher als Fundament für die anforderungsbezogenen Teile dienen dürfte als für einen eigenständigen Konformitätsanspruch. Der Grund, sich jetzt daran auszurichten, ist praktischer Natur. Die Prozessstruktur, die Terminologie und die geforderte Nachweiskette sind stabil genug, um darauf aufzubauen, und ein Hersteller, der diesen Prozess 2026 betreibt, trifft die harmonisierten Fassungen mit Unterlagen, die bereits die richtige Form haben, deutlich vor der vollen Geltung der Verordnung am 11. Dezember 2027.
Die Klassifizierung setzt den Rahmen
Jeder Produktdatensatz in CRA Portal beginnt mit einer Klassifizierung. Das Produkt ist Standard, wichtig nach Anhang III Klasse I oder Klasse II oder kritisch nach Anhang IV, und der Workspace speichert eine schriftliche Begründung neben der Klasse. Die Klassifizierung taucht in der Bewertung selbst nie auf, aber sie bestimmt den Konformitätsweg nach Artikel 32 und damit, welcher Prüfung die Bewertung standhalten muss. Ein Standardprodukt kann sich nach Modul A selbst bewerten. Ein wichtiges oder kritisches Produkt steuert auf vollständig angewandte harmonisierte Normen, eine notifizierte Stelle oder eine Zertifizierung zu, was die Messlatte dafür anhebt, wie belastbar jedes Urteil in der Bewertung sein muss. Die gespeicherte Begründung landet in der technischen Dokumentation, denn die Klassifizierungsentscheidung ist das Erste, was ein Prüfer kontrolliert.
Produktkontext und Risikoakzeptanzkriterien
Der Prozess des Normentwurfs beginnt mit Abschnitt 6.2, dem Produktkontext, und der Workspace folgt ihm. Bevor eine Bedrohung benannt wird, sammelt der Produktdatensatz die funktionalen Anwendungsfälle, die Nutzertypen, das Marktsegment und vergleichbare Produkte als Referenz für den Stand der Technik, das Architektur- oder Datenflussdiagramm mit jeder Schnittstelle und die vorhandenen Funktionen des Produkts. Er erfasst außerdem eine Abhängigkeitskarte für die Datenfernverarbeitung, denn der CRA behandelt das Produkt und die von ihm genutzte Fernverarbeitung als ein System. Für jede Funktion, die von einem Backend-Dienst abhängt, werden der Betreiber, die ausgetauschten Daten, das Vertrauens- und Authentisierungsmodell und das Verhalten bei gestörter Verbindung festgehalten.
Hier bekommt der Wortlaut von Artikel 13 Absatz 3 seinen Inhalt. Die Verordnung verlangt, dass die Analyse auf der Zweckbestimmung und der vernünftigerweise vorhersehbaren Verwendung, den Nutzungsbedingungen und der erwarteten Nutzungsdauer beruht. Der Produktkontext ist die dokumentierte Antwort auf alle drei Punkte, und jedes spätere Urteil in der Bewertung führt auf ihn zurück.
Abschnitt 6.3 legt anschließend den Maßstab fest, bevor irgendein Risiko gemessen wird. Aus den rechtlichen Anforderungen an das Produkt und den vertraglichen und sonstigen Erwartungen der Beteiligten leitet der Workspace die Risikoakzeptanzkriterien des Produkts und die dokumentierte Bewertungs- und Behandlungsmethodik ab. Beide werden als eigenständige Artefakte festgehalten. Vor der Bewertung zu entscheiden, was als akzeptabel gilt, klingt nach Bürokratie und ist tatsächlich die Disziplin, die spätere Akzeptanzentscheidungen belastbar macht, denn ein Risiko, das gegen vorab vereinbarte Kriterien akzeptiert wurde, liest sich in einer Prüfung ganz anders als ein Risiko, das akzeptiert wurde, weil der Liefertermin erreicht war.
Bedrohungen, Bewertungen und die Anwendbarkeitstabelle
Abschnitt 6.4 ist die eigentliche Bewertung, und der Workspace führt sie in den vier Schritten durch, die der Normentwurf benennt. Assets werden aus dem Produktkontext identifiziert. Bedrohungen werden je Asset identifiziert, mit systematisch angewandtem STRIDE und gestützt auf einen Bedrohungskatalog für CRA-Produktkategorien, damit die unspektakulären Bedrohungen ebenso erfasst werden wie die interessanten. Jede Bedrohung wird zu einem Risiko mit einer geschätzten Eintrittswahrscheinlichkeit auf einer fünfstufigen Skala von selten bis nahezu sicher und einer geschätzten Auswirkung von vernachlässigbar bis katastrophal. Das Produkt der beiden Werte stuft das Risiko als niedrig, mittel, hoch oder kritisch ein, und der Workspace verfolgt den inhärenten Wert, den Restwert nach Kontrollen und die Reduktion dazwischen.
Die Ergebnisse entsprechen der Liste des Normentwurfs. Ein Register aller identifizierten Risiken mit Schätzungen für Eintrittswahrscheinlichkeit und Auswirkung sowie ein Register der bewerteten Risiken mit einer Begründung überall dort, wo ein Risiko akzeptiert wird.
Dann folgt der Schritt, der aus der Übung eine CRA-Bewertung macht. Artikel 13 Absatz 3 verlangt, dass die Bewertung angibt, ob und wie jede Produktsicherheitsanforderung aus Anhang I Teil I anwendbar ist. Der Workspace erzeugt eine Anwendbarkeitstabelle über Teil I Nummer 2 Buchstaben a bis m, und jede Zeile ist entweder anwendbar mit einem Verweis auf die Beschreibung der Umsetzung oder nicht anwendbar mit einer schriftlichen risikobasierten Begründung. Teil I Nummer 1 und der gesamte Teil II gelten als stets anwendbar, was der Konstruktion der Verordnung entspricht. Der Generator verweigert die Erstellung der Tabelle, solange bei einer nicht anwendbaren Zeile die Begründung fehlt. Eine stillschweigende Auslassung, also genau die Lücke, auf die Marktüberwachungsbehörden trainiert sind, kann es damit nicht in die Dokumentation schaffen.
Die Zuordnung zwischen dem Prozess des Normentwurfs und der Plattform sieht so aus.
| Prozessschritt prEN 40000-1-2 | Im Produkt-Workspace | CRA-Anker |
|---|---|---|
| 6.2 Produktkontext | Anwendungsfälle, Nutzer, Architektur, Schnittstellen, Fernverarbeitungskarte | Art. 13 Abs. 3 Zweckbestimmung und Nutzungsbedingungen |
| 6.3 Risikoakzeptanzkriterien | Kriterien und dokumentierte Methodik aus rechtlichen und Stakeholder-Vorgaben | Art. 13 Abs. 3 dokumentierte Bewertung |
| 6.4 Risikobewertung | Assets, STRIDE-Bedrohungen, 5x5-Bewertung, Register bewerteter Risiken | Art. 13 Abs. 2 Risikoanalyse |
| Ergebnis von 6.4 | Anwendbarkeitstabelle Anhang I Teil I Nr. 2 Buchst. a bis m | Art. 13 Abs. 3 und 4 |
| 6.5 Risikobehandlung | Behandlungsentscheidung mit Begründung je Risiko | Kontrollen nach Anhang I Teil I |
| 6.6 Risikokommunikation | Stakeholder-Dokumentation und nutzergerichtete Hinweise | Nutzerinformationen nach Anhang II |
| 6.7 Risikoüberprüfung | Überprüfungsrhythmus plus erfasste Auslöseereignisse | Art. 13 Abs. 3 Aktualitätspflicht |
Behandlung, Kommunikation und Überprüfung
Die übrigen Abschnitte schließen den Kreis. Nach Abschnitt 6.5 erhält jedes bewertete Risiko eine Behandlungsentscheidung mit Begründung, sei es eine im Entwurf umgesetzte Kontrolle, eine geplante Minderungsmaßnahme oder eine dokumentierte Akzeptanz gegen die Kriterien aus 6.3. Nach Abschnitt 6.6 werden die Behandlungsinformationen für die Beteiligten dokumentiert, und der nutzerrelevante Teil fließt in die Nutzerinformationen ein, die dem Produkt beiliegen. So bleibt die Bewertung konsistent mit dem Anhang-II-Blatt, statt sich davon zu entfernen.
Abschnitt 6.7 behandelt die Pflicht, die die meisten Teams unterschätzen. Artikel 13 Absatz 3 verlangt, die Bewertung während des Unterstützungszeitraums bei Bedarf zu aktualisieren, und dieser Bedarf braucht eine Definition. Der Workspace hält einen festgelegten Überprüfungsrhythmus fest und daneben Auslöseereignisse dreierlei Art. Eine Veränderung der Bedrohungslage, ein Cybersicherheitsvorfall wie ein Incident oder eine Schwachstellenmeldung zum Produkt und eine Veränderung der Risikoexposition, etwa eine neue Schnittstelle oder ein neuer Markt. Jeder Auslöser stößt eine Überprüfung der Bewertung an, und jede Überprüfung wird dokumentiert. Damit wird aus der Aktualitätspflicht ein Nachweis statt einer Absichtserklärung.
Artefakte, Evidenzverankerung und Selbstprüfung
Alles Vorstehende erzeugt Dokumente, und der Normentwurf ist präzise darin, welche. Jeder Prozessschritt definiert erforderliche Eingaben und Ergebnisse, und der Workspace verfolgt knapp neunzig davon über die Risikomanagement-Abschnitte, die Aktivitäten des sicheren Entwicklungslebenszyklus von der Planung bis zur Außerbetriebnahme und zur Sorgfaltsprüfung von Drittkomponenten sowie die Konformitätsdokumente, die EU-Konformitätserklärung nach Anhang V und das Verzeichnis der technischen Dokumentation nach Anhang VII.
Die Artefakte zerfallen in zwei Arten. Deterministische, also die Methodik, die Anwendbarkeitstabelle und die Konformitätsdokumente, werden ohne generativen Schritt direkt aus den Workspace-Daten zusammengesetzt, denn ein Dokument, dessen Inhalt vollständig durch dokumentierte Entscheidungen bestimmt ist, sollte mechanisch entstehen. Die übrigen Artefakte entwirft der Assistent der Plattform aus dem Workspace-Zustand, und zwei Schutzmechanismen halten die Entwürfe am Boden. Erstens sind Entwürfe in der eigenen Evidenz des Herstellers verankert. Hochgeladene Dokumente durchlaufen einen Ablauf aus Analyse, Prüfung und Bestätigung, und nur bestätigte Dokumente fließen in die Entwürfe ein, wobei der Assistent angewiesen ist, die Quelldatei zu zitieren und nichts darüber hinaus zu erfinden. Zweitens kann jeder Entwurf einer Selbstprüfung unterzogen werden. Eine Lückenanalyse bewertet die Vollständigkeit, listet Fehlendes auf und überarbeitet den Entwurf einmal, wenn er schlecht abschneidet, und die Bewertung wird dem Prüfer angezeigt. Ein Mensch nimmt jedes Artefakt ab, bevor es für die Anhang-VII-Dokumentation am Produkt festgehalten wird. Der Assistent entwirft, der Hersteller entscheidet.
Die Schwachstellenbehandlung bleibt angebunden
Eine Risikobewertung, die nie etwas aus dem Feld hört, veraltet planmäßig. Die Seite der koordinierten Schwachstellenoffenlegung von CRA Portal, also das öffentliche Meldeportal, die Triage mit vorgeschlagenem Schweregrad, CVSS-Vektor und Schwachstellentyp sowie die Verfolgung der Artikel-14-Fristen für die 24-Stunden-Frühwarnung, die 72-Stunden-Meldung und den Abschlussbericht, speist die Produktseite direkt. Eine Meldung, die eine vom Modell übersehene Bedrohung offenlegt, ist genau der Auslöser der Kategorie Cybersicherheitsvorfall, den Abschnitt 6.7 definiert. So wird das Offenlegungsprogramm zum laufenden Input, der die Bewertung aktuell hält, ein Zusammenhang, den wir in Schwachstellenmeldung und Produkt-Risikomanagement vertieft haben. Die Schwachstellenbehandlung selbst folgt dem Schwesterentwurf prEN 40000-1-3, dessen Zuordnung die Plattform Abschnitt für Abschnitt auf der Normseite zu EN 40000-1-3 dokumentiert.
Momentaufnahmen und die Zehnjahresakte
Artikel 13 Absatz 4 gibt der Bewertung einen langen Nachlauf. Die technische Dokumentation ist zehn Jahre oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, welcher Zeitraum länger ist, und zu jeder Einheit kann eine Behörde fragen, welche Fassung der Bewertung sie abdeckte. Der Workspace beantwortet das mit unveränderlichen Momentaufnahmen. Beim Inverkehrbringen eines Produkts und erneut bei jeder wesentlichen Änderung wird der vollständige Bewertungszustand eingefroren und aufbewahrt. Die Antwort auf die Frage, was beim Versand dieser Einheit bekannt und entschieden war, ist damit ein abrufbarer Datensatz und kein Ausgrabungsprojekt in der Versionsgeschichte eines Wikis.
Was das für Hersteller bedeutet
Die Verordnung sagt, was die Risikobewertung leisten muss. Der Normentwurf sagt, welcher Prozess sie hervorbringt, und es ist der Prozess, den die harmonisierten Normen später formalisieren werden. Ihn heute zu betreiben heißt, den Produktkontext herzustellen, Akzeptanzkriterien festzulegen, Risiken je Asset und Bedrohung mit dokumentierten Schätzungen zu bewerten, die Anwendbarkeit von Anhang I mit einer Begründung für jede Ausnahme zu entscheiden, Risiken zu behandeln und zu kommunizieren und das Ganze in festem Rhythmus mit definierten Auslösern zu überprüfen. CRA Portal operationalisiert jeden dieser Schritte und hält die Eingaben und Ergebnisse fest, die der Normentwurf benennt. Dieselbe Arbeit, die das Risiko des Produkts steuert, stellt damit auch die Nachweise zusammen, die Artikel 13 und Anhang VII verlangen. Die Norm wird ihren Weg ins Amtsblatt in ihrem eigenen Tempo gehen. Für Hersteller, die ihren Prozess früh daran ausgerichtet haben, wird dieses Ereignis nichts mehr ändern.