Modelado de amenazas: STRIDE, árboles de ataque y diagramas de flujo de datos

Qué es el modelado de amenazas

El modelado de amenazas es la actividad de examinar un diseño para descubrir qué podría fallar en su seguridad y decidir qué hacer al respecto, antes de que lo descubran por ti los atacantes o los incidentes. Es la principal vía por la que los principios de seguridad se convierten en decisiones concretas, y la respuesta más directa a la categoría de OWASP de diseño inseguro: defectos que ninguna cantidad de código correcto puede arreglar porque el control necesario nunca se diseñó.

Adam Shostack, que dirigió el trabajo de modelado de amenazas en Microsoft y escribió el libro de referencia sobre el tema, reduce la actividad a cuatro preguntas. ¿En qué estamos trabajando? (un modelo del sistema, normalmente un diagrama). ¿Qué puede salir mal? (amenazas, encontradas de forma sistemática). ¿Qué vamos a hacer al respecto? (mitigar, eliminar, transferir o aceptar cada amenaza). ¿Lo hemos hecho suficientemente bien? (revisar el modelo, las amenazas y el seguimiento). Cualquier método que responda a las cuatro preguntas es modelado de amenazas; el resto de esta sección describe las técnicas que la mayoría de los equipos usan para responderlas.

En 2020, un grupo de profesionales, entre ellos Shostack, publicó el Threat Modeling Manifesto, inspirado en el Manifiesto Ágil. Valora una cultura de encontrar y corregir problemas de diseño por encima del cumplimiento de casillas, las personas y la colaboración por encima de los procesos y las herramientas, un camino de comprensión por encima de una instantánea de seguridad puntual, hacer modelado de amenazas por encima de hablar de él, y el refinamiento continuo por encima de una única entrega. Su idea es que el modelado de amenazas es un hábito del equipo que construye el sistema, no un documento que elaboran personas ajenas una vez al año.

Modelar el sistema: diagramas de flujo de datos y límites de confianza

La primera pregunta necesita un modelo del sistema que muestre adónde van los datos y dónde cambia la confianza. La opción tradicional es un diagrama de flujo de datos (DFD) con cinco tipos de elementos: entidades externas (personas o sistemas fuera de tu control, dibujados como rectángulos), procesos (código que ejecutas tú, dibujado como círculos o elipses), almacenes de datos (bases de datos, archivos, colas y cachés, dibujados entre dos líneas paralelas), flujos de datos (flechas que muestran los datos que se mueven entre los demás elementos) y límites de confianza (líneas o recuadros discontinuos donde cambia el nivel de confianza).

Los DFD encajan con el modelado de amenazas porque los ataques siguen a los datos: cada flujo que cruza un límite de confianza es un lugar donde un atacante puede inyectar, interceptar o reenviar algo. Un diagrama de contenedores C4 del Capítulo 4 es un buen punto de partida: añade los límites de confianza, convierte cada flecha en un flujo de datos con dirección y etiqueta, e incluye los almacenes y las colas que los diagramas de contenedores a veces dejan implícitos. Mantén el diagrama en el nivel en el que se encuentran las amenazas: un diagrama por cada funcionalidad o flujo significativo es más útil que un único diagrama enorme de todo.

Encontrar amenazas con STRIDE

STRIDE lo crearon en Microsoft en 1999 Loren Kohnfelder y Praerit Garg como regla mnemotécnica para ayudar a los desarrolladores a pensar en las amenazas a sus productos. Cada letra nombra una categoría de amenaza, y cada categoría es la violación de una propiedad de seguridad, que es lo que la hace útil: es un estímulo sistemático, no una lista de ataques conocidos.

Una forma práctica de aplicar STRIDE es STRIDE por elemento: recorrer cada elemento del DFD y hacer solo las preguntas que se aplican a su tipo. Las entidades externas pueden ser suplantadas y pueden repudiar; los procesos están expuestos a las seis categorías; los almacenes de datos, a la manipulación, la divulgación de información y la denegación de servicio (y al repudio cuando el almacén es un log); los flujos de datos, a la manipulación, la divulgación de información y la denegación de servicio. Dedicar la mayor parte de la atención a los flujos que cruzan límites de confianza mantiene el ejercicio centrado.

STRIDE encuentra amenazas; no las clasifica por prioridad ni elige mitigaciones. Además, en la práctica sus categorías se solapan (una identidad suplantada suele llevar a la divulgación de información o a la elevación de privilegios), lo cual no importa: el objetivo es encontrar la amenaza, no clasificarla a la perfección. Para las amenazas a la privacidad, como vincular o identificar a personas a partir de datos que parecen inofensivos, el método LINDDUN de la KU Leuven cumple el papel que STRIDE cumple para la seguridad; se trata junto con la privacidad desde el diseño.

Árboles de ataque

Un árbol de ataque, popularizado por Bruce Schneier en un artículo de 1999 en Dr. Dobb's Journal, mira el sistema desde el lado del atacante. La raíz es un objetivo, como conseguir comida sin pagar; cada hijo es una forma de alcanzar a su padre. Los hijos de un nodo OR son alternativas; todos los hijos de un nodo AND se necesitan a la vez. Las hojas pueden anotarse con propiedades como el costo, la habilidad necesaria o si el paso es siquiera posible, y esos valores se propagan hacia arriba por el árbol: el costo de un nodo OR es el de su hijo más barato, y el de un nodo AND, la suma de sus hijos.

Los árboles de ataque complementan bien a STRIDE. STRIDE recorre el diseño elemento a elemento y es bueno para la cobertura; un árbol de ataque sigue a un atacante motivado y es bueno para mostrar qué camino es el más barato y, por tanto, dónde rinde más una mitigación. En el árbol de abajo, pagar con una tarjeta robada es relativamente costoso porque necesita dos cosas a la vez, mientras que cambiar el precio en la solicitud del cliente es trivial si el servidor se fía de él. El camino más barato fija el riesgo, así que recalcular cada precio en el servidor vale más que cualquier ajuste del sistema antifraude de tarjetas.

Valorar el riesgo

Un modelo de amenazas suele encontrar más amenazas de las que un equipo puede abordar a la vez, así que cada una necesita una valoración. El enfoque habitual es juzgar la probabilidad (lo fácil, lo atractiva y lo expuesta que es) y el impacto (qué se pierde si ocurre: dinero, datos personales, disponibilidad, reputación, exposición legal) en escalas sencillas como baja, media y alta, y combinarlos en una matriz. El valor de la valoración reside menos en la precisión del número que en un motivo escrito que otros puedan cuestionar. Las organizaciones con una gestión de riesgos madura usan a veces métodos cuantitativos como FAIR (Factor Analysis of Information Risk) para expresar el riesgo como un rango de pérdida esperada.

Conviene conocer dos atajos populares porque a menudo se usan mal. DREAD (damage, reproducibility, exploitability, affected users, discoverability: daño, reproducibilidad, explotabilidad, usuarios afectados y descubribilidad), que se usó en su día en Microsoft, puntuaba cada amenaza en cinco factores (a menudo de 1 a 10) y hacía la media. Cayó en desuso, también en Microsoft, porque distintas personas puntuaban la misma amenaza de forma muy diferente y el número promediado daba una falsa sensación de precisión; la descubribilidad, en particular, premia la ocultación, lo que contradice el diseño abierto. CVSS, el Common Vulnerability Scoring System que mantiene FIRST (versión 4.0, 2023), es la herramienta adecuada para otra tarea: valorar la gravedad de una vulnerabilidad conocida en un producto, como un defecto en una biblioteca. Su puntuación base describe la vulnerabilidad, no el riesgo de una amenaza de diseño en tu contexto, así que no debe usarse para priorizar el resultado de un modelo de amenazas.

Toda amenaza termina en una de cuatro decisiones: mitigar (añadir un control), eliminar (quitar la funcionalidad o los datos, a menudo la mejor opción), transferir (dejar que la asuma alguien mejor situado, como un proveedor de pagos que guarda los datos de las tarjetas) o aceptar (dejar constancia de que una persona con autoridad para ello ha aceptado el riesgo residual, y de por qué). La aceptación no registrada es el fallo más habitual: se encontró la amenaza, nadie la corrigió y nadie decidió no corregirla.

Las respuestas a las dos últimas preguntas son tan importantes como la tabla. Cada mitigación se convierte en un elemento del backlog con un responsable; T3 y T4 se convierten además en escenarios de seguridad con pruebas automatizadas (un webhook con una firma incorrecta debe rechazarse; una llamada a Pagos desde cualquier identidad distinta de Pedidos debe fallar). Las dos decisiones arquitectónicas, los campos de pago alojados y el TLS mutuo entre Pedidos y Pagos, se registran como ADR. Para la cuarta pregunta, el equipo revisa el modelo un mes después frente a lo que realmente se construyó, y el campeón de seguridad comprueba que cada elemento de riesgo alto se mitigó o se aceptó de forma explícita.

Cuándo y con qué frecuencia modelar las amenazas

El modelado de amenazas rinde más en la fase de diseño, cuando cambiar una decisión cuesta lo que una pasada de borrador por la pizarra. Después debe repetirse cada vez que cambia algo significativo: un nuevo límite de confianza o una nueva integración externa, un nuevo tipo de datos sensibles, un cambio en la autenticación o la autorización, un nuevo entorno de despliegue o el paso de un monolito a servicios. Una regla sensata es convertir "¿cambia esto el modelo de amenazas?" en una pregunta de las revisiones de diseño y de la plantilla de los registros de decisiones de arquitectura, y programar una revisión del modelo de cada sistema al menos una vez al año y después de cada incidente de seguridad.

El esfuerzo debe ser proporcionado, en el espíritu del enfoque guiado por el riesgo del Capítulo 1. Un nuevo microservicio que procesa pagos merece una sesión de media jornada con un DFD completo; añadir un campo a una carta pública necesita cinco minutos y un vistazo con STRIDE al flujo modificado. Muchos equipos mantienen su DFD como código junto al sistema (OWASP Threat Dragon y la Threat Modeling Tool de Microsoft son herramientas gratuitas de diagramación, y bibliotecas como OWASP pytm generan diagramas y amenazas candidatas a partir del código), para que el modelo se revise y se actualice junto con el sistema que describe.