Threat Modeling: anticipar los ataques antes de escribir el código

La mayoría de los enfoques modernos siguen el marco de las cuatro preguntas de Adam Shostack («Threat Modeling: Designing for Security», 2014): ¿en qué estamos trabajando? ¿Qué puede salir mal? ¿Qué hacemos al respecto? ¿Hemos hecho un buen trabajo? Las cuatro preguntas estructuran el proceso en modelado del sistema, identificación de amenazas, derivación de medidas y validación, con independencia del método concreto que se emplee. El Threat Modeling Manifesto define en consecuencia el threat modeling como el análisis de representaciones de un sistema para poner de relieve las preocupaciones sobre sus propiedades de seguridad y privacidad. Lo decisivo es el cambio de perspectiva: no comprobar si se cumplen los requisitos, sino preguntarse sistemáticamente qué podría hacer un atacante con el diseño.

STRIDE —formulado en 1999 por Loren Kohnfelder y Praerit Garg en Microsoft y más tarde elemento central del Microsoft Security Development Lifecycle— clasifica las amenazas en seis categorías, cada una de las cuales vulnera un objetivo de protección: Spoofing (autenticación), Tampering (integridad), Repudiation (no repudio), Information Disclosure (confidencialidad), Denial of Service (disponibilidad) y Elevation of Privilege (autorización). PASTA (Process for Attack Simulation and Threat Analysis; UcedaVélez/Morana, 2015) trabaja, en cambio, con un enfoque centrado en el riesgo: en siete etapas —desde la definición de los objetivos, pasando por el alcance técnico, la descomposición y el análisis de amenazas y vulnerabilidades, hasta el modelado de ataques y el análisis de riesgos e impactos— el método vincula ataques simulados con su impacto en el negocio. Los árboles de ataque (Bruce Schneier, 1999) modelan un objetivo de ataque como nodo raíz y lo descomponen mediante relaciones AND/OR en rutas de ataque concretas, que pueden evaluarse, por ejemplo, según su coste o su probabilidad de éxito. En la práctica, los enfoques se complementan: STRIDE para la amplitud sistemática, PASTA para la perspectiva de riesgo y los árboles de ataque para el análisis en profundidad de escenarios concretos.

La base de casi todo análisis es un diagrama de flujo de datos (DFD): entidades externas, procesos, almacenes de datos y flujos de datos representan el sistema, mientras que los límites de confianza marcan las transiciones entre zonas con distintos niveles de confianza, por ejemplo entre Internet y el backend o entre la aplicación y la base de datos. Las amenazas se concentran en estos límites, por lo que constituyen el punto de partida natural de la revisión sistemática. En sistemas complejos es habitual trabajar con varios diagramas con distintos niveles de detalle: una visión general del sistema completo, complementada con vistas detalladas de los componentes críticos. El diagrama sigue siendo un medio para un fin: un modelo que sustente la discusión en el equipo importa más que una exhaustividad perfecta.

En 2020, un grupo de 15 especialistas del ámbito profesional y de la investigación publicó el Threat Modeling Manifesto, inspirado deliberadamente en el Manifiesto Ágil. Formula cinco valores, entre ellos: una cultura de detección y corrección de problemas de diseño frente al cumplimiento de casillas, las personas y la colaboración frente a los procesos, las metodologías y las herramientas, y el refinamiento continuo frente a una entrega única. Cuatro principios concretan su aplicación; por ejemplo, que un análisis temprano y frecuente mejora la seguridad y la privacidad, y que el threat modeling debe adaptarse a las prácticas de desarrollo y a las iteraciones del equipo. Además, el manifiesto identifica patrones favorables, como el enfoque sistemático y la diversidad de puntos de vista, así como antipatrones como el «hero threat modeler» o la búsqueda de la representación perfecta.

Con OWASP Threat Dragon existe una herramienta de modelado libre con estatus «production» de OWASP que, como aplicación web y de escritorio, crea diagramas y documenta amenazas según STRIDE, LINDDUN y PLOT4ai, entre otros (versión actual 2.6.2, mayo de 2026); también está consolidada la Microsoft Threat Modeling Tool. OWASP pytm (proyecto con estatus «lab») sigue otro camino: la arquitectura se describe como código Python, a partir del cual el framework genera diagramas de flujo de datos, diagramas de secuencia e informes de amenazas. Este threat modeling as code hace que los modelos sean versionables, revisables en la revisión de código y automatizables en pipelines de CI/CD: la arquitectura y el modelo de amenazas recorren el mismo proceso de cambios. La automatización no sustituye el análisis conjunto en el equipo, sino que lo escala: las listas de amenazas generadas son un punto de partida, no un resultado final.

El NIST Secure Software Development Framework (SP 800-218, versión 1.1) convierte el modelado de amenazas en parte integral del desarrollo seguro: la tarea PW.1.1 exige formas de modelado de riesgos —expresamente, por ejemplo, threat modeling, attack modeling o attack surface mapping— para evaluar el riesgo de seguridad de un software. En los equipos ágiles esto no funciona como un gran taller puntual, sino de forma incremental: las funcionalidades relevantes para la seguridad, las nuevas interfaces o los cambios de arquitectura desencadenan un análisis focalizado cuyos resultados se incorporan al backlog; anclado como criterio en la Definition of Done, el análisis de amenazas se convierte en la norma y no en la excepción. Es exactamente lo que exige el manifiesto: un análisis temprano y frecuente, adaptado a las iteraciones del equipo. Para los sistemas de IA agéntica, sin embargo, los métodos clásicos se quedan cortos; para ellos, la Cloud Security Alliance presentó en 2025 MAESTRO, un framework propio de siete capas que tratamos en profundidad en nuestro artículo de conocimiento sobre MAESTRO dentro del área temática de Agentic AI Security.