<EbeneX/>
Sicherheit Architektur · Updated 3. Juli 2026

Threat Modeling

Definition

Ein strukturierter Prozess zur Identifikation von Sicherheitsbedrohungen in Systemen – bevor Angreifer sie finden.

Fortgeschritten 3 Min. Lesezeit EN: Threat Modeling

Einfach erklärt

Threat Modeling identifiziert systematisch, was schiefgehen kann – bevor es passiert.

STRIDE Framework:

BedrohungBeschreibungBeispiel
SpoofingIdentität vortäuschenGefälschte Login-Seite
TamperingDaten manipulierenSQL Injection
RepudiationAktionen abstreitenFehlende Audit Logs
Info DisclosureDaten leakenAPI gibt zu viel zurück
Denial of ServiceSystem lahmlegenDDoS-Angriff
ElevationRechte erschleichenAdmin-Zugang erlangen

Technischer Deep Dive

Prozess

1. Scope definieren
   └── Was modellieren wir?

2. Diagramm erstellen
   └── Datenflüsse, Trust Boundaries

3. Bedrohungen identifizieren
   └── STRIDE pro Komponente

4. Risiken bewerten
   └── Wahrscheinlichkeit × Impact

5. Mitigationen planen
   └── Gegenmaßnahmen definieren

Beispiel: ML-API

Bedrohungen für ML-Inference-API:

1. Spoofing: Gefälschte API-Keys
   → Mitigation: JWT mit kurzer Laufzeit

2. Tampering: Manipulierte Inputs
   → Mitigation: Input Validation

3. Info Disclosure: Model Extraction
   → Mitigation: Rate Limiting, Output-Rounding

4. DoS: Teure Inference-Requests
   → Mitigation: Request-Limits, Timeouts

Weitere Methoden neben STRIDE

STRIDE ist der bekannteste, aber nicht der einzige Ansatz:

MethodeFokusGeeignet für
STRIDETechnische BedrohungskategorienSysteme und Komponenten
PASTARisiko- und Business-orientiert, siebenstufigAngriffssimulation mit Geschäftsbezug
LINDDUNPrivacy-Bedrohungen (Linking, Identifying …)Datenschutz-Analysen
Attack TreesAngriffsziele hierarchisch zerlegenEinzelne, kritische Angriffsszenarien

Für den Einstieg reichen oft die vier Kernfragen des Threat-Modeling-Manifests: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir gute Arbeit geleistet?

Threat Modeling für LLM-Anwendungen

KI-Systeme erweitern die klassische Angriffsfläche um eigene Bedrohungsklassen. Wer eine LLM-Anwendung modelliert, sollte mindestens diese Vektoren durchspielen:

  • Prompt Injection: Manipulierte Eingaben oder Inhalte aus externen Quellen (Webseiten, Dokumente, E-Mails) überschreiben die Anweisungen des Systems – die wichtigste neue Trust Boundary verläuft zwischen vertrauenswürdigem System-Prompt und nicht vertrauenswürdigem Kontext.
  • Datenabfluss über Ausgaben: Das Modell gibt vertrauliche Inhalte aus dem Kontext preis – etwa RAG-Dokumente, auf die der Nutzer keinen Zugriff haben dürfte.
  • Exzessive Agenten-Rechte: Ein Agent mit Tool-Zugriff wird durch Injection zu unerwünschten Aktionen verleitet. Mitigation: Least Privilege, menschliche Freigabe für kritische Operationen, Sandboxing.
  • Poisoning der Wissensbasis: Manipulierte Dokumente in RAG-Speichern oder Fine-Tuning-Daten verändern das Systemverhalten.
  • Kosten-DoS: Absichtlich teure Anfragen (lange Kontexte, viele Aufrufe) treiben die Inferenzkosten – Rate Limiting und Budgets sind hier Sicherheitskontrollen.

Als Referenz für KI-spezifische Bedrohungen haben sich unter anderem die OWASP-Übersichten zu LLM-Risiken sowie MITRE ATLAS etabliert.

Typische Stolperfallen

FehlerFolgeBesser
Einmalig statt kontinuierlichModell veraltet mit jeder ArchitekturänderungBei relevanten Änderungen aktualisieren
Perfektion vor NutzenAnalyse-Lähmung, nie fertigKlein anfangen, iterieren
Nur Security-Team beteiligtFachwissen über das System fehltEntwickler und Product einbeziehen
Bedrohungen ohne OwnerFindings versandenMitigationen als Tickets mit Verantwortlichen
Trust Boundaries unklarKritische Übergänge werden übersehenDatenflussdiagramm mit expliziten Grenzen

Abgrenzung zu verwandten Begriffen

  • Risk Assessment bewertet Risiken oft auf Organisationsebene – Threat Modeling arbeitet konkret am System- und Architekturdesign.
  • Penetration Testing prüft ein fertiges System empirisch auf Schwachstellen; Threat Modeling findet Designfehler, bevor sie gebaut werden. Ideal ist die Kombination: Das Threat Model liefert Testhypothesen für den Pentest.
  • Security Review ist meist eine punktuelle Prüfung von Code oder Konfiguration – Threat Modeling betrachtet das Gesamtsystem inklusive Datenflüssen und Vertrauensgrenzen.

Threat Modeling ist wie ein Einbrecher-Test für dein Haus: Du denkst wie ein Einbrecher, findest Schwachstellen und sicherst sie – bevor ein echter Einbrecher kommt.

Identifiziere Assets, Angriffsvektoren, Bedrohungen

STRIDE: Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Elevation

Früh im Entwicklungsprozess, nicht erst am Ende

Neue Systeme

Sicherheit von Anfang an einbauen

API-Design

Angriffsflächen minimieren

ML-Systeme

Model Poisoning, Data Leakage identifizieren

Wann sollte Threat Modeling stattfinden?

Früh! Am besten in der Design-Phase. Änderungen sind dann noch günstig. Aber auch nachträglich für bestehende Systeme sinnvoll.

Wer sollte teilnehmen?

Entwickler, Security-Experten, Architekten, Product Owner. Verschiedene Perspektiven finden mehr Bedrohungen.

Dein persönliches Share-Bild für Instagram – 1080×1080px, bereit zum Posten.