MSDN Magazin > Home > Ausgaben > 2008 > Juli >  Security Briefs: Beleben Sie den Prozess der Be...
Security Briefs
Beleben Sie den Prozess der Bedrohungsmodellierung
Adam Shostack

Meine Kollegin Ellen sagt gern, dass jeder zu jeder Zeit Bedrohungsmodelle erstellt. Wir erstellen Bedrohungsmodelle für Flughafensicherheit. Wir erstellen Bedrohungsmodelle für unsere Häuser. Wir denken über Bedrohungen für Dinge nach, die uns wichtig sind: unsere Familien, unsere Wertgegenstände, unsere sentimentalen und unersetzlichen Fotos (zumindest jene von uns, die alt genug sind, Fotos zu besitzen, die es nicht auch in digitaler Form gibt). Wir modellieren Bedrohungen basierend auf Architektur: Hier ist eine Wand, das ein Panoramafenster und dort ein leicht zu erkletternder Baum, den wir nutzen können, wenn wir unseren Schlüssel vergessen haben. Wir modellieren Bedrohungen basierend auf Angreifern. Wir fürchten uns vor Einbrechern und haben Angst, dass Kinder in das Schwimmbecken fallen. Wir fürchten uns auch vor dem Wetter, zum Beispiel vor Erdbeben, Schnee oder Wirbelstürmen.
Ein Unternehmensberater würde sagen, Sie verwenden einen reifen, mehrdimensionalen Bewertungsprozess und vertrauen auf Heuristik und niedrige Reproduzierbarkeit über Instanzen hinweg. Gleichzeitig ist es wahrscheinlich, dass Sie nicht an alles gedacht oder Verteidigungen gegen alle möglichen Angriffe implementiert haben. Es ist unwahrscheinlich, dass Sie einen Hausverteidigungsplan haben oder Ihr Haus jemals einem Penetrationstest unterzogen haben.
Wenn wir Software erstellen, unabhängig davon, ob wir in einer schnelllebigen Welt leben, müssen wir uns darüber einig sein, was erstellt wird und was nicht und wie das Richtige erstellt wird. In den vergangenen Jahren hat sich die Vorstellung durchgesetzt, dass Bedrohungsmodellierung ein schwerer, bürokratischer Prozess ist. Es gibt gute Gründe, weitere Prozesse hinzuzufügen. Diese möchte ich darlegen. Ich möchte über Erfahrungen sprechen, die wir aus diesen Prozessen gewonnen haben, sowie darüber, wie Bedrohungsmodellierung wieder Spaß machen kann, während der Vorgang effizient und flexibel wird, sodass er von jedem ausgeführt werden kann.

Ansätze zur Bedrohungsmodellierung
Vieles wird als Bedrohungsmodellierung bezeichnet. Statt über „den einzig wahren Weg“ zu streiten, sollten die eigenen Bedürfnisse, Fähigkeiten, Kenntnisse und Zeitpläne in Betracht gezogen werden. So können Sie mit der für Sie am besten geeigneten Methode arbeiten. Gemäß diesem Ansatz fragen einige Experten: „Welches Bedrohungsmodell verwenden Sie?“ und „Haben Sie für diese Komponente eine Bedrohungsmodellierung erstellt?“ Ein Weg ist die Anforderungserhebung, der andere die Entwurfsanalyse. Bei Microsoft herrscht letzteres Verfahren vor.
Es gibt wesentlich mehr Methoden für Bedrohungsmodellierung, als in einem Artikel behandelt werden können. Darüber hinaus gibt es auch unglaublich viele unterschiedliche Ziele. Sollte Ihr Bedrohungsmodellierungsprozess schnell oder tiefgehend sein? Sollte er sich auf Sicherung und Vollständigkeit konzentrieren oder auf einfache Anwendbarkeit? Sollten an jedem Treffen Fachleute oder Entwickler beteiligt sein? Müssen Organisations- oder Branchenstandards befolgt werden, wie z. B. der Microsoft® Security Development Lifecycle (SDL) oder die Vorschriften für Hersteller medizinischer Geräte? Oberste Priorität sollte das frühzeitige Verstehen von Sicherheitsproblemen haben, damit diese im Entwurf berücksichtigt werden können, sodass später keine Entwurfsfehler überwunden werden müssen.
Einige Hauptansätze zur Bedrohungsmodellierung umfassen folgende Aspekte:
Ressourcen Ressourcengesteuerte Bedrohungsmodellierung ähnelt dem Nachdenken darüber, was in Ihrem Haus geschützt werden soll. Zunächst wird aufgelistet, mit welchen Ressourcen Ihre Software verbunden ist, und anschließend wird darüber nachgedacht, wie ein Angreifer diese Ressourcen schädigen kann. Beispiele dafür sind eine Datenbank, die Kundenkreditkarten speichert, oder eine Datei, die verschlüsselte Kennwörter enthält.
Einige Experten interpretieren eine Ressource als ein Element des Bedrohungsmodellierungsdiagramms und gehen davon aus, dass ein Webserver selbst eine Ressource ist. Das ist purer Wahnsinn. Ein Angreifer möchte digitale Ressourcen lesen, sie ändern oder Ihnen den Zugriff auf sie verweigern.
Angreifer Angreifergesteuerte Bedrohungsmodellierung erfordert, darüber nachzudenken, wer an Ihren Ressourcen interessiert sein könnte. Sie basiert darauf zu verstehen, welche Fähigkeiten die Angreifer besitzen und wie sie Sie angreifen könnten. Dies funktioniert hervorragend, wenn Ihr Gegner eine fremde Armee mit einer bekannten strategischen Doktrin, physischen Grenzen und einer langen Entwicklungszeit für Waffensysteme ist. Es funktioniert jedoch weniger gut, wenn Ihr Gegner eine locker organisierte Gruppe anonymer Hacker ist.
Vor allem ist nicht klar, ob dies für die Softwarebedrohungsmodellierung hilfreich ist. Es gibt sicher Menschen, für die es ein effektiver Teil der Entwurfsanalyse ist, „wie ein Angreifer zu denken“. Es ist jedoch weniger bekannt, dass dies ein reproduzierbarer Prozess ist, der erlernt werden kann. Wenn Angreifer Ihr Ausgangspunkt sind, lohnt es sich wahrscheinlich, einen Standardsatz zu verwenden. Es wird hilfreich sein, eine kleine Gruppe dieser Antipersonas aufzuschreiben.
Softwareentwurf Entwurfsgesteuerte Bedrohungsmodellierung basiert darauf, wo sich Ihre Zäune und Fenster befinden. Sie zeichnen Diagramme und denken darüber nach, was bei jedem Element im Diagramm schief gehen kann. (Dies ist heute die Grundlage des SDL-Bedrohungsmodellierungsprozesses, da jeder Programmierer weiß, wie Diagramme auf einem Whiteboard gezeichnet werden.)
Die Softwareäquivalente zu Zäunen und Fenstern sind die verschiedenen Formen der Angriffsfläche, wie z. B. Dateiparser oder Netzwerkabfragedienste – Sockets, RPC-Dienste (remote procedure call, Remoteprozeduraufruf), WSDL-Schnittstellen (Web Services Description Language) oder AJAX-APIs. Dies sind die Vertrauensgrenzen, über die ein Angreifer erwartungsgemäß zuerst Zugang erhält.

Ein schnelles und unsauberes Bedrohungsmodell
Bedrohungsmodellierung muss nicht schwierig sein. Entsprechend dem in Abbildung 1 dargestellten Prozess soll nun ein grundlegender Bedrohungsmodellierungsprozesses vorgestellt werden, mit dem Sie schnell und einfach beginnen können:
  1. Erstellen Sie ein Diagramm der Anwendung, mit dem die Anwendung an einem Whiteboard dargestellt werden kann (siehe Abbildung 2). Verwenden Sie Kreise für Code, Kästchen für Dinge, die sich außerhalb befinden (Personen, Server), sowie Zylinder für Speicher. Unser Team verwendet seltsam aussehende parallele Zeilen für Datenspeicher. Zeichnen Sie mithilfe gepunkteter Linien Vertrauensgrenzen, um Domänen zu unterscheiden.
  2. Führen Sie ein Brainstorming zur Identifizierung von Bedrohungen durch. Wenn Sie nicht weiterkommen, können Sie das STRIDE-Bedrohungsmodell, das in Abbildung 3 dargestellt ist, für jedes Element Ihrer Anwendung verwenden. Problembehebungen sind nicht wichtig, Hauptsache das Brainstorming liefert Ergebnisse.
  3. Ziehen Sie Neuentwürfe in Betracht, und überlegen Sie, ob die Bedrohungen gebündelt sind oder völlig verstreut. So oder so ist es empfehlenswert, eine Komponente zu entwerfen oder eine hinzuzufügen, um sie zentral zu behandeln. Konzentrieren sich alle Bedrohungen auf einen Ort, müssen Sie sich möglicherweise Gedanken über die Eingangstür machen und sonst nichts.
  4. Verringern Sie die Bedrohungen erster Ordnung. Gehen Sie dabei in die Breite, nicht in die Tiefe. Es kann hilfreich sein, Bedrohungen und Problembehebungen als in Kategorien eingeteilt zu betrachten. Eine Bedrohung erster Ordnung öffnet die Tür. Die Problembehebung erster Ordnung ist ein Schloss. Die Bedrohung zweiter Ordnung ist, dass jemand das Schloss aufbricht. Die Problembehebungen zweiter Ordnung umfassen gute Schlösser und stabile Türen, die ordentlich eingebaut sind. Eine Verteidigung dritter Ordnung könnte ein Alarmsystem an der Tür sein, und um die Gefahr zu verringern, dass jemand das Kabel durchtrennt, werden regelmäßig Nachrichten über das Kabel gesendet. Wenn Sie sich Gedanken über das Softwareäquivalent dessen machen, was geschieht, wenn jemand das Telefonkabel des Alarmsystems durchtrennt, bevor Sie an Türschlösser denken, machen Sie sich über die falschen Dinge Gedanken.
  5. Archivieren Sie Fehler, damit Sie Probleme beheben können, die bei der Bedrohungsmodellierung gefunden wurden.
Abbildung 1 Der Bedrohungsmodellierungsprozess (zum Vergrößern auf das Bild klicken)
Abbildung 2 Das Erstellen eines Diagramms Ihrer Anwendung hilft bei der Bedrohungsmodellierung (zum Vergrößern auf das Bild klicken)
Bedrohung Eigenschaft Definition Beispiel
Spoofing Authentifizierung Etwas oder jemanden nachahmen. Vorgeben, bspw. Folgendes zu sein: billg, microsoft.com oder ntdll.dll.
Manipulieren Integrität Ändern von Daten oder Code. Ändern einer DLL auf dem Datenträger oder auf der DVD, oder eines Pakets, während es das LAN durchläuft.
Nichtanerkennung Unleugbarkeit Es wird behauptet, dass eine Aktion nicht durchgeführt wurde. „Ich habe diese E-Mail nicht gesendet.“ „Ich habe diese Datei nicht geändert.“ „Ich habe diese Website mit Sicherheit nicht besucht!“
Offenlegung von Informationen Datenschutz Informationen sind für nicht autorisierte Personen zugänglich. Der Windows-Quellcode wird zugänglich gemacht. Eine Liste mit Kunden wird auf der Website veröffentlicht.
Denial-of-Service Verfügbarkeit Dienst für Benutzer verweigern oder einschränken. Windows oder eine Website abstürzen lassen, ein Paket senden und die CPU für Sekunden auslasten, Pakete in ein schwarzes Loch umleiten.
Erhöhung von Berechtigungen Autorisierung Zugriff auf Funktionen ohne die entsprechende Autorisierung erlangen. Einem Remote-Internetnutzer erlauben, Befehle auszuführen. Das ist das klassische Beispiel, aber auch der Wechsel von einem Benutzer mit eingeschränkten Rechten zu einem Administrator zählt dazu.

Wissen, wann es reicht
Wenn in Ihren Diagrammen alle relevanten Teile des Systems dargestellt sind und sie das STRIDE-Modell nach jedem Element im Diagramm durchgegangen sind, sieht es ziemlich gut aus. (Noch besser sieht es aus, wenn Sie Fehler für jedes Sicherheitsrisiko protokolliert haben.)
Das ist jedoch ungefähr so, als wären Sie fertig, wenn überprüft wurde, ob alle Türen und Fenster Schlösser besitzen. Das kann ausreichen. Möglicherweise haben sie nur dafür Zeit. Oder vielleicht planen Sie, mehr in die Tiefe zu gehen, um über Umgehungen der Verteidigungen nachzudenken, die Sie eingerichtet haben.
Wie weit Sie in die Tiefe gehen, hängt zu einem Großteil von der Risikotoleranz Ihrer Organisation ab – oder der Ihres Kunden. Budget und Erfahrung spielen auch eine Rolle. Es kann sein, dass Sie mit dem Bedrohungsmodellierungsprozess beginnen, den Erfolg beweisen und ziemlich schnell wieder aussteigen. Es kann sein, dass Sie das Steuerungssystem für etwas Sicherheitskritisches entwerfen und tief eintauchen müssen und viel Zeit damit verbringen.
Zu wissen, wann Sie fertig sind, beinhaltet also eine Reihe von Kompromissen. Zunächst müssen die Richtlinien, Gesetze oder Regelungen in Betracht gezogen werden, die Ihre Bemühungen betreffen. Dann muss das Risiko für das zu entwickelnde System bewertet werden. Abschließend muss die Verfügbarkeit von Zeit und Ressourcen sowohl für den Bedrohungsmodellierungsprozess als auch für sich daraus ergebende Problembehebungen und Tests berücksichtigt werden.

Durchführung des Bedrohungsmodellierungsprozesses
Bedrohungsmodellierung geschieht nicht von allein. Sie muss von jemandem durchgeführt werden. Wer das ist, wirkt sich entscheidend auf die Funktionsweise aus. Personen, die Sicherheit lieben, können Bedrohungsmodellierung für eine ganze Organisation durchführen.
Die Frage ist, ob andere Personen einbezogen werden sollten und wie. Dies ist sowohl eine kulturelle als auch eine Ressourcenfrage. Wenn jene, die sich einfach dafür interessieren, für alles Bedrohungsmodelle erstellen, Ergebnisse mitteilen und die gefundenen Probleme beheben können, ist das großartig. Warum sollten andere Personen einbezogen werden?
Leider gibt es manchmal mehr Projekte als Personen, die sich gern mit Sicherheitsfragen beschäftigen, und es müssen andere involviert werden. Microsoft hat herausgefunden, dass Bedrohungsmodellierung besser funktioniert, wenn es einen Sicherheitsexperten gibt, aber es steht nicht immer einer zur Verfügung.
Ihr Experte ist jemand, der ständig mit einer strukturierten Herangehensweise über Sicherheit nachdenkt. Er kann darüber sprechen, was eine Nichtanerkennung von Bedrohungen im Zusammenhang mit Ihrem Entwurf bedeuten würde. Möglicherweise verfügt Ihr Experte über eine Zertifizierung. Er weist auf Sicherheitsfehler in Ihrem Code und in Vorgängen hin. Er nimmt vielleicht an Konferenzen teil, wie z. B. SANS oder BlackHat, oder ihm wurde in einem Microsoft Sicherheitsbulletin gedankt.
Gute Ergebnisse lassen sich erzielen, wenn die Arbeit strukturiert wird und Sie Feedback geben, und indem die Arbeit in kleine Teile mit Regeln und Selbstüberprüfungen unterteilt wird. Wird die Bedrohungsmodellierung jedoch in zu viele kleine Teile mit zu vielen (oder den falschen) Regeln aufgeteilt, macht die Arbeit keinen Spaß mehr, und Bedrohungsmodellierung wird zu einer unangenehmen Aufgabe. Die Aufteilung ist also abhängig davon, wie viele Experten zur Verfügung stehen und wie viel Zeit sie in den Prozess investieren können.

Synchronisierung: Umgang mit Änderungen
Pläne ändern sich. Das ist unvermeidlich. Ist dies der Fall, ist es schwierig, die Dokumentation mit den vielen echten Plänen in Einklang zu bringen, die in den Köpfen der Experten vorhanden sind. Egal wie flexibel Sie sind, für ein umfangreicheres Projekt gibt es mit Sicherheit irgendwo eine Architekturdokumentation. Möglicherweise ist es ein Visio®-Diagramm von der Größe einer ganzen Wand, oder es ist ein Whiteboard, das nicht gelöscht werden kann.
Für Bedrohungsmodellierungszwecke ist es wichtig zu wissen, wenn infolge durchgeführter Arbeiten Vertrauensgrenzen hinzugefügt werden. Dabei müssen die Implikationen der neuen Bedrohungen in Betracht gezogen werden.
Manchmal sind die Bedrohungen direkt. Angenommen, Sie ändern eine Komponente, um Port 80 abzuhören. Wenn es direkte Bedrohungen für die Komponente gibt, können sie leicht erkannt und behoben werden, und Sie können sich dem nächsten Problem widmen.
Manchmal sind die Bedrohungen auch indirekt. Angenommen, Sie möchten Konfigurationsdaten von Active Directory® und Lightweight Directory Access-Protokoll (LDAP) abrufen. Dies erfordert wahrscheinlich einige neue Komponenten (die Verzeichnisschnittstelle und eine Abstraktionsschicht zum Umschalten), aber es müssen auch die Konfigurationsdaten geändert werden. Zuvor wurden die Daten möglicherweise von einem Benutzer mit Administratorberechtigung in die grafische Benutzeroberfläche eingegeben. Jetzt kommen diese über das Netzwerk unter Verwendung mehrerer verschiedener Protokolle. Wahrscheinlich möchten Sie die Daten in der Abstraktionsschicht sehr vorsichtig überprüfen, und sicher werden Sie auch vorsichtiger im Umgang mit Konfigurationsdaten.

Hilfe, ich weiß nicht weiter!
Vielleicht gibt es einen Punkt, an dem Sie an einem Tisch sitzen und fragen: „Was machen wir jetzt?“ Vielleicht gibt es Verständnisprobleme in Bezug auf den Prozess. Vielleicht war ein Schritt verwirrend. Dies sind einige Probleme, die im SDL-Team aufgetreten sind, und deren Lösung:
Einige Teams haben Probleme mit der Erstellung von Diagrammen. Wenn Sie nicht wissen, was das System tut, müssen Sie jemanden finden, der sich damit auskennt, oder den Bedrohungsmodellierungsprozess aufteilen und versuchen, es zu verstehen.
Wenn Sie nicht wissen, was das System tun sollte, da Sie an einem neuen System arbeiten und es zwei gegensätzliche Entwürfe gibt, kann die Bedrohungsmodellierung dabei helfen, den Entscheidungsprozess voranzutreiben. Zeichnen Sie beide Entwürfe, und fragen Sie sich, welcher die größten Sicherheitsrisiken aufweist.
Wenn Sie nicht wissen, wie ein Element dargestellt werden soll, bemühen Sie sich nicht unnötig. Vielleicht verwenden Sie den falschen Elementtyp, und Sie werden es merken. Im Wesentlichen ist der Code, für den Sie verantwortlich sind, ein Prozess, egal wer ihn geschrieben hat. Alle gelesenen und geschriebenen Daten werden in Datenspeichern gespeichert.
Vielleicht stoßen Sie auch bei der Aufzählung von Bedrohungen auf Probleme. Zunächst ist es wichtig, dass Sie nicht bei einer einzelnen Bedrohung steckenbleiben. Kennzeichnen Sie sie, und kommen Sie später auf sie zurück. Wenn das nicht funktioniert, empfehle ich die großartige Reihe von Larry Osterman zu Bedrohungsmodellierung (go.microsoft.com/fwlink/?LinkId=118281). Auch die Bücher von Michael Howard, „Writing Secure Code“ und „The Security Development Lifecycle“, sind empfehlenswert.
Bei Problemen mit der Überprüfung des Bedrohungsmodells und Ihres Problembehebungsplans sollten Sie nachsehen, ob die Diagramme den Code wiedergeben und ob darüber Einigkeit zwischen den Entwicklern und Testern besteht. Sehen Sie nach, ob eine Bedrohung für jeden Bedrohungstyp für jedes Element aufgeführt ist (siehe Artikel in der Ausgabe des MSDN® Magazins vom November 2006 „Aufdecken von Fehlern im Sicherheitsentwurf mithilfe des STRIDE-Ansatzes“, der unter msdn.microsoft.com/de-de/magazine/cc163519 verfügbar ist). Prüfen Sie zum Abschluss, ob pro Bedrohung ein Fehler registriert und behoben wurde.
Wenn Sie einen Experten zur Hand haben, bitten Sie ihn um Hilfe. Sogar unsere Fachleute fragen einander: „Wie würden Sie an dieses Problem herangehen?“ Wenn Sie keinen Experten zur Hand haben, versuchen Sie, einen zu bekommen, entweder indem Sie einen einstellen oder indem Sie Ihr Problem in Blogs darlegen.
Lassen Sie sich nicht von einem einzelnen Problem entmutigen. Bedrohungsmodellierung ist zu wichtig, um sie einfach wegzulassen. Denken Sie daran, dass es Spaß machen soll. Das Fehler und Probleme vor der Auslieferung aufzudecken, macht wesentlich mehr Spaß, als sie hinterher beheben zu müssen.

Senden Sie Fragen und Kommentare in englischer Sprache an briefs@microsoft.com.

Adam Shostack ist Programmmanager im SDL-Team (Security Development Lifecycle) bei Microsoft. Er ist verantwortlich für die Bedrohungsmodellierungskomponente des SDL.

Page view tracker