Bedrohungsmodellierung: Architektur, Angriffsszenarien und Kontrollen
Sytance · Aktualisiert
Bedrohungsmodellierung ist ein strukturiertes Verfahren, um zu erkennen, wie ein Produkt angegriffen werden könnte, und Maßnahmen zur Risikominderung auszuwählen. Die Analyse beginnt mit der Produktarchitektur und erläutert, wie ein Angriff erfolgreich sein könnte, was er beeinträchtigen würde und wie die vorgeschlagene Schutzmaßnahme überprüft wird.
Produktversion und Bereitstellung
Ein Bedrohungsmodell gilt für eine bestimmte Produktversion und Bereitstellung. Ein internetverbundenes Gateway und dasselbe Gateway in einem isolierten Wartungsnetz können unterschiedliche Einstiegspunkte und Betriebsannahmen haben.
Beziehen Sie Personen ein, die sich mit Architektur, Entwicklung, Produktnutzung und Sicherheit auskennen. Sammeln Sie vor der Sitzung genügend Material, um einen normalen Betriebsablauf von Anfang bis Ende zu erläutern.
- Die Version, die unterstützte Bereitstellung und die vorgesehenen Nutzer.
- Die Architektur, externen Schnittstellen und ausgetauschten Daten.
- Die Berechtigungen der einzelnen Nutzer, Dienste und lokalen Prozesse.
- Die sensiblen Daten, Zugangsdaten und Produktfunktionen, die geschützt werden müssen.
- Die vorhandenen Kontrollen und alle Annahmen, die noch bestätigt werden müssen.
Datenflüsse und Vertrauensgrenzen
Ein Datenflussdiagramm (DFD) zeigt externe Entitäten, Prozesse, Datenspeicher und Datenbewegungen. Eine Vertrauensgrenze kennzeichnet einen Wechsel des Vertrauens oder der Berechtigung. Sie kann zwischen einem Browser und einer API, zwischen zwei Betriebssystemkonten oder zwischen einem Gerät und einem entfernten Dienst liegen.
Geben Sie jedem Datenfluss eine Richtung, eine Datenbeschreibung und einen Schutzmechanismus. Ein als „Cloud“ beschrifteter Kasten verbirgt zu viele Details, wenn mehrere Dienste unterschiedliche Identitäten und Berechtigungen haben. Teilen Sie den Kasten auf, wenn dieser Unterschied die Analyse verändert.
Beginnen Sie beim Beispiel des Industrie-Gateways mit dem Browser des Bedieners, der Gateway-Verwaltungs-API, dem lokalen Konfigurationsspeicher, der lokalen Steuerung, dem Telemetriedienst und dem Updatedienst. Stellen Sie Verwaltung und Telemetrie als TLS-Verbindungen dar. Behandeln Sie die Überprüfung der Update-Signatur als vorgeschlagene Kontrolle, solange ihre Umsetzung nicht belegt ist.
Von STRIDE-Kategorien zu Angriffsszenarien
STRIDE gruppiert Bedrohungen in Spoofing, Manipulation, Abstreitbarkeit, Offenlegung von Informationen, Denial of Service und Rechteausweitung. Verwenden Sie diese Kategorien, um Fragen zu relevanten Prozessen und Datenflüssen anzuregen. Ein Kategoriename allein beschreibt keinen Angriff.
Beispiel: Ein Nutzer mit Lesezugriff sendet direkt eine Anfrage zur Konfigurationsänderung an die Verwaltungs-API. Prüft die API zwar die Anmeldung, nicht aber die Berechtigung für die Aktion, kann der Nutzer die Gateway-Konfiguration ändern. Damit sind Akteur, Einstiegspunkt, fehlende Kontrolle und Auswirkung benannt.
Verknüpfen Sie jedes Szenario mit der relevanten Schnittstelle, dem Prozess oder Datenfluss im Diagramm. Szenarien mit unterschiedlichen Angriffsbedingungen oder Kontrollen sind getrennt zu analysieren. Ist eine Bedingung unbekannt, etwa die Authentifizierung an der Steuerungsschnittstelle, halten Sie fest, was noch zu bestätigen ist.
Risikoprioritäten und Sicherheitskontrollen
Risikoprioritäten hängen von Zugang und Fähigkeiten ab, die ein Angreifer benötigt, von der Erfolgswahrscheinlichkeit und den Folgen für das Produkt. Eine vereinbarte Risikomethode sorgt für konsistente Bewertungen. Die Begründung einer Einstufung ermöglicht anderen, sie nachzuvollziehen.
Wählen Sie eine Maßnahme, die das Team umsetzen kann. Für das Szenario der Konfigurationsänderung muss die API bei jedem Schreibvorgang die Berechtigungen des Aufrufers durchsetzen. Weisen Sie eine verantwortliche Person, eine Zielversion und eine Prüfung zu, die die Wirksamkeit der Kontrolle belegt.
Vorhandenes TLS schützt eine Transportverbindung; es belegt nicht, dass ein angemeldeter Nutzer die Konfiguration ändern darf. Prüfen Sie die Kontrolle anhand des konkreten Angriffsschritts, den sie verhindern soll. Akzeptiert das Team ein Restrisiko, dokumentieren Sie die Begründung und die dafür befugte Person.
Verifizierung und Aktualisierung des Modells
Eine vorgeschlagene Kontrolle und eine verifizierte Kontrolle sind unterschiedliche Zustände. Verknüpfen Sie eine implementierte Kontrolle mit der betreffenden Änderung und ihrem Verifizierungsergebnis. Senden Sie im API-Beispiel eine Schreibanfrage als Nutzer mit Leserechten und bestätigen Sie sowohl die Ablehnung als auch, dass die Konfiguration unverändert bleibt.
Überprüfen Sie das Modell, wenn sich eine Schnittstelle, Berechtigung, Komponente, Bereitstellung oder ein Update-Mechanismus ändert. Neue Informationen zu Schwachstellen können ebenfalls eine frühere Annahme ungültig machen. Bewahren Sie das vorherige Modell auf, damit das Team erläutern kann, für welche Versionen eine Entscheidung galt.