Diagramas de flujo de datos para el modelado de amenazas: STRIDE paso a paso

Todo método de modelado de amenazas empieza con la misma pregunta: ¿en qué estamos trabajando? La respuesta habitual es un diagrama de flujo de datos. Es un dibujo sencillo con cinco tipos de elementos, y la hora que le dedicas es la más útil que puedes invertir antes de una revisión de seguridad, porque la mayoría de las amenazas se concentran donde los datos pasan de un nivel de confianza a otro.

Esta guía muestra cómo dibujar un diagrama de flujo de datos (DFD) para el modelado de amenazas, dónde colocar los límites de confianza y cómo recorrer el diagrama con STRIDE. El ejemplo es una función que tiene casi cualquier producto: los usuarios suben una foto de perfil.

Las cuatro preguntas

Un modelo de amenazas práctico responde a cuatro preguntas, popularizadas por Adam Shostack y el Threat Modeling Manifesto:

1. ¿En qué estamos trabajando?
2. ¿Qué puede salir mal?
3. ¿Qué vamos a hacer al respecto?
4. ¿Hicimos un trabajo lo bastante bueno?

El diagrama de flujo de datos responde a la primera. STRIDE ayuda con la segunda. Las notas y los tickets que adjuntas al diagrama responden a la tercera, y una revisión unas semanas después responde a la cuarta.

Los elementos de un diagrama de flujo de datos

Elemento	Qué es	Forma habitual
Entidad externa	Una persona o un sistema fuera de tu control: un usuario, la API de un socio	Rectángulo
Proceso	Código que ejecutas y que transforma o mueve datos	Círculo o forma redondeada
Almacén de datos	Donde los datos reposan: una base de datos, un bucket, una cola, un log	Dos líneas paralelas o un cilindro
Flujo de datos	Datos que se mueven entre dos elementos	Flecha etiquetada con los datos
Límite de confianza	Donde cambia el nivel de confianza	Línea discontinua o una zona alrededor de los elementos

Dos reglas hacen que un DFD sea útil para la seguridad. Etiqueta cada flujo con los datos que transporta, no solo con el protocolo: photo + session token le dice a quien revisa mucho más que HTTPS. Y nunca conectes directamente dos almacenes de datos ni dos entidades externas: los datos solo se mueven a través de un proceso, que es donde puedes verificarlos.

El ejemplo: subida de la foto de perfil

Los usuarios suben una foto de perfil desde el navegador. La API web comprueba su sesión y guarda el archivo sin procesar en un bucket privado. Un procesador de subidas lo recoge, envía los bytes a una API de análisis de malware de terceros, vuelve a codificar la imagen, elimina sus metadatos, escribe la versión limpia de vuelta en el bucket y registra la URL de la foto en la base de datos de usuarios.

Hay cuatro zonas de confianza: internet, nuestra capa de aplicación, nuestra capa de datos y el escáner de terceros. Así queda como DFD:

Cuenta los flujos que cruzan el límite de una zona: del navegador a la API, de la API al bucket, del bucket al procesador y de vuelta, del procesador al escáner y de vuelta, y del procesador a la base de datos. Ahí es donde conviene invertir tu tiempo.

Recorre el diagrama con STRIDE

STRIDE nombra seis tipos de amenazas. El enfoque "STRIDE por elemento" de Microsoft revisa cada elemento solo frente a las amenazas que se aplican a su tipo:

Tipo de elemento	S	T	R	I	D	E
Entidad externa	✓		✓
Proceso	✓	✓	✓	✓	✓	✓
Almacén de datos		✓	✓ (logs)	✓	✓
Flujo de datos		✓		✓	✓

Las seis letras corresponden a suplantación de identidad (Spoofing), manipulación (Tampering), repudio (Repudiation), divulgación de información (Information disclosure), denegación de servicio (Denial of service) y elevación de privilegios (Elevation of privilege). Si recorres la función de subida elemento por elemento, obtienes una lista como esta:

• Suplantación de identidad (navegador). Con un token de sesión robado o falsificado, alguien sube una foto en nombre de otra persona. Mitigación: valida el token en cada petición, usa sesiones de corta duración y vincula la clave del objeto al id del usuario autenticado, nunca a un valor que venga en la petición.
• Manipulación (del bucket al procesador). Un archivo llamado photo.jpg es en realidad algo completamente distinto. Mitigación: comprueba el formato real del archivo, no su nombre ni su tipo declarado, y vuelve a codificar cada imagen antes de que nadie más la vea.
• Repudio (API). Un usuario niega haber subido una imagen ofensiva y nada demuestra lo contrario. Mitigación: registra en el log el id del usuario, la clave del objeto, la hora y la dirección del cliente de cada subida.
• Divulgación de información (bucket). El bucket permite el listado público, o las fotos conservan sus coordenadas GPS en los metadatos EXIF. Mitigación: un bucket privado con URL firmadas de corta duración y metadatos eliminados durante la recodificación.
• Denegación de servicio (API y procesador). Archivos enormes o imágenes que al descomprimirse alcanzan tamaños gigantescos agotan la memoria. Mitigación: límites de tamaño de archivo y de número de píxeles, y tiempos de espera en el procesador.
• Elevación de privilegios (procesador). Un archivo preparado a propósito explota un bug de la biblioteca de imágenes y ejecuta código con los permisos del procesador. Mitigación: ejecuta el procesador en un sandbox sin acceso a nada más que su prefijo del bucket y su única tabla.

Escribe las amenazas en el diagrama como líneas cortas y numeradas en una nota junto a los elementos afectados, y enlaza cada una con el ticket que da seguimiento a la corrección. Así el diagrama sirve también como resumen de la revisión.

Reglas para diagramas de modelado de amenazas

• Dibuja la función, no la empresa. Un DFD por función o por servicio. En un diagrama de todo no hay sitio para los detalles que importan.
• Muestra dónde ocurre la autenticación. En cada flujo que cruza un límite, marca el proceso que verifica la identidad.
• Incluye los caminos que nadie enseña en una demo. Las herramientas de administración, el acceso de soporte, los procesos por lotes y las copias de seguridad también cruzan límites.
• Mantén un solo nivel de detalle. Un DFD de nivel de contexto muestra el sistema como un único proceso; un DFD de nivel 1 lo divide en sus procesos principales. Elige uno por diagrama.
• Versiónalo junto con la función. Cuando cambia el diseño, cambian las amenazas. Actualiza el diagrama en el mismo pull request que el documento de diseño.

Herramientas especializadas o un lienzo compartido

Herramientas gratuitas como OWASP Threat Dragon y Microsoft Threat Modeling Tool están hechas para este trabajo y pueden sugerir amenazas para cada elemento. Funcionan bien cuando un equipo de seguridad dirige el proceso.

Un lienzo compartido funciona mejor cuando quienes construyen la función dibujan el diagrama juntos durante el diseño: el DFD queda junto a los diagramas de arquitectura, todos lo editan en vivo y las notas siguen unidas a los elementos. En cualquier caso, lo valioso es la conversación en torno al diagrama.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade un Marco del pack Básico por cada zona de confianza y ponle el nombre de la zona, por ejemplo Trust zone: app tier.
3. Añade las entidades externas como nodos Caja y los procesos como formas Elipse, ambos del pack Básico, y los almacenes de datos desde el pack Datos (Almacén de objetos, Postgres).
4. Conecta los puertos y etiqueta cada conexión con los datos que transporta.
5. Añade una Nota junto a los elementos afectados que enumere cada amenaza con su letra de STRIDE, su número y su ticket.

El ejemplo usa 10 nodos de diagrama más tres notas que enumeran siete amenazas, dentro del plan Free. Para la parte de red de la seguridad, consulta la plantilla de diagrama de arquitectura de confianza cero y, para mapear datos personales, el caso de uso Mapas de datos para el RGPD.

Preguntas frecuentes

¿Un diagrama de flujo de datos es lo mismo que un diagrama de arquitectura? No. Un diagrama de arquitectura muestra los componentes y cómo se conectan; un DFD muestra cómo se mueven los datos y dónde cambia la confianza. A menudo comparten cajas, pero el DFD se dibuja para responder a la pregunta de seguridad.

¿STRIDE u otro método? STRIDE es una buena opción por defecto para funciones de software. LINDDUN se centra en las amenazas a la privacidad, y PASTA es un proceso centrado en el riesgo para programas más grandes. El diagrama es el mismo punto de partida para todos.

¿Quién debería participar? Los ingenieros que construyen la función, alguien que vaya a operarla y un ingeniero de seguridad si tienes uno. Quienes conocen el código encuentran las amenazas; el ingeniero de seguridad se asegura de que el repaso sea honesto.

¿Cuánto debería durar? Para una función como la subida de fotos, lo típico es una hora: 15 minutos para dibujar, 30 para recorrer STRIDE y 15 para acordar las correcciones y sus responsables.

¿Cada cuánto deberíamos actualizar el modelo? Cada vez que un flujo cruce un nuevo límite, aparezca un nuevo almacén de datos o la función cambie quién puede hacer qué.

Empieza gratis — un puesto, sin tarjeta de crédito.