Begriff
Threat Modeling
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Bevor du eine Burg baust, überlegst du: "Wie würde ich hier einbrechen?" "Würde ich über die Mauer klettern? Oder den Tunnel graben? Oder das Tor rammen?" Threat Modeling ist genau das für Software. Man setzt sich vor dem Programmieren zusammen und spielt "Hacker". Man malt ein Diagramm (Whiteboard) und sucht Schwachstellen. "Was passiert, wenn die Datenbank geklaut wird?" "Was, wenn der Admin sein Passwort verliert?" Das Ziel: Löcher stopfen, bevor sie existieren (Design Phase).
Merksatz: Ein strukturierter Prozess zur Identifizierung, Aufzählung und Priorisierung potenzieller Bedrohungen und Sicherheitslücken in einem System, üblicherweise während der Designphase.
Das bekannteste Modell ist STRIDE (von Microsoft):
- Spoofing: "Ich bin wer anders."
- Tampering: "Ich ändere Daten."
- Repudiation: "Ich war das nicht." (Fehlende Logs).
- Information Disclosure: "Datenleck."
- Denial of Service: "System lahmlegen."
- Elevation of Privilege: "Ich bin jetzt Admin." Du gehst jede Komponente durch und fragst: "Ist sie anfällig für S? Für T? Für R...?"
1. Data Flow Diagrams (DFD)
Man zeichnet, wie Daten fließen. User -> Webserver -> Datenbank. Jede Linie (Datenfluss) ist ein Angriffsvektor ("Man in the Middle?"). Jeder Kasten (Speicher) ist ein Ziel ("SQL Injection?").
2. Attack Trees
Ein Baumdiagramm des Bösen. Wurzel: "Bankkonto hacken". Äste: "Online-Banking knacken" ODER "Kreditkarte klauen" ODER "Banküberfall". Hilft zu verstehen, welcher Weg für den Hacker am billigsten ist ("Path of least resistance").
1. DREAD: Die Risiko-Mathe
Nachdem man mit STRIDE eine Bedrohung gefunden hat, muss man sie bewerten. Wie schlimm ist sie? Dafür gibt es das DREAD-Rating (Werte von 1 bis 10 für jedes Feld):
Damage Potential: Wie groß ist der Schaden?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Das bekannteste Modell ist STRIDE (von Microsoft): Spoofing: "Ich bin wer anders." Tampering: "Ich ändere Daten." Repudiation: "Ich war das nicht." (Fehlende Logs). Information Disclosure: "Datenleck." Denial of Service: "System lahmlegen." Elevation of Privilege: "Ich bin jetzt Admin." Du gehst jede Komponente durch und fragst: "Ist sie anfällig für S? Für T? Für R...?"Reproducibility: Wie leicht lässt sich der Angriff wiederholen?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Das bekannteste Modell ist STRIDE (von Microsoft): Spoofing: "Ich bin wer anders." Tampering: "Ich ändere Daten." Repudiation: "Ich war das nicht." (Fehlende Logs). Information Disclosure: "Datenleck." Denial of Service: "System lahmlegen." Elevation of Privilege: "Ich bin jetzt Admin." Du gehst jede Komponente durch und fragst: "Ist sie anfällig für S? Für T? Für R...?"- Exploitability: Wie viel Talent braucht der Hacker? (Script-Kiddie vs. Geheimdienst).
Affected Users: Wie viele Leute betrifft es?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Das bekannteste Modell ist STRIDE (von Microsoft): Spoofing: "Ich bin wer anders." Tampering: "Ich ändere Daten." Repudiation: "Ich war das nicht." (Fehlende Logs). Information Disclosure: "Datenleck." Denial of Service: "System lahmlegen." Elevation of Privilege: "Ich bin jetzt Admin." Du gehst jede Komponente durch und fragst: "Ist sie anfällig für S? Für T? Für R...?"- Discoverability: Wie leicht findet man die Lücke? Der Durchschnittswert ergibt das Risiko. Aber Vorsicht: DREAD ist oft subjektiv. In modernen Firmen nutzt man eher das CVSS (Common Vulnerability Scoring System) für eine objektivere Bewertung.
2. Trust Boundaries
Der wichtigste Teil eines Threat Model Diagramms sind die Trust Boundaries. Das sind gestrichelte Linien, die Bereiche mit unterschiedlichem Vertrauensniveau trennen (z. B. Internet vs. Privates Firmennetz). Jedes Mal, wenn ein Datenfluss (Pfeil) eine Trust Boundary kreuzt, muss zwingend eine Validierung stattfinden. Wenn ein Pfeil vom Bereich "Anonymer User" in den Bereich "Interne Datenbank" geht, ohne dass dazwischen eine Boundary mit Authentifizierung liegt, hast du einen kritischen Architektur-Fehler gefunden, ohne eine einzige Zeile Code geschrieben zu haben.
3. Rapid Threat Modeling in Agile/DevOps
In einem Agile-Umfeld kann man nicht zwei Wochen lang Diagramme malen. Man nutzt Evil User Stories. Normal: "Als User möchte ich mich einloggen." Evil: "Als Hacker möchte ich mich einloggen, indem ich die Datenbank per SQL-Injection umgehe." Diese Evil Stories fließen direkt in den Backlog ein. Security wird so zu einem normalen Feature, das "Definition of Done" sein muss. Tools wie OWASP Threat Dragon oder IriusRisk helfen dabei, diesen Prozess zu automatisieren, indem sie auf Basis der Cloud-Architektur (AWS/Azure) automatisch passende Bedrohungen vorschlagen.
Quick-Check
Wann machen?
Am Anfang ("Shift Left"). Ein Design-Fehler ("Wir verschlüsseln nichts") ist später extrem teuer zu fixen.Wer macht das?
Nicht nur Security-Leute. Entwickler und Architekten müssen dabei sein, denn sie kennen das System am besten.Einmalig?
Nein. Jedes Mal, wenn sich die Architektur ändert ("Wir fügen eine neue API hinzu"), muss man das Threat Model aktualisieren.