Bedrohungsmodelle

Was ein Bedrohungsmodell ist

Ein Bedrohungsmodell ist die strukturierte Antwort auf vier Fragen, die Adam Shostack (Microsoft, später Independent) in seinem Buch Threat Modeling: Designing for Security (2014) prägnant zusammengefasst hat:

1. Was bauen wir? — Architektur, Datenflüsse, Vertrauensgrenzen.
2. Was kann schiefgehen? — welche Bedrohungen sind plausibel?
3. Was tun wir dagegen? — welche Schutzmaßnahmen wählen wir aus?
4. Haben wir das gut gemacht? — Review, Test, Wiedervorlage.

Das Modell ist kein Dokument, sondern ein Gespräch — auch wenn am Ende oft ein Diagramm oder eine Tabelle entsteht. Die wertvollste Phase ist die zweite: wer wirklich nachdenkt, was schiefgehen kann, findet Lücken, die kein automatischer Scanner sieht.

Für Web-Entwickler:innen läuft Bedrohungsmodellierung typischerweise im Architektur- und Design-Review. Für Nutzer:innen ist es eine kürzere, persönliche Version: was schütze ich, vor wem, und wie weit gehe ich dafür?

STRIDE: Bedrohungen klassifizieren

STRIDE ist das bekannteste Klassifikationsschema für Bedrohungen, ursprünglich Ende der 1990er bei Microsoft entwickelt. Jeder Buchstabe steht für eine Bedrohungs-Kategorie und korrespondiert mit einem Schutzziel — die Verbindung zur CIA-Trias ist direkt.

Anwendung: man läuft die Architektur entlang und fragt für jedes Bauteil — Endpoint, Datenfluss, Trust-Boundary — welche STRIDE-Kategorien könnten hier zuschlagen? Die Buchstaben sind dabei eine Checkliste gegen die menschliche Tendenz, immer nur an die offensichtliche Bedrohung zu denken (typischerweise: Spoofing und Tampering).

DREAD: Risiken bewerten

STRIDE sagt dir, welche Bedrohungen es gibt — aber nicht, welche zuerst dran sind. Für die Priorisierung gab es bei Microsoft das Schwester-Schema DREAD:

• Damage — wie groß ist der Schaden im Erfolgsfall?
• Reproducibility — wie zuverlässig lässt sich der Angriff wiederholen?
• Exploitability — wie viel Aufwand braucht ein Angreifer?
• Affected Users — wie viele sind betroffen?
• Discoverability — wie leicht ist die Schwachstelle zu finden?

Jede Dimension wird grob bewertet (z. B. 1 bis 10), und der Mittelwert ergibt ein Risiko-Score. Wichtig: DREAD ist heute umstritten. Microsoft selbst hat es ab ca. 2008 zugunsten von CVSS aufgegeben, weil die Bewertungen subjektiv schwanken und das Ranking dadurch instabil wird.

In der Praxis nutzen Teams oft eine vereinfachte Variante: Eintrittswahrscheinlichkeit × Schaden. Für CVE-konkrete Schwachstellen ist CVSS (Common Vulnerability Scoring System, aktuell v4.0) das verbreitete Werkzeug — zu finden auf first.org/cvss.

MITRE ATT&CK: Taktiken und Techniken

Ein anderer Blickwinkel kommt von MITRE. Das ATT&CK-Framework (attack.mitre.org) ist eine Wissensdatenbank realer Angreifer-Verhaltensweisen, aufgeteilt in Taktiken (was Angreifer erreichen wollen) und Techniken (wie sie es konkret tun).

Die Taktiken im Enterprise-Bereich, in chronologischer Reihenfolge eines typischen Angriffs:

ATT&CK ist weniger ein Modellierungs-Werkzeug als eine gemeinsame Sprache: wer „T1566.001" sagt, meint genau „Spear-Phishing Attachment". Detection-Teams nutzen das Framework, um zu prüfen, welche Techniken ihre Logs überhaupt sehen würden — Stichwort Detection Coverage.

Im Web ist neben dem Enterprise-Set vor allem ATT&CK for Web und die jüngere Containers/Cloud-Matrix relevant.

Praktischer Workflow für ein Web-Projekt

So lässt sich ein Bedrohungsmodell für eine konkrete Anwendung in ein paar Stunden erstellen — kein wochenlanges Audit, sondern eine strukturierte Bestandsaufnahme.

Schritt 1 — Datenfluss skizzieren. Komponenten und Pfeile aufmalen. Wichtig sind die Vertrauensgrenzen: wo wechselt der Kontext (Browser → Server, Server → DB, eigene App → externes API)? An jeder solchen Grenze muss authentifiziert und autorisiert werden.

┌──────────┐    HTTPS    ┌──────────┐   SQL   ┌─────────┐
│ Browser  │ ─────────▶ │ Web-App  │ ──────▶ │ Postgres│
└──────────┘  ┊TB1┊      └────┬─────┘  ┊TB2┊  └─────────┘
                              │
                              │ HTTPS  ┊TB3┊
                              ▼
                        ┌──────────┐
                        │ Payment  │
                        │ Provider │
                        └──────────┘
TB = Trust Boundary

Schritt 2 — STRIDE pro Komponente durchgehen. Liste mit drei Spalten: Komponente, STRIDE-Kategorie, Konkrete Bedrohung. Nicht alles ausfüllen, was theoretisch geht — nur das, was plausibel ist.

Schritt 3 — Mitigations zuordnen. Pro Bedrohung eine oder mehrere Gegenmaßnahmen. Wo die Maßnahme noch nicht existiert: Ticket. Wo sie existiert: wo ist sie dokumentiert/getestet?

Schritt 4 — Akzeptierte Risiken festhalten. Nicht alles wird mitigiert. Was bewusst akzeptiert wird, gehört genauso schriftlich fest wie das, was umgesetzt wird — sonst diskutiert man bei jedem Audit dieselben Punkte neu.

Schritt 5 — Wiedervorlage. Nach jedem größeren Architektur-Change, bei neuem externen Integration-Partner, mindestens jährlich.

Threat-Model für Nutzer:innen

Für eine einzelne Person ist das Modell viel schlanker — vier Fragen reichen:

• Was schütze ich? Mail-Konto, Bank, Krankenakte, Familienfotos, politische Identität, Quellen-Schutz (Journalismus).
• Vor wem? Familienmitglieder mit Geräte-Zugang, Ex-Partner, neugierige Mitschüler:innen, opportunistische Bots, organisierte Kriminalität, eigener Arbeitgeber, ausländische Behörden.
• Wie wahrscheinlich ist ein Angriff? Massen-Phishing trifft jede:n; gezielte Recherche-Versuche treffen wenige.
• Wie schmerzhaft wäre der Schaden? Mail-Übernahme zieht oft alle anderen Konten hinterher — der Schaden ist hier hoch, auch bei niedriger Wahrscheinlichkeit.

Die EFF hat dazu mit der Surveillance Self-Defense-Reihe eine sehr gute, allgemeinverständliche Einführung. Ergebnis: nicht jede:r braucht Tor, Tails und 4 Hardware-Keys — aber jede:r braucht ein Passwort-Manager und 2FA auf Mail.

Typische Modellierungs-Fehler

• Nur die Frontdoor anschauen. Login-Seite wird auf Brute-Force geprüft, der Webhook-Endpoint daneben hat keine Auth. Bedrohungsmodellierung umspannt alle Eintrittspunkte, nicht nur die offensichtlichen.
• Insider ausblenden. „Wir haben nette Kolleg:innen" ist kein Sicherheits-Argument. Off-Boarding-Lücken, Schatten-IT und schlechte Logs sind häufiger als externe Angriffe.
• Compliance mit Sicherheit verwechseln. DSGVO-konform ≠ angreifbar. ISO-27001-zertifiziert ≠ sicher. Compliance setzt Untergrenzen, kein Sicherheitsniveau.
• Verzettelung in Theatralik. Drei Stunden Diskussion über das Quanten-Computing-Risiko, während die Datenbank ohne Backup läuft. Risiko realistisch gewichten — was ist eintrittsstark, was ist katastrophen-stark, was ist Spielerei?
• Einmalig statt iterativ. Das Modell von letztem Jahr beschreibt nicht die heutige Architektur. Wenn das letzte Update vor zwei Jahren war, ist das Modell Folklore.

Weiterführende Ressourcen

Externe Quellen

• OWASP Threat Modeling Cheat Sheet
• Threat Modeling Manifesto
• MITRE ATT&CK Framework
• MITRE CWE – Common Weakness Enumeration
• FIRST CVSS v4.0 Spezifikation
• Microsoft – STRIDE-Threat-Model-Dokumentation
• Adam Shostack – Threat Modeling: Designing for Security (Buch, 2014)
• EFF Surveillance Self-Defense – Threat Modeling für Nutzer:innen

Verwandte Artikel

• Was ist Web-Sicherheit?
• Angreifer-Typen
• Angriffsketten und Kill Chain
• Risiko und Defense-in-Depth
• Glossar und Begriffe