DE 
EN 
Gemäß CRA müssen Hersteller für Prüfer nachvollziehbar dokumentieren, warum sie Sicherheitsmaßnahmen eingeführt haben oder nicht. Security Decision Records eignen sich bestens für die Dokumentation von Entscheidungsprozessen.
Bild 1: SDR Stack
Nachvollziehbare Dokumentation der Risikobewertung
Die Cyberresilienz-Verordnung (kurz CRA für Cyber Resilience Act) verlangt von jedem Hersteller, dass er eine Bewertung der Cybersicherheitsrisiken (Anhang I.I) seines Produkts mit digitalen Elementen durchführt und diese während des gesamten Produktlebenszyklus auf dem neuesten Stand hält (Artikel 13.1-4). Diese Pflicht gilt für alle Maschinen, IoT-Geräte, Embedded-Systeme und natürlich für Software.
Bei einer Überprüfung durch die Marktüberwachungsbehörde oder bei einem Streitfall vor Gericht muss der Hersteller nachweisen können, dass sein Produkt ausreichend gegen Cybersicherheitsrisiken geschützt ist. In solchen Fällen nehmen die Prüfer die Risikobewertung genauestens unter die Lupe. Deshalb ist eine gründliche Dokumentation der Risikobewertung (Anhang VII.3) außerordentlich wichtig.
Ein Prüfer muss nachvollziehen können, warum der Hersteller sich bei einem Benutzungsszenario für oder gegen bestimmte Sicherheitsmaßnahmen entschieden hat. Bei der Dokumentation von Entscheidungsprozessen haben sich Architecture Decision Records (ADRs) bewährt. Security Decision Records (SDRs) sind eine Variante von ADRs, um die Sicherheitsentscheidungen in der Risikobewertung zu dokumentieren.
Gemeinsamer Ursprung von Risikobewertung und Security Decision Records
SDRs sind besonders gut für die Dokumentation der Risikobewertung geeignet, weil sich beide aus der Gefahrenmodellierung herleiten lassen. Zur Gefahrenmodellierung bevorzuge ich wegen seiner Einfachheit das 4-Fragen-Framework von Adam Shostack.
- Frage 1: Woran arbeiten wir? – Für den CRA umformuliert: Welches Benutzungsszenario betrachten wir gerade?
- Frage 2: Was kann schief gehen? – Welche wesentlichen Produkteigenschaften, wie Vertraulichkeit, Verfügbarkeit oder Minimierung der Angriffsfläche, sind verletzt?
- Frage 3: Was tun wir dagegen? – Mit welchen Sicherheitsmaßnahmen verringern oder beseitigen wir die Gefahren durch die verletzten Produkteigenschaften?
- Frage 4: Haben wir gute Arbeit geleistet? – Haben wir alle möglichen Gefahren ausreichend adressiert?
Jetzt brauchen wir nur noch eine Brücke zwischen den ermittelten Gefahren und den Produkteigenschaften des CRA. Diese Brücke liefert uns erneut Adam Shostack in seinem Artikel The Cyber Resilience Act (CRA). Die Produkteigenschaften (Annex I.I.2b-m) folgen einem Muster.
Produkte müssen Schutz bieten
– vor einer Gefahr (Frage 2)
– durch geeignete Sicherheitsmaßnahmen (Frage 3).
Eine Gefahr (z. B. unbefugter Zugriff) ist nichts anderes als eine verletzte Produkteigenschaft (z. B. Zugriff nur durch Befugte). Von einer Gefahr gelangen wir durch Verneinung zu einer Produkteigenschaft.
Wie dann die Risikobewertung genau aussieht, erkläre ich in dem Artikel A Pragmatic Approach to CRA Risk Assessment. Wie wir die vier Fragen zum Schreiben eines SDRs verwenden, lernen wir im nächsten Abschnitt.
Definition eines Security Decision Records
SDR-NNN: Titel
Status: Entwurf, Vorschlag, Akzeptiert, Ersetzt oder Verworfen
Datum: Datum der letzten Statusänderung
Autor(en): Namen der Autoren
Kontext
Benutzungsszenario (Frage 1) mit existierenden Sicherheitsmaßnahmen.
Die Tabelle gibt den Ist-Zustand wieder, welche Produkteigenschaften verletzt sind oder nicht (Frage 2). Mögliche Werte sind „+“ für erfüllt, „-“ für verletzt oder „n/a“ für nicht anwendbar.
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Ist-Zustand
OptionenListe möglicher Sicherheitsmaßnahmen (Frage 3), um Gefahren durch verletzte Produkteigenschaften einzudämmen.
Entscheidung
Ausgewählte Optionen.
Bevor wir die Entscheidung treffen, vergewissern wir uns, dass wir alle Gefahren behandelt oder behoben haben (Frage 4)
Konsequenzen
Begründung, warum sich der Ist-Zustand nach Anwendung der ausgewählten Optionen verbessert hat oder nicht.
Die Tabelle wiederholt den Ist-Zustand und gibt den Soll-Zustand an, welche Produkteigenschaften nach Anwendung der ausgewählten Optionen verletzt sind oder nicht (Frage 2).
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Ist-Zustand Soll-Zustand
Jedes SDR beginnt mit einer eindeutigen Nummer SDR-NNN und einem aussagekräftigen Titel. Dann folgen der Status, das Datum der letzten Statusänderung und die Namen der Autoren.
Das Leben eines SDR beginnt im Status Entwurf. Wenn das SDR bereit für einen Review durch das Produktteam ist, setzen wir den Status auf Vorschlag. Hat das SDR den Review gut überstanden, ist der neue Status Akzeptiert. Ab dann dürfen wir das SDR nicht mehr ändern, damit wir die Entscheidungsfindung in ein paar Monaten oder Jahren problemlos nachvollziehen können.
Wollen wir die Entscheidung später doch ändern, führen wir ein neues SDR ein und setzen den Status des alten SDR auf Ersetzt. Das alte SDR verweist auf das neue SDR. Wenn eine Entscheidung nicht mehr gültig ist und es auch keinen Ersatz gibt, bekommt das SDR den Status Verworfen.
Im Kontext beschreiben wir ein Benutzungsszenario wie die Fernwartung oder Inbetriebnahme eines Geräts durch einen Techniker. Dann gehen wir die Produkteigenschaften aus Anhang I.I.2 des CRA durch und ermitteln, welche Produkteigenschaften verletzt oder erfüllt sind. Diesen Verletzungsgrad tragen wir als Ist-Zustand in die Tabelle ein. Das folgende Diagramm gibt die Produkteigenschaften (2a) – (2m) noch einmal in aller Kürze an.
Bild. 2: Alle wesentlichen Produkteigenschaften (2a)-(2m) für die Dokumentation der Risikobewertung in SDRs
Für jede erfüllte Produkteigenschaft begründen wir, warum die existierenden Sicherheitsmaßnahmen zur Eindämmung der Gefahr ausreichen oder warum keine Sicherheitsmaßnahmen nötig sind. Im letzteren Fall erklären wir, warum der mögliche Schaden für das Gerät selbst oder vernetzte Geräte zu gering ist oder warum die besonderen Nutzungsumstände oder Nutzungsbedingungen aus der Zweckbestimmung die Gefahr ausreichend eindämmen. Diese Begründungen gehören in den Kontext.
Unter Optionen führen wir die Sicherheitsmaßnahmen auf, mit denen wir die verletzten Produkteigenschaften eindämmen oder beseitigen könnten. Die erste Option ist immer, nichts zu tun. Nur diese eine Option anzugeben, kann für die Prüfer verdächtig aussehen. Die Prüfer könnten annehmen, dass sich der Hersteller nicht ausreichend mit den Gefahren dieses Benutzungsszenarios beschäftigt hat. Deshalb ist es sinnvoll, mindestens zwei Optionen anzubieten.
In der Entscheidung legen wir fest, welche Optionen wir auswählen. Bei der Option Nichtstun kopieren wir noch die Spalte Ist-Zustand in die Spalte Soll-Zustand und sind fertig. Entscheiden wir uns dafür, doch etwas zu tun, müssen wir unter Konsequenzen begründen, warum sich die Produkteigenschaften durch die ausgewählten Sicherheitsmaßnahmen verbessern. Das machen wir genauso wie für die bereits existierenden Sicherheitsmaßnahmen im Kontext. Damit haben wir den Soll-Zustand des Benutzungsszenarios beschrieben. Wir tragen den Verletzungsgrad für jede Produkteigenschaft in der Spalte Soll-Zustand in der Tabelle ein.
In der Tabelle fehlen drei Produkteigenschaften.
- 2a. Das Gerät muss ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden.
- 2i. Die negativen Auswirkungen auf das Gerät selbst sowie auf die Verfügbarkeit anderer Geräte und Netzwerke soll minimiert werden.
- 2k. Die Auswirkungen von Sicherheitsvorfällen müssen durch geeignete Maßnahmen eingedämmt werden.
Das Fehlen ist Absicht, da diese drei Eigenschaften Ziele sind und aus den anderen Eigenschaften folgen. Wenn unsere Sicherheitsmaßnahmen die anderen Eigenschaften erfüllen, dann sind auch diese drei Eigenschaften erfüllt.
Beispiel eines Security Decisions Records
Bild 3: Betriebsumgebung einer Wärmepumpe aus Benutzersicht mit dem Benutzungsszenario für Fernwartung mittels VNC
Als Benutzungsszenario suchen wir uns die Fernwartung mittels VNC für eine Wärmepumpe aus. Alles Weitere steht im SDR.
SDR-007: Fernwartung über VNC
Status: Akzeptiert
Datum: 16.09.2026
Autor(en): Burkhard Stubert
Kontext
Ein Techniker kann sich jederzeit über VNC mit jeder Wärmepumpe des Herstellers verbinden, um eine Fernwartung durchzuführen. Über VNC bedient der Techniker die grafische Benutzeroberfläche der Wärmepumpe. Neben den Funktionen, die die Bewohner nutzen, stehen dem Techniker zusätzliche Funktionen zur Diagnose und Wartung zur Verfügung.
- Die VNC-Verbindung ist verschlüsselt (2e).
- VNC überträgt nur die geänderten Bildschirmausschnitte. Eine Manipulation der übertragenen Daten ist nur sehr schwer möglich (2f), da die Daten komprimiert und verschlüsselt sind.
- Der Techniker kann das WLAN-Passwort des Heimnetzwerkes und andere Anmeldedaten der Bewohner nicht einsehen (2g).
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Ist-Zustand – n/a – + + + – – – n/a
Optionen
- Nichts zu tun.
- Der Techniker muss sich erfolgreich beim Cloud-Backend angemeldet haben, bevor er sich per VNC mit der Wärmepumpe verbinden kann.
- Standardmäßig ist der VNC-Server auf der Wärmepumpe deaktiviert. Erst wenn ein Bewohner die VNC-Verbindung aktiviert, startet die Wärmepumpe den VNC-Server und der Techniker kann sich über VNC verbinden.
- Die Wärmepumpe hat eine private Internet-Adresse und ist somit aus dem Internet nicht erreichbar. Sie muss daher die VNC-Verbindung initiieren. Das Cloud-Backend leitet den VNC-Verbindungswunsch der Wärmepumpe an den VNC-Client des Technikers weiter. Der Techniker akzeptiert die Verbindung.
- Die Wärmepumpe schließt die VNC-Verbindung nach zwei Stunden automatisch. Die Bewohner können die Sitzung vor Ablauf einmal um zwei Stunden verlängern und jederzeit beenden.
- Die Wärmepumpe protokolliert Beginn und Ende der VNC-Sitzung sowie die Identität des Technikers als Sicherheitsereignisse mit.
Entscheidung
Wir wählen die Optionen 2, 3, 4, 5 und 6 aus.
Konsequenzen
Ein Angreifer braucht zusätzlich zum API-Schlüssel für VNC sowohl die Anmeldedaten eines Technikers (Option 2) als auch die explizite Zustimmung eines Bewohners (Option 3). Dadurch ist der Zugriff (2d) auf die Wärmepumpe besser abgesichert.
Option 4 und 5 minimieren die Angriffsfläche (2j), da die Wärmepumpe von Computern außerhalb des Heimnetzwerkes nicht erreichbar ist und die VNC-Verbindung zeitlich stark beschränkt ist.
Aufgrund von Option 5 kann ein Überlastungsangriff maximal vier Stunden dauern oder bis ein Bewohner die VNC-Sitzung beendet. Dadurch wird die Verfügbarkeit der Wärmepumpe erhöht (2h).
Option 6 zeichnet die Sicherheitsereignisse auf (2l).
Alle Optionen sind ab der Inbetriebnahme wirksam, wodurch eine sichere Standardkonfiguration (2b) für dieses Benutzungsszenario gewährleistet ist.
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Ist-Zustand – n/a – + + + – – – n/a Soll-Zustand + n/a + + + + + + + n/a
SDRs ohne Änderung in die technische Dokumentation übernehmen
Über die Produkteigenschaften schreibt der CRA schon einige Standard-Benutzungsszenarien vor, die ausreichend gegen Cyberangriffe abgesichert sein müssen: Inbetriebnahme (2b), Außerbetriebnahme (2b und 2m), automatische Sicherheitsupdates mit Opt-out (2c) und Protokollieren von Sicherheitsereignissen (2l). Dazu gesellen sich dann alle Kern- und Zusatzfunktionen, die in der Zweckbestimmung aufgeführt sind. Für die Wärmepumpe können wir diese Funktionen aus dem Diagramm ersehen:
- Direktbedienung an der Inneneinheit durch Bewohner oder Techniker
- Fernbedienung über Handy- oder Web-App durch Bewohner
- Fernwartung mittels VNC durch Techniker
- Fernüberwachung über Web-App durch Techniker
- Funktionale Updates übers Internet oder über USB-Stick
- Authentisierung der Benutzer am Cloud-Backend oder an der Inneneinheit
Wenn wir von technischer Seite auf die Wärmepumpe schauen, kommen noch eine Reihe von Benutzungsszenarien hinzu. Alle diese Szenarien zu finden, ist die Antwort auf Frage 4: Haben wir alle Gefahren in allen Benutzungsszenarien adressiert?
Alle diese Benutzungsszenarien und ihre Sicherheitsrelevanz dokumentieren wir mit Hilfe von SDRs. Diese SDRs übernehmen wir ohne Änderung in die technische Dokumentation und erfüllen dadurch Anhang VII.3. SDRs ermöglichen es uns, unsere Entscheidungsfindung bei der Risikobewertung für externe Prüfer leicht nachvollziehbar zu dokumentieren.
Machen Sie sich fit für diesen hochaktuellen Themenbereich: Vom 16. bis 20. November 2026 findet in München das Training Der Cyber Resilience Act (CRA) – praktisch erklärt für die Embedded-Entwicklung unter der Leitung von Burkhard Stubert statt. Die Teilnehmenden lernen am Beispiel einer Wärmepumpe, wie sie die Konformitätsbewertung für den CRA selbst durchführen können.
Weiterführende Informationen
MicroConsult-Training: Der Cyber Resilience Act (CRA) – praktisch erklärt für die Embedded-Entwicklung
MicroConsult Training & Coaching: Embedded- und Echtzeitentwicklung
MicroConsult Fachwissen: Embedded- und Echtzeit-Softwareentwicklung
Alle Trainings & Termine auf einen Blick
Über den Autor
Als Systemarchitekt und Chef-Ingenieur hilft Burkhard Stubert Herstellern dabei, wichtige Entscheidungen frühzeitig und richtig zu treffen, um kostspielige Überraschungen zu vermeiden. Seine Kunden bauen Landmaschinen, Baumaschinen, Warenausgabeautomaten, Autos, Backöfen, Messinstrumente und andere Maschinen und Geräte. Seit 13 Jahren führt er sein eigenes Geschäft.
