Dieses Dokument befindet sich in aktiver Entwicklung und ist noch nicht finalisiert.
Skip to content

3.4 Risikobewertung

3.4.1 Methodik

Die Risikobewertung für Schwachstellen und Produkte erfolgt auf Basis etablierter Standards:

  • CVSS v3.1/v4.0 – Common Vulnerability Scoring System für einzelne CVEs
  • SSVC – Stakeholder-Specific Vulnerability Categorization für Priorisierung
  • CRA Annex I – Anforderungskatalog als Bewertungsrahmen

RECHTSGRUNDLAGE

Art. 13 Abs. 3 CRA: „Der Hersteller führt eine Cybersecurity-Risikobewertung des Produkts mit digitalen Elementen durch und berücksichtigt das Ergebnis dieser Bewertung bei der Planung, dem Entwurf, der Entwicklung, der Herstellung, der Lieferung und der Wartung des Produkts."

3.4.2 CVE-Risikobewertung (Einzelschwachstellen)

CVSS-basierte Erstbewertung

CVSS ScoreSchweregradCRA-Priorität
9.0 – 10.0CriticalP0/P1
7.0 – 8.9HighP2
4.0 – 6.9MediumP3
0.1 – 3.9LowP4

Kontextuelle Bewertung

Die CVSS-Bewertung wird durch eine kontextuelle Analyse ergänzt:

FaktorBewertungGewichtung
AusnutzbarkeitAktiv ausgenutzt / PoC verfügbar / TheoretischHoch
ErreichbarkeitNetzwerk / Lokal / PhysischHoch
DatenexpositionPersonenbezogene Daten / Geschäftsdaten / KeineMittel
VerbreitungAnzahl betroffener Produkte / KundenMittel
MitigierbarkeitFix verfügbar / Workaround / KeinerMittel

Entscheidungsmatrix

                    Ausnutzbarkeit
                    Aktiv    PoC    Theoretisch
Schweregrad  ┌─────────────────────────────────┐
Critical     │  P0       P1       P1            │
High         │  P1       P2       P2            │
Medium       │  P2       P3       P3            │
Low          │  P3       P4       P4            │
             └─────────────────────────────────┘

3.4.3 Produkt-Risikobewertung (CRA Art. 13 Abs. 3)

Für jedes CRA-relevante Produkt wird eine Cybersecurity-Risikobewertung durchgeführt. Verwenden Sie das Risikobewertung-Template.

Bewertungskategorien

1. Bedrohungsanalyse

  • Wer sind potenzielle Angreifer? (Skript-Kiddies, organisierte Kriminalität, staatliche Akteure)
  • Welche Angriffsvektoren existieren? (Netzwerk, physisch, Supply Chain)
  • Welche Assets sind gefährdet? (Daten, Funktionalität, Verfügbarkeit)

2. Auswirkungsanalyse

  • Vertraulichkeit: Welche Daten könnten offengelegt werden?
  • Integrität: Welche Daten/Funktionen könnten manipuliert werden?
  • Verfügbarkeit: Welche Ausfallzeiten sind akzeptabel?
  • Sicherheit: Können physische Schäden entstehen? (relevant für Firmware/IoT)

3. Wahrscheinlichkeitsbewertung

  • Angriffskomplexität
  • Erforderliche Privilegien
  • Nutzerinteraktion erforderlich
  • Angriffsvektor-Exposition

Risikomatrix

                    Wahrscheinlichkeit
                    Hoch     Mittel    Niedrig
Auswirkung  ┌──────────────────────────────────┐
Kritisch    │  KRITISCH  HOCH      MITTEL       │
Erheblich   │  HOCH      HOCH      MITTEL       │
Moderat     │  HOCH      MITTEL    NIEDRIG      │
Gering      │  MITTEL    NIEDRIG   NIEDRIG      │
            └──────────────────────────────────┘

3.4.4 Restrisiko unter dem CRA ist keine Frage der Risikobereitschaft

Im organisatorischen Risikomanagement werden Risiken an Akzeptanzkriterien gemessen, die sich aus den eigenen Zielen oder der Risikobereitschaft der Organisation ableiten. So funktioniert der CRA nicht.

MASSSTAB IST DAS PRODUKT, NICHT DIE ORGANISATION

Unter dem CRA wird das verbleibende Cybersicherheitsrisiko daran gemessen, ob das in Verkehr gebrachte Produkt ein angemessenes Cybersicherheitsniveau auf der Grundlage der Risiken gewährleistet — unter Berücksichtigung seiner Zweckbestimmung und der vernünftigerweise vorhersehbaren Verwendung.

Die interne Risikotoleranz, die Geschäftsstrategie oder bloße Kostenerwägungen des Herstellers sind unerheblich für die Frage, ob Risiken behandelt wurden.

Restrisiko ist ein inhärentes Ergebnis von Risikobewertung und -behandlung — Cybersicherheitsrisiken lassen sich praktisch nicht vollständig beseitigen. Das Bestehen eines Restrisikos bedeutet jedoch nicht, dass beliebige Risiken nach Ermessen des Herstellers akzeptiert werden dürften. Ein Produkt darf nur in Verkehr gebracht werden, wenn die Restrisiken nach Ergreifung geeigneter Maßnahmen durch die Umsetzung der grundlegenden Anforderungen des Anhangs I Teil I hinreichend behandelt wurden, und zwar im Licht:

  • der Zweckbestimmung,
  • der vernünftigerweise vorhersehbaren Verwendung und der Verwendungsbedingungen, gegebenenfalls einschließlich der Betriebsumgebung (etwa der vorgesehenen Nutzer) und der zu schützenden Werte, sowie
  • der Dauer, für die das Produkt voraussichtlich genutzt wird.

Wege, ein identifiziertes Risiko zu behandeln (Art. 13 Abs. 3)

MaßnahmeBeispiel
Angriffsfläche verringernUngenutzte Dienste und Schnittstellen entfernen
Technische Schutzmaßnahmen umsetzenAuthentifizierung, Verschlüsselung, Integritätsschutz
Funktionalität begrenzen oder anpassenEine riskante Fähigkeit standardmäßig deaktivieren
Zweckbestimmung präziser fassenDas Produkt auf vertrauenswürdige Umgebungen beschränken
Vernünftigerweise vorhersehbare Verwendung steuernRisikokommunikation, Nutzerhinweise, Gestaltung der Benutzeroberfläche, die zu sicheren Nutzungsmustern führt

RISIKO DARF NICHT AUF NUTZER ÜBERTRAGEN WERDEN

Der CRA sieht keine Übertragung von Cybersicherheitsrisiken oder Verantwortung auf Nutzer oder Dritte vor, um Mängel im Produktdesign auszugleichen oder unbehandelte Risiken zu rechtfertigen. Die Pflicht, ein sicheres Produkt in Verkehr zu bringen und die Konformität nachzuweisen, verbleibt beim Hersteller.

Informationen und Anleitungen für Nutzer können den sicheren Einsatz und Betrieb unterstützen — auch dort, wo der Hersteller die Zweckbestimmung auf vertrauenswürdige Umgebungen beschränkt hat — und über Restrisiken informieren. Sie ersetzen die Behandlung nicht.

Beispiel (zulässige Beschränkung der Zweckbestimmung): Ein Hersteller entwickelt einen Industriesensor, der aus funktionalen Gründen nicht gegen physische Angriffe auf den Sensor selbst geschützt werden kann. Zur Minderung des in der Risikobewertung identifizierten Risikos beschränkt der Hersteller die Zweckbestimmung auf vertrauenswürdige Umgebungen, in denen unbefugter physischer Zugriff verhindert wird, und stellt diese Beschränkungen in den Informationen und Anleitungen für die Nutzer klar dar.

Beispiel (zulässiges Vertrauen auf Plattformsicherheit): Der Hersteller einer professionellen Anwendung, die lokal gespeicherte sensible Daten verarbeitet, identifiziert das Risiko unbefugten Zugriffs auf Klartextdaten. Statt einen eigenen Verschlüsselungsmechanismus zu entwickeln, stützt er sich auf die vom Betriebssystem nativ bereitgestellten Verschlüsselungs- und Schlüsselverwaltungsfunktionen, deren kryptografische Dienste ausgereift und regelmäßig gepflegt sind.

Identifiziert die Risikobewertung Risiken, die durch geeignete Maßnahmen nicht angemessen behandelt werden können, kann die Einhaltung des CRA Änderungen an Design, Funktionalität oder Zweckbestimmung erfordern. Kosten- oder Wirtschaftlichkeitserwägungen allein sind kein hinreichender Grund, solche Risiken unbehandelt zu lassen, wenn das Produkt dadurch die grundlegenden Anforderungen nicht erfüllen würde.

Das Verhältnis zu Anhang I Teil I Nr. 1

Nr. 1 des Anhangs I Teil I verlangt, dass Produkte so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Cybersicherheitsniveau auf Grundlage der Risiken gewährleisten. Dies ist eine Auffangnorm, zu unterscheiden von der Rechtspflicht zur Durchführung einer Risikobewertung nach Art. 13 Abs. 2.

SachverhaltWirkung auf Nr. 1
Alle relevanten Risiken werden durch Umsetzung der übrigen anwendbaren grundlegenden Anforderungen des Teils I behandeltNr. 1 gilt als erfüllt. In den meisten Fällen führt die Einhaltung der übrigen Anforderungen zur Einhaltung von Nr. 1.
Die Risikobewertung identifiziert zusätzliche Risiken, die davon nicht vollständig behandelt werdenDer Hersteller muss weitere geeignete Maßnahmen am Produkt umsetzen, um Nr. 1 einzuhalten.

3.4.5 Risiken, die außerhalb des Produkts entstehen

Die Risikobewertung erfasst relevante Risiken, die das Produkt beeinträchtigen können, einschließlich solcher außerhalb des Produkts — externe Netze, Umgebungsfaktoren, externe Infrastruktur, andere Systeme oder Dienste, auf die sich das Produkt stützt.

WAS DER CRA VERLANGT UND WAS NICHT

Der CRA verlangt nicht, dass Hersteller die externe Umgebung kontrollieren oder steuern. Er verlangt, solche Risiken zu identifizieren und sie durch Konzeption und Entwicklung des Produkts selbst zu mindern — durch Umsetzung der einschlägigen grundlegenden Anforderungen und, soweit erforderlich, durch Informationen und Anleitungen zu Integrations- oder Einsatzrisiken.

Externes RisikoMinderung auf Produktebene
Unbefugte erlangen Zugriff auf Backend-Systeme außerhalb des Produkts und senden ihm schadhafte BefehleKryptografische Authentifizierung von Fernbefehlen; Integritätsprüfung von Konfigurationsänderungen; sicherheitsrelevante Protokolle oder Alarme bei anomalem Verhalten
Ein externer Dienst wird nicht verfügbar (Stromausfall, Infrastrukturstörung)Sicherstellen, dass der Ausfall das Produkt nicht in unsichere Zustände versetzt

Der CRA regelt, wie das Produkt reagiert. Er stellt keine Anforderungen daran, wie die Backend-Infrastruktur organisiert, besetzt oder betrieben wird, und behandelt sie nicht als Teil des Produkts → 1.15 Fernverarbeitung.

Für jedes Produkt mit Fernanteilen sind daher drei Risikokategorien abzudecken:

  1. Risiken der Fernverarbeitungslösungen, die Teil des Produkts sind;
  2. Risiken aus der Nutzung von Fernlösungen Dritter — wie Drittkomponenten behandelt;
  3. Risiken der Produktumgebung (z. B. zugrunde liegende Hardware).

3.4.6 Wiederverwendung über Produktfamilien hinweg

Hersteller bringen häufig ähnliche Produkte in Verkehr — unterschiedliche Varianten, Modelle oder Konfigurationen derselben Familie. Der CRA verlangt nicht, jede Variante für Zwecke der Risiko- und Konformitätsbewertung als vollständig eigenständiges Produkt zu behandeln.

WANN WIEDERVERWENDUNG ZULÄSSIG IST

Teilen die Produkte dieselbe Architektur, dasselbe sicherheitsrelevante Design und dieselbe Zweckbestimmung und sind sie denselben Cybersicherheitsrisiken ausgesetzt, darf sich der Hersteller stützen auf:

  1. eine einzige Cybersicherheits-Risikobewertung nach Art. 13 Abs. 2;
  2. einen einzigen Satz technischer Dokumentation; und
  3. ein einziges Konformitätsbewertungsverfahren.

Damit kann auch eine einzige EU-Konformitätserklärung für die Gruppe ausgestellt werden — sofern sie die erfassten Produktvarianten eindeutig benennt.

Entscheidend: sind die Unterschiede cybersicherheitsrelevant?

UnterschiedGesonderte Bewertung erforderlich?
Farbe, Formfaktor, Speichergröße, andere nicht sicherheitsrelevante MerkmaleNein
Unterschiedliche KommunikationsschnittstellenJa — in der Risikobewertung und, soweit erforderlich, in Konformitätsbewertung und technischer Dokumentation abbilden
Unterschiedliche Software-StacksJa
Unterschiedliche Update-MechanismenJa
Unterschiedliche FernkonnektivitätJa

WIEDERVERWENDUNG IST BEDINGT UND MUSS GEPFLEGT WERDEN

Hersteller bleiben dafür verantwortlich, dass Risikobewertung und zugehörige Dokumentation die tatsächlich in Verkehr gebrachten Produkte zutreffend abbilden. Führt eine neue Variante neue Cybersicherheitsrisiken ein oder ändert sie die Umsetzung der grundlegenden Anforderungen, müssen bestehende Risikobewertung und Konformitätsunterlagen aktualisiert werden. Eine einzige Konformitätsbewertung ist nur insoweit möglich, wie die Produkte keine Unterschiede in ihren Cybersicherheitseigenschaften aufweisen.

GILT AUCH FÜR ALTE PRODUKTFAMILIEN

Bei Produkten, die vor Geltung des CRA entworfen wurden, darf sich der Hersteller — wenn mehrere Varianten dieselbe Konstruktion und dasselbe Cybersicherheits-Risikoprofil teilen — auf repräsentative Nachweise für die Produktfamilie stützen, statt jede Variante zu prüfen → 1.1 Geltungsbereich.

3.4.7 Dokumentationspflicht

Jede Risikobewertung muss dokumentieren:

  • Datum der Bewertung
  • Bewertetes Produkt / bewertete Version — und, bei einer Familienbewertung, die genaue Liste der erfassten Varianten
  • Identifizierte Risiken mit Bewertung, einschließlich außerhalb des Produkts entstehender Risiken
  • Getroffene Maßnahmen zur Risikominderung auf Produktebene
  • Verbleibende Restrisiken mit Begründung gegenüber den grundlegenden Anforderungen — nicht gegenüber der internen Risikobereitschaft
  • Jede grundlegende Anforderung, die nicht vollständig erfüllt werden kann, den ursächlichen Zwang und die umgesetzten kompensierenden Maßnahmen
  • Verantwortlicher Bewerter
  • Nächster Überprüfungstermin

Die Risikobewertung ist Teil der technischen Dokumentation (Annex VII) und ist zutreffend, vollständig und fortlaufend aktuell zu halten (Art. 13 Abs. 7, Art. 31 Abs. 2) — bei wesentlichen Änderungen am Produkt, bei neuen Varianten und bei neuen Bedrohungslagen.

Quelle und Rechtsstatus der Auslegungen in den Abschnitten 3.4.4 bis 3.4.6: Leitlinien der EU-Kommission zum CRA.

Dokumentation lizenziert unter CC BY-NC 4.0 · Code lizenziert unter MIT