Ein Team will eine neue Bezahlfunktion bauen. Wann und wie sollte die Bedrohungsmodellierung stattfinden?
Kurzantwort
Bedrohungsmodellierung ist in der Designphase am günstigsten und wirksamsten, bevor Code Entscheidungen festzurrt: gehe die Datenflüsse durch, zähle Bedrohungen mit einem Rahmenwerk wie STRIDE auf, baue Gegenmaßnahmen ein und überarbeite sie, während sich das Design entwickelt. Sie erst nach einem Vorfall oder beim jährlichen Pentest zu machen, findet Probleme, wenn sie teuer zu beheben und bereits exponiert sind. Und sich auf „sorgfältige Entwickler" zu verlassen ist Hoffnung, keine wiederholbare, prüfbare Kontrolle.
Eine Bezahlfunktion verarbeitet Geld und sensible Daten — genau der Systemtyp, bei dem Sicherheitsdenken in der Designphase am meisten bringt. Die Frage prüft, ob der Kandidat versteht, wann Sicherheitsarbeit günstig und wirksam ist gegenüber teuer und reaktiv.
Warum Bedrohungsmodellierung in der Designphase gewinnt
Bedrohungsmodellierung ist eine strukturierte Art, vor dem Bauen zu fragen: Was kann schiefgehen, und was tun wir dagegen? In der Designphase ist die Architektur noch flüssig — du kannst eine Vertrauensgrenze verschieben, eine Kontrolle hinzufügen oder eine riskante Abhängigkeit fallen lassen, zum Preis einer Diagrammänderung, nicht eines Refactorings ausgelieferten Codes.
Ein praktischer Ablauf:
- Diagrammiere die Datenflüsse der Bezahlfunktion und markiere die Vertrauensgrenzen (Browser → API → Zahlungsdienstleister → Datenbank).
- Zähle Bedrohungen mit einem Rahmenwerk wie STRIDE auf — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — an jeder Grenze.
- Definiere Gegenmaßnahmen (Authentifizierung/Autorisierung, Eingabevalidierung, Idempotenz-Schlüssel, Tokenisierung, Logging) und verfolge sie als Anforderungen.
- Überarbeite sie bei jeder Designänderung — es ist eine lebendige Tätigkeit, kein Einmalakt.
Warum die falschen Antworten falsch sind
„Nach dem Start, nur wenn es einen Vorfall gibt" ist das teuerstmögliche Timing: Du zahlst mit Sicherheitsverletzungen, Kundenschaden und Notfall-Nacharbeit. „Nur während des jährlichen Pentests" findet Probleme spät, eng und nach dem Ausliefern — ein Pentest validiert ein Design, er ersetzt nicht sicheres Entwerfen. „Unnötig, wenn die Entwickler sorgfältig sind" verwechselt individuelle Sorgfalt mit einem Prozess; Sorgfalt ist nicht wiederholbar, nicht prüfbar, nicht resistent gegen Personalwechsel und bietet keine systematische Abdeckung der Bedrohungskategorien.
Worauf der Interviewer achtet
Er will Shift-Left-Instinkt: Sicherheitsdenken im Design verankert, eine benannte Methodik, konkrete Vertrauensgrenzen und Gegenmaßnahmen und die Reife, das Bedrohungsmodell als lebendiges Artefakt zu behandeln, das sich mit dem System entwickelt — kein Häkchen am Ende.
Wahrscheinliche Anschlussfragen
- Führe STRIDE angewandt auf einen Bezahlfluss durch — nenne eine Bedrohung pro Kategorie.
- Welche Artefakte (Datenflussdiagramm, Vertrauensgrenzen) brauchst du, bevor du Bedrohungen modellieren kannst?
- Wie hältst du ein Bedrohungsmodell lebendig, statt es zu einem einmaligen, vergammelnden Dokument werden zu lassen?