Modelado de amenazas con STRIDE.
Elegimos una web diminuta y la recorremos con STRIDE; después escribimos el prompt con el que un LLM hace el 60% del trabajo de un revisor.
El modelado de amenazas suena pesado. En la práctica, su versión útil es un ejercicio de una hora con una pizarra y el acrónimo STRIDE. Lo haremos con una aplicación deliberadamente pequeña y luego mostraremos cómo sacarle el mismo trabajo a un LLM a escala.
El sistema: un servicio de pastes
Los usuarios pegan texto, reciben a cambio una URL con un ID aleatorio y comparten la URL. Los pastes caducan de forma opcional. No hay cuentas. La arquitectura son cuatro cajas:
[ Navegador ] →https→ [ Web ] →TCP→ [ BD ]
↓
[ Caché ]STRIDE en un párrafo por letra
STRIDE recorre cada componente y plantea seis preguntas. El acrónimo es tu guion: a cada caja del diagrama y a cada flecha se le aplica cada letra.
| Letra | Categoría de amenaza | Propiedad CIA atacada |
|---|---|---|
| S | Spoofing (suplantación) | Autenticidad (una forma de Integridad) |
| T | Tampering (manipulación) | Integridad |
| R | Repudiation (repudio) | No repudio |
| I | Information Disclosure (fuga de información) | Confidencialidad |
| D | Denial of Service (denegación de servicio) | Disponibilidad |
| E | Elevation of Privilege (elevación de privilegios) | Autorización |
Recorriendo el diagrama
Navegador → Web (la flecha)
- S: el certificado TLS del servidor impide la suplantación. Mitigado con HTTPS.
- T: manipulación en tránsito. Mitigado con TLS AEAD.
- I: alguien escuchando en el cable. Mitigado con TLS.
- D: inundaciones, slowloris. Mitigado con CDN / rate limit.
Web (la aplicación)
- S: no hay inicios de sesión, así que la suplantación de identidad no aplica. Pero el propio ID del paste es un identificador: unos IDs predecibles permiten a un atacante "suplantar" cualquier paste. Pregunta abierta: ¿es el ID lo bastante aleatorio?
- T: ¿puede un usuario hacer POST a una URL que le permita sobrescribir el paste de otra persona? Pregunta abierta.
- R: ¿puede el operador demostrar qué IP envió un paste malicioso? Hacen falta logs y una política de retención.
- I: los IDs de los pastes en las URLs acaban en el historial del navegador, en las cabeceras Referer, en los logs de proxies intermedios. Pregunta abierta: ¿filtramos el contenido del paste vía Referer?
- D: un tamaño de paste sin límite = disco lleno. Pregunta abierta: ¿cuál es el tamaño máximo del cuerpo?
- E: el endpoint de administración: ¿existe?, ¿está en el mismo puerto?, ¿está autenticado?
Web → BD y Web → Caché
- T / I: ¿estas conexiones van por TLS o en texto plano dentro de la red local? En una VPC plana, el texto plano es aceptable si el segmento está bien blindado; en una red compartida, no lo es.
- D: la expulsión de la caché por presión de memoria puede provocar una carga en cascada sobre la BD.
- E: inyección SQL sobre el texto que aporta el usuario. Pregunta abierta: ¿solo sentencias preparadas?
No es un montón de "vulnerabilidades". Es una lista corta de preguntas abiertas que nadie en la sala puede responder con seguridad, y un plan para cerrar cada una. Las amenazas que ya sabes mitigar se anotan, pero no son interesantes.
Mitigaciones concretas para nuestras preguntas abiertas
- Aleatoriedad del ID del paste: 128 bits de entropía con
secrets.token_urlsafe(22). Rechaza en el router cualquier ID más corto. - Sobrescritura vía POST: la emisión del ID es el único punto donde se crea un paste; la ruta no acepta ningún
iddel cliente. - Fuga por Referer: fija
Referrer-Policy: no-referreren las páginas de visualización de pastes. - Tamaño del cuerpo: límite de 1 MB en el proxy. Devuelve 413 por encima.
- Inyección SQL: consultas parametrizadas obligadas por el ORM; una regla de CI hace fallar la build si una cadena SQL en crudo menciona
%s.
El prompt de LLM que te lleva al 60%
El modelado de amenazas es lo bastante mecánico como para que un LLM bien orientado haga la mayor parte. El prompt de abajo se ha refinado a lo largo de una docena de revisiones reales. Encaja tu propia arquitectura en el hueco.
Eres un revisor de seguridad. Te daré una descripción de arquitectura. Recórrela con STRIDE. Para cada componente y cada flujo de datos, emite: - Nombre del componente o flujo - Una línea por cada letra de STRIDE, marcada como una de: MITIGADO (y con qué) ABIERTO (y qué investigar) N/A (y por qué) - NO especules sobre detalles de implementación que no estén en la descripción. - Al final, lista los elementos ABIERTOS como un checklist numerado. Arquitectura: <pega aquí la descripción de tu diagrama>
De ese prompt importan dos cosas. Fuerza una tabla por componente (algo en lo que un LLM es bueno) y prohíbe especular (algo en lo que un LLM es malo). La salida es un punto de partida, no un informe final: la recorres con el equipo y conviertes cada ABIERTO en un "lo sabemos" o un "hay que arreglarlo".
Lo que acabas de aprender
El modelado de amenazas no es una reunión en la que enumeras todo lo que podría salir mal. Es una forma estructurada de encontrar aquello que nadie en la mesa puede responder con seguridad. STRIDE es la estructura más barata que atrapa la mayoría de esas cosas. Un LLM puede montarte el primer borrador y dejarte dedicar la reunión a las respuestas.