Be Wise Apps
Read in English · Leer en español · Lire en français
Abschnitt 8.2 von 8.8 · Mittelstufe · 22 Min. Lesezeit
Bedrohungsmodellierung: STRIDE, Angriffsbäume und Datenflussdiagramme
Videolektion
5 Min. · auf Englisch gesprochen, mit UntertitelnNur anhören (Audio)
Transkript lesen
Mit Bedrohungsmodellierung werden Sicherheitsprinzipien zu konkreten Designentscheidungen. In dieser Lektion sehen Sie, wie ein Team einen Entwurf untersucht, findet, was schiefgehen könnte, und entscheidet, was dagegen zu tun ist.
Bevor eine Familie in den Urlaub fährt, geht meist jemand durchs Haus und fragt, was schiefgehen könnte. Ist die Hintertür abgeschlossen? Liegt der Ersatzschlüssel unter dem Blumentopf? Stapelt sich die Post und verrät, dass niemand zu Hause ist? Dann wird für jeden Punkt entschieden, was zu tun ist. Bedrohungsmodellierung ist derselbe Rundgang durch einen Softwareentwurf: zeichnen, wie Daten fließen, fragen, was ein Angreifer bei jedem Schritt tun könnte, und entscheiden.
Adam Shostack, der die Arbeit an der Bedrohungsmodellierung bei Microsoft leitete, reduziert sie auf vier Fragen. Erstens: Woran arbeiten wir? Gemeint ist ein Modell des Systems, meist ein Diagramm. Zweitens: Was kann schiefgehen? Sie finden Bedrohungen systematisch, nicht durch Raten. Drittens: Was werden wir dagegen tun? Jede Bedrohung bekommt eine Entscheidung. Viertens: Haben wir gute Arbeit geleistet? Sie prüfen das Modell und die Nacharbeit. Jede Methode, die diese vier Fragen beantwortet, ist Bedrohungsmodellierung.
Das übliche Modell ist ein Datenflussdiagramm. Rechtecke sind externe Entitäten, Ellipsen sind Prozesse, parallele Linien sind Datenspeicher, Pfeile sind Datenflüsse, und gestrichelte Kästen sind Vertrauensgrenzen. Dieses hier zeigt einen neuen Checkout. Die Kunden-App liegt außerhalb der Vertrauensgrenze der Plattform. Datenfluss eins, die Bestellung und ein Token, überquert diese Grenze zum API-Gateway. Innen lässt der Bestellservice den Warenkorb von der Preisgestaltung bepreisen und schreibt die Bestellung in seine Datenbank. Eine zweite, streng abgeschottete Zone umgibt den Zahlungsservice und seine Datenbank, die nur Zahlungstokens und Referenzen halten. Der Zahlungsservice bittet den Zahlungsanbieter, das Geld einzuziehen, und der Anbieter meldet das Ergebnis per Webhook. Beide Datenflüsse überqueren eine Grenze, und Angriffe folgen den Daten über Grenzen hinweg. Und beachten Sie Datenfluss neun am unteren Rand. Kartendaten gehen über gehostete Felder in der App direkt zum Anbieter, sodass sie nie in die Plattform gelangen.
Um Bedrohungen zu finden, nutzen die meisten Teams STRIDE, neunzehnhundertneunundneunzig bei Microsoft entwickelt. Jeder Buchstabe benennt eine Bedrohung, die eine Eigenschaft verletzt. Spoofing verletzt die Authentizität, etwa wenn ein fremder Prozess sich als Bestellservice ausgibt. Tampering verletzt die Integrität: Ein Client sendet eine veränderte Warenkorbsumme. Repudiation: Jemand bestreitet eine Handlung, und nichts beweist das Gegenteil. Information Disclosure verletzt die Vertraulichkeit, etwa wenn Adressen den falschen Kurieren angezeigt werden. Denial of Service verletzt die Verfügbarkeit. Und Elevation of Privilege verletzt die Autorisierung. Praktisch geht man jedes Element des Diagramms durch und richtet die meiste Aufmerksamkeit auf Datenflüsse, die Vertrauensgrenzen überqueren.
Angriffsbäume betrachten das System aus der Sicht des Angreifers. Die Wurzel ist ein Ziel: hier Essen zu bekommen, ohne zu bezahlen. Jedes Kind ist ein Weg, es zu erreichen. Diese drei sind Alternativen, und jede genügt: Gutscheine missbrauchen, den Preis ändern oder mit einer gestohlenen Karte zahlen. Das Zahlen mit einer gestohlenen Karte braucht beide Schritte zusammen. Der Angreifer muss Kartendaten kaufen und außerdem die Betrugsprüfungen bestehen, was teuer ist. Die Summe in der Client-Anfrage zu ändern, ist dagegen trivial, wenn der Server ihr vertraut. Der billigste Pfad bestimmt das Risiko. Deshalb ist es mehr wert, jeden Preis auf dem Server neu zu berechnen, als noch so viel Feinabstimmung der Kartenbetrugserkennung.
Das ist das Ergebnis einer neunzigminütigen Sitzung zu diesem Checkout. Ein geänderter Preis wird gemindert, indem der Server jede Summe neu berechnet. Ein falscher Aufrufer, der beim Zahlungsservice Erstattungen anfordert, wird durch Mutual TLS und Workload Identity gestoppt. Ein gefälschter Webhook „Zahlung erfolgreich“ wird gestoppt, indem man die Signatur des Anbieters prüft und den Status bestätigt. Das Erraten fremder Bestellnummern wird durch eine Eigentümerprüfung bei jeder Anfrage gestoppt. Und die Bedrohung für Kartennummern wird gar nicht gemindert. Sie wird beseitigt. Der billigste Weg, sie zu schützen, ist, sie nicht zu halten.
Bewerten Sie jede Bedrohung auf einer einfachen Skala nach Wahrscheinlichkeit und Auswirkung. Die schriftliche Begründung zählt mehr als die Zahl. Dann endet jede Bedrohung in einer von vier Entscheidungen: mindern, beseitigen, an jemanden übertragen, der besser aufgestellt ist, oder akzeptieren. Der häufigste Fehler ist die nicht dokumentierte Akzeptanz: Die Bedrohung wurde gefunden, niemand hat sie behoben, und niemand hat entschieden, es nicht zu tun. Erstellen Sie Bedrohungsmodelle beim Entwurf, wenn Änderungen am billigsten sind, und erneut, wann immer sich Vertrauensgrenzen, sensible Daten oder Authentifizierung ändern.
Der vollständige Abschnitt enthält die komplette Bedrohungstabelle zum Checkout und häufige Fehler, die Sie vermeiden sollten. Als Nächstes betrachten wir in Abschnitt acht Punkt drei Identität und Zugriff: Wer ruft auf, und was darf er tun? Bis gleich.
Was Sie wissen müssen
- Bedrohungsmodellierung beantwortet die vier Fragen von Shostack: Woran arbeiten wir, was kann schiefgehen, was werden wir dagegen tun, und haben wir gute Arbeit geleistet?
- Ein Datenflussdiagramm aus externen Entitäten, Prozessen, Datenspeichern, Datenflüssen und Vertrauensgrenzen ist das übliche Modell; Datenflüsse, die Vertrauensgrenzen überqueren, verdienen die meiste Aufmerksamkeit.
- STRIDE (Kohnfelder und Garg, Microsoft, 1999) benennt sechs Bedrohungskategorien, die jeweils eine Eigenschaft verletzen: Spoofing (Authentizität), Tampering (Integrität), Repudiation (Nichtabstreitbarkeit), Information Disclosure (Vertraulichkeit), Denial of Service (Verfügbarkeit) und Elevation of Privilege (Autorisierung).
- Angriffsbäume (Schneier, 1999) modellieren das Ziel eines Angreifers mit UND- und ODER-Knoten; der billigste Pfad durch den Baum zeigt, wo eine Gegenmaßnahme am meisten zählt.
- Bewerten Sie Bedrohungen nach Wahrscheinlichkeit und Auswirkung mit schriftlicher Begründung; DREAD kam aus der Mode, weil seine Werte subjektiv waren, und CVSS bewertet bekannte Schwachstellen, keine Bedrohungen im Design.
- Jede Bedrohung endet als gemindert, beseitigt, übertragen oder ausdrücklich akzeptiert von jemandem mit der nötigen Befugnis; erstellen Sie Bedrohungsmodelle beim Entwurf und erneut, wann immer sich Vertrauensgrenzen, Daten oder Authentifizierung ändern.
Was Bedrohungsmodellierung ist
Bedrohungsmodellierung ist die Tätigkeit, einen Entwurf darauf zu untersuchen, was mit seiner Sicherheit schiefgehen könnte, und zu entscheiden, was dagegen zu tun ist, bevor Angreifer oder Incidents es für Sie herausfinden. Sie ist der wichtigste Weg, auf dem Sicherheitsprinzipien zu konkreten Entscheidungen werden, und die direkteste Antwort auf die OWASP-Kategorie Insecure Design: Mängel, die sich auch durch noch so korrektes Programmieren nicht beheben lassen, weil die nötige Kontrolle nie entworfen wurde.
Adam Shostack, der die Arbeit an der Bedrohungsmodellierung bei Microsoft leitete und das Standardwerk dazu schrieb, reduziert die Tätigkeit auf vier Fragen. Woran arbeiten wir? (ein Modell des Systems, meist ein Diagramm). Was kann schiefgehen? (Bedrohungen, systematisch gefunden). Was werden wir dagegen tun? (jede Bedrohung mindern, beseitigen, übertragen oder akzeptieren). Haben wir gute Arbeit geleistet? (das Modell, die Bedrohungen und die Nacharbeit prüfen). Jede Methode, die die vier Fragen beantwortet, ist Bedrohungsmodellierung; der Rest dieses Abschnitts beschreibt die Techniken, mit denen die meisten Teams sie beantworten.
2020 veröffentlichte eine Gruppe von Fachleuten, darunter Shostack, das Threat Modeling Manifesto, nach dem Vorbild des Agilen Manifests. Es stellt eine Kultur des Findens und Behebens von Designproblemen über Checklisten-Compliance, Menschen und Zusammenarbeit über Prozesse und Werkzeuge, einen Weg des Verstehens über eine einmalige Sicherheitsmomentaufnahme, das Durchführen von Bedrohungsmodellierung über das Reden darüber und kontinuierliche Verfeinerung über eine einmalige Lieferung. Seine Botschaft: Bedrohungsmodellierung ist eine Gewohnheit des Teams, das das System baut, kein Dokument, das Außenstehende einmal im Jahr erstellen.
Das System modellieren: Datenflussdiagramme und Vertrauensgrenzen
Die erste Frage braucht ein Modell des Systems, das zeigt, wohin Daten fließen und wo sich das Vertrauen ändert. Die klassische Wahl ist ein Datenflussdiagramm (DFD) mit fünf Arten von Elementen: externe Entitäten (Menschen oder Systeme außerhalb Ihrer Kontrolle, als Rechtecke gezeichnet), Prozesse (Code, den Sie ausführen, als Kreise oder Ellipsen gezeichnet), Datenspeicher (Datenbanken, Dateien, Queues und Caches, zwischen zwei parallelen Linien gezeichnet), Datenflüsse (Pfeile, die zeigen, wie Daten zwischen den anderen Elementen fließen) und Vertrauensgrenzen (gestrichelte Linien oder Kästen, wo sich das Vertrauensniveau ändert).
DFDs eignen sich für die Bedrohungsmodellierung, weil Angriffe den Daten folgen: Jeder Datenfluss, der eine Vertrauensgrenze überquert, ist eine Stelle, an der ein Angreifer etwas einschleusen, abfangen oder wiederholt einspielen kann. Ein C4-Containerdiagramm aus Kapitel 4 ist ein guter Ausgangspunkt; ergänzen Sie die Vertrauensgrenzen, machen Sie jeden Pfeil zu einem Datenfluss mit Richtung und Beschriftung, und nehmen Sie die Speicher und Queues auf, die Containerdiagramme manchmal nur implizit lassen. Halten Sie das Diagramm auf der Ebene, auf der Bedrohungen gefunden werden: Ein Diagramm je wichtigem Feature oder Ablauf ist nützlicher als ein riesiges Diagramm von allem.
Bedrohungen mit STRIDE finden
STRIDE wurde 1999 bei Microsoft von Loren Kohnfelder und Praerit Garg als Merkhilfe entwickelt, damit Entwickler über Bedrohungen für ihre Produkte nachdenken. Jeder Buchstabe benennt eine Kategorie von Bedrohungen, und jede Kategorie ist die Verletzung einer Sicherheitseigenschaft. Das macht STRIDE nützlich: Es ist ein systematischer Denkanstoß, keine Liste bekannter Angriffe.
STRIDE und die Eigenschaft, die jede Bedrohung verletzt
| Bedrohung | Verletzte Eigenschaft | Beispiel Essenslieferung | Typische Gegenmaßnahmen |
|---|---|---|---|
| Spoofing (Vortäuschen einer Identität) | Authentizität | Ein Angreifer meldet sich mit einem per Credential Stuffing erbeuteten Passwort als Kunde an; ein fremder Prozess ruft den Zahlungsservice auf und gibt sich als Bestellservice aus. | Starke Authentifizierung (MFA, Passkeys), Rate Limits, Mutual TLS und Workload Identity zwischen Services. |
| Tampering (Manipulation) | Integrität | Ein Client sendet eine veränderte Warenkorbsumme; jemand verändert einen Zahlungs-Webhook oder eine Datenbankzeile. | Neuberechnung auf dem Server, Signaturen und MACs, TLS, Schreibzugriff nach Least Privilege. |
| Repudiation (Abstreiten) | Nichtabstreitbarkeit (Verantwortlichkeit) | Ein Kunde bestreitet, eine Bestellung aufgegeben zu haben; eine Support-Kraft bestreitet, eine Erstattung ausgelöst zu haben, und nichts beweist das Gegenteil. | Audit-Logs, die an authentifizierte Identitäten gebunden sind, Zeitstempel, manipulationssichere Speicherung. |
| Information Disclosure (Offenlegung von Informationen) | Vertraulichkeit | Eine API gibt Kundenadressen an Kuriere heraus, die nicht an diese Kunden liefern; Fehlermeldungen verraten Interna. | Autorisierung für jedes Objekt, Datenminimierung, Verschlüsselung, allgemein gehaltene Fehlermeldungen. |
| Denial of Service (Dienstverweigerung) | Verfügbarkeit | Bots überfluten den Checkout während der Abendspitze; eine teure Suchanfrage erschöpft die Datenbank. | Rate Limits und Kontingente, Timeouts, Bulkheads, Autoscaling, Kostenlimits für Abfragen. |
| Elevation of Privilege (Rechteausweitung) | Autorisierung | Ein Kunde ruft einen Endpoint für Restaurantmanager auf; eine Injection lässt einen Angreifer Code mit den Rechten des Service ausführen. | Autorisierung mit standardmäßiger Ablehnung, Eingabevalidierung, Sandboxing, Least Privilege. |
Ein praktischer Weg, STRIDE anzuwenden, ist STRIDE per Element: Gehen Sie jedes Element des DFD durch und stellen Sie nur die Fragen, die zu seinem Typ passen. Externe Entitäten können vorgetäuscht werden und Handlungen abstreiten; Prozesse sind allen sechs Kategorien ausgesetzt; Datenspeicher der Manipulation, der Offenlegung von Informationen und Denial of Service (und dem Abstreiten, wenn der Speicher ein Log ist); Datenflüsse der Manipulation, der Offenlegung von Informationen und Denial of Service. Wer die meiste Aufmerksamkeit auf Datenflüsse richtet, die Vertrauensgrenzen überqueren, hält die Übung fokussiert.
STRIDE findet Bedrohungen; es ordnet sie weder nach Rang noch wählt es Gegenmaßnahmen. Seine Kategorien überschneiden sich in der Praxis auch (eine vorgetäuschte Identität führt meist zur Offenlegung von Informationen oder zur Rechteausweitung), was keine Rolle spielt: Ziel ist es, die Bedrohung zu finden, nicht, sie perfekt einzuordnen. Für Datenschutzbedrohungen, etwa das Verknüpfen oder Identifizieren von Personen anhand harmlos wirkender Daten, übernimmt die Methode LINDDUN der KU Leuven die Rolle, die STRIDE für die Sicherheit spielt; sie wird bei Privacy by Design behandelt.
Angriffsbäume
Ein Angriffsbaum, bekannt gemacht durch Bruce Schneier in einem Artikel im Dr. Dobb’s Journal von 1999, betrachtet das System aus der Sicht des Angreifers. Die Wurzel ist ein Ziel, etwa Essen zu bekommen, ohne zu bezahlen; jedes Kind ist ein Weg, seinen Elternknoten zu erreichen. Die Kinder eines ODER-Knotens sind Alternativen; alle Kinder eines UND-Knotens werden zusammen benötigt. Blätter können mit Eigenschaften wie Kosten, nötigem Können oder der Frage, ob der Schritt überhaupt möglich ist, versehen werden, und diese Werte setzen sich im Baum nach oben fort: Die Kosten eines ODER-Knotens sind die seines billigsten Kindes, die Kosten eines UND-Knotens die Summe seiner Kinder.
Angriffsbäume ergänzen STRIDE gut. STRIDE geht den Entwurf Element für Element durch und ist gut für die Abdeckung; ein Angriffsbaum folgt einem motivierten Angreifer und zeigt gut, welcher Pfad am billigsten ist und wo eine Gegenmaßnahme deshalb am meisten bringt. Im Baum unten ist das Bezahlen mit einer gestohlenen Karte relativ teuer, weil es zwei Dinge zugleich braucht, während das Ändern des Preises in der Client-Anfrage trivial ist, wenn der Server ihm vertraut. Der billigste Pfad bestimmt das Risiko, deshalb ist es mehr wert, jeden Preis auf dem Server neu zu berechnen, als noch so viel Feinabstimmung der Kartenbetrugserkennung.
Risiken bewerten
Ein Bedrohungsmodell findet in der Regel mehr Bedrohungen, als ein Team auf einmal angehen kann, deshalb braucht jede eine Bewertung. Üblich ist es, Wahrscheinlichkeit (wie leicht, wie attraktiv, wie exponiert) und Auswirkung (was verloren geht, wenn es passiert: Geld, personenbezogene Daten, Verfügbarkeit, Ruf, rechtliche Risiken) auf einfachen Skalen wie niedrig, mittel und hoch einzuschätzen und in einer Matrix zu kombinieren. Der Wert der Bewertung liegt weniger in der Genauigkeit der Zahl als in einer schriftlichen Begründung, die andere hinterfragen können. Organisationen mit reifem Risikomanagement nutzen manchmal quantitative Methoden wie FAIR (Factor Analysis of Information Risk), um Risiko als Spanne erwarteter Verluste auszudrücken.
Zwei beliebte Abkürzungen sollte man kennen, weil sie oft falsch eingesetzt werden. DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability), einst bei Microsoft im Einsatz, bewertete jede Bedrohung nach fünf Faktoren (oft von 1 bis 10) und bildete den Durchschnitt. Es kam aus der Mode, auch bei Microsoft, weil verschiedene Personen dieselbe Bedrohung sehr unterschiedlich bewerteten und die gemittelte Zahl eine falsche Genauigkeit vorspiegelte; besonders Discoverability belohnt Verschleierung, was dem offenen Design widerspricht. CVSS, das von FIRST gepflegte Common Vulnerability Scoring System (Version 4.0, 2023), ist das richtige Werkzeug für eine andere Aufgabe: den Schweregrad einer bekannten Schwachstelle in einem Produkt zu bewerten, etwa eines Fehlers in einer Bibliothek. Sein Base Score beschreibt die Schwachstelle, nicht das Risiko einer Designbedrohung in Ihrem Kontext, deshalb sollte man es nicht verwenden, um die Ergebnisse eines Bedrohungsmodells zu ordnen.
Jede Bedrohung endet in einer von vier Entscheidungen: mindern (eine Kontrolle hinzufügen), beseitigen (das Feature oder die Daten entfernen, oft die beste Option), übertragen (jemanden, der besser aufgestellt ist, sie tragen lassen, etwa einen Zahlungsanbieter, der die Kartendaten hält) oder akzeptieren (festhalten, dass eine dazu befugte Person das Restrisiko akzeptiert hat, und warum). Die häufigste Schwachstelle ist die nicht dokumentierte Akzeptanz: Die Bedrohung wurde gefunden, niemand hat sie behoben, und niemand hat entschieden, es nicht zu tun.
Ausgearbeitetes Beispiel
Ausgearbeitetes Beispiel: ein Bedrohungsmodell für den Checkout
Das Team der Essenslieferplattform gestaltet den Bezahlvorgang neu, damit Kunden in der App mit Karte oder Wallet zahlen können. Der Architekt leitet eine 90-minütige Sitzung mit den Entwicklern von Bestellungen und Zahlungen, einem Product Owner und einem Security Champion. Das DFD unten beantwortet die erste Frage, woran wir arbeiten. Es zeigt zwei Vertrauensgrenzen: die Plattform als Ganzes und eine engere, streng abgeschottete Zahlungszone (beschriftet als PCI-Zone) um den Zahlungsservice und seine Datenbank, die Zahlungstokens und Referenzen halten und mit dem Zahlungsanbieter kommunizieren; ihre Abschottung hält den PCI-DSS-Geltungsbereich der Plattform klein. Die Kartendaten selbst (Datenfluss 9) gehen über gehostete Zahlungsfelder direkt von der App zum Zahlungsanbieter und gelangen nie in die Plattform.
| 1. Woran arbeiten wir? | Das Checkout-DFD unten: Kunden-App, API-Gateway, Bestellungen, Preisgestaltung, Zahlungen, zwei Datenbanken und der Zahlungsanbieter, mit zwei Vertrauensgrenzen (der Plattform und der PCI-Zone) und neun nummerierten Datenflüssen. |
|---|---|
| 2. Was kann schiefgehen? | STRIDE per Element für jeden Datenfluss, der eine Grenze überquert (1, 5, 6, 8 und 9), und für die Bestell-API, dazu der weiter oben gezeigte Angriffsbaum für Essen ohne Bezahlung. |
| 3. Was werden wir dagegen tun? | Jede Bedrohung wird bewertet und erhält eine Entscheidung (mindern, beseitigen, übertragen oder akzeptieren) und eine verantwortliche Person; die wichtigsten stehen in der Tabelle unten. |
| 4. Haben wir gute Arbeit geleistet? | Ein Review einen Monat später vergleicht das Modell mit dem, was gebaut wurde, und prüft, ob jedes hohe Risiko gemindert oder schriftlich akzeptiert wurde. |
Der billigste Weg, Kartennummern zu schützen, ist, sie nicht zu halten: Datenfluss 9 hält sie ganz aus der Plattform heraus, was Bedrohungen beseitigt, statt sie zu mindern.
Ausgewählte Bedrohungen aus dem Checkout-Bedrohungsmodell
| ID und Ort | STRIDE | Bedrohung | Risiko | Entscheidung und Gegenmaßnahme |
|---|---|---|---|---|
| T1, Datenfluss 1 | S | Credential Stuffing übernimmt Konten mit gespeicherten Karten. | Hoch | Mindern: Passkeys oder MFA auf neuen Geräten; Rate Limits je Konto und IP; Prüfung auf geleakte Passwörter. |
| T2, Datenflüsse 1 und 2 | T | Der Client sendet einen veränderten Preis, Rabatt oder eine veränderte Liefergebühr. | Hoch | Mindern: Der Bestellservice ignoriert Client-Preise; die Preisgestaltung berechnet neu aus Speisekarten und Gutscheinen; die Zahlung wird über die Summe des Servers angelegt. |
| T3, Datenfluss 5 | S, E | Ein anderer interner Service oder ein Angreifer im Netzwerk bittet den Zahlungsservice, beliebige Beträge zu autorisieren oder zu erstatten. | Hoch | Mindern: Mutual TLS mit Workload Identity; der Zahlungsservice akzeptiert Autorisierungen nur von der Identität des Bestellservice, gebunden an eine Bestell-ID und einen Betrag. |
| T4, Datenfluss 8 | S, T | Ein gefälschter Webhook „Zahlung erfolgreich“ markiert eine unbezahlte Bestellung als bezahlt. | Hoch | Mindern: Signatur und Zeitstempel des Anbieters prüfen; den Status über die API des Anbieters bestätigen, bevor die Bestellung freigegeben wird; jedes Event nur einmal verarbeiten. |
T5, GET /orders/{id} | I | Das Durchprobieren von Bestell-IDs legt die Adressen anderer Kunden offen (Broken Object Level Authorization). | Hoch | Mindern: Eigentümerprüfung bei jeder Anfrage; zufällige Kennungen nur als ergänzende Maßnahme. |
| T6, Bestell-DB | I | Bestelldatensätze mit Adressen fließen aus einem Backup oder über ein zu weit berechtigtes Analysekonto ab. | Mittel | Mindern: Verschlüsselung im Ruhezustand mit KMS-Schlüsseln, Konten nach Least Privilege, Backups in einem separaten Konto. |
| T7, Datenfluss 1 | D | Bots erschöpfen in der Abendspitze die Kapazität des Checkouts. | Mittel | Mindern: Rate Limits und Bot-Erkennung an der Edge, reservierte Kapazität für den Checkout, bei Bedarf ein virtueller Warteraum. |
| T8, Bestellungen | R | Ein Kunde bestreitet, eine Bestellung aufgegeben zu haben, und es gibt keinen Nachweis. | Niedrig | Mindern: Audit-Event mit Benutzer-ID, Gerät, Zeit und Bestelldetails, aufbewahrt gemäß Policy. |
| T9, Datenfluss 9 | I | Kartennummern, die durch die Plattform laufen, würden jede Komponente in den PCI-DSS-Geltungsbereich bringen. | Design | Beseitigen und übertragen: Gehostete Felder senden Kartendaten direkt an den Anbieter; die Plattform speichert nur Tokens und Referenzen. |
Die Antworten auf die letzten beiden Fragen sind ebenso wichtig wie die Tabelle. Jede Gegenmaßnahme wird zu einem Backlog-Eintrag mit einer verantwortlichen Person; T3 und T4 werden außerdem zu Sicherheitsszenarien mit automatisierten Tests (ein Webhook mit ungültiger Signatur muss abgelehnt werden; ein Aufruf des Zahlungsservice von einer anderen Identität als der des Bestellservice muss scheitern). Die beiden Architekturentscheidungen, gehostete Zahlungsfelder und Mutual TLS zwischen Bestell- und Zahlungsservice, werden als ADRs festgehalten. Für die vierte Frage prüft das Team das Modell einen Monat später gegen das, was tatsächlich gebaut wurde, und der Security Champion kontrolliert, ob jeder Punkt mit hohem Risiko entweder gemindert oder ausdrücklich akzeptiert wurde.
Wann und wie oft man Bedrohungsmodelle erstellt
Bedrohungsmodellierung zahlt sich am meisten beim Entwurf aus, wenn eine geänderte Entscheidung nur einen Whiteboard-Schwamm kostet. Danach sollte sie wiederholt werden, wann immer sich etwas Wesentliches ändert: eine neue Vertrauensgrenze oder externe Integration, eine neue Art sensibler Daten, eine Änderung an Authentifizierung oder Autorisierung, eine neue Deployment-Umgebung oder der Wechsel von einem Monolithen zu Services. Eine sinnvolle Regel ist, „Ändert das unser Bedrohungsmodell?“ zu einer festen Frage in Design-Reviews und in der Vorlage für Architecture Decision Records zu machen und das Modell jedes Systems mindestens jährlich und nach jedem Sicherheitsvorfall zu überprüfen.
Der Aufwand sollte verhältnismäßig sein, im Sinne des risikogetriebenen Ansatzes aus Kapitel 1. Ein neuer Microservice, der Zahlungen verarbeitet, verdient eine halbtägige Sitzung mit vollständigem DFD; ein zusätzliches Feld in einer öffentlichen Speisekarte braucht fünf Minuten und einen kurzen STRIDE-Blick auf den geänderten Datenfluss. Viele Teams halten ihr DFD als Code neben dem System (OWASP Threat Dragon und das Threat Modeling Tool von Microsoft sind kostenlose Diagrammwerkzeuge, und Bibliotheken wie OWASP pytm erzeugen Diagramme und mögliche Bedrohungen aus Code), damit das Modell zusammen mit dem System, das es beschreibt, geprüft und aktualisiert wird.
Prüfen Sie Ihr Verständnis
Welche STRIDE-Kategorien gelten bei STRIDE per Element für einen Datenfluss?
Tampering, Information Disclosure und Denial of Service: Daten bei der Übertragung können verändert, gelesen oder blockiert werden.
Warum ist CVSS das falsche Werkzeug, um die in einem Bedrohungsmodell gefundenen Bedrohungen zu ordnen?
CVSS bewertet den Schweregrad einer bestimmten bekannten Schwachstelle in einem Produkt; es berücksichtigt weder Ihr Design noch Ihre Assets und Ihren Kontext und misst daher nicht das Risiko einer Bedrohung auf Designebene.
Wie werden in einem Angriffsbaum die Kosten eines UND-Knotens aus seinen Kindern berechnet, und warum ist das wichtig?
Sie sind die Summe der Kosten seiner Kinder, weil alle Schritte nötig sind. UND-Knoten sind deshalb meist teure Pfade, während das billigste Kind eines ODER-Knotens das Risiko bestimmt.
Was ist der häufigste Fehler im vierten Schritt der Bedrohungsmodellierung?
Bedrohungen, die gefunden, aber weder behoben noch ausdrücklich akzeptiert wurden: Niemand ist für sie verantwortlich, und niemand hat entschieden, mit ihnen zu leben.
Quellen und weiterführende Literatur
Haben Sie eine Frage zu diesem Abschnitt? ArchitectBot, der KI-Lernassistent des Kurses, antwortet zuerst aus dem Kurs.
Fragen: „Wie würde ich eine erste Sitzung zur Bedrohungsmodellierung für ein neues Zahlungsfeature durchführen, und was sollte dabei herauskommen?“