Threat Modeling: aus Architektur Sicherheitsentscheidungen machen

Threat Modeling fragt, was in einem bestimmten System schiefgehen könnte und was das Team dagegen tun sollte. Das nützliche Ergebnis ist kein Katalog beängstigender Möglichkeiten. Es ist eine Reihe von Design- und Umsetzungsentscheidungen, die an die Architektur gebunden sind, mit Verantwortlichen und Nachweisen dafür, dass die gewählten Abwehrmaßnahmen wirken.

Für einen CTO lautet die zentrale Frage, ob die Entwicklung erklären kann, wie wichtige Sicherheitseigenschaften das reale Systemverhalten überstehen: Wiederholungsversuche, Hintergrundjobs, privilegierte Supportaktionen, Ausfälle von Lieferanten und bösartige Eingaben. Ein Diagramm macht diese Gespräche konkret. Ein gepflegtes Bedrohungsmodell überführt die Schlussfolgerungen in Umsetzungsarbeit.

Die Threat-Modeling-Leitlinien von OWASP bieten eine nützliche Grundlage: das System verstehen, Bedrohungen identifizieren, über die Reaktion entscheiden und bewerten, ob die Arbeit ausreicht. Der folgende Ablauf überträgt diesen Ansatz auf technische Entscheidungen.

Beschreiben Sie das System, bevor Sie über Angriffe sprechen

Beginnen Sie mit einer abgegrenzten Funktion, etwa Kundenexporten, Zahlungsauslösung oder Geräteaktualisierungen. Wer eine ganze Plattform auf einmal modelliert, erhält oft oberflächliche Beobachtungen, weil niemand jede Abhängigkeit detailliert genug erklären kann.

Formulieren Sie Werte und Sicherheitsziele in betrieblichen Begriffen. „Kundendaten schützen“ ist zu allgemein. „Ein authentifizierter Nutzer kann nur Datensätze exportieren, die zu seinem berechtigten Mandanten gehören“ gibt dem Team eine Eigenschaft, die es testen kann. Andere Ziele können Transaktionsintegrität, Dienstverfügbarkeit, Wiederherstellung oder die Zuordenbarkeit administrativer Aktionen betreffen.

Ermitteln Sie Nutzer, Dienste, Datenspeicher, externe Abhängigkeiten, Einstiegspunkte und Vertrauensgrenzen. Zeichnen Sie die wichtigen Datenflüsse einschließlich asynchroner Verarbeitung und administrativer Wege. Beschriften Sie Flüsse mit den übertragenen Daten, dem Authentisierungsmechanismus und dem Autorisierungskontext, sofern diese die Analyse beeinflussen.

Eine Vertrauensgrenze markiert einen Wechsel von Annahmen oder Befugnissen, nicht unbedingt einen Netzwerkperimeter. Ein Browser, der eine API aufruft, überschreitet eine Grenze. Ein gemeinsam genutzter Worker, der im Auftrag eines Kunden handelt, überschreitet eine andere, auch wenn beide Dienste im selben Cluster laufen.

Zeigen Sie bei einer mandantenfähigen Anwendung, wo die Mandantenidentität festgestellt wird und wie sie zu Autorisierungsprüfungen, Hintergrundjobs und Exporten gelangt. Beziehen Sie Dienstidentitäten, Zugriff auf Objektspeicher, Support-Werkzeuge und externe Callbacks ein. Andernfalls beschreibt das Diagramm vielleicht den Normalfall, lässt aber gerade die Wege aus, die die Isolation am ehesten umgehen.

Halten Sie Annahmen getrennt von Fakten fest. „Die Queue kann von Kunden nicht beschrieben werden“ braucht unterstützende Nachweise aus der Konfiguration. Unbekanntes sollte zu Untersuchungsaufgaben werden, nicht zu stillschweigend akzeptierten Abwehrmaßnahmen.

Wählen Sie eine Methode, die dem Team beim Denken hilft

Eine Methode liefert Denkanstöße und Struktur. Sie bestimmt nicht, welche Bedrohungen am wichtigsten sind, beweist nicht, dass ein Design sicher ist, und ersetzt nicht das Wissen über das System.

STRIDE für systematische Denkanstöße

STRIDE untersucht sechs Kategorien. Wenden Sie sie auf relevante Komponenten, Flüsse und Grenzen an, statt jede Kategorie auf jedes Diagrammelement zu zwingen.

Ein Szenario kann mehrere Kategorien umfassen. Führen Sie, wo angebracht, einen einzigen umsetzbaren Eintrag, statt doppelte Tickets anzulegen, nur um der Taxonomie zu genügen.

Andere Methoden für andere Fragen

PASTA (Process for Attack Simulation and Threat Analysis) bietet einen siebenstufigen, risikoorientierten Ansatz, der Geschäftsziele, technischen Umfang, Zerlegung, Bedrohungs- und Schwachstellenanalyse, Angriffsmodellierung und Risikobehandlung verbindet. Er eignet sich für tiefere Analysen, wenn Angreiferverhalten und geschäftliche Folgen ausdrücklich betrachtet werden müssen.

Angriffsbäume beginnen mit einem Ziel des Angreifers und zerlegen es in alternative oder kombinierte Wege. Für „den Export eines anderen Mandanten erlangen“ können Alternativen darin bestehen, die API-Autorisierung zu umgehen, den Mandantenkontext des Workers zu verwirren oder ein Download-Credential zu stehlen. UND-Beziehungen stehen für Bedingungen, die gemeinsam eintreten müssen; ODER-Beziehungen stehen für Alternativen.

VAST (Visual, Agile, and Simple Threat modeling) legt den Schwerpunkt auf skalierbare Modellierung aus Anwendungs- und Betriebsperspektive. Teams, die VAST in Betracht ziehen, sollten prüfen, ob ihre Werkzeuge und ihr Entwicklungsprozess diese Sichten einheitlich pflegen können.

Eine praktische Empfehlung für den Einstieg ist ein Datenflussdiagramm mit STRIDE, gefolgt von einem Angriffsbaum für das folgenreichste Szenario. Mehr Methodik ist nur dann nützlich, wenn sie Entscheidungen verbessert.

Führen Sie die Überprüfung entlang konkreter Szenarien durch

Holen Sie die Menschen dazu, die Umsetzung und Betrieb verstehen: eine Entwicklerin, einen Architekten oder eine technische Leitung, eine Person aus der Sicherheitsprüfung und jemanden, der das Produktivverhalten kennt. Beziehen Sie Fachleute aus Produkt, Datenschutz oder Lieferantenmanagement ein, wenn ihr Wissen den Umfang beeinflusst.

Verteilen Sie vor der Sitzung das Diagramm, die Sicherheitsziele, relevante Konfigurationen und offene Annahmen. Gehen Sie während der Überprüfung eine Anfrage oder ein Ereignis vom Eingang bis zum Abschluss durch. Fragen Sie, wo sich die Identität ändert, wo Daten gespeichert werden, was wiederholt wird und welche Komponente befugt ist, eine Aktion zu genehmigen.

Formulieren Sie Bedrohungen als Szenarien, nicht als Etiketten. „Autorisierungsproblem“ ist nicht nützlich genug. Eine stärkere Aussage lautet: „Ein authentifizierter Nutzer ersetzt die Exportkennung durch die eines anderen Mandanten; der Download-Endpunkt prüft die Anmeldung, aber nicht die Zugehörigkeit des Objekts, und legt so Kundendatensätze offen.“

Unterscheiden Sie drei Begriffe:

• Eine Bedrohung beschreibt eine schädliche Handlung oder ein schädliches Ereignis, etwa den unbefugten Abruf eines Exports.
• Eine Schwachstelle ist eine Schwäche, die sie ermöglichen könnte, etwa eine fehlende Prüfung der Objektzugehörigkeit.
• Das Risiko berücksichtigt Eintrittswahrscheinlichkeit und Folgen des Szenarios in der tatsächlichen Umgebung.

Eine Bedrohung kann es wert sein, untersucht zu werden, bevor eine Schwachstelle bestätigt ist. Ebenso belegt das Auffinden einer Schwäche nicht, dass jeder denkbare Angriff durchführbar ist.

Berücksichtigen Sie neben externen Angriffen auch Missbrauch durch legitime Nutzer, privilegierte Innentäter, Konfigurationsfehler und Ausfälle von Lieferanten. Fragen Sie, was passiert, wenn eine Abhängigkeit in ein Timeout läuft oder eine unerwartete Antwort liefert. Fail-open-Verhalten und uneinheitliche Wiederholungen zeigen sich oft in solchen Gesprächen.

Beispiel: eine mandantenfähige Export-Pipeline

Das folgende Beispiel dient der Veranschaulichung. Angenommen, eine SaaS-Anwendung besteht aus einem Browser-Client, einer API, einer gemeinsam genutzten Datenbank, einer Job-Queue, einem Export-Worker und einem Objektspeicher. Nutzer eines Mandanten fordern CSV-Exporte an; der Worker erzeugt Dateien, und die API stellt temporäre Downloadlinks aus. Supportadministratoren haben eine separate Oberfläche zur Fehlersuche.

Die Sicherheitsziele sind Mandantenisolation, befugte Auslösung von Exporten, begrenzter Ressourcenverbrauch und zuordenbare Supportaktionen. Angenommen, der Worker hat so weitreichenden Datenbankzugriff, dass er mehrere Mandanten bedienen kann. Damit wird sein Umgang mit dem Mandantenkontext zu einer zentralen Entscheidung statt zu einem nebensächlichen Umsetzungsdetail.

Befugnisse durch den Fluss verfolgen

An der API wird der authentifizierte Principal den zulässigen Mandantenmitgliedschaften zugeordnet. Eine vom Browser übermittelte Mandantenkennung ist eine Auswahlanfrage, kein Nachweis der Berechtigung. Die API prüft Mitgliedschaft und Exportberechtigung, bevor sie einen unveränderlichen Job-Eintrag mit dem berechtigten Mandanten, der anfragenden Person und dem zulässigen Exportumfang anlegt.

Die Nachricht in der Queue verweist auf diesen Eintrag. Der Worker validiert den Job und erzwingt beim Erzeugen des Exports einen mandantenbezogenen Datenzugriff. Metadaten im Speicher ordnen das erzeugte Objekt dem Job und dem Mandanten zu. Bevor die API einen Downloadlink ausstellt, prüft sie die Berechtigung der aktuell anfragenden Person anhand dieser Zuordnung.

Auch dieses Design erfordert ausdrückliche Entscheidungen zum Entzug von Zugriffen: Soll ein Nutzer, der nach Anforderung eines Exports seine Mitgliedschaft verliert, weiterhin Zugriff auf die fertige Datei haben? Das Team muss diese Regel festlegen und einheitlich umsetzen.

Szenarien in Maßnahmen und Tests überführen

Temporäre Links schaffen ein verbleibendes Expositionsfenster: Je nach Mechanismus kann der Besitz des Links bis zum Ablauf Zugriff ermöglichen. Das Team sollte entscheiden, ob dies für die betroffenen Daten akzeptabel ist oder ob Downloads über eine authentifizierte Zwischenstelle mit aktueller Berechtigungsprüfung laufen müssen.

Schließen Sie das Modell nicht ab, nachdem nur die synchrone API getestet wurde. Verifizieren Sie verzögerte Jobs, Wiederholungen, abgebrochene Anfragen, abgelaufene Mitgliedschaften, gelöschte Mandanten und Teilausfälle. Ein wiederholter Job darf beispielsweise kein Objekt wiederverwenden, das einem anderen Mandanten zugeordnet ist, oder einen unvollständigen Export als erfolgreich veröffentlichen.

Das Arbeitsergebnis ist eine geprüfte Architektur, ein Bedrohungsregister, Umsetzungsaufgaben und verknüpfte Verifizierungsergebnisse, nicht bloß das Diagramm.

Priorisieren Sie nach Exposition und Folgen

Priorisieren Sie plausible Szenarien nach Exposition, Auswirkung, Voraussetzungen und bestehenden Abwehrmaßnahmen. Unterscheiden Sie einen direkt erreichbaren Autorisierungsfehler von einem Szenario, das mehrere unbewiesene Kompromittierungen voraussetzt. Berücksichtigen Sie, wo relevant, betroffene Daten, Dienstunterbrechungen, finanzielle Folgen, Auswirkungen auf die funktionale Sicherheit und den Aufwand der Wiederherstellung.

Verwenden Sie eine einfache, einheitliche Skala, wenn sie dem Team hilft, dokumentieren Sie aber die Begründung der Einstufung. Ein Zahlenwert mit unerklärten Eingaben erzeugt Scheingenauigkeit. CVSS kann die Bewertung einer konkreten Schwachstelle unterstützen; es ersetzt nicht das Verständnis der geschäftlichen Auswirkungen oder eines architektonischen Missbrauchsfalls.

Zu den Behandlungsoptionen gehören eine Änderung des Designs, die Verringerung der Exposition, zusätzliche präventive oder detektive Maßnahmen, der Verzicht auf die Funktion oder die Akzeptanz des verbleibenden Risikos. Lieferantenverträge können Verantwortlichkeiten zuweisen, beseitigen aber keine technischen Fehlerarten.

Ein Restrisiko sollte eine benannte entscheidende Person, eine Begründung, ein Ablaufdatum oder einen Überprüfungsauslöser und gegebenenfalls Betriebsbedingungen haben. Technischer Abschluss und Risikoakzeptanz sind unterschiedliche Entscheidungen. Ein Ticket kann erledigt sein, während ein erhebliches Risiko bestehen bleibt.

Tragen Sie das Modell in Umsetzung und Nachweise

Dokumentieren Sie für jedes wesentliche Szenario Kennung, betroffene Komponenten, Voraussetzungen, Folge, bestehende Abwehrmaßnahmen, Behandlung, verantwortliche Person und Verifizierungsmethode. Verknüpfen Sie den Eintrag mit der Architekturversion und der relevanten Umsetzungsarbeit, damit Prüfende erkennen, welches Design bewertet wurde.

Übersetzen Sie Behandlungen in testbare Akzeptanzkriterien. „Zugriffskontrolle verbessern“ ist vage. „Mandant A kann den Export von Mandant B über keinen unterstützten Endpunkt anfordern, abfragen, abbrechen oder herunterladen“ beschreibt ein Verhalten, das die Entwicklung verifizieren kann.

Verwenden Sie Nachweise, die zur Aussage passen:

• Code-Reviews können zeigen, wo Autorisierung durchgesetzt wird.
• Konfigurationsprüfungen können Dienstberechtigungen und die Exposition von Speichern zeigen.
• Negative Integrationstests können mandantenübergreifende Grenzen und Berechtigungsgrenzen prüfen.
• Last- und Fault-Injection-Tests können Verfügbarkeit und Fehlerverhalten untersuchen.
• Gezielte Penetrationstests können Angriffswege untersuchen, die eine unabhängige Erkundung erfordern.

Kein einzelnes Artefakt beweist das gesamte Modell. Ein Screenshot einer Einstellung beweist nicht, dass jeder Worker sie verwendet, und ein bestandener Test belegt keinen ungetesteten Pfad. Dokumentieren Sie Testumgebung, Umfang, Ergebnisse und Grenzen.

Threat Modeling ergänzt sichere Programmierung, die Bewertung von Abhängigkeiten, Schwachstellenscans und Penetrationstests. Sein besonderer Beitrag ist architektonisches Denken: Es kann eine gefährliche Verteilung von Befugnissen aufdecken, auch wenn einzelne Komponenten keine bekannte Schwachstelle haben.

Ordnen Sie Werkzeuge und Automatisierung dem Modell unter

Ein gemeinsames Diagramm und ein strukturiertes Register können eine fokussierte erste Überprüfung unterstützen. Spezialisierte Werkzeuge werden nützlich, wenn Teams wiederverwendbare Komponentenbibliotheken, einheitliche Kennungen, Zusammenarbeit und verlässliche Verknüpfungen zwischen Bedrohungen und Umsetzungsaufzeichnungen brauchen.

Prüfen Sie, ob ein Werkzeug Vertrauensgrenzen, eigene Szenarien, Versionshistorie, exportierbare Einträge, Verantwortlichkeiten und Verweise auf Nachweise unterstützt. Automatisch erzeugte Bedrohungen sind Denkanstöße zur Prüfung, keine bestätigten Feststellungen. Lange Listen ohne Kontext können die wenigen wichtigen Entscheidungen verdecken.

KI-Unterstützung kann Szenariobeschreibungen entwerfen, fehlende Wege vorschlagen oder Änderungen mit einem früheren Modell vergleichen. Menschliche Prüfende müssen dennoch Architektur, Durchführbarkeit, Abdeckung der Gegenmaßnahmen und Restrisiko validieren. Halten Sie vertrauliche Diagramme und Zugangsdaten aus nicht freigegebenen Diensten heraus. Die Erzeugung eines Bedrohungsmodells ist zudem etwas anderes als Erkennung zur Laufzeit; ein Modell zu erstellen begründet weder kontinuierliche Überwachung noch automatisierte Behebung.

Überprüfen Sie das Modell, wenn sich Architektur oder Annahmen ändern

Aktualisieren Sie das Modell bei neuen Integrationen, Änderungen der Authentisierung, privilegierten Aktionen, Datenkategorien, Netzwerkexposition und größeren Änderungen an Abhängigkeiten. Auch ein Vorfall oder ein unerwartetes Testergebnis kann eine frühere Annahme entkräften.

Unterschiedliche Systeme erfordern unterschiedliche Schwerpunkte. Cloud-Anwendungen erfordern Aufmerksamkeit für Identitätsberechtigungen und den Zugriff auf die Management-Ebene. Mobile Clients sollten als vom Angreifer kontrollierte Umgebungen behandelt werden, nicht als vertrauenswürdige Durchsetzungspunkte. Vernetzte Geräte bringen physischen Zugriff, Integrität von Updates, Wiederherstellung und möglicherweise Folgen für die funktionale Sicherheit mit sich. KI-gestützte Funktionen fügen nicht vertrauenswürdige Inhalte und Grenzen der Werkzeugnutzung hinzu; die Autorisierung muss Aktionen unabhängig von der Modellausgabe beschränken.

Messen Sie, ob wichtige Flüsse aktuelle Modelle haben, ob Behandlungen mit hoher Priorität Verifizierungsnachweise haben, ob Annahmen ungeklärt bleiben und ob akzeptierte Risiken überfällige Überprüfungen haben. Wer nur Bedrohungen zählt, belohnt Menge statt nützlicher Analyse. Bitten Sie regelmäßig eine unabhängige prüfende Person, ein kritisches Szenario und seine Nachweise zu hinterfragen.

Halten Sie die erste Überprüfung klein genug, um sie abzuschließen

Secani kann den Ablauf rund um diese Entscheidungen bewahren, indem es relevante Systeme und Abhängigkeiten modelliert, Verantwortliche und prüfende Personen zuweist und Nachweise mit Anforderungen, Maßnahmen und Entscheidungen verbindet. Ungeklärte Annahmen werden zu Aufgaben; Quellmaterial und menschliche Freigaben bleiben mit der Überprüfung verknüpft. KI-gestützte Vorschläge sollten vor der Freigabe geprüft werden.

Beginnen Sie mit einem kritischen Datenfluss. Verfolgen Sie seine Befugnisse durchgängig, ermitteln Sie eine Handvoll plausibler Szenarien und schließen Sie mit verantworteten Behandlungen und ausdrücklichen Verifizierungskriterien ab. Planen Sie die nächste Überprüfung entlang der Architekturänderungen, die diese Entscheidungen entkräften könnten.