Was ist der Cyber Resilience Act? Ein Überblick für Sie.

Warum gibt es den CRA?

Viele Produkte mit digitalen Elementen weisen Schwachstellen auf, während Sicherheitsupdates nicht immer rechtzeitig und zuverlässig bereitgestellt werden. Zugleich fehlte bislang ein horizontaler EU-Rechtsrahmen mit einheitlichen Cybersicherheitsanforderungen für vernetzte Hard- und Software. Der CRA schafft deshalb gemeinsame Vorgaben für die Entwicklung, Bereitstellung und Schwachstellenbehandlung über den Produktlebenszyklus hinweg. Warum der CRA entstanden ist und welche Produkte er erfasst ↗

Log4Shell zeigte Ende 2021, wie sich eine Schwachstelle in einer weitverbreiteten Softwarebibliothek auf zahlreiche Produkte und Organisationen auswirken kann. Für viele Unternehmen war zunächst kaum feststellbar, in welchen eigenen oder zugekauften Systemen die betroffene Komponente enthalten war. SBOM für Softwarehersteller: Anforderungen und Umsetzung ↗

Der XZ-Utils-Fall im März 2024 war der Versuch, eine Hintertür in eine verbreitete Open-Source-Komponente einzuschleusen. Die Manipulation wurde entdeckt, bevor die betroffenen Versionen eine breite stabile Verteilung erreichten. Der Fall verdeutlicht dennoch, welche Risiken aus komplexen Softwarelieferketten und übernommenen Komponenten entstehen können. Bundle & Open Source: Komponenten und Verantwortung ↗

Was verlangt der CRA konkret?

Zentrale Anforderungen mit Quellenzuordnung zu Anhang und Artikeln der Verordnung (EU) 2024/2847.

Sicherheitsanforderungen an das Produkt

• Bewertung der Cybersicherheitsrisiken – Art. 13 Abs. 2–4 CRA
• Angemessenes Cybersicherheitsniveau entsprechend den Risiken – Anhang I Teil I Nr. 1
• Keine bekannten ausnutzbaren Schwachstellen bei der Marktbereitstellung – Anhang I Teil I Nr. 2 Buchst. a
• Sichere Standardeinstellungen und Möglichkeit zur Wiederherstellung des Ausgangszustands – Anhang I Teil I Nr. 2 Buchst. b
• Behebung von Schwachstellen durch Sicherheitsupdates; gegebenenfalls automatische Installation als Standardeinstellung mit Opt-out – Anhang I Teil I Nr. 2 Buchst. c
• Schutz vor unbefugtem Zugriff durch geeignete Kontrollmechanismen – Anhang I Teil I Nr. 2 Buchst. d
• Schutz der Vertraulichkeit gespeicherter, übertragener oder anderweitig verarbeiteter Daten, zum Beispiel durch Verschlüsselung relevanter Daten – Anhang I Teil I Nr. 2 Buchst. e
• Schutz der Integrität von Daten, Befehlen, Programmen und Konfigurationen – Anhang I Teil I Nr. 2 Buchst. f
• Verarbeitung nur solcher Daten, die für den vorgesehenen Zweck erforderlich sind – Anhang I Teil I Nr. 2 Buchst. g
• Schutz der Verfügbarkeit wesentlicher Funktionen, einschliesslich Widerstandsfähigkeit gegen und Begrenzung von Denial-of-Service-Angriffen – Anhang I Teil I Nr. 2 Buchst. h
• Minimierung negativer Auswirkungen auf die Verfügbarkeit anderer Geräte, Netze und Dienste – Anhang I Teil I Nr. 2 Buchst. i
• Verringerung der Angriffsfläche, einschliesslich externer Schnittstellen – Anhang I Teil I Nr. 2 Buchst. j
• Begrenzung der Auswirkungen von Sicherheitsvorfällen – Anhang I Teil I Nr. 2 Buchst. k
• Aufzeichnung und Überwachung sicherheitsrelevanter Vorgänge mit Opt-out-Möglichkeit für Nutzer – Anhang I Teil I Nr. 2 Buchst. l
• Sichere und dauerhafte Löschung sowie sichere Übertragung von Daten und Einstellungen – Anhang I Teil I Nr. 2 Buchst. m

Schwachstellenbehandlung und Sicherheitsupdates

• Dokumentation der Komponenten und Schwachstellen, unter anderem durch eine SBOM in einem gängigen maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten erfasst – Anhang I Teil II Nr. 1
• Unverzügliche Behandlung und Behebung von Schwachstellen; Sicherheitsupdates sollen, soweit technisch machbar, getrennt von Funktionsupdates bereitgestellt werden – Anhang I Teil II Nr. 2
• Regelmässige und wirksame Sicherheitstests und Sicherheitsüberprüfungen – Anhang I Teil II Nr. 3
• Veröffentlichung oder Weitergabe von Informationen über behobene Schwachstellen, sobald ein Sicherheitsupdate verfügbar ist; ein Aufschub ist nur in begründeten Fällen zulässig – Anhang I Teil II Nr. 4
• Einrichtung und Umsetzung einer Strategie für die koordinierte Offenlegung von Schwachstellen – Anhang I Teil II Nr. 5
• Erleichterung des Informationsaustauschs über mögliche Schwachstellen, einschliesslich einer Kontaktadresse für Meldungen – Anhang I Teil II Nr. 6
• Sichere Verteilung von Updates zur unverzüglichen Behebung oder Minderung von Schwachstellen – Anhang I Teil II Nr. 7
• Unverzügliche und grundsätzlich kostenlose Bereitstellung von Sicherheitsupdates; bei massgeschneiderten Produkten für gewerbliche Nutzer kann etwas anderes vereinbart werden – Anhang I Teil II Nr. 8

Dokumentation und Konformität

• Technische Dokumentation einschliesslich der Bewertung der Cybersicherheitsrisiken – Art. 31 und Anhang VII, insbesondere Anhang VII Nr. 3
• Durchführung des anwendbaren Konformitätsbewertungsverfahrens – Art. 32 und Anhang VIII
• EU-Konformitätserklärung – Art. 28 und Anhang V
• CE-Kennzeichnung – Art. 30
• Bereitstellung der vorgeschriebenen Informationen und Nutzeranweisungen – Art. 13 Abs. 18 und Anhang II

Meldepflichten nach Art. 14 CRA

• Aktiv ausgenutzte Schwachstelle: Frühwarnung innerhalb von 24 Stunden nach Kenntnis; Schwachstellenmeldung innerhalb von 72 Stunden; Abschlussbericht spätestens 14 Tage, nachdem eine Abhilfe- oder Risikominderungsmassnahme verfügbar ist.
• Schwerwiegender Sicherheitsvorfall mit Auswirkungen auf die Sicherheit des Produkts: Frühwarnung innerhalb von 24 Stunden; Vorfallmeldung innerhalb von 72 Stunden; Abschlussbericht grundsätzlich innerhalb eines Monats nach der 72-Stunden-Meldung.

• Die Meldungen erfolgen über die einheitliche Meldeplattform an das benannte koordinierende CSIRT und sind gleichzeitig für ENISA zugänglich – Art. 14 Abs. 1, 3 und 7.
• Betroffene Nutzer sind über die Schwachstelle oder den Sicherheitsvorfall sowie über erforderliche Abhilfe- oder Risikominderungsmassnahmen zu informieren – Art. 14 Abs. 8.
• Informationen über behobene Schwachstellen sind nach Verfügbarkeit eines Sicherheitsupdates zu veröffentlichen oder weiterzugeben – Anhang I Teil II Nr. 4.