Threat modeling con Microsoft Threat Modeling Tool: encuentra los fallos antes de escribir código

La mayoría de las vulnerabilidades graves no nacen en el código: nacen en el diseño. El pentesting encuentra los fallos cuando el sistema ya está construido; el análisis de código, cuando ya está escrito. Pero decisiones como «¿dónde valido los permisos?», «¿qué viaja por esta API?» o «¿qué pasa si alguien manipula este parámetro?» se toman — o se ignoran — meses antes, en una pizarra. El threat modeling (modelado de amenazas) es la disciplina que lleva la pregunta «¿qué puede salir mal?» a ese momento exacto, cuando corregir cuesta una conversación en lugar de una refactorización de emergencia.

La idea no es nueva ni exótica: es la misma que aplica un arquitecto al calcular cargas antes de construir. Lo que la hace accesible es que existe un método concreto — STRIDE, creado en Microsoft hace más de dos décadas — y una herramienta gratuita que lo automatiza: la Microsoft Threat Modeling Tool, pieza central del Security Development Lifecycle (SDL) de Microsoft y aún hoy, con actualizaciones recientes, la implementación de referencia del método.

En esta guía explicamos el concepto y la práctica: qué es modelar amenazas y por qué es de lo más rentable en seguridad, cómo funciona STRIDE con ejemplos de una plataforma web real, cómo trabaja la herramienta de Microsoft paso a paso, y cómo encajarla en el ciclo de desarrollo de un equipo normal — sin burocracia y sin necesitar un departamento de seguridad.

1. Qué es el threat modeling y por qué hacerlo en el diseño

Modelar amenazas es responder de forma estructurada a cuatro preguntas, en este orden: ¿qué estamos construyendo? (un diagrama del sistema), ¿qué puede salir mal? (la enumeración de amenazas), ¿qué hacemos al respecto? (mitigaciones priorizadas) y ¿lo hemos hecho bien? (validación). Nada más — y nada menos: la diferencia con «pensar un rato en seguridad» es la sistemática, que es precisamente lo que evita que se escape la amenaza incómoda que nadie quería ver.

El argumento económico es contundente. Un control de acceso mal diseñado detectado en la fase de diagrama se arregla moviendo una caja; detectado en un pentest tras el lanzamiento, exige retrabajo, regresiones y despliegues urgentes; detectado por un atacante, cuesta un incidente. Es el principio shift-left aplicado a seguridad: cuanto antes se encuentra el fallo, más barato es. Por eso el threat modeling es el complemento natural — no el sustituto — de las auditorías y pruebas de intrusión posteriores.

¿Cuándo se hace? En el diseño inicial de cualquier sistema que maneje datos o dinero, y después en cada cambio arquitectónico significativo: una integración nueva, una API pública, un cambio de modelo de autenticación. No es un documento que se hace una vez y se enmarca: es un artefacto vivo del proyecto.

2. STRIDE: las seis formas en que las cosas salen mal

STRIDE es la mnemotecnia que estructura la pregunta «¿qué puede salir mal?». Cada letra es una categoría de amenaza, y cada categoría ataca una propiedad de seguridad concreta:

• S — Spoofing (suplantación): hacerse pasar por otro. En un ecommerce: robar la sesión de un cliente, o un tercero que se hace pasar por tu pasarela de pago. Propiedad atacada: la autenticación. Mitigaciones típicas: MFA, tokens con caducidad corta, verificación de firmas en webhooks.
• T — Tampering (manipulación): alterar datos o código. El clásico: modificar el precio del producto en la petición del carrito porque el servidor confía en lo que envía el navegador. Propiedad: la integridad. Mitigación: validar todo en servidor, firmar lo que viaja.
• R — Repudiation (repudio): negar haber hecho algo sin que puedas demostrar lo contrario. Un administrador borra registros y no hay log de auditoría que lo acredite. Propiedad: el no repudio. Mitigación: logs de auditoría inmutables y con marca de tiempo.
• I — Information disclosure (revelación de información): datos que llegan a quien no debe. Una API que devuelve el pedido de cualquier usuario cambiando el ID de la URL. Propiedad: la confidencialidad. Mitigaciones: control de acceso a nivel de objeto, cifrado en tránsito y reposo, minimización.
• D — Denial of service (denegación de servicio): tumbar o degradar el servicio. El buscador interno sin límite de peticiones que permite freír la base de datos. Propiedad: la disponibilidad. Mitigaciones: rate limiting, colas, timeouts, degradación controlada.
• E — Elevation of privilege (elevación de privilegios): conseguir permisos que no corresponden. Un usuario normal que llega al panel de administración porque la autorización se comprueba en el frontend. Propiedad: la autorización. Mitigación: comprobación de permisos en servidor en cada operación, principio de mínimo privilegio.

Si estos ejemplos te suenan, es porque son la versión de diseño de las vulnerabilidades que luego aparecen en el OWASP Top 10: el modelado de amenazas es la forma de cazarlas antes de que existan.

3. La Microsoft Threat Modeling Tool: qué es y cómo trabaja

La Microsoft Threat Modeling Tool es la aplicación gratuita (Windows) con la que Microsoft instrumenta su propio SDL, mantenida desde hace más de una década y con versiones recientes en 2026. Su base de trabajo tiene dos piezas:

3.1 El diagrama de flujo de datos (DFD)

Todo parte de dibujar tu sistema con cinco tipos de elemento: procesos (tu aplicación, tus servicios), entidades externas (usuarios, pasarelas, APIs de terceros), almacenes de datos (bases de datos, colas, buckets), flujos de datos (las flechas: qué viaja de dónde a dónde) y — la pieza clave — fronteras de confianza (trust boundaries): las líneas que separan zonas con distinto nivel de confianza, como Internet/tu backend, o backend/base de datos. La experiencia dice que el mero hecho de dibujar el DFD ya destapa sorpresas: flujos que nadie recordaba, datos sensibles cruzando fronteras sin cifrar, servicios con acceso a más de lo que necesitan.

3.2 STRIDE-per-element: la generación automática de amenazas

Aquí está el valor diferencial de la herramienta: al pulsar el botón de análisis, aplica STRIDE por elemento — sabe que a un almacén de datos le aplican manipulación y revelación de información, que a un proceso le aplican las seis categorías, que todo flujo que cruza una frontera de confianza merece revisión — y genera automáticamente la lista de amenazas candidatas para tu diagrama concreto, con descripción y sugerencias. De un DFD de tamaño medio salen fácilmente 40-80 amenazas potenciales.

Esa lista no es el resultado final: es la agenda de la conversación. Cada amenaza se revisa y se le asigna estado — mitigada (y cómo), pendiente de investigar, no aplicable (y por qué) — y la herramienta genera un informe HTML con todo el razonamiento, que sirve directamente como evidencia de diseño seguro en auditorías y certificaciones. Sus limitaciones, para ser justos: solo Windows, interfaz anticuada, sin integración nativa con Git o CI/CD, y plantillas orientadas al ecosistema Azure (aunque el método vale para cualquier stack).

4. Ejemplo práctico: modelando un checkout de ecommerce

Veámoslo con un caso que conocemos bien: el proceso de pago de una tienda online. El DFD tendría al cliente (entidad externa) hablando con el frontend, este con la API de checkout (proceso), que consulta la base de datos de pedidos (almacén) y llama a la pasarela de pago (entidad externa), que a su vez devuelve confirmación por webhook. Dos fronteras de confianza: Internet/backend y backend/pasarela. El análisis STRIDE de ese diagrama pone sobre la mesa, entre otras:

• Spoofing del webhook: ¿qué impide que un atacante llame a tu endpoint de confirmación simulando ser la pasarela y dé por pagado un pedido? Mitigación: verificar la firma criptográfica del webhook — un control que se decide en el diseño, no después.
• Tampering en el importe: el total viaja del frontend a la API. Si la API no lo recalcula en servidor, el precio lo pone el atacante. Mitigación: el carrito manda referencias, el servidor calcula.
• Information disclosure en el almacén de pedidos: direcciones y datos de contacto accesibles por IDs predecibles. Mitigación: autorización a nivel de objeto — el mismo principio que desarrollamos en la guía de seguridad de APIs REST.
• Denial of service en el checkout: el flujo más caro de la plataforma expuesto sin límite de tasa. Mitigación: rate limiting y colas antes de que el pico — malicioso o de campaña — decida por ti.
• Repudiation en cambios de pedido: ¿quién cambió esta dirección de envío después del pago? Sin log de auditoría, nadie puede responder. Mitigación: registro inmutable de operaciones sensibles.

Una sesión de dos horas con este diagrama, el equipo de desarrollo y la herramienta delante suele producir la lista de deberes de seguridad más rentable del proyecto.

5. Threat modeling, ISO 27001 y el desarrollo seguro

Si tu empresa está en el camino de certificarse, esto no es un extra: es una pieza que encaja directamente. El modelado de amenazas es la versión a nivel de aplicación del análisis de riesgos que exige ISO 27001, y los controles de desarrollo seguro de la norma — requisitos de seguridad en el diseño, principios de ingeniería segura — se evidencian de forma natural con los informes de la herramienta, como vimos al repasar los controles técnicos de ISO 27001 y el SDLC seguro. Un modelo de amenazas por sistema crítico, revisado en cada cambio grande, es exactamente el tipo de evidencia que un auditor quiere ver — y que además sirve para algo.

6. Alternativas y cómo empezar sin fricción

Si el requisito de Windows o la integración con tu flujo de trabajo son un problema, la alternativa madura es OWASP Threat Dragon: open source, multiplataforma (web y escritorio), guarda los modelos como JSON en tu repositorio Git — con lo que el modelo de amenazas versiona junto al código — y soporta STRIDE entre otros marcos. Menos automatización en la generación de amenazas que la herramienta de Microsoft, más encaje en equipos de desarrollo modernos.

Y para empezar, nuestra recomendación de mínimos, probada con equipos que nunca habían hecho esto:

• Elige un solo sistema — el más crítico o el que está ahora en diseño. No intentes modelar toda la empresa.
• Sesión de 2 horas: quien conoce la arquitectura, quien conoce el negocio, y el DFD dibujándose en directo. La herramienta genera la lista; el equipo la discute.
• Sal con máximo 10 mitigaciones priorizadas con responsable y fecha. Una lista de 80 amenazas sin dueño es un PDF muerto.
• Revisa el modelo en cada cambio de arquitectura y una vez al año. Añadir una integración nueva al diagrama cuesta minutos; las amenazas nuevas aparecen solas.

7. Errores comunes al empezar (y cómo evitarlos)

\n\n

Después de facilitar sesiones de modelado con equipos muy distintos, los tropiezos se repiten con una regularidad casi cómica. Los cinco que más proyectos de threat modeling matan:

\n\n

\n
• Modelar con demasiado detalle. Un DFD con sesenta cajas es tan inútil como uno con dos: la sesión muere dibujando en lugar de analizando. La granularidad correcta es la que permite discutir fronteras de confianza — si dos procesos viven en el mismo servidor con los mismos permisos, probablemente son una sola caja.

\n

• Convertirlo en un trámite de una sola vez. El modelo que se hace para la auditoría y no se vuelve a abrir pierde su valor en el primer sprint que cambia la arquitectura. El antídoto es ligarlo a eventos concretos: integración nueva, endpoint público nuevo, cambio de autenticación — modelo revisado.

\n

• Hacerlo sin la gente que construye. Un modelo hecho solo por el responsable de seguridad se queda en teoría; los desarrolladores conocen los atajos reales del sistema — ese endpoint interno «temporal» de hace dos años — que es exactamente donde viven las amenazas buenas.

\n

• Aceptar las amenazas generadas sin discutirlas. La herramienta produce candidatas, no verdades: marcar 60 amenazas como «mitigadas» en una tarde para cerrar el informe es autoengaño con formato HTML. Mejor 15 amenazas discutidas de verdad que 60 tramitadas.

\n

• No priorizar. Sin un criterio de riesgo (impacto x probabilidad, aunque sea estimado en camisetas S/M/L), todo parece igual de urgente y nada se arregla. La salida de cada sesión debe caber en un sprint: pocas mitigaciones, con dueño y fecha.

\n

\n\n

El patrón de fondo es siempre el mismo: el threat modeling funciona cuando se trata como una práctica de ingeniería — ligera, recurrente, integrada en el flujo de diseño — y fracasa cuando se trata como un documento de cumplimiento. La herramienta es la misma en ambos casos; la diferencia es el hábito del equipo.

\n\n

Conclusión

El threat modeling es probablemente la práctica con mejor relación esfuerzo/beneficio de toda la seguridad de aplicaciones: una pizarra, un método de seis letras y una herramienta gratuita bastan para encontrar en horas de diseño lo que costaría semanas de retrabajo o un incidente descubrir después. La Microsoft Threat Modeling Tool no es la herramienta más moderna del mundo, pero automatiza lo difícil — no olvidarse de ninguna categoría de amenaza en ningún elemento — y produce evidencia útil para auditorías por el camino.

La clave, como siempre, no es la herramienta sino el hábito: la pregunta «¿qué puede salir mal aquí?» hecha sistemáticamente cada vez que alguien dibuja una caja nueva en la arquitectura. Los equipos que la incorporan diseñan distinto — y se nota en cada pentest posterior.

Preguntas frecuentes sobre threat modeling

¿El threat modeling sustituye al pentesting?

No: son complementarios y atacan momentos distintos. El modelado encuentra fallos de diseño antes de construir; el pentesting verifica la implementación real, incluyendo los errores que ningún modelo predice. La combinación ideal es modelar en diseño, desarrollar con las mitigaciones, y auditar el resultado.

¿Sirve la herramienta de Microsoft si no uso Azure ni .NET?

Sí. Las plantillas por defecto están orientadas al ecosistema Microsoft, pero el método STRIDE y los elementos del DFD (procesos, flujos, almacenes, fronteras) son universales: modelar un stack PHP, Node o Python funciona exactamente igual. Si prefieres algo agnóstico e integrado en Git, OWASP Threat Dragon es la alternativa natural.

¿Cada cuánto hay que actualizar un modelo de amenazas?

Con cada cambio arquitectónico relevante (integración nueva, API nueva, cambio de autenticación) y como mínimo una revisión anual. La señal de alarma es la contraria: si tu sistema evoluciona cada trimestre y el modelo lleva dos años sin tocarse, ya no describe lo que tienes en producción.