Datenflussdiagramme für die Bedrohungsmodellierung: STRIDE Schritt für Schritt

Jede Methode der Bedrohungsmodellierung beginnt mit derselben Frage: Woran arbeiten wir? Die übliche Antwort ist ein Datenflussdiagramm. Es ist ein einfaches Bild mit fünf Arten von Elementen, und die Stunde, die du hineinsteckst, ist die nützlichste vor einem Security-Review, denn die meisten Bedrohungen liegen dort, wo Daten von einer Vertrauensstufe in eine andere wechseln.

Dieser Guide zeigt, wie du ein Datenflussdiagramm (DFD) für die Bedrohungsmodellierung zeichnest, wo du Vertrauensgrenzen setzt und wie du das Diagramm mit STRIDE durchgehst. Als Beispiel dient ein Feature, das fast jedes Produkt hat: Nutzer laden ein Profilfoto hoch.

Die vier Fragen

Ein praxistaugliches Bedrohungsmodell beantwortet vier Fragen, die Adam Shostack und das Threat Modeling Manifesto bekannt gemacht haben:

1. Woran arbeiten wir?
2. Was kann schiefgehen?
3. Was unternehmen wir dagegen?
4. Haben wir unsere Sache gut genug gemacht?

Das Datenflussdiagramm beantwortet die erste. STRIDE hilft bei der zweiten. Die Notizen und Tickets, die du an das Diagramm hängst, beantworten die dritte, und ein Review einige Wochen später beantwortet die vierte.

Die Elemente eines Datenflussdiagramms

Element	Was es ist	Übliche Form
Externe Entität	Eine Person oder ein System außerhalb deiner Kontrolle: ein Nutzer, eine Partner-API	Rechteck
Prozess	Code, den du ausführst und der Daten umwandelt oder bewegt	Kreis oder abgerundete Form
Datenspeicher	Wo Daten ruhen: eine Datenbank, ein Bucket, eine Queue, ein Log	Zwei parallele Linien oder ein Zylinder
Datenfluss	Daten, die sich zwischen zwei Elementen bewegen	Pfeil, beschriftet mit den Daten
Vertrauensgrenze	Wo sich das Vertrauensniveau ändert	Gestrichelte Linie oder eine Zone um Elemente

Zwei Regeln machen ein DFD für die Sicherheit nützlich. Beschrifte jeden Fluss mit den Daten, die er trägt, nicht nur mit dem Protokoll: photo + session token sagt einem Reviewer weit mehr als HTTPS. Und verbinde nie zwei Datenspeicher oder zwei externe Entitäten direkt: Daten bewegen sich nur über einen Prozess, und genau dort kannst du sie prüfen.

Das Beispiel: Profilfoto-Upload

Nutzer laden im Browser ein Profilfoto hoch. Die Web-API prüft ihre Session und speichert die Rohdatei in einem privaten Bucket. Ein Upload-Prozessor holt sie ab, schickt die Bytes an die Malware-Scan-API eines Drittanbieters, kodiert das Bild neu, entfernt seine Metadaten, schreibt die bereinigte Version zurück in den Bucket und trägt die Foto-URL in die Nutzerdatenbank ein.

Es gibt vier Vertrauenszonen: das Internet, unsere Anwendungsschicht, unsere Datenschicht und den Scanner des Drittanbieters. Als DFD gezeichnet:

Zähl die Flüsse, die eine Zonengrenze überqueren: Browser zur API, API zum Bucket, Bucket zum Prozessor und zurück, Prozessor zum Scanner und zurück, Prozessor zur Datenbank. Genau dort lohnt es sich, Zeit zu investieren.

Das Diagramm mit STRIDE durchgehen

STRIDE benennt sechs Arten von Bedrohungen. Microsofts Ansatz „STRIDE per Element“ prüft jedes Element nur auf die Bedrohungen, die für seinen Typ gelten:

Elementtyp	S	T	R	I	D	E
Externe Entität	✓		✓
Prozess	✓	✓	✓	✓	✓	✓
Datenspeicher		✓	✓ (Logs)	✓	✓
Datenfluss		✓		✓	✓

Die sechs Buchstaben stehen für Identitätsfälschung (Spoofing), Manipulation (Tampering), Abstreitbarkeit (Repudiation), Offenlegung von Informationen (Information disclosure), Dienstverweigerung (Denial of service) und Rechteausweitung (Elevation of privilege). Wenn du das Upload-Feature Element für Element durchgehst, entsteht eine Liste wie diese:

• Identitätsfälschung (Browser). Mit einem gestohlenen oder gefälschten Session-Token wird ein Foto im Namen einer anderen Person hochgeladen. Gegenmaßnahme: Prüfe das Token bei jedem Request, halte Sessions kurzlebig und binde den Objektschlüssel an die ID des authentifizierten Nutzers, nie an einen Wert aus dem Request.
• Manipulation (Bucket zum Prozessor). Eine Datei namens photo.jpg ist in Wahrheit etwas völlig anderes. Gegenmaßnahme: Prüfe das tatsächliche Format der Datei, nicht ihren Namen oder deklarierten Typ, und kodiere jedes Bild neu, bevor es irgendjemand anderes sieht.
• Abstreitbarkeit (API). Ein Nutzer bestreitet, ein anstößiges Bild hochgeladen zu haben, und nichts beweist das Gegenteil. Gegenmaßnahme: Logge bei jedem Upload Nutzer-ID, Objektschlüssel, Zeitpunkt und Client-Adresse.
• Offenlegung von Informationen (Bucket). Der Bucket lässt sich öffentlich auflisten, oder Fotos behalten ihre GPS-Koordinaten in den EXIF-Metadaten. Gegenmaßnahme: ein privater Bucket mit kurzlebigen signierten URLs und Metadaten, die beim Neukodieren entfernt werden.
• Dienstverweigerung (API und Prozessor). Riesige Dateien oder Bilder, die beim Dekomprimieren auf enorme Größen anwachsen, erschöpfen den Speicher. Gegenmaßnahme: Limits für Dateigröße und Pixelzahl sowie Timeouts im Prozessor.
• Rechteausweitung (Prozessor). Eine präparierte Datei nutzt einen Bug in der Bildbibliothek aus und führt Code mit den Rechten des Prozessors aus. Gegenmaßnahme: Betreibe den Prozessor in einer Sandbox, in der er auf nichts außer seinem Bucket-Präfix und seiner einen Tabelle zugreifen kann.

Schreib die Bedrohungen als kurze, nummerierte Zeilen in eine Notiz neben den Elementen, die sie betreffen, und verknüpfe jede mit dem Ticket, das den Fix verfolgt. Dann dient das Diagramm zugleich als Zusammenfassung des Reviews.

Regeln für Diagramme in der Bedrohungsmodellierung

• Zeichne das Feature, nicht das Unternehmen. Ein DFD pro Feature oder pro Service. In einem Diagramm von allem ist kein Platz für die Details, auf die es ankommt.
• Zeig, wo die Authentifizierung stattfindet. Markiere bei jedem Fluss, der eine Grenze überquert, den Prozess, der die Identität prüft.
• Nimm die Pfade auf, die niemand in einer Demo zeigt. Admin-Tools, Supportzugriffe, Batch-Jobs und Backups überqueren ebenfalls Grenzen.
• Bleib auf einer Detailebene. Ein DFD auf Kontextebene zeigt das System als einen einzigen Prozess; ein DFD der Ebene 1 zerlegt es in seine Hauptprozesse. Wähl pro Diagramm eine davon.
• Versioniere es mit dem Feature. Wenn sich das Design ändert, ändern sich die Bedrohungen. Aktualisiere das Diagramm im selben Pull Request wie das Designdokument.

Spezialisierte Tools oder ein gemeinsamer Canvas

Kostenlose Tools wie OWASP Threat Dragon und das Microsoft Threat Modeling Tool sind für genau diese Aufgabe gebaut und können für jedes Element Bedrohungen vorschlagen. Sie funktionieren gut, wenn ein Security-Team den Prozess verantwortet.

Ein gemeinsamer Canvas funktioniert besser, wenn die Leute, die das Feature bauen, das Diagramm während des Designs zusammen zeichnen: Das DFD liegt neben den Architekturdiagrammen, alle bearbeiten es live, und die Notizen bleiben an den Elementen. So oder so ist das Gespräch rund um das Diagramm der wertvolle Teil.

In Archboard umsetzen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge für jede Vertrauenszone einen Rahmen aus dem Basis-Pack hinzu und benenne ihn nach der Zone, zum Beispiel Trust zone: app tier.
3. Füge externe Entitäten als Kasten-Nodes und Prozesse als Ellipse-Formen aus dem Basis-Pack hinzu, Datenspeicher aus dem Daten-Pack (Objektablage, Postgres).
4. Verbinde die Ports und beschrifte jede Kante mit den Daten, die sie trägt.
5. Füge neben den betroffenen Elementen eine Notiz hinzu, die jede Bedrohung mit ihrem STRIDE-Buchstaben, ihrer Nummer und ihrem Ticket auflistet.

Das Beispiel nutzt 10 Diagramm-Nodes plus drei Notizen mit sieben Bedrohungen und passt damit in den Free-Plan. Für die Netzwerkseite der Sicherheit sieh dir die Vorlage Zero-Trust-Architekturdiagramm an, für die Kartierung personenbezogener Daten den Anwendungsfall DSGVO-Datenlandkarten.

FAQ

Ist ein Datenflussdiagramm dasselbe wie ein Architekturdiagramm? Nein. Ein Architekturdiagramm zeigt Komponenten und wie sie verbunden sind; ein DFD zeigt, wie sich Daten bewegen und wo sich das Vertrauen ändert. Oft haben beide dieselben Boxen, aber das DFD wird für die Sicherheitsfrage gezeichnet.

STRIDE oder eine andere Methode? STRIDE ist ein guter Standard für Software-Features. LINDDUN konzentriert sich auf Datenschutzbedrohungen, und PASTA ist ein risikozentrierter Prozess für größere Vorhaben. Das Diagramm ist für alle derselbe Ausgangspunkt.

Wer sollte dabei sein? Die Engineers, die das Feature bauen, jemand, der es betreiben wird, und ein Security-Engineer, falls ihr einen habt. Wer den Code kennt, findet die Bedrohungen; der Security-Engineer sorgt dafür, dass beim Durchgang nichts beschönigt wird.

Wie lange sollte das dauern? Für ein Feature wie den Foto-Upload ist eine Stunde typisch: 15 Minuten zum Zeichnen, 30 für den Durchgang mit STRIDE, 15, um sich auf Fixes und Verantwortliche zu einigen.

Wie oft sollten wir das Modell aktualisieren? Immer wenn ein Fluss eine neue Grenze überquert, ein neuer Datenspeicher hinzukommt oder das Feature ändert, wer was tun darf.

Kostenlos starten — ein Seat, keine Kreditkarte.