Lesezeit 6 min
Das Inkrafttreten des Cyber Resilience Act (CRA, deutsch: Cyberresilienz-Verordnung (CRV)) bedeutet, das fast kein elektronisches Produkt mehr ohne Berücksichtigung der Cybersicherheit, ohne einen Damm zum Internet entwickelt werden kann.
Was heisst das für Sie als Entwicklungsleiter, als Projektleiter, als Entwickler? Hier haben wir hier Informationen zu verschiedenen Entwicklungs-Aspekten der CRA zusammengetragen. Melden Sie sich gerne bei mir, wenn Sie zusätzliche Fragen haben!
Für allgemeine Informationen zur CRA, sehen Sie CRA Allgemein.
Der CRA unterscheidet vier Stufen:
Alle Sicherheitsstufen müssen Anhang I entsprechen, d.h. alle Tätigkeiten müssen immer durchgeführt werden.
Der Unterschied zwischen den Sicherheitsstufen liegt in der Konzeption des Produkts, das ein der Sicherheitsstufe angemessenes Cybersicherheitsniveau gewährleisten muss (Anhang I Teil I Abs. 1), und im Konformitätsbewertungsverfahren (Anhang VIII).
Derzeit gibt es noch keine harmonisierten Normen für die Verordnung. Harmonisierte Normen sind technische Standards, die von der EU-Kommission anerkannt sind und eine rechtlich vereinfachte Konformitätsbewertung ermöglichen.
Bis zur Veröffentlichung solcher harmonisierten Normen können Hersteller auf etablierte Normen wie die Normenreihe IEC 62443 zurückgreifen.
Dies ist für Produkte der Sicherheitsstufe «Standard/ Basis» möglich (Art. 32 Abs. 1, Ewgr. 91). Das dazugehörige Verfahren (Modul A) ist im Anhang VIII Teil I beschrieben und verlangt:
Der Hersteller muss gewährleisten und auf eigene Verantwortung erklären, dass der CRA entspricht. Siehe auch «Brauche ich dafür Prozesse? Wieso? Welche?» und «Welche Strafen drohen bei Nichteinhaltung des CRA?».
Der Nachweis der Konformität hängt von der Sicherheitsstufe des Produkts ab.
Alle höheren Sicherheitsstufen benötigen den Einbezug einer notifizierten Stelle.
oder
Das zentrale Element der CRA ist die Bewertung der Cybersicherheitsrisiken. Dieses Dokument wird zu Beginn der Produktentwicklung erstellt und anschliessend regelmässig aktualisiert (Art. 13 Abs. 2, 3).
Die Produktentwicklung (Planungs-, Konzeptions-, Entwicklungsphase) muss die Ergebnisse der Risikoanalyse berücksichtigen, um die Cybersicherheitsrisiken zu minimieren, Sicherheitsvorfälle zu verhindern und die Auswirkungen von Sicherheitsvorfälle zu minimieren.
Das Produkt muss so konzipiert, entwickelt und hergestellt werden, dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleistet wird.
Die Cybersicherheitsanforderungen (Anhang I Teil I) müssen erfüllt werden. Gefordert werden unter anderem:
Die Technische Richtlinie TR-03183-1 des BSI beschreibt den Stand der Technik im Detail.
Eine Software-Stückliste (Software Bill of Materials (SBOM)) ist zwingend und muss in einer maschinenlesbaren Form vorliegen (Anhang I Teil II Abs. 1). Mögliche Formate sind CycloneDX oder SPDX.
Die Technische Richtlinie TR-03183-2 des BSI beschreibt die Anforderungen an eine SBOM im Detail.
Die Dokumentation ist in zwei Teile gegliedert:
Die technische Dokumentation muss alle relevanten Daten oder Einzelheiten darüber enthalten, wie der Hersteller sicherstellt, dass das Produkt dem CRA entspricht (Art. 31 Abs. 1).
Die technische Dokumentation muss vollständig und in leicht verständlicher Sprache geschrieben sein und den Marktüberwachungsbehörden auf Antrag zur Verfügung gestellt werden (Artikel 53, 58). Sie muss es den Marktüberwachungsbehörden ermöglichen, die Konzeption, die Entwicklung, die Herstellung und den Umgang mit Schwachstellen zu verstehen (Artikel 31 Abs. 2).
Die technische Dokumentation beinhaltet mindesten (Anhang VII):
Die Dokumentation ist vor dem Inverkehrbringen zu erstellen und während der gesamten Lebensdauer des Produkts zu aktualisieren (Art. 31 Abs. 2).
Das Kapitel 6 der Technische Richtlinie TR-03183-1 des BSI geht detailliert auf die Dokumentationspflichten ein.
Alois Cavelti
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!

ist Dipl. Elektroingenieur FH , Mitgründer, stellvertretender Geschäftsführer und Software-Entwickler. Er ist Spezialist für Architekturen und Software in C, C++ und C#. Er setzt sich für wartbare Architektur, Security und sauberen Code ein. Dafür schaut er gerne über den «embedded» Tellerand in andere Bereiche der Softwareentwicklung. Gesamtsysteme jeglicher Art und deren Zusammenhänge interessieren ihn. Alois bewirtschaftet eine 5'000 m2 Biodiversitätsinsel und bringt dabei Natur, Pferd und Mensch in Einklang. Er liebt gute (Film)Geschichten und gutes Essen.
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare