Security Briefs

Erste Schritte mit dem SDL-Bedrohungsmodellierungstool

Adam Shostack

Inhalt

Starten des Bedrohungsmodellierungsprozesses
Analysieren von Bedrohungen
Umgebungsbildschirm
Verfolgen von Berichten
Das Menü „Actions“
Besprechungen zur Bedrohungsmodellierung
Nachdenken über Ressourcen

Abbildung 1 Der Bedrohungsmodellierungsprozess

Im November 2008 hat Microsoft die allgemeine Verfügbarkeit des SDL-Bedrohungsmodellierungstools (Security Development Lifecycle) als kostenloser Download von MSDN angekündigt. In diesem Artikel wird ein Team durch bei den ersten Schritten mit dem SDL-Bedrohungsmodellierungsansatz begleitet. Dabei erfahren Sie, wie Sie mit dem neuen Tool großartige Bedrohungsmodelle als Rückgrat Ihres Sicherheitsprozesses entwickeln können.

Dieser Artikel ist keine Einführung in SDL-Bedrohungsmodellierung. Lesen Sie dazu den Artikel in der Ausgabe des MSDN Magazins vom November 2006 über die Verwendung des STRIDE-Ansatzes, Bedrohungsmodellierung: Aufdecken von Fehlern im Sicherheitsentwurf mithilfe des STRIDE-Ansatzes. Abbildung 1 bietet einen schnellen Überblick über den Prozess.

Starten des Bedrohungsmodellierungsprozesses

Wenn Sie das SDL-Bedrohungsmodellierungstool starten, werden Sie sehen, dass die linke untere Ecke sehr nach Microsoft Office Outlook mit vier Fenstern aussieht: Diagramm, Analyse, Umgebung und Berichte (weitere Informationen finden Sie in Abbildung 2). Diese Fenster unterscheiden sich ein wenig von der Darstellung in Abbildung 1, da es logisch ist, Bedrohungen und Problembehebungen zusammen zu betrachten, weil sie eng zusammenhängen.

In diesem Abschnitt werden Deb (eine Entwicklerin), Paul (ein Programmmanager) und Tim (ein Tester) durch beim Prozess des Entwickelns ihres ersten Bedrohungsmodells begleitet. Außerdem wird jeder Bildschirm des Tools erörtert.

„Hallo Deb, ich habe an diesem Bedrohungsmodelldiagramm gearbeitet und wollte es mit dir durchgehen, um sicherzustellen, dass wir die Details richtig hinbekommen haben.“

„Klar, Paul! Komm rein.“

Paul holt einen Ausdruck eines Diagramms hervor, das er bereits aus dem in Abbildung 3 gezeigten „Nur Diagramme“-Bericht des Bedrohungsmodellierungstools erstellt hat.

„Paul, diese Diagramme habe ich noch nicht gesehen. Sie sehen sehr einfach aus, aber kannst du mir erklären, was die verschiedenen Formen bedeuten?“

„Das funktioniert so: Carl, unsere normale Kundenpersona, ist als äußere Entität gezeichnet, ein Rechteck. Er sendet Befehle an unseren Webserver. Der Kreis ist beliebiger ausgeführter Code, und mit dem Pfeil wird die Kommunikationsrichtung angegeben. Der Webserver konsultiert eine Datenbank. Die wird, wie alles, wo Daten gespeichert werden, als zwei parallele Linien dargestellt. Das System wird Datenflussdiagramm (data flow diagram, DFD) genannt. In Wikipedia gibt es einen guten Artikel zu DFDs. Das Einzige, was dort nicht behandelt wird, sind diese gestrichelten Linien der Vertrauensgrenze zwischen den verschiedenen Personen, die die Leitung innehaben. Du weißt ja, dass die IT-Experten verlangen, dass wir ihr Active Directory-System für Anmeldeinformationen verwenden. Deshalb ist Active Directory als außerhalb unserer Kontrolle dargestellt.“

Abbildung 3 Pauls DFD-Diagramm

Wenn das Tool gestartet wird, wird der Diagrammbildschirm angezeigt. An dieser Stelle hat Paul mit den Visio-Tools und der bereitgestellten Schablone sein DFD gezeichnet (siehe Abbildung 4). Obwohl er dies zum ersten Mal getan hat, fühlte er sich wohl damit, da das Validierungssteuerelement auf der linken Seite ihm aufgrund seiner Erfahrung mit Bedrohungsmodellierung als Bestandteil von SDL Feedback gegeben hat. Als er feststellte, dass er mit mehr Komplexität gezeichnet hat, fügte er zusätzliche Details hinzu. Dazu klickte er mit der rechten Maustaste auf den Kontextordner in der rechten oberen Ecke. Dadurch konnte er ein komplexes, geschichtetes Diagramm erstellen.

Abbildung 4 Der Diagrammbildschirm

Analysieren von Bedrohungen

Paul war ein wenig zögerlich, als er den Analysebildschirm öffnete (siehe Abbildung 5). Dort wurde eine lange Liste mit Bedrohungen angezeigt. Wo kamen die alle her? Sie waren mithilfe des SDL-Ansatzes namens „STRIDE pro Element“ vom Tool erstellt worden. Das Konzept besteht darin, dass Software im Allgemeinen einer Reihe vorhersagbarer Bedrohungen unterliegt (in Abbildung 5 dargestellt). Einige Sicherheitsfachleute möchten zuerst den Hacker verfolgen, weil die Verfolgung selbst Spaß machen kann. Ich denke, es ist logisch, Ihr Haus zu sichern, indem Sie sicherstellen, dass jede Tür und jedes Fenster mit einer Art Schloss versehen ist. Erst dann sollten Sie über eine Alarmanlage nachdenken. Beginnen Sie also mit „STRIDE pro Element“, indem Sie auf eine beliebige Zeile auf dem Analysebildschirm klicken.

Abbildung 5 Der Analysebildschirm

Paul begann mit der Auswahl der Datenbank in der Liste der Elemente. Er hat oben im Bildschirm gelesen, dass „Datenbank“ ein Datenspeicher ist und deshalb von Manipulationen, der Offenlegung von Informationen und Denial-of-Service-Bedrohungen betroffen sein kann. Während er weiterlas, halfen ihm die Fragen, darüber nachzudenken, wie Personen die Daten manipulieren könnten. Dabei erkannte er, dass niemand festgelegt hatte, wer eine Verbindung zur Datenbank herstellen darf. Ein kleines Diagramm und einige einfache Regeln hatten die erste Bedrohung offenbart. Ein Punkt für die Bedrohungsmodellierung.

Ein paar Minuten Diskussion führten zu der Feststellung, dass über Zugriffssteuerung und -regeln nachgedacht werden musste. Paul fügte rasch einige Hinweise zu zwei Bedrohungen hinzu. Der erste Hinweis lautete „Kein Zugriffssteuerungsplan“. Er legte auch eine Arbeitsaufgabe in der TFS-Datenbank (Team Foundation Server) ab. Der zweite Hinweis lautete „Zugriffssteuerungsplan erfordert Rollenliste“. Paul begab sich dann in TFS und erstellte einen zweiten Fehler, der vom ersten abhängig ist.

Als Paul sich mit der Offenlegung von Informationen beschäftigte, erkannte er, dass der Zugriffssteuerungsplan einige schreibgeschützte Konten für die Überwachung und Berichterstellung erfordert. Er fragte sich, ob dies eine neue Bedrohung sei, und entschied dann, dass dem nicht so ist, da die Problembehebung die gleiche ist. Daraufhin bearbeitete er den Fehler in TFS. Dann beschloss er zu belegen, dass die Bedrohung andernorts minimiert wird, und schrieb „Behoben in TFS-Fehler Nr. 235“. Er war nicht ganz sicher, ob das in Ordnung war, aber dafür ist das Zertifizierungsfeature gedacht (siehe Abbildung 6).

Abbildung 6 Belegen, dass Bedrohungen nicht zutreffen

Er dachte auch noch ein wenig über die Offenlegung von Informationen nach und erkannte, dass die Sicherungsbänder verschlüsselt werden müssen, aber das ist eine Aufgabe der Betriebsabteilung. (Ich komme gleich dazu, wie er das nachverfolgte, nachdem ein verwandtes Feature behandelt wurde: das Kontrollkästchen für das automatische Generieren von Bedrohungen für ein Element oben im Bildschirm.)

Die automatische Generierung ist für große Teams vorgesehen, die viele Bedrohungsmodelle haben und sicherstellen können, dass die Tester und Programmmanager alle Punkte in den Bedrohungsmodellen besprechen. In dieser Situation könnte Paul z. B. sagen, dass Phil für mehrere Elemente verantwortlich ist, die er als Kontext zeigen möchte, sowie dafür, wie sie mit seinen Features interagieren. Das Kontrollkästchen für die automatische Generierung ist standardmäßig aktiviert, aber Paul kann es deaktivieren und erklären, dass er der Meinung sei, dies sei Phils Feature.

Umgebungsbildschirm

Besorgt darüber, dass die Sicherungsbänder in der Betriebsabteilung verschlüsselt werden, öffnete Paul den Umgebungsbildschirm und sah einen Abschnitt für externe Sicherheitshinweise (siehe Abbildung 7). Dort erstellte er einen Hinweis, dass die Bandsicherung von der Betriebsabteilung vorgenommen werden muss. Er würde sicherstellen müssen, dass die Betriebsabteilung eine Kopie des Tools hat.

Abbildung 7 Externe Sicherheitshinweise

Während er sich dort befand, fragte er sich, worum es sich beim Dokumentkopfabschnitt handelt. Er war erleichtert, dass es am oberen Bildschirmrand weiteren Anleitungstext gab. Darin wurde erklärt, dass an jener Stelle angegeben wird, wer Eigentümer des Bedrohungsmodells ist, wofür es gedacht ist und dergleichen. Er füllte dies aus und wünschte sich, die Contoso-Projektnachverfolgungsnummer einfügen zu können.

Beim systematischen Durchgehen der Elemente der Struktur stellte Paul fest, dass es Abhängigkeiten von SQL Server und der Fabrikam Foxy Web Widgets 2.3-Widgetbibliothek gab. Paul fügte einen Hinweis hinzu, dass Tim dies untersuchen und sich vergewissern sollte, dass sie auf dem aktuellen Stand sind und Sicherheitsbenachrichtigungen von Fabrikam erhalten.

Verfolgen von Berichten

Es stehen fünf Bedrohungsmodellierungsberichte zur Verfügung:

Analysebericht Dieser Bericht ist für einen Sicherheitsberater oder Berater vorgesehen, um ein Bedrohungsmodell zu überprüfen. Der Bericht kann aber von jedem verwendet werden, um zu sehen, welche Diagrammvalidierungsprobleme offen sind, welche leeren Bedrohungen nicht ausgefüllt wurden, für welche Bedrohungen es keine Problembehebungen gibt und welche Bedrohungen zertifiziert oder als keine Bedrohungen generierend markiert wurden.

Bedrohungsmodellbericht Dieser Bericht enthält die Informationen, die ins Bedrohungsmodell eingegeben wurden, dargestellt auf einer Seite.

Nur Diagramme Dieser Bericht wurde dazu entwickelt, das Drucken von Diagrammen zu vereinfachen. Einige Personen arbeiten gern mit Papier, müssen aber nicht ganze Berichte drucken, wenn sie nur das Diagramm haben möchten.

Fehlerbericht In diesem Bericht werden die Fehler angezeigt, die von diesem Bedrohungsmodell erfasst werden, sowie ihr Status.

Fuzzingbericht Anhand der architektonischen Informationen im Diagrammerstellungsschritt wird eine priorisierte Liste von Fuzzingzielen bereitgestellt. Fuzzing ist ein Testverfahren, bei dem zufällige Eingaben für ein Programm generiert werden. Es ist erstaunlich, wie gut Fuzzing darin sein kann, Programme abstürzen zu lassen. Viele dieser Abstürze sind ausnutzbar. (Weitere Informationen zum Fuzztesten finden Sie unter Erstellen eines benutzerdefinierten Testschnittstellenanbieters für Team System und Fuzztesten bei Microsoft und der Triage-Prozess.)

Das Menü „Actions“

Im Menü „Actions“ sind einige nützliche Features versteckt: Miniaturansicht, Fehlernachverfolgungseinstellungen und Teamleitermodus. Mithilfe der Miniaturansicht können Sie einfach auf die Diagramme zugreifen, wenn Sie sich in anderen Bildschirmen befinden. Das ist nützlich, wenn Sie ein komplexes Diagramm haben und dieses während der Analyse Ihres Modells auf dem Bildschirm sehen möchten. Die Größe der Miniatur wird automatisch so angepasst, dass es einen Großteil des Fensters ausfüllt. Bei der Größenänderung wird weiterhin das gesamte Diagramm angezeigt.

Wenn Sie versuchen, einen Fehler ohne Fehlerinformationen zu erfassen, wird das Dialogfeld der Fehlerüberwachung angezeigt. Sie können dieses Dialogfeld aber jederzeit über das Menü „Actions“ aufrufen. Es gibt eine sehr einfache XML-Datei, mit der Sie Felder definieren können, die ausgefüllt werden sollen. Sie können die Felder auch einfach nur bearbeiten (vorausgesetzt, das Kontrollkästchen für die Vorlagenverwendung ist nicht aktiviert). Fehler erhalten automatisch einen Titel wie „TM: [Bedrohung] betrifft [Element]“, und die Inhalte bezüglich Informationen zur Bedrohung und Problembehebung sind vorausgefüllt. Felder können gelöscht werden, indem sie ausgewählt werden und dann die Taste „Entf“ betätigt wird.

Im Teamleitermodus wird im Umgebungsbildschirm ein neuer Abschnitt für Vorlageneinstellungen angezeigt. Dadurch kann ein Teamleiter die anleitenden Fragen ändern und einen Standardspeicherort für Bedrohungsmodelle festlegen. Der Teamleiter kann auch die Felder in Dokumentkopfinformationen bearbeiten und Elemente hinzufügen bzw. entfernen, um die Umgebung anzupassen.

Paul fügte die Contoso-Projektnachverfolgungsnummer als neues Feld hinzu, wie er es bereits früher erledigen wollte. Jedes im Teamleitermodus gespeicherte Bedrohungsmodell kann als Vorlage dienen. (Tatsächlich kann jedes Bedrohungsmodell als Vorlage für zusätzliche Arbeiten dienen.)

Das Ändern der anleitenden Fragen erfordert die Bearbeitung einer XML-Datei, die ihren Ursprung im Ordner „\Data“ des SDL-Bedrohungsmodellierungstools hat. Das Format ist recht einfach zu befolgen.

Besprechungen zur Bedrohungsmodellierung

Als Paul sein Bedrohungsmodell herumsendete, war Tim, der Tester, alles andere als begeistert. Ihm sprang alles Mögliche ins Auge, und er fragte Paul: „Ihr Programmmanager nehmt immer an, dass alles funktioniert, was?“

Möglicherweise ist die Erkenntnis für Sie überraschend, dass Tester und ihr Skeptizismus eine großartige Ergänzung für Bedrohungsmodelle darstellen können. Infolgedessen bitten viele Teams ihre Tester, den Bedrohungsmodellierungsprozess zu leiten. Nachdem Tim in diesem Szenario das Bedrohungsmodell übernommen hatte, setzte er zwei Besprechungen zur Bedrohungsmodellierung an: eine Besprechung, um den Prozess zu synchronisieren und die Diagramme durchzugehen, und eine zweite zur Prüfung der Bedrohungen und zur Genehmigung.

In der ersten Besprechung verbrachte Tim 10 Minuten damit, den SDL-Bedrohungsmodellierungsprozess für alle Beteiligten durchzugehen. Dann holte er das Bedrohungsmodelldiagramm hervor und erklärte es ausführlich. Innerhalb von fünf Minuten war eine wichtige fehlende Komponente identifiziert worden.

Einige Minuten später engagierten sich Tim und Paul in einer ausgedehnten Erörterung darüber, wie der Webserver tatsächlich aufgebaut sei. Das war nicht die ideale Art und Weise, um mit der Besprechung fortzufahren, aber schließlich stimmte jeder zu, dass die frühzeitige Entdeckung der Unstimmigkeit ihnen später viel Zeit sparen würde.

In der zweiten Besprechung ging das Team die Bedrohungen durch, erörterte einige Möglichkeiten zu deren Behebung und segnete das Bedrohungsmodell ab. Das Dokument wurde in die Quellcodeverwaltung eingecheckt, und die Entwicklung wurde fortgesetzt.

Nachdenken über Ressourcen

Einige Leser, die Bedrohungen modelliert haben, haben vielleicht festgestellt, dass gar nicht von Ressourcen die Rede war. Wir haben festgestellt, dass viele Softwareentwickler ihre Software besser verstehen als das Konzept von Ressourcen sowie die Frage, an welchen Ressourcen ein Angreifer interessiert sein könnte.

Wenn Sie Bedrohungen für ein Haus modellieren, denken Sie u. U. zuerst an Ihre Familie oder unersetzliche Fotos oder wertvolle Kunstwerke. Vielleicht denken Sie als Erstes daran, wer einbrechen könnte, sowie an das aktuelle Sicherheitssystem. Oder Sie beginnen mit der Betrachtung der physischen Merkmale wie dem Pool oder der vorderen Veranda. Dies ist analog zum Nachdenken über Ressourcen, Angreifer oder Softwareentwürfe. Einer dieser drei Ansätze wird funktionieren.

Der hier präsentierte Ansatz zur Bedrohungsmodellierung ist wesentlich einfacher als das, was Microsoft in der Vergangenheit getan hat. Das Microsoft SDL-Team hat herausgefunden, dass der Softwareentwurfsansatz bei vielen Teams sehr gut funktioniert. Wir hoffen, dass das auch für Ihres gilt.

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 für die Bedrohungsmodellierungskomponente des SDL verantwortlich.