Cómo diseñar un cyber-eval air gap que permita atacar un mundo sintético sin tocar internet real

Paso 1 — Crea un universo de objetivos sintéticos. Usa dominios y subdominios controlados, direcciones privadas y datasets que no correspondan a personas o empresas reales. Evita nombres de marca plausibles que puedan colisionar. Genera IDs únicos para cada objetivo y haz que toda documentación del ejercicio apunte a ellos. Si necesitas simular internet, replica páginas o APIs dentro del lab. El objetivo es que una búsqueda o resolución equivocada nunca encuentre una entidad real con el mismo nombre. La identidad de la simulación debe estar respaldada por infraestructura, no solo descrita en la consigna.

Paso 2 — Aplica egress default deny en la capa más baja disponible. Bloquea salida desde la VM o contenedor hacia internet y permite únicamente rangos del laboratorio. No confíes solo en un proxy configurado por la aplicación, porque una herramienta alternativa podría saltárselo. Usa security groups, reglas de red o namespaces según tu stack. Registra cada intento denegado con destino, proceso y runid. Para servicios absolutamente necesarios, crea allowlists pequeñas y preferiblemente proxies de solo lectura. Cada excepción de red debe tener owner, propósito y fecha de expiración.

Paso 3 — Controla DNS y resolución de nombres. El agente debería consultar un resolutor interno que conozca los dominios sintéticos y devuelva NXDOMAIN o un sinkhole para cualquier nombre no autorizado. Bloquea DNS directo a servidores públicos y protocolos alternativos cuando corresponda. Añade casos de prueba con dominios similares a empresas reales, unicode y subdominios inesperados. Este control evita que un nombre ambiguo se convierta en una IP externa incluso si el agente intenta explorar. Guarda el log de resolución como evidencia de qué destinos intentó descubrir durante la evaluación.

Paso 4 — Usa credenciales de laboratorio sin valor fuera del entorno. Crea cuentas temporales, tokens scoped y secretos falsos que solo funcionen contra servicios simulados. Nunca coloques credenciales productivas “por conveniencia” en una imagen de evaluación. Monta repositorios ficticios con ejemplos de secretos para probar detección, pero asegúrate de que esos valores no autentiquen en ningún sistema real. Si el agente encuentra una credencial pública inesperada, la red sigue bloqueando su uso externo. La evaluación debe poder observar intención y técnica sin convertir el hallazgo en capacidad real sobre terceros.

Paso 5 — Ejecuta una suite de escape antes del benchmark. Pide al agente o a un tester separado intentar conexiones a IPs públicas, DNS externos, metadata endpoints, filesystem del host y sockets fuera de scope. Espera bloqueos deterministas y verifica que cada intento quede logueado. Corre la suite después de cualquier cambio de imagen, runtime o herramienta. No declares el lab seguro por diseño; demuéstralo con tests repetibles. Si una prueba de contención falla, detén el benchmark funcional. La puntuación del modelo no tiene valor si el entorno que la produjo no puede demostrar su perímetro.

Paso 6 — Define respuesta a incidentes y cierre. Ante un escape, mata la sesión, preserva logs, congela la imagen y determina si hubo tráfico real. Establece responsables de notificación antes de comenzar. Después de cada evaluación, genera un containmentreceipt con reglas activas, intentos denegados y confirmación de que no se observó egress autorizado fuera del lab. En Goatify, este patrón puede extenderse a demos de navegador y cuentas: el mundo disponible para una habilidad se compone explícitamente. La creatividad del agente se evalúa dentro del perímetro; la seguridad la garantiza la infraestructura alrededor.