Qué es un modelo de amenazas y cuándo se hace

Modelar amenazas no es un ritual ni un documento largo: es contestar cuatro preguntas, en este orden. Qué estamos construyendo. Qué puede salir mal. Qué vamos a hacer al respecto. Y si lo hecho fue suficiente. La primera produce un diagrama; la segunda, una lista de amenazas; la tercera, decisiones con responsable; la cuarta obliga a volver sobre lo hecho y comprobar que lo decidido se aplicó y que el diagrama sigue siendo el del sistema real.

Casi todo modelo que fracasa se queda en la segunda pregunta: una lista de miedos sin decisiones. Las cuatro juntas son lo que lo convierte en trabajo útil.

El mejor momento para un modelo de amenazas es el diseño. Cambiar un flujo en un dibujo cuesta una conversación; cambiarlo cuando ya hay código, datos reales y clientes cuesta semanas y a veces no se puede. Hay fallos que ningún escáner de la cadena encuentra porque no son un error de código: un servicio que confía en cualquiera que le hable desde la red interna es correcto línea por línea y está mal diseñado.

Por eso el modelo no sustituye a los controles de la cadena: mira lo que ellos no ven, y cada amenaza que sale de él acaba como un control, una prueba o una decisión de diseño.

El equipo de Farolito dibujó su diagrama y lo pasó a tablas para poder trabajarlo: una tabla con los elementos (quién usa el sistema, qué procesos lo mueven, dónde se guardan los datos) y otra con los flujos (qué dato va de qué elemento a cuál). Abre el modelo y lee la tabla de elementos con SELECT * FROM elementos. Cada elemento tiene un identificador estable: es la forma de citarlo en una amenaza o en una decisión sin ambigüedad.

Saber moverse por esa tabla y encontrar un elemento por lo que hace es el primer paso de todo lo demás.

Un elemento solo no dice nada de riesgo: el riesgo está en lo que se mueve entre ellos. Cada flecha del diagrama lleva un dato concreto, y casi toda amenaza se escribe pensando en ese dato: quién podría leerlo, cambiarlo, falsificarlo o impedir que llegue. Lee ahora la tabla de flujos con SELECT * FROM flujos y fíjate en la columna datos.

Preguntar siempre «qué dato viaja aquí» es el hábito que separa leer un diagrama de mirarlo.