Reservar cita

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

Cómo identificar los riesgos de seguridad ya en la fase de diseño con el marco de las cuatro preguntas, STRIDE, PASTA y árboles de ataque, y cómo anclar el threat modeling de forma permanente en el SDLC y en los equipos ágiles.

Las vulnerabilidades más costosas rara vez son errores de programación, sino decisiones de diseño: un límite de confianza ausente, un flujo de datos sin proteger, un caso de abuso no contemplado. El threat modeling analiza representaciones de un sistema para hacer visibles de forma estructurada estos problemas de seguridad y privacidad antes de que se implementen. Lo que durante mucho tiempo se consideró una disciplina de expertos está hoy bien sistematizado desde el punto de vista metodológico: el marco de las cuatro preguntas aporta la estructura, métodos como STRIDE y PASTA la sistemática, y herramientas desde OWASP Threat Dragon hasta pytm reducen la barrera de entrada. Al mismo tiempo, marcos como el NIST Secure Software Development Framework anclan expresamente el modelado de amenazas en el proceso de desarrollo seguro.

Lo esencial en resumen

01

El marco de las cuatro preguntas de Shostack

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.

02

Métodos: STRIDE, PASTA y árboles de ataque

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.

03

Diagramas de flujo de datos y límites de confianza

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.

04

El Threat Modeling Manifesto

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.

05

Herramientas y threat modeling as code

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.

06

Anclaje en el SDLC, el desarrollo ágil y la Definition of Done

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.

Estándares y fuentes

Los contenidos de esta página se basan en las siguientes guías y estudios disponibles públicamente.

Threat Modeling Manifesto Working Group · 2020

Threat Modeling Manifesto

Define el threat modeling, remite al marco de las cuatro preguntas y formula cinco valores, cuatro principios, así como patrones y antipatrones como guías neutrales respecto al método.

Adam Shostack / Wiley · 2014

Threat Modeling: Designing for Security

Obra de referencia de la que procede el marco de las cuatro preguntas que siguen la mayoría de los enfoques modernos de threat modeling.

Tony UcedaVélez, Marco M. Morana / Wiley · 2015

Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis

Fuente original de la metodología PASTA de siete etapas y centrada en el riesgo, que vincula ataques simulados con el impacto en el negocio.

Bruce Schneier / Dr. Dobb's Journal · 1999

Attack Trees

Artículo original sobre los árboles de ataque: objetivo de ataque como nodo raíz, rutas de ataque vinculadas mediante AND/OR, evaluables por ejemplo según coste o probabilidad de éxito.

NIST · 2022

NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1

Ancla el modelado de riesgos —incluido expresamente el threat modeling— como tarea PW.1.1 de la práctica «Produce Well-Secured Software».

Cloud Security Alliance · 2025

Agentic AI Threat Modeling Framework: MAESTRO

Framework de threat modeling de siete capas para sistemas de IA agéntica que aborda las carencias de métodos clásicos como STRIDE y PASTA.

¿Quiere establecer el threat modeling en su equipo?

Le acompañamos en la creación de un proceso de threat modeling aplicable en la práctica, desde el primer taller hasta la automatización en el pipeline. Hable con nosotros.