Un equipo de desarrollo puede modelar las amenazas de una funcionalidad en una hora si responde a cuatro preguntas en orden y sale con tickets en lugar de un documento. Las preguntas proceden del Threat Modeling Manifesto: en qué estamos trabajando, qué puede salir mal, qué vamos a hacer al respecto y si lo hemos hecho lo bastante bien. No hace falta un arquitecto de seguridad, porque el trabajo no depende de la capacidad innata de una sola persona.
La hora de un vistazo
| Minutos | Pregunta | Resultado |
|---|---|---|
| Antes | - | Una persona prepara un borrador del diagrama de flujo de datos |
| 0-10 | En qué estamos trabajando | Diagrama corregido, puntos de entrada numerados |
| 10-30 | Qué puede salir mal | Lista de amenazas, agrupadas por categoría STRIDE |
| 30-45 | Qué vamos a hacer al respecto | Una respuesta para cada amenaza |
| 45-55 | Tickets y pruebas | Un ticket y una prueba por cada medida de mitigación |
| 55-60 | Lo hemos hecho lo bastante bien | Comprobación de completitud |
Antes de la sesión
Elija una funcionalidad, no un producto entero. Encontrar problemas en la fase de diseño es mucho más eficiente que corregir fallos en producción, así que celebre la sesión antes de que empiece el desarrollo.
Convoque a un desarrollador, al responsable de los requisitos y, si hay infraestructura implicada, a alguien de operaciones. Una de estas personas lleva un borrador del diagrama de flujo de datos, hecho con una herramienta cuyos archivos el equipo pueda editar más adelante.
Minutos 0-10: en qué estamos trabajando
El grupo corrige el borrador. La OWASP Threat Modeling Cheat Sheet pide tener una visión clara de los límites de confianza (trust boundaries), los flujos de datos, los almacenes de datos, los procesos y las entidades externas, que a menudo representan posibles puntos de ataque. Compruebe que cada uno de ellos figura en el diagrama.
Si algunos participantes no son técnicos, haga una lluvia de ideas sobre los flujos en una pizarra en lugar de insistir en la notación DFD.
Numere los puntos de entrada a medida que avanzan, con notación mayor.menor para los que están en capas (1, 1.2, 1.2.1), como hace la página del proceso de la comunidad OWASP, y marque también los puntos de salida. Un mensaje de error en una página de inicio de sesión puede facilitar ataques a través del punto de entrada correspondiente, como la recolección de cuentas ("usuario no encontrado") o la inyección SQL (mediante errores de excepciones SQL).
Minutos 10-30: qué puede salir mal
Empiece con STRIDE para un diseño técnico. Recorra cada componente, flujo de datos y límite de confianza con las seis categorías y anote el ID del punto de entrada que afecta cada amenaza.
| Categoría | Vulnera | Ejemplo |
|---|---|---|
| Suplantación de identidad (Spoofing) | Autenticación | Token de autenticación robado y utilizado para hacerse pasar por un usuario |
| Manipulación (Tampering) | Integridad | Actualizaciones no previstas de la base de datos a través de la aplicación |
| Repudio (Repudiation) | Trazabilidad | Registros manipulados para encubrir acciones |
| Revelación de información (Information Disclosure) | Confidencialidad | Datos extraídos de una base de datos de cuentas de usuario |
| Denegación de servicio (Denial of Service) | Disponibilidad | Usuario bloqueado por muchos intentos de autenticación fallidos |
| Elevación de privilegios (Elevation of Privileges) | Autorización | Un JWT manipulado para cambiar el rol |
Para una regla de negocio, añada casos de uso indebido (misuse cases): acciones realizadas fuera de orden, de forma repetida, simultánea o para obtener un resultado no previsto. Para un objetivo del atacante que requiera varios pasos, utilice un árbol de ataque. No añada técnicas para aparentar exhaustividad: explique por qué encaja cada una y qué deja sin cubrir.
Probabilidad por impacto suena ordenado, pero ambos valores son difíciles de estimar y el producto ignora el coste de la corrección. En una hora basta con una valoración aproximada de alta, media o baja por amenaza.
Un ejemplo práctico: restablecimiento de contraseña
Tomemos un restablecimiento de contraseña. El diagrama muestra el navegador, la aplicación web, la base de datos de usuarios y un servicio de correo, con un límite de confianza entre internet y la aplicación. La solicitud de restablecimiento es el punto de entrada 3 y el enlace enviado por correo es el 3.1 (ID ilustrativos).
El grupo encuentra cuatro amenazas. Un enlace de restablecimiento funciona para alguien que no es su propietario (suplantación de identidad). Un mensaje del tipo "no existe ninguna cuenta con esa dirección" revela quién está registrado (revelación de información). Los eventos de restablecimiento no se registran (repudio). Alguien provoca restablecimientos repetidos contra una víctima (denegación de servicio).
Minutos 30-45: qué vamos a hacer al respecto
Cada amenaza recibe una de estas cuatro respuestas:
- Mitigar: reducir la probabilidad de que la amenaza se materialice.
- Eliminar: suprimir la funcionalidad o el componente que la causa.
- Transferir: trasladar a un tercero la responsabilidad contractual o financiera.
- Aceptar: no hacer nada, porque las demás opciones no encajan con las restricciones del negocio.
Transferir no reduce por sí solo la probabilidad ni el daño, así que anote quién es responsable de los controles restantes y del riesgo residual. En las amenazas aceptadas, registre quién aceptó el riesgo y por qué.
Minutos 45-55: tickets y pruebas
Convierta cada medida de mitigación acordada en un requisito que un desarrollador pueda asumir. Basta con una fila por amenaza:
| ID de amenaza | STRIDE | Ticket | Prueba |
|---|---|---|---|
| 3.1-S | Suplantación de identidad | Hacer que los enlaces de restablecimiento sean de un solo uso y de corta duración | Se rechaza un enlace usado o caducado |
| 3-I | Revelación de información | Devolver una única respuesta genérica para cualquier dirección | Las direcciones conocidas y desconocidas reciben respuestas idénticas |
| 3-R | Repudio | Registrar cada solicitud de restablecimiento | Un intento de restablecimiento aparece en el registro |
La columna de pruebas hace que el modelo sea algo más que un diagrama. Cada medida de mitigación necesita una comprobación que falle cuando falte el control. Los casos de abuso se traducen directamente: repetir la solicitud (replay), enviar los pasos fuera de orden, enviar dos solicitudes a la vez. Ponga los tickets en el backlog de la propia funcionalidad, con el ID de la amenaza en el título.
Minutos 55-60: lo hemos hecho lo bastante bien
Empiece con una comprobación sencilla: ¿existen registros que muestren un diagrama, una lista de amenazas y una lista de controles? Si falta alguno, la sesión no ha terminado. Confirme que cada amenaza tiene una respuesta, que cada medida de mitigación indica cómo la implementará el equipo y que los riesgos aceptados explican el motivo.
Después, mantenga vivo el modelo. Actualícelo junto con el sistema y, cuando cambie el diseño, vuelva a ejecutar solo las partes afectadas.
Por dónde empezar
- Elija una funcionalidad próxima y reserve una hora con un desarrollador, el responsable de los requisitos y alguien de operaciones.
- Pida a una persona que prepare un borrador del diagrama de flujo de datos con los límites de confianza marcados. El grupo lo corrige y numera los puntos de entrada en los primeros diez minutos.
- Aplique STRIDE a cada componente y flujo durante 20 minutos, anotando con cada amenaza el ID del punto de entrada afectado.
- Asigne una respuesta a cada amenaza, anote quién es responsable de cualquier riesgo aceptado o transferido y cree después un ticket y una prueba por cada medida de mitigación.
- Guarde el diagrama, la lista de amenazas y la lista de controles junto con la documentación de la funcionalidad. Si desea una opinión externa sobre el primer modelo, nuestro servicio de consultoría puede revisarlo, y las amenazas registradas constituyen un buen alcance para un test de intrusión posterior.
