Ein Feature mit STRIDE in einer Arbeitssitzung bedrohungsmodellieren

Ziel

Die sicherheitsrelevanten Arten, in denen ein Feature scheitern kann, finden, bevor es gebaut wird, in einer Sitzung, die kurz genug ist, dass ein Team sie für das nächste Feature wiederholt, und Entscheidungen hinterlassen, die ein späteres Review prüfen kann.

Voraussetzungen

Ein Feature oder eine Änderung mit bekanntem Umfang; die Personen, die seine Datenflüsse kennen (üblicherweise eine entwickelnde und eine betreibende Person); ein Whiteboard oder Diagrammwerkzeug. Die vier Fragen des Threat Modeling Manifesto dienen als Agenda: Woran arbeiten wir, was kann schiefgehen, was unternehmen wir dagegen, haben wir gut genug gearbeitet.

Schritte

1. Modellieren: ein Datenflussdiagramm des Features zeichnen mit externen Entitäten, Prozessen, Datenspeichern, Datenflüssen und Vertrauensgrenzen (Browser zu Server, Dienst zu Datenbank, ein Mandant zu einem anderen). Das OWASP-Cheat-Sheet nennt das DFD den wohl gängigsten Ansatz zur Systemmodellierung und benennt Vertrauensgrenzen, Flüsse, Speicher, Prozesse und externe Entitäten als die üblichen Angriffspunkte.
2. Die Elemente und Grenzübertritte nummerieren, damit sich jede Bedrohung auf einen davon beziehen kann.
3. Aufzählen: für jedes Element die sechs STRIDE-Fragen stellen. Die Microsoft-Dokumentation definiert die sechs Kategorien; das OWASP-Cheat-Sheet tabelliert, welche Eigenschaft jede davon verletzt: Spoofing (Authentifizierung), Tampering (Integrität), Repudiation (Nachvollziehbarkeit), Information Disclosure (Vertraulichkeit), Denial of Service (Verfügbarkeit), Elevation of Privilege (Autorisierung). Pro Bedrohung eine Zeile schreiben: Element, Kategorie, was eine angreifende Person tut.
4. Grob nach Wahrscheinlichkeit und Auswirkung einstufen. Die Sitzung nicht mit Bewertungspräzision verbringen; das Cheat-Sheet merkt an, dass beides schwer zu berechnen ist.
5. Reagieren: für jede Bedrohung eine der vier vom Cheat-Sheet genannten Reaktionen festhalten (mindern, eliminieren, übertragen, akzeptieren) und für Minderungsmassnahmen eine prüfbare Anforderung wie "jedes Schreiben in Speicher 3 trägt die Mandanten-ID aus der Sitzung; abgedeckt durch Test X".
6. Überprüfen: "haben wir gut genug gearbeitet" mit den Fragen des Cheat-Sheets beantworten: entspricht das Diagramm dem System, hat jede Bedrohung eine Reaktion, lässt sich jede Minderungsmassnahme testen.
7. Das Diagramm und die Bedrohungstabelle neben dem Design ablegen (einem ADR oder Design-Dokument) und sie erneut aufsuchen, wenn sich eine Vertrauensgrenze ändert.

Erwartetes Ergebnis

Ein einseitiges Diagramm, eine Bedrohungstabelle sowie eine Liste von Anforderungen und akzeptierten Risiken mit zugeordneten Namen. Spätere Reviews können prüfen, ob die Minderungsmassnahmen existieren, statt die Bedrohungen erneut herzuleiten.

Grenzen und Prüfbasis

STRIDE liefert Kategorien, keine konkreten Angriffe; es bringt Missbrauch der Geschäftslogik oder Lieferkettenprobleme nur zutage, wenn das Modell diese Flüsse einschliesst. Das Ergebnis ist nur so gut wie das Diagramm. Das Verfahren ist eine Zusammenführung der zitierten Anleitungen; es wird keine Zahl gefundener Mängel pro Sitzung behauptet.