En pocas palabras
Modelado de amenazas: analizar activos, flujos de datos y límites de confianza para identificar riesgos y decidir mitigaciones.
Qué problema resuelve
Descubrir demasiado tarde problemas de diseño que los escáneres de código no detectan por sí solos.
Cuándo utilizarlo
Diseño de sistemas, cambios de arquitectura, nuevas integraciones y agentes con herramientas. Ejemplo: analizar si un documento malicioso podría inducir a un agente a extraer información y definir controles para impedirlo.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
Las cuatro preguntas
El Threat Modeling Manifesto y Adam Shostack resumen la técnica en cuatro preguntas:
- ¿En qué estamos trabajando? Diagrama de flujo de datos con límites de confianza.
- ¿Qué puede salir mal? Amenazas, con STRIDE u otra técnica.
- ¿Qué vamos a hacer al respecto? Mitigar, eliminar, transferir o aceptar.
- ¿Lo hemos hecho bien? Verificar mitigaciones y revisar el modelo.
El equipo representa el sistema, sus datos y límites de confianza. A partir de ese modelo identifica amenazas, acuerda mitigaciones y define cómo comprobarlas. STRIDE es una de las técnicas posibles para ordenar la conversación.
STRIDE en una tabla
| Amenaza | Propiedad violada | Pregunta guía | Mitigación típica |
|---|---|---|---|
| Spoofing | Autenticación | ¿Puede alguien hacerse pasar por otro usuario o servicio? | MFA, passkeys, mTLS |
| Tampering | Integridad | ¿Puede alterarse un dato en tránsito o en reposo? | Firmas, TLS, control de acceso a escritura |
| Repudiation | No repudio | ¿Podría alguien negar una acción realizada? | Logs de auditoría inmutables |
| Information disclosure | Confidencialidad | ¿Puede filtrarse información sensible? | Cifrado, mínimo privilegio, Presidio |
| Denial of service | Disponibilidad | ¿Puede alguien agotar recursos? | Rate limiting, cuotas, resiliencia |
| Elevation of privilege | Autorización | ¿Puede alguien obtener permisos que no le corresponden? | Autorización por recurso, JIT PAM |
Recorre cada flujo que cruza un límite de confianza y pregunta por las seis categorías.
Cuándo hacerlo
- Al diseñar un sistema o una funcionalidad que cambie flujos de datos o límites de confianza.
- Antes de exponer una API a terceros o integrar un proveedor.
- Tras un incidente de seguridad o un cambio regulatorio.
Sesiones cortas (60–90 minutos) sobre un alcance acotado funcionan mejor que un análisis exhaustivo anual. Parte del diagrama de despliegue o de contenedores del modelo C4.
Ejemplo: un agente con acceso a documentos
| Amenaza | Mitigación ilustrativa | Verificación |
|---|---|---|
| Instrucciones maliciosas en documentos | Separar evidencia de instrucciones y limitar herramientas | Casos adversariales |
| Lectura de datos de otro usuario | Autorización por recurso en la API | Pruebas de aislamiento |
| Acción sensible sin autorización | Permisos mínimos y revisión según la operación | Pruebas de acceso y trazas |
Criterios de implementación
Anota supuestos y riesgos pendientes, con responsables. Revisa el modelo después de incidentes o cambios relevantes. Complementa el análisis de diseño con escáneres, pruebas y observación del sistema en ejecución.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.