Threat Modeling — Wie anfangen?
Von: Michael Sauer
Threat Modeling (TM) also Bedrohungsmodellierung ist ein Werkzeug, mit dem IT-Systeme auf potenzielle Bedrohungen analysiert werden, um sie mit entsprechenden Gegenmaßnahmen möglichst zu beseitigen. Als Security Engineer im Cross Solution Center der DATEV (XSC) biete ich das für alle bei uns entwickelten Produkte an. In diesem Beitrag schildere ich meine ersten Schritte und Erfahrungen. Damit möchte ich anderen den Einstieg erleichtern und dazu motivieren TM auszuprobieren. Denn inzwischen weiß ich: Geeignete Security-Maßnahmen frühzeitig zu finden, ist nicht der einzige Vorteil.
Der Anfang
Bei Recherchen im Internet tauchen schnell Diagramme in verschiedenen Notationen und Komplexitäten auf. Für mich war schnell klar: Sowas brauche ich auch! Was könnte anschaulicher sein als ein Bild. Allerdings haben mich diese z.T. sehr umfangreichen Gebilde auch am meisten abgeschreckt. Was ist wichtig? Was muss eingezeichnet werden? Welche Informationen müssen eingetragen werden? Welche Notation eignet sich? Welches Tool ist geeignet? Zum Glück liefert die Agilität eine gute Ausrede bzw. Methode für Unvollkommenheit, inspect and adapt — also: Tu etwas, schau, ob es funktioniert und verbessere es. Darum habe ich mein eher pragmatisches Vorgehen agiles Threat Modeling genannt, die Diagramme erstmal beiseite geschoben, mir vom Team die Anwendung erklären lassen und dabei über Security gesprochen. Auf einem bereitgestellten Flipchart entstand nebenbei fast von selbst ein kleines Diagramm mit 2 Rechtecken und einem Datenbank-Topf. Trotzdem haben wir Bedrohungen gefunden. Nach einigen Workshops stellte sich heraus, das Diagramm ist gar nicht das Ziel, sondern nur ein Hilfsmittel. Genauso ist das Finden von Bedrohungen nicht das einzige Ziel des TM. Allein die Diskussion über die Anwendung hat zum allgemeinen Verständnis beigetragen und einige implizite Annahmen aufgedeckt: “…ich dachte der Token wäre verschlüsselt…”. Späteres Feedback hat gezeigt, dass in den Teams, bei denen ein TM stattfand, hinterher die Security-Awareness höher war, es gab im weiteren Projektverlauf häufiger Diskussionen über Security-Aspekte. Das TM trägt also auch dazu bei, Wissen zu streuen, verbessert das Verständnis der Anwendung und steigert die Security-Awareness. Allein diese Aspekte sind wertvoll genug, um einen solchen Workshop zu rechtfertigen.
Workshops durchführen
Für das TM ist nicht nur Security-Expertise notwendig. Unklarheiten zur Funktionalität, Architektur und anderen Aspekten sollte möglichst sofort geklärt werden können. Das verkürzt die Anlaufzeit, erhöht den Wissensaustausch, sorgt für besseren Flow und verhindert, dass Risiken falsch eingeschätzt oder sogar übersehen werden. Bei den Workshops sollten möglichst diese Disziplinen vertreten sein:
• Entwicklung: Verständnis für die umzusetzenden Maßnahmen und für technische Fragen,
• Project Owner oder Requirement Engineering: für fachliche Fragen,
• Architektur: für Fragen zur Architektur,
• Security: um Wissen zu Angriffen und Schwachstellen beizusteuern (ideal: jemand mit Pentest-Erfahrung) und
• Testing: hier herrscht ein gutes Gespür für Schwachstellen und zum Verständnis für die zu testenden Maßnahmen.
Bevor mit der eigentlichen Analyse begonnen wird, sollten alle Beteiligten abgeholt werden. Das ist insbesondere für alle wichtig, die nicht permanent am Projekt mitarbeiten. Für den Workshop ergibt sich intuitiv folgende Agenda:
• erklären worum es beim TM geht,
• sammeln von Informationen, die für die Analyse nützlich sind, und die
• Analyse der Risiken in einer Mischung aus Brainstorming und Strukturiertem Vorgehen.
Weiteres Vorgehen
Zuerst sollte kurz erklärt werden was TM überhaupt ist und vor allem warum es gemacht wird. Es ist wichtig zu vermitteln, dass es nicht nur darum geht, ein Diagramm für den Security-Menschen anzufertigen. Menschen tun gern sinnvolle Dinge, deswegen sollte gezeigt werden, dass ein Mehrwert für alle entsteht: eine sicherere Anwendung, aber auch Wissensvermittlung und gesteigerte Awareness. Nun sollte auch der Scope festgelegt werden, d.h. definieren was wird betrachtet und was nicht, z.B. nur die Anwendung aber keine Infrastruktur. Durch den Ausschluss von Netzwerk, Webserver oder zentraler Komponenten gibt es weniger Ablenkung vom eigentlichen Betrachtungsgegenstand. Außerdem könnte festgelegt werden, das Innentäter-Szenarien zunächst ausgeschlossen werden. Gegen einen böswilligen Administrator gibt es Anwendungsseitig kaum eine Chance auf Verteidigung.
Informationen sammeln
In dieser Phase geht es darum, security-relevante Informationen zu sammeln, die später als Anhaltspunkte für die Analyse der Risiken dienen. Durch die gemeinsame Auseinandersetzung mit der Anwendung wird Wissen verteilt und vertieft, das hilft ein einheitliches Verständnis zu bekommen und deckt implizite Annahmen auf. Außerdem können die Informationen für andere Security-Maßnahmen benutzt werden, z.B. als Input für Pentest. Im Idealfall reicht die Aufzeichnung zur Abschätzung des Pentestumfangs aus und spart später mühevolles Zusammentragen der Informationen von einzelnen Wissensträgern. An der Stelle lasse ich mir die Anwendung erklären und frage gezielt nach security-relevanten Aspekten. Die Informationen notiere ich stichpunktartig. Das geht schnell und kann später leicht umsortiert und ergänzt werden. Hier kommen die Diagramme ins Spiel: Ich zeichne, was mein Verständnis unterstützt. Ich versuche aber zuerst auf bestehende Dokumentationen (Ablauf- oder Komponentendiagramme) zurückzugreifen, denn der Aufwand für die Pflege im weiteren Projektverlauf muss nicht selbst gemacht werden, wenn das bereits jemand anderes tut. Es wäre auch denkbar, bestehende Diagramme um Security-Aspekte zu erweitern, was aber Single Responsibility Prinzip verletzen würde und dadurch zu Komplikationen führen kann.
Auf jeden Fall sollten diese Informationen erfasst werden:
• Schnittstellen: Alle bereitgestellten und konsumierten Endpunkte, denn das sind die Punkte, auf die von außen auf eine Komponente eingewirkt werden kann, also die Angriffspunkte.
• Rechtekonzept (Rollen, Rechte): viele Angriffe zielen darauf ab, zugewiesene Rollen zu wechseln oder bestehende Rechte zu umgehen.
• Assets/schützenswerte Güter inkl. einer Bewertung: Deren Auflistung ist wichtig, um sich klar zu machen, was überhaupt zu schützen ist. Die Bewertung hilft bei der Priorisierung der Maßnahmen und bewirkt ein realistischeres Verständnis der Kritikalität von Schwachstellen. Manche Risiken stellen sich nach der Analyse als weniger kritisch dar als anfangs vermutet, oder es werden Dinge kritische, die gar nicht so aussahen, z.B. personenbezogene Metadaten. Die Bewertung ist ein Maß für den Schutzbedarf für jeweils Vertraulichkeit, Verfügbarkeit und Integrität, z.B. kein, mittel, hoch, sehr hoch.
Analyse — lets be evil
Nun geht es endlich los! Ich habe mit dem Ansatz begonnen: ‘Denken wie ein Hacker’, in der Hoffnung, dass es Spaß macht. Mal seine böse Seite raus zu lassen. Tatsächlich ist das aber gar nicht so einfach, da sich die meisten eher selten mit Angriffen und Gefahren auseinandersetzen. Allerdings könnte es aber gerade deswegen einen guten Lerneffekt haben. Zunächst sammle ich in einer Art Brainstorming alle Ideen für mögliche Angriffe. Da es davon reichlich gibt, ist es ratsam, sich auf einzelne Aspekte zu fokussieren. Ich mache das in zwei Dimensionen: Abstraktion und Kategorisierung. Die Abstraktion ist ein Top-Down-Ansatz. Um sich nicht in technischen Details zu verlieren, wird zuerst nur auf fachlicher Ebene überlegt: Was will ein Angreifer? Wie könnte sich jemand an KundInnen, AnwenderInnen, PartnerInnen oder uns als Hersteller bereichern? Das ist das gleiche Prinzip wie bei einer User Story, die nur enthält, was ein Anwender mit dem Produkt erreichen will, aber die technische Umsetzung offen lässt. Wegen der Ähnlichkeit habe ich den Begriff “Evil User Story” (EUS) ausgewählt. Sind die Ideen für EUS alle erfasst, können durch die Kategorisierung evtl. noch weitere gefunden werden. Ich nutze dazu das STRIDE-Modell von Microsoft, das alle möglichen Angriffe in 6 Kategorien unterteilt. Indem die Kategorien einzeln betrachtet werden, können neue Ideen entstehen. Gleichzeitig fungieren sie als Checkliste, um sicherzustellen, dass keine Angriffsart vergessen wird. Zum Fokussieren gibt es noch zahlreiche Möglichkeiten, z.B. Betrachtung einzelner Schnittstellen oder Systemkomponenten oder Erstellen eigener Checklisten. Hier sind viele Experimente möglich.
Eine EUS sieht z.B. so aus: “Als Angreifer möchte ich fremde Dokumente sehen [, um …]” Die genaue Erläuterung, warum der Angreifer das tun will (um…), halte ich für optional. Beim Stehlen von Geschäftsdaten ist wenig Fantasie notwendig, in anderen Szenarien kann damit die Kritikalität überhaupt erst verdeutlicht werden, z.B. “… Telefonnummer ändern” vs. “… Telefonnummer ändern, um den Rückruf bei Überweisungen >1 MIO abzufangen” (fiktives Beispiel).
Zu jeder EUS wird nun überlegt: Welche technischen Möglichkeiten es gibt sie umzusetzen, meist gibt es mehrere. Diese Möglichkeiten oder Angriffe nenne ich Abuse Cases (AUC). Nun werden noch für jedem AUC alle Gegenmaßnahmen aufgelistet, auch bereits existierende, da diese das Risiko vollständig mitigieren könnten und somit weitere Maßnahmen überflüssig wären. Die Maßnahmen nenne ich Security Stories (SST), denn das sind die Kandidaten, die später ins Backlog der Anwendung übernommen werden könnten. Die Priorisierung der SST mache ich nach dem Workshop, nachdem die EUS und AUC genauer bewertet wurden. Ob zuerst alle EUS gesucht werden und danach die AUC, oder zu jedem EUS direkt die AC, ist Geschmackssache. Ich habe bisher immer ersteres getan, um nicht ständig den Context zwischen fachlich und technischem Blickwinkel wechseln zu müssen.
Dokumentation
Am liebsten arbeite mit einem Flipchart zum Zeichnen, Kritzeln und Zettel kleben. Im Nachgang erfasse ich alles in einem Dokument.
Abbildung 1: Flipcharts aus verschiedenen Workshops
Bei Videokonferenzen schreibe ich direkt ins Dokument. Zum Zeichnen gibt es zahlreiche Tools ob Freihand oder mit vorgefertigten Formen und Symbolen. In der Dokumentation erfasse ich die EUS/AUC/SST als nummerierte Liste aufgeführt. Die Nummern erleichtern das Adressieren von bestimmten Elementen:
• EUS [für einen Angriff interessantes Ziel]
o AUC [mögliches Vorgehen, um Ziel zu erreichen]
SSt [wie kann das verhindert werden]
Beispiel:
• EUS 1: Als EU möchte ich fremde Dokumente sehen [, um …]
o AUC 1.1: Austauschen der Dokument-ID im HTTP-Request
SSt 1.2.1: für jedes Dokument Zugriffsrechte prüfen
SSt 1.2.2: Dokument-ID nur über HTTPS übertragen
o AUC 1.2: Adresse manipulieren und Dokument per Post zusenden lassen
SSt 1.2.1: Funktion zur Adressänderung absichern
SSt 1.2.2: Postversand nur mit zusätzlicher Autorisierung
Für die Bewertung eignen sich die Abuse Cases, da sie trotz gleichem EUS unterschiedliche Vorbedingungen erfordern können, was sich auf die Komplexität und damit auf die Kritikalität auswirket. Als Metrik nutze ich den [CVSS], denn damit ergibt sich ein gut definierter vergleichbarer Zahlenwert.
Welche Maßnahmen schließlich umgesetzt werden, ist eine Kosten-Nutzen Abschätzung. Oft gibt es Compliance-Vorgaben wie mit Risiken zu verfahren ist. Bei einfach umzusetzenden Maßnahmen sollten mehrere implementiert werden, nur zur Sicherheit — defense in depth.
Erfahrungen
Hier noch einige Beobachtungen und Gedanken, die auch interessant sein könnten:
• Kein Ersatz für andere Maßnahmen: Das TM, auch wenn mit viel investierter Zeit eine gute Abdeckung erreicht wird, kann andere Security-Maßnahmen nicht ersetzen, z.B. könnten bei der Umsetzung Fehler passieren oder es gibt Abuse Cases die nicht entdeckt wurden.
• Denken wie Hacker ist schwer: Der Ansatz “Denken wie ein Hacker” mag auf den ersten Blick witzig und spannend sein. Es ist aber gar nicht so leicht in diese Perspektive zu wechseln, hierfür ist viel Security-Wissen nötig. Es könnte leichter sein, sich durch eine Checkliste zu arbeiten. Andererseits ist das TM bezüglich Wissen selbstverstärkend, d.h. durch TM lernen die teilnehmenden Wissen, dass sie beim nächsten TM nutzen können.
• STRIDE evtl. zu abstrakt: Das STRIDE-Model ist sehr abstrakt und grob. Eine feingranularere Liste mit Angriffen zu benutzen könnte hilfreich sein und zusätzliches Security Knowhow liefern. Interessant wäre eine eigene Checkliste aus den bei früheren TM-Workshops und Pentests gefundenen Schwachstellen.
• wenige Schwachstellen gefunden: Bei meinen TM wurden eher wenige, manchmal sogar gar keine neuen Risiken entdeckt. Das ist zuerst frustrierend aber — sofern das TM nicht völlig falsch angegangen wurde — ein gutes Zeichen, es zeigt, dass das untersuchte Produkt bereits ein gutes Sicherheitsniveau hat. Bei unseren Pentests durch externe Experten werden auch kaum Verwundbarkeiten gefunden. Außerdem bleibt immer noch der Aspekt der Awareness und Wissensvermittlung.
Natürlich ist der Nutzen von TM immer eine Kosten/Nutzen-Abschätzung. Aber es hat einige zusätzliche positive Effekte auf der Haben-Seite. Trotz meines vereinfachten best effort-Ansatz würde ich sagen: Der größte Fehler der bei TM gemacht werden kann ist — es nicht zu tun.
