CRA Schwachstellenbewertung & Ausnutzbarkeit erklärt

Der Cyber Resilience Act fordert, dass Produkte ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden. Gleichzeitig müssen Hersteller Risiken über den gesamten Produktlebenszyklus hinweg kontinuierlich bewerten.

In der Praxis stellt sich dabei schnell eine zentrale Frage:

Wann ist eine Schwachstelle in einem Produkt tatsächlich ausnutzbar?

Denn nicht jede bekannte Schwachstelle führt automatisch zu einem realen Risiko im konkreten Produktkontext. Genau an diesem Punkt wird die Risikoanalyse zum entscheidenden Bestandteil der CRA-Umsetzung.

Warum CVSS alleine nicht ausreicht

Viele Unternehmen arbeiten heute bereits mit Schwachstellen-Scannern oder Software Bill of Materials (SBOMs). Dadurch werden bekannte Schwachstellen in verwendeten Komponenten sichtbar. Das Problem dabei: Eine Schwachstelle allein sagt noch nicht aus, ob sie im konkreten Produkt tatsächlich ausnutzbar ist.

Der gleiche CVE-Eintrag kann in zwei unterschiedlichen Produkten zu völlig unterschiedlichen Risiken führen.

Entscheidend sind unter anderem:

• die Betriebsumgebung
• vorhandene Schutzmaßnahmen
• Netzwerksegmentierung
• physischer Zugriff
• Kommunikationsschnittstellen
• Rollen und Berechtigungen
• reale Angriffspfade

Genau deshalb fordert der CRA eine Security-Risikoanalyse im Produktkontext.

Der Produktkontext entscheidet über das Risiko

In unserem Webinar „SECIRA im Einsatz - CRA-Risikoanalyse vom Systemmodell bis zum Produktlebenszyklus“ haben wir dies anhand einer industriellen Fertigungsanlage mit Laserschneidemaschine gezeigt.

Die Anlage bestand unter anderem aus:

• Laserschneidemaschine
• Steuerungskomponenten
• MQTT-Kommunikation
• Webschnittstellen
• Produktionshalle
• Schaltschrank
• Transport- und Lackierungsprozessen

Die einzelnen Komponenten wurden innerhalb eines digitalen Zwillings modelliert.

Dabei wurden nicht nur technische Systeme betrachtet, sondern auch:

• physische Infrastruktur
• Zugänge
• Rollen
• Kommunikationsbeziehungen
• Sicherheitsmerkmale einzelner Komponenten

Genau dieser Kontext ist entscheidend für die Bewertung von Schwachstellen.

Beispiel: Schwachstelle im Webinterface

In unserem Beispiel verfügte die Laserschneidemaschine über eine Webschnittstelle zur Parametrisierung.

Dabei wurde modelliert, dass es keine Transportverschlüsselung gibt und zusätzliche Schutzmaßnahmen fehlen.

Zusätzlich wurde betrachtet:

• wie ein Angreifer überhaupt zur Anlage gelangen könnte
• welche physischen Barrieren existieren
• welche Netzwerkpfade vorhanden sind
• welche Komponenten miteinander kommunizieren

Auf Basis dieses Modells wurde automatisiert ein Angriffsbaum erzeugt.

Angriffsbäume statt isolierter Schwachstellenlisten

Der Angriffsbaum bewertet nicht nur einzelne Schwachstellen isoliert, sondern:

• welchen Weg ein Angreifer tatsächlich gehen müsste

• welche Voraussetzungen erfüllt sein müssen
• welche Schutzmaßnahmen bereits existieren
• wie komplex ein erfolgreicher Angriff ist
• welche Auswirkungen entstehen würden

Im Beispiel musste ein Angreifer:

• zunächst Zugang zur Produktionshalle erhalten
• anschließend den Schaltschrank erreichen
• danach auf die Schnittstellen der Laserschneidemaschine zugreifen

Dabei zeigte sich: Die physische Umgebung beeinflusst das Risiko direkt. Eine dauerhaft offene Tür zur Produktionshalle erhöhte die Eintrittswahrscheinlichkeit erheblich.

Gegenmaßnahmen verändern die Ausnutzbarkeit

Im Webinar wurden anschließend verschiedene Gegenmaßnahmen betrachtet.

Dazu gehörten unter anderem:

• elektronische Schlösser
• zusätzliche physische Absicherung
• Verschlüsselung der Webschnittstelle
• bessere Konfiguration von Kommunikationsprotokollen

Die Maßnahmen wurden in Iterationen modelliert.

Dadurch konnte sichtbar gemacht werden:

• welche Risiken reduziert werden
• welche Maßnahmen welche Auswirkungen haben
• welche Risiken weiterhin oberhalb der Akzeptanzschwelle liegen

Im Beispiel reduzierten die physischen Schutzmaßnahmen zunächst bestimmte Risiken deutlich.

Zusätzliche technische Maßnahmen an den Kommunikationsschnittstellen reduzierten anschließend weitere Risiken.

Warum die Betriebsumgebung entscheidend ist

Unser Beispiel des Industrielasers im digitalen Zwilling zeigt also deutlich: Eine Schwachstelle kann je nach Betriebsumgebung völlig unterschiedlich bewertet werden.

Die gleiche technische Schwachstelle kann:

• in einer stark segmentierten Produktionsumgebung schwer ausnutzbar sein
• in einer offen angebundenen Umgebung dagegen ein hohes Risiko darstellen

Deshalb reicht es nicht aus, lediglich bekannte Schwachstellen aufzulisten und entscheidend ist die Frage wie sich die Schwachstelle im konkreten Produkt und in der tatsächlichen Betriebsumgebung auswirkt.

Betreiberumgebung als konkreter Risikofaktor

Ob eine Schwachstelle tatsächlich kritisch ist, hängt nicht nur von der betroffenen Komponente selbst ab, sondern stark von der Umgebung, in der das Produkt betrieben wird.

Dabei spielen unter anderem folgende Faktoren eine Rolle:

• Netzwerkanbindung, Firewall und Segmentierung
• physischer Zugriff auf Anlagen oder Komponenten
• Rollen- und Zutrittsberechtigungen
• externe Wartungszugänge
  
• Fernwartungsanbindungen
• vorhandene Schutzmaßnahmen innerhalb der Infrastruktur

Dadurch kann dieselbe Schwachstelle in unterschiedlichen Betriebsumgebungen zu völlig unterschiedlichen Risiken führen.

Ein System innerhalb einer isolierten Produktionsumgebung mit streng kontrollierten Zugriffen kann deutlich anders bewertet werden als ein vergleichbares Produkt mit direkter externer Anbindung oder offenen Wartungszugängen.

Gerade in OT- und Industrieumgebungen reicht es deshalb nicht aus, Schwachstellen ausschließlich technisch oder anhand generischer CVSS-Werte zu bewerten.

Entscheidend ist immer die Frage, wie sich eine Schwachstelle innerhalb der tatsächlichen Betreiberumgebung ausnutzen lässt und welche realen Angriffspfade daraus entstehen.

Mit diesem Wissen ist es möglich, die potenziellen Risiken proaktiv einzuplanen und bereits für das Produkt eine sichere Betriebsumgebung vorzudenken und bspw. in Form einer Checkliste an den Betreiber zu übergeben, damit diese Risiken gar nicht erst eintreten.

Risikoanalyse als kontinuierlicher Prozess

Der CRA betrachtet nicht nur die Entwicklung eines Produktes, sondern den gesamten Unterstützungszeitraum und genau dadurch verändert sich auch die Risikoanalyse kontinuierlich.

Neue Risiken können entstehen durch:

• neue bekannte Schwachstellen
• neue Angriffstechniken
• Änderungen am Produkt
• neue Schnittstellen
• Komponentenwechsel
• Veränderungen der Betriebsumgebung

Die Risikoanalyse muss deshalb regelmäßig aktualisiert werden.

SECIRA als Grundlage für strukturierte Risikoanalysen

Im vorangehenden Beispiel haben wir gezeigt, wie SECIRA Risikoanalysen über einen digitalen Zwilling unterstützt.

Dabei werden Komponenten, Kommunikationspfade, Sicherheitsmerkmale, Rollen, physische Infrastruktur, Bedrohungen und Gegenmaßnahmen zentral modelliert.

Auf dieser Grundlage können Angriffsbäume automatisiert erzeugt und Risiken nachvollziehbar bewertet werden.

Dadurch wird sichtbar:

• welche Schwachstellen tatsächlich relevant sind
• welche Angriffspfade existieren
• welche Gegenmaßnahmen wirksam sind
• wie sich Risiken über den Lebenszyklus verändern

Fazit

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

Nicht jede bekannte Schwachstelle ist automatisch ausnutzbar.

Entscheidend sind:

• Betriebsumgebung
• reale Angriffspfade
• vorhandene Schutzmaßnahmen
• physische und logische Infrastruktur
• tatsächliche Erreichbarkeit

Genau deshalb wird die Risikoanalyse zum zentralen Werkzeug der CRA-Umsetzung.

Sie hilft dabei, Risiken nachvollziehbar zu bewerten, Gegenmaßnahmen abzuleiten und Produkte über den gesamten Lebenszyklus hinweg strukturiert abzusichern.