Cybersecurity-Risikobewertung in der Praxis: Eine Einführung

Die Cybersecurity-Risikobewertung ist das Herzstück des Cyber Resilience Act (CRA). Jeder Hersteller von Produkten mit digitalen Elementen muss nachweisen können, dass er Cyber-Bedrohungen systematisch analysiert, bewertet und behandelt hat.

Das klingt zunächst nach klassischem Risikomanagement, ist aber in der Praxis eine ganz eigene Disziplin: Es geht um Angriffswege, Bedrohungsszenarien und technische Schwachstellen, nicht um klassische Sicherheits- oder Zuverlässigkeitsthemen.

Doch wie nähert man sich so einer Analyse strukturiert, ohne im Methoden-Wirrwarr zu versinken? Hier kommt TARA ins Spiel.

🧩 Was ist TARA eigentlich?

TARA steht für “Threat Analysis and Risk Assessment”, also Bedrohungsanalyse und Risikobewertung.
Es handelt sich dabei nicht um eine einzelne Methode, sondern um einen Framework-Ansatz, welcher die Schritte und Struktur beschreibt, mit der man Risiken im Bereich der Cybersicherheit systematisch identifiziert und bewertet.

Ein TARA-Prozess umfasst dabei folgende Phasen:

1. Identifikation & Kontextanalyse
2. Analyse von Bedrohungen und Risiken
3. Risikobewertung und -behandlung

TARA ist also der methodische Rahmen. Die eigentliche Arbeit geschieht mit konkreten Werkzeugen wie STRIDE, PASTA, Attack Trees oder FMEA. Diese Methoden füllen die einzelnen Prozessschritte mit Leben.

Phase 1: Identifikation & Kontextanalyse

Am Anfang steht das Verständnis des Systems und seines Schutzbedarfs. Dazu gehören zwei Aufgaben:

1. Identifikation von Assets: Welche Daten, Funktionen oder Komponenten sind schützenswert? Das können Steuerbefehle, Firmware, Benutzerkonten oder Kommunikationsschnittstellen sein.
2. Identifikation von Bedrohungsszenarien: Welche Angriffe könnten diese Assets gefährden, und unter welchen Bedingungen?

Salopp gesprochen, ist das Ziel dieser Phase der Aufbau des notwendigen Verständnisses, um am Ende überhaupt eine Bewertung treffen zu können. Zur Identifikation der relevanten Assets, können bestehende Unterlagen und Dokumentation herangezogen werden. Besonders hilfreich sind hierbei Systemübersichten, Architekturdiagramme und Datenflussmodellierungen. Aber auch Assetbeschreibungen von Zulieferern können hier hilfreich sein, denn es wäre z.b. fatal, wenn sie eine an der zugekauften PLC vorhandene serielle Schnittstelle bei der Risikobewertung übersehen, nur weil in ihrer Systemarchitektur serielle Schnittstellen keine Rolle spielen.

Darüber hinaus können Methoden wie STRIDE und PASTA helfen, Bedrohungen systematisch zu erfassen. Auch existierende Bedrohungskataloge wie MITRE ATT&CK oder die elementaren Gefährdungen aus dem BIS Grundschutz helfen, einen schnelleren Überblick zu erlangen.

Phase 2: Analyse von Bedrohungen und Risiken

In Phase 2 geht es darum, die identifizierten Assets und Bedrohungsszenarien systematisch zu analysieren. Während Phase 1 vor allem das Was und Wo klärt, beantwortet Phase 2 das Wie: Wie genau kann ein Angriff ablaufen? Welche Angriffspfade sind realistisch? Welche technischen Schwachstellen werden dabei ausgenutzt?

Hier kommen Methoden wie STRIDE, PASTA und insbesondere Attack Trees ins Spiel. Sie helfen dabei, abstrakte Bedrohungen in konkrete Angriffsszenarien zu überführen. Aus einer Aussage wie „Manipulation von Prozessdaten“ wird so eine nachvollziehbare Angriffskette, etwa bestehend aus Einstiegspunkt, Rechteerlangung und eigentlicher Manipulation.

Wichtig ist dabei: In dieser Phase wird noch nicht bewertet, ob ein Risiko akzeptabel ist oder nicht. Ziel ist vielmehr, ein möglichst vollständiges und realistisches Bild der Bedrohungslage zu erzeugen. Gerade bei komplexen Produkten mit mehreren Schnittstellen oder sicherheitskritischen Funktionen ist das entscheidend, um spätere Fehleinschätzungen zu vermeiden.

Ein typischer Fehler in der Praxis ist es, diese Phase zu verkürzen oder zu überspringen und direkt zu Bewertungen zu springen. Das führt oft dazu, dass Risiken entweder über- oder unterschätzt werden, weil Angriffspfade nicht sauber durchdacht wurden. Eine gründliche Bedrohungsanalyse ist daher die Voraussetzung für jede belastbare Risikobewertung im Sinne des CRA.

Phase 3: Risikobewertung und -behandlung

Erst in Phase 3 werden die analysierten Bedrohungen bewertet und behandelt. Auf Basis der zuvor identifizierten Angriffspfade wird nun eingeschätzt, wie wahrscheinlich ein Angriff ist und welche Auswirkungen er hätte. Diese Bewertung kann qualitativ oder semiquantitativ erfolgen, entscheidend ist weniger die Skala als die Nachvollziehbarkeit der Entscheidung.

Der Cyber Resilience Act verlangt dabei keine Eliminierung jedes denkbaren Risikos, sondern eine risikobasierte Herangehensweise. Das bedeutet konkret: Für jedes relevante Risiko muss klar dokumentiert sein, ob und wie es behandelt wird. Typische Optionen sind technische Maßnahmen (z. B. Härtung, Authentifizierung, Signaturprüfungen), organisatorische Maßnahmen (z. B. Prozesse, Rollen, Schulungen) oder – bewusst und begründet – die Akzeptanz eines Restrisikos.

Attack Trees leisten in dieser Phase einen besonders wertvollen Beitrag. Sie zeigen nicht nur, dass ein Risiko existiert, sondern auch, an welcher Stelle eine Maßnahme den Angriff unterbricht. Dadurch lassen sich Maßnahmen priorisieren und technisch begründen, statt sie pauschal oder checklistengetrieben festzulegen.

Das Ergebnis dieser Phase ist keine theoretische Bewertung, sondern eine konkrete Entscheidungsgrundlage: Welche Maßnahmen werden umgesetzt, welche Risiken bleiben bestehen und warum. Genau diese Transparenz ist es, die der CRA fordert – und die im Ernstfall gegenüber Auditoren, Kunden oder Behörden den Unterschied macht.

Werkzeuge

STRIDE – der Klassiker der Bedrohungsanalyse

STRIDE wurde bei Microsoft entwickelt und zählt heute zu den etabliertesten Methoden für Bedrohungsanalysen. Das Modell unterteilt mögliche Angriffe in sechs Kategorien: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege. Diese Struktur hilft, Bedrohungen systematisch und nachvollziehbar zu erfassen.

STRIDE bietet einen klaren Rahmen, um jede Systemkomponente auf potenzielle Schwachstellen zu überprüfen. Die Methode ist besonders nützlich für Teams, die einen wiederholbaren, praxisnahen Ansatz suchen. Sie kann mit spezialisierten Plattformen wie Threat Modeler oder visuellen Werkzeugen wie dem Microsoft Threat Modeling Tool oder OWASP Threat Dragon umgesetzt werden. Häufig finden sich aber auch weniger integrierte Ansätze auf Basis einfacher Diagrammen aus Visio oder DrawIO.

Der nachfolgende Screenshot zeigt das Microsoft Threat Modeling Tool in Aktion. Im oberen Bereich ist das Systemdiagramm zu sehen, das die betrachtete Architektur visualisiert, in diesem Fall mit Nutzer, Web Application, Sicherheitskomponenten und Datenbank sowie den jeweiligen Vertrauensgrenzen und Datenflüssen. Auf Basis dieses Modells generiert das Tool automatisch potenzielle Bedrohungen nach dem STRIDE-Schema. Diese werden im mittleren Bereich als Threat-Liste dargestellt. Ein einzelner Eintrag ist ausgewählt und wird dadurch auch im Diagramm hervorgehoben. Im unteren Bereich sieht man die Detailansicht dieses konkreten Threats: inklusive Kategorie, Beschreibung, betroffener Interaktion, Priorität und Risikoeinschätzung. Der Screenshot verdeutlicht gut, wie Diagramm, systematische Bedrohungsidentifikation und detaillierte Analyse in einem Werkzeug zusammengeführt werden und so eine strukturierte, nachvollziehbare Bedrohungsanalyse unterstützen.

PASTA – der Angreifer denkt mit

PASTA (Process for Attack Simulation and Threat Analysis) stammt aus der Unternehmens- und Anwendungssicherheit und setzt stärker auf die Perspektive des Angreifers. Der Prozess besteht aus sieben klar definierten Phasen, die von der Geschäfts- und Risikoanalyse bis zur Simulation realistischer Angriffsszenarien reichen.

PASTA verbindet im Gegensatz zu STRIDE die technische Analyse mit einer Bewertung der geschäftlichen Auswirkungen. Dadurch entsteht ein Gesamtbild, das technische Schwachstellen in ihrem unternehmerischen Kontext sichtbar macht und so hilft, Prioritäten richtig zu setzen. In der Praxis wird PASTA häufig mit Tools wie ThreatPlaybook oder strukturierten Vorlagen in Excel und Confluence umgesetzt. In Kombination mit MITRE ATT&CK lassen sich damit realistische Angriffsketten modellieren, die zeigen, wie ein Angreifer tatsächlich vorgehen könnte.

Attack Trees – Angriffe verständlich, strukturiert und prüfbar machen

Attack Trees sind ein äußerst praxisnahes Werkzeug, um Cyberangriffe systematisch und nachvollziehbar zu analysieren. Sie eignen sich besonders dort, wo klassische Listen oder Risikomatrizen an ihre Grenzen stoßen, also bei sicherheitskritischen Funktionen, komplexen Systemarchitekturen und der Frage, welche technischen Maßnahmen wirklich wirksam sind.

Der Ausgangspunkt eines Attack Trees ist immer ein klar definiertes Angriffsziel, etwa die Manipulation von Prozessdaten, der unbefugte Zugriff auf eine Steuerung oder das Einschleusen manipulierter Firmware. Von diesem Ziel aus wird der Angriff schrittweise in Teilziele und konkrete Aktionen zerlegt. Diese stehen in einer logischen Beziehung zueinander: Manche Schritte müssen gemeinsam erfüllt sein (UND), andere stellen alternative Wege dar (ODER).

Genau diese Struktur ist der große Mehrwert von Attack Trees. Sie zwingen dazu, Annahmen explizit zu machen: Was muss ein Angreifer zuerst erreichen? Wo braucht er Schreibrechte? Welche Zwischenschritte sind realistisch? Aus vagen Bedrohungen werden so konkrete Angriffspfade, die technisch überprüfbar sind.

In der Praxis zeigen Attack Trees ihre Stärke besonders bei sicherheitskritischen Funktionen wie Update-Mechanismen, Authentifizierung oder Fernwartung. Ein erfolgreicher Angriff auf diese Komponenten hat meist weitreichende Folgen. Attack Trees helfen hier, nicht nur das Risiko zu benennen, sondern sauber herzuleiten, welche Voraussetzungen ein Angriff wirklich hat und an welcher Stelle er am effektivsten unterbrochen werden kann. Oft wird dabei sichtbar, dass eine scheinbar wichtige Maßnahme nur einen einzelnen Pfad blockiert, während eine andere Maßnahme mehrere Angriffsketten gleichzeitig unterbricht.

Ein weiterer typischer Anwendungsfall sind komplexe Produkte mit vielen Schnittstellen, wie Maschinen oder Laborgeräte mit Ethernet, Feldbussen, USB und Protokollen wie OPC UA. In solchen Systemen entstehen Angriffe selten über eine einzelne Schnittstelle, sondern über Kombinationen. Attack Trees machen genau diese Ketten sichtbar, etwa den Einstieg über einen physischen Wartungsport und die spätere Manipulation von Prozessdaten über eine Netzwerkverbindung. Ohne diese Sichtweise werden Risiken häufig isoliert betrachtet und genau dort entstehen blinde Flecken.

Nicht zuletzt sind Attack Trees hilfreich bei der Ableitung technischer Maßnahmen aus der Risikoanalyse. Sie liefern eine saubere Begründung dafür, warum eine Maßnahme notwendig ist und welche Angriffspfade sie tatsächlich adressiert. Das ist nicht nur für Entwickler hilfreich, sondern auch für Management, Audits und den Nachweis der Sorgfaltspflicht im Sinne des Cyber Resilience Act. Statt pauschaler Aussagen entsteht eine klare Argumentationslinie: Diese Angriffspfade haben wir betrachtet, an diesen Stellen greifen unsere Maßnahmen, diese Restrisiken akzeptieren wir bewusst.

Wichtig ist dabei: Attack Trees sind aufwändig. Ihre Stärke liegt in der Tiefe. Sie ergänzen Methoden wie STRIDE. Richtig eingesetzt ergänzen sie den TARA-Prozess ideal überall dort, wo man Angriffe wirklich verstehen, Maßnahmen priorisieren und Entscheidungen belastbar dokumentieren muss.

Praxistipp: Für die Modellierung von Attack Trees kann auf Formate wir DrawIO oder PlantUML zurückgegriffen werden. Diese lassen sich leicht in die Versionskontrollsysteme einbinden und sind sowohl vom Mensch als auch von Maschinen (z.B. AI Tools wie GitHub Copilot, Google Gemini, ChatGPT oder Claude) les- und editierbar.

FMEA – systematisch denken, Schwachstellen früh erkennen

Die Failure Mode and Effects Analysis (FMEA) stammt ursprünglich aus der Sicherheits- und Zuverlässigkeitsbetrachtung, hat sich aber auch im Kontext der Cybersicherheit als wertvolles Werkzeug etabliert. Besonders dort, wo Produkte technisch komplex sind und stark aus Komponenten, Schnittstellen und Zuständen bestehen, hilft FMEA dabei, Risiken strukturiert und vollständig zu erfassen.

Im Unterschied zu angreiferzentrierten Methoden wie Attack Trees nähert sich FMEA dem Thema aus einer anderen Perspektive: Sie fragt nicht primär, wie ein Angreifer vorgeht, sondern was im System schiefgehen kann – und welche Auswirkungen das hätte. Ausgangspunkt sind einzelne Funktionen, Komponenten oder Schnittstellen, für die mögliche Fehlermodi identifiziert werden. Im Cybersecurity-Kontext können das etwa fehlerhafte Zugriffskontrollen, unerwartete Zustandswechsel, inkonsistente Konfigurationen oder Ausfälle sicherheitsrelevanter Mechanismen sein.

Ein großer Vorteil der FMEA ist ihre hohe Praxistauglichkeit. In vielen Unternehmen kommt dafür kein spezialisiertes Tool zum Einsatz. Stattdessen werden FMEAs ganz bewusst mit einfachen Mitteln durchgeführt, etwa in Excel, Google Sheets oder als tabellarische Markdown-Dokumente in einem Git-Repository oder Wiki. Diese Formate sind leicht zugänglich, gut versionierbar, auditfähig und für interdisziplinäre Teams verständlich. Gerade im CRA-Kontext ist das oft völlig ausreichend – entscheidend ist die saubere Struktur und die nachvollziehbare Dokumentation, nicht das eingesetzte Werkzeug.

Wer größere Systeme, viele Varianten oder eine enge Verzahnung mit Anforderungen und Maßnahmen managen möchte, kann auf spezialisierte FMEA-Tools zurückgreifen. In der Industrie sind hier unter anderem Lösungen von Siemens oder peakAvenue verbreitet. Diese bieten Funktionen wie Wiederverwendung von Fehlermodi, zentrale Datenhaltung und bessere Skalierbarkeit – sind aber kein Muss für eine CRA-konforme Risikoanalyse.

Wichtig ist die richtige Einordnung: FMEA ersetzt keine angreiferzentrierte Analyse. Sie beantwortet sehr gut die Frage, wo das System verwundbar ist, aber nur eingeschränkt, wie ein Angriff tatsächlich ablaufen würde. In der Praxis entfaltet sie ihre größte Wirkung daher in Kombination mit Methoden wie Attack Trees oder STRIDE. Während die FMEA für Breite und Vollständigkeit sorgt, liefern diese Methoden die notwendige Tiefe.

Richtig eingesetzt ist FMEA damit ein wirkungsvolles Werkzeug im TARA-Prozess – insbesondere, um Risiken frühzeitig zu erkennen, sauber zu dokumentieren und eine solide, CRA-konforme Basis für die weitere Risikobewertung zu schaffen.

Ausführliches FMEA-Template

Erläuterung der FMEA-Spalten:

• ID: Eindeutige Kennzeichnung des FMEA-Eintrags zur Referenzierung in Reviews, Maßnahmenlisten und Audits.

• System / Funktion: Die betrachtete Systemkomponente oder Funktion, z. B. Firmware-Update, OPC-UA-Kommunikation oder Benutzerverwaltung.

• Asset: Das schützenswerte Gut innerhalb der Funktion, etwa Steuerbefehle, Konfigurationsdaten, Firmware, Zugangsdaten oder Messwerte.

• Fehlermodus (Failure Mode): Beschreibung dessen, was schiefgehen kann, bewusst angriffsneutral formuliert, z. B. „Unbefugter Schreibzugriff möglich“.

• Ursache: Technische oder konzeptionelle Ursache des Fehlermodus, z. B. Fehlkonfiguration, fehlende Zugriffskontrollen oder unsichere Default-Einstellungen.

• Auswirkung: Konsequenz des Fehlermodus auf System, Produkt oder Nutzer, etwa Prozessmanipulation, Integritätsverlust von Messergebnissen oder Betriebsstillstand.

• Sicherheitsziel (C/I/A): Betroffenes Schutzziel nach Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability); Mehrfachnennungen sind möglich.

• Angriffsvektor / Bedrohung: Typischer Angriffsweg oder Bedrohungskontext, z. B. Netzwerkzugriff, physischer Zugriff, Wartungsschnittstelle oder Missbrauch legitimer Nutzerrechte; optional mit Referenz auf STRIDE oder MITRE ATT&CK.

• Bestehende Maßnahmen: Bereits implementierte technische oder organisatorische Schutzmaßnahmen, die den Fehlermodus verhindern, erschweren oder detektieren.

• Eintrittswahrscheinlichkeit: Qualitative Einschätzung (z. B. niedrig, mittel, hoch), wie wahrscheinlich das Auftreten des Fehlermodus ist, mit nachvollziehbarer Begründung.

• Schadensauswirkung: Qualitative Bewertung der Auswirkungen im Schadensfall (z. B. niedrig, mittel, hoch), etwa auf Sicherheit, Betrieb, Compliance oder Reputation.

• Risiko: Gesamtrisikoeinschätzung auf Basis von Eintrittswahrscheinlichkeit und Schadensauswirkung zur Priorisierung.

  Eintritt \ Schaden	niedrig	mittel	hoch
  niedrig	niedrig	niedrig	mittel
  mittel	niedrig	mittel	hoch
  hoch	mittel	hoch	hoch

• Geplante Maßnahmen: Zusätzliche technische oder organisatorische Maßnahmen zur Risikoreduktion, z. B. Härtung, Authentifizierung, Monitoring oder Prozessanpassungen.

• Restrisiko: Verbleibendes Risiko nach Umsetzung der geplanten Maßnahmen, das weiterhin bewusst akzeptiert oder beobachtet wird.

• Entscheidung / Begründung: Dokumentierte Entscheidung zum Umgang mit dem Risiko (reduzieren, akzeptieren, vermeiden) inklusive Begründung – besonders relevant für den CRA-Nachweis.

Hier können Sie das Template als Excel-Datei herunterladen.

Fazit

Cybersecurity-Risikobewertung ist im Kontext des Cyber Resilience Act keine akademische Pflichtübung, sondern der zentrale Mechanismus, um Security by Design nachvollziehbar umzusetzen. Der CRA verlangt dabei keine perfekte Sicherheit und keine bestimmten Methoden, sondern eine klare, begründete und dokumentierte Auseinandersetzung mit realistischen Bedrohungen.

Das TARA-Framework bietet dafür den notwendigen Rahmen. Es hilft, Struktur in das Thema zu bringen und verhindert, dass Teams entweder im Methodendschungel stecken bleiben oder Risiken zu früh pauschal bewerten. Methoden wie STRIDE und PASTA unterstützen bei der systematischen Identifikation von Bedrohungen, Attack Trees schaffen Tiefe bei kritischen Szenarien, und FMEA sorgt für Vollständigkeit und Anschlussfähigkeit an bestehende Entwicklungs- und Qualitätsprozesse.

Entscheidend ist nicht, welche Methode eingesetzt wird, sondern wie konsequent und nachvollziehbar sie angewendet wird. Eine sauber dokumentierte Risikoanalyse in Excel, Markdown oder einfachen Diagrammen ist regulatorisch wertvoller als ein komplexes Toolset ohne klare Argumentationslinie. Gerade im CRA-Kontext zählt, dass Risiken verstanden, priorisiert und bewusst behandelt werden – inklusive der Entscheidung, bestimmte Restrisiken zu akzeptieren.

Wer Cybersecurity-Risikobewertung so versteht, schafft nicht nur die Grundlage für CRA-Konformität, sondern auch für bessere Architekturentscheidungen, zielgerichtete Sicherheitsmaßnahmen und belastbare Diskussionen mit Management, Auditoren und Kunden. TARA ist damit kein zusätzlicher Prozess, sondern ein Werkzeug, um vorhandenes Wissen strukturiert nutzbar zu machen.