En la lección anterior situamos el diseño como la fase de mayor retorno del S-SDLC, y su actividad estrella como el modelado de amenazas. Ya lo anticipamos en la lección 03-05 (Diseño Inseguro), donde dijimos que un fallo de arquitectura no se corrige con un parche y que la forma de anticiparlo tenía nombre propio, cuyo desarrollo dejábamos para aquí. Ha llegado el momento. El modelado de amenazas es el ejercicio estructurado de imaginar, antes de construir, cómo un adversario intentaría abusar del sistema, para decidir qué defensas incorporar por diseño. Es la disciplina que responde a la pregunta que un pentest solo responde tarde y caro: ¿qué puede salir mal? En esta lección construimos un threat model completo del checkout de BazarNube.

1. Qué es el modelado de amenazas y cuándo hacerlo
2. Las cuatro preguntas de Shostack
3. Diagramas de flujo de datos (DFD) y límites de confianza
4. STRIDE: un lenguaje de categorías de amenaza
5. Priorización de riesgos (DREAD y alternativas)
6. Herramientas: Threat Dragon y pytm
7. Threat model del checkout de BazarNube
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Modelar amenazas es analizar un diseño buscando de forma sistemática sus puntos débiles y las contramedidas apropiadas. No requiere que el sistema esté construido: se hace sobre diagramas y decisiones, que es precisamente su ventaja. Es un ejercicio de equipo, no un informe que redacta un experto en solitario; el valor está tanto en el documento resultante como en la conversación que lo produce.

¿Cuándo hacerlo?

• Al diseñar una funcionalidad nueva con datos sensibles o dinero de por medio.
• Ante un cambio de arquitectura relevante (nuevo servicio, nueva integración externa, nuevo almacén de datos).
• De forma periódica sobre componentes críticos, porque el sistema y las amenazas evolucionan.
• No es realista modelar cada commit: se reserva para lo que importa, guiado por la clasificación de datos que hicimos en la fase de requisitos.

Adam Shostack popularizó un marco de cuatro preguntas que estructura cualquier sesión de modelado. OWASP lo adopta como columna vertebral del proceso.

La cuarta pregunta cierra el bucle: un threat model no es un artefacto muerto, se revisa cuando el diseño cambia. Nótese el paralelismo con el S-SDLC: la pregunta 3 alimenta requisitos ASVS y la pregunta 4 se apoya en verificación (por ejemplo, ZAP comprobando que una mitigación funciona).

Para responder "¿qué construimos?" se dibuja un Diagrama de Flujo de Datos (Data Flow Diagram). Un DFD usa un vocabulario deliberadamente pequeño:

• Entidad externa (rectángulo): actor fuera de nuestro control (usuario, pasarela de pago).
• Proceso (círculo): código que transforma datos (una API, un servicio).
• Almacén de datos (dos líneas paralelas): base de datos, caché, cola.
• Flujo de datos (flecha): el movimiento de datos entre los anteriores.
• Límite de confianza (línea discontinua): la frontera donde cambia el nivel de confianza; cruzarla es donde nacen la mayoría de las amenazas.

Los límites de confianza son el concepto clave. Cada vez que un dato cruza uno —de Internet a nuestra API, de nuestra API a la base de datos, de nuestro backend a un servicio de terceros— hay una oportunidad para el atacante y una necesidad de validar, autenticar o cifrar. Modelar bien consiste, en buena medida, en enfocar la atención en esos cruces.

Responder "¿qué puede salir mal?" a mano lleva a olvidos. STRIDE, creado en Microsoft, es una mnemónica que fuerza a considerar seis categorías de amenaza para cada elemento del DFD. Cada categoría es la negación de una propiedad de seguridad deseable.

Una técnica práctica es STRIDE-per-element: recorrer cada proceso, almacén y flujo del DFD y preguntarse qué letras de STRIDE aplican. No todas aplican a todos los elementos, y eso está bien; el valor es la cobertura sistemática.

No todas las amenazas merecen la misma atención. Hace falta priorizar para invertir el esfuerzo donde importa. DREAD es un modelo clásico que puntúa cada amenaza en cinco ejes (típicamente 1-3 o 1-10):

• Damage — daño potencial.
• Reproducibility — facilidad de reproducir el ataque.
• Exploitability — esfuerzo para explotarlo.
• Affected users — cuántos usuarios afecta.
• Discoverability — facilidad de descubrir la vulnerabilidad.

Se suman los ejes y se ordena. DREAD es simple pero subjetivo (dos personas puntúan distinto), por lo que muchos equipos prefieren alternativas:

Para BazarNube usaremos una simple matriz probabilidad x impacto (Alto/Medio/Bajo), suficiente para priorizar y fácil de consensuar en equipo.

Modelar puede hacerse en una pizarra, pero hay herramientas que ayudan a mantener el modelo vivo y versionado:

• OWASP Threat Dragon: aplicación gráfica (web y escritorio) para dibujar DFDs y anotar amenazas STRIDE. Guarda el modelo como JSON, versionable en Git junto al código. Ideal para equipos que prefieren lo visual.
• pytm: framework de threat modeling as code en Python. Se describe el sistema como objetos (procesos, almacenes, flujos, límites) en un script y la herramienta genera el DFD y un informe de amenazas. Encaja con la filosofía "todo como código" que veremos en DevSecOps.

La herramienta no sustituye el criterio: es el equipo quien decide qué amenazas son reales y qué mitigaciones aplican.

Apliquemos las cuatro preguntas al flujo más sensible de BazarNube: el checkout, donde convergen datos personales, direcciones y el pago.

Los cruces de límite de confianza son: cliente→API (Internet a interna), API→pasarela y el webhook pasarela→API (interna a tercero). Ahí concentramos el análisis.

Obsérvese cómo cada mitigación enlaza con un control ya estudiado: el threat model no inventa defensas nuevas, sino que decide cuáles del catálogo Top Ten/ASVS aplican a este diseño. El threat model traduce riesgos genéricos en requisitos concretos y verificables. Ese es exactamente el puente hacia la fase de pruebas, donde ZAP y las pruebas manuales confirmarán que la mitigación funciona.

El Security Champion del equipo revisa el modelo, se registran las mitigaciones como requisitos de aceptación (ASVS) en el backlog, y se marca el modelo para revisión cuando cambie la pasarela o se añada, por ejemplo, pago aplazado. La amenaza del webhook falsificado se convierte en una historia con su prueba correspondiente.

• Modelar el sistema perfecto, no el real. El DFD debe reflejar cómo funciona de verdad, incluidos los atajos y el servicio legacy de Java. Un modelo idealizado oculta las amenazas reales.
• Buscar la exhaustividad absoluta. Es imposible enumerar toda amenaza. Prioriza los cruces de límite de confianza y los datos sensibles; un modelo "suficientemente bueno" y revisado supera a uno perfecto que nunca se termina.
• Convertirlo en un documento muerto. Si el modelo no se revisa cuando cambia el diseño, caduca. Vincúlalo al proceso (pregunta 4) y guárdalo versionado junto al código.
• Hacerlo en solitario. El valor está en la conversación entre desarrollo, seguridad y producto. Sin el equipo, se pierde el conocimiento del sistema real.
• Consejo: empieza pequeño. Un DFD en pizarra de una hora sobre el flujo más crítico aporta más que un curso teórico. La habilidad se desarrolla modelando.

Ejercicio 1. En el DFD del checkout, un desarrollador propone que el frontend envíe el precio total ya calculado "para ahorrar una consulta". Identifica la categoría STRIDE del riesgo y la mitigación correcta.

Ejercicio 2. Clasifica cada amenaza con la letra STRIDE adecuada: (a) un atacante repite un webhook de pago capturado, (b) un usuario cambia el order_id de la URL y ve el pedido de otro, (c) el log no registra quién canceló un pedido.

Ejercicio 3. BazarNube va a añadir "iniciar sesión con Google". Dibuja mentalmente el nuevo flujo e indica un nuevo límite de confianza y una amenaza STRIDE que aparece con esta integración.

Solución 1. Es Tampering (manipulación de integridad): confiar en un precio enviado por el cliente permite alterarlo en tránsito o desde el navegador y comprar por menos. La mitigación es no confiar nunca en datos del cliente para decisiones de dinero: el servidor recalcula el precio desde el catálogo autorizado. Relaciona con A04 (Diseño Inseguro) y ASVS V5 (validación).

Solución 2.

• (a) Tampering y/o Spoofing (webhook de replay/falsificado); se mitiga con firma HMAC y control anti-replay (nonce/timestamp).
• (b) Elevation of privilege / control de acceso roto (IDOR); autorización por objeto.
• (c) Repudiation; registro íntegro con identidad y marca temporal.

Solución 3. Aparece un nuevo límite de confianza con el proveedor de identidad externo (Google) y el flujo OAuth/OIDC que cruza a un tercero. Una amenaza típica es Spoofing: aceptar un token de identidad no validado correctamente (firma, audiencia, emisor, expiración) permitiría suplantar a un usuario. Se mitiga validando el token según el estándar OIDC y ligando la cuenta local de forma segura. Relaciona con A07 y ASVS V2/V3.

El modelado de amenazas es la práctica que da contenido a la fase de diseño del S-SDLC: con un DFD y sus límites de confianza respondemos "qué construimos", con STRIDE "qué puede salir mal", con mitigaciones enlazadas al Top Ten y ASVS "qué hacemos", y con la revisión "lo hicimos bien". En BazarNube hemos convertido un flujo de checkout en una lista priorizada de requisitos verificables. Pero un buen diseño solo se sostiene si el resto del proceso lo respeta de forma automática y continua. En la siguiente lección, 07-03, llevamos estas mitigaciones al terreno de la automatización: cómo DevSecOps convierte estos controles en comprobaciones que el pipeline ejecuta en cada cambio.