Threat Modeling: STRIDE, PASTA y ATT&CK-Based para Organizaciones

Threat modeling identifica amenazas antes de que se materialicen. El framework que elijas determina qué ves y qué se te escapa

Threat modeling es el proceso sistemático de identificar amenazas potenciales contra un sistema, evaluar su probabilidad e impacto, y definir contramedidas. No es una auditoría de seguridad (que mira lo que ya existe) ni un pentest (que prueba defensas activas). Es un ejercicio proactivo que se hace idealmente antes de construir o desplegar.

Existen múltiples frameworks, cada uno con un enfoque distinto. STRIDE piensa en categorías técnicas de amenaza. PASTA conecta amenazas con riesgo de negocio. ATT&CK-based parte de adversarios reales. No hay uno "mejor": depende de tu contexto, madurez y objetivo.

STRIDE: 6 categorías de amenaza

Creado por Microsoft en 1999 (Loren Kohnfelder y Praerit Garg). Es el framework más usado en desarrollo de software porque se integra naturalmente con diagramas de flujo de datos (DFD).

STRIDE es un acrónimo donde cada letra representa una categoría de amenaza:

S: Spoofing (Suplantación de identidad)

Un atacante se hace pasar por otra entidad (usuario, servicio, componente).

Elemento	Detalle
Propiedad violada	Autenticación
Ejemplo	Robo de credenciales para acceder como admin
Ejemplo técnico	Falsificación de cabecera From en email, token JWT manipulado
Contramedida	MFA, certificados mutuos (mTLS), validación de tokens

T: Tampering (Manipulación)

Modificación no autorizada de datos en tránsito, en reposo o en proceso.

Elemento	Detalle
Propiedad violada	Integridad
Ejemplo	Modificación de un pedido en la base de datos
Ejemplo técnico	SQL injection para alterar precios, MITM para modificar API responses
Contramedida	Checksums, firma digital, HMAC, validación de entrada, WAF

R: Repudiation (Repudio)

Un usuario niega haber realizado una acción y no hay forma de demostrar lo contrario.

Elemento	Detalle
Propiedad violada	No repudio
Ejemplo	Usuario niega haber autorizado una transferencia
Ejemplo técnico	Logs insuficientes, timestamps manipulables, sin audit trail
Contramedida	Logging inmutable, firmas digitales, timestamps verificables, audit trail

I: Information Disclosure (Revelación de información)

Exposición de datos a entidades no autorizadas.

Elemento	Detalle
Propiedad violada	Confidencialidad
Ejemplo	Fuga de datos de clientes por API sin autenticación
Ejemplo técnico	Error messages verbose, directory listing, IDOR, cache poisoning
Contramedida	Cifrado (TLS, AES), control de acceso, sanitización de errores

D: Denial of Service (Denegación de servicio)

Impedir el acceso legítimo a un recurso o servicio.

Elemento	Detalle
Propiedad violada	Disponibilidad
Ejemplo	DDoS contra la API de pagos
Ejemplo técnico	Flood HTTP, ReDoS, resource exhaustion, lock contention
Contramedida	Rate limiting, CDN, circuit breakers, auto-scaling, input validation

E: Elevation of Privilege (Escalada de privilegios)

Un usuario obtiene permisos superiores a los que le corresponden.

Elemento	Detalle
Propiedad violada	Autorización
Ejemplo	Usuario regular accede a panel de administración
Ejemplo técnico	IDOR para acceder a recursos de otro tenant, JWT sin validación de roles
Contramedida	Principio de mínimo privilegio, RBAC/ABAC, validación server-side

Proceso STRIDE

1. Dibujar un DFD (Data Flow Diagram) del sistema
2. Identificar trust boundaries (fronteras de confianza)
3. Para cada elemento del DFD (proceso, store, flujo, entidad externa), aplicar las 6 categorías STRIDE
4. Documentar amenazas identificadas
5. Priorizar por riesgo
6. Definir mitigaciones

PASTA: 7 fases orientadas al riesgo de negocio

PASTA (Process for Attack Simulation and Threat Analysis) fue creado por Tony UcedaVélez y Marco Morana (2012). Su diferenciador clave es que conecta el análisis técnico con los objetivos de negocio.

Fase 1: Definir objetivos de negocio

Qué protege la organización, cuáles son los requisitos regulatorios (NIS2, DORA, ENS, GDPR), cuál es el apetito de riesgo.

Entregable: documento de contexto con objetivos de negocio, requisitos de cumplimiento y activos críticos.

Fase 2: Definir el alcance técnico

Identificar componentes del sistema, dependencias, tecnologías y puntos de entrada. Diagrama de arquitectura con trust boundaries.

Entregable: diagrama de arquitectura anotado, inventario de componentes y tecnologías.

Fase 3: Descomponer la aplicación

Análisis detallado del flujo de datos, roles de usuario, mecanismos de autenticación y autorización, puntos de entrada y salida.

Entregable: DFD detallado con trust boundaries, actores y data stores.

Fase 4: Análisis de amenazas

Identificar amenazas basándose en inteligencia real: qué actores atacan tu sector, qué TTPs usan, qué vulnerabilidades explotan. Aquí es donde PASTA integra CTI.

Entregable: catálogo de amenazas relevantes con fuentes de inteligencia.

Fase 5: Análisis de vulnerabilidades

Mapear vulnerabilidades conocidas en los componentes identificados. Correlacionar con las amenazas de la fase 4. Usar datos de CVE, CISA KEV, escáneres de vulnerabilidades.

Entregable: lista de vulnerabilidades correlacionada con amenazas.

Fase 6: Modelado de ataques

Simular los ataques más probables usando árboles de ataque (attack trees). Cada árbol muestra cómo un atacante podría combinar vulnerabilidades y técnicas para alcanzar un objetivo.

Entregable: árboles de ataque con probabilidad e impacto estimado.

Fase 7: Análisis de riesgo y contramedidas

Calcular riesgo residual para cada escenario. Priorizar contramedidas por coste-beneficio. Definir plan de mitigación con responsables y plazos.

Entregable: matriz de riesgo, plan de mitigación priorizado, riesgo residual documentado.

ATT&CK-Based Threat Modeling

El enfoque ATT&CK-based no es un framework formal sino una metodología que usa MITRE ATT&CK como base para modelar amenazas basándose en adversarios reales documentados.

Proceso

1. Identificar adversarios relevantes: Usar CTI para determinar qué actores atacan tu sector, región y tipo de organización. Ejemplo: si eres una utility europea, APT28, Sandworm y Turla son relevantes.

2. Extraer TTPs de esos adversarios: Desde ATT&CK Navigator, exportar las técnicas documentadas de cada actor relevante. Superponer los heatmaps para ver las técnicas más frecuentes.

3. Evaluar cobertura defensiva: Para cada técnica relevante, ¿tienes detección? ¿Tienes prevención? ¿A qué nivel de madurez?

4. Identificar gaps: Las técnicas usadas por tus adversarios relevantes que no tienes cubiertas son tus gaps prioritarios.

5. Priorizar mitigaciones: No todas las técnicas tienen el mismo riesgo. Priorizar por: frecuencia de uso por adversarios relevantes, facilidad de explotación, impacto potencial, coste de mitigación.

Ventajas del enfoque ATT&CK-based

• Basado en amenazas reales, no teóricas
• Permite medir la cobertura defensiva objetivamente
• Se actualiza con cada nueva versión de ATT&CK
• Facilita la comunicación con el equipo CTI y SOC
• Integrable con herramientas como ATT&CK Navigator y DeTT&CT

Limitaciones

• Requiere un programa CTI maduro para identificar adversarios relevantes
• ATT&CK documenta post-compromise, no todo el espectro de amenazas
• Puede generar sesgo hacia técnicas documentadas (lo no documentado no es inexistente)

DREAD: scoring deprecado pero conocido

DREAD fue creado por Microsoft como complemento de STRIDE para puntuar amenazas. Cada categoría se puntúa de 1 a 10:

Letra	Significado	Pregunta
D	Damage	¿Cuánto daño causa?
R	Reproducibility	¿Es fácil de reproducir?
E	Exploitability	¿Es fácil de explotar?
A	Affected users	¿A cuántos usuarios afecta?
D	Discoverability	¿Es fácil de descubrir?

Puntuación total = suma / 5. Microsoft lo abandonó en 2008 porque las puntuaciones eran demasiado subjetivas (dos personas asignaban valores diferentes al mismo escenario). Aparece en certificaciones (CISSP, CEH) por razones históricas.

Comparativa de frameworks

Criterio	STRIDE	PASTA	ATT&CK-based	OCTAVE	VAST
Enfoque	Categorías técnicas	Riesgo de negocio	Adversarios reales	Riesgo organizacional	Ágil, visual
Creador	Microsoft (1999)	UcedaVélez (2012)	Comunidad MITRE	CMU/SEI (2001)	ThreatModeler
Complejidad	Baja-Media	Alta	Media	Alta	Media
Requiere CTI	No	Sí (fase 4)	Sí (core)	No	No
Mejor para	Desarrollo software	Enterprise risk	SecOps maduros	Evaluación org	DevSecOps
Output principal	Lista amenazas por DFD	Riesgo cuantificado	Gaps defensivos	Perfil de riesgo	Modelo automatizado
Integración DevOps	Alta	Baja	Media	Baja	Alta
Curva aprendizaje	Baja	Alta	Media	Alta	Media

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

Desarrollado por el SEI de Carnegie Mellon. Enfoque organizacional, no técnico. Evalúa riesgo desde la perspectiva de los activos críticos del negocio. Tres variantes: OCTAVE (completo), OCTAVE-S (simplificado para PYMEs) y OCTAVE Allegro (focalizado en activos de información).

VAST (Visual, Agile, and Simple Threat)

Comercializado por ThreatModeler. Diseñado para escalar en organizaciones grandes con múltiples equipos de desarrollo. Dos tipos de modelos: application threat models (para desarrolladores) y operational threat models (para infraestructura). Integración nativa con pipelines CI/CD.

Cuándo usar cada framework

Escenario	Framework recomendado
Diseñando una nueva aplicación web	STRIDE
Evaluando riesgo para el board/CISO	PASTA
Validando controles contra APTs de tu sector	ATT&CK-based
Evaluación de riesgo organizacional amplia	OCTAVE
Equipos DevOps con threat modeling continuo	VAST o STRIDE simplificado
Compliance (NIS2, DORA, ENS)	PASTA (conecta con riesgo de negocio)
SOC evaluando cobertura de detección	ATT&CK-based

No son mutuamente excluyentes. Una organización madura puede usar STRIDE en el ciclo de desarrollo, PASTA para evaluaciones de riesgo periódicas y ATT&CK-based para validar la cobertura del SOC.

Ejemplo práctico: aplicación web de e-commerce

Aplicamos STRIDE a una aplicación web simplificada con: frontend, API backend, base de datos, pasarela de pago externa y servicio de email.

DFD simplificado

[Usuario] ──HTTPS──► [Frontend SPA]
                          │
                     [API Gateway]
                       /      \
              [Auth Service]  [Payment Service]
                    │              │
              [User DB]    [Payment Gateway]
                                (externo)

Trust boundaries

1. Internet → Frontend (boundary exterior)
2. Frontend → API Gateway (boundary aplicación)
3. API Gateway → Payment Gateway (boundary con tercero)

Amenazas STRIDE identificadas

Boundary	Categoría	Amenaza	Prioridad
Internet → Frontend	S (Spoofing)	Phishing con dominio similar	Alta
Internet → Frontend	D (DoS)	DDoS contra frontend	Media
Frontend → API	T (Tampering)	Manipulación de precios en request	Crítica
Frontend → API	E (EoP)	IDOR para acceder a pedidos de otro usuario	Crítica
API → Auth	S (Spoofing)	Brute force de credenciales	Alta
API → Auth	R (Repudiation)	Transacciones sin audit trail	Alta
API → User DB	I (InfoDisc)	SQL injection exponiendo datos PII	Crítica
API → Payment GW	T (Tampering)	MITM modificando monto de pago	Crítica
API → Payment GW	I (InfoDisc)	Logging de datos de tarjeta	Crítica

Mitigaciones priorizadas

CRÍTICO (implementar antes de producción):
  1. Validación server-side de precios (nunca confiar en el cliente)
  2. RBAC con validación de ownership en cada endpoint
  3. Prepared statements para todas las queries
  4. TLS 1.3 con certificate pinning hacia payment gateway
  5. Nunca loguear PAN, CVV ni datos de tarjeta (PCI DSS)

ALTO (implementar en sprint siguiente):
  6. MFA para cuentas de usuario
  7. Rate limiting en login (max 5 intentos / 15 min)
  8. Audit trail inmutable para todas las transacciones
  9. WAF con ruleset OWASP CRS

MEDIO:
  10. CDN con protección DDoS
  11. Phishing detection (DMARC, domain monitoring)

Integración con el ciclo de desarrollo

Threat modeling no es un evento puntual. Se integra en el SDLC:

Fase SDLC	Actividad de threat modeling
Requisitos	Definir requisitos de seguridad basados en contexto de amenazas (PASTA fase 1-2)
Diseño	STRIDE sobre DFD de la arquitectura propuesta
Implementación	Validar que mitigaciones están implementadas
Testing	Verificar amenazas identificadas con pruebas específicas
Despliegue	ATT&CK-based para validar controles operacionales
Operación	Actualizar modelo con nuevas amenazas e incidentes

En equipos ágiles, el threat modeling se hace en el refinamiento del sprint cuando hay cambios arquitectónicos significativos (nuevo componente, nueva integración, cambio de modelo de autenticación).

Herramientas

Herramienta	Tipo	Framework	Coste
Microsoft Threat Modeling Tool	Desktop (Windows)	STRIDE	Gratuita
OWASP Threat Dragon	Web/Desktop	STRIDE, genérico	Open source
IriusRisk	SaaS	STRIDE, PASTA, custom	Comercial
ThreatModeler	SaaS	VAST	Comercial
Threagile	CLI (Go)	Genérico, code-as-model	Open source
MITRE ATT&CK Navigator	Web	ATT&CK-based	Gratuita
DeTT&CT	Python scripts	ATT&CK-based	Open source
pytm	Python library	STRIDE, DFD-as-code	Open source

OWASP Threat Dragon

Open source, multiplataforma. Permite crear DFDs interactivos, asignar amenazas STRIDE por elemento y generar informes. Integración con GitHub para versionar modelos.

Microsoft Threat Modeling Tool

Gratuita pero solo Windows. Incluye templates para Azure, Windows, aplicaciones web genéricas. Genera automáticamente amenazas STRIDE basadas en el DFD y las propiedades de cada elemento.

pytm (Threat Modeling as Code)

Define el modelo como código Python. Genera DFDs, listas de amenazas y reportes automáticamente. Ideal para equipos que prefieren code-as-documentation.

# Ejemplo conceptual pytm
from pytm import TM, Server, Datastore, Dataflow, Boundary

tm = TM("E-commerce App")
internet = Boundary("Internet")
dmz = Boundary("DMZ")

web = Server("Web Frontend")
api = Server("API Backend")
db = Datastore("User Database")

# Definir flujos, boundaries, propiedades...
# pytm genera amenazas STRIDE automáticamente
tm.process()

Recursos

• STRIDE original paper (Microsoft, Kohnfelder & Garg)
• PASTA Threat Modeling (UcedaVélez, OWASP)
• MITRE ATT&CK (framework de TTPs)
• OWASP Threat Dragon (herramienta open source)
• Threat Modeling Manifesto (principios de la comunidad)
• Shostack, Adam. "Threat Modeling: Designing for Security" (libro de referencia)
• pytm (threat modeling as code)
• DeTT&CT (ATT&CK detection coverage)