Threat Modeling mit der STRIDE-Methodik praktisch einsetzen

1. Warum Threat Modeling ohne Struktur meist scheitert

Ein informeller Sicherheits-Workshop, bei dem Teilnehmer frei über mögliche Angriffe auf ein System nachdenken sollen, produziert in der Praxis häufig eine ungleichmäßige Ergebnisliste: Manche einzelnen Komponenten werden ausführlich diskutiert, weil ein Teilnehmer sich zufällig gut damit auskennt, während andere, ebenso kritische Komponenten komplett unbesprochen bleiben, weil niemand im Raum spontan an sie gedacht hat. Diese Zufälligkeit ist das eigentliche, strukturelle Kernproblem einer unstrukturierten Bedrohungsanalyse, nicht etwa ein Mangel an Fachwissen der jeweils Beteiligten.

STRIDE löst dieses Problem, indem es sechs feste Bedrohungskategorien vorgibt, die für jede einzelne Systemkomponente systematisch durchgegangen werden, unabhängig davon, ob ein Teilnehmer spontan eine passende Bedrohung dazu einfällt oder nicht. Diese erzwungene Vollständigkeit ist tatsächlich der eigentliche Wert der gesamten Methodik, mehr noch als die einzelnen Kategorien für sich genommen selbst, die inhaltlich größtenteils bereits aus allgemeinem Sicherheitswissen bekannt sind, aber ohne diese feste Struktur selten wirklich systematisch angewendet werden.

2. Die sechs STRIDE-Kategorien im Detail

Spoofing bezeichnet das Vortäuschen einer falschen Identität, etwa ein Angreifer, der sich als legitimer Nutzer oder als vertrauenswürdiger Dienst ausgibt. Tampering steht für unbefugte Veränderung von Daten oder Code, sowohl während der Übertragung als auch im Ruhezustand. Repudiation beschreibt die Fähigkeit eines Angreifers, eine durchgeführte Aktion nachträglich glaubhaft abzustreiten, weil keine ausreichende Protokollierung existiert, die das Gegenteil belegen könnte.

Information Disclosure meint die ungewollte Preisgabe von Daten an Unbefugte, etwa durch zu ausführliche Fehlermeldungen oder fehlende Zugriffskontrollen. Denial of Service beschreibt die Fähigkeit, ein System für legitime Nutzer unbrauchbar zu machen, ohne notwendigerweise Daten zu kompromittieren. Elevation of Privilege schließlich bezeichnet den Übergang von eingeschränkten zu weitreichenderen Berechtigungen, etwa von einem normalen Nutzerkonto zu Administratorrechten, ohne dass dieser Übergang legitim vorgesehen war.

3. Ein praktischer Workshop-Ablauf im Team

Der Workshop beginnt mit einem groben Architekturdiagramm der zu analysierenden Anwendung, das die wichtigsten Komponenten (Frontend, API, Datenbank, externe Dienste) und die Datenflüsse zwischen ihnen zeigt, erstellt idealerweise gemeinsam zu Beginn der Sitzung statt vorab von einer einzelnen Person. Dieses gemeinsame Erstellen stellt sicher, dass alle Teilnehmer dieselbe Vorstellung vom System haben, bevor die eigentliche Bedrohungsanalyse beginnt.

Anschließend wird für jede Komponente und jede Datenflusslinie systematisch jede der sechs STRIDE-Kategorien durchgegangen, mit der einfachen Leitfrage "Könnte hier ein Spoofing-Angriff stattfinden, und wenn ja, wie?" für jede Kategorie einzeln. Ein Moderator sollte dabei explizit auch Kategorien ansprechen, für die auf den ersten Blick keine Bedrohung erkennbar ist, um zu vermeiden, dass eine Kategorie vorschnell als irrelevant abgehakt wird, ohne wirklich durchdacht worden zu sein.

# STRIDE-Analyse: Bestell-API

## Komponente: POST /api/orders

| Kategorie | Bedrohung | Risiko | Maßnahme |
|-----------|-----------|--------|-----------|
| Spoofing | Gefälschter API-Key eines anderen Händlers | Hoch | Key-Rotation + Rate-Limiting pro Key |
| Tampering | Manipulierter Bestellbetrag im Request-Body | Hoch | Serverseitige Preisvalidierung gegen DB |
| Repudiation | Bestellung wird später abgestritten | Mittel | Audit-Log mit Zeitstempel + Signatur |
| Info Disclosure | Fehlermeldung verrät interne Struktur | Niedrig | Generische Fehlermeldungen in Prod |
| DoS | Massenhafte Bestell-Requests | Mittel | Rate-Limiting pro Nutzerkonto |
| Elevation | Normaler Nutzer setzt Admin-Flag | Hoch | DTO statt direktem Entity-Binding |

4. Von der Bedrohungsliste zur priorisierten Maßnahmenliste

Eine vollständige STRIDE-Analyse erzeugt für ein mittelgroßes System schnell dutzende identifizierte Bedrohungen, von denen nicht jede dieselbe Dringlichkeit hat, weshalb eine anschließende Priorisierung nach Eintrittswahrscheinlichkeit und potenziellem Schaden unverzichtbar ist, statt alle Punkte gleichrangig in ein Backlog zu schreiben. Eine einfache Risikomatrix mit den Achsen Wahrscheinlichkeit und Schadenshöhe reicht meist aus, um die kritischsten Bedrohungen von den eher theoretischen zu trennen.

Für jede priorisierte Bedrohung sollte eine konkrete, umsetzbare Gegenmaßnahme formuliert werden, nicht nur eine allgemeine Empfehlung wie "besser absichern", sondern ein spezifischer, testbarer Schritt wie "Preisvalidierung serverseitig gegen die Datenbank statt Vertrauen auf den Client-Wert". Diese Konkretisierung ist der entscheidende Schritt, der aus einer Analyse tatsächlich umsetzbare Arbeit macht, statt als reines Dokumentationsartefakt in einer Schublade zu verschwinden.

5. Threat Models als lebende Dokumente statt Einmal-Übung

Ein Threat Model, das einmalig erstellt und danach nie wieder angeschaut wird, verliert mit jeder architektonischen Änderung an Aussagekraft, bis es irgendwann ein völlig veraltetes Bild des tatsächlichen Systems zeichnet. Ein sinnvoller Rhythmus ist, das bestehende Threat Model bei jeder größeren architektonischen Änderung (neue externe Integration, neue Datenflüsse) gezielt zu aktualisieren, statt es komplett neu zu erstellen.

Zusätzlich lohnt sich eine jährliche, vollständige Neubewertung, selbst wenn keine großen architektonischen Änderungen stattgefunden haben, da sich die gesamte Bedrohungslandschaft selbst kontinuierlich weiterentwickelt und regelmäßig neue Angriffsmuster entstehen, die zum Zeitpunkt der ursprünglichen Analyse noch gar nicht relevant waren.

6. Tool-gestütztes Threat Modeling vs. reiner Workshop-Ansatz

Werkzeuge wie Microsoft Threat Modeling Tool oder OWASP Threat Dragon bieten eine strukturierte, diagrammbasierte Oberfläche für die STRIDE-Analyse, die automatisch generische Bedrohungsvorschläge pro Komponententyp liefert und dadurch die Vollständigkeit zusätzlich unterstützt, verglichen mit einer rein manuellen Whiteboard-Session. Diese generischen Vorschläge ersetzen aber nicht das team-eigene Fachwissen über die konkrete Systemarchitektur, sondern dienen als Ausgangspunkt, der anschließend team-spezifisch verfeinert werden muss.

Für kleinere Teams oder eine erste Einführung in die Methodik ist ein einfacher Whiteboard-Workshop ohne spezialisiertes Tool oft der pragmatischere Einstieg, da die Lernkurve für ein neues Tool zusätzlich zur neuen Methodik selbst die Einstiegshürde unnötig erhöhen kann.

7. Häufige Fehler bei der praktischen Anwendung

Ein verbreiteter Fehler ist, die Analyse auf Anwendungsebene durchzuführen, aber die zugrunde liegende Infrastruktur (Cloud-Konfiguration, Netzwerksegmentierung, CI/CD-Pipeline) komplett auszusparen, obwohl gerade dort viele reale Sicherheitsvorfälle ihren Ursprung haben. Ein vollständiges Threat Model sollte beide Ebenen einbeziehen, auch wenn das bedeutet, mehrere separate Sitzungen mit unterschiedlichen Fachexperten durchzuführen.

Ein zweiter häufiger Fehler ist, das Threat Model ausschließlich vom Sicherheitsteam erstellen zu lassen, ohne die tatsächlichen Entwickler der jeweiligen Komponente einzubeziehen, wodurch wichtiges Detailwissen über die reale Implementierung fehlt und die Analyse oberflächlich bleibt. Die wertvollsten und praxisnächsten Erkenntnisse entstehen meist genau im direkten Dialog zwischen Sicherheitsexpertise und konkretem Implementierungswissen der Entwickler.

8. Threat Modeling in den regulären Entwicklungsprozess integrieren

Threat Modeling entfaltet den größten Nutzen, wenn es fester Bestandteil der Design-Phase neuer Features wird, statt eine isolierte, jährliche Sonderveranstaltung zu bleiben, die vom eigentlichen Entwicklungsrhythmus komplett losgelöst ist. Ein pragmatischer Ansatz ist, für jedes neue Feature mit nennenswerter Sicherheitsrelevanz (neue externe Schnittstelle, neue Authentifizierungslogik) eine verkürzte, fokussierte STRIDE-Analyse als verpflichtenden Schritt vor der Implementierung einzuplanen, statt die vollständige Methodik nur für das Gesamtsystem einmal jährlich anzuwenden.

Ein benannter Security Champion pro Team, der die STRIDE-Grundlagen beherrscht und diese verkürzten Analysen moderiert, senkt die Einstiegshürde erheblich gegenüber der Anforderung, dass jedes Team-Mitglied die Methodik vollständig selbstständig anwenden können muss, und verankert Threat Modeling nachhaltig als normalen Teil des Entwicklungsalltags statt als externe, aufgezwungene Zusatzaufgabe.

9. STRIDE im Überblick

Die folgende Tabelle fasst die sechs Kategorien mit typischen Gegenmaßnahmen zusammen.

10. Zusammenfassung

11. FAQ: STRIDE: Das Wichtigste auf einen Blick