CRA-Risikoanalyse und Schwachstellenbewertung nach harmonisierten Normen

Der Cyber Resilience Act verpflichtet Hersteller, Importeure und Händler dazu, Produkte mit digitalen Elementen cybersicher zu entwickeln, bereitzustellen und über den gesamten Lebenszyklus hinweg zu begleiten. Im Zentrum steht dabei die Security-Risikoanalyse.

Sie ist nicht nur ein einzelner Arbeitsschritt. Sie ist die Grundlage dafür, Schwachstellen zu bewerten, Maßnahmen abzuleiten, technische Dokumentation zu erstellen und die Konformitätsbewertung vorzubereiten.

Gerade deshalb lohnt sich ein genauer Blick darauf, wie eine Risikoanalyse im CRA-Kontext aufgebaut sein muss und welche Rolle harmonisierte Normen dabei spielen.

Warum die Risikoanalyse im CRA zentral ist

Der CRA fordert, dass Produkte mit digitalen Elementen ein angemessenes Cybersicherheitsniveau erreichen. Außerdem sollen Produkte ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden.

Damit wird die Risikoanalyse zum zentralen Instrument. Sie hilft dabei zu beurteilen:

• welche Risiken für ein Produkt bestehen
• welche Schwachstellen für das konkrete Produkt relevant sind
• ob eine Schwachstelle tatsächlich ausnutzbar ist
• welche Gegenmaßnahmen erforderlich sind
• ob das verbleibende Risiko akzeptiert werden kann
• welche Informationen in die technische Dokumentation einfließen müssen

Eine Schwachstelle in einer Softwarebibliothek ist nicht automatisch in jedem Produkt praktisch ausnutzbar. Entscheidend ist der Kontext: Wie ist das Produkt aufgebaut? Welche Schnittstellen gibt es? Wie ist die Betriebsumgebung? Welche Schutzmaßnahmen bestehen bereits?

Genau diese Bewertung kann nicht losgelöst vom Produkt erfolgen.

Warum Schwachstellenlisten alleine nicht ausreichen

Schwachstellenlisten ersetzen keine Risikoanalyse

Viele Unternehmen starten beim CRA zunächst mit klassischen Schwachstellen-Scannern oder einer Software Bill of Materials (SBOM). Dadurch wird sichtbar, welche bekannten Schwachstellen sich innerhalb eines Produktes befinden. Genau an diesem Punkt endet jedoch häufig die rein technische Betrachtung.

Der CRA fordert nicht nur die Identifikation bekannter Schwachstellen, sondern deren Bewertung im konkreten Produktkontext.

Denn dieselbe Schwachstelle kann je nach Systemumgebung zu völlig unterschiedlichen Risiken führen. Entscheidend ist unter anderem:

• ob die betroffene Komponente überhaupt erreichbar ist
• welche Kommunikationspfade existieren
• welche Schutzmaßnahmen bereits umgesetzt wurden
• ob physischer Zugriff möglich ist
• welche Rollen und Berechtigungen vorhanden sind
• wie die Betreiberumgebung aufgebaut ist

Erst die Kombination aus Schwachstelle, Systemkontext und realem Angriffspfad entscheidet darüber, ob eine Schwachstelle tatsächlich ausnutzbar wird.

Genau deshalb wird die Risikoanalyse im CRA zu einem zentralen Bestandteil der Konformitätsbewertung.

Harmonisierte Normen & Konformitätsvermutung

Der CRA basiert auf dem Konzept des New Legislative Framework. Dabei spielen harmonisierte Normen eine wichtige Rolle.

Harmonisierte Normen sind technische Standards, die im EU-Amtsblatt veröffentlicht werden. Ihre Anwendung ist rechtlich nicht verpflichtend. Wer sie anwendet, kann jedoch von einer widerlegbaren Konformitätsvermutung profitieren.

Das bedeutet: Die Anwendung harmonisierter Normen kann es erleichtern, nachzuweisen, dass die Anforderungen aus dem CRA erfüllt werden. Werden sie nicht angewendet, muss auf anderem Weg gezeigt werden, dass die Anforderungen eingehalten werden.

Für den CRA befinden sich aktuell zahlreiche Standards in Entwicklung. Unterschieden wird dabei zwischen produktunabhängigen horizontalen Standards und produktbezogenen vertikalen Standards. Zu den produktunabhängigen Standards gehört auch der Entwurf EN 40000 1 2, der unter anderem Anforderungen an Risk Management Elements beschreibt.

Was die Risikoanalyse nach harmonisiertem Standard leisten muss

Der Entwurf zur EN 40000 1 2 beschreibt kein starres Verfahren nach einem einzelnen bestehenden Standard. Stattdessen werden Rahmenbedingungen beschrieben, die eine Risikoanalyse erfüllen muss.

Dazu gehören insbesondere:

• Festlegung des Produktkontextes
• Festlegung der Methodik
• Durchführung der Risikoanalyse
• Risikobehandlung
• Risikokommunikation
• Fortschreibung über den Lebenszyklus

Die Methodik muss so gewählt werden, dass sie konsistent über den gesamten Lebenszyklus angewendet werden kann. Die Ergebnisse müssen vergleichbar bleiben. Es hilft wenig, heute eine Methode zu nutzen und in drei Jahren eine andere, wenn sich die Risikoniveaus dann nicht mehr sinnvoll gegenüberstellen lassen.

Außerdem muss die Methodik zum Produkt passen, den Stand der Technik widerspiegeln und individuelle sowie aggregierte Risiken betrachten.

Produktkontext: Der erste Schritt der Risikoanalyse

Bevor Risiken bewertet werden, muss der Produktkontext festgelegt werden. Dazu gehört die Zweckbestimmung des Produktes.

Relevant sind unter anderem:

• wofür das Produkt gedacht ist
• wie es vernünftigerweise vorhersehbar verwendet wird
• welche Nutzergruppen das Produkt verwenden
• welche Nutzungsdauer vorgesehen ist
• in welcher Umgebung das Produkt eingesetzt wird
• mit welchen Netzwerken oder Systemen es verbunden ist
• welche Funktionen und Schnittstellen vorhanden sind

Wichtig ist dabei die vernünftigerweise vorhersehbare Verwendung. Diese kann auch eine Nutzung umfassen, die nicht ausdrücklich in der Anleitung beschrieben ist, aber nach menschlichem Verhalten erwartbar ist.

Nicht berücksichtigt werden muss dagegen die vorhersehbare Fehlanwendung.

Methodik: Risikoakzeptanz und Vergleichbarkeit

Nach dem Produktkontext wird die Methodik der Risikobewertung festgelegt. Dabei müssen Risikoakzeptanzkriterien definiert werden.

Ein Beispiel dafür ist eine Risikomatrix. Sie verbindet Eintrittswahrscheinlichkeit und Auswirkung. Daraus ergeben sich Risikokategorien. Über eine Risikoakzeptanzschwelle wird festgelegt, welche Risiken akzeptiert werden können und welche behandelt werden müssen.

Einflussfaktoren für diese Akzeptanzkriterien können sein:

• regulatorische Anforderungen
• Verträge mit Kunden
• bekannte Risiken
• Nutzergruppen
• Stand der Technik
• gesellschaftlich akzeptierte Risikoniveaus für den jeweiligen Produkttyp

Risiken unterhalb der Akzeptanzschwelle können akzeptiert werden. Sie müssen dennoch dokumentiert werden. Risiken oberhalb der Schwelle müssen behandelt werden.

Durchführung der Risikoanalyse

Bei der Durchführung der Risikoanalyse werden zunächst Assets und Schutzziele identifiziert. Anschließend werden Bedrohungen betrachtet.

Dabei geht es um Fragen wie:

• Wer könnte das System angreifen?
• Aus welchem Grund?
• Über welchen Weg?
• Welche Assets wären betroffen?
• Wie wahrscheinlich ist der Angriff?
• Welche Auswirkungen hätte er?

Aus Eintrittswahrscheinlichkeit und Auswirkung ergibt sich das Risiko. Danach wird bewertet, ob dieses Risiko akzeptiert werden kann oder behandelt werden muss.

Dieser Schritt ist auch für die Bewertung von Schwachstellen entscheidend. Wenn eine Schwachstelle bekannt wird, muss bewertet werden, ob und wie sie im konkreten Produkt ausnutzbar ist.

Risikobehandlung und Kommunikation

Wenn ein Risiko oberhalb der definierten Akzeptanzschwelle liegt, muss es behandelt werden. Das kann unterschiedliche Maßnahmen betreffen, zum Beispiel technische Anpassungen, Konfigurationsänderungen oder andere Schutzmaßnahmen.

Nach der Bewertung und Behandlung muss das Ergebnis dokumentiert werden. Die Risikoanalyse gehört in die technische Dokumentation des CRA. Sie muss nicht allen Nutzern offengelegt werden, ist aber für den Hersteller selbst und gegebenenfalls für die Marktüberwachungsbehörde relevant.

Warum Risikoanalysen regelmäßig aktualisiert werden müssen

Risikoanalysen können veralten. Das kann verschiedene Gründe haben:

• das Produkt wird verändert
• eine neue Schnittstelle wird hinzugefügt
• die Bedrohungslandschaft verändert sich
• neue Schwachstellen werden bekannt
• ein Security Incident tritt auf
• aktiv ausgenutzte Schwachstellen werden identifiziert
• Komponenten müssen wegen Obsoleszenz ausgetauscht werden

Auch wenn keine dieser konkreten Bedingungen eintritt, muss definiert werden, was eine regelmäßige Aktualisierung bedeutet. Der CRA verlangt, dass die Risikoanalyse über den Unterstützungszeitraum aktuell gehalten wird.

Umsetzung mit digitalem Zwilling und Angriffsbaum

In SECIRA wird die Risikoanalyse über einen digitalen Zwilling unterstützt. Das Produkt wird mit seinen Komponenten, Eigenschaften, Schnittstellen und Zusammenhängen modelliert.

Im Webinar wurde dies anhand einer Fertigungsstraße mit Laserschneidemaschine gezeigt. Im Modell wurden unter anderem technische Komponenten, Schnittstellen und Protokolle abgebildet. Die Laserschneidemaschine hatte beispielsweise eine Webschnittstelle und nutzte MQTT. Für die Webschnittstelle war im Beispiel keine Transportverschlüsselung konfiguriert.

Aus dem Modell kann automatisch ein Angriffsbaum abgeleitet werden. Dieser zeigt, über welche Wege ein Angreifer ein System erreichen oder beeinträchtigen könnte. Dabei wird nicht nur die technische Komponente betrachtet, sondern auch die Umgebung.

Im Beispiel wurde unter anderem betrachtet:

• wie ein Angreifer physisch in eine Produktionshalle gelangen könnte
• welche Rolle Türen, Fenster und Schaltschränke spielen
• wie sich ungesicherte Schnittstellen auf das Risiko auswirken
• welche Gegenmaßnahmen die Eintrittswahrscheinlichkeit senken können

Maßnahmen in Iterationen bewerten

SECIRA ermöglicht es, Maßnahmen in Iterationen zu betrachten. So kann sichtbar gemacht werden, wie sich Risiken durch einzelne Maßnahmen verändern.

Im Beispiel wurden zunächst Softwaremaßnahmen betrachtet, etwa die Absicherung einer Webschnittstelle durch Verschlüsselung. Dadurch konnte die Eintrittswahrscheinlichkeit bestimmter Risiken reduziert werden.

In einer weiteren Iteration wurden physische Schutzmaßnahmen betrachtet, etwa ein Schloss an der Tür der Produktionshalle. Diese Maßnahme wirkt nicht nur auf eine einzelne Komponente, sondern auf alle Komponenten, die sich in der Halle befinden.

So wird erkennbar, welche Maßnahmen welches Risiko senken und ob weitere Schritte notwendig sind, um unter die definierte Akzeptanzschwelle zu kommen.

Fazit

Die CRA-Risikoanalyse ist kein formaler Nachweis am Ende eines Projekts. Sie ist ein zentrales Werkzeug, um Schwachstellen zu bewerten, Maßnahmen zu priorisieren und ein angemessenes Sicherheitsniveau über den Lebenszyklus eines Produktes nachzuweisen.

Harmonisierte Normen können dabei helfen, die Anforderungen strukturiert umzusetzen und die Nachweisführung zu erleichtern. Entscheidend bleibt aber, dass die Risikoanalyse den konkreten Produktkontext berücksichtigt: Zweckbestimmung, Nutzer, Betriebsumgebung, Schnittstellen, Assets, Schutzziele und Bedrohungen.

Nur so lässt sich beurteilen, ob eine Schwachstelle im konkreten Produkt tatsächlich ausnutzbar ist und welche Maßnahmen erforderlich sind. Mehr zum Thema Risikoanalyse und harmonisierte Normen im Kontext vom CRA finden Sie auch in unserem Webinar.