Cyber-Regulierung: CRA in der Entwicklung

Der CRA unterscheidet vier Stufen:

• Standard/ Basis Produkte (Art. 6)
  • z.B. Haushaltsgeräte, Messgeräte, IoT (Internet of Things) Geräte, Mobile- oder PC-Applikationen
• Wichtige Produkte (Klasse I) (Art. 7, Anhang III)
  • z.B. Virtuelle Assistenten, intelligente Türschlösser, Babyphones, Wearables mit dem Zweck der Gesundheitsüberwachung
• Wichtige Produkte (Klasse II) (Art. 7, Anhang III)
  • z.B. Firewall-Appliance
• Kritische Produkte (Art. 8, Anhang IV)
  • z.B. HSM-Appliance (Hardware Security Module)

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:

• gewährleisten, dass Konzeption, Entwicklung, Herstellung und Behandlung von Schwachstellen der CRA entsprechen
• erstellen der technische Dokumentation gemäss Anhang VII
• anbringen der Konformitätskennzeichnung (CE-Kennzeichnung) und erstellen der EU-Konformitätserklärung

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.

Standard/ Basis Produkte

• siehe oben

Alle höheren Sicherheitsstufen benötigen den Einbezug einer notifizierten Stelle.

Wichtige Produkte (Klasse I) (Art. 32 Abs. 2)

• EU-Baumusterprüfung (Modul B) gemäss Anhang VIII Teil II und Konformität mit dem Baumuster (Modul C) gemäss Anhang VIII Teil III.
  • Dies entspricht dem Standardverfahren zur Erlangung der CE-Kennzeichnung.

oder

• Konformität auf der Grundlage einer umfassenden Qualitätssicherung (Modul H) gemäss Anhang VIII Teil IV
  • Das Qualitätssicherungssystem muss von einer notifizierten Stelle zugelassen und regelmässig überprüft werden.
  • Dieses Verfahren ermöglicht es dem Hersteller, die Konformität auf der Grundlage des zugelassenen Qualitätssicherungssystems im Namen der benannten Stelle zu bescheinigen.

Wichtige Produkte (Klasse II) (Art. 32 Abs. 3)

• Gemäss Modul B und Modul C und Modul H (siehe Klasse I)

Kritische Produkte (Art. 32 Abs. 4)

• Benötigt ein europäisches Cybersicherheitszertifikat, mindestens der Vertrauenswürdigkeitsstufe «mittel» gemäss der Verordnung EU 2019/881

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:

• Security by Design und bewährte Praktiken für einen sicheren (Software-)Entwicklungszyklus
• Security by Default (z.B. sichere Standardkonfiguration)
• Minimierung potenzieller Angriffsflächen
• Schutz vor unbefugtem Zugriff
• Vertraulichkeit, Integrität und Verfügbarkeit (z.B. Secure Boot)
• Schutz personenbezogener Daten
• Protokollierung sicherheitsrelevanter Daten und Ereignisse

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 (System Package Data Exchange).

Die Technische Richtlinie TR-03183-2 des BSI beschreibt die Anforderungen an eine SBOM im Detail.

Der CRA fordert von Herstellern, dass Sie die Cybersicherheitsrisiken ihrer Produkte bewerten (Art. 12 Abs. 2). Die BSI technischen Richtlinien TR‑03183-1 («Cyber Resilience Requirements for Manufacturers and Products») geben dazu einen Ansatz, welcher sich folgendermassen zusammenfassen lässt:

1. Risikoidentifikation mit strukturierter Gefährdungsmodellierung: 
   1. Identifikation der Werte («assets»: Komponenten, Daten, Funktionen etc.), welche geschützt werden müssen und deren Gruppierung in sinnvolle Kategorien
   2. Erfassung der potentiellen Bedrohungen für diese Werte und deren Zuordnung zu den Gefährdungen
2. Risikoanalyse: Abschätzung der potentiellen Auswirkungen und der Häufigkeit für jedes identifizierte Risiko
3. Risikoevaluation: Vergleich der Auswirkungen mit vordefinierten Akzeptanzkriterien und Identifikation der zu behandelnden Risiken; alle Risiken mit einem whrnehmbar negativen Effekt auf den Nutzer müssen behandelt werden

Diese Analyse muss dokumentiert und gepflegt werden.

Die Erkennung von Schwachstellen wird unter anderem durch folgende Massnahmen sichergestellt:

• Regelmässig und wirksam testen und prüfen (Abs. 3)
  • Unit-, Penetration-Tests etc.
• Analyse in Bezug auf die Cybersecurity
  • Aktualisierung und Pflege der Risikoanalyse
• Analyse von bekannten Schwachstelle und deren Einfluss auf das eigene Produkt (z.B. OWASP)
• Analyse von Schwachstellen von Komponenten, welche im Produkt eingesetzt werden (dazu muss eine SBOM erstellt werden und die dazugehörigen bekannten Schwachstellen müssen analysiert werden)

Die Dokumentation ist in zwei Teile gegliedert:

• Technische Dokumentation
• Benutzerdokumentation

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):

• allgemeine Beschreibung des Produkts
• Beschreibung der Konzeption, Entwicklung und Herstellung des Produkts
• Beschreibung des Verfahrens zur Behandlung von Schwachstellen
• Bewertung der Cybersicherheitsrisiken
• Informationen, die bei der Festlegung des Unterstützungszeitraums gemäss Art. 13 Abs. 8 berücksichtigt wurden
• Eine Liste der ganz oder teilweise angewandten harmonisierten Normen oder eine Beschreibung der Lösungen, mit denen die in Anhang I genannten grundlegenden Anforderungen an die Cybersicherheit erfüllt werden
• Berichte über die durchgeführten Tests und Prüfungen
• EU-Konformitätserklärung
• Software-Stückliste

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.

Ja, für alle Produkte mit digitalen Elementen sind gemäß CRA Prozesse erforderlich. Ein Verzicht auf definierte Prozesse macht die CRA-Compliance zu einer gewaltigen Herausforderung. Die Prozesse stellen sicher, dass Cybersicherheitsrisiken systematisch identifiziert, bewertet, behoben und über den gesamten Produktlebenszyklus hinweg verfolgt werden, und sie liefern den dokumentierten Nachweis, dass Sie die gesetzlichen Anforderungen erfüllen (CRA, Art. 13(2–3)).

Der CRA ist keine reine Checkliste für Software-Features, sondern reguliert den gesamten Lebenszyklus eines Produkts. Während technische Sicherheitsfunktionen wichtig sind, konzentriert sich die EU-Verordnung stark darauf, wie Sie als Unternehmen Sicherheit langfristig verwalten, d.h. welche Arbeitsweisen («Prozesse») Sie etabliert haben. 

Selbst wenn eine Risikobewertung nur akzeptable Risiken ergibt, sind Prozesse wie Incident Management, Vulnerability Handling und sichere Updates erforderlich, da nach der Veröffentlichung des Produkts neue Schwachstellen und unerwartete Bedrohungen auftreten können (CRA, Art. 13(6–8); Art. 14).

Hier sind die wichtigsten Prozessbereiche, die Sie aufbauen oder anpassen müssen: 

• Risikobewertung und Design-Phase 
• Software Bill of Materials (SBOM) 
• Schwachstellenmanagement (Vulnerability Management) 
• Konformitätsbewertungsverfahren 
• Support- und Lebenszyklus-Prozesse 

Mehr Details zu den Prozessen für die CRA

Risikobewertung und Design-Phase 

Bevor ein Produkt auf den Markt kommt, verlangt der CRA von Ihnen: 

• Security by Design: Dokumentierte Prozesse, die belegen, dass Sicherheit von Beginn an Teil der Entwicklung war (« Sichere Entwicklung»). Von Anfang an Sicherheit einbauen, einschließlich Bedrohungsmodellierung und Tests (CRA, Art. 13(1–2)).
• Risikoanalyse: Eine systematische Bewertung der Cyber-Risiken, denen Ihr Produkt ausgesetzt ist. Identifizieren Sie zu schützende Assets, analysieren und bewerten Sie Risiken und entscheiden Sie, welche davon Aufmerksamkeit erfordern (CRA, Art. 13(3)).

Schwachstellenmanagement (Vulnerability Management) 

Dies ist einer der wichtigsten Punkte des CRA. Finden, dokumentieren, priorisieren und beheben Sie Schwachstellen. Halten Sie eine aktuelle SBOM bereit und unterstützen Sie eine koordinierte Offenlegung (CRA, Art. 13(6–8)). 

• Monitoring: Kontinuierliche Überprüfung Ihrer Software auf Sicherheitslücken. Das schliesst auch und genutzter Drittkomponenten ein. 
• Meldewesen: Sie sind verpflichtet, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die zuständigen Behörden zu melden. Ausgenutzte Schwachstellen oder Cybersicherheitsvorfälle erkennen, melden und behandeln (CRA, Art. 14).
• Patch-Management: Strukturierte Abläufe, damit der Kunde schnell informiert wird und für das Problem schnell ein Fix zur Verfügung steht. 

Software Bill of Materials (SBOM) 

Sie müssen in der Lage sein, für jedes Produkt eine SBOM zu erstellen und aktuell zu halten.  

• Alle verwendeten Bibliotheken und Abhängigkeiten müssen lückenlos erfasst sein. 
• Diese Liste muss bei jedem Update aktualisiert werden. 

Konformitätsbewertungsverfahren 

Je nach Risikoklasse Ihres Produkts müssen Sie nachweisen, dass Sie die Anforderungen erfüllen: 

• Interne Kontrolle: Bei Standard-Produkten genügt oft eine interne Dokumentation Ihrer Prozesse. 
• Externe Prüfung: Bei kritischen Produkten müssen Sie Prozesse für die Zusammenarbeit mit der «nezeichneten Stelle»  (Notified Body) etablieren. 

Support- und Lebenszyklus-Prozesse 

Der CRA schreibt vor, dass Sie über einen festgelegten Zeitraum Sicherheits-Updates bereitstellen müssen. Dieser Zeitraum muss mindestens 5 Jahre betragen, kann aber länger sein wenn das Produkte eine längere erwartete Lebensdauer hat. Überwachen und aktualisieren Sie das Produkt und seine Komponenten während seiner gesamten erwarteten Lebensdauer (CRA, Art. 13(8–9)).

• Sie benötigen Prozesse, die sicherstellen, dass die Update-Infrastruktur über Jahre hinweg stabil bleibt. 
• End-of-Life: Ein geregelter Prozess zur Kommunikation an Kunden, wenn der Support endet.