Was ist eigentlich Threat Modeling?

„Theat Modeling“, also die Bedrohungsanalyse ist, wie der Name schon sagt eine Analyse der Bedrohungen gegenüber einem System, Programm, Prozess, … etc.  Die Bedrohungsanalyse ist nicht nur auf IT-Systeme beschränkt, sondern immer dann gegenwärtig, wenn wir es mit schützenswerten Gütern („Assets“) zu tun haben. Ein Beispiel: Wenn ein Hausbesitzer eine Wasserpumpe im Keller installiert hat, die bei einer Überflutung das Wasser aus dem Keller pumpen soll, hat der Hausbesitzer die Bedrohung einer Überflutung durch Starkregen „analysiert“ und mit der Wasserpumpe diese Bedrohung „mitigiert“. (Mitigation zu Deutsch: Lindern, abschwächen, entschärfen).

Übertragen auf die IT-Welt bedeutet es, dass mögliche Bedrohungen zu einem IT-System analysiert und mitigiert werden. Dies geschieht am besten vor dem „Bau“ des Systems. In unserem Hausbeispiel mit der Überflutung wären z.B. vor dem Bau ein besseres Grundstück zu finden, oder auch keinen Keller zu bauen mögliche „Mitigierungen“. Das Hausbeispiel verdeutlicht auch, dass nach dem Bau die Bedrohung u.U. nicht mehr abgewendet werden kann, Überflutung vs. keine Überflutung, mehr dazu später. Natürlich ist das auch nur eine Bedrohung von vielen.

Halten wir also fest: Eine Bedrohungsanalyse sollte ein integraler Bestandteil des Software-Entwicklungsprozesses sein, damit erkannte Bedrohungen schon während des „Baus“ adressiert werden können.

Wenn wir bei unserem Hausbeispiel bleiben: Früh getroffene Entscheidungen können sich drastisch auf die Sicherheit des Hauses auswirken. Natürlich kann man immer noch die Wasserpumpe einbauen – aber wäre es nicht besser, wenn man direkt ein besseres Grundstück ausgesucht hätte?

Eine Bedrohungsanalyse kann ungünstige oder falsche Architekturentscheidungen vermeiden, und zwar schon bevor eine Zeile Code geschrieben wurde. Außerdem kann eine Bedrohungsanalyse hilfreich sein, um Sicherheits-Anforderungen an das System zu verstehen und diese zu ergänzen.

IT-Beispiel: Müssen die Daten verschlüsselt werden? Vielleicht nicht unbedingt auf einem Server, aber auf einem mobilen Endgerät schon.

Wie wir sehen, existiert eine enge Abhängigkeit zwischen Bedrohungen, Maßnahmen zur Mitigierung und System-Anforderungen.  Durch die Betrachtung der (Sicherheits-)Anforderungen schon im frühen Designprozess kann ein viel besseres (und auch sichereres) Produkt ausgeliefert werden.

Salopp gesagt ist Threat Modeling nichts anderes als die vorzeitige Überlegung, was alles an welcher Stelle schiefgehen kann und das Entwickeln einer darauf basierenden Schutzstrategie, um das ersonnene Worst-Case-Szenario zu vermeiden. Dafür müssen folgende Fragen, in dieser Reihenfolge, beantwortet werden:

1. Was wird gebaut?
2. Was kann schiefgehen?
3. Was kann dagegen getan werden?
4. Wie bewerte ich das Ganze?
5. War die Analyse gut genug?

Jede dieser fünf Fragen kann als ein Prozessschritt der Bedrohungsanalyse betrachtet werden.

Nachdem ein „vollständiges“ Diagramm des Systems erstellt worden ist, überlegt man sich in der nächsten Aktivität, was alles schiefgehen kann. Hierbei kann es hilfreich sein, gewisse Annahmen zu treffen, um die möglichen Bedrohungen etwas einzugrenzen.

Beispiel: Wenn man das System in Abbildung 1 betrachtet, können durch die Annahme, dass ein aktuelles (und gepflegtes) Betriebssystem verwendet wird, einige Bedrohungen von vornherein ausgeschlossen werden. Aber Vorsicht! Diese Annahmen sollten stets überprüft und bei der Bedrohungsanalyse festgehalten werden.

Einige Fragen kommen sofort in den Sinn:

1. Ist der Web-Server wirklich der, als der er sich ausgibt?
2. Können die Daten zwischen Web-Proxy und Webapplication manipuliert werden?
3. Wie stellt die Webapplication sicher, dass die Datenbank die Daten erhalten hat?
4. Kann ein Benutzer durch die Webapplication auch die Architektur dahinter erkennen?
5. Kann die Webapplication  (oder die Datenbank) durch hohe Last abstürzen?
6. Kann ein Benutzer im Kontext der Webapplication Dinge tun, die er nicht dürfte?
7. …

Diese Liste kann man natürlich sehr lange fortsetzen. Entsprechend schnell kann es passieren, dass wichtige Dinge übersehen werden. Daher sollte eine gewisse Methodik bei diesen Fragen benutzt werden. Wir werden hier die STRIDE-Methode anwenden, welche von Loren Kohnfelder bei Microsoft entwickelt wurde. Dabei steht STRIDE für:

S: Spoofing
T: Tampering
R: Repudiation
I: Information Disclosure
D: Denial of Service
E: Elevation of Privilege

Mit dieser Methodik können wir unsere „Was kann schiefgehen?“-Fragen kategorisieren und durch ein strukturiertes Vorgehen die Wahrscheinlichkeit reduzieren, dass etwas übersehen wurde. Genau betrachtet kann jede oben als Beispiel aufgeführte Frage diesen Kategorien zugeordnet werden.

Am Ende der „Was kann schiefgehen?“-Aktivität sollte nun eine Liste von Bedrohungen zu allen im System-Diagramm aufgezeichneten Interaktionen und Daten vorliegen. Im nächsten Schritt gehen wir die Liste durch und adressieren alle gefundenen Bedrohungen. Das geht auf vier verschiedene Arten:

• Mitigation bedeutet, Maßnahmen zu ergreifen, um eine Bedrohung abzuschwächen bzw. es schwieriger zu machen, dass eine Bedrohung ausnutzbar wird. Beispiel: Passwörter für eine administrative Schnittstelle mitigieren die Bedrohung, dass sich jemand als Administrator ausgeben könnte.
• Eliminierung erreicht man meistens durch Streichen von Features. Beispiel: Man kann die administrative Schnittstelle mit Passwörtern schützen, aber die Bedrohung, dass sich jemand als Administrator ausgeben könnte, ist immer noch vorhanden. Eine Abschaltung der administrativen Schnittstelle würde diese Bedrohung eliminieren.
• Transfer erreicht man, wenn man die Bedrohung auf jemand anderen überträgt. Man könnte zum Beispiel die Authentifizierung für die administrative Schnittstelle dem Betriebssystem überlassen oder einem Active Directory Service.
• Akzeptieren ist, wenn man beschließt, nichts gegen eine gefundene Bedrohung zu unternehmen. Dies kann unterschiedliche und auch valide Gründe haben. Meistens sind das (auch) Kosten-Nutzen Abwägungen.

Nun wollen wir beispielhaft die Fragen aus Schritt 2 angehen:

An dieser Stelle sei gesagt, dass es noch weitere Maßnahmen für diese Bedrohungen geben kann und dass diese Tabelle definitiv nicht vollständig ist.

Nun hat man eine Liste von Bedrohungen und unterschiedliche Strategien zur Adressierung dieser Bedrohungen. Im nächsten Schritt müssen wir die Mitigationen bewerten und priorisieren. Die dann ausgewählten Mitigationen sollten in den Softwareentwicklungszyklus aufgenommen werden. Hier kann man z.B. (Evil) User-Stories oder Bugs verwenden. Beispiel:

• Ein Angreifer kann durch zu viele automatisierte Anfragen die Datenbank zum Absturz bringen.  

Am Ende dieser Aktivität hat man eine Menge To-Dos, die umgesetzt werden müssen. Doch vor der Umsetzung bewerten wir alle Bedrohungen und Maßnahmen, um eine Kosten-Nutzen-Analyse zu machen.

Nach den letzten beiden Aktivitäten hat man eine Menge an Bedrohungen und möglichen Gegenmaßnahmen identifiziert. Jetzt geht es darum, diese Bedrohungen bzw. die Gegenmaßnahmen zu priorisieren. Hierzu bestimmt man für jede Bedrohung das Bedrohungsrisiko. Eine Möglichkeit zur Bestimmung ist folgende Formel:

Bedrohungsrisiko = Eintrittswahrscheinlichkeit X Auswirkung

Hier gibt es unterschiedliche Ansätze, wie man solche Bedrohungsrisiken bewertet:

• Microsoft Bug Bar
• CVSS (Common Vulnerability Scoring System)
• …

In größeren Unternehmen wird dies im Sicherheitsstandard des Unternehmens festgehalten. Um es hier einfach zu halten, kann man die Eintrittswahrscheinlichkeit und die Auswirkung in vier Kategorien einordnen:

Sehr hoch, Hoch, Mittel, Niedrig

Daraus leitet sich (beispielhaft) folgende Matrix ab:

Die Möglichkeiten zur Bewertung der Bedrohung sind sehr vielfältig. Im ersten Schritt ist nur wichtig, ein abgestimmtes Vorgehen zur Bewertung der Bedrohungen zu nutzen, dass einheitlich angewandt wird.

Nachdem alle Bedrohungen ohne Gegenmaßnahmen bewertet werden, sollte man diese Bedrohungen mit Gegenmaßnahme(n) erneut bewerten. Letzteres dient aber eher Dokumentationszwecken und ist hilfreich, um im Nachhinein Entscheidungen nachzuvollziehen.

In unserem Hausbespiel könnte man das Bedrohungsrisiko einer Kellerüberflutung in unterschiedlichen Klimaregionen unterschiedlich bewerten: In einer Region, in der es wenig regnet, ist die Eintrittswahrscheinlichkeit geringer als in den Regionen mit regelmäßigen Starkregenfällen. Wenn aber eine Überflutung stattfinden sollte, wäre die Auswirkung gleich. Dies ist aber nicht immer so, die Auswirkung einer Bedrohung kann durchaus mit Maßnahmen reduziert werden.

Die Bewertungen dienen vor allem dazu, Entscheidungen zu erleichtern – auch Entscheidungen gegen eine Schutzmaßnahme. In unserem Hausbeispiel würde es sich zum Beispiel in einigen Regionen nicht lohnen, eine Wasserpumpenanlage in den Keller zu stellen.  

Zurück zur IT: Nachdem das Bedrohungsrisiko für alle Bedrohungen bestimmt wurde, kann man diese nach der Beispiel-Matrix priorisieren und in den Softwareentwicklungsprozess aufnehmen. Besonders kann man dokumentieren warum man einige Bedrohungen akzeptieren möchte (s. Schritt 3), aber auch, warum einige Maßnahmen bevorzugt werden.

Der letzte Schritt im Threat Modeling ist die Validierung der Bedrohungsanalyse.

Überprüfung der Architektur

Zuerst geht man zurück zu seinem Diagramm und überprüft, ob es noch korrekt ist. Es ist nicht unüblich, dass Designentscheidungen kurzfristig geändert werden: Features kommen hinzu, vorher nicht bedachte Use-Cases bringen andere Datensätze mit sich, Interaktionen zwischen Systemen ändern sich, …, etc. Also muss das Diagramm aktualisiert bzw. erweitert werden. Es hilft, sich dabei auf den Datenfluss zu konzentrieren.

Überprüfung der Bedrohungen

Natürlich müssen neue Bedrohungen, die durch eine geänderte Architektur entstehen, identifiziert werden. Danach sollten noch einmal alle identifizierten Bedrohungen hinsichtlich ihrer Mitigationen überprüft werden. Dafür müssen wir die Liste der Bedrohungen erneut durchgehen und dabei folgende Fragen stellen:

• Wurde jede einzelne Bedrohung adressiert?
• Wurde jede einzelne Bedrohung richtig mitigiert?

Tests für die Maßnahmen

Für alle Maßnahmen sollten Tests durchgeführt werden. Diese können manuell oder auch automatisiert stattfinden. Es muss sichergestellt werden, dass alle Maßnahmen, die umgesetzt werden sollen, auch getestet werden. Idealerweise sollten diese Tests in das schon vorhandene Testing-Framework bei der Entwicklung integriert werden. Natürlich könnte man hier eine Ebene tiefer gehen und eine Bedrohungsanalyse gegen die Maßnahmen starten. Dies mag in einigen hoch sicheren IT-Systemen sinnvoll und nützlich sein, aber für die meisten (Web-)Anwendungen ist so etwas nicht notwendig.

Natürlich ist eine „echte“ Bedrohungsanalyse noch um einiges detaillierter als der hier skizzierte Ablauf. Es sollte dennoch deutlich geworden sein, dass es wichtig ist, Sicherheit z.B. durch die Durchführung von Threat Modelings bereits konzeptionell mit in den Entwicklungsprozess zu integrieren und in regelmäßigen Abständen zu aktualisieren Die hier gezeigte Analyse mit ihren Mitigations- und Kosten-Nutzen-Überlegungen sorgt für mehr Sicherheit von Anfang an.

In unserem nächsten Beitrag zu Threat Modeling werden wir Abbildung 1 erweitern und methodisch die fünf Schritte des Threat Modeling durchgehen, um eine detaillierte Liste von Bedrohungen festzustellen.

Hier geht es zu unserem