Asset Identification und Impact Rating: Wessen Schaden zählt eigentlich?

Die eine Hälfte des Risikos

Nach der Item Definition ist der Reflex in den meisten Projekten, sofort Bedrohungen zu sammeln. Die Norm stellt eine andere Frage voran: was ist hier überhaupt schützenswert, und was kostet es, wenn es kaputtgeht.

Ein Risikowert entsteht in einer Threat Analysis and Risk Assessment (TARA) aus zwei Größen, dem Impact und der Attack Feasibility. Dieser Schritt liefert die erste davon, und damit die halbe Strecke bis zum Risiko. Wie viel die zweite Hälfte danach noch bewegen kann, hängt an der ersten: in der Beispiel-Risikomatrix aus Annex H steht in der Zeile “negligible” über alle vier Feasibility-Stufen hinweg derselbe Wert. Wo der Schaden vernachlässigbar ist, ändert die Angriffsseite am Ergebnis nichts mehr. In den Zeilen darüber ändert sie eine ganze Menge.

Das ist Teil zwei meiner Serie zu den Schritten einer TARA nach ISO/SAE 21434. Teil eins war die Item Definition, der Schritt, der festlegt, was ihr analysiert. In diesem geht es um den Schritt, der festlegt, was auf dem Spiel steht.

Was die Norm verlangt

Die Norm verlangt eine Analyse auf Basis der Item Definition, die unter anderem die Asset Identification nach 15.3 und das Impact Rating nach 15.5 umfasst.

Ein Asset ist in den Worten der Norm ein Objekt von Wert, dessen Sicherheitseigenschaft kompromittiert werden kann: Vertraulichkeit, Integrität, Verfügbarkeit. Ein Schadensszenario beschreibt, welcher Schaden einem Stakeholder entsteht, wenn eine solche Eigenschaft verletzt wird. Die beiden Definitionen zeigen aufeinander. Etwas ist ein Asset, weil es dafür ein Schadensszenario gibt, und ein Schadensszenario braucht ein Asset, über das es spricht.

Wichtig dabei: ein Asset ist nie das Element allein, sondern das Element zusammen mit der Eigenschaft, die geschützt werden soll. Annex H markiert bei der Firmware des Body-Control-Steuergeräts sowohl die Vertraulichkeit als auch die Integrität. Für mich sind das zwei Assets, die sich ein Element teilen, und sie haben wenig miteinander zu tun. Ist die Integrität verletzt, läuft manipulierter Code im Fahrzeug; der Schaden trifft Fahrer und Umgebung und ist ein Safety-Fall. Ist die Vertraulichkeit verletzt, fließt Entwicklungs-Know-how ab; der Schaden trifft den Hersteller, und mit Safety hat er nichts zu tun. Zwei Eigenschaften am selben Element, zwei Stakeholder, zwei Kategorien, am Ende zwei Risiken.

Wer das Paar auftrennt und nur das Element führt, setzt die Eigenschaft implizit auf “alle drei” und merkt es nicht.

Diese Zirkularität ist keine Nachlässigkeit im Normtext, sie ist Bewegungsfreiheit. Annex H stellt ausdrücklich fest, dass sich die Module einer TARA in beliebiger Reihenfolge bearbeiten lassen, und nennt dafür zwei Beispielabläufe: erst die Assets, dann ihre Schadensszenarien, oder erst die Schadensszenarien aus einem Katalog, dann die Assets, die sich daraus ergeben. Beides ist legitim. Bottom-up aus der Architektur heraus geht, top-down entlang einer Liste von Folgen, die dem Unternehmen ohnehin wichtig sind, geht genauso.

Ab wann ist ein Element des Items ein Asset?

Jede Funktion, jede Komponente, jeder Kanal, jeder Datenfluss und jedes Datum der Item Definition ist ein Kandidat. Keines davon ist automatisch ein Asset.

Mein Test dafür ist simpel: bekomme ich diesen Satz zu Ende? Wenn die [Eigenschaft] von [Element] verletzt wird, dann tritt [Folge] für [Stakeholder] ein. Geht er auf, habe ich in einem Zug ein Asset mit einer konkreten Eigenschaft und ein Schadensszenario. Geht er nicht auf, habe ich ein Element der Architektur, und es trotzdem als Asset zu führen bläht die Analyse nur auf.

Am häufigsten begegnet mir ein Muster: die Asset-Liste ist in Wahrheit die Komponentenliste aus der Item Definition. Einmal kopiert, und in jeder Zeile ein Häkchen bei Vertraulichkeit, Integrität und Verfügbarkeit. Ein Häkchen, das überall steht, sagt nichts. Arbeit macht es trotzdem: jedes davon zieht Bedrohungsszenarien nach sich.

Das Scheinwerfer-Beispiel aus Annex H macht es vor. Beim Asset “data communication (lamp request)” ist nur die Integrität markiert, nicht die Vertraulichkeit und nicht die Verfügbarkeit, weil die dort genannten Schadensszenarien davon handeln, dass sich das Licht ungewollt abschaltet. Die Eigenschaft folgt dem Schadensszenario, nicht der Vorsicht. Ob die Vertraulichkeit einer Lichtanforderung irgendwen interessiert, darf man diskutieren. Annex H spart sich die Diskussion und lässt das Häkchen weg.

Interessant ist auch, was dort überhaupt als Asset auftaucht: eine Datenkommunikation und eine Firmware. Kein einziger Steuergeräte-Kasten. Aus meiner Erfahrung sind Datenflüsse und Daten ohnehin häufiger Assets als Komponenten, und das ist der zweite Grund, warum die Komponentenliste ein schlechter Startpunkt ist.

Wessen Schaden zählt?

In der Definition des Schadensszenarios steht ein Stakeholder, und dieses Wort leistet mehr Arbeit, als es aussieht.

Der Stakeholder, auf den die Norm zielt, ist der Road User, also der Verkehrsteilnehmer. Das Impact Rating der ISO 21434 misst in erster Linie, was einem Menschen im Straßenverkehr passiert. Annex H führt das schön vor: bewertet wird dort unter anderem ein Szenario, in dem die Fahrer entgegenkommender Fahrzeuge geblendet werden, weil das Fernlicht nicht mehr auf Abblendlicht zurückschaltet. Diese Leute haben das Auto nie gekauft. Sie sind trotzdem der Maßstab.

Alles darüber hinaus ist freiwillig. Der OEM, für den aus dem Szenario ein Rückruf wird, der Flottenbetreiber mit Standzeiten, der Zulieferer, die betroffene Person im Privacy-Fall: keinen von ihnen verlangt die Norm, verboten sind sie aber auch nicht. Mein Rat wäre trotzdem, sie von Anfang an mitzubewerten.

Das setzt ein Werkzeug voraus, das mehrere Stakeholder nebeneinander trägt, statt euch auf einen festzulegen. In itemis SECURE ist der Stakeholder ein eigenes Objekt, und der Impact Level entsteht gruppiert nach Stakeholder und Kategorie: dasselbe Schadensszenario trägt mehrere Bewertungen nebeneinander, ohne dass ihr die Analyse ein zweites Mal anlegt.

Die Entscheidung, welche Stakeholder ihr betrachtet, nimmt euch das Werkzeug aber nicht ab. Bewertet der eine Analyst nur den Road User und der nächste zusätzlich den Betriebsausfall beim Flottenbetreiber, habt ihr zwei TARAs mit zwei Maßstäben. Die Impact Level darin lassen sich nicht mehr vergleichen, und darunter leidet alles, was darauf aufbaut, von der Portfolio-Sicht bis zu den Nachweisen für den Auditor. Das Unangenehme daran: auffallen wird es nicht. Beide Analysen sehen für sich stimmig aus.

Den Kreis der Stakeholder und die Impact-Kategorien einmal auf Organisationsebene festzulegen und dann wiederzuverwenden, ist die unspektakulärste Qualitätsmaßnahme in diesem ganzen Schritt und vermutlich die mit dem höchsten Ertrag.

Vier Kategorien, vier Stufen, eine Zahl, die Security nicht allein setzt

Der Schaden jedes Schadensszenarios wird in vier Kategorien bewertet, Safety, Financial, Operational und Privacy, auf einer Skala von negligible, moderate, major und severe. Ein Schadensszenario kann in mehreren Kategorien gleichzeitig wirken.

Diese vier sind gesetzt, aber sie sind keine Obergrenze. Wer regulatorische Folgen oder Reputationsschaden getrennt sehen will, ergänzt eine fünfte. Und was bei euch als major zählt und was als severe, schreibt euch niemand vor. Ihr müsst es nur einmal festlegen und euch dann daran halten.

Am Ende muss ein Impact Level herauskommen, ein IL. Aus den Einzelbewertungen über alle Kategorien und Stakeholder wird ein Wert, und erst dieser Wert trifft im Risiko auf die Attack Feasibility. Wie ihr zusammenfasst, ist eure Entscheidung, das Maximum ist der übliche Weg.

Die Safety-Bewertung gehört euch nicht allein. Annex H bewertet die Frontalkollision als severe und schreibt S3 dazu, die Schadensklasse aus der funktionalen Sicherheit. Da steht eine Zahl aus einer anderen Disziplin mitten in eurer Analyse.

Tuma und Widman zählen das zu ihren sieben Schmerzpunkten der TARA-Praxis: eine HARA sieht nur, was von selbst kaputtgeht, einen Angreifer kann sie nicht abbilden. Also müssen Safety und Security sich abstimmen, und das kostet Termine.

Ich würde die Skala lieber einmal gemeinsam festlegen, bevor die erste Kollision bewertet wird. Das Gespräch ist mühsam. Ohne das Gespräch steht am Ende aber eine Safety-Zahl in eurer TARA, die in Safety niemand kennt.

Das Konsistenzproblem

Das Impact Rating ist aus meiner Sicht der subjektivste Schritt der ganzen Methode, und ich halte es für besser, das offen zu sagen, statt es zu kaschieren.

Die Attack Feasibility zerfällt wenigstens in Faktoren: Zeit, Fachwissen, Kenntnis des Items, Gelegenheitsfenster, Ausrüstung. Wer sich darüber streitet, findet heraus, worüber. Beim Impact geht das nicht. Da urteilt jemand über Folgen in der Welt, und zwei Leute, die sich uneinig sind, bleiben es meistens auch. Tuma und Widman nennen genau das als Grund, warum sich automatisierte Qualitätsprüfungen auf TARA-Ergebnissen so schwer bauen lassen.

Dazu kommt, dass sich der Schaden lokal oft gar nicht bestimmen lässt. Ein manipulierter Datenfluss ist für sich genommen nichts. Interessant wird er über die Frage, welche Funktion daran hängt und wer sie benutzt. Bremsassistent oder Innenraumbeleuchtung, ein Fahrzeug oder eine Flotte von zehntausend: derselbe technische Defekt, völlig verschiedene Schäden. Wer das Schadensszenario nur am Element festmacht, hat diesen Kontext nicht und rät.

Deshalb lohnt es sich, auch Funktionen als Assets zu modellieren. Dann hängt das Schadensszenario da, wo der Schaden entsteht, und der Datenfluss darunter erbt ihn über die Abhängigkeit, statt ihn selbst behaupten zu müssen.

Was hilft, sind gemeinsam genutzte Kataloge. Wenn eine Bewertung einmal definiert ist und danach jedes Projekt darauf verweist, das auf dieselbe Folge stößt, wird sie einmal ausdiskutiert statt in jeder TARA neu. Die Forschung, die Tuma und Widman zitieren, weist in dieselbe Richtung: Leute ohne Security-Expertise erzielten mit Katalogen Ergebnisse, die mit denen von Experten ohne Kataloge vergleichbar waren.

Wie weit sich das treiben lässt, ist eine eigene Frage. Für Bedrohungen und Controls sind Kataloge verbreitet, auf der Schadensseite ist das Feld dünner, und was davon nutzbar ist, hängt am Werkzeug. Wiederverwendbare Kataloge sind seit unserem escar-Paper von 2022 Teil des itemis-Arguments für modellbasierte TARA. Der Gedanke dahinter bleibt in jeder Ausbaustufe derselbe: was einmal entschieden ist, sollte nicht in jedem Projekt neu entschieden werden.

Dass ein Katalog Impact Ratings objektiv macht, würde ich nicht behaupten. Er macht sie konsistent, und das ist etwas anderes und deutlich leichter erreichbar. Konsistenz ist das, was Bewertungen über ein Portfolio hinweg vergleichbar macht.

Derselbe Schritt, andere Industrien

Auch diese Reihenfolge ist keine Eigenheit der Automobilwelt. Die IEC 62443-3-2 beginnt ihre Risikobewertung mit ZCR 2, einer ersten Abschätzung des schlimmsten Schadens, den eine Kompromittierung des System under Consideration anrichten kann, bevor irgendeine Gegenmaßnahme eingerechnet wird. Beschrieben wird er in den Begriffen Gesundheit und Sicherheit, Sachwerte, Informationen und Betriebsunterbrechung, und das alles passiert, bevor die detaillierte Arbeit pro Zone überhaupt anfängt. Gegen diese Folge wird anschließend das tolerierbare Risiko gehalten.

Das Vokabular ist anders, die Reihenfolge dieselbe: erst klären, was auf dem Spiel steht und für wen, dann über den Angriff reden. Beim Cyber Resilience Act läuft es wieder darauf hinaus. Die Kategorien sehen jedes Mal anders aus, überspringen lässt sich der Schritt nirgends.

Warum dafür ein Werkzeug?

Alles, was ich bis hierhin beschrieben habe, lässt sich in einer Tabelle machen. Das ist kein Strohmann: Tuma und Widman nennen die parametrisierte Tabellenkalkulation als den verbreitetsten Mechanismus für TARAs überhaupt, und daran hat sich seither weniger geändert, als man annehmen würde. Die Frage ist also nicht, ob es geht. Die Frage ist, was dabei verloren geht.

Assets hängen an Elementen. Wenn ein Asset an einer Funktion, einer Komponente, einem Kanal, einem Datenfluss oder einem Datum der Item Definition hängt, statt in eine Zeile getippt zu werden, wird die Vollständigkeitsprüfung, die die Norm verlangt, zur Abfrage statt zur Lesearbeit: welche Elemente tragen kein Asset und warum, welche Assets haben kein Schadensszenario, welche Schadensszenarien wurden nie bewertet. Dieselben Abfragen sind später der Rohstoff für den Bericht, den ohnehin jemand schreiben muss.

Der Impact wird berechnet, und er wandert. In der Engine, an der ich arbeite, werden die Bewertungen aller Schadensszenarien eines Security Objectives über eine konfigurierbare Formel zusammengefasst, standardmäßig das Maximum, und ergeben so den Impact Level (IL). Und ein Objective, das von einem anderen abhängt, gibt seinen Impact nach unten weiter: hängt A von B ab und hat A den höheren IL, erbt B ihn. Diese Propagation ist der Teil, den ich noch nie jemanden zuverlässig von Hand habe machen sehen. Ein gemeinsamer Bus oder eine gemeinsame Spannungsversorgung erbt den Impact des kritischsten Dings, das darauf sitzt, und in einer Tabelle muss sich das jemand merken, jedes Mal, in jeder Zeile.

Mehrere Stakeholder, ein Modell. Der Impact Level entsteht aus den Einzelbewertungen, gruppiert nach Impact-Kategorie und Stakeholder. Das klingt nach einem Implementierungsdetail, entscheidet aber, ob ihr über den Road User hinausgehen könnt, ohne euch zu verheben. Die Norm verlangt diesen Schritt nicht, und entsprechend ist er in TARA-Werkzeugen auch keine Selbstverständlichkeit. In einer Tabelle legt ihr euch auf eine Perspektive fest, oder ihr legt die Analyse ein zweites Mal an. Das eine verliert Schaden, das andere verdoppelt den Pflegeaufwand, und die beiden Kopien driften ab dem Tag auseinander, an dem sie existieren. Im Modell trägt dasselbe Schadensszenario mehrere Bewertungen nebeneinander, und dieselbe Gruppierung ist es, nach der sich die Ergebnisse hinterher auswerten und exportieren lassen.

Das Vokabular ist Konfiguration, keine Konstante. Sicherheitseigenschaften und Impact-Kategorien sind eigene Objekte und keine fest verdrahteten Spalten. Safety, Financial, Operational und Privacy sind die vier, die die Norm nennt, nicht die Obergrenze: wer regulatorische Folgen oder Reputationsschaden getrennt führen will, ergänzt eine Kategorie, statt eine Tabellenvorlage neu zu verhandeln. Dasselbe bei den Eigenschaften. Vertraulichkeit, Integrität und Verfügbarkeit sind der übliche Satz, aber wer Authentizität als vierte danebenstellen will, weil sie im eigenen Umfeld eine eigene Angriffsklasse trägt, legt sie an. In einer Tabellenlandschaft ist so eine Ergänzung eine neue Spalte in jeder bestehenden Datei, und deshalb passiert sie meistens nicht.

Vieles davon lässt sich auf Unternehmensebene ablegen und in jedes Projekt mitnehmen: Bewertungsmodell, Terminologie, Stakeholder, Kategorien, Kataloge. Das ist der Unterbau für die Konsistenz, über die ich weiter oben geschrieben habe. Sie entsteht nicht dadurch, dass sich alle Beteiligten Mühe geben, sondern dadurch, dass alle dieselben Objekte referenzieren.

Auch die Annahmen bekommen einen Platz. Die Norm erlaubt der Analyse, Informationen anzunehmen, die die Item Definition nicht hergibt, und verlangt dafür einen Preis: wer ein Risiko auf Basis einer solchen Annahme akzeptiert, braucht einen dokumentierten Cybersecurity Claim. Im Modell ist eine Annahme ein Objekt mit einer Transformation, die den Schaden oder den Aufwand genau in den Angriffspfaden verändert, für die sie gilt. Ihre Wirkung auf die Bewertung bleibt damit sichtbar, statt in einem Kommentarfeld zu verschwinden.

Und dann ist da die KI-Frage, die ich in Teil eins schon angerissen habe. Ein Assistent, der Schadensszenarien zu einem Asset vorschlägt oder eine Analyse auf Lücken abklopft, ist nur so gut wie der Kontext, den er befragen kann. Gegen ein Modell aus typisierten Elementen, Katalogen und einem hinterlegten Regelwerk kann er arbeiten, und seine Vorschläge lassen sich gegen dasselbe Regelwerk prüfen, bevor ein Mensch sie annimmt oder verwirft. Gegen eine Tabelle bleibt ihm das Raten. Für diesen Schritt gilt das besonders, weil ein Schadensszenario der Ort ist, an dem ein Vorschlag am leichtesten plausibel klingt und trotzdem falsch ist.

Der Punkt, der mir am wichtigsten ist, kommt zum Schluss. Eine TARA, die mit der Freigabe stehen bleibt, nützt euch im Feld nichts. Dort tauchen laufend neue Schwachstellen auf, und jede stellt dieselbe Frage: betrifft mich das, und wie schlimm ist es?

Die erste Hälfte der Antwort liefert die SBOM. Sie sagt, welche Komponente das betroffene Paket ausführt. Die zweite Hälfte ist genau das, worum es in diesem Artikel geht: an der Komponente hängen Assets, an den Assets Schadensszenarien, und daran der Impact. Ist diese Kette im Modell gezogen, kann das Werkzeug die betroffenen Schadensszenarien selbst heraussuchen und den Impact dazu ausrechnen. Entscheiden muss immer noch jemand, aber er entscheidet über eine Liste statt über ein Gefühl.

Das ist gemeint, wenn von einer dynamischen TARA die Rede ist. In einer Tabelle gibt es diese Kette nicht. Da steht die Schwachstelle auf der einen Seite, ein Impact-Wert auf der anderen, und dazwischen sitzt jemand, der sich erinnern muss.

Fazit

Asset Identification und Impact Rating klingen nach Buchhaltung und sind das Gegenteil. Sie legen den Maßstab fest, auf dem jeder spätere Schritt arbeitet: welche Elemente die Bedrohungsanalyse abdecken muss, wessen Schaden die Bewertungen messen, und wie hoch das höchste Risiko im ganzen Item überhaupt werden kann.

Was ich davon mitnehmen würde: ein Element wird zum Asset, wenn sich Eigenschaft, Folge und Stakeholder in einem Satz benennen lassen, vorher nicht. Eigenschaften werden pro Schadensszenario gewählt und nicht vorsorglich flächendeckend angehakt. Der Kreis der Stakeholder und die Impact-Kategorien gehören der Organisation, nicht dem Projekt. Die Safety-Bewertung ist eine gemeinsame Zahl mit dem Safety-Team. Und vergleichbar bleiben die Bewertungen nur, wenn die Schadensszenarien dahinter geteilte Objekte sind statt frisch formulierter Prosa in jeder TARA.

Wer das modellbasiert umsetzen will: itemis SECURE setzt genau diesen Ansatz um, von den Assets am Item-Modell über Schadensszenario- und Impact-Kataloge bis zum berechneten Impact Level, der durch die Analyse propagiert. Kategorien, Eigenschaften und Stakeholder sind dabei Konfiguration, kein Gerüst, in das ihr euch einpassen müsst. Wenn ihr sehen wollt, wie das an einem echten Item aussieht, erreicht ihr mich auf LinkedIn oder über itemis.com.

Im dritten Teil geht es um die andere Hälfte des Risikos: die Identifikation der Bedrohungsszenarien, und um das Vollständigkeitsargument, das sich tatsächlich verteidigen lässt. Und wer vor der Tiefe erst den Überblick über die ganze Methode sucht, findet ihn in meinem Einführungsartikel Was ist eine TARA?.

Eines würde mich wirklich interessieren: wie haltet ihr eure Impact Ratings zwischen Projekten vergleichbar? Über einen geteilten Katalog, über ein Gremium, das sie kalibriert, oder diskutiert jede TARA den Schweregrad neu aus?