TARA - Threat Analysis and Risk Assessment

Bedrohungsanalyse und Risikobeurteilung

Lesezeit: 6 Min.

Was bedeutet TARA?

Eine TARA ist eine strukturierte Methode, um Bedrohungen für ein System zu identifizieren und die damit verbundenen Risiken zu bewerten.

TARA (Threat Analysis and Risk Assessment) ist eine systematische Methode, um Bedrohungen für ein System oder Produkt zu identifizieren, ihre Auswirkungen zu bewerten und geeignete Schutzmaßnahmen abzuleiten. Der Prozess folgt typischerweise einer festen Schrittfolge: Systemabgrenzung und Scoping, Identifikation schützenswerter Assets, Bedrohungsmodellierung (z. B. mit STRIDE), Risikobewertung anhand von Eintrittswahrscheinlichkeit und Schadenspotenzial, sowie Definition und Nachverfolgung von Maßnahmen. Das Ergebnis ist ein dokumentiertes Risikoregister, das als Nachweis gegenüber Zertifizierungsstellen und Behörden dient.

TARA-Schritte im Überblick

Eine TARA durchläuft typischerweise fünf Phasen:

Scope: Systemgrenzen, Komponenten und Datenflüsse definieren;
Assets: schützenswerte Werte wie Schlüssel, Konfigurationsdaten oder Sicherheitsfunktionen identifizieren;
Threats: Bedrohungsszenarien ableiten, häufig mit STRIDE als Klassifikationsrahmen;
Risk: Risiken nach Wahrscheinlichkeit und Auswirkung bewerten und priorisieren;
Measures: Mitigationsmaßnahmen festlegen, verantworten und verfolgen.

TARA-Pflicht nach IEC 62443 und EU CRA

IEC 62443-4-1 fordert eine TARA als Teil des Secure Development Lifecycle (SDL) für industrielle Komponenten. Der EU Cyber Resilience Act (CRA, EU 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen, eine Cybersicherheits-Risikobeurteilung durchzuführen und zu dokumentieren. ISO/SAE 21434 schreibt die TARA für automotive Cybersecurity (TARA nach Annex G) vor. In allen drei Regelwerken ist die TARA kein einmaliges Dokument, sondern muss über den gesamten Produktlebenszyklus aktuell gehalten werden.

TARA und Bedrohungsmodellierung

Threat Modeling (Bedrohungsmodellierung) ist der kreative Teil einer TARA: das systematische Durchdenken von Angriffsszenarien auf Basis der Systemarchitektur. STRIDE ist dabei das verbreitetste Klassifikationsframework. Moderne Tools ermöglichen es, das Systemmodell visuell zu erstellen und daraus automatisch Bedrohungsvorschläge zu generieren, was den Einstieg auch für Teams ohne dedizierte Security-Experten erleichtert.

Der Unterschied in einem Satz: Threat Modeling identifiziert Bedrohungen, die TARA bewertet sie zusätzlich und leitet daraus verbindliche Maßnahmen ab. Threat Modeling ist damit ein Baustein der TARA, nicht ihr Ersatz.

Die fünf TARA-Schritte im Detail

Scope und Systemabgrenzung: Im ersten Schritt wird festgelegt, welches Produkt oder Teilsystem betrachtet wird, wo die Systemgrenze verläuft und welche Schnittstellen nach außen bestehen. Grundlage ist ein Architektur- oder Datenflussdiagramm; ohne dieses Diagramm bleibt jede TARA lückenhaft.

Assets identifizieren: Erfasst wird alles, dessen Verlust, Manipulation oder Offenlegung Schaden anrichtet. Typisch sind kryptografische Schlüssel, Firmware, Konfigurationsdaten, Messwerte, Kundendaten und Sicherheitsfunktionen wie ein Not-Aus. Zu jedem Asset wird notiert, welches Schutzziel gilt: Vertraulichkeit, Integrität oder Verfügbarkeit.

Bedrohungen ableiten: Für jede Komponente und jeden Datenfluss wird geprüft, welche Angriffsszenarien denkbar sind. STRIDE liefert dafür die Kategorien, sodass keine Bedrohungsklasse übersehen wird. Das Ergebnis ist eine Liste konkreter Szenarien, nicht eine Liste abstrakter Gefahren.

Risiken bewerten: Jedes Szenario erhält eine Eintrittswahrscheinlichkeit und ein Schadensausmaß, die zu einem Risikowert verrechnet werden, üblicherweise über eine Risikomatrix. Die Skalen müssen vorab definiert und dokumentiert sein, sonst ist die Bewertung im Audit nicht nachvollziehbar.

Maßnahmen festlegen: Für Risiken oberhalb der Akzeptanzschwelle werden Maßnahmen definiert, mit Verantwortlichem und Termin versehen und im Risikoregister nachverfolgt. Anschließend wird das Restrisiko erneut bewertet und formal akzeptiert.

TARA-Pflicht nach dem EU Cyber Resilience Act

Der CRA verlangt in Anhang I, Teil I, dass Produkte mit digitalen Elementen auf Basis einer Cybersicherheits-Risikobeurteilung entwickelt werden. Diese Risikobeurteilung ist keine Formalität am Projektende: Sie muss die Grundlage der Designentscheidungen sein und über den gesamten Unterstützungszeitraum (in der Regel mindestens fünf Jahre) aktuell gehalten werden. Die Ergebnisse gehören in die technische Dokumentation nach Anhang VII und sind Teil dessen, was eine benannte Stelle oder Marktaufsichtsbehörde einsehen kann.

Für Hersteller heißt das praktisch: Die TARA muss versioniert, mit Datum und Verantwortlichem versehen und bei jeder relevanten Produktänderung fortgeschrieben werden. Eine einmalig erstellte PDF-Datei ohne Aktualisierungshistorie erfüllt die Anforderung nicht.

TARA, Risikoregister und SoA: Wie sie zusammenhängen

Die drei Dokumente werden oft verwechselt, haben aber klar getrennte Rollen. Die TARA ist die Methode und der Analyseprozess: Sie erzeugt die Risiken.

Das Risikoregister ist das Ergebnisdokument: Es hält jedes identifizierte Risiko mit Bewertung, Maßnahme, Verantwortlichem und Status fest und wird laufend gepflegt. Das Statement of Applicability gehört dagegen in die ISO-27001-Welt und begründet, welche der 93 Annex-A-Controls im Unternehmen anwendbar sind.

Entscheidend ist der Bezugspunkt: Eine TARA betrachtet ein Produkt oder System, ein ISMS-Risikoregister nach ISO 27001 betrachtet die Organisation. Wer beides betreibt (etwa ein zertifizierter Hersteller mit CRA-Pflicht) führt in der Regel zwei getrennte Register und verweist an den Schnittstellen aufeinander.

TARA-Beispiel: vernetzter Sensor im Industrieumfeld

Ein Hersteller bringt einen vernetzten Temperatursensor mit Weboberfläche und OTA-Update-Funktion auf den Markt.

Scope: Sensor, Weboberfläche, Update-Server, Funkstrecke.

Assets: Update-Signaturschlüssel, Messwerte, Admin-Zugangsdaten, Firmware.

Szenario: Ein Angreifer im selben Netzsegment spielt eine manipulierte Firmware ein, weil die Update-Signatur nicht geprüft wird. STRIDE-Kategorie: Tampering. Eintrittswahrscheinlichkeit mittel, Schadensausmaß hoch, weil damit die vollständige Kontrolle über das Gerät übernommen wird, Risikowert also hoch.

Maßnahme: Signaturprüfung im Bootloader verankern, Rollback-Schutz ergänzen, Verantwortlicher Firmware-Team, Termin vor Serienfreigabe.

Restrisiko nach Umsetzung: niedrig, akzeptiert durch die Produktverantwortung.

Prüfmaßstab: Genau in dieser Granularität (Szenario, Kategorie, Bewertung, Maßnahme, Restrisiko) erwartet ein Auditor die Einträge. Formulierungen wie „Gefahr durch Hacker, Maßnahme: Sicherheit erhöhen“ sind nicht prüffähig.

Aufwand, Werkzeuge und typische Fehler

Für ein überschaubares Produkt mit klarer Architektur ist eine erste TARA in zwei bis vier Workshop-Tagen machbar, wenn Entwicklung, Produktmanagement und eine sicherheitskundige Person gemeinsam am Tisch sitzen. Der Aufwand steigt weniger mit der Codebasis als mit der Zahl der Schnittstellen. Als Werkzeug reicht anfangs eine strukturierte Tabelle; entscheidend ist nicht das Werkzeug, sondern dass Skalen, Datum und Verantwortliche festgehalten werden. Typische Fehler:

Die Systemgrenze wird nicht sauber gezogen, sodass unklar bleibt, was überhaupt betrachtet wurde.
Es werden Bedrohungen statt Szenarien notiert: „Malware“ ist keine Bedrohung, „Schadcode gelangt über den ungeprüften USB-Serviceport auf die Steuerung“ schon.
Die Bewertungsskala wird nicht dokumentiert, wodurch die Einstufungen im Audit beliebig wirken.
Die TARA wird nach dem Release nie wieder angefasst, obwohl CRA und IEC 62443 ausdrücklich eine Fortschreibung über den Lebenszyklus verlangen.

Praxis-Tool

Erfasse deine Bedrohungsanalyse als strukturiertes Risikoregister nach ISO 27001

Zum Risikoregister →

Auch bekannt als

Threat Analysis · Risikobeurteilung · Bedrohungsanalyse · Cybersecurity Risk Assessment · TARA-Analyse · Threat Analysis and Risk Assessment

Teil des Themenbereichs: Compliance & Regulierung

Quellen

Zuletzt aktualisiert: 2026-08-02

Häufige Fragen zu TARA

Was ist eine TARA nach dem Cyber Resilience Act?

Der CRA verlangt in Anhang I eine Cybersicherheits-Risikobeurteilung für jedes Produkt mit digitalen Elementen. Die TARA ist die in der Industrie etablierte Methode, um diese Anforderung zu erfüllen: Sie identifiziert Bedrohungen, bewertet die Risiken und leitet Maßnahmen ab. Die Ergebnisse gehören in die technische Dokumentation nach Anhang VII und müssen über den gesamten Unterstützungszeitraum aktuell gehalten werden.

Was ist der Unterschied zwischen TARA und Threat Modeling?

Threat Modeling ist das systematische Identifizieren von Bedrohungsszenarien anhand der Systemarchitektur, meist mit STRIDE als Raster. Die TARA umfasst diesen Schritt, geht aber darüber hinaus: Sie bewertet die gefundenen Bedrohungen nach Wahrscheinlichkeit und Schadensausmaß und leitet verbindliche, nachverfolgte Maßnahmen ab. Threat Modeling ist also ein Baustein der TARA.

Wer muss eine TARA durchführen?

Verpflichtet sind Hersteller von Produkten mit digitalen Elementen nach dem EU Cyber Resilience Act, Hersteller industrieller Automatisierungskomponenten nach IEC 62443-4-1 sowie Automobilzulieferer und -hersteller nach ISO/SAE 21434. Betreiber und reine Anwender brauchen keine produktbezogene TARA. Für sie ist das organisationsbezogene Risikomanagement nach ISO 27001 oder NIS-2 der richtige Rahmen.

Wie oft muss eine TARA aktualisiert werden?

Es gibt keine feste Frist, aber alle drei Regelwerke verlangen eine Fortschreibung über den Produktlebenszyklus. In der Praxis bedeutet das: bei jeder wesentlichen Architektur- oder Funktionsänderung, bei neuen Schnittstellen, nach sicherheitsrelevanten Vorfällen und ergänzend in einem festen Turnus, üblicherweise jährlich. Jede Fortschreibung sollte mit Datum und Verantwortlichem dokumentiert sein.

Was kostet eine TARA?

Bei interner Durchführung liegt der Aufwand für ein überschaubares Produkt bei etwa zwei bis vier Workshop-Tagen mit drei bis fünf Beteiligten, plus Dokumentationszeit. Ausschlaggebend ist weniger der Codeumfang als die Zahl der Schnittstellen und Betriebsarten. Externe Begleitung lohnt sich vor allem bei der ersten TARA, um Methodik und Bewertungsskalen festzulegen, die Fortschreibung gelingt danach meist eigenständig.

Reicht eine TARA für ISO 27001 aus?

Nein. Eine TARA betrachtet ein Produkt oder System, ISO 27001 verlangt eine Risikobeurteilung für die gesamte Organisation nach Kapitel 6.1.2, einschließlich Prozessen, Personal und Standorten. Beide ergänzen sich: Ein Hersteller mit ISMS führt typischerweise ein organisationsbezogenes Risikoregister und je Produkt eine eigene TARA und verweist an den Schnittstellen wechselseitig darauf.

Welche Methode nutzt eine TARA zur Risikobewertung?

Am verbreitetsten ist die Bewertung über Eintrittswahrscheinlichkeit und Schadensausmaß in einer Risikomatrix, häufig auf einer drei- bis fünfstufigen Skala. ISO/SAE 21434 beschreibt in Annex G ein detaillierteres Verfahren mit Angriffspotenzial-Bewertung. Entscheidend für die Prüffähigkeit ist nicht die Wahl der Methode, sondern dass die Skalen und Akzeptanzschwellen vorab definiert und dokumentiert sind.