El tabletop es teatro. Haz un assumed breach.

Un ejercicio de tabletop mide lo bien que tu equipo describe lo que haría. Eso es una habilidad real y no es la habilidad que importa a las tres de la madrugada. Todo el mundo en la sala sabe la respuesta a «qué harías si vieras PowerShell sospechoso», porque la pregunta lleva dentro su propia respuesta. A nadie en la sala se le pregunta si la alerta habría llegado, si la persona de guardia tiene permisos en la consola para actuar sobre ella, o si el primer paso del runbook menciona una herramienta que se dio de baja en marzo.

Un ejercicio de assumed breach hace esas preguntas metiendo a un intruso real dentro de la red y no contándoselo a nadie. Cuesta más de organizar y produce hallazgos que una conversación no puede producir.

Empieza desde un acceso inicial, no desde el perímetro

La premisa es que el acceso inicial ya ha ocurrido. Eso no es una concesión a la comodidad; refleja cómo van las intrusiones de verdad, y mueve el ejercicio entero a la parte de la línea temporal donde un equipo defensivo todavía puede cambiar el desenlace.

La posición de partida es una decisión de alcance, y la honesta suele estar más abajo de lo que dice el primer instinto del cliente. Una cuenta de usuario estándar en un puesto estándar con software estándar es la posición a la que llega un atacante después de un phishing con éxito, y es la posición para la que la mayoría de los entornos están menos preparados, porque el perímetro se llevó toda la inversión.

Acuerda la posición de partida, los objetivos y nada más. Resístete a escribir una ruta de ataque dentro del plan. El valor del ejercicio depende de que el operador encuentre la ruta que existe, no de que recorra la ruta que alguien anticipó.

Objetivos que se puedan juzgar de verdad

«Probar nuestra capacidad de detección» no es un objetivo. No se puede aprobar ni suspender y produce un informe lleno de adjetivos.

Los objetivos deberían nombrar un estado final concreto que los dos lados puedan verificar después sin discusión:

• Leer un registro concreto de una base de datos de producción concreta.
• Autenticarse en la aplicación financiera como un usuario con permisos de aprobación.
• Obtener acceso persistente que sobreviva a un reinicio y a un cambio de contraseña de la cuenta inicial.
• Pasar del segmento de red de los puestos de trabajo al entorno que aloja datos de clientes.

Cada uno de ellos es binario. Cada uno se corresponde con algo que al negocio le importa de verdad perder. Y cada uno le da al equipo defensivo algo concreto que haber evitado, en lugar de una sensación que haber detectado.

Las barandillas que lo hacen seguro

Un ejercicio dentro de un entorno de producción vivo necesita restricciones escritas antes de empezar, porque el momento de discutirlas no es el momento en que algo sale mal.

• Autorización por escrito que nombre los sistemas dentro del alcance, la ventana y las personas que pueden dar el alto. Firmada por alguien con autoridad para concederla.
• Una prohibición de acciones destructivas explícita, no implícita. Nada de borrados, nada de denegación de servicio, nada de modificar datos de producción. La prueba de acceso es una lectura, una captura, un fichero marcador controlado; nunca un efecto sobre el negocio.
• Una condición de parada y un número de teléfono. Los dos lados necesitan poder detenerlo en minutos, y el número tiene que contestarlo una persona que sepa qué es el ejercicio.
• Poca gente enterada. Normalmente el CISO, el patrocinador del ejercicio y un contacto técnico que pueda confirmar que la actividad de un operador está autorizada. Los demás se enteran después, que es justo el objetivo.
• Registro completo del operador. Cada acción, con marca de tiempo, para que un incidente real y ajeno durante la ventana se pueda separar del ejercicio de inmediato.

Lo último no es papeleo. Si ocurre una intrusión real durante tu ventana de ejercicio, y ocurre, poder decir con certeza qué actividad era tuya es la diferencia entre una investigación limpia y una semana muy mala.

Si los responders pueden aprobar el ejercicio de memoria, has probado su memoria. Los fallos interesantes son los que nadie ensayó.

Injects, y cuándo usarlos

A veces el ejercicio se atasca. El operador establece un acceso inicial, no se detecta nada y pasan días sin actividad defensiva que observar. Eso ya es un hallazgo, pero es un hallazgo que solo puedes recoger una vez, y desperdicia la ventana que queda.

Un inject es una señal deliberada y creciente, pensada para darle al equipo defensivo algo con lo que trabajar. Empieza flojo y sube el volumen hasta que alguien responda:

1. Un comportamiento que debería disparar una detección existente que el cliente cree tener.
2. El mismo comportamiento, repetido y con menos cuidado.
3. Algo inequívoco: una alerta que viene en el ruleset por defecto del fabricante.
4. Un aviso directo al contacto técnico, que convierte el ejercicio de detección en ejercicio de respuesta.

Anota qué peldaño produjo una reacción. El número del peldaño es el hallazgo. Un equipo que responde en el paso uno está en una posición distinta de uno que solo responde cuando se le dice, y saber ambas cosas es más útil que un ejercicio que corrió en silencio hasta el final.

Qué merece la pena medir

La tasa de detección es la métrica que todo el mundo pide y la menos útil, porque se reduce a un porcentaje de un conjunto de actividades que elegiste tú.

Las medidas basadas en tiempo aguantan mejor el escrutinio, y se comparan contra el mismo equipo seis meses después:

• Tiempo hasta la primera detección. Desde la primera acción observable hasta la primera alerta que disparó. Si alguien la miró se mide aparte.
• Tiempo hasta el primer triaje humano. Desde la alerta hasta que una persona la abre. En muchos entornos este es el número que duele, y es un problema de plantilla y de diseño de colas más que de herramientas.
• Tiempo hasta acotar correctamente. Desde el triaje hasta entender bien a qué tiene acceso el intruso de verdad. Quedarse corto al acotar es el fallo de respuesta más común y más caro: el equipo contiene un host y el operador conserva tres.
• Tiempo hasta la contención. Desde el acotado hasta que el acceso queda genuinamente cortado. Verifícalo contra los propios logs del operador, no contra lo que crean los responders.

Junto a los tiempos, anota qué no se detectó en absoluto. Esa lista genera más trabajo de remediación que los tiempos.

El debrief es el entregable

Hazlo conjunto, con los dos lados en la sala y la línea temporal del operador proyectada junto a la del equipo defensivo. Recórrelas a la vez, en orden.

Los huecos se ven de inmediato y no hay que convencer a nadie de ellos. Una alerta que disparó hacia una cola sin vigilancia, una detección que existía pero estaba acotada al entorno equivocado, un paso de runbook que menciona una herramienta dada de baja, un escalado que esperaba a una persona que estaba de vacaciones. Esos son los hallazgos, y son todos cosas que un tabletop habría respondido correctamente en teoría.

Después repítelo. No la misma ruta: eso solo comprueba si se taparon los agujeros concretos. El siguiente ejercicio parte de otra posición con otros objetivos, y lo que estás midiendo es si los tiempos se movieron. Un solo ejercicio es una anécdota. El segundo es el primer dato.