Ein erster Blick auf den CRA – aus Perspektive der ISO/SAE 21434

Bevor es losgeht, beginnen wir mit den Ausnahmen. Von den Anforderungen des CRA ausgenommen sind bestimmte Branchen und Produktgruppen, die bereits anderweitig unter hier heranzuzuziehende Verordnungen fallen. Dazu zählen auch Fahrzeuge, die im Rahmen der Typzulassung der UN Regulation Nr 155 unterliegen. Wer also formal unter eine branchenspezifische Richtlinie fällt (u.a. auch zivile Luftfahrt, Medizinprodukte u.a.), für den findet der CRA keine Anwendung.

Als Profi für Fahrzeug-Cybersicherheit werden Sie jetzt wahrscheinlich hellhörig: Hier ergibt sich eine interessante Situation. Formal gilt die UN R155 ja nur für Fahrzeughersteller. Diese werden jedoch für die Cyberrisiken ihrer Supply Chain verantwortlich gemacht. Sie kaskadieren daher die UN R155-Anforderungen in der Regel 1:1 weiter. Betrachtet man Entwicklungsprojekte in der Praxis, in denen Lieferanten und Technologieanbieter mit ihrer Hardware, Software, Steuergeräten und vernetzten Komponenten marktübergreifend als Anbieter am Markt auftreten, dann dürfte der CRA sehr wohl Anwendung finden. Dies gilt besonders für Akteure, die ihre Produkte im weit gefassten Automotive-Ökosystem über das reine Fahrzeug (und die zugehörige Typzulassung) hinaus platzieren.

Die ISO/SAE 21434 mit dem Cyber Resilience Act vergleichen: Warum das Ganze?

Wichtig ist zu verstehen: Der Cyber Resilience Act, dessen erste Anforderungen bereits 2026 verpflichtend werden und dessen vollständige Anwendung ab Dezember 2027 erfolgt, stellt faktisch eine Markteintrittsbarriere für Produkte innerhalb der EU dar. Wer die entsprechenden Anforderungen an Cybersicherheit nicht erfüllt, soll seine Produkte „mit digitalen Elementen“ nicht mehr innerhalb der EU verkaufen können.

Entsprechend lohnt sich der Blick auf die Besonderheiten des CRA. Wer mit dem ISO/SAE 21434-Standard (offiziell im Jahr 2021 erschienen) bereits vertraut ist, wird im Abgleich zwischen ISO/SAE 21434 und CRA vier Möglichkeiten feststellen:

• Synergien, z.B. fordern beide Richtlinien eine strukturierte Cybersecurity-Governance, eine systematisierte Risikobewertung (Hallo, Threat Analysis & Risk Assessment!) und die kontinuierliche Schwachstellenbehandlung.
• Erweiterungen, z.B. bleibt die ISO/SAE 21434 an vielen Stellen abstrakt, während der CRA horizontale Marktanforderungen konkret aufzeigt, wie etwa die CE-Kennzeichnung, bestimmte verpflichtende Meldungen und die Erforderlichkeit der Software-Bill-of-Materials-(SBOM)-Dokumentation.
• Neue Dimensionen/Kontext, z.B. werden im CRA spezifisch Marktüberwachung, administrative Strafen und EU-weite Reporting-Systeme genannt.
• Praktischer Nutzen, z.B. ganz konkret werden Unternehmen mit bestehender ISO/SAE 21434-Compliance diese als Fundament nutzen können; müssen jedoch dennoch signifikante Ergänzungen vornehmen.

Die Struktur der ISO/SAE 21434 als Fundament für die effiziente Umsetzung des CRA

Lassen Sie uns nachfolgend high-level einmal durch alle Clauses der ISO/SAE 21434:2021 gehen, um eine erste Analyse zwischen beiden Richtlinien zu erarbeiten.

Clause 5 Organizational Cybersecurity Management – Welche Äquivalenz bringt der CRA?

Clause 5 der ISO/SAE 21434 bezieht sich auf die organisatorischen Cybersicherheitsanforderungen und das Cybersecurity Management im Kontext von Organisation, Prozessen und Strukturen. Dabei schafft die ISO/SAE 21434 ein detailliertes organisatorisches Rahmenwerk. Cybersecurity Governance wird umfassend definiert, indem unter anderem konkrete Pflichten für Organisationen festgelegt werden, beispielsweise in den Bereichen Awareness, Kompetenzmanagement, Unternehmenskultur und kontinuierliche Verbesserungsprozesse.

Dabei sollen spezifische Regeln, Policies und Prozesse etabliert werden, die den Informationsaustausch, das Wissen und die Kompetenzen innerhalb der Organisation in Bezug auf Cybersicherheit fördern.

Die ISO/SAE 21434 spezifiziert dafür konkrete Work Products, die erforderlich sind auszuarbeiten, um die aufgezeigte organisatorische Cybersicherheit sicherzustellen. (Diese bilden dann auch die Grundlage für das Cybersecurity Management Systems (CSMS), wie es auch in der UN R155 gefordert wird.)

Im Gegensatz dazu enthält der Cyber Resilience Act keine expliziten organisatorischen Strukturen, definiert keine Prozesse und keine zugehörigen Audits in vergleichbarer Weise. Der CRA verlangt also nicht die Etablierung eines spezifischen Cybersicherheitsmanagementsystems oder konkreter Strukturen, Prozesse, Rollen und Policies, wie es die ISO/SAE 21434 in Clause 5 fordert.

Dennoch erwartet der CRA von Herstellern – gedacht aus der Perspektive des Produkts – angemessene Maßnahmen zur Sicherstellung der Cybersicherheit. Dabei werden kein konkretes Prozessmodell und auch keine detaillierten Vorgaben zur Etablierung von Qualitäts- und Informationssicherheitsmanagementsystemen vorgegeben.

Hilfreich können hier Normen wie ISO 9001 oder ISO/IEC 27001 sein, da sie eine gewisse Prozesslandschaft bieten, in die spezifische CRA-Anforderungen integriert werden können.

Zusammenfassend: Obwohl der CRA keine konkreten Prozess- bzw. Strukturdefinitionen enthält, kann eine Orientierung an der ISO/SAE 21434 dennoch praktisch nützlich und zielführend sein.

Dies gilt insbesondere für die effiziente Regelung von Zuständigkeiten und Abläufen auf Organisationsebene, die erforderlich werden dürften, um alle aufgelisteten Anforderungen an die Produktcybersicherheit erfüllen zu können.

Chapter 6 Projektspezifisches Cybersecurity Management und warum der CRA nicht in Entwicklungsprojekten denkt

Ein zentraler Unterschied zwischen ISO/SAE 21434 und CRA zeigt sich in der Art, wie mit Projekten umgegangen wird. Die ISO/SAE 21434 denkt in klar definierten Entwicklungsprojekten, in denen cybersecurity-relevante Aspekte von Anfang an geplant und dokumentiert werden müssen. Dies erfolgt unter anderem durch den erforderlichen Cybersecurity Plan, in dem Zuständigkeiten, Maßnahmen und Projektstruktur festgelegt werden.

Im sogenannten Cybersecurity Case wird abschließend begründet, warum das Produkt aus Sicherheitssicht als unbedenklich eingestuft werden kann.

Diese Vorgehensweise wird im Rahmen eines Assessments, oft durch eine unabhängige Stelle, überprüft.

Der CRA hingegen denkt nicht in Projekten, sondern fordert die Bereitstellung technischer Produktdokumentation, wie in Artikel 31 und Anhang VII beschrieben.

Daneben gibt es im CRA keine expliziten Verpflichtung, Aktivitäten oder Verantwortlichkeiten projektbasiert zu strukturieren.

In der Praxis ist es dennoch empfehlenswert, die Erstellung der Dokumentation sinnvoll ins Projektmanagement zu integrieren – etwa, um Kosten, Verzögerungen oder Abstimmungsprobleme zu vermeiden. Anders als bei der ISO/SAE 21434 ist im CRA kein Nachweis der Planung erforderlich.

Gerade in der Automobilindustrie, in der Entwicklungsprojekte komplex sind und viele Stakeholder involviert sind, ist es sinnvoll, die Cybersecurity-Dokumentation nicht isoliert, sondern im Rahmen etablierter Projektstrukturen zu erstellen. In anderen, weniger projektlastigen Branchen mag das Vorgehen freier sein – dennoch sollte auch dort eine gewissenhafte Planung mit Blick auf die letztendlich produktspezifischen Cybersicherheitsvorgaben nicht fehlen.

Mit Blick auf die Dokumentation, als ein Teil eines cybersicherheitsrelevanten Nachweises, sei hier erwähnt: Ein weiteres verbindendes Element ist die sogenannte Konformitätsbewertung im CRA. Sie erinnert an das Cybersecurity Assessment aus der ISO/SAE 21434, geht aber regulatorisch noch weiter: Der Händler – also der Inverkehrbringer – muss nachweisen, dass die Cybersicherheitsanforderungen erfüllt sind (siehe CRA, Anhang I).

Je nach Kritikalität des Produkts genügt eine Selbsterklärung, oder es ist eine Bewertung durch eine spezifische Drittstelle notwendig – insbesondere bei sicherheitskritischen oder stark vernetzten Produkten.

Zusammenfassend: Die Erarbeitungen von Cybersecurity Plan, Cybersecurity Case und einem Cybersecurity Assessment Report (gemäß ISO/SAE 21434) werden vom CRA auf diese Weise nicht explizit gefordert. Sie können aber eine sinnvolle Stütze (im Sinne einer Zuarbeit!) für die Erfüllung der CRA-Nachweispflichten sein. Und abstrakter formuliert: Wie ein Entwicklungsprojekt die auferlegten Pflichten des CRA erfüllt, ist ihm egal.

Clause 7 Distributed Cybersecurity activities – Der genaue Blick auf die Herstellerhaftung im CRA

Ein entscheidender Unterschied zwischen ISO/SAE 21434 und CRA zeigt sich in der Art und Weise, wie mit Lieferanten und kontinuierlichen Sicherheitsaktivitäten umgegangen wird – also mit dem, was „nach dem Projektstart“ oder sogar „nach Start of Production (kurz: SOP)“ geschieht.

Die ISO/SAE 21434 unterscheidet klar zwischen

• verteilter Entwicklung, z.  wenn ein Zulieferer ein System im Kundenauftrag entwickelt
• und Komponenten, die als sogenannte „Off-the-shelf“-Produkte (z.  standardisierte Hardwaremodule) in ein Fahrzeug integriert werden.

Für beide Fälle verlangt der Standard, dass Zuständigkeiten eindeutig definiert werden – idealerweise in Form einer cybersicherheitsspezifischen Leistungsschnittstellenvereinbarung, dem sogenannten Cybersecurity Interface Agreement (kurz: CIA) – und dass dass Cybersecurity-Aktivitäten über den gesamten Produktlebenszyklus hinweg berücksichtigt werden.

Der CRA unterscheidet hingegen zunächst nicht explizit zwischen unterschiedlichen Modellen der Zusammenarbeit (z. B. OEM vs. Tier-1).

Er stellt aber dennoch klare Anforderungen: Hersteller, die ein Produkt in Verkehr bringen, sind für die Einhaltung der Cybersecurity-Anforderungen voll verantwortlich – inklusive aller integrierten Komponenten.

Das heißt: Auch wenn ein Hersteller ein Produkt eines Zulieferers (weiter-)verwendet, muss er sicherstellen, dass die Cybersicherheit dieses Bausteins in seinem Produkt gewährleistet ist.

Dazu gehört entlang des CRA insbesondere ein funktionierendes Vulnerability Management entlang der gesamten Lieferkette. Hersteller müssen also Prozesse etablieren, um Schwachstellen in Komponenten – auch von Dritten – zu identifizieren, zu bewerten und gegebenenfalls Updates bereitzustellen. Dies betrifft den gesamten Produktlebenszyklus bis zur vollständigen Außerbetriebnahme, genau wie es bei der ISO/SAE 21434 der Fall ist.

Obwohl der CRA keinen expliziten Abschnitt zu Anforderungen an das Lieferantenmanagement enthält, wird in mehreren Artikeln und Erwägungsgründen (zum Beispiel Artikel 13 und Erwägungsgrund 34) darauf hingewiesen, dass Hersteller nur dann Produkte in den Verkehr bringen dürfen, wenn sie die Sicherheit der integrierten Komponenten gewährleisten können.

Dies umfasst auch Open-Source-Komponenten. Damit wird klar: Auch ohne eine cybersicherheitsspezifische Formalisierung der Cybersicherheitszuständigkeiten, wie sie das CIA der ISO/SAE 21434 vorsieht, müssen Hersteller organisatorische und technische Maßnahmen treffen, um ihre involvierte Lieferkette cybersicherheitsseitig im Griff zu behalten.

Ein besonderer Knackpunkt im Kontext des CRA ist hier auch der Umgang mit Zulieferern aus Nicht-EU-Staaten. Diese unterliegen formal zwar nicht den Anforderungen des CRA, dennoch bleibt der europäische Inverkehrbringer voll verantwortlich für die Cybersecurity-Konformität des Gesamtprodukts.

Unternehmen müssen deshalb sicherstellen, dass auch Komponenten aus Drittstaaten den EU-Anforderungen entsprechen – etwa durch vertragliche Vereinbarungen, technische Nachweise oder zusätzliche Sicherheitsprüfungen. (Im Zuge geopolitischer Verschiebungen sind hier stets neue Entwicklungen denkbar, wie der kürzliche US-Bann spezieller Automotive-Komponenten aus China und Russland zeigt.)

Zusammengefasst: Der CRA stellt mit seinen Anforderungen nach Due Dilligence, der Software-Bill-of-Materials und der technischen Doku klar, dass Hersteller hier auch bei Nutzung von Drittkomponenten vollumfänglich in der Pflicht stehen; Gleichzeitig wird auf Formalisierung hier weitestgehend verzichtet.

Clause 8 Continual Cybersecurity Activities – Pflicht zum Cybersicherheits-Support über Jahre, Meldepflichten und mehr (der Kern des CRA!)

Die cybersicherheitsrelevanten Erforderlichkeiten enden nicht mit der Auslieferung eines Produkts: Sowohl ISO/SAE 21434 als auch CRA verlangen, dass Hersteller auch nach dem Serienstart aktiv bleiben, insbesondere im Hinblick auf (neue) Schwachstellen und Sicherheitsvorfälle.

Die ISO/SAE 21434 fordert dafür, dass ein cybersicherheits-spezifisches Monitoring etabliert wird, sobald ein Produkt im Feld ist. Der Standard beschreibt dabei sogar ein mehrstufiges Vorgehen, das präzise regelt, wie mit sicherheitsrelevanten Informationen umgegangen werden muss – von der Erfassung über die Bewertung der Kritikalität bis hin zur Klassifizierung als Schwachstelle oder gar Vorfall.

Hersteller bzw. Zulieferer müssen demzufolge Prozesse schaffen, um potenzielle Risiken während der Betriebsphase fortlaufend zu analysieren und zu bewerten (hier kommt auch das CIA zum Tragen!).

Der CRA geht hier noch weiter. In Bezug auf die Notwendigkeit, Cybersicherheit auch nach dem Inverkehrbringen zu überwachen, macht der CRA verbindliche Vorgaben: Laut Artikel 13, Absatz 8 müssen Hersteller während der erwarteten Produktlebensdauer und des zugesagten Unterstützungszeitraums sicherstellen, dass Schwachstellen – einschließlich solcher in integrierten Komponenten – adressiert und behandelt werden.

Die CRA-Verordnung schreibt darüber hinaus präzise vor, dass sich dieser Zeitraum an der typischen Nutzung des Produkts orientieren muss, wobei Nutzererwartung, Produkttyp und Zweckbestimmung zu berücksichtigen sind. Darüber hinaus gilt: Mindestens fünf Jahre (!) lang müssen Hersteller cybersicherheits-spezifischen Support gewährleisten.

Dies ist quasi als Erweiterung, bzw. Konkretisierung zu betrachten, die der CRA hier reinbringt: Während die ISO/SAE 21434 keine feste Zeitangabe für den Supportzeitraum macht (sie fordert lediglich eine “Communication of End of Cybersecurity Support”), legt der CRA hier klare Mindestanforderungen fest. Das bedeutet für Hersteller, dass die Verantwortung über den SOP hinaus deutlich konkreter spezifiziert ist.

Besonders relevant ist auch die im CRA verankerte Meldepflicht im Falle einer ausgenutzten Schwachstelle, wie in Artikel 14 beschrieben. Eine solche Pflicht existiert in der ISO/SAE 21434 nicht – dort wird lediglich ein strukturiertes Schwachstellenmanagement empfohlen.

Der CRA verlangt hingegen, dass ein Hersteller innerhalb von 24 Stunden nach Kenntnisnahme einer aktiven Ausnutzung eine erste Meldung absetzt. Innerhalb weiterer 72 Stunden müssen Informationen zu geplanten oder eingeleiteten Korrekturmaßnahmen folgen (Vgl. Artikel 14). Nach spätestens 14 Tagen ist ein umfassender Abschlussbericht zu erstellen, der Details zur Schwachstelle, ihrer Schwere und den umgesetzten Maßnahmen enthält.

Für den Automotive-Bereich ist diese Pflicht übrigens nicht neu: Die UN R155 stellt ähnliche Anforderungen an Fahrzeughersteller/OEM.

Mit dem CRA werden diese Pflichten jedoch auf eine deutlich breitere Produktpalette ausgeweitet – und betreffen somit auch unzählige Zulieferer und Komponentenhersteller, die bislang nicht im Fokus derartiger Meldepflichten standen.

Zusammengefasst: Das laufende Vulnerability-Handling, die Meldepflichten sowie die Cybersecurity-Support-Periode (und Update-Vorhaltung) sind im CRA präziser definiert als in der ISO/SAE 21434; Die Work-Product-Artefakte, bzw. die prozessuale Struktur des Standards sind hier nur ein Teil der weitreichenden Verpflichtungen, mit denen viele Akteure wohl zum ersten Mal konfrontiert sein dürften.

Clause 9 Produktentwicklung gemäß ISO/SAE 21434 (mit Item Definition & Co) vs. Anforderungen der CRA

Aus Sicht der Produktentwicklung beginnt die ISO/SAE 21434 mit der Item Definition. Das Ziel dieses Work Products ist es, ein vollständiges Verständnis und eine klare Abgrenzung des betrachteten Systems zu schaffen – als Grundlage für alle nachfolgenden Schritte, wie etwa das cybersicherheits-spezifische Risiko-Assessment.

Die Item Definition beschreibt typischerweise das System inklusive seiner Schnittstellen, Funktionen, Abhängigkeiten und der verwendeten Komponenten, sofern diese bereits bekannt sind.

Der CRA hingegen fordert kein explizites Dokument zur Beschreibung des geplanten Systems, bzw. Produkts.

Dennoch müssen Hersteller im Zuge der vom CRA explizit genannten Verpflichtung, eine Cybersicherheits-Risikobewertung durchzuführen (Vgl. Artikel 13), verschiedene Informationen über das Produkt bereitstellen, beispielsweise zur Zweckbestimmung, den Rahmenbedingungen der Nutzung und der Betriebsumgebung.

Das bedeutet: Der CRA setzt ein dokumentiertes Systemverständnis nur indirekt voraus und nennt dies nicht explizit als formale Anforderung.

Das Cyberrisiko-Assessment der ISO/SAE 21434, die sogenannte Threat-Analysis-and-Risk-Assessment-(TARA)-Methodik definiert spezifische Cybersecurity Goals, die als Schutzziele oder Cybersecurity Requirements auf hohem Abstraktionsniveau verstanden werden können. Diese Ziele beschreiben die technischen Risiken des Produkts, von denen konkrete Maßnahmen abgeleitet werden.

Der CRA definiert die Herangehensweise an das Cybersecurity-Risk-Assessment hier nicht so strukturiert.

Eine der wichtigsten Kernaussagen hierzu findet sich in Artikel 13, Absatz 1:

Wenn sie ein Produkt mit digitalen Elementen in den Verkehr bringen, gewährleisten die Hersteller, dass dieses Produkt gemäß den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I konzipiert, entwickelt und hergestellt worden ist.

Der genauere Blick auf Anhang I „Grundlegende Cybersicherheitsanforderungen“ macht bereits deutlich, dass dort indirekt vorausgesetzt wird, dass Sicherheitsziele bekannt sind und in die Produktentwicklung einfließen. Allerdings gibt es im CRA dennoch keine explizite Forderung, solche Ziele formal (beispielsweise im Rahmen eines Cybersecurity Concepts) zu definieren, wie es im ISO/SAE 21434-Standard der Fall ist.

In der ISO/SAE 21434 werden im Anschluss daran im Rahmen des Cybersecurity Concepts technische und organisatorische Maßnahmen definiert, die zur Erfüllung der zuvor gesetzten Ziele beitragen. Diese Konzeptentwicklung stellt eine methodisch nachvollziehbare Brücke zwischen Analyse und Umsetzung dar.

An dieser Stelle wird der CRA konkreter. In Anhang I sind bereits eine Reihe grundlegender Cybersecurity-Anforderungen aufgelistet, darunter z. B. geeignete Kontrollmechanismen zum Schutz vor unbefugtem Zugriff, die Sicherstellung der Vertraulichkeit und Integrität von Daten oder auch Maßnahmen zur Reduzierung der Angriffsfläche.

Zusammengefasst: Die ISO/SAE 21434 liefert in der Concept Phase eine strukturierte Vorgehensweise zur Herleitung und Dokumentation von Sicherheitsmaßnahmen. Der CRA verlangt vergleichbare Inhalte, lässt jedoch die Vorgehensweise der Umsetzung, bzw. Erarbeitung undefiniert.

Clause 10 und 11 Implementierung von Cybersicherheit und die Überprüfung – Das Vorgehen der ISO/SAE 21434 und der offene Ansatz des CRA

Seit jeher wird in der Fahrzeugentwicklung und der Automobilbranche hitzig darüber diskutiert, dass der ISO/SAE 21434:2021 Standard möglicherweise zu abstrakt ist. Er beschreibt nahezu an keiner Stelle das „Was“, das zu tun ist, sondern liefert zuvorderst vor allem Anforderungen zum „Wie“ etwas zu erledigen ist. (Eben anhand von aufgezeigten Vorgehensweisen, Methodiken, Aktivitäten, Work Products etc.)

Dies wird besonders in der Phase der Produktentwicklung deutlich, in der der Standard mit den Clauses 10 und 11 spezifiziert, wie Cybersicherheit innerhalb der Produktentwicklung ordnungsgemäß zu implementieren ist.

Dabei folgt die ISO/SAE 21434 dem klassischen Ansatz des System Engineerings. Aus dem Cybersecurity Concept werden konkrete Cybersicherheitsanforderungen abgeleitet. Diese werden in die Systemarchitektur integriert und anschließend implementiert.

Nach der Implementierung erfolgt dann die Verifikation, um sicherzustellen, dass die Maßnahmen (die Cybersecurity Controls) korrekt und fehlerfrei funktionieren.

Hierzu fordert der Standard die konsequente Berücksichtigung und Konsistenz im Prozess, also die lückenlose Nachverfolgbarkeit zwischen Anforderungen, Architektur und dem Doing im Testing. Zudem gilt der Grundsatz der Nachvollziehbarkeit und Rückverfolgbarkeit: Alle Schritte und Ergebnisse müssen klar dokumentiert und offene Punkte müssen stets geschlossen werden.

Der Cyber Resilience Act betrachtet dies ganz anders: Zwar sind Hersteller verpflichtet, bestimmte Cybersecurity-Anforderungen umzusetzen (s. vorangegangene Ausführungen dazu), wie diese aber methodisch abgeleitet, spezifiziert und prozessual dokumentiert werden sollen, dazu macht der CRA keine Vorgaben.

Das bedeutet konkret: Cybersicherheit und geschlossene Schwachstellen, die durch Risikoanalysen identifiziert, erkannt und reduziert wurden, müssen im Produkt enthalten sein. Vorgeschriebene Verfahren und Standard-Methodiken definiert der CRA dafür jedoch nicht.

Ähnlich verhält es sich mit der Unterscheidung zwischen Clause 11 Cybersecurity Validation und dem CRA.

Die ISO/SAE 21434 fordert einen eigenständigen Schritt, der über die reine Abarbeitung der Spezifikationen hinausgeht und die Wirksamkeit der implementierten Cybersicherheit im realen Kontext überprüft (d. h., ob die vorab definierten Cybersecurity-Ziele und -Anforderungen tatsächlich erreicht werden).

Der CRA fordert hingegen keinen spezifischen Validierungsprozess, sondern rückt die formale Erfüllung der Anforderungen in den Vordergrund.

So gilt es im Zuge der technischen Dokumentation, die für die CE-Kennzeichnung erforderlich ist, neben der Risikobewertung mit Berichten nachzuweisen, dass die Konformität des Produkts mit den grundlegenden Cybersicherheitsanforderungen (vgl. Anhang I) geprüft wurde. Ein genaueres methodisches Vorgehen dieser Prüfungen oder spezifische Testmethoden gibt der CRA jedoch auch hier nicht vor.

Clause 12 bis 14 Cybersicherheit in der Produktion, Auslieferung, Betrieb und Stilllegung – Was sagen ISO/SAE 21434 und CRA?

Das Produkt ist nun endlich in der Produktion (Start of Production, kurz SOP) und geht in die Nutzung– wir befinden uns nun in der sogenannten Post-Development-Phase. In den letzten Jahren hat das Thema  Cybersicherheit hier ein enormes Umdenken veranlasst. Während früher vor allem die Entwicklungsarbeit im Fokus lag, sind heute auch die nachgelagerten Phasen von ebenso hoher Priorität.

So präzisiert die ISO/SAE 21434 die prozessualen Anforderungen, die auch während dieser Phasen sicherstellen sollen, dass Cybersicherheitsmechanismen vorhanden sind und Risiken konsequent reduziert werden, beispielsweise durch Maßnahmen zum Schutz der Produktion. (s. auch Cybersicherheit in der Fahrzeug-Produktion)

Auch im CRA wird die Phase der Produktion aufgegriffen: So wird in bereits in Artikel 1 spezifiziert, dass Cybersicherheitsanforderungen auch für die Herstellungsphase gelten. Besonders wichtig dabei ist, dass die bereits erwähnte Bewertung der Cybersicherheitsrisiken für ihre Produkte nicht nur die Grundlage für die bereits skizzierten Erfordernisse in der Planungs-, Konstruktions- und Entwicklungsphase des Produkts bildet, sondern auch für die Herstellung, Auslieferung und Wartungsphase.

Während dieser gesamten Zeit gilt es, Cybersicherheitsrisiken zu minimieren und Sicherheitsvorfälle bestmöglich zu verhindern.

In Bezug auf im Feld auftretende Schwachstellen ähneln sich ISO/SAE 21434 und CRA. Beide formulieren dies eher vage durch die Forderung eines Incident Response Managements, ohne jedoch konkrete Prozessvorgaben zu machen.

Wichtig ist, dass das im CRA sogenannte Enddatum des Unterstützungszeitraums (in dem Schwachstellen des Produkts im Einklang mit den grundlegenden Cybersicherheitsanforderungen behandelt werden) von Herstellern klar und verständlich auf Monat und Jahr spezifiziert angegeben wird, was in der ISO/SAE 21434 in Clause 14 in einer spezifischen Kundenkommunikation vorgesehen ist.

Clause 15: Die Threat-Analysis-and-Risk-Assessment-Methode und die CRA-Risikobewertung im Vergleich

Das Kernstück des ISO/SAE 21434-Standards ist die Methodik zur Identifikation und Bewertung von Cyberrisiken, die als Threat Analysis and Risk Assesssment (kurz TARA) bezeichnet wird. In der First Edition des Standards (2021) wurde diese Methode ans Ende gerückt und ist nun in Clause 15 zu finden.

In der Fachwelt der Fahrzeugentwicklung sind die in diesem methodisch-strukturierten Vorgehen geforderten Ausarbeitungen hinlänglich bekannt:

• Definition der Assets (z. B. Systeme, Komponenten, Daten, Schnittstellen)
• Identifikation potenzieller Bedrohungen für diese Assets
• Ermittlung relevanter Schwachstellen und Angriffsvektoren
• Ableitung möglicher Schadensszenarien und deren Auswirkungen
• Bewertung der Bedrohungsszenarien hinsichtlich Eintrittswahrscheinlichkeit und Schweregrad
• Bestimmung des Risikoniveaus für jedes Szenario
• Ableitung von Cybersecurity-Zielen und -Anforderungen zur Risikominderung

Ein direkter Vergleich der TARA-Methodik gemäß ISO/SAE 21434 mit den Anforderungen der Risikobewertung des CRA zeigt, dass der Standard den Fokus auf die methodischen Schritte legt, während der CRA die Minimalziele und -anforderungen an das Produkt konkretisiert. Die Wahl der formalen Methodik schreibt der CRA dabei nicht vor.

Präzisiert werden die Aspekte, die bei der Bewertung von Cybersicherheitsrisiken entlang der Lebensdauer und unter Berücksichtigung der grundlegenden Cybersicherheitsanforderungen (siehe Anhang 1) einzubeziehen sind:

• Zweckbestimmung,
• Vorhersehbare Verwendung,
• Betriebsumgebung,
• Assets

Dabei ist zu berücksichtigen, dass der CRA im Zweifel Begründungen dafür fordert, warum bestimmte Anforderungen aus Anhang I nicht anwendbar sind.

Sowohl die TARA als auch die CRA-Risikobewertung fordern eine Risikobetrachtung des gesamten Produktlebenszyklus bzw. des Unterstützungszeitraums. Entsprechend ist bei beiden eine Dokumentation (und gegebenenfalls eine Aktualisierung) erforderlich.

Im CRA wird dieser Punkt weiter spezifiziert (vgl. Artikel 13, Absatz 4): Die Bewertung der Cybersicherheitsrisiken muss in die technische Dokumentation aufgenommen werden.

Je nach Organisation, Produkt und Entwicklungsabläufen kann die Frage gestellt werden, inwieweit sich die TARA-Methodik heranziehen lässt, um die Vorgaben des CRA inhaltlich zu erfüllen.

Aufgrund ihrer Struktur erfüllt eine korrekt umgesetzte TARA nicht nur die Erfordernisse der Cyberrisikobetrachtung, wie sie der CRA formuliert, sondern liefert auch die erforderliche Nachvollziehbarkeit und Dokumentation. Somit ist sie ein geeignetes Verfahren, um den Anforderungen des CRA in Bezug auf die Risikobewertung zu entsprechen. Unternehmen müssen allerdings zusätzlich sicherstellen, dass die Integration in die geforderte technische Dokumentation entsprechend erfolgt.

Zusammengefasst: Der Blick auf den CRA aus Perspektive der ISO/SAE 21434

Die gute Nachricht: Organisationen und Entwicklungsprojekte, die sich an der ISO/SAE 21434 orientieren, können diesem Taktgeber für ordnungsgemäßes Cybersecurity Engineering entlang des Produktlebenszyklus, projektspezifisch und evidenzbasiert, treu bleiben.

Letztendlich schafft der Cyber Resilience Act hier eine Ergänzung für den rechtlich verbindlichen Marktzugang innerhalb der Europäischen Union. Oder um es kurz auszudrücken: Die ISO/SAE 21434 definiert, wie cybersicherheitskonform entwickelt wird, während der CRA festlegt, was beim Inverkehrbringen in der Europäischen Union nachweisbar sein muss.

Basierend auf den obigen Ausführungen lässt sich eine erste Übersicht mit Handlungsfeldern zusammenstellen, die im Detail angegangen werden müssen:

• Mapping der Work Products: Artefakte der ISO/SAE 21434 mit den konkreten Anforderungen des CRA gegenüberstellen (Vgl. Anhänge).
• Bisherige Ausarbeitungen für die geforderten Inhalte der technischen Dokumentation bereit machen (Vgl. Anhang VII).
• Prüfung der Notwendigkeiten, welche Verpflichtungen als Hersteller für den CRA-Nachweis (passende Konformitätsbewertung) erforderlich werden.
• Integration der Evidenz-Verpflichtungen und Timings in bestehende Entwicklungs- und Projektpläne.
• Vorgehensweisen im Prozess des Vulnerability-Managements (CVD) sowie im Incident-Response-Management (PSIRT) prüfen und neu ausrichten.
• Operative Verpflichtungen in Meldesystemen entlang der CRA-Vorgaben abstimmen.
• Und weitere Aspekte (wie Software-Bill-of-Materials-Prozesse, Lieferanten einbinden, Support-Perioden definieren u.a.)