Threat Modeling: Wie kam es überhaupt zu diesem Projekt?
Vor diesem Hintergrund entstand die Idee auf beiden Seiten: Der Spamfilter sollte mithilfe eines systematischen Vorgehens und automatischer Tests auf potenzielle Bedrohungen analysiert und damit die Sicherheit gegenüber Angriffen auf ihn selbst verstärkt werden. Besonders wichtig dabei ist die Anwendung strukturierter Methoden wie Threat Modeling, das speziell für die Analyse von Software entwickelt wurde, um Bedrohungen frühzeitig und systematisch zu erkennen.
Doch wie geht man bei einer so komplexen Aufgabenstellung vor?
Um eine Bedrohungsanalyse zu erstellen, war zunächst eine Dokumentation des Informationsflusses im Spamfilter notwendig. Um diesen zu visualisieren, wurden Datenflussdiagramme genutzt. Datenflussdiagramme sind ein in der Softwarearchitektur genutzter Diagrammtyp, der seinen Fokus auf den Fluss von Daten zwischen Prozessen, Datenspeichern und externen Akteuren richtet. Aus sicherheitstechnischer Sicht ist dieser Diagrammtyp daher hervorragend für eine Bedrohungsmodellierung geeignet, da ein Transfer von Daten stets Ziel eines Angriffs sein könnte.
Mit der Modellierung des Spamfilters in Datenflussdiagrammen war der Grundstein für die weitere Analyse geschaffen: Auf Basis dieser Datenflussdiagramme kann nun eine Technik namens „STRIDE per Element“ angewandt werden. STRIDE per Element wurde von Microsoft entwickelt und in der wissenschaftlichen Literatur insbesondere von Adam Shostack in Büchern und Papern wie „Threat Modeling, Designing for Security“ veröffentlicht. Threat Modeling beschreibt einen strukturierten Prozess und Rahmen für eine geordnete Modellierung und Analyse von Software. Durch die feste Vorgehensweise wird ein möglichst reproduzierbares Vorgehen mit möglichst vollständiger Betrachtung der wichtigsten Bedrohungen erreicht.
Als Teil eines solchen Threat Modelings sieht Microsoft die STRIDE-Bedrohungskategorien. „STRIDE“ ist dabei ein Akronym, in dem jeder Buchstabe für eine Kategorie von üblichen Bedrohungen steht:
- S = Spoofing Identity
- T = Tampering with data
- R = Repudiation
- I = Information Disclosure
- D = Denial of Service
- E = Elevation of Privilege
Diese Bedrohungen werden in „STRIDE per Element“ nun auf jedes Element in den Datenflussdiagrammen des zu analysierenden Systems angewandt. Dabei soll aber nicht jede Kategorie auch für jeden Typ von Element angewandt werden. So kann beispielsweise ein Datenfluss nicht eine falsche Identität vorgeben, wenn er selbst gar keine Identität hat.
Im Falle von Jans Masterarbeit wurde STRIDE per Element für das Datenflussdiagramm unseres HTML Control Panels angewandt. Dabei ist eine Liste von theoretischen Bedrohungen entstanden, die dann alle einzeln weiter analysiert wurden. Neben dem Sammeln von Wegen, einen praktischen Angriff für eine solche theoretische Bedrohung durchzuführen, wurden alle Bedrohungen auch hinsichtlich ihrer Komplexität und ihres Schutzes gegenüber Angriffen bewertet. Aus den Bewertungen lässt sich ein Risiko der einzelnen Bedrohungen berechnen, dass die ermittelte Gefährlichkeit einer Bedrohung wiederspiegelt.
Nach der Risikoanalyse wurden zu einem Teil der gefundenen potenziellen Bedrohungen automatisierte Sicherheitstests erstellt. Diese Tests sollen die bisher zum Teil noch manuelle Prüfung verschiedener Angriffe gegenüber unserem Control Panel automatisieren und so für schnellere, konstantere und vor allem mehr Sicherheitstests sorgen. Diese Sicherheitstests ergänzen die automatisierten Funktions- und Integrationstests in diesem Bereich optimal.
Daneben war aus wissenschaftlicher Perspektive auch interessant zu betrachten, wie gut sich solche theoretisch ermittelten Bedrohungen testen lassen. Die Tests wurden zu einem Teil aus öffentlich verfügbaren Sicherheitsframeworks zusammengestellt und zu einem anderen Teil selbst entwickelt.
Beide Seiten können durchweg ein positives Fazit aus dem Projekt ziehen. Das beschriebene Vorgehen war sehr sinnvoll, weil potenzielle Bedrohungen explizit sichtbar gemacht werden konnten. Darüber hinaus können die entwickelten Tests in Zukunft weiterverwendet werden und damit frühzeitig – bereits in der Entwicklungs- und Testphase – Fehler entdeckt werden.
