Threat Modeling: Angriffe systematisch vorwegnehmen

Threat Modeling ist die systematische Frage: Welche Angriffe sind bei diesem System realistisch? Es ist der Unterschied zwischen Sicherheit nach Gefühl und Sicherheit nach Plan – und es kostet einen halben Tag.

Warum es sich lohnt

Ohne Bedrohungsmodell:\n  - Massnahmen nach Bauchgefuehl oder Checkliste\n  - Die falschen Dinge werden gehaertet\n  - Niemand weiss, welche Risiken bewusst\n    akzeptiert wurden und warum\n  - Bei einem Vorfall ist niemand vorbereitet\n\nMit Bedrohungsmodell:\n  - Die wichtigsten Risiken sind benannt und priorisiert\n  - Massnahmen sind begruendet, nicht geraten\n  - Bewusste Akzeptanz ist dokumentiert\n  - Neue Funktionen werden gegen das Modell geprueft\n  - Bei einem Vorfall gibt es einen Plan\n\nAufwand: Ein halber Tag fuer ein System.\nAlle sechs Monate oder bei groesseren Aenderungen\nueberarbeiten.

Die vier Fragen (klassisch)

1) Was bauen wir?\n   -> Architekturzeichnung: Komponenten, Datenfluesse,\n      Vertrauensgrenzen (Trust Boundaries)\n\n2) Was kann schiefgehen?\n   -> STRIDE je Komponente durchgehen (siehe unten)\n\n3) Was tun wir dagegen?\n   -> Massnahmen: Vermeiden, Verringern, Uebertragen,\n      Akzeptieren (mit Begruendung!)\n\n4) Haben wir es gut genug gemacht?\n   -> Modell pruefen, Massnahmen testen, Restrisiko\n      dokumentieren und absegnen lassen

STRIDE: die sechs Bedrohungsarten

Spoofing (Vortaeuschen)\n   Bedrohung: Jemand gibt sich als jemand anderes aus.\n   Massnahme:  Authentifizierung (MFA, Zertifikate,\n               Signatur), gegenseitige TLS-Authentifizierung\n   Frage:      Kann sich jemand als Nutzer oder Dienst\n               ausgeben, der er nicht ist?\n\nTampering (Manipulation)\n   Bedrohung: Daten werden unerlaubt geaendert.\n   Massnahme:  Signaturen, Pruefsummen, Rechte (Dateisystem\n               nur lesen), Protokollierung mit Verkettung\n   Frage:      Kann jemand eine Nachricht oder gespeicherte\n               Daten unbemerkt aendern?\n\nRepudiation (Abstreiten)\n   Bedrohung: Eine Handlung kann nicht bewiesen werden.\n   Massnahme:  Revisionssichere Protokolle, Zeitstempel,\n               Signaturen, unabhaengige Protokollablage\n   Frage:      Kann eine Person eine Handlung abstreiten,\n               weil kein Nachweis existiert?\n\nInformation Disclosure (Informationspreisgabe)\n   Bedrohung: Daten werden unerlaubt gelesen.\n   Massnahme:  Verschluesselung (Uebertragung und Speicher),\n               Datenminimierung, Berechtigungen\n   Frage:      Kann jemand Daten sehen, die ihm nicht zustehen?\n               (Auch in Protokollen, Fehlermeldungen, Backups!)\n\nDenial of Service (Dienstverweigerung)\n   Bedrohung: Der Dienst ist nicht mehr verfuegbar.\n   Massnahme:  Ratenbegrenzung, Zeitueberschreitungen,\n               Ressourcenobergrenzen, Redundanz\n   Frage:      Kann eine einzelne Anfrage oder eine Flut\n               den Dienst ausser Betrieb setzen?\n\nElevation of Privilege (Rechteausweitung)\n   Bedrohung: Ein Angreifer erhaelt mehr Rechte als gedacht.\n   Massnahme:  Minimale Rechte, Trennung von Konten,\n               keine Ausfuehrung als root, Eingabepruefung\n   Frage:      Kann ein Nutzer zu Administratorrechten\n               gelangen?

Vertrauensgrenzen: der wichtigste Teil

Eine Vertrauensgrenze ist die Stelle, an der sich die\nVertrauenswuerdigkeit aendert. Genau dort muss geprueft werden.\n\nTypische Grenzen:\n  Internet <-> DMZ\n  DMZ <-> internes Netz\n  Anwendung <-> Datenbank\n  Anwendung <-> externer Dienst (API)\n  Nutzer <-> Verwaltungsschnittstelle\n  Container <-> Host\n  Browser <-> Server (der Nutzer ist NICHT vertrauenswuerdig!)\n  Entwicklung <-> Produktion\n\nBei JEDER Grenze fragen:\n  1. Wer darf hier durch? (Authentifizierung)\n  2. Was darf hier durch? (Eingabepruefung, Formate)\n  3. Was wird hier protokolliert?\n  4. Was passiert, wenn die Gegenseite boesartig ist?\n     (Nicht: "was passiert, wenn sie sich korrekt verhaelt?")\n\nFaustregel: Ein Datenfluss, der eine Grenze OHNE Pruefung\nueberquert, ist ein Fehler. Die Pruefung findet IMMER auf\nder empfangenden Seite statt.

Praktischer Ablauf für einen halben Tag

Vormittag (2 h): Modell zeichnen\n  - Komponenten aufschreiben (Webserver, Anwendung, Datenbank,\n    externer Dienst, Cache, Warteschlange)\n  - Datenfluesse als Pfeile\n  - Vertrauensgrenzen als gestrichelte Linien\n  - Was liegt AUSSERHALB unserer Kontrolle? (Nutzer,\n    Anbieter, Zertifizierungsstelle)\n  # Werkzeug: Stift und Papier reicht. Diagramme, die\n  # niemand versteht, helfen niemandem.\n\nVormittag (1 h): STRIDE je Komponente\n  - Fuer jede Komponente und jeden Fluss die sechs Fragen\n  - Nicht diskutieren, sondern erst sammeln\n  - Alles aufschreiben, auch Unwahrscheinliches\n\nNachmittag (2 h): Bewerten und priorisieren\n  - Wahrscheinlichkeit (1-3) x Auswirkung (1-3)\n  - Nur die obersten 5 bis 10 bearbeiten\n  - Massnahme, Verantwortliche, Termin festhalten\n\nNachmittag (1 h): Gegenpruefung\n  - Ein Kollege versucht, das Modell zu widerlegen\n  - "Welche Angriffe fehlen hier?"\n  - "Warum ist diese Grenze vertrauenswuerdig?"\n  # Diese Stunde ist die wertvollste des Tages.\n\nErgebnis: Eine Seite mit Massnahmen und Verantwortlichen.\nKein 40-Seiten-Dokument, das niemand liest.

Beispiel: ein Webshop

Komponenten: Browser, Lastverteiler, Webserver, Anwendung,\n             Datenbank, Zahlungsdienst, Mailversand\n\nGrenzen:     Browser<->Lastverteiler   (Internet)\n             Lastverteiler<->Webserver (intern, aber Vertrauen\n                                        nur bei Netzsegmentierung)\n             Anwendung<->Zahlungsdienst (extern!)\n             Anwendung<->Datenbank      (Rechte trennen!)\n\nFunde (gekuerzt):\n  S  Anmeldung ohne zweiten Faktor fuer Verwaltungskonten\n     -> MFA erzwingen\n  T  Bestellbetrag kommt vom Browser!\n     -> Betrag IMMER serverseitig aus dem Warenkorb berechnen\n  R  Zahlungsbestaetigung nicht protokolliert\n     -> Signatur des Zahlungsdienstes pruefen und ablegen\n  I  Bestelluebersicht prueft nicht die Eigentuemerschaft\n     -> Objektberechtigung je Anfrage pruefen (IDOR!)\n  D  Produktsuche unbegrenzt\n     -> Ratenbegrenzung und Anfragekosten begrenzen\n  E  Anwendung verbindet sich als Datenbankeigentuemer\n     -> eigenes Konto mit minimalen Rechten je Tabelle\n\nDie wichtigsten zwei Funde:\n  - Betrag vom Browser (Manipulation -> Betrug)\n  - Bestelluebersicht ohne Eigentuemerpruefung\n    (Informationspreisgabe -> fremde Bestellungen)\nBeide kosten je eine Stunde Arbeit und werden oft uebersehen.

Prüfliste

Existiert eine Architekturzeichnung mit Vertrauensgrenzen – nicht im Kopf?
Sind für jede Grenze Authentifizierung und Eingabeprüfung benannt?
ist Gegenstand der Prüfung aus Sicht der empfangenden Seite gedacht („Was, wenn die Gegenseite bösartig ist?“)?
Sind die obersten Risiken mit Verantwortlichen und Termin versehen?
Ist dokumentiert, welche Risiken bewusst akzeptiert wurden – und von wem?
Wird das Modell bei neuen Funktionen überprüft?
Ist mindestens eine Person beteiligt, die nicht am System gebaut hat (Gegenprüfung)?
Werden die Maßnahmen getestet (funktioniert die Berechtigungsprüfung wirklich)?

Häufige Fehler

Der Nutzer wird als vertrauenswürdig behandelt. Der Browser ist unter Kontrolle des Angreifers. Jede Prüfung, die nur im Frontend stattfindet, ist keine Prüfung (Preise, Rechte, Mengen).
Nur von außen gedacht. Der größte Teil der Vorfälle kommt von innen: Dienstkonten mit zu vielen Rechten, übernommene Konten, neugierige Berechtigte. Interne Grenzen sind genauso wichtig.
Maßnahmen ohne Test. „Wir prüfen die Berechtigung“ – ohne Test ist das eine Behauptung. Objektberechtigungen (IDOR) werden besonders häufig angekündigt und selten umgesetzt.
Zu viele Details. Ein 60-Seiten-Dokument wird nicht gelesen. Eine Seite mit zehn Punkten wird umgesetzt.
Einmalig statt fortlaufend. Nach sechs Monaten stimmt das Modell nicht mehr. Feste Überarbeitungstermine.
Keine Gegenprüfung. Wer sein eigenes Modell prüft, findet nur die Fehler, die er schon kennt.
Risiken nur benennen, nicht bewerten. Ohne Wahrscheinlichkeit und Auswirkung gibt es keine Priorisierung – und dann wird das Billigste zuerst gemacht, nicht das Wichtigste.
Externe Abhängigkeiten vergessen. Der Zahlungsdienst, der Mailversand, das CDN. Deren Ausfall oder Kompromittierung ist ein eigenes Risiko.

Verwandte Grundlagen: Zero Trust, Schwachstellenmanagement, Vorfallbehandlung, Penetrationstest.

IT-Sicherheit