Un modelo de amenaza es un documento vivo, no una instantánea: se redacta en las fases de diseño y arquitectura de cualquier producto o servicio para identificar qué se protege, de quién y cómo. En su blog Dhole Moments, el criptógrafo Soatok ofrece una guía introductoria, en tono desenfadado, para construir esa intuición desde cero.
El punto de partida es responder cinco preguntas básicas: qué se protege, quién o qué quiere atacarlo, cómo podría hacerlo, qué medidas se aplican para impedirlo y qué riesgos se aceptan conscientemente. A esas preguntas Soatok añade otras que muchos modelos omiten y que marcan la diferencia entre un ejercicio inútil y uno útil: cómo se relacionan los activos entre sí (mejor pensar en grafos que en listas, porque los atacantes piensan en grafos), qué supuestos se asumen de forma implícita y qué amenazas se decide deliberadamente no abordar.
Los supuestos —advierte— son la pieza más crítica: si uno falla, el modelo queda incompleto o los riesgos aceptados deben revisarse. Pone como ejemplo el ataque "Invisible Salamanders", que rompe la denuncia de abuso en mensajería cifrada cuando se introducen múltiples claves válidas por mensaje, algo no contemplado en los esquemas AEAD clásicos como AES-GCM o ChaCha20-Poly1305.
Para ilustrar un modelo bien hecho, Soatok describe el suyo propio en el proyecto de transparencia de claves para el Fediverse (publickey.directory), estructurado en supuestos, activos, actores y riesgos clasificados en cuatro estados: prevenido por diseño, mitigado, direccionable y abierto. Como contrapunto, analiza el modelo de amenaza de Matrix v1.18, al que critica por ser exhaustivo en la enumeración de vectores de ataque de denegación de servicio pero incompleto en supuestos y relaciones entre activos, repitiendo así los errores más comunes del sector.