# Threat Modeling: cómo identificar amenazas antes de desarrollar

**Categoría:** Seguridad Informática · **Nivel:** Intermedio · **Lectura:** 17 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/seguridad-informatica/threat-modeling-identificar-amenazas-antes-de-desarrollar/

## Respuesta rápida

El **threat modeling** (modelado de amenazas) es el ejercicio de **pensar los riesgos de seguridad de un sistema antes de construirlo** —o al menos temprano—, para diseñarlo con las defensas ya previstas en vez de parchearlo después. Su lógica es económica: **arreglar un fallo en el diseño cuesta una fracción de lo que cuesta en producción**, cuando ya hay usuarios, datos y un ataque en curso. Es la idea del *shift-left*: mover la seguridad al principio. El threat modeling se guía por **cuatro preguntas** sencillas: **¿Qué estamos construyendo?** (entender el sistema: sus componentes, sus datos, por dónde entran y salen); **¿Qué puede salir mal?** (identificar las amenazas: qué podría atacar un adversario); **¿Qué vamos a hacer al respecto?** (decidir las defensas o mitigaciones para cada amenaza); y **¿Lo hicimos bien?** (revisar que las defensas funcionan y repetir). Para no depender solo de la imaginación, existe **STRIDE**, un método que da **seis categorías de amenaza** como lista de chequeo: **S**poofing (suplantación de identidad), **T**ampering (manipulación de datos), **R**epudiation (negar haber hecho algo), **I**nformation disclosure (fuga de información), **D**enial of service (denegación de servicio) y **E**levation of privilege (elevación de privilegios). Recorrés cada parte del sistema preguntándote si es vulnerable a cada categoría. No hace falta ser experto en seguridad: el threat modeling es sobre todo **una conversación estructurada** del equipo, y hacerlo aunque sea de forma básica supera con creces no hacerlo. Es la diferencia entre construir pensando en cómo te pueden atacar y descubrirlo cuando ya te atacaron.

## Qué es el threat modeling

El **threat modeling** es un proceso **estructurado** para identificar, antes o durante el diseño, las **amenazas de seguridad** de un sistema y decidir cómo defenderse de ellas. En vez de programar primero y preocuparse por la seguridad al final (o cuando algo falla), se dedica un rato *al principio* a preguntarse, en equipo, **qué podría salir mal y quién querría aprovecharlo**.

> **Por qué antes sale mucho más barato**
>
> Es un principio conocido en ingeniería: **cuanto más tarde se detecta un fallo, más caro es arreglarlo**. Un problema de seguridad detectado en el *diseño* se corrige cambiando un diagrama o una decisión: casi gratis. El mismo problema descubierto **en producción**, con el sistema en marcha, implica reescribir código, migrar datos, coordinar un despliegue de emergencia y, si un atacante ya lo explotó, gestionar una brecha con su coste económico y de reputación. El threat modeling aplica la filosofía *shift-left* —mover la seguridad hacia el inicio del desarrollo— porque prevenir en el diseño es órdenes de magnitud más barato que remediar después. No elimina todos los fallos, pero atrapa los grandes errores de diseño cuando aún son fáciles de cambiar.

## Las cuatro preguntas

El proceso, en su forma más difundida, se organiza alrededor de **cuatro preguntas** que cualquier equipo puede responder:

| Pregunta | Qué implica |
|---|---|
| ¿Qué estamos construyendo? | Entender el sistema: componentes, datos y por dónde entran y salen (un diagrama ayuda) |
| ¿Qué puede salir mal? | Identificar las amenazas: qué intentaría un atacante contra cada parte |
| ¿Qué vamos a hacer? | Decidir las defensas para cada amenaza, o aceptar el riesgo si es asumible |
| ¿Lo hicimos bien? | Revisar que las defensas cubren las amenazas y repetir según el sistema evoluciona |

> **Empezá por entender y dibujar el sistema**
>
> La primera pregunta es la que más se subestima y la más importante: **no se puede proteger lo que no se entiende**. Antes de imaginar ataques, hay que tener claro *qué* se está construyendo: qué componentes hay (la app, la base de datos, las APIs, los servicios externos), qué **datos** maneja y cuáles son sensibles, y cómo fluye la información —por dónde **entra** (formularios, APIs, subidas de archivos) y por dónde **sale**—. Dibujar un **diagrama de flujo de datos**, aunque sea a mano, revela las *fronteras de confianza* (dónde los datos pasan de una zona controlada a una que no lo está), que es justo donde se concentran las amenazas. Con el mapa claro, las tres preguntas siguientes casi se responden solas.

## El método STRIDE

«¿Qué puede salir mal?» es difícil de responder desde cero: uno se olvida de categorías enteras de ataque. **STRIDE** resuelve eso dando **seis categorías** de amenaza como lista de chequeo; recorrés cada parte del sistema preguntándote si es vulnerable a cada una:

| Letra | Amenaza | Qué es |
|---|---|---|
| S | Spoofing (suplantación) | Hacerse pasar por otro usuario o sistema |
| T | Tampering (manipulación) | Alterar datos o código sin autorización |
| R | Repudiation (repudio) | Negar haber hecho una acción sin que quede registro |
| I | Information disclosure (fuga) | Exponer información confidencial |
| D | Denial of service (denegación) | Dejar el sistema inoperativo |
| E | Elevation of privilege (elevación) | Conseguir más permisos de los que corresponden |

> **Atención**
>
> El valor de STRIDE es que **te obliga a considerar tipos de ataque en los que no habrías pensado**. Sin un método, un equipo tiende a fijarse solo en las amenazas que ya conoce y a olvidar familias enteras. Con STRIDE, tomás cada elemento del diagrama —cada componente, cada flujo de datos, cada frontera— y lo pasás por las seis letras: «¿Alguien podría *suplantar* a este usuario? ¿Podría *manipular* estos datos en tránsito? ¿Podría *escalar* sus privilegios aquí?». Muchas respuestas serán «no aplica», pero la disciplina de preguntarse las seis en cada punto es lo que atrapa el agujero que se te habría escapado. No es la única metodología —hay otras—, pero es la más conocida y una excelente forma de empezar sin ser experto.

## Errores frecuentes

- **Dejar la seguridad para el final.** Pensar las amenazas después de construir hace que arreglarlas sea carísimo; el objetivo es hacerlo antes.
- **Saltarse entender el sistema.** No se puede modelar lo que no se comprende; empezar dibujando el flujo de datos.
- **Confiar solo en la imaginación.** Sin un método como STRIDE se olvidan categorías enteras de amenaza.
- **Identificar amenazas y no decidir defensas.** Una lista de riesgos sin mitigaciones ni decisiones no protege de nada.
- **Hacerlo una vez y nunca más.** El sistema evoluciona; el modelo de amenazas hay que revisarlo cuando cambia.
- **Creer que hace falta ser experto.** Es una conversación estructurada del equipo; hacerlo básico ya aporta muchísimo.
- **Intentar cubrir todo con la misma prioridad.** Hay que priorizar por impacto y probabilidad; no todo riesgo merece la misma inversión.

## Preguntas frecuentes

**¿Qué es el threat modeling?**
El threat modeling, o modelado de amenazas, es un proceso estructurado para identificar y analizar las amenazas de seguridad de un sistema, idealmente antes de construirlo o al menos en las fases tempranas de su diseño, con el fin de decidir cómo defenderse de ellas e incorporar esas defensas desde el principio en lugar de añadirlas apresuradamente al final o cuando ya se ha producido un problema. En esencia, consiste en dedicar tiempo, normalmente en equipo, a pensar de forma sistemática qué podría salir mal desde el punto de vista de la seguridad, quién podría querer atacar el sistema y cómo, y qué se puede hacer para prevenirlo. En lugar de programar primero y preocuparse por la seguridad después, el threat modeling invierte el orden y sitúa la reflexión sobre las amenazas en el momento del diseño, cuando todavía es fácil y barato tomar decisiones que eviten problemas. Se trata de un enfoque proactivo y preventivo, frente al enfoque reactivo de esperar a que aparezcan los fallos o los ataques para corregirlos. El proceso suele organizarse en torno a un conjunto de preguntas guía que ayudan a estructurar la reflexión, y puede apoyarse en metodologías que aportan listas de categorías de amenazas para no olvidar tipos de ataque importantes. Un aspecto clave es que el threat modeling no requiere necesariamente ser un experto en seguridad, ya que en buena medida es una conversación estructurada del equipo que construye el sistema, en la que se combina el conocimiento del propio sistema con un marco que ayuda a pensar en las amenazas; hacerlo aunque sea de forma básica supera con mucho no hacerlo en absoluto. Tampoco pretende eliminar todos los fallos posibles, sino identificar y abordar los riesgos más relevantes, especialmente los grandes errores de diseño, cuando aún son fáciles de corregir. En definitiva, el threat modeling es una práctica que ayuda a construir sistemas más seguros por diseño, anticipando las amenazas en lugar de descubrirlas cuando ya han sido explotadas, y forma parte de una cultura de seguridad que integra la reflexión sobre los riesgos en el propio proceso de desarrollo.

**¿Por qué conviene pensar la seguridad antes de programar?**
Conviene pensar la seguridad antes de programar, o al menos muy temprano en el diseño, principalmente por una razón económica y práctica bien conocida en ingeniería de software: cuanto más tarde se detecta y corrige un fallo, mucho más caro y complicado resulta arreglarlo. Un problema de seguridad identificado durante la fase de diseño se puede corregir simplemente cambiando una decisión, ajustando un diagrama o replanteando cómo se estructura una parte del sistema, con un coste mínimo, porque aún no se ha escrito el código ni se ha desplegado nada. El mismo problema, si no se detecta hasta que el sistema está en producción y funcionando, implica un coste muchísimo mayor: hay que reescribir código ya hecho, posiblemente migrar datos, coordinar un despliegue de corrección a menudo urgente, probar que el arreglo no rompe otras cosas, y todo ello con el sistema en marcha y con usuarios reales dependiendo de él. Y si además un atacante ya ha explotado ese fallo antes de que se corrigiera, a los costes técnicos se suman los de gestionar una brecha de seguridad, que pueden incluir la pérdida o el robo de datos, el daño a la reputación, las consecuencias legales y regulatorias, y la pérdida de confianza de los usuarios. Esta diferencia de coste, que crece de forma acusada a medida que avanza el ciclo de vida del desarrollo, es la que justifica la filosofía de mover la seguridad hacia el principio del proceso, un enfoque conocido como desplazar a la izquierda, en referencia a llevar las actividades de seguridad hacia las fases iniciales. El threat modeling es una de las prácticas centrales de ese enfoque, porque permite anticipar las amenazas en el diseño y construir el sistema con las defensas ya previstas, en lugar de descubrir los problemas cuando ya son caros de resolver. Además de lo económico, pensar la seguridad desde el principio conduce a diseños intrínsecamente más robustos, en los que la protección está integrada en la arquitectura en vez de añadida como un parche, lo que suele resultar en soluciones más limpias, coherentes y eficaces. Por todo ello, invertir un tiempo relativamente pequeño al inicio en reflexionar sobre las amenazas y las defensas produce un retorno muy alto, evitando costes y riesgos mucho mayores más adelante.

**¿Cuáles son las cuatro preguntas del threat modeling?**
El threat modeling, en su forma más difundida y accesible, se organiza en torno a cuatro preguntas sencillas que guían todo el proceso y que cualquier equipo puede responder para estructurar su reflexión sobre la seguridad. La primera pregunta es qué estamos construyendo, y consiste en entender bien el sistema antes de intentar protegerlo, identificando sus componentes, como las aplicaciones, las bases de datos, las interfaces de programación y los servicios externos, los datos que maneja y cuáles de ellos son sensibles, y sobre todo cómo fluye la información, es decir, por dónde entran los datos, mediante formularios, interfaces o subidas de archivos, y por dónde salen; esta pregunta se apoya a menudo en dibujar un diagrama de flujo de datos, que revela las fronteras de confianza, aquellos puntos donde los datos pasan de una zona controlada a otra que no lo está, y que son precisamente donde se concentran las amenazas. La segunda pregunta es qué puede salir mal, y consiste en identificar las amenazas, es decir, en imaginar qué podría intentar un atacante contra cada parte del sistema; para responderla de forma completa y no olvidar categorías enteras de ataque, es muy útil apoyarse en una metodología que aporte una lista de tipos de amenaza a considerar. La tercera pregunta es qué vamos a hacer al respecto, y consiste en decidir, para cada amenaza identificada, qué defensa o mitigación se va a aplicar, o bien aceptar conscientemente el riesgo si se considera asumible; esta pregunta es la que convierte el análisis en acción, ya que de nada sirve identificar amenazas si luego no se decide cómo abordarlas. La cuarta pregunta es si lo hicimos bien, y consiste en revisar que las defensas propuestas cubren efectivamente las amenazas identificadas, comprobar que el modelo es adecuado y repetir el ejercicio a medida que el sistema evoluciona, ya que el modelado de amenazas no es algo que se hace una vez y se olvida, sino un proceso que debe actualizarse cuando el sistema cambia. Estas cuatro preguntas, entender el sistema, identificar las amenazas, decidir las defensas y revisar el resultado, forman un ciclo que estructura de manera clara y práctica el modelado de amenazas, y siguiéndolas incluso de forma básica se obtiene un gran beneficio en la seguridad del sistema.

**¿Qué es STRIDE?**
STRIDE es una metodología o modelo muy conocido para identificar amenazas de seguridad, que proporciona seis categorías de amenaza a modo de lista de comprobación, ayudando así a responder de forma sistemática a la pregunta de qué puede salir mal en un sistema. Su nombre es un acrónimo formado por las iniciales en inglés de esas seis categorías. La primera es la suplantación de identidad, que consiste en que un atacante se haga pasar por otro usuario o por otro sistema para obtener acceso o engañar. La segunda es la manipulación, que consiste en alterar datos o código sin autorización, ya sea información almacenada o datos en tránsito. La tercera es el repudio, que se refiere a la posibilidad de que alguien niegue haber realizado una acción cuando no existe un registro fiable que lo demuestre, lo que apunta a la necesidad de trazabilidad y registros de auditoría. La cuarta es la revelación de información, que consiste en exponer datos confidenciales a quien no debería tener acceso a ellos. La quinta es la denegación de servicio, que busca dejar el sistema inoperativo o inaccesible para sus usuarios legítimos, agotando recursos o interrumpiendo su funcionamiento. Y la sexta es la elevación de privilegios, que consiste en conseguir más permisos de los que corresponden, por ejemplo pasando de un usuario normal a un administrador. La forma de usar STRIDE es recorrer cada parte del sistema, apoyándose en el diagrama del flujo de datos, y para cada componente, flujo o frontera de confianza preguntarse si es vulnerable a cada una de las seis categorías, es decir, si alguien podría suplantar, manipular, repudiar, revelar información, denegar el servicio o elevar privilegios en ese punto concreto. El valor de STRIDE reside precisamente en que actúa como una defensa contra la falta de imaginación, obligando a considerar tipos de ataque en los que quizá no se habría pensado espontáneamente, ya que sin un método los equipos tienden a fijarse solo en las amenazas que ya conocen y a pasar por alto familias enteras de riesgos. Aunque muchas respuestas serán que una categoría no aplica a un punto determinado, la disciplina de plantearse las seis en cada elemento es lo que permite detectar el agujero que de otro modo se habría escapado. STRIDE no es la única metodología de modelado de amenazas, ya que existen otras aproximaciones, pero es la más difundida y una excelente forma de empezar sin necesidad de ser un experto en seguridad.

**¿Necesito ser experto en seguridad para hacer threat modeling?**
No es necesario ser un experto en seguridad para hacer threat modeling, y este es uno de los aspectos más importantes y liberadores de esta práctica, porque en buena medida el modelado de amenazas es una conversación estructurada del equipo que construye el sistema más que una tarea reservada a especialistas. Quienes desarrollan y diseñan un sistema son, de hecho, quienes mejor lo conocen, y ese conocimiento del funcionamiento, los componentes, los datos y los flujos es la materia prima fundamental del threat modeling; combinándolo con un marco que ayude a pensar en las amenazas, como las cuatro preguntas guía y una metodología con categorías de amenaza, un equipo sin formación especializada en seguridad puede realizar un modelado de amenazas valioso. La clave está en que las metodologías proporcionan la estructura y las listas de comprobación que suplen la falta de experiencia, guiando la reflexión para que no se olviden aspectos importantes; por ejemplo, recorrer cada parte del sistema preguntándose por las distintas categorías de amenaza no exige ser un experto, sino aplicar con disciplina un marco establecido. Además, es mucho mejor hacer un threat modeling básico, aunque sea imperfecto, que no hacer ninguno, porque incluso un ejercicio sencillo suele revelar riesgos evidentes y errores de diseño que de otro modo pasarían desapercibidos hasta ser explotados. Dicho esto, la experiencia en seguridad sí aporta valor y mejora la calidad del modelado, ya que un experto conoce más tipos de ataque, sabe estimar mejor la probabilidad y el impacto de las amenazas, y puede proponer defensas más adecuadas, por lo que en sistemas críticos o complejos es recomendable involucrar a personas con conocimientos de seguridad o incluso a especialistas. Pero eso no debe ser una excusa para no empezar: el enfoque sano es que el threat modeling se convierta en una práctica habitual del equipo, integrada en el proceso de diseño, en la que todos participen aportando su conocimiento del sistema y aplicando los marcos disponibles, y en la que se recurra a mayor experticia cuando el riesgo lo justifique. Existen además recursos, guías, herramientas y ejemplos que facilitan enormemente empezar, así como plantillas y listas de comprobación pensadas para no expertos. En resumen, el threat modeling está al alcance de cualquier equipo que construya software, no requiere ser experto para aportar un gran beneficio, y lo importante es incorporarlo como una conversación estructurada y periódica sobre la seguridad desde las fases tempranas del desarrollo.

**¿Cada cuánto se hace el threat modeling?**
El threat modeling no es una actividad que se realice una sola vez y se dé por terminada, sino un proceso que conviene llevar a cabo en momentos clave y repetir a medida que el sistema evoluciona, ya que las amenazas y el propio sistema cambian con el tiempo. El momento más importante para hacer threat modeling es al principio, durante el diseño de un sistema nuevo o de una funcionalidad nueva importante, porque es cuando resulta más barato y eficaz incorporar las defensas y cuando las decisiones de arquitectura aún están abiertas; hacerlo en esta fase temprana es precisamente lo que permite construir con la seguridad pensada desde el diseño en lugar de parchearla después. Sin embargo, un sistema no permanece estático, sino que evoluciona añadiendo funcionalidades, integrando nuevos componentes o servicios, cambiando cómo fluyen los datos o modificando su arquitectura, y cada uno de esos cambios significativos puede introducir nuevas amenazas o alterar las existentes, por lo que conviene revisar y actualizar el modelo de amenazas cuando se producen cambios relevantes en el diseño o en el alcance del sistema. También es recomendable revisar el threat modeling cuando cambia el contexto de seguridad, por ejemplo si aparecen nuevos tipos de ataque relevantes para el sistema, si cambian los datos sensibles que maneja o si se modifica el perfil de los posibles atacantes. En equipos que trabajan de forma iterativa e incremental, una buena práctica es integrar el modelado de amenazas de manera ligera y continua en el propio proceso de desarrollo, dedicando pequeños ejercicios de reflexión sobre las amenazas al planificar cada nueva funcionalidad significativa, en lugar de reservarlo para grandes sesiones aisladas y esporádicas. De este modo, el threat modeling se convierte en una actividad viva y recurrente, alineada con el ritmo de evolución del sistema, más que en un documento que se elabora una vez y queda obsoleto. La cuarta pregunta guía del proceso, la de si se hizo bien, incluye precisamente esta idea de revisión y repetición. En resumen, el threat modeling se hace al inicio del diseño de algo nuevo, se repite ante cambios importantes en el sistema o en las amenazas, y en entornos ágiles se incorpora de forma continua y proporcionada al desarrollo, garantizando que el análisis de amenazas siga siendo pertinente y actualizado a lo largo de toda la vida del sistema.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Seguridad informática](https://underc0de.org/foro/seguridad-informatica/). Diseño seguro.
2. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Desarrollo seguro.

### Documentación oficial

1. **OWASP.** [Threat Modeling](https://owasp.org/www-community/Threat_Modeling). Concepto y proceso.
2. **Microsoft.** [STRIDE](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats). Las categorías de amenaza de STRIDE.
3. **Threat Modeling Manifesto.** [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/). Principios y valores.
4. **OWASP.** [Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). Guía práctica.

## Guías relacionadas

- [Ingeniería social](../ingenieria-social-tecnicas-y-como-prevenirlas/index.md)
- [Análisis con OpenVAS](../como-realizar-un-analisis-de-vulnerabilidades-con-openvas/index.md)
- [Encabezados de seguridad HTTP](../como-configurar-encabezados-de-seguridad-http/index.md)
- [Seguridad de APIs REST](../../hacking/seguridad-de-apis-rest-autenticacion-permisos-y-validaciones/index.md)
- [Índice de Seguridad Informática](../index.md)