Zum Hauptinhalt springen

Threat Scenario (Bedrohungsszenario)

Ein Threat Scenario (Bedrohungsszenario) beschreibt nach ISO/SAE 21434 eine mögliche Ursache dafür, dass die Sicherheitseigenschaft eines Assets verletzt wird. Die Norm verlangt drei Bestandteile: das angegriffene Asset, die verletzte Sicherheitseigenschaft und die Ursache. Das Szenario sagt, was passiert. Wie es passiert, beschreiben die Angriffspfade.

Drei Bestandteile, ein Satz

Ein Bedrohungsszenario passt in einen Satz: Ursache verletzt die Eigenschaft von Element. Annex H der Norm formuliert es am Scheinwerfer-Beispiel so: Spoofing eines Signals verletzt die Integrität der Datenkommunikation “Lamp Request” zum Aktor, der den Scheinwerfer schaltet. Das Licht geht womöglich ungewollt aus.

“Spoofing” allein ist noch kein Bedrohungsszenario. Es ist eine Kategorie aus STRIDE. Ohne Asset und Eigenschaft lässt sich kein Schadensszenario daran knüpfen.

Bedrohung und Schaden

Bedrohungs- und Schadensszenarien hängen nicht eins zu eins zusammen. Ein Schadensszenario kann mehrere Bedrohungsszenarien haben, ein Bedrohungsszenario mehrere Schäden. Annex H führt für die Frontalkollision mit einem Baum zwei Szenarien: das Spoofing der Lichtanforderung und das Tampering am Signal des Body-Control-Steuergeräts. Hier führen also zwei Ursachen zum selben Schaden.

Auch die Reihenfolge ist frei. Für Bedrohungsszenarien setzt die Norm nur die Item Definition voraus. Assets und Schadensszenarien helfen, nötig sind sie nicht. Umgekehrt darf man Assets aus Bedrohungsszenarien ableiten. Wer lieber vom Angreifer her denkt, darf das.

Workshop oder Katalog

Die Norm lässt die Diskussion in der Gruppe ebenso zu wie systematische Ansätze: Missbrauchsfälle durchspielen oder mit Frameworks wie STRIDE, EVITA, TVRA oder PASTA arbeiten. Einen Katalog schreibt sie nicht vor.

Sie verlangt aber, gegen die Item Definition zu verifizieren, dass das Ergebnis korrekt und vollständig ist. “Wir haben zwei Tage diskutiert” hilft dabei nicht. “Jedes Asset wurde gegen jede passende Bedrohungsklasse des Katalogs geprüft” schon, denn diese Aussage lässt sich nachprüfen.

Vom Szenario zum Risiko

Bewertet wird nicht das Szenario, sondern seine Angriffspfade. Jeder Pfad bekommt ein Rating der Attack Feasibility. Das Szenario übernimmt bei der Risikobestimmung den Wert seiner Pfade, im Beispiel der Norm das Maximum, weil der Angreifer den bequemsten Weg nimmt. Zusammen mit dem Impact der zugehörigen Schadensszenarien ergibt sich daraus der Risikowert des Szenarios.

Wie Szenario, Pfad und Feasibility zusammenspielen, beschreibt unser Artikel zu Bedrohungsszenarien und Angriffspfaden.

Verwandte Begriffe

Häufige Fragen

Was ist der Unterschied zwischen Threat Scenario und Attack Path?
Das Bedrohungsszenario sagt, was passiert: welche Eigenschaft welches Assets wodurch verletzt wird. Der Angriffspfad sagt, wie: die Schritte, mit denen ein Angreifer das Szenario umsetzt. Zu einem Szenario gehören oft mehrere Pfade. Annex H nennt für das Spoofing der Lichtanforderung drei: über Mobilfunk, über Bluetooth und über den OBD-Stecker.
Schreibt die ISO/SAE 21434 STRIDE vor?
Nein. Die Norm nennt STRIDE, EVITA, TVRA und PASTA als Beispiele und erlaubt ausdrücklich auch die Diskussion in der Gruppe. Festgelegt ist nur der Inhalt eines Szenarios: Asset, verletzte Sicherheitseigenschaft und Ursache.
Braucht ein Bedrohungsszenario ein Schadensszenario?
Um es zu finden, nicht. Dafür reicht die Item Definition. Für das Risiko schon, denn der Risikowert entsteht aus dem Impact der zugehörigen Schadensszenarien. Ein Szenario ohne Schaden hat eine Feasibility, aber kein Risiko.
Fachlich geprüft von Jens Bühl, Product Owner am 30. Oktober 2026