CRA-Risikobewertung & Bedrohungsmodellierung

Warum die Risikobewertung das Herzstück der CRA-Konformität ist

Die Verordnung (EU) 2024/2847 (Cyber Resilience Act, kurz CRA) verlangt für Produkte mit digitalen Elementen eine Cybersicherheits-Risikobewertung nach Art. 13 in Verbindung mit Anhang I. Diese Bewertung steht im Zentrum der technischen Dokumentation: Aus ihr leitet sich schematisch ab, welche der grundlegenden Cybersicherheitsanforderungen aus Anhang I auf ein konkretes Produkt anwendbar sind und wie sie umgesetzt werden. Die Risikobewertung ist Bestandteil der technischen Dokumentation nach Anhang VII (nicht Anhang II - dort geht es um die Informationen für die Nutzer) und mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum aufzubewahren.

In der Praxis wird diese Pflicht leicht unterschätzt. Wer erst kurz vor dem Inverkehrbringen anfängt, kann die geforderte Nachvollziehbarkeit „von der Bedrohung bis zur Maßnahme" kaum noch rückwirkend belegen. Threat-Modeling (Bedrohungsmodellierung) ist eine etablierte Methode, um genau diese Kette strukturiert, wiederholbar und nachvollziehbar zu erzeugen - und sie idealerweise schon in der Entwurfsphase (Security-by-Design) zu verankern.

Threat-Modeling als Methode: DFD, STRIDE, Attack-Trees

Der CRA schreibt keine bestimmte Methode vor. Drei etablierte Bausteine lassen sich gut kombinieren und auf die Anhang-I-Anforderungen abbilden.

Data-Flow-Diagramme (DFD): die Landkarte

Zuerst wird das System modelliert - Prozesse, Datenspeicher, externe Entitäten und vor allem die Vertrauensgrenzen (trust boundaries). Ein DFD zeigt, wo Daten über eine solche Grenze fließen (etwa vom Internet in die Firmware, von der App in den Cloud-Backend-Dienst). Diese Grenzübergänge sind die Stellen, an denen Bedrohungen entstehen. Das DFD ist damit die Landkarte, auf der alles Weitere verortet wird.

STRIDE: keine Kategorie auslassen

Pro Element und Datenfluss werden sechs Bedrohungskategorien systematisch geprüft:

• Spoofing (Identitätsfälschung) → Authentifizierung, Schutz vor unbefugtem Zugriff
• Tampering (Manipulation) → Integrität
• Repudiation (Abstreitbarkeit) → Protokollierung/Nachweisbarkeit
• Information Disclosure (Informationsoffenlegung) → Vertraulichkeit
• Denial of Service → Verfügbarkeit
• Elevation of Privilege (Rechteausweitung) → Zugriffskontrolle

STRIDE hilft, keine Kategorie auszulassen, und lässt sich auf die Schutzziele aus Anhang I Teil I Nr. 2 abbilden (Schutz vor unbefugtem Zugriff, Integrität, Vertraulichkeit, Verfügbarkeit, geringe Angriffsfläche). Deshalb eignet sich die Methode für den CRA-Nachweis: Sie liefert die Begründung, warum eine Anforderung anwendbar ist - oder mit sachlicher Rechtfertigung eben nicht.

Attack-Trees: priorisieren und Restrisiko begründen

Für die relevantesten Bedrohungen werden die Angriffspfade als Baum zerlegt: Angriffsziel → Teilziele → konkrete Techniken. Das macht sichtbar, welche Gegenmaßnahme einen ganzen Ast abschneidet, priorisiert den Aufwand und liefert die dokumentierte Begründung für bewusste Restrisiko-Entscheidungen.

Durchgespieltes Beispiel: ein vernetztes IoT-Gateway

Das Vorgehen lässt sich an einem fiktiven, aber typischen Produkt nachvollziehen - einem WLAN-fähigen Gateway mit Cloud-Anbindung und Mobil-App.

1. Scoping: Produktgrenze festlegen (Firmware, Web-Konfigurationsoberfläche, Cloud-API, App), einschließlich Update-Mechanismus und Support-Zeitraum. Der Unterstützungszeitraum richtet sich nach der voraussichtlichen Nutzungsdauer: mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer (Art. 13 Abs. 8).
2. Assets & Trust-Boundaries: Schützenswert sind u. a. Gerätekonfiguration, Nutzerdaten, Signierschlüssel für Firmware-Updates. Vertrauensgrenzen liegen zwischen Internet/Gerät, App/Cloud und Prozess/Datenspeicher.
3. Angreifermodell: unauthentifizierter Netzangreifer im selben LAN, kompromittierte App, sowie ein Angreifer mit physischem Gerätezugang.
4. STRIDE-Durchgang (Auszug): Am Datenfluss „App → Cloud-API" fällt Spoofing auf → Gegenmaßnahme: gegenseitige Authentifizierung/Token. Am Firmware-Update fällt Tampering auf → signierte, verifizierte Updates. An der Konfig-Oberfläche fällt Elevation of Privilege auf → Rollentrennung, kein Default-Passwort.
5. Risiko & Gegenmaßnahmen: Je Bedrohung Eintrittswahrscheinlichkeit × Schaden bewerten, Maßnahme wählen, Restrisiko begründen.
6. Nachweis/Doku: Die Kette Bedrohung → Risiko → gewählte Anhang-I-Maßnahme → Verifikation wird versioniert festgehalten und in die technische Dokumentation (Anhang VII) übernommen - inklusive Software-Stückliste (SBOM).

Die SBOM gehört in die technische Dokumentation, in einem gängigen maschinenlesbaren Format und zumindest mit den obersten Abhängigkeiten (Anhang I Teil II Nr. 1). Die BSI TR-03183-2 (v2.1.0) nennt dafür CycloneDX ab 1.6 oder SPDX ab 3.0.1. Eine allgemeine Veröffentlichungspflicht besteht nicht; der Marktüberwachungsbehörde ist sie auf begründetes Verlangen vorzulegen (Anhang VII Nr. 8).

Von der Bewertung zur nachvollziehbaren Kette

Das Ergebnis eines guten Threat-Modelings ist eine nachvollziehbare Kette, an der eine notifizierte Stelle oder eine Marktüberwachungsbehörde die Bewertung prüfen kann: identifizierte Bedrohung → bewertetes Risiko → gewählte Anhang-I-Maßnahme → Verifikation. Ob eine notifizierte Stelle überhaupt einzubinden ist, hängt schematisch von der Produktklasse ab: Ohne Eintrag in Anhang III oder IV genügt die interne Kontrolle (Modul A). Bei „wichtigen“ Produkten der Klasse I ebenfalls, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema mindestens der Stufe „mittel“ vollständig angewandt werden, sonst Modul B+C oder H. Für Klasse II und für „kritische“ Produkte nach Anhang IV ist Modul A ausgeschlossen (Art. 32). Für KI-Produkte erweitert sich der Bedrohungskatalog zusätzlich um Prompt-Injection, Modell-Extraktion und Data-Poisoning - dieselbe Methodik lässt sich hier anwenden.

Fristen: warum jetzt der richtige Zeitpunkt ist

Der CRA ist am 10.12.2024 in Kraft getreten. Die erste harte Herstellerpflicht, die Melde- und Berichtspflichten nach Art. 14, gilt seit dem 11.09.2026. Die volle Anwendbarkeit aller Produktanforderungen folgt am 11.12.2027. Die Meldung ist gestaffelt: Frühwarnung unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnis; Meldung mit den verfügbaren allgemeinen Informationen unverzüglich, in jedem Fall innerhalb von 72 Stunden; Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist (aktiv ausgenutzte Schwachstelle), bzw. innerhalb eines Monats nach der Meldung (schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Sicherheit des Produkts). Gemeldet wird gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA, über die einheitliche Meldeplattform nach Art. 16.

Verstöße gegen Anhang I sowie Art. 13/14 können mit bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden (jeweils der höhere Betrag); für weitere Pflichten gelten 10 Mio. / 2 %, für falsche Angaben gegenüber Behörden 5 Mio. / 1 %. Art. 64 gehört nicht zu den vorgezogenen Vorschriften und gilt ab dem 11.12.2027 (Art. 71 Abs. 2); das deutsche Durchführungsgesetz (Bundestag-Drucksache 21/6134), das Behörde und Bußgeldverfahren regeln soll, ist zum 9. Oktober 2026 weder beschlossen noch verkündet. Eine belastbare Risikobewertung ist damit auch wirtschaftlich von Bedeutung.

Was Blackfort tut

Blackfort Technology bringt die Perspektive des Angreifers in die Risikobewertung ein. Blackfort Technology ist über ihren Geschäftsführer im Expertenkreis KI-Sicherheit der Allianz für Cyber-Sicherheit vertreten; er ist Mitautor des dort erschienenen Leitfadens für Penetrationstests von Large Language Models. Wir erstellen mit Ihren Entwicklern aus Quellcode, Konfiguration und Dokumentation ein Bedrohungsmodell Ihrer Produkte mit Datenflüssen und Vertrauensgrenzen, bewerten die Bedrohungen nach STRIDE und übertragen das Ergebnis in die technische Dokumentation nach Anhang VII.

Ob und wie der CRA auf ein konkretes Produkt anwendbar ist, ist eine Einzelfallfrage - dieser Beitrag ist schematisch und ersetzt keine Rechtsberatung. Ein guter erster Schritt ist unser Betroffenheits-Check. Vertiefend: Cyber Resilience Act im Überblick, Einordnung für kleinere Hersteller unter CRA für KMU und branchenspezifische Aspekte unter Branchen. Für ein konkretes Gespräch: Kontakt aufnehmen.