Threat Modeling: Schwachstellen erkennen, bevor sie schmerzen

Threat Modeling ist eine strukturierte Methode, um systematisch zu erkennen, wie Angreifer eine Anwendung oder einen Prozess kompromittieren könnten – und welche Massnahmen das Risiko wirksam senken. Dabei betrachten wir Assets, Prozesse und Datenflüsse, identifizieren mögliche Schwachstellen und priorisieren die wichtigsten Gegenmassnahmen.

Hinweis: Man liest manchmal „Thread Modeling“. Gemeint ist aber Threat (Bedrohung), nicht Thread (Faden).

Workshop

Unser Threat-Modeling-Workshop besteht aus fünf Teilen – vom Festlegen der zu schützenden Assets bis zu priorisierten Massnahmen. In der Regel dauert er 2 bis 3 Stunden und ist so aufgebaut, dass Teams schnell zu greifbaren Ergebnissen und klaren nächsten Schritten kommen.

Teil 1: Scope & Lösungsdiagramm

Wir legen den Scope fest und visualisieren die Architektur: User, Prozesse, Daten/Speicher, Schnittstellen und Zonen mit unterschiedlichem Trust-Level (z. B. Internet, DMZ, internes Netz, Cloud-Konto). Idealerweise greifen wir dabei auf die bestehende Architekturdokumentation zurück (siehe https://arc42.org/).

Aufgabe fürs TeamFormuliert den Scope in 1–2 Sätzen und zeichnet das Lösungsdiagramm inklusive Datenflüssen und Vertrauensgrenzen.Erwartetes Ergebnis: Ein Diagramm, das genau den Scope abbildet (nicht mehr, nicht weniger).

Tipps:

• Benennt relevante Elemente eindeutig.
• Zieht Trust-Boundary-Linien ein.
• Nummeriert Datenflüsse.

Teil 2: Was muss wirklich geschützt werden?

Auf Basis des Diagramms bestimmen wir die zu schützenden Assets – alles, dessen Vertraulichkeit, Integrität oder Verfügbarkeit geschäftskritisch ist. Das Ergebnis ist eine priorisierte Asset-Liste als Grundlage für die weitere Analyse.

Asset vs. Prozess – kurz erklärt

• Asset: Alles von Wert, das Vertraulichkeit, Integrität oder Verfügbarkeit benötigt – z.B. Kundendaten, Quellcode-Repository, Zahlungs-API, Build-Pipeline.
• Prozess: Eine Abfolge von Tätigkeiten (manuell oder automatisiert), um ein Ziel zu erreichen – z.B. Login-Flow, Datenexport, Onboarding, Incident-Handling.

Aufgabe fürs TeamErstellt eine Asset-Liste eurer Lösung.Erwartetes Ergebnis: Eine priorisierte Liste von Assets, die zwingend abzusichern sind.

Beispiel (Auszug):

• Kundenprofil-Datenbank (personenbezogene Daten)
• Zahlungsabwicklung (umsatzkritisch)
• Admin-Konsole (hohe Rechte)
• CI/CD-Pipeline (Supply-Chain-Risiko)
• Secrets (API-Keys, Tokens)

Teil 3: Bedrohungen identifizieren – mit S.T.R.I.D.E

Hier wird es konkret. Wir arbeiten in kurzen Zeitslots und kreativ: zwei gemischte Gruppen, Diagramm an die Wand, dann Buchstabe für Buchstabe durch S.T.R.I.D.E:

Spoofing (Identitätsvortäuschung)

• Wie kann sich jemand als eine andere Person oder als ein Dienst ausgeben (z. B. durch gestohlene Sessions, Tokens, API-Keys)?
• Wo fehlen starke Identitätsnachweise (MFA, Hardware-Tokens)?
• Können Service-zu-Service-Aufrufe sicher identifiziert werden?
• Gibt es Standard-/Default-Credentials, gemeinsam genutzte Accounts oder schwache Passwortrichtlinien?
• Sind OAuth-Flows korrekt konfiguriert (Redirect-URIs, Scopes)?
• Können Webhooks oder Callbacks gefälscht werden (fehlende Signaturen, Shared Secrets)?

Tampering (Manipulation)

• Wo können Daten auf dem Transport oder in der Datenbank verändert werden (fehlende Integritätsprüfungen, TLS, Signaturen)?
• Ist Eingabevalidierung konsequent serverseitig umgesetzt (Injection, Deserialisierung, XSS)?
• Können Build-/Release-Artefakte oder Dependencies manipuliert werden?
• Sind Konfigurationen und Secrets vor unbefugter Änderung geschützt (Git-Schutzregeln, Secret-Vault)?
• Lassen sich Logs oder Audits nachträglich ändern oder löschen?
• Gibt es Client-seitige Logik, die sicherheitsrelevant ist und leicht umgangen/manipuliert werden kann?

Repudiation (Nicht-Abstreitbarkeit)

• Wo fehlen Nachweise für Aktionen (Audit-Logs, fälschungssichere Zeitstempel, Request-/Trace-IDs)?
• Können Nutzende Transaktionen abstreiten, weil Belege oder Kontext fehlen?
• Sind Logs manipulationssicher gespeichert?
• Wer darf Logs einsehen/löschen, und sind diese Zugriffe selbst auditierbar?
• Ist die Zeit­synchronisation gewährleistet?
• Werden wichtige Entscheidungen (Admin-Aktionen, Finanztransaktionen) zweifach bestätigt oder signiert?

Information Disclosure (Datenabfluss)

• Wo liegen personenbezogene, vertrauliche oder geheime Daten, und wer hat Zugriff?
• Werden Geheimnisse oder PII (Personally Identifiable Information, also personenbezogene Daten) versehentlich geloggt, in Crashdumps, Headers, Metriken oder Traces?
• Geben Fehlerseiten oder Debug-Infos internale Details preis (Stacktraces, SQL, Pfade)?
• Sind Backups, Analytics-Kopien, Staging-Umgebungen genauso geschützt wie Produktion?
• Sind Berechtigungen zu weit gefasst (z. B. Admin-Rollen, Wildcard-Policies, globale DB-Rechte, öffentliche Buckets, „full_access“-Scopes)?
• Können sensible Informationen über Nebenkanäle (Timing, Antwortgrösse, Caching, Metadaten, Header/Fehlercodes) unbeabsichtigt preisgegeben werden?

Denial of Service (Dienstverweigerung)

• Welche Endpunkte/Prozesse sind anfällig für Lastspitzen (fehlendes Rate-Limiting, fehlende Quotas)?
• Gibt es teure Operationen (z. B. komplexe Suchabfragen, grosse Datei-Uploads, Bilder-Konvertierung, LLM-Aufrufe), die leicht triggerbar sind?
• Können Queues, Thread-Pools, DB-Verbindungen erschöpft werden?
• Sind Timeouts, Circuit-Breaker, Caching und Bulkheads richtig eingestellt?
• Wie wirken sich Upstream-Ausfälle oder externe Abhängigkeiten kaskadierend aus?
• Besteht Tenant-Isolation (Noisy-Neighbor), und sind Ressourcenlimits definiert?

Elevation of Privilege (Rechteausweitung)

• Wo kann ein Niedrig-Privileg-Akteur höhere Rechte erlangen (fehlende Autorisierungsprüfungen)?
• Werden Authentisierung und Autorisierung konsequent serverseitig getrennt geprüft?
• Gibt es überprivilegierte Rollen/Tokens/Service-Accounts oder Default-Admin-Zugänge?
• Sind Admin-Workflows (Passwort-Reset, Rollenänderungen) missbrauchssicher?

Zur Inspiration verwenden wir die S.T.R.I.D.E-Karten von ThoughtWorks: https://thoughtworksinc.github.io/sensible-security-conversations/materials/Sensible_Agile_Threat_Modelling_Cards.pdf

Ablauf je Buchstabe (5–10 Minuten):

1. Kurz erklären, worum es geht (Coach oder erfahrene Person).
2. Gruppen sammeln so viele Bedrohungen wie möglich – Quantität vor Qualität.
3. Ergebnisse zeigen und am Diagramm platzieren.
4. Weiter zum nächsten Buchstaben.

Tipp:

• Schreibt den Buchstaben (S, T, R, I, D oder E) auf jede gesammelte Bedrohung.

Teil 4: Priorisieren, damit es wirkt

Nicht alles ist gleich wichtig. Wir markieren jede Bedrohung als Critical / High / Medium / Low und wählen unser Top 5 aus.

Fragen zur Einschätzung:

• Wie hoch ist der Impact auf Vertraulichkeit, Integrität, Verfügbarkeit?
• Wie wahrscheinlich ist die Ausnutzung in der Praxis?
• Wie betriebsrelevant ist das für die kontinuierliche Funktion?
• Welche Kosten (finanziell, Reputation, Compliance) drohen bei Eintritt?

Aufgabe fürs TeamBewertet alle Post-its und bestimmt die Top 5.Erwartetes Ergebnis: Eine klar priorisierte Liste – bereit für die Umsetzung.

Teil 5: Von Post-its zu Massnahmen

Jetzt wird’s operativ:

• Formuliert pro Top-Bedrohung konkrete Massnahmen (z. B. MFA aktivieren, Input-Validierung ergänzen, Rate-Limiting, Secrets in einen Vault, Audit-Logs, Least-Privilege-Rollen).
• Erstellt Tickets mit Akzeptanzkriterien.
• Vereinbart Owner und Fälligkeiten.
• Plant eine Nachkontrolle (z. B. Retest im nächsten Workshop).

Unser Fazit bei Apptiva

Threat Modeling ist kein einmaliges Dossier, sondern eine Team-Routine: kurz, fokussiert, wiederholbar. So entdecken wir Risiken früh, verankern Security im Alltag und investieren Zeit dort, wo sie am meisten Risiko reduziert.

Wenn ihr eure Lösung gemeinsam auf Herz und Nieren prüfen wollt, begleiten wir euch gerne durch einen Threat-Modeling-Workshop – von Asset-Liste über Diagramm bis zu priorisierten Massnahmen.

Dabei könnt ihr auch gleich erleben, wie wir Security in unseren eigenen Produkten verankern: etwa bei injoi, dem digitalen Self-Checkout für Restaurants, mit dem Gäste einfach im Browser bestellen und bezahlen – oder bei Bubble Chat, unserer Lösung für smarte Chat-Erlebnisse. So profitiert ihr doppelt: von praxisnahen Beispielen und einem Workshop, der direkt auf eure Bedürfnisse zugeschnitten ist.