Risikoanalyse im Cyber Resilience Act

Warum überhaupt eine Risikoanalyse?

Wenn in Projekten das Thema Risikoanalyse aufkommt, entsteht schnell der Eindruck, es ginge nur darum, ein weiteres Kästchen in einer Checkliste abzuhaken. Doch das ist ein totales Missverständnis und wird dem Thema Risikoanalyse und Risikomanagement nicht gerecht. Eine Risikoanalyse ist kein reines Dokumentationsartefakt, sondern ein zentrales Werkzeug, um die Sicherheit und Resilienz eines Produkts wirklich zu verstehen und gezielt zu verbessern.

Jedes Produkt ist unterschiedlich und benötigt eine individuelle Risikoanalyse. Die Risiken eines Smart-Home-Geräts unterscheiden sich grundlegend von denen eines Industrie-Sensors oder einer Software-as-a-Service-Plattform. Deshalb kann eine Risikoanalyse niemals nur eine Standard-Liste von Bedrohungen abarbeiten, sie muss individuell auf das Produkt und die entsprechenden Einsatzzwecke zugeschnitten sein.

Besonders wertvoll ist dabei die Zusammenarbeit mit den tatsächlichen Produktverantwortlichen und Experten: Product Owner, Architekten, Entwickler und Betrieb. Nur wenn deren Expertise einfließt, lassen sich die entscheidenden Fragen beantworten:

• Was wäre das Schlimmste, das unserem Produkt passieren könnte?
• Was wäre, wenn eine veraltete Firmware absichtlich wieder eingespielt wird?
• Wie reagieren wir, wenn Millionen Geräte gleichzeitig kompromittiert werden?

Diese „What if“-Fragen sind der Schlüssel, um nicht nur Compliance zu erfüllen, sondern tatsächlich ein sichereres Produkt zu entwickeln.

Risikoanalyse und kontinuierliches Risikomanagement als Grundlage für den CRA

Der Cyber Resilience Act (CRA) macht deutlich, dass es ohne eine Risikoanalyse nicht geht. Artikel 13 schreibt vor, dass Hersteller eine Bewertung der Cybersicherheitsrisiken durchführen müssen, die mit einem Produkt mit digitalen Elementen verbunden sind. Diese Bewertung darf kein einmaliger Schritt sein, sie muss laufend aktualisiert werden und alle Phasen des Produktlebenszyklus abbilden.

Die Risikoanalyse ist die Grundlage für alle weiteren Sicherheitsmaßnahmen, die im Annex I des CRA beschrieben sind. Nur wenn klar ist, welche Bedrohungen und Schwachstellen relevant sind, können Hersteller angemessene Maßnahmen treffen und überhaupt ein sichereres Produkt entwickeln und auf den Markt bringen.

Der CRA verlangt, dass dieses Risikomanagement den gesamten Lebenszyklus eines Produkts abdeckt. Typischerweise lassen sich die Phasen folgendermaßen strukturieren:

• Planning (Konzeptionsphase) In dieser Phase werden der Intended Use (geplanter Einsatzzweck) und vorhersehbarer Missbrauch (z.B. absichtliche Manipulation, unsachgemäße Nutzung) dokumentiert. Erste Risiken werden identifiziert.
• Design (Architektur) Eine Bedrohungsmodellierung (z. B. STRIDE, Attack Trees) deckt auf, welche Angriffsflächen im System bestehen. Architekturentscheidungen müssen Sicherheitsaspekte berücksichtigen. Sicherheitsentscheidungen wie beispielsweise Verschlüsselung und Zugriffskontrollen müssen dokumentiert werden.
• Development (Implementierung) Während der Entwicklung entstehen neue Risiken, z. B. durch eingebundene Open-Source-Bibliotheken. Hier ist eine kontinuierliche Überprüfung durch SCA (Software Composition Analysis) und SAST notwendig.
• Production (Test & Verifikation) Testergebnisse (Pen-Tests, DAST, Fuzzing) fließen direkt in die Risikoanalyse ein. Eintrittswahrscheinlichkeiten und Auswirkungen müssen angepasst werden.
• Delivery (Release & Deployment) Vor der Markteinführung muss eine finale Risikoanalyse vorliegen. Akzeptierte Restrisiken sind zu dokumentieren, ebenso die EU-Konformitätserklärung.
• Maintenance (Betrieb & End-of-Life) Nach Markteinführung ist ein kontinuierliches Risikomanagement gefordert: Schwachstellenmanagement, Patch- und Update-Prozesse sowie eine Risikoanalyse für das Ende des Produktlebens (End-of-Life).

Eine Risikoanalyse ist keine Momentaufnahme, sondern ein lebendiger Prozess, der die Sicherheit eines Produkts von der Idee bis zum Ende des Supports begleitet.

Notwendige Dokumentation für den CRA

Die Risikoanalyse ist nicht nur ein internes Arbeitsinstrument, sondern muss umfassend dokumentiert werden. Der CRA verlangt in Artikel 31 und Annex VII, dass die technische Dokumentation so vollständig ist, dass Marktaufsichtsbehörden jederzeit nachvollziehen können, wie Hersteller zu ihren Sicherheitsentscheidungen gekommen sind.

Das bedeutet:

• Alle Ergebnisse der Risikoanalyse müssen enthalten sein, nicht nur die finale Version, sondern auch die erste Risikoanalyse aus der Konzeptionsphase.
• Bereits zu Beginn müssen der Intended Use (geplanter Verwendungszweck) und der vorhersehbare Missbrauch dokumentiert sein. Diese Angaben bilden die Basis für alle weiteren Risikobewertungen.
• Jede spätere Aktualisierung der Risikoanalyse (z. B. nach Design-Änderungen, nach Testphasen oder im Betrieb) muss nachvollziehbar dokumentiert und versioniert werden.
• Neben der reinen Risikoidentifikation müssen auch die getroffenen Maßnahmen beschrieben werden, mit Verweis auf die jeweiligen Anforderungen aus Annex I.
• Wenn eine Anforderung aus Annex I nicht oder in abgewandelter Form umgesetzt wird, ist eine Begründung für diese Abweichung zu dokumentieren, einschließlich einer Beschreibung des akzeptierten Restrisikos.
• Ergebnisse aus Tests und Verifikation (z. B. Penetrationstests, DAST, Fuzzing) müssen ebenfalls in die technische Dokumentation aufgenommen werden, da sie die Annahmen der Risikoanalyse bestätigen oder widerlegen.
• Am Ende des Produktlebenszyklus muss die Risikoanalyse auch die Bewertung des End-of-Life-Risikos enthalten und dokumentieren, wie Kunden über verbleibende Risiken informiert werden.

Die Dokumentation ist damit nicht nur ein interner Nachweis, sondern die Grundlage für die Konformitätsbewertung und letztlich für die CE-Kennzeichnung.

Ein Workshop als Fundament für die Risikoanalyse

Die Einführung einer Risikoanalyse darf nicht im stillen Kämmerlein passieren. Am wirkungsvollsten ist es, wenn alle relevanten Stakeholder, von der Entwicklung über die Architektur bis hin zum Betrieb und der Produktverantwortung, an einem Tisch sitzen. Ein gut strukturierter Workshop ist der ideale Startpunkt, um die wichtigsten Risiken sichtbar zu machen und eine erste Bewertung vorzunehmen.

Ein solcher Workshop sollte bewusst interaktiv gestaltet sein. Es geht darum, unterschiedliche Blickwinkel zusammenzubringen: Entwickler kennen den Code, Architekten die Systemzusammenhänge, das Security-Team die Bedrohungslage, das Produktmanagement die Business-Perspektive. Zusammen entsteht so ein umfassendes Bild.

Agenda für einen Workshop

1. Begrüßung & Zielsetzung Der Workshop beginnt mit einer kurzen Einordnung und Zielsetzung: Warum machen wir diese Risikoanalyse? Der Cyber Resilience Act (CRA) verpflichtet uns zwar zu dieser Analyse, aber der eigentliche Wert liegt darin, unser Produkt sicherer zu machen und Business-Risiken zu minimieren. Dieser Kontext schafft ein gemeinsames Verständnis und Motivation.

2. Produktbeschreibung Bevor Risiken gesammelt werden, muss das Produkt klar umrissen sein:

• Was ist der Intended Use, also der geplante Einsatzzweck?
• Was könnte der vorhersehbare Missbrauch sein, etwa der Betrieb in unsicheren Umgebungen oder eine absichtliche Manipulation durch Angreifer?

Diese Diskussion ist essenziell, da sie die Grundlage für die gesamte Risikoanalyse bildet.

3. Asset-Identifikation Nun geht es darum, die kritischen Komponenten zu erfassen: Firmware, APIs, Datenbanken, Update-Mechanismen, Cloud-Services. Jede Komponente ist ein potenzielles Angriffsziel und muss deshalb separat betrachtet werden.

Genauso wichtig ist aber der Blick auf das Gesamtsystem: Viele Risiken entstehen nicht nur durch einzelne Bauteile, sondern durch ihre Interaktion. Ein Beispiel: Eine Firmware allein ist ein Asset, ein API-Gateway ebenfalls – doch die Kombination beider, etwa wenn die Firmware über das Gateway Updates bezieht, eröffnet zusätzliche Angriffspfade.

Daher sollte die Asset-Identifikation immer zwei Ebenen berücksichtigen:

1. Isolierte Komponenten – jedes einzelne Asset mit seinen Schwachstellen.
2. System in Kombination – wie greifen die Assets ineinander, welche Abhängigkeiten gibt es, wo entstehen Schnittstellenrisiken?

Dieser ganzheitliche Ansatz verhindert, dass nur Teilaspekte betrachtet werden, während sich die eigentlichen kritischen Risiken an den Übergängen zwischen Komponenten verstecken.

4. „What if“-Fragen Dieser Teil ist besonders wertvoll: Gemeinsam wird diskutiert, was im schlimmsten Fall passieren könnte.

• Was wäre, wenn der Update-Server kompromittiert wird?
• Was, wenn Angreifer eine manipulierte Firmware einspielen?
• Welche Folgen hätte ein Datenabfluss aus der Cloud-Datenbank?

Solche Worst-Case-Szenarien schärfen den Blick für die größten Risiken und holen auch die Business-Perspektive in die Diskussion.

5. Bedrohungsmodellierung (systematische Erfassung der Angriffsflächen) Um Bedrohungen nicht dem Zufall zu überlassen, ist eine strukturierte Methode zur Modellierung unerlässlich. Hier bieten sich etablierte Ansätze wie STRIDE oder Attack Trees an.

• STRIDE hilft, typische Angriffsarten systematisch durchzugehen: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Dadurch werden Angriffsflächen identifiziert, die im Alltag leicht übersehen würden.
• Attack Trees ermöglichen es, vom Angriffsziel („Manipulation der Firmware“) rückwärts zu denken und Schritt für Schritt die möglichen Angriffswege aufzuzeigen.

Wichtig ist, dass nicht nur isolierte Komponenten betrachtet werden (z. B. eine API oder eine Firmware), sondern auch die Kombination der Komponenten und die daraus entstehenden Schnittstellenrisiken. Oft liegen die größten Bedrohungen in den Übergängen zwischen Systemen.

Der Anspruch in diesem Workshop ist nicht, sofort eine hochdetaillierte Bedrohungsanalyse für das gesamte System zu erstellen. Ziel ist vielmehr eine strukturierte, nachvollziehbare Übersicht der relevanten Angriffsflächen, die als Ausgangsbasis für die weitere Risikoanalyse dient. Damit ist sichergestellt, dass keine wesentlichen Bedrohungskategorien übersehen werden und die Diskussion nicht ins Beliebige abgleitet.

6. Erste Risikobewertung Die identifizierten Risiken werden nun bewertet: Eintrittswahrscheinlichkeit (1–5) multipliziert mit Auswirkung (1–5). So entsteht eine erste Priorisierung: Welche Risiken sind kritisch, welche nur von geringer Bedeutung?

7. Ideen für die Risikomitigation sammeln Nun werden mögliche Mitigationsmöglichkeiten gesammelt, von technischen Maßnahmen wie Verschlüsselung oder Code-Signing bis zu organisatorischen Prozessen wie einem Incident-Response-Plan. Erste Bezüge zu den Anforderungen des Annex I im CRA helfen, die Maßnahmen gleich mit regulatorischen Vorgaben abzugleichen.

8. Nächste Schritte Zum Abschluss wird geklärt, wie es weitergeht:

• Wer dokumentiert die Ergebnisse des Workshops?
• Wer übernimmt welche Verantwortung im weiteren Prozess?
• In welchem Rhythmus wird die Risikoanalyse aktualisiert?

Damit wird aus dem Workshop kein einmaliges Ereignis, sondern der Startpunkt für ein kontinuierliches Risikomanagement.

Risikoanalyse über den Produktlebenszyklus mit Quality Gates

Um sicherzustellen, dass die Risikoanalyse nicht liegen bleibt, sondern in allen Phasen fortgeführt wird, empfiehlt sich die Einführung von Quality Gates. Diese Gates sind feste Prüfpunkte im Entwicklungs- und Betriebsprozess, an denen die Risikoanalyse bewusst auf den Tisch gelegt wird.

Das Prinzip dahinter ist einfach: Kein Projektabschnitt darf abgeschlossen werden, bevor die Risikoanalyse überprüft und falls notwendig aktualisiert wurde. Auf diese Weise wird verhindert, dass Risiken einmalig am Anfang dokumentiert und dann vergessen werden. Stattdessen wird die Risikoanalyse zu einem lebendigen Dokument, das sich mit dem Produkt weiterentwickelt.

Quality Gates haben mehrere Vorteile:

• Verbindlichkeit: Die Risikoanalyse ist nicht optional, sondern Teil des Prozesses.
• Transparenz: Entscheidungen und Restrisiken werden nachvollziehbar dokumentiert.
• Früherkennung: Risiken werden nicht erst kurz vor der Markteinführung entdeckt, sondern schrittweise adressiert.
• Nachvollziehbarkeit für den CRA: Jede Gate-Prüfung liefert ein Stück Dokumentation, das für die technische Dokumentation (Art. 31, Annex VII) genutzt werden kann.

Besonders wichtig ist, dass diese Gates nicht nur auf die technische Entwicklung abzielen, sondern auch Angriffe im Betrieb berücksichtigen. Der CRA verlangt ausdrücklich, dass das Risikomanagement den gesamten Lebenszyklus abdeckt, also auch die Phase, in der Produkte bereits bei Kunden im Einsatz sind. Neue Schwachstellen, Zero-Day-Exploits oder DoS-Angriffe gegen zentrale Systeme wie Update-Server müssen laufend in die Risikoanalyse einfließen.

Die folgende Tabelle zeigt, wie sich Quality Gates entlang des Produktlebenszyklus einordnen lassen:

Fazit

Eine Risikoanalyse im Sinne des CRA ist weit mehr als ein formales Muss, sie ist die Grundlage für die Entwicklung eines sicheren Produktes und damit ein entscheidender Erfolgsfaktor für die Zukunftsfähigkeit von Produkten.

Sie zwingt Hersteller, ihr Produkt ehrlich und systematisch zu durchleuchten: Wo liegen die Schwachstellen? Welche Angriffsflächen gibt es? Und wie sieht das Worst-Case-Szenario aus? Dabei werden nicht nur technische Aspekte sichtbar, sondern auch die Auswirkungen auf das Geschäft: Umsatzeinbußen, Reputationsschäden, regulatorische Sanktionen.

Besonders wertvoll ist die Verbindung von technischer Sicht und Business-Perspektive. Mit den richtigen „What if“-Fragen gelingt es, die schlimmsten Risiken greifbar zu machen: Was wäre, wenn ein Angreifer die Firmware manipuliert? Was passiert, wenn Kundendaten in falsche Hände geraten? Solche Szenarien öffnen den Blick für das, was wirklich auf dem Spiel steht.

Darüber hinaus sorgt die Risikoanalyse dafür, dass Risiken nicht nur erkannt, sondern auch dokumentiert, behandelt und über den gesamten Lebenszyklus hinweg überwacht werden. Quality Gates und ein kontinuierliches Risikomanagement stellen sicher, dass die Analyse nicht zum einmaligen Papierprodukt verkommt, sondern ein lebendiges Werkzeug bleibt.

Wer Risikoanalyse im Sinne des CRA lebt, erreicht nicht nur Compliance und vermeidet Sanktionen. Er baut vor allem sicherere, vertrauenswürdigere Produkte, die im Markt bestehen können. Kunden, Partner und Aufsichtsbehörden erwarten heute, dass Sicherheit nicht nachträglich ergänzt, sondern von Anfang an systematisch berücksichtigt wird.

Der eigentliche Mehrwert einer Risikoanalyse liegt also nicht darin, den CRA zu erfüllen, sondern darin, Produkte zu schaffen, die robust, verlässlich und zukunftssicher sind. Hersteller, die diesen Weg konsequent gehen, schaffen Vertrauen.

Solltest du Unterstützung benötigen, wie du den CRA effizient in deine bestehenden Produktentwicklungsprozesse integrieren kannst, oder Hilfe bei der GAP-Analyse oder allgemein CRA-Beratung brauchst, kannst du dich gerne an uns wenden.