Bedrohungsmodellierung und Risikokontrolle

1) Grundsätze

1. Architectural First. Wir beginnen mit Kontexten, Vertrauensgrenzen und Datenflüssen.
2. Risk ≈ Likelihood × Impact. Wir messen, nicht fühlen.
3. Defense in Depth. Kontrollen auf jeder Ebene: Code → Protokoll → Plattform → Menschen.
4. Shift Left/Right. Frühe Tore in PR + Überwachung und Reaktion in der Produktion.
5. Privacy by Design. Wir simulieren nicht nur Sicherheitsbedrohungen, sondern auch Datenschutzrisiken.
6. Automate Where Possible. Politiker als Code, Autokontrollen, „rote Linien“.

2) Bestandsaufnahme: Vermögenswerte, Subjekte, Vertrauensgrenzen

Assets: Daten (PII, Finanzen, Geheimnisse), Rechenressourcen, Schlüssel, Zugriffe, Geschäftsprozesse.
Subjekte: Nutzer, Dienste, Admins, Partner, externe Anbieter.
Grenzen des Vertrauens: Benutzer ↔ Front, Front ↔ API-Gateway, Dienste ↔ DB/Caches/Queues, Regionen/Clouds.
Angriffsfläche: Eingangspunkte (API, Webhooks, UI, Netzwerke, CI/CD, Supply Chain).

mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end

3) Bedrohungsrahmen

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (Prozess): Von Geschäftszielen und Bedrohungsakteuren → technische Details → Testszenarien.

4) Risikobewertung

DREAD/OWASP Risk Rating oder CVSS für Schwachstellen.
Wahrscheinlichkeit (L): Motiv/Fähigkeiten des Angreifers, Komplexität, Belichtung der Oberfläche.
Auswirkungen (I): Finanzen, Jurriken, Ausfallzeiten, PD-Lecks.
Risiko (R = L × I) → Priorisierung und Tritment: Avoid/Reduce/Transfer/Accept.

Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

Risikoregister (Minimum der Felder): „id, scenario, STRIDE, asset, L, I, R, owners, controls, status, review date“.

5) Kontrollen: Prevent/Detect/Respond

• Authentifizierung/Autorisierung: OIDC/OAuth2, PoLP, RBAC/ABAC, Kurzzeit-Service-Credits.
• Geheimnisse/Schlüssel: KMS/HSM, Rotation, Nicht-Wissen-Prinzip, FPE/Feldverschlüsselung.
• Sichere Protokolle: TLS1. 2 +, mTLS, Webhook-Signaturen, Idempotenz und Anti-Replay.
• Validierung/Sanierung: Schemata (JSON Schema/Proto), Grenzen, Normalisierung.
• Isolation: Netzwerkrichtlinien, Segmentierung, Sandbox, Namespaces, Bulkheads.

• Audit-Protokolle (nicht widerruflich), Korrelation in SIEM, Warnungen vor Anomalien.
• Signatur- und Integritätsüberwachung (Export von Artefakt-Hashes, Attestation).
• Honeytokens/Kanarienvögel für Frühaufsteher-Schlüssellecks.

• Runbook IR: Klassifizierung, Isolierung, Schlüsselrückruf, Warnungen, Forensik.
• Automatischer Kill-Switch/Feature-Flag, „schwarze Listen“ von Token.
• Benachrichtigung von Benutzern/Aufsichtsbehörden bei PD-Vorfällen.

6) SDL und Sicherheitsgates

In Idee/Design: Bedrohungsmodell (RFC/ADR), Checkliste der Kontrollen.
In Entwicklung: SAST/secret-scan, dependent scans (SCA), Abhängigkeitsrichtlinie.
In der Montage: SBOM, Signatur von Artefakten, Vulnerability Policy (CVSS-Schwellenwerte).
Im Deploy: OPA/Kyverno - IaC/Manifest Policy (securityContext, Netzwerkrichtlinien, Secret Break).
In der Produktion: IDS/WAF, Anomaly Detection, Canary-Checks, Chaos-Security (z.B. abgelaufenes Zertifikat).

rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}

7) Supply Chain und Vertrauen in Artefakte

SBOM für jedes Image/Paket; Abhängigkeitsaktualisierungen - durch Bot/Richtlinie.
SLSA/Provenance: reproduzierbare Assemblies, Signaturen, Attestationen.
Container: minimale Bilder, rootless, drop capabilities, read-only FS.
IaC-Scans: Terraform/Helm - Richtlinien für Verschlüsselung, offene Ports, Netzwerkregeln.

8) Datenschutz und Compliance

LINDDUN-Karte von Bedrohungen der Privatsphäre, Datenminimierung, Pseudonymisierung/Anonymisierung.
Aufbewahrungsrichtlinien: TTL/Retention, „Recht auf Löschung“, PD Access Audit.
Lokalisierung: Geo-Restriktionen, „die Daten bleiben in der Region“.
Transparenz: Verarbeitungsprotokolle, Benachrichtigungen und Einwilligungen.

9) Wolken und Perimeter

Zero Trust: Authentifizierung jeder Anfrage, mTLS/OPA zwischen den Diensten.
Segmentierung: VPC/Subnets/SG, private Endpunkte, Egress-Steuerung.
Schlüssel/Geheimnisse: KMS, Rotation, kurze Credits im CI (OIDC-Verband).
Reserve/DR: verschlüsselte Backups, Schlüssel separat, Wiederherstellungsproben.

10) Rote/violette Befehle und Tabletop-Übungen

Red Team: Testen von Bedrohungshypothesen, Social Engineering, Ausnutzen von Ketten.
Purple Team: Gemeinsames Debuggen von Detects/Alerts, Verbesserung der IR-Playbooks.
Tabletop: Skripte „Zertifikat abgelaufen“, „Schlüsselleck“, „Supply-Chain-Kompromittierung“. Das Ergebnis sind aktualisierte Kontrollen und Metriken.

11) Reifegradmetriken und Management

Abdeckung:% der Dienste mit aktuellem Bedrohungsmodell und DFD.
MTTD/MTTR-Sicherheit, Anteil der Vorfälle, die von den Kontrollen erfasst wurden.
Policy Pass-Rate in CI, Zeit zum Schließen von Schwachstellen nach Kritikalität.
Datenschutz:% Dataset mit TTL/ILM, Anteil Zugriffe mit Begründung.
Prüfung: Regelmäßigkeit der Überprüfung des Risikoregisters (vierteljährlich).

12) Artefaktmuster

12. 1 Risikokarte (Beispiel)

Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High  Impact: High  Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts  Статус: Reduce (в работе)
Дата пересмотра: 2025-12-01

12. 2 Design-Checkliste

Assets und PII identifiziert? Sind die Vertrauensgrenzen markiert?
DFD/Datenkonturen zusammengestellt und an ADR gebunden?
Sind STRIDE/LINDDUN über jeden DFD-Pfeil gelaufen?
Das Risiko-Tritment ist ausgewählt; gibt es Eigentümer/Deadlines/DoD?
Richtlinien als Code hinzugefügt (OPA/Kyverno/CI-Gates)?
Monitoring-/Alert-Plan und IR-Runbook aktualisiert?
Datenschutz: Minimierung, Verschlüsselung, TTL/Retention, Lokalisierung?

12. 3 Webhook-Richtlinie (Pseudocode)

python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 200

13) Anti-Muster

Bedrohungsmodell „zum Ankreuzen“ ohne DFD/Invarianten.
„Super-Perimeter“ ohne interne Service-to-Service-Authentifizierung.
Langlebige Geheimnisse in Umgebungsvariablen/Repos.
Richtlinien, die nicht als Code implementiert sind → werden manuell „vergessen“.
Protokolle mit PD ohne Maskierung und ohne Retenschen/TTL.
Supply chain ignorieren (keine SBOMs/Signaturen/Scans).
Risikoübernahme (Accept) ohne Eigentümer und Revisionsdatum.

14) Integration in Prozesse

RFC/ADR: Jede sinnvolle Lösung enthält den Abschnitt „Bedrohungen und Kontrollen“.
Docs-as-Code: Bedrohungsmodell, DFD, Risikoregister in der Version neben dem Code.
Release Gates: Die Freigabe wird blockiert, wenn SAST/SCA/SBOM-Richtlinien fehlschlagen oder keine Kontrollen mit hoher Kritikalität vorhanden sind.
Training: Playbooks für Entwickler (Geheimnisse, Signaturen, PoLP), regelmäßige Tabletops.

Schluss

Threat Modeling ist eine technische Praxis des Risikomanagements und kein einmaliges Dokument. Identifizieren Sie Assets und Vertrauensgrenzen, wenden Sie STRIDE/LINDDUN an, messen Sie das Risiko, erfassen Sie es im Register und implementieren Sie die Kontrollen als Code, indem Sie sie in CI/CD und Betrieb einbetten. Mit Reifegradmetriken und regelmäßiger Überarbeitung verwandeln Sie Sicherheit in eine vorhersehbare architektonische Fähigkeit - mit einem nachvollziehbaren Preis, Wirkung und Geschwindigkeit.