Threat modeling en diseño

El threat modeling en AppSec analiza una funcionalidad o aplicación en fase de diseño para encontrar fallos antes de escribir código. Es la práctica de mayor retorno del Secure SDLC: corregir un fallo de diseño en un diagrama cuesta minutos; en producción, un incidente. (Para la teoría general ver Modelado de amenazas.)

Cuándo y para qué

- en el DISEÑO de una nueva feature/servicio, y al cambiar algo relevante de arquitectura
- salida: lista PRIORIZADA de amenazas + mitigaciones que entra en el backlog
- no es un documento muerto: se mantiene vivo con la evolución del sistema

Proceso ágil (las 4 preguntas de Shostack)

1. ¿Qué construimos?   diagrama simple (DFD): componentes, flujos, LÍMITES DE CONFIANZA
2. ¿Qué puede ir mal?  STRIDE por elemento/flujo (ver cti-modelado)
3. ¿Qué hacemos?       mitigación por amenaza (control, aceptar, transferir)
4. ¿Lo hicimos bien?   revisar; las mitigaciones se vuelven requisitos/tests

STRIDE aplicado a una feature

Spoofing              ¿cómo se autentica cada actor/servicio? (tokens, mTLS)
Tampering             ¿se valida la entrada? ¿integridad de datos en tránsito/reposo?
Repudiation           ¿hay logging suficiente de acciones sensibles? (def-deteccion)
Information disclosure ¿datos sensibles cifrados? ¿control de acceso por objeto? (web-logic)
Denial of service     ¿límites de tasa/recursos? ¿entradas que amplifican coste?
Elevation of privilege ¿autorización en cada endpoint? ¿IDOR/escalada? (web-api)

Integración en el flujo de desarrollo

- "threat modeling as code" / como parte del diseño en el PR de arquitectura
- plantillas ligeras por tipo de servicio; Security Champions facilitan la sesión (dso-sdlc)
- OWASP Threat Dragon / pytm para modelar; enlazar amenazas a tickets y tests
- revisar contra ASVS: convertir mitigaciones en requisitos verificables

Errores comunes

- hacerlo demasiado tarde (ya en código) -> pierde el valor de "diseño"
- modelos gigantes que nadie mantiene -> mejor ligero, iterativo y por feature
- no priorizar -> lista infinita de amenazas sin acción
- olvidar PRIVACIDAD (datos personales, RGPD) -> añadir LINDDUN (cti-modelado)

Blue Team / AppSec

Modelar en diseño, ligero e iterativo, por feature; salida = mitigaciones priorizadas en el backlog.
Centrarse en límites de confianza y aplicar STRIDE por flujo; enriquecer con ATT&CK/CTI.
Convertir mitigaciones en requisitos verificables (ASVS) y tests; mantener el modelo vivo.
Escalar con Security Champions y plantillas; no dejarlo como ejercicio puntual.

CVEs y casos reales

Fallos de control de acceso (IDOR/BOLA, nº1 del OWASP API Top 10) se previenen modelando autorización en diseño (Seguridad de APIs (OWASP API Top 10)).
Brechas por datos sensibles sin cifrar o endpoints sin autorización que un threat model habría señalado.
Organizaciones con threat modeling en el SDLC reducen el coste y el número de fallos de diseño en producción.

Checklist de prueba

Diagrama (DFD) de la feature con límites de confianza
STRIDE por elemento/flujo
Enriquecer con TTPs reales (ATT&CK) y privacidad (LINDDUN/RGPD)
Priorizar amenazas y definir mitigaciones
Mitigaciones → requisitos ASVS y tests
Enlazar amenazas a tickets del backlog
Mantener el modelo vivo con cada cambio