Erste Schritte mit dem Threat Modeling Tool
Das Microsoft Threat Modeling Tool 2018 wurde im September 2018 als kostenlos per Mausklick herunterladbare Version für die Allgemeinheit veröffentlicht. Die Änderung am Übermittlungsmechanismus ermöglicht uns, die neuesten Verbesserungen und Fehlerkorrekturen per Push an Kunden zu übertragen, sobald sie das Tool öffnen, wodurch es einfacher zu warten und zu nutzen ist. Dieser Artikel begleitet Sie durch die ersten Schritte mit dem Bedrohungsmodellierungsansatz des Microsoft Security Development Lifecycle (SDL) und veranschaulicht, wie Sie das Tool einsetzen, um überzeugende Bedrohungsmodelle als tragende Säule Ihres Sicherheitsprozesses zu entwickeln.
Dieser Artikel setzt auf vorhandenen Kenntnissen zum SDL-Bedrohungsmodellierungsansatz auf. Eine Kurzübersicht finden Sie im Artikel zur Bedrohungsmodellierung für Webanwendungen und in einer archivierten Version des 2006 veröffentlichten MSDN-Artikels Uncover Security Flaws Using the STRIDE Approach (Aufdecken von Sicherheitslücken mit der STRIDE-Methode).
Kurz zusammengefasst, umfasst diese Methode das Erstellen eines Diagramms, das Bestimmen von Bedrohungen und deren Entschärfung sowie das Überprüfen jeder Entschärfung. Es folgt ein Diagramm dieses Prozesses:
Starten des Bedrohungsmodellierungsprozesses
Wenn Sie das Threat Modeling Tool starten, fallen Ihnen einige Dinge auf (siehe die Abbildung):
Abschnitt „Bedrohungsmodell“
Komponente | Details |
---|---|
Schaltfläche „Feedback, Vorschläge und Probleme“ | Führt Sie zum MSDN-Forum für alles, was den SDL betrifft. Sie erhalten eine Möglichkeit, sich durchzulesen, was andere Benutzer unternehmen, und finden Problemumgehungen und Empfehlungen. Wenn Sie dennoch nicht finden, was Sie suchen, senden Sie eine E-Mail an tmtextsupport@microsoft.com, in der Sie unser Supportteam um Hilfe bitten. |
Modell erstellen | Öffnet einen leeren Zeichenbereich, in dem Sie Ihr Diagramm zeichnen können. Wählen Sie für Ihr Modell unbedingt die entsprechende Vorlage. |
Vorlage für neue Modelle | Vor Erstellung eines Modells müssen Sie die zu verwendende Vorlage auswählen. Unsere Hauptvorlage heißt „Azure Threat Model Template“, die Azure-spezifische Schablonen, Bedrohungen und Entschärfungen enthält. Wählen Sie für generische Modelle im Dropdownmenü „SDL TM Knowledge Base“ aus. Möchten Sie eine eigene Vorlage erstellen oder allen Benutzern eine neue bereitstellen? Auf unserer GitHub-Seite Template Repository erfahren Sie mehr. |
Modell öffnen | Öffnet zuvor gespeicherte Bedrohungsmodelle. Die Funktion „Zuletzt geöffnete Modelle“ eignet sich besonders, wenn Sie Ihre zuletzt verwendeten Dateien öffnen müssen. Wenn Sie den Mauszeiger über der Option bewegen, finden Sie zwei Möglichkeiten zum Öffnen von Modellen:
|
Leitfaden zu den ersten Schritten | Öffnet die Hauptseite des Microsoft Threat Modeling Tools . |
Abschnitt „Vorlage“
Komponente | Details |
---|---|
Neue Vorlage erstellen | Öffnet eine leere Vorlage zum Erstellen eines Modells. Wenn Sie nicht über umfassende Kenntnisse der Erstellung von Vorlagen von Grund auf verfügen, sollten Sie vorhandene Vorlagen als Basis verwenden. |
Vorlage öffnen | Dient zum Öffnen vorhandener Vorlagen, an denen Sie Änderungen vornehmen können. |
Das Threat Modeling Tool-Team arbeitet fortlaufend an der Verbesserung der Funktionalität und Benutzeroberfläche des Tools. Im Laufe des Jahres können einige kleinere Änderungen erfolgen, doch alle größeren Änderungen erfordern ein Umschreiben des Leitfadens. Konsultieren Sie diesen häufig, um die neuesten Ankündigungen unbedingt zu erhalten.
Erstellen eines Modells
In diesem Abschnitt begleiten wir:
- Cristina (Entwicklerin)
- Ricardo (Programmmanager) und
- Ashish (Tester)
Sie durchlaufen den Prozess der Entwicklung ihres ersten Bedrohungsmodells.
Ricardo: Hallo Cristina, ich habe am Bedrohungsmodelldiagramm gearbeitet und möchte sicherstellen, dass alle Details richtig sind. Kannst du mit mir einen Blick darauf werfen? Cristina: Absolut. Sehen wir uns das genauer an. Ricardo öffnet das Tool und gibt seinen Bildschirm für Cristina frei.
Cristina: OK, das sieht unkompliziert aus, aber kannst du es mit mir durchgehen? Ricardo: Ja, natürlich. Dies ist die Gliederung:
- Unsere menschlichen Benutzer werden als externe Entität gezeichnet (ein Quadrat).
- Sie senden Befehle an unseren Webserver (den Kreis).
- Der Webserver fragt eine Datenbank ab (zwei parallele Geraden)
Was Ricardo gerade eben Cristina gezeigt hat, ist ein Datenflussdiagramm . Das Threat Modeling Tool ermöglicht Benutzern die Angabe von Vertrauensstellungsgrenzen, die durch die rot gepunkteten Linien angezeigt werden, um zu veranschaulichen, welche verschiedenen Entitäten die Kontrolle haben. IT-Administratoren benötigen z.B. zu Authentifizierungszwecken ein Active Directory-System, weshalb das Active Directory außerhalb ihrer Kontrolle ist.
Cristina: Das sieht stimmig aus. Was ist mit den Bedrohungen? Ricardo: Das zeige ich dir.
Analysieren von Bedrohungen
Nachdem er auf der Menüleiste mit den Symbolen auf die Analyseansicht (Datei mit Lupe) geklickt hat, gelangt er zu einer Liste generierter Bedrohungen, die das Threat Modeling Tool basierend auf der Standardvorlage gefunden hat. Diese befolgt den DSL-Ansatz STRIDE (Spoofing, Manipulation, Nichtanerkennung, Veröffentlichung von Informationen, Nichtanerkennung, Denial of Service, Rechteerweiterungen). Die Idee ist, dass Software mit einer vorhersagbaren Gruppe von Bedrohungen geliefert wird, die mithilfe dieser sechs Kategorien gefunden werden können.
Diese Methode ist vergleichbar mit dem Absichern Ihres Hauses, indem sichergestellt wird, dass alle Türen und Fenster über einen Sperrmechanismus verfügen, ehe Sie eine Alarmanlage hinzufügen oder dem Dieb nachjagen.
Ricardo beginnt mit der Auswahl des ersten Elements in der Liste. Hier geschieht Folgendes:
Erstens wird die Interaktion zwischen den beiden Schablonen verbessert.
Zweitens werden weitere Informationen zur Bedrohung im Fenster „Bedrohungseigenschaften“ hinzugefügt.
Die generierte Bedrohung hilft ihm, potenzielle Schwächen im Entwurf zu verstehen. Die STRIDE-Kategorisierung bietet ihm eine Vorstellung potenzieller Angriffsvektoren, während ihn die zusätzliche Beschreibung informiert, was genau falsch ist und welche potenziellen Entschärfungsmöglichkeiten es gibt. Er kann in den editierbaren Felder Notizen in die Begründungsdetails eingeben oder die Prioritätsstufen abhängig von der Fehlerleiste seiner Organisation ändern.
Azure-Vorlagen bieten zusätzliche Details, die Benutzern helfen, nicht nur zu verstehen, was falsch ist, sondern auch Korrekturen vorzunehmen, indem Beschreibungen, Beispiele und Links zu Azure-spezifischer Dokumentation hinzugefügt werden.
Dank der Beschreibung wurde ihm die Bedeutung des Hinzufügens eines Authentifizierungsmechanismus klar, um zu verhindern, dass Benutzer Opfer eines Spoofings werden, der ersten Bedrohung, die zu entschärfen ist. Nach einer mehrminütigen Unterhaltung mit Cristina war beiden die Wichtigkeit der Implementierung einer Zugriffssteuerung und von Rollen bewusst. Ricardo hat einige kurze Notizen eingegeben, um sicherzustellen, dass diese implementiert wurden.
Nachdem Ricardo die Bedrohungen unter „Veröffentlichung von Informationen“ untersucht hatte, stellte er fest, dass für den Zugriffssteuerungsplan einige schreibgeschützte Konten für die Überwachung und Berichterstellung erforderlich waren. Er fragte sich, ob dies eine neue Bedrohung sein sollte, doch die Entschärfungen waren dieselben, weshalb er die Bedrohung entsprechend notierte. Er dachte auch ein wenig mehr über die Preisgabe von Informationen nach und bemerkte, dass für die Sicherungsbänder eine Verschlüsselung erforderlich war, eine Aufgabe für das Betriebsteam.
Bedrohungen, die für den Entwurf aufgrund vorhandener Entschärfungen oder Sicherheitsgarantien nicht zutreffend waren, können im Dropdownmenü „Status“ in „Nicht zutreffend“ geändert werden. Es gibt drei weitere Optionen: „Nicht gestartet“ (Standardauswahl), „Untersuchung erforderlich“ (für die Nachverfolgung von Elementen) und „Entschärft“ (nach Abschluss des Prozesses).
Berichte und Freigabe
Nachdem Ricardo die Liste mit Cristina durchlaufen und wichtige Notizen, Entschärfungen/Begründungen, eine Priorität und Statusänderungen hinzugefügt hat, wählt er „Berichte -> Vollständigen Bericht erstellen -> Bericht speichern“ aus. Den ausgegebenen Bericht geht er mit Kollegen durch, um sicherzustellen, dass die Sicherheitsmaßnahmen ordnungsgemäß umgesetzt wurden.
Wenn Ricardo stattdessen die Datei freigeben möchte, kann er sie dazu mühelos im OneDrive-Konto der Organisation speichern. Im Anschluss kann er den Dokumentlink kopieren und für seine Kollegen freigeben.
Besprechungen zur Bedrohungsmodellierung
Nachdem Ricardo sein Bedrohungsmodell über OneDrive an seinen Kollegen gesendet hat, war Ashish, der Tester, alles andere als begeistert. Es schien ihm, als hätten Ricardo und Cristina einige wichtige Ausnahmefälle übersehen, die leicht ausgenutzt werden könnten. Seine Skepsis ist eine Ergänzung für Bedrohungsmodelle.
In diesem Szenario, nachdem Ashish das Bedrohungsmodell übernommen hatte, beraumte er zwei Besprechungen zur Bedrohungsmodellierung an: eine Besprechung zum Synchronisieren hinsichtlich des Prozesses und Durchlaufen der Diagramme und eine zweite Besprechung zur Bedrohungsüberprüfung und Genehmigung.
In der ersten Besprechung verbrachte Ashish 10 Minuten damit, mit allen Teilnehmern den SDL-Bedrohungsmodellierungsprozess zu durchlaufen. Er rief dann das Bedrohungsmodelldiagramm ab und begann, es im Detail zu erläutern. Binnen fünf Minuten wurde eine wichtige fehlende Komponente identifiziert.
Ein paar Minuten später begannen Ashish und Ricardo eine längere Diskussion darüber, wie der Webserver erstellt wurde. Dies war nicht der ideale Verlauf einer Besprechung, doch alle Teilnehmer waren sich schließlich einig, dass das frühzeitige Aufdecken der Diskrepanz ihnen künftig Zeit sparen würde.
In der zweiten Besprechung ging das Team die Bedrohungen durch, erörterte verschiedene Möglichkeiten zu ihrer Entschärfung und genehmigte das Bedrohungsmodell. Das Team checkte das Dokument in die Quellcodeverwaltung ein und setzte die Entwicklung fort.
Überlegungen zu Datenobjekten
Einigen Lesern, die Bedrohungsmodelle entwickelt haben, wird vielleicht aufgefallen sein, dass wir überhaupt nicht über Datenobjekte gesprochen haben. Wir haben festgestellt, dass viele Softwareentwickler ihre Software besser verstehen als das Konzept von Datenobjekten und an welchen Datenobjekten ein Angreifer ggf. interessiert ist.
Wenn Sie ein Bedrohungsmodell für ein Haus erstellen, beginnen Sie ggf. mit dem Nachdenken über Ihre Familie, unersetzbare Fotos oder wertvolle Kunstgegenstände. Sie denken vielleicht darüber nach, wer in das aktuelle Sicherheitssystem einbrechen könnte. Oder Sie beginnen mit der Inaugenscheinnahme der physischen Merkmale wie Pool oder Veranda. Diese Vorgehensweise ist analog zum Nachdenken über Datenobjekte, Angreifer und Softwareentwurf. Jeder dieser drei Ansätze funktioniert.
Der hier vorgestellte Ansatz zur Bedrohungsmodellierung ist wesentlich einfacher als das, was Microsoft in der Vergangenheit angeboten hat. Wir haben herausgefunden, dass der Softwareentwurfsansatz in vielen Teams funktioniert. Wir hoffen, dass das auch für Ihr Team stimmt.
Nächste Schritte
Senden Sie Ihre Fragen, Kommentare und Probleme an tmtextsupport@microsoft.com. Laden Sie das Threat Modeling Tool herunter , um die ersten Schritte zu unternehmen.