OPSEC

Threat Modeling con STRIDE en Sprints: Ejemplo Completo de un Microservicio

Por Equipe Basilisk ·

Como aplicar STRIDE en un microservicio real de pagos dentro de un sprint de dos semanas, con diagrama, amenazas priorizadas y mitigaciones accionables.

El threat modeling muere en el cajon cuando se convierte en una reunion de cuatro horas sin dueno. En Basilisk OffSec integramos STRIDE en sprints de dos semanas usando un microservicio de pagos como conejillo de indias: 1 dev backend, 1 SRE, 1 investigador ofensivo, 90 minutos de kickoff y 30 minutos de revision a mitad de sprint. El resultado no es un PDF de 40 paginas, son 12 tickets en Jira con mitigaciones verificables. Este post muestra exactamente como lo corrimos en el servicio payments-api, que recibe webhooks de PSPs, habla con Postgres, Redis y un KMS, y como cada letra de STRIDE se convirtio en un parche real en codigo.

Antes de modelar, dibujamos el DFD (Data Flow Diagram) en draw.io con cuatro elementos: entidades externas (PSP, frontend), procesos (payments-api, worker-reconciliation), datastores (Postgres tx_db, Redis idempotency_cache) y flujos. Marcamos las trust boundaries: internet -> Cloudflare -> ingress -> mesh interno -> KMS. Ese diagrama no necesita ser bonito; necesita ser correcto. En 25 minutos teniamos el DFD aprobado. Quien ya monto un lab de pentest sabe que un diagrama erroneo genera tests erroneos Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite. Si tu flujo de webhook no muestra el HMAC validandose antes del parse JSON, vas a modelar el servicio que existe en tu cabeza, no el que esta en produccion.

Spoofing aparecio primero en el flujo PSP -> payments-api. El webhook llegaba con header X-Signature, pero la verificacion se hacia despues del json.loads(body), abriendo ventana para parser differential. Mitigacion: validar HMAC SHA-256 con clave rotativa del KMS antes de tocar el body, con comparacion constant-time via hmac.compare_digest. Tampering surgio en Redis: el cache de idempotencia no tenia TTL fijo ni firma, asi que un atacante con acceso a la red interna podria inyectar entradas para causar replay de cobro. Agregamos prefijo namespaced + HMAC corto en la clave y ACL con requirepass + TLS en Redis 7. Repudiation se trato con log append-only en una tabla audit_log con hash encadenado, patron que tambien usamos cuando documentamos pivoting en redes segmentadas Pivoting con Chisel y Ligolo-ng: Redes Segmentadas en Lab de Pentest.

Information Disclosure fue la categoria con mas hallazgos, ocho en total. Stack traces se filtraban via 500 de FastAPI en homologacion espejo de prod, secrets aparecian en /debug detras de un header magico olvidado por un becario en 2024, y el endpoint /metrics de Prometheus exponia labels con card_bin. Lo corregimos con middleware que serializa solo {error_id, code} al cliente, removimos /debug, y aplicamos relabel_config en Prometheus dropeando labels sensibles. Para que el equipo entendiera el impacto, mostramos una POC equivalente a un SSRF tirando cloud metadata, ejercicio ya documentado en otro lab SSRF sin Complicaciones: Explotando Cloud Metadata en Lab AWS Local. Tambien corrimos SAST con reglas custom de Semgrep y SCA con osv-scanner; ambos entraron al pipeline como gates bloqueantes para High y Critical.

Denial of Service no se trato solo como rate limit. Mapeamos amplificacion algoritmica: un endpoint /search aceptaba regex del cliente y golpeaba Postgres con LIKE %term%. Lo cambiamos por tsvector con indice GIN y cap de 64 caracteres en el termino. Agregamos token bucket por API key en envoy (100 rps burst 200) y circuit breaker en el client del KMS con pybreaker, porque el KMS gestionado tiene cuota de 1200 ops/s por clave y ya causamos un incidente de 14 minutos en enero. Elevation of Privilege cerro la lista: el JWT de la API interna usaba HS256 con secreto compartido entre 6 servicios. Migramos a RS256 con clave por servicio en KMS, claims con aud especifico, y validacion de exp + nbf + iss en middleware unico publicado como libreria interna basilisk-authz==2.3.0.

Al cierre del sprint, cada item se convirtio en issue con titulo en formato STRIDE--: y tag mitigation:. De las 12 amenazas levantadas, 9 se mergearon como PRs en el mismo sprint, 2 fueron aceptadas como riesgo residual con revision a 90 dias, y 1 se convirtio en epic de refactor del modulo de webhooks. Costo total: 4 horas de reunion distribuidas, mas el trabajo de codigo que ya estaria en sprint. STRIDE no es checklist de auditoria; es lenguaje comun entre dev, SRE y ofensivo. Takeaway practico: arranca por el DFD de 1 pagina, forza las 6 letras contra cada flujo que cruce trust boundary, y exige que toda amenaza termine como issue con criterio de aceptacion verificable. Si no se vuelve codigo en este sprint, no fue threat modeling, fue teatro.

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