Ein nützliches Bedrohungsmodell erklärt, was Sie schützen, wer oder was es beeinflussen kann, wo sich das Vertrauen ändert und wie Sie die wichtigsten Risiken reduzieren und testen werden. Beginnen Sie mit dem tatsächlichen Projekt statt mit einer generischen Liste von Werkzeugen.
Definieren Sie einen Umfang, der klein genug zum Durchdenken ist
Beginnen Sie mit einem funktionierenden Dienst: einem Kundenportal, einer Publishing-Seite oder einer internen Anwendung. Schreiben Sie die Komponenten auf, die Sie betreiben, und die externen Systeme, auf die Sie sich verlassen. Ein Bedrohungsmodell sollte Annahmen sichtbar machen, nicht suggerieren, dass jeder mögliche Angriff gelöst wurde. Halten Sie die erste Version klein genug, dass die Personen, die die Anwendung bereitstellen, sie ohne einen separaten Berater zur Interpretation des Diagramms erklären können.
Listen Sie die wertvollen Ergebnisse und Assets auf. Dazu können Kundendaten, Administratorzugriff, Zahlungsstatus, veröffentlichte Inhalte und die Fähigkeit zur Wiederherstellung des Dienstes gehören. Verfügbarkeit kann ein Asset sein, auch wenn die Informationen öffentlich sind. Entscheiden Sie, welche Ausfälle unpraktisch wären und welche Menschen oder die Organisation schädigen würden. Diese Unterscheidung hilft Ihnen, Kontrollen zu priorisieren, statt jede Warnung gleich zu behandeln.
Zeichnen Sie die Stellen ein, an denen sich das Vertrauen ändert
Die Threat-Modeling-Leitlinien von OWASP verwenden Datenflüsse und Vertrauensgrenzen, um ein Design verständlich zu machen. Zeichnen Sie für eine kleine gehostete Anwendung den Browser, den Webprozess, die Datenbank, den Administrator, das Backup-Ziel und externe Integrationen. Markieren Sie die Informationen, die sich zwischen ihnen bewegen. Eine Anfrage, die von einem nicht vertrauenswürdigen Client in eine privilegierte Serveroperation übergeht, verdient ausdrückliche Validierung und Autorisierung.
Gehen Sie nicht davon aus, dass Komponenten innerhalb derselben Maschine alle gleichermaßen vertrauenswürdig sind. Ein öffentlicher Upload-Prozess sollte nicht dieselben Berechtigungen haben wie die Datenbankadministration. Ein Backup-Job benötigt möglicherweise Lesezugriff, ohne Live-Anwendungsdatensätze ändern zu können. Die Trennung dieser Rollen macht die Auswirkung einer kompromittierten Komponente leichter eindämmbar und die erforderlichen Berechtigungen leichter überprüfbar.
Wählen Sie konkrete Ausfallszenarien
Verwenden Sie eine Handvoll plausibler Ereignisse, um das Design herauszufordern. Ein Angreifer stiehlt ein Administratorkennwort; ein Benutzer fordert den Datensatz eines anderen Benutzers an; ein Upload füllt die Festplatte; eine Bereitstellung legt eine Konfigurationsdatei offen; eine Wiederherstellungskopie kann nicht wiederhergestellt werden. Beschreiben Sie die Ausgangsbedingung, die betroffene Komponente und die Konsequenz. Ein konkretes Szenario ist leichter zu testen als eine breite Anweisung zur Verbesserung der Sicherheit.
Beziehen Sie Fehler und Missbrauch legitimer Workflows ebenso ein wie externe Eindringlinge. Ein Wiederholungsversuch kann zwei wertvolle Vorgänge erzeugen, oder zwei Anfragen können um dieselbe Änderung an einem Objekt konkurrieren. Die Business-Logic-Leitlinien von OWASP heben diese Prozessannahmen hervor. Prüfen Sie, wer einen Workflow in seinen nächsten Zustand versetzen darf und ob das Wiederholen oder Umordnen einer Anfrage das Ergebnis unerwartet ändert.
| Szenario | Zu untersuchende Kontrolle | Zu erfassende Nachweise |
|---|---|---|
| Gestohlenes Administrationskennwort | Eingeschränkter Zugriff und ein zweiter Faktor, wo unterstützt | Eine unbefugte Anmeldung kann nicht abgeschlossen werden |
| Objekt eines anderen Benutzers angefordert | Serverseitige Objekt-Autorisierung | Ein isolierter Test liefert ein verweigertes Ergebnis |
| Festplatte durch Uploads erschöpft | Größen-, Quota- und Aufbewahrungskontrollen | Ein Limit wird vor dem Dienstausfall durchgesetzt |
| Doppelte Workflow-Anfrage | Idempotenz und Transaktionsgrenzen | Eine wiederholte Anfrage erzeugt ein Ergebnis |
Priorisieren Sie nach Auswirkung und glaubhaftem Pfad
Notieren Sie für jedes Szenario seine potenzielle Auswirkung und die Bedingungen, unter denen es auftreten kann. Vermeiden Sie die Vortäuschung, dass eine geschätzte numerische Punktzahl eine präzise Wahrscheinlichkeit ist. Sie können dennoch ein im Internet exponiertes schwaches Passwort von einem stark bedingten lokalen Ereignis unterscheiden. Weisen Sie den wichtigen Risiken einen Verantwortlichen und einen praktischen nächsten Schritt zu, damit das Modell Arbeit erzeugt, die jemand tatsächlich erledigen kann.
Betrachten Sie neben der Kompromittierung der Anwendung auch den Informationslebenszyklus. Ein Diagnose-Export kann während des ansonsten normalen Betriebs unnötige Daten offenlegen. Ein aufbewahrtes Kontofeld kann lange nach dem Ende seines Zwecks eine Exposition erzeugen. Eine Datenschutzprüfung kann daher Informationen entfernen oder die Aufbewahrung verkürzen, während eine Sicherheitsprüfung den Zugriff auf das verbleibende beschränkt. Beide Änderungen gehören ins Modell, wenn sie das Projekt schützen.
Testen Sie die Kontrollen in einer autorisierten Umgebung
Erstellen Sie eine Staging-Umgebung mit repräsentativen Berechtigungen und fiktiven Datensätzen. Testen Sie verweigerten Zugriff, Anfragegrenzen, Workflow-Wiederholungen und Wiederherstellung. Verwenden Sie keine echten Kundendaten, wenn synthetische Daten das Verhalten demonstrieren können. Ziel ist es, die Kontrolle zu überprüfen, nicht beeindruckenden Angriffsverkehr zu erzeugen. Bleiben Sie innerhalb von Systemen, die Ihnen gehören oder deren Bewertung Sie ausdrücklich autorisiert haben.
Halten Sie fest, was bestanden wurde, was fehlgeschlagen ist und was unbekannt bleibt. Ein Scanner-Ergebnis kann als Nachweis dienen, ersetzt aber keinen Test der Geschäftsregeln der Anwendung. Ebenso verifiziert eine Netzwerkschutzoption nicht die Objektberechtigung oder den Umgang mit geheimen Dateien. Fügen Sie die nützlichen Ergebnisse dem Szenario bei, damit künftige Betreuer verstehen, warum eine bestimmte Kontrolle existiert.
Halten Sie das Modell mit Änderungen verbunden
Überprüfen Sie die relevanten Teile, wenn Sie eine Integration hinzufügen, einen neuen Endpunkt bereitstellen, ein Recht ändern oder Daten an ein anderes Ziel verschieben. Sie müssen nicht die gesamte Architektur für eine kleinere Textänderung neu zeichnen. Der Auslöser ist eine geänderte Annahme über Zugriff, Informationen oder Systemverhalten. Bewahren Sie das Modell neben der Bereitstellungs- und Wiederherstellungsdokumentation auf, anstatt es als einmaliges Workshop-Ergebnis zu belassen.
SwissOctet bietet einen Katalog von Infrastrukturoptionen, kein vollständiges Bedrohungsmodell für Anwendungen. Wählen Sie die Konfiguration und Optionen, die Ihre Kontrollen unterstützen, und überprüfen Sie dann die Bereitstellung, die Sie erstellen. Ein kleines, gepflegtes Modell mit getesteten Maßnahmen ist nützlicher als eine große Sammlung von Sicherheitsprodukten ohne klare Erklärung der Risiken, die sie adressieren.
Ihre praktische Checkliste.
- Listen Sie Assets und Folgen eines Fehlschlags auf.
- Zeichnen Sie Datenflüsse und Vertrauensgrenzen.
- Wählen Sie spezifische Szenarien für Eindringen, Fehler und Workflows.
- Weisen Sie den wichtigen Risiken Kontrollen und Verantwortliche zu.
- Testen Sie mit synthetischen Daten in einer autorisierten Umgebung.
- Überprüfen Sie das Modell, wenn sich eine relevante Annahme ändert.
Die Details, die zählen.
Brauche ich ein formales Framework, um anzufangen?+
Nein. Ein kleines Diagramm und eine dokumentierte Sammlung von Szenarien können nützlich sein. Ein Framework hilft sicherzustellen, dass Sie Risiken konsistent überprüfen.
Ersetzt ein Schwachstellenscanner die Bedrohungsmodellierung?+
Nein. Scanner können technische Schwächen finden, während ein Bedrohungsmodell auch Designannahmen, Berechtigungen und Geschäftsworkflows untersucht.
Wie oft sollte ich das Modell aktualisieren?+
Aktualisieren Sie die betroffenen Teile, wenn sich Datenflüsse, Integrationen, Berechtigungen oder exponierte Funktionalität ändern, und überprüfen Sie ungelöste Risiken regelmäßig.
Gehen Sie zur Quelle.
Diese Referenzen unterstützen die technischen Konzepte in diesem Leitfaden. Folgen Sie der aktuellen Dokumentation, bevor Sie ein Produktionssystem ändern.
- OWASP: Threat Modeling Cheat Sheet cheatsheetseries.owasp.org
- OWASP: Bedrohungsmodellierung in der Praxis devguide.owasp.org
- OWASP: Sicherheit der Geschäftslogik cheatsheetseries.owasp.org
Redaktionelle Beratung durch SwissOctet. Beispiele sind illustrativ. Servicespezifikationen, verfügbare Optionen und vertragliche Bedingungen müssen separat überprüft werden.