Die 5 häufigsten Fehler in der Praxis
Revision 1.0
Die Threat Analysis and Risk Assessment (TARA) ist das methodische Herzstück von ISO/SAE 21434. Aus ihr leiten sich Cybersecurity Goals, Claims und letztlich das gesamte Sicherheitskonzept ab. Ist die TARA schwach, wackelt alles, was darauf aufbaut.
In Assessments und Audits sehe ich dieselben Muster immer wieder – nicht bei Teams, die den Standard nicht kennen, sondern bei erfahrenen Organisationen, die unter Termindruck oder aus alter Gewohnheit an entscheidenden Stellen abkürzen. Hier sind die fünf Fehler, die mir in der Praxis am häufigsten begegnen, jeweils mit dem typischen Symptom im Assessment und einem konkreten Gegenmittel.
Fehler 1: Assets zu grob – und ohne Cybersecurity-Eigenschaften
Ein Klassiker aus Clause 15.3. Das Asset heißt „Steuergerät XY“ oder „Gateway“, und damit ist die Asset-Identifikation für das Team erledigt. Was fehlt, ist die Betrachtungsebene, auf der Cybersecurity tatsächlich stattfindet: konkrete Datenobjekte, Funktionen und Kommunikationsbeziehungen, jeweils mit den betroffenen Cybersecurity-Eigenschaften (Confidentiality, Integrity, Availability, bei Bedarf Authenticity und Non-Repudiation).
Symptom im Assessment: Die Damage Scenarios lassen sich nicht sauber aus den Assets herleiten, weil die Assets zu abstrakt sind. Man merkt es daran, dass für ein „Asset“ plötzlich drei völlig unterschiedliche Schadensbilder aufgemacht werden – ein sicheres Zeichen dafür, dass hier eigentlich mehrere Assets stecken.
Was hilft: Assets auf der Ebene von Daten und Funktionen führen und jedem Asset explizit die relevanten Cybersecurity Properties zuordnen. Erst diese Property-Zuordnung macht die Ableitung der Damage Scenarios reproduzierbar – und genau das prüft ein Assessor.
Fehler 2: Impact-Bewertung aus der Safety-Welt kopiert
ISO/SAE 21434 verlangt in Clause 15.5 eine Impact-Bewertung über vier Kategorien: Safety, Financial, Operational und Privacy (S/F/O/P). In der Praxis wird häufig nur die Safety-Dimension ernst genommen, oft, weil dieselben Leute aus der ISO-26262-Welt kommen und den ASIL gedanklich 1:1 als Impact übernehmen.
Symptom im Assessment: Die Financial-, Operational- und Privacy-Spalten sind entweder leer, durchgängig „low“ oder erkennbar nur pro forma gefüllt. Bei einem reinen Datenschutz- oder Reputationsschaden ohne Safety-Bezug kippt die ganze Bewertung – weil das Bewertungsmodell die Kategorie nie wirklich beherrscht hat.
Was hilft: Alle vier Kategorien mit eigenen, dokumentierten Kriterien bewerten. Safety-Input ist wertvoll, aber er ersetzt die anderen drei Dimensionen nicht. Wer S/F/O/P ernst nimmt, findet regelmäßig relevante Risiken, die eine rein safety-getriebene Sicht komplett übersieht.
Fehler 3: Attack Feasibility geschätzt statt methodisch hergeleitet
Die Attack Feasibility Rating (Clause 15.7) ist die Stelle, an der am meisten „aus dem Bauch“ bewertet wird. Ein „mittel“ hier, ein „hoch“ dort, ohne nachvollziehbare Methode. Der Standard bietet dafür drei anerkannte Ansätze an: attack-potential-based, CVSS-based und attack-vector-based. Genutzt wird oft keiner davon konsequent.
Symptom im Assessment: Vergleichbare Angriffe erhalten über verschiedene Threat Scenarios hinweg unterschiedliche Feasibility-Werte, ohne dass ein sachlicher Grund erkennbar ist. Dazu tendiert die Bewertung systematisch nach unten – der Angreifer wird unterschätzt, die Risiken werden kleingerechnet.
Was hilft: Sich für eine Methode entscheiden und sie durchhalten. Beim attack-potential-based approach bedeutet das: Elapsed Time, Expertise, Knowledge of the Item, Window of Opportunity und Equipment sauber und einheitlich bewerten. Die zugrunde liegenden Annahmen gehören dokumentiert, sonst ist die Bewertung weder reproduzierbar noch verteidigbar.
Fehler 4: Keine durchgängige Nachvollziehbarkeit
Jedes einzelne Rating in der TARA braucht eine Begründung, und der rote Faden muss durchgehen: Asset → Damage Scenario → Threat Scenario → Attack Path → Risk Value → Risk Treatment Decision → Cybersecurity Goal/Claim.
In der Praxis stehen die Werte oft nackt in der Tabelle, ohne Rationale und ohne konsistente Verknüpfung über die Work Products hinweg.
Symptom im Assessment: Der Assessor kann nicht rekonstruieren, warum ein Risiko so bewertet wurde, wie es bewertet wurde. Spätestens wenn nachgefragt wird, wird improvisiert, und improvisierte Begründungen widersprechen sich über den Verlauf eines Assessments hinweg fast immer.
Was hilft: Eine konsequente Rationale-Spalte und stabile IDs über den gesamten Work-Product-Verbund. Traceability ist kein Selbstzweck: Sie ist der Unterschied zwischen einer TARA, die man verteidigen kann, und einer, die im Assessment auseinanderfällt.
Fehler 5: TARA als Einmal-Artefakt statt lebendes Dokument
Die TARA wird zu Projektbeginn erstellt, freigegeben und dann eingefroren. Design-Änderungen, neue Schwachstellen aus dem Vulnerability Management (Clause 8) oder Erkenntnisse aus der Post-Development-Phase finden nicht zurück in die Bewertung. Cybersecurity ist aber ausdrücklich als kontinuierliche Aktivität über den gesamten Lebenszyklus angelegt.
Symptom im Assessment: Die TARA trägt ein Datum von vor achtzehn Monaten, während das Design seither dreimal geändert wurde und im Vulnerability Management längst relevante Findings liegen, die nie zurückgespielt wurden. Die TARA beschreibt damit ein Fahrzeug, das es so nicht mehr gibt.
Was hilft: Klare Trigger für ein TARA-Update definieren (Design-Änderung, neue Threat Intelligence, Feldvorfall) und die TARA fest in Change- und Vulnerability-Management-Prozesse einhängen. Eine gute TARA lebt. Sie ist ein Prozess, kein Meilenstein.
.
Fazit
Die meisten TARA-Schwächen sind keine Wissenslücken, sondern Abkürzungen: zu grobe Assets, eine safety-verengte Impact-Sicht, geschätzte Feasibility, fehlende Rationale und eine TARA, die nach der Freigabe stehen bleibt. Jeder dieser fünf Punkte ist mit Disziplin und einer sauberen Methodik vermeidbar – und jeder ist im Assessment sofort sichtbar.
Wenn Sie Ihre TARA-Methodik oder ein konkretes Bewertungsschema vor dem nächsten Assessment auf den Prüfstand stellen möchten: Steinmetz Security Services bietet Unterstützung und Anleitung, Schulungen sowie Advisory-Leistungen rund um ISO/SAE 21434.
Sprechen Sie mich gern an.
Management systems under scrutiny.