Verwenden Sie Wardley Mapping zur Optimierung Ihrer Bedrohungsmodellierungsstrategie

Anfang dieser Woche stellte Patrick Debois auf Twitter die Frage, "inwieweit Sie Dinge wie dns, ca, Proxies [...] usw. als Teil der API-Sicherheit betrachten".

Twitter Status @patrickdebois Dies führte zu einer kurzen Diskussion über den Umgang mit der Komplexität und dem Umfang eines Bedrohungsmodells, für das ich vorschlug, das Konzept der begrenzten Kontexte und eine Wardley-Karte zu verwenden.

Das führte natürlich zu weiteren Diskussionen und einer Frage nach einem Beispiel aus dem wirklichen Leben, wie man das macht. Da ich versprochen hatte, mir etwas einfallen zu lassen und es wahrscheinlich nicht in einen (Haufen) Tweets passen würde, habe ich beschlossen, einen Blog darüber zu schreiben.

Hier sind die Drachen!

Eine Warnung vorweg: Die Kombination eines DDD-Ansatzes mit der Bedrohungsmodellierung ist größtenteils ein "Hier sind die Drachen" Gebiet. Dieser Ansatz konzentriert sich auch darauf, wie man mit komplexen Systemen in einer Bedrohungsmodellierungsstrategie umgeht. Er wird nicht so detailliert sein wie Techniken wie STRIDE, aber er wird Ihnen hoffentlich einen besseren Überblick darüber geben, wo Sie STRIDE anwenden können, ohne sich in schmutzigen Details zu verlieren.

Bevor wir in dieses ungewohnte Terrain eintauchen, möchte ich Ihnen einige Hintergrundinformationen geben, die für das Verständnis im Vorfeld nützlich sind;

• Wenn Sie mit der Bedrohungsmodellierung nicht vertraut sind, empfehle ich Ihnen, mit dem Threat Modeling Manifesto zu beginnen.
• Wenn Sie mit dem Wardley Mapping nicht vertraut sind, empfehle ich Ihnen, sich die Einführung auf dem YouTube-Kanal von HiredThought anzusehen oder Simons Buch auf Medium zu lesen.
• Ich habe viel Inspiration aus einer Präsentation von Susanne Kaiser bei einem DDD France Meetup mit dem Titel "Building adaptive systems with Wardley mapping, DDD, and Team Topologies" gezogen.

Beginnen Sie mit einer einfachen Karte

Lassen Sie uns mit Patricks ursprünglicher Frage beginnen: "Inwieweit betrachten Sie Dinge wie dns, ca, Proxies [...] usw. als Teil der API-Sicherheit?". Es ist klar, worauf diese Frage hinausläuft: Entwicklungsteams müssen sich bei der Entwicklung ihrer Anwendungen in der Regel nicht viele Gedanken über die Netzwerkarchitektur machen, aber sobald Sie anfangen, über Sicherheit nachzudenken, gibt es in vielen Netzwerkschichten potenzielle Probleme und viele davon haben Auswirkungen auf die Anwendung selbst. Andererseits können Sie nicht die ganze Welt in Ihr Design einbeziehen, also wo ziehen Sie die Grenzen?

Versuchen wir also einfach, uns einen Überblick über das zu verschaffen, womit wir es zu tun haben und eine erste Karte zu erstellen. In diesem Beispiel habe ich die folgenden Annahmen getroffen, die auf realen Erfahrungen beruhen:

• die Website, die mobile App und die API werden intern entwickelt
• DNS, WAF, Proxies, Loadbalancer, Firewalls, TLS-Verarbeitung werden von kommerziellen oder Open-Source-Paketen verwaltet.
• Zertifizierungsstellen und BGP werden als Handelsware/Dienstleistung genutzt
• die Verwaltung der Netzwerkkomponenten wird in der Regel von einem Netzwerkteam (oder einer Abteilung) übernommen, während die Anwendungsteile von einem produktorientierten Entwicklungsteam bearbeitet werden

In dieser Karte ignoriere ich auch die Wertachse, da es schwierig ist, den Benutzer zu definieren (vielleicht ein 'Datenpaket'?) und wenn wir einen korrekten OSI-basierten Datenfluss verwenden würden, würde es wahrscheinlich ziemlich schnell unübersichtlich werden. Für die Informationen, nach denen wir suchen, ist das jedoch nicht wirklich wichtig.

Wenn Sie all diese Informationen in unsere erste Karte einfügen, ergibt sich etwa folgendes Bild:

Die erste Erkenntnis, die Sie aus dieser Karte ziehen können, betrifft den Grad der Kontrolle und der Verantwortlichkeiten. Je weiter rechts eine Komponente platziert ist, desto weniger Kontrolle haben Sie über sie. Das bedeutet, dass Sie auf konfigurierbare Teile oder Serviceanfragen beschränkt sind, wenn Sie etwas ändern möchten. Gleichzeitig bedeutet dies automatisch, dass Sie umso mehr für die Sicherheit verantwortlich sind, je weiter links eine Komponente platziert ist.

Auf der Suche nach Ärger

Da wir nun eine Karte haben, können wir mit der Erkundung der Landschaft beginnen. Wo könnten die Bereiche sein, die wir weiter erforschen müssen und wie sollten wir das tun? In der Übersicht der Chancen gibt es 4 Punkte, die für die Identifizierung möglicher Bedrohungen sehr wichtig sind:

• Voreingenommenheit reduzieren
• Geeignete Methoden verwenden
• Entsorgen Sie die Haftung
• Refactor Haftung

Annahmen in Frage stellen

Beginnen wir mit dem ersten, 'Reduzieren Sie Vorurteile', was im Grunde bedeutet: 'Überprüfen Sie Ihre Annahmen'. Verzerrungen treten typischerweise dort auf, wo es Übergaben oder geteilte Verantwortlichkeiten gibt. Hotspots in unserer Karte sind die Linien zwischen Elementen, die von verschiedenen Teams kontrolliert werden. Lassen Sie uns diese mit einem Dreieck markieren. Bei Ihrer Bedrohungsmodellierungsstrategie sollten Sie sich darauf konzentrieren, die Annahmen zwischen den Teams zu überprüfen und sicherzustellen, dass es keine Punkte gibt, bei denen beide Teams erwarten, dass das andere Team sie übernimmt (denn das sind die Dinge, die niemand tut). Sobald Sie alle Versprechen und Annahmen in beiden Teams identifiziert haben, können Sie diese als Input für die detaillierteren Bedrohungsmodellsitzungen innerhalb eines Teams verwenden.

Identifizieren Sie Bedürfnisse und Fähigkeiten

Die nächste Möglichkeit ist 'Angemessene Methoden verwenden', bei der es darum geht, die Reife der von Ihnen verwendeten Lösungen zu überprüfen und weniger riskante Ansätze zu identifizieren. Für diese Analyse ist es wichtig zu verstehen, wo der Wert für Ihr Unternehmen generiert wird, welche Expertise und welches Wissen Sie in der Organisation haben und welche Vorschriften für Ihr Unternehmen gelten. In unserer Karte wäre die Positionierung der API ein interessanter Punkt (ich habe ihn mit einem Stern markiert). Bietet die API wirklich einen Mehrwert oder ist sie eher eine Last? Haben wir die Fähigkeiten und das Fachwissen im Haus, um alle Probleme zu entschärfen? Das Ergebnis dieser Diskussion könnte sein, dass eine API-Härtung (die das Ergebnis eines standardmäßigen STRIDE-basierten Bedrohungsmodells wäre) nicht durchführbar ist und dass es für eine angemessene Risikominderung besser ist, nach einer produkt- oder standardmäßigen Lösung zu suchen.

Eine ähnliche Diskussion kann auch über die Netzwerkkomponenten der unteren Ebene geführt werden. Die Konfiguration, Absicherung und Wartung von DNS-Servern, Load Balancern und Firewalls erfordert Fachwissen, also müssen Sie sicherstellen, dass dieses Wissen in ausreichendem Maße vorhanden ist. Wenn diese Analyse zeigt, dass die Fähigkeiten zur Absicherung dieser Komponenten nicht ausreichen, müssen Sie entweder mehr Fachwissen an Bord holen oder über einen standardisierten Ansatz nachdenken.

Hier hat uns unsere Wardley-Karte geholfen, Orte zu identifizieren, an denen wir in unseren Möglichkeiten eingeschränkt sind. Wenn wir an diesen Stellen Bedrohungen erkennen, wird es uns schwer fallen, sie zu beheben und wir könnten gezwungen sein, alles zu akzeptieren.

Den Müll rausbringen

Die letzten interessanten Möglichkeiten sind 'Dispose of Liability' (brauchen wir wirklich eine Komponente) und 'Refactor Liability' (können wir es einfacher machen). Vom Standpunkt der Sicherheit aus gesehen ist dies im Grunde eine Herausforderung für Ihre Angriffsfläche. Einfacher ausgedrückt: Wenn es sie nicht gibt, kann sie auch keine Probleme enthalten. In unserer Karte sehen wir 3 Komponenten, die http-Anfragen bearbeiten: die API, einen Proxy und eine WAF. Es lohnt sich zu untersuchen, ob diese Situation vereinfacht werden kann, ohne wertvolle Funktionen zu verlieren. Vielleicht kann der Proxy auch als (eingeschränkte, aber ausreichende) WAF fungieren. Ein praktisches Beispiel wäre die Verwendung des mod_security-Plugins auf einem Webserver, der so konfiguriert ist, dass er als Proxy-Server fungiert.

Unsere erste Reise

An diesem Punkt haben wir eine erste Karte erstellt und einige Orientierungspunkte identifiziert, so dass wir beginnen können, über die Reise nachzudenken. Die Reise, die wir zu beschreiben versuchen, lautet: "Wie können wir dieses komplexe System so effizient wie möglich modellieren?".

Auf der Grundlage unserer Wardley-Karte wird deutlich, dass wir die folgenden Diskussionen führen sollten, bevor wir uns eingehend mit der Bedrohungsmodellierung beschäftigen:

• sind die Erwartungen und Versprechen zwischen den Teams völlig klar
• Haben wir in unserem Unternehmen die Möglichkeiten, dieses System sicher genug zu machen, oder sollten wir uns nach einfacheren Lösungen umsehen?
• Verwenden wir tatsächlich alle Komponenten, oder sollten wir zuerst Teile umgestalten?

Die Ergebnisse dieser Diskussionen könnten so aussehen:

• die Rolle der API ist begrenzt und ihr Wert ist nicht sehr groß
• es gibt nur begrenzte Kenntnisse und Fähigkeiten zur Verwaltung der WAF- und Proxy-Schicht
• Es sind nur sehr wenige Anpassungen bei den Load Balancern und DNS-Servern erforderlich.

Auf der Grundlage dieser Ergebnisse können wir die Karte neu zeichnen, um eine Situation zu schaffen, in der die Bedrohungen und Risiken besser beherrschbar sind:

Wohin als nächstes?

Wie ich bereits oben erwähnt habe, ist die Kombination von DDD und Bedrohungsmodellierung größtenteils Neuland, so dass sich die wahren Möglichkeiten erst noch zeigen müssen. Ich hoffe jedoch, mit diesem einfachen Beispiel einige der Möglichkeiten aufgezeigt zu haben, wie wir diesen Ansatz zur effektiven Bedrohungsmodellierung komplexer Situationen nutzen können. Zumindest habe ich gezeigt, wie Sie durch die Erstellung einer Wardley-Map schnell erkennen können, wo Vorurteile und Annahmen validiert werden sollten (immer eine gute Quelle für Zwischenfälle!) und wie Sie die bestehende Architektur aus einer Bedrohungs- und Risikoperspektive in Frage stellen können.