Im Rahmen unserer Serie #cyber#forschung widmen wir uns wieder dem Forschungsprojekt OVVL. Nachdem wir im letzten Beitrag eine grobe Einführung gegeben haben, wollen wir diesmal ein wenig in die Tiefe zoomen und ein paar Erkenntnisse teilen.
Aber um was ging es in diesem Forschungsprojekt nochmal?
Wir beschäftigen uns mit Threat Modeling oder Bedrohungsanalyse. Zusammen mit unseren Projektpartnern entwickeln wir ein Tool, um den oft mühsamen Prozess des Threat Modeling zu vereinfachen und zu beschleunigen.
Auf dem Weg dahin haben wir aber nicht nur unsere interne Methodik verfeinert, sondern auch an einem neuen Konzept gearbeitet, den Bedrohungsdatenbanken, wir nennen diese kurz TH-DB (Threat-Database). Hierbei handelt es sich um eine Datenbank, in der für einen Produkttyp oder für eine technische Domäne (neudeutsch Vertical) alle denkbaren Security-Bedrohungen gelistet sind.
Und was machen wir mit einer TH-DB?
Hierzu haben wir bereits verschiedenste Ideen, zwei davon werden wir hier vorstellen.
Bevor wir die erste Idee beschreiben, müssen wir uns zunächst einmal kurz anschauen, wie typischerweise Threat Modeling betrieben wird, und wo dort die Herausforderungen liegen.
Der Threat Modeling Prozess
Am Anfang wird das analysierte System dekomponiert und es werden alle Schnittstellen identifiziert. Über Schnittstellen greift ein Angreifer ein Produkt oder eine Komponente an. Wenn man nun diese Schnittstellen hat, geht man diese sequentiell durch und überlegt sich zu jeder Schnittstelle, was ein Angreifer alles anrichten kann. Hierbei geht man oft nach dem STRIDE-Modell vor. Jeder Buchstabe steht hier für eine bestimmte Angriffskategorie. S steht für Spoofing, d.h. Angreifer gibt sich für jemand anderen aus, T für Tampering, also wie Angreifer Daten manipulieren können, etc. In der Anwendung erhält man so alle Bedrohungen zu jeder Schnittstelle.
Nun gibt es verschiedene Herausforderungen in dem Threat Modeling Prozess. Zum einen ist es ein kreativer Prozess. Da jedes System verschieden ist, gibt es auch keine allgemeingültige Musterlösung. Zum anderen haben die Domänenexperten den Vorteil, dass sie das System kennen, in der Regel sind diese aber gleichzeitig keine Security-Experten. Umgekehrt haben Security-Experten kein spezifisches Wissen über das System oder die technische Domäne. Wir haben es also typischerweise mit einem Ressourcenproblem zu tun, spätestens dann, wenn häufig oder viele Analysen durchgeführt werden müssen.
Erste Optimierungsidee
In der ersten Optimierungsidee verzichten wir soweit wie möglich bei der Bedrohungsmodellierung auf den Security-Experten. Die Bedrohungsmodellierung wird nur durch den Domänenexperten durchgeführt. Der Domänenexperte nutzt die Bedrohungsdatenbank und kann so Bedrohung für Bedrohung durchgehen und alles relevante identifizieren. Alle irrelevante Bedrohungen werden dabei abgewählt und optimalerweise kurz kommentiert. Am Ende hat er eine Auflistung mit allen Bedrohungen (und optimalerweise auch gleich allen Mitigationen) die für sein System relevant sind. Die Bedrohungsmodellierung selbst findet also in der Bedrohungsdatenbank statt. Die größte Herausforderung bei diesem Ansatz ist, die Daten so aufzubereiten, dass diese für Nicht-Security-Experten handhabbar sind. Nutzer müssen die Daten effektiv und effizient filtern können, um auch ohne Security-spezifisches Know-How gute Ergebnisse zu bekommen.
Zweite Optimierungsidee
Die zweite Optimierungsidee dient der Verbesserung der Arbeitsweise von Security- und Domänenexperte, also dem klassischen Team der Bedrohungsmodellierung. Der Security-Experte übernimmt typischerweise die Moderation. Bei Einsatz einer TH-DB kann diese dem Security-Experten eine große Stütze sein, und bei Bedarf als „doppelter Boden“ dienen. Wenn alles zu einer Schnittstelle und deren Bedrohungen gesagt wurde, dann kann ein Blick in die Datenbank eventuell noch eine andere, übersehene Bedrohung finden.
Auf einen Blick
Zusammengefasst dient im ersten Ansatz die TH-DB als Hauptwerkzeug zur Bedrohungsmodellierung, bei der zweiten Idee dient sie zur Unterstützung und Optimierung des Threat Modelings. In beiden Fällen besteht die Herausforderung, dass die TH-DB aktuell gehalten werden muss. Dies kann man durch Updates der TH-DB nach jedem Workshop sicherstellen. Eine weitere Herausforderung ist, dass für jede technische Domäne eine eigene Strategie definiert werden muss, also wie z. B. Forschungsergebnisse in die Datenbank kommen.
Wie geht’s weiter?
Auf dieses Problem und unsere bisherigen Lösungen werden wir in einem zukünftigen Artikel eingehen. Dann können wir auch vorstellen, wie wir die ersten Prototypen der TH-DB mit einfachen Office-Boardmitteln erstellt haben.