Guía informal de Soatok sobre modelos de amenazas
(soatok.blog)- Un modelo de amenazas no termina con anotar qué se protege y quiénes son los atacantes; sirve para tomar decisiones de diseño cuando también revela las relaciones entre activos, las suposiciones y las amenazas excluidas deliberadamente
- Un buen modelo ve los activos no como una lista, sino como un grafo, y confirma riesgos y premisas acotando las entradas, salidas y dependencias de los componentes
- Si una suposición se rompe, también hay que revisar los riesgos aceptados; el ataque Invisible Salamanders se vuelve problemático cuando entran en conflicto una función de reporte de abuso en E2EE y la suposición de AEAD de “una clave válida por mensaje”
- El caso de publickey.directory separa suposiciones, activos, actores y estados de riesgo, pero no es perfecto; el modelo de amenazas de Matrix v1.18 se parece más a una lista de tipos de ataque y omite cifrado y gestión de claves
- El modelado de amenazas ayuda a tomar mejores decisiones de diseño al separar las restricciones de elección tecnológica y los riesgos reales, como en autenticación con passkeys, diseño de E2EE distribuido y debates sobre PQC
Preguntas que debe responder un modelo de amenazas
- Un modelo de amenazas puede ser un proceso formal de ciberseguridad, pero también puede realizarse de manera informal durante la etapa de diseño y arquitectura de un nuevo producto o servicio
- Como mínimo, debe responder estas preguntas
- Qué se está protegiendo
- Quién o qué intenta dañar lo que se protege
- De qué manera puede atacar el atacante
- Qué se hará para impedir ese ataque
- Con estas cuatro preguntas ya se puede llamarlo modelo de amenazas, pero en la práctica es fácil que falten detalles importantes
- Las preguntas adicionales necesarias son las siguientes
- Cómo están conectados los activos protegidos
- Qué suposiciones se están haciendo
- Qué amenazas se dejan fuera deliberadamente
- Como no se pueden cubrir todos los ataques futuros, hay que explicitar las amenazas excluidas
- Si una suposición es incorrecta, el modelo queda incompleto y también hay que revisar la lista de riesgos ya aceptados
- Un modelo de amenazas no debe ser una instantánea de un momento específico, sino un documento vivo que se actualiza cuando hace falta
Problemas cuando se rompen las suposiciones
- El ataque Invisible Salamanders puede romper la función de reporte de abuso al introducirla en algunos diseños de mensajería E2EE
- Este ataque se relaciona con las suposiciones de esquemas AEAD como AES-GCM y ChaCha20-Poly1305
- En esos esquemas existe la suposición de que hay una sola clave válida para un mensaje específico
- Si se introducen varias claves válidas para un mismo mensaje o se crean confused deputies, se sale de las garantías de seguridad del algoritmo
- Escribir claramente las suposiciones ayuda a identificar los propios unknown unknowns
- No hace falta que sea perfecto, pero debe quedar claro qué se toma como premisa
Procedimiento para empezar con el modelado de amenazas
- Para hacer modelado de amenazas de forma profesional, se recomienda leer el Threat Modeling Manifesto
- En la práctica, se empieza escribiendo rápidamente los 7 puntos en un formato que se pueda copiar y usar
- Luego se dibujan los componentes del sistema a analizar en papel o en una herramienta digital
- Si un widget se comunica directamente con otro, depende de otro o interactúa con otro, se marca esa relación
- La forma de representar las relaciones debe ser la que resulte más útil para quien trabaja en ello
- Después de encerrar todo el grafo en una caja, se va reduciendo la caja poco a poco para enfocarse en cada componente
- En cada iteración se registran las entradas y salidas del componente
- Se responden las 7 preguntas tanto como sea posible
- Tras profundizar hasta donde lo permita el nivel de abstracción, se hace una lluvia de ideas sobre qué suposiciones se están haciendo respecto de las capas en las que no se profundizó más
- Una base de datos quizá no dependa de la seguridad de X25519 del mismo modo que un balanceador de carga
- El objetivo es registrar relaciones inapropiadas, como que un feed RSS llegue a una base de datos, y cortarlas si es posible
Caso de publickey.directory
- El trabajo para ofrecer transparencia de claves al Fediverse se sigue en publickey.directory
- Este trabajo comenzó con la especificación public-key-directory-specification, y la especificación incluye un modelo de amenazas
- Ese modelo de amenazas está compuesto por las siguientes secciones
- Suposiciones
- Activos
- Nombres de actores y roles, incluidos atacantes y personas a proteger
- Riesgos y estados de riesgo
- Los estados de riesgo se dividen en cuatro
- Prevented by design: el ataque no funciona por diseño
- Mitigated: el ataque no debería tener éxito si las suposiciones no son incorrectas
- Addressable: existe una forma de mitigarlo, pero requiere esfuerzo o cuidado, y el operador debe conocerlo
- Open: es un riesgo que no puede mitigarse o que no se mitigará, y ese ataque tiene éxito
- Este modelo de amenazas tampoco es perfecto
- No conectó completamente las relaciones entre activos y actores en un grafo fácil de leer para las personas
- La sección de riesgos puede tener puntos ciegos que no se consideraron
- Puede haber omitido suposiciones importantes para la seguridad del sistema
Contraste entre Matrix y Signal
- El Security Threat Model de Matrix v1.18 enumera tipos de ataques como denegación de servicio, spoofing, spam y espionaje
- Ese documento tiene los siguientes problemas
- Se parece más a una lista de tipos de ataque
- No tiene una lista de suposiciones
- No tiene una lista de activos ni relaciones entre activos
- La lista de ataques es incompleta
- Aunque Matrix se promociona como mensajero E2EE, el modelo de amenazas no aborda el cifrado ni la gestión de claves
- El modelo de amenazas de Matrix no cambió mucho desde v1.1, y desde entonces hubo divulgaciones de vulnerabilidades y dos ataques criptográficos adicionales de Lotte
- Aun así, Matrix sí tiene un modelo de amenazas
- Signal ofrece especificaciones técnicas, pero el modelo de amenazas queda en una forma que el usuario debe deducir por su cuenta
- Incluso un mal modelo de amenazas es mejor que no tener ningún modelo de amenazas
Cómo un modelo de amenazas mejora el diseño
- En la práctica de seguridad aparece con frecuencia el dicho de que el defensor siempre debe acertar, mientras que al atacante le basta tener éxito una sola vez
- Si el defensor está lo suficientemente preparado, puede definir el terreno por el que se moverá el atacante
- El verdadero defense-in-depth incluye entender lo suficiente el modelo de amenazas como para llevar al atacante hacia callejones sin salida previsibles
-
Prevención de credential stuffing
- El credential stuffing es un ataque simple que resulta excesivamente eficaz en el mundo real
- La causa es que las personas reutilizan contraseñas
- Como a los usuarios les resulta difícil recordar varias contraseñas únicas y seguras, los gestores de contraseñas fueron una mitigación adecuada durante un tiempo
- Actualmente, las passkeys se consideran una mejor opción
- Las passkeys son una forma más amigable para el usuario de hacer que la autenticación use criptografía asimétrica
- En el mejor caso se usan tokens de seguridad de hardware como SoloKeys o YubiKeys
- En el caso promedio, el sistema operativo o el gestor de contraseñas las proporciona
- Para evitar ataques simples similares al credential stuffing, se necesita el siguiente diseño
- Diseñar la aplicación para que exija passkeys
- Permitir que los usuarios registren varias passkeys o, como mínimo, exigir una de respaldo
- Proporcionar una ruta de break glass para que un administrador pueda agregar una nueva passkey para usuarios que hayan perdido todas sus credenciales
- Registrar esa operación administrativa en logs de una forma que el administrador no pueda censurar
- Si es posible, no admitir contraseñas de autenticación en absoluto
- Las contraseñas para derivación de claves de cifrado están bien en un contexto separado
- Las passkeys hacen imposible el phishing porque, al registrarse, la credencial queda criptográficamente vinculada al nombre de dominio
- Aunque haya un costo de onboarding para passkeys, puede reducir aún más la carga de soporte causada por credential stuffing y phishing
- Al eliminar la expectativa poco realista de que las personas recuerden secretos de alta entropía y no los reutilicen, se eliminan varias clases de ataques y también mejora la usabilidad
- Se cita la frase de Avi Douglen: “La seguridad a expensas de la usabilidad sacrifica la seguridad”
E2EE distribuido y modelos de amenazas
- Se están discutiendo dos propuestas para E2EE en mensajes directos
- La especificación ActivityPub E2EE, orientada al software del Fediverse, por ejemplo los DM privados de Mastodon
- Proyectos como Germ Network, con el mismo objetivo para ATProto, por ejemplo BlueSky
- En algún momento, ambos proyectos consideraron usar MLS como protocolo de gestión de claves para conversaciones E2EE
- En sistemas descentralizados, MLS tiene dos restricciones importantes
- MLS especifica un concepto abstracto llamado Authentication Service
- El orden de los mensajes es importante para la seguridad del ratcheting tree que respalda las epochs de MLS
- Si ActivityPub adopta transparencia de claves para la primera restricción, debe especificar cómo manejar múltiples mensajes KeyUpdate compitiendo entre varios servidores
- La situación de ATProto y BlueSky es más complicada
- En ATProto no hay instancias como en el Fediverse
- En el análisis de seguridad, debe tratarse casi como P2P
- Puede requerir un protocolo complejo que garantice el orden de los mensajes en un sistema distribuido, por ejemplo un enfoque como el algoritmo de consenso Raft
- O bien habría que omitir MLS y elegir E2EE pairwise, renunciando a la abstracción de grupo
- Si la confidencialidad de los mensajes entre usuarios es un objetivo de seguridad y se quiere distribuir el hosting, el diseño de ATProto al estilo blockchain se convierte en un obstáculo para usar los protocolos eficientes y estandarizados de acuerdo de claves de grupo actuales
- El modelado de amenazas puede revelar estas restricciones de diseño en la etapa inicial de diagramación
El rol del modelado de amenazas en el debate sobre PQC
- En relación con las construcciones híbridas poscuánticas, en la lista de correo del grupo de trabajo TLS de IETF se está discutiendo un RFC para establecer code points de ML-KEM no híbrido
- Las premisas de la discusión son las siguientes
- ML-KEM no es un diseño de la NSA
- El autor principal de la propuesta es Peter Schwabe, quien colaboró con Daniel J. Bernstein y la biblioteca criptográfica NaCl, y reside en Alemania
- Otros autores de la propuesta también están en varias partes de Europa
- Como explica el texto de Sophie Schmieg, la teoría de la información descarta un backdoor en ML-KEM
- ML-KEM fue elegido mediante el esfuerzo de estandarización internacional, público y de 10 años de NIST
- NIST, FIPS y la NSA exigen ML-KEM y ML-DSA no híbridos en sistemas clasificados
- Ese borrador de IETF especifica ML-KEM no híbrido y está marcado como Recommend=N
- El RFC de KEM híbrido se marcará como Recommend=Y, y el KEM híbrido se prefiere sobre el KEM no híbrido
- Un sistema configurado para usar siempre KEM híbrido no sufre una degradación de seguridad aunque exista el RFC de ML-KEM
- Google Chrome ya admite ML-KEM no híbrido, y esto no cambiará aunque no salga un RFC de IETF
- El efecto práctico de este RFC es levantar restricciones de procedimiento para organizaciones que deben seguir CNSA 2.0, FIPS 140-3 o reglas similares, y que necesitan un número de RFC estable de IETF en lugar de un Internet Draft
- Este problema puede ser común especialmente en algunos sectores que venden a clientes gubernamentales
-
Diferencia entre Hybrid PQ+ECDH y Pure PQ
- El riesgo que se enfrenta en KEM no es “romper el cifrado después del Q-Day”, sino Harvest Now, Decrypt Later
- Q-Day se usa como abreviatura para referirse al momento en que un atacante obtiene una computadora cuántica relevante para la criptografía
- Al dividir los riesgos, queda así
- ECDH puro, es decir, sin PQ, se rompe retroactivamente en el Q-Day
- PQ puro no se rompe en el Q-Day bajo la suposición de que el algoritmo PQ no se rompe primero
- Hybrid PQ+ECDH es una cobertura frente al colapso de algoritmos antes del Q-Day, pero después del Q-Day no sirve frente a Pure PQ
- Defender ECDH + ML-KEM equivale a reconocer que, a largo plazo, ML-KEM es un algoritmo seguro
- Las razones para preferir híbrido se resumen en dos
- Es más fácil de aceptar que un algoritmo totalmente desconocido, por lo que acelera la adopción de PQ
- Permite cubrirse frente a un colapso algorítmico de ML-KEM o de toda la criptografía basada en retículas
- Para cubrirse de una forma que también resista computadoras cuánticas relevantes para la criptografía, se necesita un híbrido PQ+PQ
- Si se valora la diversidad algorítmica, un híbrido de 3 vías ML-KEM + HQC + ECDH se acerca más a una postura honesta
- ML-KEM es un KEM basado en retículas y se considera resistente a ataques cuánticos
- HQC es un KEM basado en códigos y se considera resistente a ataques cuánticos
- ECDH es el método usado actualmente, pero es vulnerable a ataques cuánticos
- El modelado de amenazas puede usarse en este tipo de debate para separar la oposición ideológica del riesgo técnico y tomar una decisión
Cierre
- En internet hay muchas guías que tratan formalmente los modelos de amenazas y las metodologías relacionadas
- El objetivo aquí es contar con una prueba de humo que permita filtrar rápidamente la calidad y la eficacia de un documento de modelo de amenazas
- Un buen modelo de amenazas debe ir más allá de qué se protege, quién ataca, cómo ataca y cuáles son las defensas: también debe revelar relaciones entre activos, suposiciones y riesgos aceptados
1 comentarios
Comentarios en Lobste.rs
La “falta de amabilidad” sí es una razón válida para reportar comentarios, pero si queremos mejorar el internet técnico, quizá deberíamos dejar de consumir y de recomendar el tono agresivo que este autor usa demasiado seguido en su blog. Incluso valdría la pena considerar bloquear por completo ese dominio
Y creo que un protocolo de “todo es un grafo” realmente debería tratarse como un proyecto de investigación. Al final, la conclusión vino a ser: “vaya, en realidad es muy difícil razonar sobre algoritmos de grafos”