STRIDE und Attack Tree an einem PROFINET-Feldgerät: eine Analyse im Detail

Methodenbeschreibungen bleiben abstrakt, solange man sie nicht an einem echten Gerät sieht. Deshalb hier eine durchgearbeitete Analyse an einem konkreten Betrachtungsobjekt: einer PROFINET-Leistungsschalter-Plattform — einem Kommunikationsmodul mit sicherheitsgerichteter Schaltfunktion über PROFIsafe, aufgebaut um einen STM32 als Steuerungs-MCU und einen LAN9354 als Netzwerkbaustein.

Das Besondere an diesem Gerät: Es schaltet Leistung, und es tut das unter einer Sicherheitsfunktion. Ein Security-Vorfall bleibt hier kein IT-Problem.

Ein Hinweis zum Umfang: Das Folgende ist ein kompaktes Arbeitsbeispiel, keine vollständige TRA. Eine vollständige Analyse für ein reales Produkt ist deutlich umfangreicher — hier geht es darum, das Vorgehen an einem echten Gerät nachvollziehbar zu machen.

Schritt 1: Die Angriffsfläche benennen

Vor jeder Bewertung steht die Frage, wo ein Angreifer überhaupt ansetzen kann. Für dieses Gerät ergeben sich sechs Eintrittspunkte:

Diese Liste ist bereits ein Ergebnis. Sie zwingt dazu, Schnittstellen zu benennen, die in Architekturdiagrammen gern fehlen — den Debug-Port und die Lieferkette etwa.

Schritt 2: STRIDE — je Kategorie das relevanteste Szenario

STRIDE geht die sechs Bedrohungskategorien durch und fragt für jede: Was ist hier das realistischste Szenario, welche Schnittstelle betrifft es, und wie schwer wiegt es?

Zwei Beobachtungen lohnen den zweiten Blick.

Fehlende Geräteidentität macht Vertrauen topologisch. Ohne eine kryptografische Geräteidentität — etwa nach IEEE 802.1AR — beruht das Vertrauen zwischen den Teilnehmern allein darauf, wer physisch am Netz hängt. Wer Netzzugang hat, ist damit implizit vertrauenswürdig. Das ist die Grundannahme, die Spoofing überhaupt erst trägt.

Verfügbarkeit ist hier ein Sicherheitsproblem, kein Komfortproblem. PROFIsafe reagiert auf Störungen korrekt — es geht in den sicheren Zustand. Genau das bedeutet aber ungeplanten Anlagenstillstand. Ein Angreifer muss die Integrität also gar nicht brechen, um Schaden anzurichten; er muss nur stören.

Die Kopplung, die dieses Gerät besonders macht

Der zentrale Befund dieser Analyse ist keine einzelne Zeile der Tabelle, sondern ihre Summe: Ein erfolgreicher Angriff auf IF-01, IF-02 oder IF-04 kann die sicherheitsgerichtete Funktion außer Kraft setzen. Integritätsverlust ist bei diesem Produkt eine potenzielle Verletzung der funktionalen Sicherheit.

Das verschiebt die Diskussion. Solange Security als Schutz von Daten verhandelt wird, konkurriert sie mit anderen Anforderungen um Budget. Sobald sie als Voraussetzung der Schutzfunktion verstanden wird, steht sie neben der Safety-Argumentation — und die ist in diesem Marktsegment nicht verhandelbar.

Schritt 3: Attack Tree — vom Szenario zu den Pfaden

Das schwerwiegendste Szenario aus der STRIDE-Tabelle wird zerlegt: Unautorisierte gefährliche Schaltaktion auslösen. Drei Wege führen zum Ziel, und es genügt einer:

• Ast A — über das Netzwerk (IF-01/02). Entweder RT-Frame-Manipulation, die beide Bedingungen zugleich verlangt: Netzzugang und fehlende Integritätssicherung. Oder eine PROFIsafe-Umgehung über manipulierte F-Parameter.
• Ast B — über die Firmware (IF-03/04). Entweder unsignierte Firmware über den Update-Pfad, oder ein offener Debug-Port (JTAG/SWD ohne aktivierten Readout-Schutz).
• Ast C — über die Konfiguration (IF-05). Service-Zugang ohne Authentisierung, per Web-UI oder serieller Konsole, und darüber die Parameter verstellen.

Der Unterschied zwischen ODER und UND ist dabei der ganze Punkt der Methode. Ein ODER-Knoten heißt: Jeder Teilpfad genügt, die Kette ist so stark wie ihr schwächstes Glied. Ein UND-Knoten heißt: Alle Bedingungen müssen zusammenkommen — und es reicht, eine davon zu brechen, um den Pfad zu schließen.

Daraus folgt die Härtungsregel unmittelbar: Zuerst den einfachsten vollständigen Pfad unterbrechen. Nicht den spektakulärsten, nicht den technisch interessantesten. Bewertet wird jedes Blatt nach benötigtem Zugang, Aufwand, Vorwissen und Entdeckungswahrscheinlichkeit — dieselbe Logik, die auch der Attack-Potential-Bewertung zugrunde liegt.

Schritt 4: Maßnahmen, die Äste kappen

Eine Maßnahme ist genau dann begründet, wenn sich zeigen lässt, welchen Ast sie unterbricht. Das ist der Unterschied zwischen einem Maßnahmenplan und einer Wunschliste:

Jede dieser Maßnahmen lässt sich auf Anforderungen aus IEC 62443-4-2 und auf Annex I des Cyber Resilience Act abbilden. Das ist kein Zufall, sondern der eigentliche Nutzen einer sauber geführten Analyse: Die Normanforderung ist dann nicht mehr eine Checkliste, die von außen kommt, sondern die Begründung einer Entscheidung, die man ohnehin getroffen hat.

Was dieses Beispiel zeigt

Die Analyse umfasst sechs Schnittstellen, sechs Bedrohungskategorien, einen zerlegten Angriffspfad und sechs Maßnahmen. Das ist überschaubar — und trotzdem reicht es, um die drei Fragen zu beantworten, an denen es im Audit hängt: Was kann passieren, wie wahrscheinlich ist es, und warum genügt das, was wir dagegen tun?

Der Aufwand liegt nicht im Erstellen. Er liegt darin, diesen Stand aktuell zu halten, wenn die nächste Firmware-Version kommt, eine Schnittstelle dazukommt oder eine Produktvariante abzweigt.