Dominio 4a: Modelado de amenazas
Dominio 4a: Modelado de amenazas
El Dominio 4 (Secure Software Architecture and Design) pesa 15%, el mayor del examen. Lo dividimos en dos capítulos: este cubre el modelado de amenazas y la evaluación de riesgo arquitectónico (subdominios 4.4 y 4.5); el siguiente cubre la arquitectura y el diseño seguros propiamente dichos.
El threat modeling (modelado de amenazas) es el proceso estructurado de identificar, enumerar y priorizar las amenazas a un sistema para poder diseñarlo con las defensas adecuadas. Es la actividad que convierte requisitos y arquitectura en una lista concreta de “qué puede salir mal” y “qué haremos al respecto”. El examen lo trata como una actividad de diseño: se hace lo más temprano posible, cuando cambiar el diseño todavía es barato.
💡 Tip de examen: el mejor momento para modelar amenazas es durante el diseño, antes de escribir código. Si una opción propone modelar amenazas “después del pentest” o “en producción”, es tardía. Threat modeling es proactivo y de diseño.
¿Qué es y cuándo se hace?
Modelar amenazas responde a una necesidad simple: no puedes defenderte de lo que no has anticipado. Es un ejercicio de pensar como el atacante de forma sistemática, sobre una representación del sistema (no sobre el sistema ya construido).
Se hace iterativamente: en el diseño inicial, y de nuevo cada vez que la arquitectura cambia significativamente (nuevo componente, nueva integración, nuevo flujo de datos). No es un evento único.
flowchart LR
R[Requisitos] --> TM[Modelado de amenazas]
A[Arquitectura / DFD] --> TM
TM --> C[Controles de diseño]
C --> V[Validación]
V -.iterar ante cambios.-> TMLas 4 preguntas de Shostack
Adam Shostack propuso un marco de cuatro preguntas que estructura todo ejercicio de threat modeling y que el examen usa como columna vertebral:
| # | Pregunta | Actividad |
|---|---|---|
| 1 | ¿Qué estamos construyendo? | Modelar el sistema (DFD, arquitectura, activos) |
| 2 | ¿Qué puede salir mal? | Enumerar amenazas (STRIDE, árboles de ataque) |
| 3 | ¿Qué vamos a hacer al respecto? | Definir mitigaciones y controles |
| 4 | ¿Hicimos un buen trabajo? | Validar y revisar el modelo |
💡 Tip de examen: memoriza las 4 preguntas de Shostack en orden. La primera actividad siempre es entender/modelar el sistema (dibujar el DFD). No puedes enumerar amenazas sobre algo que no has representado.
Data Flow Diagrams (DFD)
El DFD es la representación estándar del sistema para modelar amenazas. Muestra cómo fluyen los datos entre componentes y —crucialmente— dónde cruzan fronteras de confianza. STRIDE se aplica elemento por elemento sobre el DFD.
Elementos de un DFD
| Elemento | Notación clásica | Significado |
|---|---|---|
| Proceso | Círculo | Componente que transforma datos (servicio, función) |
| Data store | Dos líneas paralelas | Almacén de datos (BD, archivo, caché) |
| External entity | Rectángulo | Actor externo (usuario, sistema de terceros) |
| Data flow | Flecha | Movimiento de datos entre elementos |
| Trust boundary | Línea punteada | Frontera donde cambia el nivel de confianza |
La trust boundary es el elemento más importante para la seguridad: los datos que cruzan una frontera de confianza son no confiables y deben validarse, autenticarse o cifrarse. La mayoría de las amenazas se concentran en los cruces de frontera.
flowchart LR
subgraph Zona no confiable
U[Usuario / External entity]
end
subgraph Zona confiable
W[Proceso: Web App]
DB[(Data store: BD)]
end
U -->|HTTPS: credenciales| W
W -->|consulta parametrizada| DB
DB -->|resultados| W
W -->|respuesta| UEn el diagrama, la flecha de “Usuario” a “Web App” cruza la frontera de confianza: ahí es donde se concentran amenazas de spoofing, tampering e information disclosure. Ese cruce es donde se exige autenticación, validación de entrada y cifrado en tránsito.
💡 Tip de examen: las amenazas más relevantes ocurren donde los datos cruzan una trust boundary. Al leer un escenario de DFD, localiza las fronteras: ahí viven los controles de autenticación, validación y cifrado.
Metodologías de modelado de amenazas
No existe una sola metodología; el examen espera que sepas qué hace cada una y cuándo elegirla. La más importante, con diferencia, es STRIDE.
STRIDE
Desarrollada en Microsoft, STRIDE clasifica amenazas en seis categorías, cada una asociada a una propiedad de seguridad violada. Es un mnemónico que se aplica sistemáticamente a cada elemento del DFD.
| Amenaza | Propiedad violada | Descripción | Contramedidas típicas |
|---|---|---|---|
| Spoofing (suplantación) | Autenticación | Hacerse pasar por otro usuario o sistema | Autenticación fuerte, MFA, certificados |
| Tampering (manipulación) | Integridad | Alterar datos o código sin autorización | Firmas digitales, hashes, control de acceso, validación |
| Repudiation (repudio) | No repudio | Negar haber realizado una acción | Logging seguro, auditoría, firmas, timestamps |
| Information Disclosure (divulgación) | Confidencialidad | Exponer información a quien no debe | Cifrado, control de acceso, minimización |
| Denial of Service (denegación) | Disponibilidad | Impedir el uso legítimo del servicio | Rate limiting, redundancia, filtrado, cuotas |
| Elevation of Privilege (elevación) | Autorización | Obtener permisos superiores a los concedidos | Least privilege, validación de autorización, sandboxing |
STRIDE es la respuesta por defecto cuando la pregunta pide “identificar tipos de amenazas de forma sistemática”. Su fortaleza es la cobertura estructurada; su límite es que no prioriza (solo enumera).
💡 Tip de examen: aprende el mapeo amenaza → propiedad violada. Spoofing rompe autenticación; Tampering rompe integridad; Repudiation rompe no repudio; Information Disclosure rompe confidencialidad; DoS rompe disponibilidad; Elevation of Privilege rompe autorización. Las preguntas suelen dar un escenario y pedir la categoría STRIDE.
PASTA
PASTA (Process for Attack Simulation and Threat Analysis) es una metodología centrada en el riesgo y el negocio, de siete etapas. A diferencia de STRIDE, alinea las amenazas técnicas con el impacto de negocio y simula ataques reales.
| Etapa | Nombre | Objetivo |
|---|---|---|
| 1 | Definir objetivos | Objetivos de negocio y de seguridad |
| 2 | Definir alcance técnico | Inventariar la superficie y tecnología |
| 3 | Descomposición de la aplicación | DFD, actores, activos, entradas |
| 4 | Análisis de amenazas | Inteligencia de amenazas, escenarios |
| 5 | Análisis de vulnerabilidades | Debilidades correlacionadas con amenazas |
| 6 | Modelado de ataques | Árboles de ataque, simulación |
| 7 | Análisis de riesgo e impacto | Priorizar y definir contramedidas |
PASTA es la respuesta cuando el escenario enfatiza alinear seguridad con objetivos de negocio y una simulación de ataque rigurosa. Es más pesada que STRIDE.
DREAD (y por qué cayó en desuso)
DREAD era un modelo de scoring/priorización (no de identificación) que puntuaba cada amenaza en cinco dimensiones:
- Damage (daño potencial)
- Reproducibility (facilidad de reproducir)
- Exploitability (facilidad de explotar)
- Affected users (usuarios afectados)
- Discoverability (facilidad de descubrir)
Se sumaban o promediaban para obtener un ranking. Microsoft lo abandonó porque la puntuación era subjetiva e inconsistente: dos analistas daban valores muy distintos al mismo riesgo, y “discoverability” incentivaba la seguridad por oscuridad. Hoy se prefiere CVSS para scoring reproducible. El examen puede preguntar por qué se dejó de usar: la respuesta es subjetividad y falta de repetibilidad.
💡 Tip de examen: STRIDE identifica amenazas; DREAD (y CVSS) las puntúan. No confundas identificación con priorización. DREAD cayó por subjetivo; CVSS es hoy el estándar de scoring.
Otras metodologías
| Metodología | Enfoque | Cuándo se prefiere |
|---|---|---|
| TRIKE | Basada en riesgo, con matriz de actores-activos-acciones; genera el modelo desde los requisitos | Cuando se busca un enfoque auditable y basado en gestión de riesgo desde requisitos |
| VAST (Visual, Agile, Simple Threat) | Escalable a toda la empresa; distingue modelos de aplicación y operacionales; integra en Agile/DevOps | Grandes organizaciones que necesitan modelar a escala y de forma continua |
| OCTAVE | Riesgo organizacional (Carnegie Mellon), centrada en activos y en el negocio, no en tecnología | Evaluación de riesgo estratégico a nivel organización |
| LINDDUN | Amenazas de privacidad | Cuando el foco es la protección de datos personales |
LINDDUN merece atención porque es el STRIDE de la privacidad. Sus categorías son amenazas contra la privacidad: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Si el escenario trata de datos personales y privacidad, LINDDUN es la respuesta, no STRIDE.
💡 Tip de examen: empareja metodología con contexto. STRIDE = seguridad general por categorías; PASTA = riesgo alineado a negocio; LINDDUN = privacidad; OCTAVE = riesgo organizacional; VAST = escala empresarial/DevOps; DREAD = scoring (obsoleto).
Attack surface analysis
La superficie de ataque es el conjunto de todos los puntos por donde un atacante puede intentar entrar o extraer datos: endpoints de API, formularios, puertos abiertos, interfaces, parámetros, cuentas, dependencias. El análisis de superficie de ataque busca medirla y reducirla.
Principios de reducción de superficie de ataque:
- Deshabilitar funciones, servicios y puertos innecesarios.
- Reducir el código expuesto a entradas no confiables.
- Aplicar least privilege a los componentes.
- Cerrar interfaces de administración a redes públicas (out-of-band).
- Eliminar cuentas y credenciales por defecto.
Menos superficie significa menos que defender. Es una de las formas más efectivas de reducir riesgo en el diseño.
💡 Tip de examen: “reducir la superficie de ataque” casi siempre es una respuesta correcta cuando la pregunta busca una estrategia de diseño para bajar el riesgo. Deshabilitar lo innecesario es preferible a añadir controles sobre algo que no debería existir.
Árboles de ataque (attack trees)
Un árbol de ataque modela cómo se puede alcanzar un objetivo hostil: la raíz es la meta del atacante y las ramas son los caminos (sub-objetivos) para lograrla, combinados con nodos AND (se requieren todos) y OR (basta uno). Ayudan a razonar sobre rutas de ataque y a priorizar defensas en los caminos más viables.
flowchart TD
G[Objetivo: robar fondos de la cuenta]
G --> A[Obtener credenciales]
G --> B[Secuestrar sesión activa]
A --> A1[Phishing]
A --> A2[Fuerza bruta]
A --> A3[Fuga de BD]
B --> B1[Robo de cookie por XSS]
B --> B2[Fijación de sesión]Cada hoja representa un ataque concreto; recorrer el árbol muestra qué combinaciones llevan al objetivo y dónde colocar controles que corten múltiples ramas a la vez (por ejemplo, MFA mitiga a la vez phishing y fuerza bruta).
Kill chain y MITRE ATT&CK
Dos marcos de referencia complementan el modelado al describir cómo operan los atacantes en el mundo real:
- Cyber Kill Chain (Lockheed Martin): modela un ataque como fases secuenciales —reconocimiento, weaponization, delivery, exploitation, installation, command & control (C2), actions on objectives—. Su valor es que romper cualquier eslabón detiene el ataque; ayuda a pensar en defensa en profundidad por fase.
- MITRE ATT&CK: es una base de conocimiento de tácticas (el “por qué”, el objetivo) y técnicas (el “cómo”) reales observadas en campañas. No es lineal como la kill chain; es una matriz consultable que sirve para mapear detecciones y evaluar cobertura defensiva.
flowchart LR
R[Reconocimiento] --> W[Weaponization]
W --> D[Delivery]
D --> E[Exploitation]
E --> I[Installation]
I --> C[Command & Control]
C --> AO[Actions on Objectives]💡 Tip de examen: la kill chain es secuencial (fases de un ataque; cortar un eslabón lo detiene). MITRE ATT&CK es una matriz de tácticas y técnicas reales, no una secuencia. No los confundas.
Scoring con CVSS y risk rating de hallazgos de diseño
Una vez identificadas las amenazas, hay que priorizarlas. El estándar de la industria es CVSS (Common Vulnerability Scoring System), que produce una puntuación de 0 a 10 a partir de métricas objetivas:
- Base: características intrínsecas e invariables (vector de ataque, complejidad, privilegios requeridos, interacción del usuario, impacto en CIA).
- Temporal: cambian con el tiempo (madurez del exploit, disponibilidad de parche).
- Environmental: ajustan según el entorno concreto de la organización.
| Rango CVSS | Severidad |
|---|---|
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
CVSS resolvió el problema de subjetividad de DREAD al basarse en métricas definidas y reproducibles. Para hallazgos de diseño (no siempre vulnerabilidades concretas), el risk rating combina probabilidad × impacto: un fallo de diseño fácil de explotar y con alto impacto en datos críticos es prioridad máxima, aunque todavía no exista código.
💡 Tip de examen: riesgo = probabilidad × impacto. CVSS aporta reproducibilidad al scoring de vulnerabilidades; para riesgos de diseño se pondera probabilidad e impacto según la clasificación de los activos afectados.
4.5 Evaluación de riesgo arquitectónico y revisiones de diseño
El threat modeling alimenta la architectural risk analysis: evaluar si el diseño (no la implementación) introduce riesgos inaceptables. Los fallos de diseño (design flaws) son distintos de los bugs de código: un cifrado mal ubicado, una frontera de confianza mal definida o una autorización que se confía al cliente son defectos arquitectónicos que ninguna cantidad de código limpio corrige. Por eso se dice que aproximadamente la mitad de los defectos de seguridad son de diseño, no de implementación.
Security design review
Es una revisión estructurada del diseño por parte de expertos de seguridad, cuyo objetivo es validar la cuarta pregunta de Shostack: ¿hicimos un buen trabajo? Verifica que:
- Cada amenaza identificada tiene una mitigación de diseño.
- Se aplican los principios de diseño seguro (least privilege, defense in depth, fail secure, complete mediation, economy of mechanism).
- Las trust boundaries están bien definidas y los cruces protegidos.
- No hay confianza indebida en el cliente ni en entradas externas.
flowchart TD
TM[Modelado de amenazas] --> RR[Risk rating de hallazgos]
RR --> DR[Design review de seguridad]
DR -->|hallazgos| M[Mitigaciones de diseño]
M -->|re-evaluar| TM
DR -->|riesgo residual aceptable| AP[Aprobación de diseño]El resultado de una design review no es siempre “arreglarlo todo”: es una decisión de riesgo informada. Algunos hallazgos se mitigan, otros se aceptan formalmente (riesgo residual) por el dueño del riesgo, y otros se transfieren. Lo importante es que la decisión sea explícita y documentada.
💡 Tip de examen: los fallos de diseño no se arreglan con mejor código. Si el escenario describe un problema arquitectónico (confiar en validación del lado del cliente, frontera de confianza mal puesta), la solución es rediseñar, no parchear. Y el riesgo residual lo acepta el dueño del riesgo, no el equipo técnico por su cuenta.
Puntos clave
- El threat modeling es una actividad de diseño, se hace lo más temprano posible y de forma iterativa ante cambios de arquitectura.
- Las 4 preguntas de Shostack estructuran el proceso: qué construimos → qué puede salir mal → qué hacemos → lo hicimos bien. La primera actividad es siempre modelar el sistema (DFD).
- En el DFD, las amenazas se concentran donde los datos cruzan una trust boundary; ahí van autenticación, validación y cifrado.
- STRIDE identifica amenazas por categoría, cada una ligada a una propiedad violada (Spoofing→autenticación, Tampering→integridad, Repudiation→no repudio, Information Disclosure→confidencialidad, DoS→disponibilidad, EoP→autorización).
- PASTA alinea amenazas con el negocio (7 etapas); LINDDUN es el modelo de privacidad; OCTAVE es riesgo organizacional; VAST escala a la empresa; TRIKE parte de los requisitos.
- DREAD era scoring y cayó por subjetivo; hoy se usa CVSS (0–10, base/temporal/environmental) para puntuación reproducible.
- Attack surface analysis: medir y reducir la superficie (deshabilitar lo innecesario) es de las defensas de diseño más efectivas.
- Los árboles de ataque modelan rutas hacia el objetivo del atacante y ayudan a colocar controles que corten varias ramas.
- La kill chain es secuencial (cortar un eslabón detiene el ataque); MITRE ATT&CK es una matriz de tácticas y técnicas reales.
- Los fallos de diseño no se corrigen con mejor código: se rediseñan. La design review valida mitigaciones y el riesgo residual lo acepta formalmente el dueño del riesgo.