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 ist kein Formular, das man am Ende abhakt, sondern der Dreh- und Angelpunkt der gesamten 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 typischerweise über zehn Jahre nach Inverkehrbringen aufzubewahren.

In der Praxis ist diese Pflicht die am häufigsten unterschätzte. 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 die etablierte Methode, um genau diese Kette strukturiert, wiederholbar und prüffest 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 bewährte, gut kombinierbare Bausteine haben sich in der Praxis durchgesetzt und lassen sich unmittelbar auf die Anhang-I-Anforderungen abbilden.

Data-Flow-Diagramme (DFD): die Landkarte

Zuerst wird das System modelliert — Prozesse, Datenspeicher, externe Entitäten und, entscheidend, 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: Vollständigkeit erzwingen

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

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

STRIDE erzwingt Vollständigkeit und lässt sich direkt auf die grundlegenden Schutzziele aus Anhang I (Authentizität, Integrität, Vertraulichkeit, Verfügbarkeit, minimale Angriffsfläche) abbilden. Das ist der Grund, warum diese Methode für den CRA-Nachweis so gut geeignet ist: 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 Support-Zeitraum orientiert sich an der erwarteten Lebensdauer; als Leitwert werden mindestens fünf Jahre genannt.
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 ist dabei maschinenlesbar beizulegen — in CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 (vgl. BSI TR-03183-2 v2.1.0), mindestens auf Ebene der direkten Abhängigkeiten. Sie ist Teil der technischen Dokumentation, es besteht aber keine allgemeine Veröffentlichungspflicht.

Von der Bewertung zur nachvollziehbaren Kette

Das Ergebnis eines guten Threat-Modelings ist eine prüffeste Kette, die eine notifizierte Stelle oder ein Auditor erwartet: 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: Der Großteil der Produkte darf sich selbst bewerten (Modul A), bei „wichtigen" Produkten (Anhang III) und „kritischen" Produkten (Anhang IV) greifen strengere Konformitätswege. Für KI-Produkte erweitert sich der Bedrohungskatalog zusätzlich um Prompt-Injection, Modell-Extraktion und Data-Poisoning — dieselbe Methodik trägt auch hier.

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 ab dem 11.09.2026. Die volle Anwendbarkeit aller Produktanforderungen folgt am 11.12.2027. Die Melde-Kaskade ist gestaffelt: 24 Stunden Frühwarnung, 72 Stunden vollständige Meldung — und danach unterschiedliche Abschlussberichte: 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme bei aktiv ausgenutzten Schwachstellen gegenüber einem Monat nach der 72-h-Meldung bei schweren Sicherheitsvorfällen. Gemeldet wird über die ENISA Single Reporting Platform.

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 %. Eine belastbare Risikobewertung ist damit nicht nur technisch, sondern auch wirtschaftlich der wichtigste Hebel.

Was Blackfort tut

Blackfort Technology UG (haftungsbeschränkt) bringt die Perspektive des Angreifers in die Risikobewertung ein: Aus praktischer Pentest- und Angriffsflächen-Kompetenz (u. a. Mitwirkung in der ACS-KI-Facharbeitsgruppe und als Mitautor eines öffentlichen Leitfadens zum Pentest von LLMs) modellieren wir Ihre Produkte mit DFD, STRIDE und Attack-Trees und übersetzen die Ergebnisse in die dokumentationsfähige Anhang-VII-Kette. So entsteht ein Threat-Model, das nicht nur formal existiert, sondern realen Angriffspfaden standhält.

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.