Nicht raten, was schiefgehen könnte

Threat Modeling verbindet ein verstandenes System mit strukturierten Fragen zu Bedrohungen, Maßnahmen und verbleibenden Risiken.

METHODENROLLE: Hier lernst du die Methode: System verstehen, mögliche Threats finden, Maßnahmen ableiten und das Ergebnis prüfen.

TAGESGESCHÄFT

Eine neue Schnittstelle soll „nur schnell“ angebunden werden

Das Fachverfahren erhält einen externen Dienst. Funktional ist die Änderung klein. Sicherheitlich entstehen aber neue Datenflüsse, eine neue Vertrauensgrenze und neue Annahmen. Threat Modeling macht diese Veränderung besprechbar, bevor aus einer Annahme ein Incident wird.

METHODENNEUTRALER KERN

Vier Fragen reichen als Einstieg

Woran arbeiten wir?

Scope, System, Nutzer, Abhängigkeiten, Annahmen und Vertrauensgrenzen verstehen.

Was kann schiefgehen?

Bedrohungen, Missbrauch, Fehlannahmen und unerwünschte Wirkungen identifizieren.

Was tun wir dagegen?

Risiken priorisieren und Maßnahmen, Designänderungen oder Tests bestimmen.

War es gut genug?

Ergebnis prüfen, Annahmen und Restrisiken nachhalten und bei Änderungen wiederholen.

VERTIEFUNG

STRIDE hilft bei der Bedrohungssuche – ersetzt aber kein Threat Modeling

STRIDE steht für Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege. Die Merkhilfe strukturiert mögliche Bedrohungsarten. Die Methode ersetzt weder das Systemmodell noch die Risikobewertung oder die Entscheidung über Maßnahmen. OWASP weist ausdrücklich darauf hin, dass es verschiedene Threat-Modeling-Methoden gibt und keinen einzigen offiziellen OWASP-Ansatz.

KONTINUIERLICH

Threat Modeling darf mit dem System mitwachsen

Das von Autodesk stammende Continuous Threat Modeling (CTM) beschreibt Threat Modeling als evolutionäre, dynamische Methodik für sich verändernde Architekturen und agile Teams. Das ist für unser Framework vor allem als Prinzip interessant: Eine relevante Änderung ist ein Anlass, das bestehende Modell gezielt neu zu betrachten – nicht jedes Mal bei null zu beginnen.

PRAXISQUELLEN

Beispiele sind Lernmaterial – keine normative Methode

Das von dir genannte Video ist verifizierbar als „Live Threat Modeling of an Online Food Ordering System“ von Luis Servin, veröffentlicht durch Open Security Summit am 15.02.2023. Die Seite threatmodel.us beschreibt einen DEF-CON-34-Wettbewerb, bei dem Teilnehmer einen dokumentierten Systementwurf prüfen, Findings berichten und konkrete Guidance liefern. Beides nutzen wir als Praxis-/Lernquelle, nicht als normative Grundlage.

OUTPUT

Was aus der Sitzung herauskommen muss

Scope und Systemmodell, dokumentierte Annahmen, identifizierte Threats, priorisierte Folgeschritte und nachvollziehbare Entscheidungen. Das Ergebnis gehört in das Threat Model und – sobald ein bewertbares Geschäftsszenario entsteht – in das Risk Register.

Threat Model

Ergebnis strukturiert festhalten.

Risikoregister

Relevante Szenarien bewerten und entscheiden.

LERNHILFE · VOR STRIDE

Erst das System verstehen – dann nach Bedrohungen fragen

STRIDE beantwortet nicht die Frage, was unser System ist. Deshalb beginnen wir mit einfachen, langlebigen Fragen zu Schutzobjekt, Akteur, Zweck, System, Ein-/Ausgängen, Datenfluss und Vertrauensgrenzen.

WAS?

Was ist schützenswert: Information, Funktion, Asset oder Geschäftsleistung?

WER?

Welche Person, Rolle, Organisation oder welches System interagiert damit?

WARUM?

Welcher legitime Geschäfts- oder Anwendungszweck steckt dahinter?

WOMIT?

Welche Systeme, Dienste, Komponenten und Abhängigkeiten sind beteiligt?

WO?

Wo liegen Entry/Exit Points und Vertrauensgrenzen (Trust Boundaries)?

WIE?

Wie bewegen sich Daten, Identitäten und Aktionen durch das System?

WAS KANN SCHIEFGEHEN?

Jetzt hilft STRIDE, die Bedrohungssuche systematisch zu strukturieren.

Wichtig: Diese sieben Fragen sind unsere didaktische Zusammenfassung etablierter Threat-Modeling-Grundlagen. Sie werden nicht als eigenständiger externer Standard ausgegeben.

Beispiel: Eine Rechnung wird hochgeladen und freigegeben

STRIDE	Einfache Frage	Im Beispiel
S – Spoofing	Kann sich jemand als jemand anderes ausgeben?	Kann jemand mit fremden Zugangsdaten eine Rechnung einstellen oder freigeben?
T – Tampering	Kann jemand etwas unbemerkt verändern?	Können IBAN oder Betrag nach der Prüfung verändert werden?
R – Repudiation	Kann jemand eine Handlung später bestreiten?	Können wir nachvollziehen, wer eingestellt, geändert und freigegeben hat?
I – Information Disclosure	Kann jemand Informationen sehen, die er nicht sehen darf?	Können Unberechtigte Rechnungs- oder Bankdaten lesen?
D – Denial of Service	Kann die Nutzung verhindert werden?	Was passiert, wenn das System zum Zahlungslauf nicht verfügbar ist?
E – Elevation of Privilege	Kann jemand mehr Rechte erhalten als vorgesehen?	Kann ein normaler Benutzer eine Freigaberolle erlangen oder umgehen?