Cybersecurity-Risikobewertung in der Praxis: Ein Beispiel
Ausgangspunkt: Worum geht es in diesem Beispiel?
Im ersten Artikel haben wir den TARA-Prozess als methodischen Rahmen für die Cybersecurity-Risikobewertung vorgestellt. In diesem zweiten Teil geht es nun um die Praxis: Wie sieht eine solche Bewertung konkret aus?
Als Kontext dient ein Gerätehersteller. Die Geräte arbeiten lokal, verfügen über Service-Schnittstellen und werden regelmäßig gewartet und kalibriert. Eine Cloud-Anbindung ist nicht zwingend erforderlich, Updates und Service erfolgen typischerweise vor Ort.
Im Folgenden betrachten wir zwei unterschiedliche Szenarien innerhalb desselben Produkts. Beide werden entlang der drei TARA-Phasen analysiert. Der entscheidende Unterschied: Ein Szenario hat kritische Auswirkungen bei niedriger Eintrittswahrscheinlichkeit, das andere eine hohe Eintrittswahrscheinlichkeit bei geringer Auswirkung. Genau an diesem Gegensatz zeigt sich, warum risikobasierte Bewertung im Sinne des Cyber Resilience Act so wichtig ist.
Beispiel 1: Manipulation von Kalibrierparametern
Beispiel 1 - Phase 1: Identifikation & Kontextanalyse
Das betrachtete Asset sind die Kalibrierparameter des Geräts. Diese bestimmen, wie Rohmesswerte interpretiert und in Ergebnisse umgerechnet werden. Sie werden intern gespeichert und beim Start des Geräts geladen.
Der Schutzbedarf ist eindeutig:
- Die Integrität der Kalibrierparameter ist kritisch.
- Eine Manipulation führt nicht zu einem offensichtlichen Fehler, sondern zu systematisch falschen Messergebnissen.
- Verfügbarkeit und Vertraulichkeit spielen eine untergeordnete Rolle.
Relevante Schnittstellen sind ein USB-Service-Port sowie die Service-Software, mit der Wartungsarbeiten durchgeführt werden.
Beispiel 1 - Phase 2: Analyse von Bedrohungen und Risiken
Das Bedrohungsszenario ist vergleichsweise unspektakulär: Während eines Wartungsvorgangs werden Kalibrierparameter über die Service-Software verändert. Technisch ist das möglich, organisatorisch ist es vorgesehen – nur nicht unbefugt.
Ein realistischer Angriffspfad erfordert:
- physischen Zugriff auf Gerät oder Service-PC,
- Kenntnisse der Service-Software,
- Schreibzugriff auf die Kalibrierfunktion.
Es handelt sich nicht um ein Remote- oder Massenangriffsszenario. Der Aufwand ist vergleichsweise hoch, der Angreiferkreis klein.
Die Eintrittswahrscheinlichkeit wird daher als niedrig eingeschätzt.
Beispiel 1 - Phase 3: Risikobewertung und -behandlung
Trotz niedriger Eintrittswahrscheinlichkeit ist die Schadensauswirkung hoch:
- Qualitätsabweichungen bleiben unentdeckt,
- Messergebnisse verlieren ihre Aussagekraft,
- Haftungs- und Reputationsrisiken entstehen.
Das Gesamtrisiko wird daher als hoch bewertet. Nicht wegen der Bedrohung, sondern wegen der Wirkung.
Als Maßnahmen werden festgelegt:
- rollenbasierte Rechte in der Service-Software,
- Protokollierung von Änderungen an Kalibrierparametern,
- Plausibilitätsprüfungen beim Gerätestart.
Ein Restrisiko bleibt bestehen, wird aber bewusst akzeptiert, da Manipulationen nun gezielt, nachvollziehbar und detektierbar sind.
Beispiel 2: Unautorisierter Lesezugriff auf Diagnosedaten
Beispiel 2 - Phase 1: Identifikation & Kontextanalyse
Im zweiten Szenario betrachten wir Diagnose- und Statusinformationen, die das Gerät lokal bereitstellt. Dazu gehören Laufzeiten, Temperaturwerte oder einfache Statuscodes.
Der Schutzbedarf ist gering:
- Die Daten sind nicht vertraulich.
- Ihre Integrität hat keinen Einfluss auf Messergebnisse.
- Ein Verlust der Verfügbarkeit ist unkritisch.
Beispiel 2 - Phase 2: Analyse von Bedrohungen und Risiken
Der Zugriff auf diese Informationen ist technisch einfach möglich. Eine lokale Schnittstelle erlaubt das Auslesen ohne Authentisierung.
Die Eintrittswahrscheinlichkeit ist entsprechend hoch:
- geringer technischer Aufwand,
- kein Spezialwissen notwendig.
Beispiel 2 - Phase 3: Risikobewertung und -behandlung
Trotz hoher Eintrittswahrscheinlichkeit sind die Auswirkungen gering. Ein unautorisierter Lesezugriff auf Diagnosedaten hat keine sicherheits- oder compliance-relevanten Folgen.
Das Risiko wird daher als niedrig bewertet.
Als Maßnahme reicht eine einfache Dokumentation des Zugriffs. Auf aufwendige Schutzmechanismen wird bewusst verzichtet, um das System nicht unnötig zu verkomplizieren.
Was dieses Beispiel zeigt
Diese beiden Szenarien machen den Kern von TARA deutlich und zeigen, wie die einzelnen Methoden und Werkzeuge helfen können. Sie verdeutlichen, dass Risiko ist nicht gleich Bedrohung ist, eine niedrige Eintrittswahrscheinlichkeit ein Risiko nicht automatisch akzeptabel macht und eine hohe Eintrittswahrscheinlichkeit nicht automatisch kritisch ist.
Entscheidend ist immer die Auswirkung auf das Produkt und seinen Zweck.
Genau diese Logik fordert der Cyber Resilience Act. Nicht maximale Absicherung, sondern nachvollziehbare, risikobasierte Entscheidungen.
Fazit
Eine gute Cybersecurity-Risikobewertung erkennt man nicht an komplexen Modellen oder spezialisierten Tools, sondern daran, dass Entscheidungen logisch hergeleitet und verständlich begründet sind. Das TARA-Framework hilft dabei, diese Struktur herzustellen – gerade in Fällen, in denen Bauchgefühl oder Checklisten in die falsche Richtung führen würden.
Wer Risiken konsequent entlang von Kontext, Angriffspfad und Auswirkung bewertet, schafft nicht nur CRA-Konformität, sondern trifft auch bessere technische Entscheidungen. Und genau darum geht es in der Praxis.
