Threat Modeling 101 – Wie fange ich eigentlich an?

In einem früheren Blogpost haben wir bereits erklärt, wie wichtig Awareness im Bereich IT-Security im agilen Projekt ist. Ein Kernthema war das Threat Modeling. Doch wie genau funktioniert das? Wie bewerte ich, welche Bereiche meiner Applikation unter dem Aspekt der IT-Sicherheit besonders kritisch sind? Welche Stellen muss ich im Auge behalten und wo sind die größten Security-Baustellen? Wie man das herausfindet und wie man grundlegend mit einer Sicherheitsanalyse startet, beschreibt dieser Artikel.

Don’t try this at home – Hol’ dir Profis ins Haus!

Ein Disclaimer vorweg: Ein professionelles Audit von ausgebildeten Spezialist:innen für Computersicherheit ist nicht zu ersetzen. Bevor eine Anwendung, die in beliebiger Form sensible Daten verarbeitet, live geht, sollten Sicherheitsanalysen (Penetration-Tests) eines erfahrenen InfoSec-Teams stattgefunden haben. Alles andere wäre grob fahrlässig. Doch um diese Prüfungen mit dem bestmöglichen zu erreichenden Ergebnis – und vor allem mit möglichst geringen Kosten – zu bestehen, ist ein internes, ebenfalls regelmäßig durchgeführtes Threat Modeling extrem hilfreich. Wenn wir wissen, wo die fragilen Punkte unseres Systems sind, können wir diese Stellen von vornherein härten oder den Profis zumindest eine ‘Karte’ mit Security-Hotspots an die Hand geben. Somit können die teuren Expert:innen ihre Arbeit effektiv auf die Main-Targets fokussieren und wir sparen kostbare Zeit.

Was ist Threat Modeling?

Sicherheit ist ein wichtiges Thema, aber ebenso abstrakt und schwer zu greifen. Wie bei jedem Aufbruch ins Unbekannte, sind gerade die ersten Schritte auch die schwersten. Bei größeren Systemlandschaften ist es nicht einfach herauszufinden, wo überhaupt Probleme auftreten können und welche davon zuerst angegangen werden sollten. Das Threat Modeling hilft uns dabei, einen Überblick zu gewinnen und konkrete Aufgaben zu ermitteln.

Im Großen und Ganzen verbirgt sich hinter diesem Begriff eine Analyse der eigenen Software, der umliegenden Systeme und Prozesse und letztendlich deren Verwundbarkeit. Verwendete Komponenten und Datenflüsse werden lokalisiert und mögliche Sicherheitsmängel aufgelistet. Auch die Aufwände zur Absicherung potenzieller Schwachstellen werden bestimmt. Ob und zu welchem Zeitpunkt diese Lücken dann geschlossen werden sollten, entscheidet eine Abwägung der angenommenen Eintrittswahrscheinlichkeit eines entsprechenden Angriffs auf diese ermittelten Schwachstellen. Ziel ist es, wichtige Baustellen zu priorisieren, um Lösungen für reale Bedrohungen zu finden und esoterische Bedrohungen hinten anzustellen.

Wann sollte man damit starten?

Darauf gibt es nur eine Antwort – sofort. Beim Threat Modeling geht es darum, mögliche Sicherheitsprobleme und konzeptionelle Lücken im eigenen System zu finden, ähnlich dem Software-Testing. Dies geschieht bestenfalls sehr früh im Entwicklungsprozess, um die Änderungskosten gering zu halten und wird kontinuierlich durchgeführt, um auf die Veränderungen der eigenen Applikation und der Umgebung zu reagieren. Je später wir von Problemen erfahren, desto teurer wird es wohlmöglich, diese wieder zu beheben.

Wie nähern wir uns der Praxis?

Das Konzept hinter dem Begriff Bedrohungsanalyse klingt ja erstmal etwas schwer zu greifen, also tasten wir uns langsam heran. Die OWASP-Community definiert Threat Modeling auf abstrakter Ebene durch vier Fragen – das Four Question Framework.

Im Kern müssen wir Antworten auf folgende Fragestellungen finden:

• Womit haben wir es zu tun? (What are we working on?)
• Was kann dabei schief gehen? (What can go wrong?)
• Haben wir einen Plan, um diese Fallstricke zu überwinden? (What are we going to do about it?)
• Wie können wir unsere Maßnahmen bewerten? (Did we do a good job?)

Das ist die Theorie. Klingt eigentlich einfach, oder? Wie so oft ist die Realität natürlich viel komplexer. Wir müssen unser System genauer untersuchen. Doch wie genau stellen wir das praktisch an? Versuchen wir einfach, Antworten darauf zu finden.

Wo fängt man an?

Um herauszufinden, ob es überhaupt Probleme gibt, müssen wir zuallererst eine Übersicht über das System bekommen. Ziel kann es beispielsweise sein, ein Diagramm mit beteiligten Komponenten, Datenflüssen, Vertrauensgrenzen und verwendeten Protokollen zu erstellen.

Beispiel eines simplen Diagramms, erstellt mit dem OWASP Threat Dragon Threat Modeling Tool:

Um ein System zu analysieren und letztendlich zu einem solchen Diagramm zu kommen, gibt es verschiedene Ansätze. Wir benötigen einen Startpunkt, sozusagen einen Aufhänger oder einen roten Faden, an dem wir uns entlanghangeln können. Hier gibt es nicht grundsätzlich den goldenen Pfad, lediglich die initiale Sicht auf das Problem unterscheidet sich und bietet je nach Vorliebe oder Rahmenbedingungen gegebenenfalls einen leichteren Zugang.

Grundlegende Strategien

Asset-zentriert

Hier stehen die Werte eines Systems im Vordergrund, auf die es potenzielle Angreifer:innen abgesehen haben könnten. Was sind die Werte meines Unternehmens? Hier beginnt der Prozess auf Business-Ebene. Wenn man Schwierigkeiten hat, diese Ziele selbst zweifelsfrei aufzuzählen, ist das Management hier ein guter Ansprechpartner. Wenn wir die schützenswerten Assets benennen können, kann ich im nächsten Schritt auch Komponenten und Prozesse identifizieren, die mit diesen Werten arbeiten oder Zugriff darauf ermöglichen.

Software-zentriert

Bei diesem Ansatz startet man auf der technischen Ebene. Die Systemlandschaft wird von Techniker:innen erklärt und modelliert, natürlich in einer sinnvoll gewählten Detailtiefe. Bei komplexeren Systemen mit vielen beteiligten Teams sind Diskussionen erwünscht und machen gegebenenfalls sogar dabei bereits versteckte Komplexität sichtbar. Vielleicht haben Teams, die bislang selten oder gar nicht miteinander kommuniziert haben, durch diese Zusammenarbeit auch die Möglichkeit, Erwartungen an andere Komponenten zu validieren.

Risiko-zentriert

Dieser Ansatz wurde mit dem PASTA-Framework bekannt. Er stellt eine Art Kombination aus Asset- und Software-zentriertem Threat Modeling dar und sieht alle Komponenten und somit das System an sich von Beginn an als untrennbar an. Dementsprechend brauchen wir auch initial das Wissen aus allen betroffenen Bereichen und der Aufwand scheint höher, wir sparen aber "hinten raus" Zeit.

Angreifer-zentriert

Die Erstellung einer Security-To-Do-Liste aus Sicht der potenziellen Angreifer:innen ist sicher möglich, aber schwer zu umzusetzen. Hierzu müssten die Hintergründe der Angreifer:innen, deren Intention und Skill-Level bekannt sein. Diese Variablen fluktuieren, sind schwer zu bewerten und machen die Ergebnisse eines Threat Modelings für technische Komponenten schwer reproduzierbar. Daher ist dieser Ansatz nur der Vollständigkeit halber aufgeführt, eher für den Bereich Social Engineering zu empfehlen und vielleicht als Ergänzung der anderen Ansätze zu sehen.

Mit dem passenden Ansatz wird dann eine Übersicht der zu untersuchenden Umgebung erstellt.

Was sollte unser Diagramm beinhalten?

Um hier eine passende Antwort zu finden, sollten wir immer folgende Frage im Hinterkopf haben: Was hilft uns weiter? Wichtige Kernelemente eines Threat-Model-Diagramms sind Datenflüsse und die entsprechenden Prozesse, die diese Daten bewegen. Auch unabdingbar sind externe Entitäten, beispielsweise Webbrowser oder Nutzer(-Eingaben) in jeglicher Form. Zu guter Letzt müssen wir die Stellen visualisieren, an denen Benutzer- und Systemrechte wechseln, das heißt wir brauchen eine Übersicht über die Trust Boundaries.

In welcher Form wir dies 'zu Papier bringen', ist Nebensache. Wenn beispielsweise UMLs sowieso schon an anderer Stelle eingesetzt werden und das Wissen im Umfeld vorhanden ist, kann in dieser Form auch das Threat-Model-Diagramm erstellt werden. Ansonsten nutzen wir vielleicht einfach die Darstellungsform, die uns das gewählte Tooling bietet.

Was machen wir nun mit der Systemübersicht?

Da wir jetzt wissen, wie unser System aussieht, können wir die Bestandteile genauer untersuchen. IT-Systeme bestehen aus Komponenten und sie kommunizieren miteinander. Wir müssen also jeden Teil dieser Konstellation einzeln unter die Lupe nehmen und bewerten. Hier müssen wir prüfen, ob Server unsicheren Code ausführen können oder Kommunikationskanäle möglicherweise unzureichend abgesichert sind. An dieser Stelle können uns Threat-Modeling-Methoden wie STRIDE helfen, aber mehr dazu später.

Wen brauchen wir für die Analyse?

Um ein System zu beschreiben und dessen Schwachstellen zu identifizieren, brauchen wir selbstverständlich Kenner:innen des Systems und Wissen über die Werte, die dahinter stehen. Grundsätzlich können hier viele Abteilungen unterstützen. Das Management kennt sich sicherlich am besten mit den Werten und Risiken des Geschäftsmodells aus, die Techniker:innen können natürlich kundige Auskunft über die Interna des Systems geben. Die Qualität des Ergebnisses steigt mit der Erfahrung der Beteiligten. Wichtig ist, dass offen über Erkenntnisse und mögliche Schwächen der einzelnen Komponenten gesprochen werden kann, ohne dass Teilnehmende (Entwickler:innen) gekränkt sind, falls ‘ihr Baby’ kritisiert wird.

Gibt es Tools, die uns unterstützen können?

Grundsätzlich ist eine Software-Risikoanalyse Handarbeit. Einen Automatismus, der unser System scannt, unsere wertvollen Assets kennt und die Kommunikation innerhalb des Unternehmens mit einbezieht, gibt es leider nicht. Auch wenn für bestimmte Teilaspekte unterstützende Hilfsmittel existieren, ist das Modellieren von Bedrohungen und vor allem das Bewerten der Risiken primär ein manueller Prozess. Es gibt keine vollständig automatisierte Lösung, die eine Anwendung (oder unter Umständen sogar eine sehr komplexe Systemlandschaft) vollständig analysieren und bewerten kann.

Am Ende des Tages würde Stift und Papier ausreichen, um ein Threat Modeling durchzuführen, dies wäre aber kaum effizient und würde in einem Kampf gegen riesige, nicht wartbare Papiertapeten enden. Effektiver und nachhaltiger ist dann sicher ein digitaler Ansatz. Welches Werkzeug hier das richtige ist, entscheidet man am besten anhand der Komplexität des Systems. Für bestimmte Techniken existieren spezialisierte Programme. Microsofts Threat Modeling Tool ist natürlich auf die hauseigene STRIDE Technik zugeschnitten, jedoch sehr komplex und schwergewichtig. Daneben stehen unabhängige, schlankere Programme wie das bereits erwähnte OWASP Threat Dragon Threat Modeling Tool, mit dem unser Beispieldiagramm erstellt wurde. Wichtige Kriterien für die Wahl der entsprechenden Software ist die Benutzbarkeit, denn Threat Modeling ist Teil des Software-Development-Lifecycles und sollte so wenig zusätzlichen Schmerz wie möglich verursachen. Vielleicht entscheidet auch die Wahl der Bewertungsstrategie über das optimale Programm, denn wenn ich mein System mit dem von Microsoft entwickelten STRIDE-Ansatz bewerten möchte, bietet vielleicht das speziell dafür erstellte Tool die meisten Benefits. Am Ende des Tages sollte man am besten ausprobieren, welches Werkzeug am besten zu der eigenen Arbeitsweise und der gewählten Technik passt.

Welche etablierten Threat-Modeling-Techniken gibt es?

Die Palette an Threat-Modeling-Werkzeugen ist nicht klein. Neben etablierten, umfangreichen Platzhirschen wie Microsofts STRIDE und dem etwas moderneren PASTA gibt es noch einige weitere Methoden. Einige darunter haben die Ambition, vollumfängliche Lösungen zu sein oder stellen Bausteine zwecks Komposition eines selbst zusammengestellten Prozesses dar. Attack Trees oder CVSS sind hier gute Beispiele für diese Komponenten. Jedenfalls ist es ratsam, einen Überblick über das gesamte Portfolio zu behalten, um sich so selbst ein gutes Set für seinen eigenen Werkzeugkasten zusammenstellen zu können.

Die üblichen Verdächtigen:

PASTA (Process for Attack Simulation and Threat Analysis)

Ein Risiko-orientierter Ansatz, bei dem der Kontext aus der Sicht der wertvollen Assets und der entsprechenden Verwundbarkeit analysiert wird. Die Technik beschreibt hierzu die folgenden sieben Schritte:

Schritt	Fragestellungen / Todos
Definition der Ziele	Wo befinden sich die Werte des Unternehmens? In welchem Kontext läuft die Applikation? Betreiben wir eine interne oder externe Anwendung? Welche Art von Daten werden verwaltet? (Gesundheit, Finanzen etc.)
Generelle Auflistung der verwendeten Technologien	Welche Technologien (OS, Libs, Sprachen, 3rd Party Software) nutzen wir? Enumerierung der Anwendungsfälle Wie groß ist die Angriffsfläche?
Analyse der Anwendung im Detail	Visualisierung der Datenflüsse Wie läuft die Autorisierung? Welche Protokolle werden verwendet? Welche Frameworks werden verwendet? Was passiert mit Eingaben / Uploads? Wie spielen die Komponenten zusammen?
Analyse der möglichen Bedrohungen	Welche Bedrohungen bestehen (wer bedroht uns)? Analyse der bekannten Bedrohungen (statische CVEs) und welche bekannten Exploits gibt es für die von uns ermittelten Komponenten? Review der aktuellen Bedrohungen (Wirtschaftslage, aktuelle Geschehnisse)
Analyse der bekannten Schwachstellen	Welche Schwachstellen gibt es?
Analyse der erwarteten Angriffe	Welche Angriffe haben wir zu erwarten? (Ermittelte Bedrohungen + ermittelte Schwachstellen) Review der bekannten Angriffsmuster
Risiko und Schadensanalyse	Bewertung der Risiken (Mögliche Angriffe vs. Objectives) Priorisierung Kosten / Nutzen Abwägung

Sowohl für die Visualisierung des Systems als auch für den Bewertungsvorgang geben die Autoren keine Vorgaben bzw. Hilfen. Hier muss ein für den eigenen Prozess passendes Tooling gewählt werden. Zum Bewerten kann aber natürlich das im Folgenden beschriebene STRIDE Pattern verwendet werden.

STRIDE

Die STRIDE-Technik nimmt die Benutzer:innen hier schon eher an die Hand. Wenn ein System modelliert ist (egal ob mit der von Microsoft entwickelten Lösung oder mit einer entsprechenden Alternative), fokussiert sich dieser Ansatz auf festgelegte Analysekategorien von Bedrohungen. Jeder ermittelte Teil des Systems wird auf die Verwundbarkeit durch folgende Bedrohungen bewertet:

Bedrohung	Szenarien / Beispiele
Spoofing identity (Vortäuschen falscher Identität)	Das Senden von Nachrichten mit fingierten Absender:innen
Tampering with data (Datenmanipulation)	Änderungen von System-Konfigurationen, Ablage von Schadsoftware
Repudiation (Abstreiten von Verantwortung)	(Nachträgliche) Manipulation von Logfiles oder Zugriffsprotokollen
Information disclosure (Enthüllung von Informationen)	Vertrauliche Informationen werden unrechtmäßig veröffentlicht, bspw. durch Zugriffe auf unverschlüsselte Backups
Denial of Service (Verfügbarkeit von Diensten verhindern)	Systeme werden unerwartet heruntergefahren oder durch Massenanfragen lahm gelegt
Elevation of Privileges (Unrechtmäßige Beschaffung von Rechten)	Durch Ausnutzen von Schwachstellen (Bugs, fehlende Rechteprüfungen) erlangt eine User:in erweiterten unrechtmäßigen Zugang

Wie bereits erwähnt, bietet Microsoft hierfür ein hauseigenes Tool an. Damit können Systeme grafisch modelliert und Reports automatisiert generiert werden. Durch die exakte Definition des Vorgehens und den damit einhergehenden hohen Detailgrad ist STRIDE geführter, aber auch komplexer.

Beispiele für Komponenten/Ergänzende Techniken:

Attack Trees

Bei dieser eher leichtgewichtigen Technik stehen einzelne Assets im Fokus. Für diese Ziele werden mögliche Angriffe und Angriffspfade benannt und als Baumstruktur visualisiert. Die Pfade werden anschließend unter dem Gesichtspunkt einer realistischen Bedrohung bewertet. Aus Angreifersicht lohnenswerte Pfade rücken somit auf der Prioritätenliste nach oben.

CVSS

Das Common Vulnerability Scoring System ist ein Standard für die angepasste Bewertung der Kritikalität einer Sicherheitslücke. Diese Einordnung kann beispielsweise verwendet werden, um die generischen Ergebnisse automatisierter Dependency-Checks für das eigene System zu verfeinern und zu dokumentieren. Hierdurch können Einschätzungen allgemeiner Bedrohungen sowohl gemildert als auch verschärft werden.

Hinweis zu Techniken, die Bedrohungen in Kategorien einordnen:
Am Ende des Tages sind Kategorien nebensächlich. Wichtig ist, dass keine Bedrohung vergessen wird. Deshalb ist es erstmal wichtig, jede realistische Bedrohung zu notieren. In welcher Kategorie diese landet, ist vorerst egal.

Wie geht es nun mit den Findings weiter?

Sicherheitslücken sind Unzulänglichkeiten unseres Produkts, also sollten wir sie auch so behandeln. Wenn wir einen Bug in unserer Software entdecken würden, wäre es völlig natürlich, hierfür ein Bug-Ticket anzulegen. Dies können wir für Findings aus unseren Threat-Modeling-Sessions ebenso tun und diese Issues analog zu anderen Tickets in unserem Prozess (Refinement, Review etc.) abarbeiten. Somit lassen sich regelmäßige Sicherheitsanalysen wunderbar in einen agilen Prozess integrieren und verbessern unser Produkt kontinuierlich. Vielleicht besteht auch nicht für jedes aufkommende Thema (technischer) Handlungsbedarf, denn grundsätzlich kommen für jedes Sicherheitsproblem folgende Lösungen in Frage:

Mitigieren:

Das System wird verändert, sodass die kritischen Pfade nicht mehr Teil der Angriffsfläche oder schwerer auszunutzen sind, beispielsweise durch ein Update einer verwundbaren Abhängigkeit oder eine Änderung des eigenen Sourcecodes.

Eliminieren:

Die Schwachstelle wird behoben, indem sie entfernt wird. Wenn ich auf ein (Nice to have-) Feature verzichten oder die Funktionalität auf einem anderen, sicheren Weg ermöglichen kann, verkleinert sich die Angriffsfläche ebenso.

Verschieben:

Gegebenenfalls kann ein notwendiger Prozess an eine andere Stelle delegiert werden, die sicherheitstechnisch kompetenter ist. Ein Beispiel wäre eine Authentifizierung, die an einen nicht von uns kontrollierten Prozess weitergereicht wird. Auch Verantwortung lässt sich transferieren, indem Nutzer:innen einer Software auf Risiken hingewiesen werden und diese aktiv in Kauf nehmen.

Akzeptieren:

Vielleicht ist die Eintrittswahrscheinlichkeit und/oder der mögliche Schaden so gering, dass der Aufwand zur Behebung unwirtschaftlich wäre und das Risiko daher einfach akzeptiert wird.

Jede Entscheidung zu einem Finding – wie auch immer diese Aussehen – sollte dokumentiert werden.

Ergebnisse validieren

Woher wissen wir, ob wir einen guten Job gemacht haben? Ganz einfach, indem wir unsere Analyse in regelmäßigen Abständen wiederholen, insbesondere nachdem Änderungen am System stattgefunden haben. Wenn die erstellten Tickets abgearbeitet und gewissenhaft gelöst sind, sollten die ermittelten Findings bei unserem nächsten Threat Modeling gegenstandslos geworden sein. Mit jeder Iteration wird unser System sicherer. Außerdem lernen alle Beteiligten aus jeder Analyse.

Takeaway

Mit folgender Checkliste kann man sich an ein gutes Ergebnis heranarbeiten:

• Systemübersicht durch ein offenes Brainstorming gewinnen
• Erkenntnisse visualisieren, zum Beispiel durch ein Diagramm
• Trust Boundaries einziehen (Wo werden Vertrauensgrenzen zwischen Systemen passiert?)
• Data Flow skizzieren (Wo bewegen sich welche Daten und Protokolle werden verwendet)
• Assets und Verbindungen darstellen. Alternative Routen und Weichen sind ebenfalls wichtig
• Das Diagramm bei Bedarf (in Iterationen) verfeinern. So vollständig wie nötig, jedoch nicht zu viele Details. Sub-Diagramme erstellen, falls notwendig. Immer die Frage im Hinterkopf behalten: Hilft uns das?
• Schwachstellen identifizieren
• Findings bewerten und priorisieren
• Verwundbarkeiten beheben
• Den Prozess spätestens bei jeder größeren, architekturellen Änderung der Software oder bei Änderungen der Umgebung wiederholen

Fazit

Aller Anfang ist schwer. Je komplexer das eigene System ist, desto aufwendiger wird auch dessen Sicherheitsanalyse. Das Ergebnis des ersten, eigenen Threat Modelings wird wahrscheinlich nicht perfekt, aber das muss auch nicht der Anspruch sein. Letztendlich kann man sich nur schrittweise einem vollständigen Ergebnis nähern und Erfahrungen in der Praxis sammeln, dabei wird sich auch eine passende Auswahl an Tools und Techniken herauskristallisieren. Der offene Austausch mit allen Beteiligten und auch der Umgang mit dem Thema Security sind extrem wertvoll. Wichtig ist zu verhindern, sich während der Diskussionen in 'rabbit holes' zu verlieren, denn dies könnte der Akzeptanz der regelmäßigen Meetings schaden. Hier hilft es, die Auswahl der Teilnehmer:innen sinnvoll zu wählen und die Detailtiefe der Themen dementsprechend anzupassen.