Ein Bedrohungsmodell – Threat Model – ist eine strukturierte Analyse eines Systems aus der Perspektive eines potenziellen Angreifers: Wer könnte das System angreifen? Mit welchen Zielen? Über welche Angriffsvektoren? Welche Komponenten oder Daten wären das Ziel? Bedrohungsmodellierung ist proaktive Sicherheitsarbeit: Sie identifiziert Bedrohungen im Designprozess eines Systems – nicht erst nachdem das System gebaut ist. Es ist deutlich günstiger, eine Schwachstelle im Architekturentwurf zu finden als nach dem Deployment.
Für Automatisierungsinfrastrukturen ist Bedrohungsmodellierung besonders wertvoll bei neuen Integrationen: Wenn ein neuer API-Endpunkt, eine neue Datenquelle oder eine neue Systemanbindung geplant wird, deckt eine Bedrohungsanalyse systematisch auf, welche neuen Angriffsvektoren dadurch entstehen – und wie sie abzusichern sind, bevor der erste Code geschrieben ist.
STRIDE – das gängigste Bedrohungsmodell-Framework
S – Spoofing
Identitätsvortäuschung: Angreifer gibt sich als legitimer Nutzer oder System aus. Gegenmaßnahme: starke Authentifizierung, MFA, Zertifikate.
T – Tampering
Datenmanipulation: Angreifer verändert Daten in Transit oder at Rest. Gegenmaßnahme: Verschlüsselung, Integritätsprüfung, Signaturen.
R – Repudiation
Abstreitbarkeit: Nutzer bestreitet eine ausgeführte Aktion. Gegenmaßnahme: Audit-Trails, digitale Signaturen, revisionssichere Protokollierung.
I – Information Disclosure
Datenleck: Unbefugte Offenlegung vertraulicher Daten. Gegenmaßnahme: Verschlüsselung, Zugriffskontrollen, Least Privilege.
D – Denial of Service
Überlastung: System wird für legitime Nutzer unzugänglich. Gegenmaßnahme: Rate Limiting, Redundanz, DDoS-Schutz, Queue-Pufferung.
E – Elevation of Privilege
Rechteausweitung: Angreifer erlangt höhere Zugriffsrechte als erlaubt. Gegenmaßnahme: Least Privilege, Zugriffskontrollen, Monitoring.
Praxisbeispiel
Ein Automationsdienstleister plant eine neue Integration: ein Webhook-Endpunkt, der Bestellungen aus einem externen Webshop empfängt und in das ERP schreibt. STRIDE-Analyse vor der Implementierung: Spoofing – was passiert, wenn jemand gefälschte Bestelldaten an den Webhook sendet? Gegenmaßnahme: HMAC-Signaturverifikation jeder Anfrage. Tampering – kann die Bestellsumme unterwegs verändert werden? Gegenmaßnahme: TLS + Signatur. Repudiation – wie beweise ich, dass eine bestimmte Bestellung empfangen wurde? Gegenmaßnahme: Anfragen mit Timestamp und Payload-Hash loggen. Information Disclosure – enthält die Webhook-URL sensible Parameter? Nein, Authentifizierung via Header-Secret. DoS – was passiert bei 10.000 Anfragen pro Sekunde? Gegenmaßnahme: Rate Limiting + Queue-Pufferung. Elevation of Privilege – kann der Webhook-Endpunkt für mehr als Bestellungsannahme missbraucht werden? Gegenmaßnahme: Endpunkt akzeptiert exakt ein Schema, alles andere wird abgelehnt. Ergebnis: 6 identifizierte Bedrohungen, alle mit konkreten Gegenmaßnahmen adressiert – vor der ersten Zeile Code.
