Modelado de amenazas
Cómo analizar un sistema antes de construirlo (o mientras evoluciona) para descubrir qué puede salir mal y decidir qué hacer al respecto.
Imagina que en Citas alguien propone guardar los documentos que suben los pacientes en un almacén de objetos (un bucket, como S3) y servirlos con un enlace público “porque es más rápido”. Detectar ese problema en una reunión de diseño cuesta diez minutos y un cambio en el diagrama. Descubrirlo después, cuando un investigador encuentra recetas médicas indexadas en un buscador, significa una notificación de brecha, un incidente y una reescritura con prisas. El modelado de amenazasModelado de amenazasAnálisis estructurado de una representación del sistema para descubrir qué puede salir mal y decidir qué hacer antes de que ocurra. existe para llevar esa conversación al momento en que todavía es barata.
Qué es#
Modelar amenazas es analizar una representación del sistema para encontrar problemas de seguridad y privacidad antes de que se conviertan en incidentes. No es un pentest (que ataca algo que ya existe) ni una auditoría de cumplimiento (que comprueba controles contra una lista): es un ejercicio de diseño, hecho por quienes construyen el sistema, que produce decisiones concretas.
La idea clave es que se trabaja sobre un modelo: un diagrama, normalmente un diagrama de flujo de datosDiagrama de flujo de datosDiagrama con entidades externas, procesos, almacenes y flujos de datos con dirección; es el modelo habitual sobre el que se buscan amenazas., lo bastante simple para razonar sobre él y lo bastante fiel para que las conclusiones sirvan. Si el modelo no se parece al sistema real, las amenazas que encuentres tampoco.
Las cuatro preguntas#
Adam Shostack resumió el proceso en cuatro preguntas, que el Threat Modeling Manifesto adoptó como núcleo de cualquier metodología:
- ¿En qué estamos trabajando? Se construye el modelo: componentes, datos, flujos y límites de confianzaLímite de confianzaFrontera donde cambia el nivel de confianza o de privilegio; todo lo que la cruza debe autenticarse, autorizarse, validarse y, normalmente, cifrarse..
- ¿Qué puede salir mal? Se buscan amenazas de forma sistemática, por ejemplo con STRIDE o con árboles de ataque.
- ¿Qué vamos a hacer al respecto? Cada amenaza recibe una respuesta: mitigar, eliminar la funcionalidad, transferir el riesgo o aceptarlo de forma explícita.
- ¿Lo hicimos suficientemente bien? Se comprueba que las mitigaciones existen, funcionan y que el modelo sigue reflejando el sistema.
Paso 1 de 5¿En qué trabajamos?
Primero se describe el sistema: un diagrama de flujo de datos con sus activos y límites de confianza. Sin ese mapa no hay forma de razonar sobre amenazas.
Fíjate en la última pregunta: obliga a cerrar el ciclo. Un modelo sin validación es una lista de buenas intenciones; uno que no se revisa cuando el sistema cambia se queda obsoleto en el siguiente sprint.
Cuándo hacerlo#
El mejor momento es durante el diseño, cuando cambiar una decisión cuesta poco. Pero no es un evento único:
-
Al diseñar un sistema o una funcionalidad nueva
Un modelo completo, aunque sea en una pizarra: diagrama, amenazas principales y decisiones.
-
Ante cambios significativos
Un flujo de datos nuevo, una integración con un tercero, cambios en autenticación o autorización, un nuevo tipo de dato sensible, un cambio de modelo multi-tenant o de cuentas de la nube. Son los cambios que mueven límites de confianza.
-
De forma continua
En el refinamiento de cada historia, una pregunta corta: “¿esto cambia el diagrama?”. Si la respuesta es sí, se actualiza el modelo y se repite el ciclo solo para la parte afectada.
Quién participa#
El modelado de amenazas no es trabajo exclusivo del equipo de seguridad. La sesión funciona mejor con:
- Quienes construyen el sistema (desarrollo y arquitectura): son los que saben cómo funciona de verdad.
- Un facilitador, a menudo un security champion o alguien de seguridad, que guía las preguntas y evita que la sesión derive.
- Producto, para decidir qué riesgos son aceptables para el negocio.
- Operaciones / plataforma, que conocen el despliegue real: cuentas, redes, pipelines, accesos de emergencia.
Qué se entrega#
Un buen modelo deja artefactos que alguien puede revisar dentro de seis meses:
| Artefacto | Contenido | En Citas |
|---|---|---|
| Diagrama (DFD) | Elementos, flujos y límites de confianza | Paciente → borde → API → base de datos / almacén de objetos |
| Supuestos | Lo que se da por cierto y no se analiza | “El proveedor de nube opera correctamente el hipervisor” |
| Lista de amenazas | Cada amenaza redactada de forma concreta | “Un paciente lee citas de otra clínica cambiando el ID” |
| Mitigaciones | Control, dueño y ticket | “Filtro por clinic_id en cada consulta, SEC-142” |
| Riesgos aceptados | Qué no se mitiga, por qué y quién lo firma | “Sin protección DDoS avanzada gestionada en v1” |
Una amenaza bien registrada se puede guardar junto al código, por ejemplo en YAML:
- id: TM-007 stride: [I] elemento: 'Flujo API → RDS' amenaza: > Un usuario autenticado de una clínica puede consultar citas de otra clínica manipulando el identificador en la URL (IDOR), lo que expone PII de pacientes. mitigacion: 'Política de autorización por tenant en la capa de datos + tests' dueño: equipo-api ticket: SEC-142 estado: mitigadaMetodologías#
No hay una única forma correcta; las metodologías son lentes distintas sobre el mismo problema:
| Metodología | Enfoque | Cuándo usarla |
|---|---|---|
| STRIDE | Seis categorías de amenaza aplicadas a cada elemento del DFD | El punto de partida por defecto para sistemas de software |
| PASTA | Proceso de 7 etapas centrado en el riesgo de negocio y la simulación de ataques | Organizaciones que quieren alinear amenazas con impacto de negocio |
| LINDDUN | Amenazas de privacidad (vinculación, identificación, divulgación, falta de transparencia…) | Sistemas con datos personales; en Citas, imprescindible por la PII |
| Árboles de ataque | Descomponer un objetivo del atacante en caminos alternativos | Analizar en profundidad un objetivo concreto (“robar la base de datos”) |
| Kill chain / ATT&CK | Cómo progresan los ataques reales, táctica a táctica | Complemento: validar detección y respuesta, no sustituye al diseño |
Para un equipo que empieza, STRIDE sobre un DFD cubre la mayor parte del valor. MITRE ATT&CK entra después, para preguntarse “si esto falla, ¿lo veríamos?”.
Priorizar amenazas#
Una sesión puede producir decenas de amenazas, así que hay que ordenarlas. Lo más útil suele ser una matriz sencilla de probabilidad × impacto con tres niveles (bajo, medio, alto), discutida en grupo.
Herramientas#
Puedes empezar con una pizarra. Cuando el modelo tenga que vivir en el repositorio, estas herramientas ayudan:
- OWASP Threat Dragon: diagramas DFD con sugerencias STRIDE; web o escritorio, multiplataforma.
- Microsoft Threat Modeling Tool: genera amenazas automáticamente a partir del diagrama; solo para Windows.
- threat-composer (AWS Labs): se centra en redactar amenazas bien formadas con una gramática guiada, y en vincularlas a mitigaciones y supuestos.
- pytm: el modelo como código Python; genera el DFD y un informe de amenazas, ideal para revisarlo en pull requests.
from pytm import TM, Actor, Boundary, Dataflow, Datastore, Server
tm = TM("Citas")tm.description = "SaaS de reserva de citas para clínicas"
internet = Boundary("Internet")vpc = Boundary("Red privada")datos = Boundary("Datos (subred aislada)")
paciente = Actor("Paciente")paciente.inBoundary = internet
api = Server("API Citas (contenedores gestionados)")api.inBoundary = vpc
rds = Datastore("PostgreSQL gestionado")rds.inBoundary = datos
Dataflow(paciente, api, "Reserva (HTTPS + JWT)")Dataflow(api, rds, "Consulta SQL (TLS)")
tm.process()python3 threat-model/citas.py --dfd | dot -Tpng -o dfd.pngpython3 threat-model/citas.py --report docs/plantilla.md > informe.mdErrores comunes#
Tu turno
Modela una app de 3 capas que ya hayas construido
Empieza por la primera pregunta. No busques amenazas todavía: describe el sistema.
- ¿Qué datos maneja y cuáles son sensibles (PII, credenciales, datos de pago)?
- ¿Quién interactúa con él desde fuera (usuarios, administradores, terceros, pipelines de CI/CD)?
- ¿Cuáles son sus procesos (frontend, API, workers) y sus almacenes (bases de datos, buckets, colas)?
- ¿Dónde cambia el nivel de confianza?
Sistema: ...Datos sensibles: ...Entidades externas: ...Procesos: ...Almacenes: ...Límites: ...Supuestos: ...Con esto tienes la base para el DFD y STRIDE. El caso práctico de app de 3 capas recorre el proceso completo con Citas como referencia.
Reto
Tu equipo quiere priorizar las amenazas del modelo con su puntuación CVSS. ¿Qué le dirías?
▸Mostrar solución
Que CVSS está pensado para vulnerabilidades concretas en software existente (con vector de ataque, complejidad, privilegios requeridos…). Una amenaza de diseño todavía no es una vulnerabilidad explotable y no encaja en ese modelo. Es mejor una matriz de probabilidad × impacto discutida en grupo y anclada en el contexto del negocio.
Reto
Citas añade un módulo de pagos con un proveedor externo. ¿Hay que rehacer el modelo de amenazas?
▸Mostrar solución
No entero, pero sí volver al ciclo: es un cambio significativo porque añade una entidad externa, flujos que cruzan límites de confianza y un tipo de dato nuevo. Se actualiza el DFD, se aplica STRIDE a los elementos y flujos nuevos, se deciden mitigaciones y se valida.
En resumen#
- Modelar amenazas es un ejercicio de diseño: encontrar problemas cuando arreglarlos todavía es barato.
- Las cuatro preguntas: ¿en qué trabajamos?, ¿qué puede salir mal?, ¿qué vamos a hacer?, ¿lo hicimos bien?
- Se hace al diseñar, ante cambios que mueven límites de confianza y de forma continua.
- Entregables: DFD, supuestos, amenazas concretas, mitigaciones con dueño y riesgos aceptados.
- STRIDE sobre un DFD es el punto de partida; LINDDUN si hay datos personales; ATT&CK como complemento.
- Prioriza con probabilidad × impacto; evita DREAD y no uses CVSS para amenazas de diseño.
Referencias#
- Threat Modeling Manifesto
- Adam Shostack, Threat Modeling: Designing for Security (Wiley, 2014)
- OWASP Threat Modeling Cheat Sheet
- AWS Security Blog: How to approach threat modeling
- threat-composer (AWS Labs)
- OWASP pytm · OWASP Threat Dragon
- LINDDUN: privacy threat modeling