Blog - Jorge Rodriguez Flores
← Volver al blog

Threat Modeling: Cómo Identificar y Mitigar Amenazas de Seguridad en el Diseño

threat modeling seguridad stride dread devSecOps arquitectura-segura
Compartir: X / Twitter LinkedIn
Threat Modeling: Cómo Identificar y Mitigar Amenazas de Seguridad en el Diseño

El Threat Modeling (modelado de amenazas) es una práctica de seguridad proactiva que consiste en identificar, clasificar y mitigar posibles vulnerabilidades y vectores de ataque antes de que el software llegue a producción. En lugar de reaccionar a incidentes de seguridad, el threat modeling te permite anticiparlos desde la fase de diseño, reduciendo drásticamente el costo de remediarlos. En este artículo exploraremos sus fundamentos, metodologías principales y cómo integrarlo en equipos modernos de desarrollo.

¿Por qué es importante el Threat Modeling?

Según el informe Cost of a Data Breach 2024 de IBM, el costo promedio global de una brecha de seguridad superó los 4,88 millones de dólares. La mayoría de estas brechas tienen raíces en decisiones de diseño inseguras que podrían haberse evitado con un análisis temprano de amenazas.

El principio es simple: cuanto más tarde se detecta una vulnerabilidad, más caro es corregirla. Una falla detectada en la fase de diseño puede costar horas de trabajo; la misma falla descubierta en producción puede costar meses de remediación, pérdida de reputación y sanciones regulatorias.

El threat modeling aporta valor en múltiples dimensiones:

  • Visibilidad: Crea un mapa compartido de la superficie de ataque del sistema entre desarrollo, arquitectura y seguridad.
  • Priorización: Permite enfocar recursos limitados en las amenazas de mayor impacto real.
  • Documentación: Genera evidencia de las decisiones de seguridad tomadas, útil para auditorías y cumplimiento.
  • Cultura: Fomenta el pensamiento adversarial en equipos de desarrollo desde etapas tempranas.

El Proceso de Threat Modeling en 4 Pasos

Independientemente de la metodología que se use, el proceso de threat modeling sigue cuatro preguntas fundamentales, popularizadas por Adam Shostack (autor de Threat Modeling: Designing for Security):

  1. ¿Qué estamos construyendo? — Modelar el sistema: diagramas de flujo de datos, componentes, fronteras de confianza.
  2. ¿Qué puede salir mal? — Identificar amenazas usando metodologías como STRIDE o PASTA.
  3. ¿Qué vamos a hacer al respecto? — Definir controles, mitigaciones y aceptación de riesgos.
  4. ¿Lo hicimos bien? — Validar que las mitigaciones son correctas y revisar el modelo periódicamente.

Paso 1: Modelar el sistema con DFDs

El punto de partida es un Diagrama de Flujo de Datos (DFD) que representa cómo la información se mueve a través del sistema. Los elementos clave son:

  • Procesos: Componentes que transforman datos (servicios, funciones, microservicios). Se representan como círculos.
  • Almacenes de datos: Donde los datos persisten (bases de datos, archivos, colas). Se representan como líneas paralelas.
  • Entidades externas: Actores fuera del sistema (usuarios, APIs de terceros, sistemas externos). Se representan como rectángulos.
  • Flujos de datos: Flechas que indican la dirección del movimiento de datos.
  • Fronteras de confianza: Límites entre zonas con diferentes niveles de confianza (internet vs. red interna, usuario vs. administrador). Se representan como líneas punteadas.
Ejemplo — Sistema de autenticación:

[Usuario] ──── HTTPS ────→ (API Gateway) ─── TLS ───→ (Auth Service)
                               │                            │
                         [Frontera de confianza]      [Token Store]
                               │                            │
                          (App Backend) ←─── JWT ──────────┘
                               │
                          [Base de Datos]

Herramientas para crear DFDs en threat modeling:

  • Microsoft Threat Modeling Tool: Gratuita, con plantillas preconfiguradas y análisis STRIDE automático.
  • OWASP Threat Dragon: Open source, basada en web, con soporte para DFDs y generación de reportes.
  • IriusRisk: Plataforma empresarial con integración a Jira, Azure DevOps y pipelines CI/CD.
  • draw.io / Mermaid: Para equipos que prefieren herramientas de diagramación general.

Metodología STRIDE

STRIDE es la metodología de threat modeling más extendida. Desarrollada por Microsoft en 1999, clasifica las amenazas en seis categorías, cada una correspondiendo a una propiedad de seguridad que viola:

LetraAmenazaPropiedad violadaEjemplo
SSpoofing (Suplantación)AutenticaciónAtacante que finge ser otro usuario o servicio
TTampering (Manipulación)IntegridadModificación de datos en tránsito o en reposo
RRepudiation (Repudio)No repudioUsuario que niega haber realizado una acción sin logs
IInformation Disclosure (Divulgación)ConfidencialidadExposición de datos sensibles en logs o errores
DDenial of Service (Denegación de servicio)DisponibilidadSobrecarga del sistema para hacerlo inaccesible
EElevation of Privilege (Escalada de privilegios)AutorizaciónUsuario sin permisos accede a funciones de admin

Aplicando STRIDE a cada elemento del DFD

La clave de STRIDE es aplicarlo sistemáticamente a cada elemento del diagrama. No todos los elementos son vulnerables a todas las categorías:

Elemento del DFD     │ S │ T │ R │ I │ D │ E
─────────────────────┼───┼───┼───┼───┼───┼───
Procesos             │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✓
Flujos de datos      │   │ ✓ │   │ ✓ │ ✓ │  
Almacenes de datos   │   │ ✓ │ ✓ │ ✓ │ ✓ │  
Entidades externas   │ ✓ │   │ ✓ │   │   │

Ejemplo práctico aplicando STRIDE a un endpoint de login:

# Amenazas identificadas — Endpoint POST /api/auth/login

## S — Spoofing
- Atacante que reutiliza tokens de sesión robados (session hijacking)
- Suplantación de identidad mediante credential stuffing con listas filtradas
Mitigación: MFA, detección de anomalías en IPs, rate limiting

## T — Tampering  
- Modificación del payload JWT si el secret es débil o está expuesto
- Man-in-the-Middle si TLS no está correctamente configurado
Mitigación: Algoritmos fuertes (RS256), HSTS, certificate pinning

## R — Repudiation
- Sin logs de intentos de login no hay trazabilidad de ataques
Mitigación: Logging inmutable de auth events (IP, timestamp, resultado)

## I — Information Disclosure
- Mensajes de error que distinguen "usuario no existe" vs "contraseña incorrecta"
- Stack traces en respuestas de error en producción
Mitigación: Mensajes de error genéricos, no revelar detalles de infraestructura

## D — Denial of Service
- Brute force ilimitado que satura el servicio de autenticación
- Ataques de account lockout para denegar acceso a usuarios legítimos
Mitigación: Rate limiting, CAPTCHA progresivo, circuit breakers

## E — Elevation of Privilege
- JWT con claims manipulados si la validación es incompleta
- Falta de validación del campo "role" permite escalada a admin
Mitigación: Validación estricta de todos los claims, verificación server-side de permisos

Metodología DREAD: Priorización de Riesgos

Una vez identificadas las amenazas con STRIDE, es necesario priorizarlas. DREAD es un sistema de puntuación que asigna un valor del 1 al 10 a cada dimensión:

  • D — Damage Potential: ¿Cuánto daño puede causar si se explota? (1=mínimo, 10=catastrófico)
  • R — Reproducibility: ¿Qué tan fácil es reproducir el ataque? (1=muy difícil, 10=trivial)
  • E — Exploitability: ¿Qué nivel de habilidad requiere? (1=experto, 10=sin conocimientos)
  • A — Affected Users: ¿Cuántos usuarios se ven afectados? (1=uno, 10=todos)
  • D — Discoverability: ¿Qué tan fácil es descubrir la vulnerabilidad? (1=imposible, 10=pública)

El score DREAD es el promedio: (D + R + E + A + D) / 5

# Script para calcular y priorizar amenazas DREAD
threats = [
    {
        "name": "Credential stuffing en login",
        "damage": 9,
        "reproducibility": 9,
        "exploitability": 8,
        "affected_users": 10,
        "discoverability": 9,
    },
    {
        "name": "JWT con secret débil",
        "damage": 10,
        "reproducibility": 6,
        "exploitability": 5,
        "affected_users": 10,
        "discoverability": 4,
    },
    {
        "name": "Mensajes de error verbosos",
        "damage": 3,
        "reproducibility": 10,
        "exploitability": 10,
        "affected_users": 2,
        "discoverability": 10,
    },
]

for t in threats:
    score = (t["damage"] + t["reproducibility"] + t["exploitability"]
             + t["affected_users"] + t["discoverability"]) / 5
    t["dread_score"] = round(score, 1)

threats.sort(key=lambda x: x["dread_score"], reverse=True)

print(f"{'Amenaza':<35} {'Score':>6} {'Prioridad'}")
print("-" * 60)
for t in threats:
    prioridad = "CRÍTICA" if t["dread_score"] >= 8 else "ALTA" if t["dread_score"] >= 6 else "MEDIA"
    print(f"{t['name']:<35} {t['dread_score']:>6} {prioridad}")
Salida:
Amenaza                             Score Prioridad
------------------------------------------------------------
Credential stuffing en login          9.0 CRÍTICA
JWT con secret débil                  7.0 ALTA
Mensajes de error verbosos            7.0 ALTA

Otras Metodologías: PASTA y LINDDUN

PASTA (Process for Attack Simulation and Threat Analysis)

PASTA es una metodología de 7 etapas orientada al riesgo de negocio, más completa que STRIDE pero también más costosa en tiempo:

  1. Definir los objetivos del negocio y los requisitos de seguridad
  2. Definir el alcance técnico del sistema
  3. Descomponer la aplicación (DFDs, casos de uso)
  4. Análisis de amenazas (árboles de ataque)
  5. Análisis de vulnerabilidades existentes
  6. Enumeración y modelado de ataques
  7. Análisis de riesgo y definición de controles

PASTA es especialmente adecuada para sistemas críticos donde el impacto en el negocio debe estar en el centro del análisis (fintech, salud, infraestructura crítica).

LINDDUN (para privacidad)

LINDDUN es el equivalente a STRIDE pero orientado a amenazas de privacidad, esencial para sistemas que manejan datos personales bajo GDPR o CCPA:

  • Linkability — Los datos pueden vincularse entre sí para identificar personas
  • Identifiability — Los datos revelan la identidad del sujeto
  • Non-repudiation — El sujeto no puede negar sus acciones
  • Detectability — Se puede detectar que alguien usa el sistema
  • Disclosure — Datos expuestos a partes no autorizadas
  • Unawareness — El usuario no sabe cómo se usan sus datos
  • Non-compliance — Incumplimiento de regulaciones de privacidad

Threat Modeling en la Práctica: Integración con DevSecOps

El threat modeling no debería ser un ejercicio puntual realizado una sola vez, sino una práctica continua integrada en el SDLC (Software Development Life Cycle):

Cuándo realizar threat modeling

  • Nuevas funcionalidades: Antes de iniciar el desarrollo de cualquier feature que involucre autenticación, pagos, datos sensibles o integraciones externas.
  • Cambios arquitectónicos: Al introducir nuevos servicios, cambiar proveedores cloud o modificar flujos de datos existentes.
  • Revisiones periódicas: Al menos una vez al año para sistemas en producción, o tras incidentes de seguridad relevantes en la industria.
  • Antes de auditorías: Como preparación para certificaciones ISO 27001, SOC 2, PCI-DSS o pen tests.

Integración con el pipeline CI/CD

Algunas herramientas permiten automatizar parte del proceso de threat modeling dentro del pipeline:

# .github/workflows/security.yml — ejemplo con pytm
name: Threat Model Validation

on:
  pull_request:
    paths:
      - 'architecture/**'
      - 'threat-model/**'

jobs:
  validate-threat-model:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install pytm
        run: pip install pytm

      - name: Generate threat model report
        run: python threat-model/model.py --report html > reports/threat-model.html

      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: threat-model-report
          path: reports/threat-model.html
# threat-model/model.py — Threat model como código con pytm
from pytm import TM, Server, Datastore, Dataflow, Boundary, Actor

tm = TM("API de Autenticación")
tm.description = "Modelo de amenazas del servicio de autenticación"
tm.isOrdered = True

internet = Boundary("Internet")
internal = Boundary("Red Interna")

usuario = Actor("Usuario", inBoundary=internet)
api_gw = Server("API Gateway", inBoundary=internet)
auth_svc = Server("Auth Service", inBoundary=internal)
token_db = Datastore("Token Store (Redis)", inBoundary=internal)

api_gw.controls.sanitizesInput = True
api_gw.controls.encodesOutput = True
auth_svc.controls.validatesInput = True
auth_svc.controls.isEncrypted = True
token_db.isEncrypted = True

Dataflow(usuario, api_gw, "Login Request", protocol="HTTPS")
Dataflow(api_gw, auth_svc, "Auth Request", protocol="gRPC/TLS")
Dataflow(auth_svc, token_db, "Store Token", protocol="Redis TLS")
Dataflow(auth_svc, api_gw, "JWT Response", protocol="gRPC/TLS")
Dataflow(api_gw, usuario, "JWT Token", protocol="HTTPS")

tm.process()

Checklist de threat modeling para Pull Requests

Para equipos que no tienen tiempo para un modelo completo en cada PR, una checklist mínima de seguridad puede capturar las amenazas más comunes:

# Security Checklist — PR Template

## Threat Modeling Quick Check

### Autenticación y Autorización
- [ ] ¿El endpoint valida que el usuario autenticado tiene permiso para el recurso solicitado?
- [ ] ¿Los tokens tienen expiración y se invalidan correctamente al logout?
- [ ] ¿Se usa autorización basada en servidor, no solo en cliente?

### Validación de Entradas
- [ ] ¿Todos los inputs externos se validan y sanitizan antes de usarlos?
- [ ] ¿Las queries a BD usan parámetros preparados (no interpolación de strings)?
- [ ] ¿Las operaciones de archivo validan rutas para evitar path traversal?

### Manejo de Datos Sensibles
- [ ] ¿Los datos sensibles (passwords, tokens, PII) nunca se loguean?
- [ ] ¿Las secrets se leen de variables de entorno o secret managers, no del código?
- [ ] ¿Las respuestas de error no revelan detalles de infraestructura?

### Comunicaciones
- [ ] ¿Todas las comunicaciones usan TLS?
- [ ] ¿Los headers de seguridad están configurados (HSTS, CSP, X-Frame-Options)?

### Logging y Auditoría
- [ ] ¿Los eventos de seguridad relevantes generan logs con contexto suficiente?
- [ ] ¿Los logs incluyen IP, usuario, timestamp y resultado de la operación?

Herramientas y Recursos para Empezar

Herramientas open source

  • OWASP Threat Dragon — Aplicación web y desktop para crear DFDs y modelos de amenazas con análisis STRIDE integrado. Soporta exportación a JSON y reportes.
  • pytm — Librería Python para definir threat models como código. Ideal para integración en pipelines CI/CD y versionado en git.
  • Threagile — Threat modeling como código YAML, con motor de análisis automático y generación de reportes PDF. Muy activo en la comunidad.
  • Microsoft Threat Modeling Tool — Herramienta gratuita de Microsoft con plantillas para Azure, AWS y sistemas genéricos. Solo disponible para Windows.

Frameworks y referencias

  • OWASP Application Security Verification Standard (ASVS): Lista de requisitos de seguridad que complementa el threat modeling con controles concretos.
  • MITRE ATT&CK: Base de conocimiento de tácticas y técnicas de atacantes reales, útil para el paso de enumeración de amenazas.
  • MITRE CAPEC: Catálogo de patrones de ataque comunes, referencia para la fase de identificación de amenazas.
  • Libro recomendado: Threat Modeling: Designing for Security de Adam Shostack — la referencia más completa sobre el tema.

Conclusión

El threat modeling no es una actividad exclusiva de equipos de seguridad especializados: es una habilidad que cualquier desarrollador o arquitecto puede y debe incorporar en su práctica diaria. Comenzar con DFDs simples y aplicar STRIDE de forma sistemática ya aporta un valor significativo frente a no hacerlo.

La clave del éxito está en la integración continua: hacer del threat modeling un artefacto vivo que evoluciona con el sistema, no un documento que se archiva tras una auditoría. Equipos que adoptan esta mentalidad no solo construyen software más seguro — también desarrollan una comprensión más profunda de sus propios sistemas y reducen el tiempo de respuesta ante incidentes reales.

Empieza con el sistema más crítico de tu organización, aplica STRIDE al DFD más simple que puedas dibujar, y desde ahí expande la práctica. El primer threat model siempre es el más difícil; el segundo es donde empieza el valor real.

Artículos relacionados