OPSEC

STRIDE Threat Modeling im Sprint: Vollstaendiges Beispiel an einem Microservice

Por Equipe Basilisk ·

Wie wir STRIDE auf einen echten Payments-Microservice innerhalb eines zweiwoechigen Sprints anwenden, mit DFD, priorisierten Bedrohungen und konkreten Mitigations.

Threat Modeling verstaubt in der Schublade, sobald es zu einem vierstuendigen Meeting ohne Owner wird. Bei Basilisk OffSec verdrahten wir STRIDE in zweiwoechige Sprints mit einem Payments-Microservice als Versuchskaninchen: 1 Backend-Dev, 1 SRE, 1 offensiver Researcher, 90 Minuten Kickoff, 30 Minuten Review zur Sprint-Mitte. Das Ergebnis ist kein 40-Seiten-PDF, sondern 12 Jira-Issues mit pruefbaren Mitigations. Dieser Post zeigt exakt, wie wir das auf dem Service payments-api gefahren haben, der PSP-Webhooks empfaengt, mit Postgres, Redis und einem KMS spricht, und wie jeder STRIDE-Buchstabe zu einem echten Patch im Code wurde.

Vor der Modellierung haben wir das DFD (Data Flow Diagram) in draw.io mit vier Elementen gezeichnet: externe Entitaeten (PSP, Frontend), Prozesse (payments-api, worker-reconciliation), Datastores (Postgres tx_db, Redis idempotency_cache) und Fluesse. Wir haben die Trust Boundaries markiert: Internet -> Cloudflare -> Ingress -> internes Mesh -> KMS. Das Diagramm muss nicht huebsch sein, es muss korrekt sein. In 25 Minuten war es freigegeben. Wer schon mal ein Pentest-Lab gebaut hat, weiss, dass ein falsches Diagramm falsche Tests erzeugt Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen. Wenn euer Webhook-Flow nicht zeigt, dass die HMAC-Pruefung vor dem JSON-Parse passiert, modelliert ihr den Service in eurem Kopf, nicht den in Produktion.

Spoofing tauchte zuerst im Flow PSP -> payments-api auf. Der Webhook kam mit dem Header X-Signature, aber die Pruefung lief nach json.loads(body), was ein Parser-Differential-Fenster oeffnete. Fix: HMAC SHA-256 mit KMS-rotierter Schluessel vor dem Body validieren, Vergleich constant-time via hmac.compare_digest. Tampering kam aus Redis: der Idempotenz-Cache hatte weder feste TTL noch Signatur, ein Angreifer mit interner Netzwerksicht konnte Eintraege injizieren und Charge-Replays ausloesen. Wir haben einen namespaced Prefix plus kurzen HMAC im Key ergaenzt und ACL mit requirepass + TLS auf Redis 7 aktiviert. Repudiation wurde mit append-only audit_log und verketteten Hashes geloest, ein Muster, das wir auch beim Pivoting durch segmentierte Netze dokumentieren Pivoting mit Chisel und Ligolo-ng: Segmentierte Netze im Pentest-Lab.

Information Disclosure wurde mit acht Findings die schwerste Kategorie. Stack Traces leakten via FastAPI-500 in einem auf Prod gespiegelten Staging, Secrets erschienen unter /debug hinter einem magischen Header, den ein Praktikant 2024 vergessen hatte, und der Prometheus-/metrics-Endpoint zeigte Labels mit card_bin. Fix: Middleware, die nur {error_id, code} an den Client serialisiert, /debug entfernt, relabel_config in Prometheus, das sensible Labels dropt. Damit das Team den Impact spuert, haben wir einen POC analog zu einem SSRF gezeigt, der Cloud Metadata zieht, eine Uebung, die wir in einem anderen Lab dokumentiert haben SSRF Entmystifiziert: Cloud Metadata im Lokalen AWS-Lab Ausnutzen. Zusaetzlich laeuft SAST mit eigenen Semgrep-Regeln und SCA mit osv-scanner, beide als blockierende Gates fuer High und Critical in der Pipeline.

Denial of Service wurde nicht als reines Rate Limiting behandelt. Wir haben algorithmische Amplifikation gemappt: ein /search-Endpoint akzeptierte Client-Regex und feuerte Postgres mit LIKE %term% an. Ersetzt durch tsvector mit GIN-Index und 64-Zeichen-Cap auf dem Term. Token Bucket pro API-Key in envoy (100 rps, Burst 200) und Circuit Breaker auf dem KMS-Client via pybreaker, denn das managed KMS hat ein Kontingent von 1200 ops/s pro Key und wir haben damit im Januar bereits einen 14-minuetigen Incident verursacht. Elevation of Privilege schloss die Liste: das interne API-JWT nutzte HS256 mit einem Secret, das sich 6 Services teilten. Migration zu RS256 mit Schluessel pro Service im KMS, audience-spezifischen Claims und exp + nbf + iss Validierung in einem zentralen Middleware, ausgeliefert als interne Library basilisk-authz==2.3.0.

Am Sprint-Ende wurde jeder Punkt zu einem Issue mit Titel STRIDE--: und Tag mitigation:. Von 12 Bedrohungen wurden 9 als gemergte PRs im selben Sprint ausgeliefert, 2 als Restrisiko mit 90-Tage-Review akzeptiert und 1 wurde Epic fuer das Webhook-Refactoring. Gesamtaufwand: 4 verteilte Meeting-Stunden plus die Code-Arbeit, die ohnehin im Sprint lag. STRIDE ist keine Audit-Checkliste, es ist eine gemeinsame Sprache zwischen Dev, SRE und Offensive. Praktischer Takeaway: beginnt mit einem einseitigen DFD, zwingt die 6 Buchstaben gegen jeden Flow, der eine Trust Boundary kreuzt, und verlangt, dass jede Bedrohung als Issue mit pruefbarem Akzeptanzkriterium landet. Wird daraus in diesem Sprint kein Code, war es kein Threat Modeling, sondern Theater.

Nenhum comentário ainda

Seja o primeiro a comentar.

Deixe seu comentário

Entre com sua conta Canverly para comentar. Você pode usar a mesma conta em qualquer site da rede.

Entrar com Canverly