Asset

Ein Asset ist nach ISO/SAE 21434 ein Objekt von Wert, dessen Sicherheitseigenschaft kompromittiert werden kann: Vertraulichkeit, Integrität oder Verfügbarkeit. Die Norm verlangt, genau die Assets zu identifizieren, deren Kompromittierung zu einem Schadensszenario führt. Ein Element des Items ist also nicht automatisch ein Asset. Es wird eins, wenn an einer seiner Eigenschaften ein Schaden hängt.

Element plus Eigenschaft

Ein Asset ist nie das Element allein. Dazu gehört immer die Eigenschaft, die geschützt werden soll. Annex H der Norm markiert bei der Firmware des Body-Control-Steuergeräts Vertraulichkeit und Integrität. Das sind zwei Assets auf einem Element, und hinter ihnen stehen ganz verschiedene Schäden.

Wer nur das Element erfasst, setzt die Eigenschaft stillschweigend auf “alle drei”. Das bläht die Bedrohungsanalyse auf und bringt nichts.

Ab wann ist ein Element ein Asset?

Die Kandidaten liefert die Item Definition: Funktionen, Komponenten, Kanäle, Datenflüsse und Daten. Bei der Auswahl hilft ein einfacher Test. Man versucht, diesen Satz sinnvoll zu füllen: Wird die Eigenschaft von Element verletzt, erleidet Stakeholder einen Schaden. Klappt das, hat man ein Asset und ein Schadensszenario. Klappt es nicht, bleibt es ein Element der Architektur.

Im Scheinwerfer-Beispiel aus Annex H ist bei der Datenkommunikation “Lamp Request” nur die Integrität markiert, weil die Schadensszenarien davon handeln, dass das Licht ungewollt ausgeht. Andere Eigenschaften markiert Annex H dort nicht, weil an ihnen kein Schadensszenario hängt. Als Assets nennt Annex H zwei Datenkommunikationen und eine Firmware. Ein Steuergerät ist nicht dabei.

Reihenfolge und Quellen

Die Norm legt nicht fest, ob zuerst die Assets oder die Schadensszenarien kommen. Assets lassen sich aus der Item Definition ableiten, über das Impact Rating, aus Bedrohungsszenarien oder aus vordefinierten Katalogen. Annex H sagt ausdrücklich, dass sich die Module der TARA in beliebiger Reihenfolge bearbeiten lassen.

Assets in der Praxis

Vertraulichkeit, Integrität und Verfügbarkeit sind die übliche Auswahl, aber keine Obergrenze. Wer Authentizität getrennt bewerten will, ergänzt sie als vierte Eigenschaft.

Am Element allein lässt sich der Schaden nicht immer bestimmen. Ein manipulierter Datenfluss richtet für sich genommen noch keinen Schaden an. Es kommt darauf an, welche Funktion daran hängt und wer sie nutzt. Deshalb lohnt es sich, auch Funktionen als Assets zu führen. Dann hängt das Schadensszenario dort, wo der Schaden entsteht.

Hängen die Assets an den Elementen eines Modells statt in einer Tabellenzeile, lässt sich die Vollständigkeit einfach abfragen: Welche Elemente tragen kein Asset, welche Assets haben kein Schadensszenario? Mehr dazu in unserem Artikel zu Asset Identification und Impact Rating.