Bedrohungsszenarien und Angriffspfade: Das Was und das Wie eines Angriffs

Die andere Hälfte des Risikos

Teil zwei dieser Serie hat die eine Hälfte des Risikos geliefert: was auf dem Spiel steht und für wen. Hier geht es um die andere. Wie kommt ein Angreifer an ein Asset heran, und wie viel Aufwand kostet ihn das?

Die ISO/SAE 21434:2021 verteilt das auf drei Module: die Identifikation der Bedrohungsszenarien, die Analyse der Angriffspfade und das Rating der Attack Feasibility. Ich behandle alle drei in einem Artikel, weil die Norm sie selbst nicht trennt. Ein Angriffspfad ist in ihren Worten die Abfolge von Schritten, die ein Bedrohungsszenario realisiert. Das Szenario sagt, was passiert. Der Pfad sagt, wie. Und bewertet wird nicht das Szenario, sondern der Pfad.

Das ist Teil drei meiner Serie zu den Schritten einer Threat Analysis and Risk Assessment (TARA). Teil eins war die Item Definition, Teil zwei Asset Identification und Impact Rating.

Was die Norm verlangt

Die Norm verlangt auf Basis der Item Definition eine Analyse, zu der unter anderem die Identifikation der Bedrohungsszenarien, die Analyse der Angriffspfade und das Rating der Attack Feasibility gehören. Die Methoden dazu stehen in Clause 15.

Ein Bedrohungsszenario hat dort drei Bestandteile: das angegriffene Asset, die verletzte Sicherheitseigenschaft und die Ursache der Verletzung. Die ersten beiden kennt ihr aus Teil zwei, zusammen sind sie das Asset. Neu ist die Ursache.

Wie ein Szenario konkret abläuft, beschreiben die Angriffspfade. Zu jedem Szenario sucht man die Pfade, und jeder Pfad gehört zu den Szenarien, die er realisieren kann. Bewertet wird dann der Pfad, nicht das Szenario. Jeder Angriffspfad bekommt ein Attack Feasibility Rating: high, medium, low oder very low. Das Szenario erbt seinen Wert erst bei der Risikobestimmung von seinen Pfaden, im Beispiel der Norm einfach das Maximum.

Hinter dem Maximum steckt eine einfache Annahme: der Angreifer nimmt den bequemsten Weg. Annex H zeigt das am Scheinwerfer. Das Szenario “Spoofing der Lichtanforderung” hat dort drei Pfade, über Mobilfunk, über Bluetooth und über den OBD-Stecker. Nach Angriffsvektor bewertet sind das high, medium und low. Das Szenario landet bei high, und zusammen mit dem Schaden severe aus Teil zwei ergibt das in der Beispielmatrix den Risikowert 5, den höchsten, den die Skala hergibt. Dass der Weg über den OBD-Stecker mühsam ist, ändert daran nichts.

Was ein Bedrohungsszenario ist, und was nicht

Ein Bedrohungsszenario passt in einen Satz: Durch [Ursache] wird die [Eigenschaft] von [Element] verletzt. Das ist der Satz aus Teil zwei, von der anderen Seite gelesen. Dort ging es von der Verletzung weiter zum Schaden, hier geht es zurück zur Ursache.

Annex H formuliert es so: Spoofing eines Signals führt zum Verlust der Integrität der Datenkommunikation “Lamp Request” zu dem Aktor, der den Scheinwerfer schaltet, und das Licht geht womöglich ungewollt aus. Ursache, Eigenschaft und Asset sind benannt.

Wer nur die erste Lücke füllt, hat noch kein Szenario. “Spoofing” ist eine Kategorie aus STRIDE, kein Bedrohungsszenario. Ohne Asset und Eigenschaft hängt es an nichts, und was an nichts hängt, erreicht kein Schadensszenario. Man kann so einem Eintrag eine Feasibility geben, aber keinen Impact.

Bedrohung und Schaden sind dabei nicht eins zu eins verbunden. Ein Schadensszenario kann mehrere Bedrohungsszenarien haben, und ein Bedrohungsszenario kann zu mehreren Schäden führen. Annex H führt für die Frontalkollision mit dem Baum zwei Szenarien: das Spoofing der Lichtanforderung und das Tampering an dem Signal, das das Body-Control-Steuergerät sendet. Zwei Ursachen, ein Schaden.

Auch die Reihenfolge ist wieder frei. Für die Identifikation der Bedrohungsszenarien setzt die Norm nur die Item Definition voraus. Assets und Schadensszenarien sind dort unterstützende Information, keine Voraussetzung. Umgekehrt erlaubt die Norm ausdrücklich, Assets aus Bedrohungsszenarien abzuleiten. Wer lieber vom Angreifer her denkt, darf das.

Katalog oder Workshop?

Wie ihr auf die Szenarien kommt, ist eure Sache. Ihr könnt euch zusammensetzen und diskutieren, Missbrauchsfälle durchspielen oder mit STRIDE, EVITA, TVRA oder PASTA arbeiten. Die Norm zählt das alles auf, einen Katalog schreibt sie nicht vor.

Ich halte beides für nötig, aus verschiedenen Gründen. Der Workshop findet, was nur in diesem Item steckt und in keinem Katalog stehen kann. Der Katalog liefert etwas anderes: ein Vollständigkeitsargument, das sich verteidigen lässt.

Vollständig ist eine Bedrohungsanalyse nie, und das verlangt auch niemand ernsthaft. Die Norm verlangt eine Verifikation, dass das Ergebnis der Analyse korrekt und vollständig ist, und zwar in Bezug auf die Item Definition. “Wir haben zwei Tage lang nachgedacht” ist kein Bezug. “Jedes Asset wurde gegen jede passende Bedrohungsklasse des Katalogs geprüft, und wo nichts übrig blieb, steht die Begründung dabei” ist einer. Die zweite Aussage lässt sich nachprüfen, die erste nicht.

Für die Automobilwelt gibt es inzwischen brauchbare Quellen. Die Automotive Threat Matrix des Auto-ISAC ordnet 77 Angriffstechniken in 14 Taktiken, von Initial Access bis Affect Vehicle Function, und verknüpft die Techniken mit 24 veröffentlichten Angriffen auf Serienfahrzeuge, darunter dem Jeep-Cherokee-Hack von 2015. Für eingebettete Geräte allgemein knüpft EMB3D von MITRE bekannte Bedrohungen an Geräteeigenschaften. Solche Quellen ersetzen keinen eigenen Katalog. Sie beantworten aber eine Frage, die in jeder Feasibility-Diskussion auftaucht: hat das schon einmal jemand geschafft?

Ob ein Team mit Katalog am Ende weniger übersieht als eines ohne, kann ich nicht mit eigenen Zahlen belegen. Die Studie, die Tuma und Widman zitieren und die ich in Teil zwei schon erwähnt habe, spricht dafür: Leute ohne Security-Hintergrund kamen mit Katalog auf Ergebnisse, die mit denen von Experten ohne Katalog vergleichbar waren.

Vom Szenario zum Angriffspfad

Ein Bedrohungsszenario sagt, was passiert. Ob es passieren kann und wie schwer das ist, sagt erst der Angriffspfad.

Die Norm lässt zwei Richtungen zu. Top-down zerlegt ihr das Szenario in die Wege, auf denen es sich realisieren lässt, etwa als Angriffsbaum oder Angriffsgraph. Bottom-up baut ihr Pfade aus den Schwachstellen, die ihr kennt. Die erste Richtung braucht das Szenario, die zweite die Schwachstelle. Auf die zweite komme ich am Schluss zurück.

Zwei Anmerkungen der Norm nehmen viel Druck aus diesem Schritt. Ein Teilpfad, der kein Szenario realisiert, muss nicht weiter analysiert werden. Und Pfade dürfen in der frühen Entwicklung unvollständig und ungenau sein, weil die Implementierung noch nicht feststeht. Sie werden nachgezogen, wenn mehr bekannt ist, etwa nach einer Schwachstellenanalyse. Die Norm erwartet in der Konzeptphase also keinen fertigen Baum. Sie erwartet, dass er wächst.

Annahmen schneiden Pfade ab. Annex H schließt alle Pfade aus, die physischen Zugang ins Innere des Items brauchen, etwa an den Mikrocontroller des Body-Control-Steuergeräts, und begründet das mit einer Annahme. Das ist legitim. Hier kommen aber die Annahmen aus Teil eins zurück: was an dieser Stelle wegfällt, fällt auf Grundlage einer Aussage weg, die später jemand prüfen können muss.

In den Pfaden aus Annex H wiederholen sich Schritte. “Angreifer kompromittiert das Navigationssteuergerät über die Mobilfunkschnittstelle” steht in einem Pfad für das Spoofing und in einem für den Denial of Service. “Das Gateway leitet die bösartigen Signale an den Aktor weiter” steht in allen fünf Pfaden. Ein Pfad ist also keine Erzählung. Er ist eine Abfolge von Schritten, und dieselben Schritte gehören mehreren Pfaden gleichzeitig. Wer das Gateway härtet, verändert fünf Pfade auf einmal.

Wie aufwendig ist der Angriff?

Für das Rating empfiehlt die Norm drei Ansätze. Sie unterscheiden sich vor allem darin, wie viel ihr wissen müsst.

Der vektorbasierte Ansatz schaut nur auf den vorherrschenden Angriffsvektor des Pfads. Netzwerk ohne Einschränkung ist high, ein benachbarter Zugang wie Bluetooth medium, ein lokaler wie USB low, physischer Zugang very low. Dafür reicht der Einstiegspunkt. Deshalb empfiehlt die Norm diesen Ansatz für die Konzeptphase, wenn sich konkrete Pfade noch nicht bestimmen lassen.

Der Attack-Potential-Ansatz bewertet fünf Faktoren: die benötigte Zeit, das Fachwissen, die Kenntnis des Items, das Gelegenheitsfenster und die Ausrüstung. Annex G gibt jedem Faktor Punkte, summiert sie und bildet die Summe auf die vier Stufen ab. Dafür braucht ihr den ganzen Pfad, nicht nur seinen Anfang.

Der CVSS-basierte Ansatz nimmt die Exploitability-Metriken aus CVSS: Angriffsvektor, Komplexität, benötigte Rechte und Nutzerinteraktion. Er braucht eine konkrete Schwachstelle oder zumindest eine konkrete Schwäche im Konzept.

Die Wahl ist keine Formsache. Annex H bewertet die beiden Denial-of-Service-Pfade mit Attack Potential. Der Pfad über die Mobilfunkschnittstelle kommt auf 20 Punkte: mehrere Experten (8), vertrauliche Kenntnis des Items (7), Spezialausrüstung (4), bis zu einer Woche Zeit (1) und ein unbegrenztes Gelegenheitsfenster (0). Das ergibt low. Nach der Vektorlogik aus Annex G wäre ein Einstieg über Mobilfunk high. Derselbe Einstieg, zwei Methoden, zwei Stufen Unterschied.

Der zweite Pfad läuft über einen Bluetooth-OBD-Dongle, den der Angreifer in einem unverschlossen geparkten Fahrzeug einsteckt, und über das kompromittierte Smartphone des Fahrers. Er braucht physischen Zugang und bekommt deshalb beim Gelegenheitsfenster 4 statt 0. Das macht 24 Punkte, wieder low, einen Punkt vor very low.

Falsch ist damit keine der Methoden. Sie messen Verschiedenes, mit verschiedenem Wissensstand. Aber die Methode gehört, wie die Impact-Kategorien aus Teil zwei, der Organisation und nicht dem einzelnen Analysten. Wer in einer TARA nach Vektor bewertet und in der nächsten nach Attack Potential, hat zwei Feasibility-Skalen, die gleich heißen.

Zwei Details aus Annex G halte ich für wichtiger, als sie dort aussehen. Ob sich ein Angriff skalieren lässt, also leicht auf viele Fahrzeuge übertragen, darf in das Rating einfließen. Und die benötigte Zeit wird am Stand des Expertenwissens zum Zeitpunkt der Bewertung gemessen. Eine Feasibility altert also. Wird ein Exploit veröffentlicht, sinkt der Aufwand, ohne dass sich am Item irgendetwas geändert hat.

Derselbe Schritt, andere Industrien

In Teil 3-2 der IEC 62443 heißt die Größe nicht Feasibility, sondern Likelihood. Die detaillierte Risikobewertung in ZCR 5 beginnt für jede Zone und jeden Conduit damit, Bedrohungen und Schwachstellen zu identifizieren. Erst danach schätzt sie die Wahrscheinlichkeit ohne Gegenmaßnahmen. Die Begriffe sind andere, die Reihenfolge dieselbe: erst klären, wer wie herankommt, dann bewerten, wie wahrscheinlich das ist.

Warum dafür ein Werkzeug?

Auch dieser Schritt geht in einer Tabelle, bei den Bedrohungsszenarien sogar ganz gut: eine Zeile pro Szenario, Spalten für Asset, Eigenschaft und Ursache. Schwierig wird es beim Pfad. Er ist eine Abfolge von Schritten, die sich mehrere Szenarien teilen, und für diese Struktur hat eine Zeile keinen Platz.

Schritte sind Objekte, keine Aufzählung in einer Zelle. In itemis SECURE sind Bedrohungsszenario und Angriffsschritt dasselbe Objekt. Bedroht es ein Security Objective direkt, ist es ein Bedrohungsszenario. Bereitet es ein anderes vor, ist es ein Angriffsschritt. Das kompromittierte Navigationssteuergerät aus Annex H gibt es damit genau einmal, und jeder Pfad, der darüber läuft, verweist darauf. Wer den Schritt umformuliert oder neu bewertet, tut das an einer Stelle. In einer Excel-Liste steht er als Text in mehreren Zellen, und jede Kopie muss jemand von Hand nachziehen.

Die Feasibility wird entlang des Pfads berechnet. Jeder Schritt trägt seine Faktoren, und die Engine kombiniert sie nach zwei Regeln. Sie rechnet zusammen, was ein Angreifer alles tun muss: den Schritt selbst, die Schritte, die ihn vorbereiten, und die Gegenmaßnahmen, die er überwinden muss. Wo er die Wahl hat, nimmt sie die leichteste Alternative. Das ist dieselbe Annahme wie das Maximum über die Pfade eines Szenarios, nur gilt sie auf jeder Ebene des Baums.

Eine Feinheit daran ist für mich der eigentliche Grund, das nicht von Hand zu machen. Die Engine legt sich an einer Verzweigung nicht auf die Alternative fest, die dort am leichtesten aussieht. Sie führt die Faktorsätze der Alternativen getrennt weiter, weil der lokal schwerere Ast zusammen mit dem Rest des Pfads der global leichtere sein kann. Wer das in einer Tabelle nachvollziehen will, rechnet jeden vollständigen Pfad einzeln aus und vergleicht am Ende. Bei drei Pfaden geht das noch.

Methode und Faktoren sind Konfiguration. Wie sich die Faktoren kombinieren, ist einstellbar, und das Bewertungsmodell kann auf Unternehmensebene liegen und von jedem Projekt referenziert werden. Die Methodenwahl aus dem vorigen Abschnitt fällt damit einmal und nicht in jeder TARA neu.

Bedrohungen kommen aus Katalogen. Das Modell kennt wiederverwendbare Klassen von Bedrohungen und Gegenmaßnahmen. Den Gedanken dahinter hat unser escar-Paper von 2022 ausgeführt: ein Bedrohungskatalog ist Referenzmaterial für die Feasibility, und wer ihn über Projekte hinweg nutzt, bekommt für dieselbe Bedrohung dieselbe Bewertung. Das Paper geht noch weiter. Ein Katalog ohne produkt- oder firmenspezifische Daten lässt sich offen teilen, und eine Aktualisierung erreicht jede TARA, die ihn verwendet, ohne Nacharbeit von Hand.

Dann die KI-Frage, die in dieser Serie jedes Mal wiederkommt. Ein Assistent, der Bedrohungsszenarien vorschlägt, ist in diesem Schritt besonders verlockend, weil es zu Bedrohungen viel öffentliches Material gibt. Genau deshalb klingen seine Vorschläge fast immer plausibel. Ob ein vorgeschlagenes Szenario an einem echten Asset hängt, ob sein Pfad über Kanäle läuft, die es im Item gibt, und ob es unter anderem Namen schon existiert, lässt sich gegen ein Modell mit hinterlegtem Regelwerk prüfen, bevor ein Mensch es annimmt. Gegen eine Tabelle nicht.

Zum Schluss der Punkt, mit dem auch Teil zwei geendet hat: Wo landet eine neue CVE in der TARA? Bei den Angriffspfaden. Die Norm nennt Schwachstellen aus dem Monitoring nach Clause 8 ausdrücklich als Information für die Pfadanalyse, und sie erlaubt, Pfade von einer bekannten Schwachstelle aus aufzubauen.

Die SBOM sagt, welche Komponente das betroffene Paket ausführt. An der Komponente hängen die Angriffsschritte, die über sie laufen. Die Schwachstelle wird ein neuer Schritt im Baum oder senkt den Aufwand eines bestehenden. Das Eintragen kann ein Assistent vorschlagen, das Nachrechnen übernimmt die Engine: neue Feasibility für die betroffenen Pfade, das Maximum für jedes Szenario, und daraus mit dem Impact aus Teil zwei das neue Risiko. Am Ende steht eine Liste der Risiken, die sich durch diese eine CVE verschoben haben. Entscheiden muss immer noch jemand, aber über eine Liste statt über ein Gefühl.

Deshalb hat jede Feasibility ein Verfallsdatum. Annex G bewertet den Zeitaufwand nach dem Wissensstand zum Zeitpunkt der Bewertung. Wird ein Exploit veröffentlicht, ist das alte Rating überholt, auch wenn sich am Item nichts geändert hat.

Fazit

Bedrohungsszenario, Angriffspfad und Attack Feasibility sind in der Norm drei Module und in der Sache ein Gedanke: was passiert, wie es passiert und was es den Angreifer kostet. Bewertet wird der Weg, nicht das Ziel, und das Szenario erbt die Bewertung seines leichtesten Wegs.

Was ich daraus mitnehme: Ein Bedrohungsszenario braucht Asset, Eigenschaft und Ursache. “Spoofing” allein ist noch keins. Ob eure Analyse vollständig ist, zeigt ihr an der Item Definition und einem Katalog, nicht an der Dauer des Workshops. Pfade teilen sich Schritte und wachsen mit dem Projekt. Wie die Feasibility bewertet wird, legt die Organisation fest, nicht jeder Analyst für sich. Und jedes Rating hat ein Verfallsdatum.

Wer das modellbasiert umsetzen will: itemis SECURE setzt diesen Ansatz um, von Bedrohungsszenarien und Angriffsschritten als gemeinsamen Objekten über Bedrohungskataloge bis zur Feasibility, die die Engine entlang der Pfade berechnet. Wenn ihr sehen wollt, wie das an einem echten Item aussieht, erreicht ihr mich auf LinkedIn oder über itemis.com.

Im vierten Teil treffen die beiden Hälften aufeinander: Risikobestimmung und Risikobehandlung. Es geht um die Matrix, in der Impact und Feasibility zum Risikowert werden, und um die Entscheidung, was ihr mit jedem Risiko tut: vermeiden, reduzieren, teilen oder selbst tragen. Wer vorher den Überblick über die ganze Methode sucht, findet ihn in meinem Einführungsartikel Was ist eine TARA?.

Wie macht ihr das in der Konzeptphase, wenn ihr die Pfade erst grob kennt? Bewertet ihr nach Angriffsvektor, schätzt ihr das Attack Potential trotzdem schon ab, oder wartet ihr mit dem Rating, bis die Architektur steht?

Cyber Security bei itemis — Systematisches Security-Engineering für Automotive, IoT und Industry 4.0: Cyber Security →