OWASP
Die Open Web Application Security Project Foundation – definiert die wichtigsten Web-Sicherheitsrisiken und Best Practices für sichere Entwicklung.
Ein strukturierter Prozess zur Identifikation von Sicherheitsbedrohungen in Systemen – bevor Angreifer sie finden.
Threat Modeling identifiziert systematisch, was schiefgehen kann – bevor es passiert.
STRIDE Framework:
| Bedrohung | Beschreibung | Beispiel |
|---|---|---|
| Spoofing | Identität vortäuschen | Gefälschte Login-Seite |
| Tampering | Daten manipulieren | SQL Injection |
| Repudiation | Aktionen abstreiten | Fehlende Audit Logs |
| Info Disclosure | Daten leaken | API gibt zu viel zurück |
| Denial of Service | System lahmlegen | DDoS-Angriff |
| Elevation | Rechte erschleichen | Admin-Zugang erlangen |
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
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
STRIDE ist der bekannteste, aber nicht der einzige Ansatz:
| Methode | Fokus | Geeignet für |
|---|---|---|
| STRIDE | Technische Bedrohungskategorien | Systeme und Komponenten |
| PASTA | Risiko- und Business-orientiert, siebenstufig | Angriffssimulation mit Geschäftsbezug |
| LINDDUN | Privacy-Bedrohungen (Linking, Identifying …) | Datenschutz-Analysen |
| Attack Trees | Angriffsziele hierarchisch zerlegen | Einzelne, 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?
KI-Systeme erweitern die klassische Angriffsfläche um eigene Bedrohungsklassen. Wer eine LLM-Anwendung modelliert, sollte mindestens diese Vektoren durchspielen:
Als Referenz für KI-spezifische Bedrohungen haben sich unter anderem die OWASP-Übersichten zu LLM-Risiken sowie MITRE ATLAS etabliert.
| Fehler | Folge | Besser |
|---|---|---|
| Einmalig statt kontinuierlich | Modell veraltet mit jeder Architekturänderung | Bei relevanten Änderungen aktualisieren |
| Perfektion vor Nutzen | Analyse-Lähmung, nie fertig | Klein anfangen, iterieren |
| Nur Security-Team beteiligt | Fachwissen über das System fehlt | Entwickler und Product einbeziehen |
| Bedrohungen ohne Owner | Findings versanden | Mitigationen als Tickets mit Verantwortlichen |
| Trust Boundaries unklar | Kritische Übergänge werden übersehen | Datenflussdiagramm mit expliziten Grenzen |
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
Früh! Am besten in der Design-Phase. Änderungen sind dann noch günstig. Aber auch nachträglich für bestehende Systeme sinnvoll.
Entwickler, Security-Experten, Architekten, Product Owner. Verschiedene Perspektiven finden mehr Bedrohungen.