Flujos de datos y límites de confianza

Un diagrama de flujo de datos tiene cuatro clases de elemento y conviene que no tenga ninguna más. Entidades externas: quien usa el sistema o quien le habla desde fuera, y sobre quien la organización no manda. Procesos: lo que recibe algo, hace algo y devuelve algo. Almacenes: donde los datos se quedan quietos. Y flujos: las flechas, que son el dato en movimiento.

La disciplina está en lo que se deja fuera. Un balanceador, un cortafuegos o una red privada virtual no son elementos del diagrama: son controles. Si se dibujan, el diagrama empieza a contar cómo está protegido el sistema en vez de cómo funciona, y el modelado se convierte en una revisión de la lista de controles del cliente. Eso ya lo hace el cliente; lo que el evaluador necesita saber es por dónde se mueve el dato cuando todo funciona.

Para un pentester el diagrama tiene un uso muy concreto: cada flecha es una pregunta y cada almacén es un premio. El plan de pruebas sale de recorrerlos, no de la lista de herramientas que uno sabe usar.

Un límite de confianza es la línea donde cambia quién responde por lo que ocurre. A un lado la organización controla el código, las cuentas y la máquina; al otro, no. Por eso los límites no se dibujan por zonas de red sino por responsabilidad: la frontera entre internet y las aplicaciones, la que separa las aplicaciones de los datos, la que separa la red de oficina del entorno productivo y la que separa a la organización de un proveedor.

Lo que importa de un límite es lo que lo cruza. Un flujo que nace y muere dentro de la misma zona casi nunca es el primer sitio donde mirar; uno que entra desde fuera lo es siempre. Y de los que entran desde fuera, el que más dice es el que no pide nada para entrar: convierte cualquier pregunta posterior sobre contraseñas o sesiones en una pregunta sobre si hacía falta tenerlas.

Abre el laboratorio y revisa los flujos que cruzan la frontera de internet, con la columna que dice qué pide cada uno.

La frontera entre la capa que atiende y la capa que guarda es la que decide cuánto duele un error. Si un proceso entra a los almacenes con una cuenta que puede hacer de todo, cualquier fallo de ese proceso se convierte en acceso a todo lo guardado; si entra con una cuenta que solo puede hacer lo suyo, el mismo fallo se queda en un susto.

Por eso cada cruce de esa frontera es una pregunta del plan: con qué cuenta entra, qué puede hacer esa cuenta y quién más la conoce. La cifra de cuántos cruces hay es lo que justifica ante el cliente cuántas horas pide ese bloque.

Un diagrama entregado por el cliente es un documento de buena fe, no una verdad verificada. Dice lo que el equipo cree que pasa, y suele estar desactualizado en los mismos sitios: integraciones añadidas con prisa, trabajos programados que nadie dibuja, accesos de soporte que existen pero no figuran.

El modelador no corrige el diagrama por su cuenta ni lo da por bueno. Lo usa como hipótesis y anota las preguntas que le faltan por responder. Esas preguntas son material del plan igual que las amenazas: una integración no dibujada que aparezca durante la prueba cambia el reparto de horas, y el cliente tiene que haberlo sabido antes.