Ejercicios de mesa:

ensayar una crisis de ransomware antes de vivirla

Serie Blue Team  |  unfantasmaenelsistema.com

La mayoría de las organizaciones que sufren un incidente grave de ransomware descubren su plan de respuesta el mismo día que lo necesitan: un documento en una carpeta compartida que nadie ha abierto en un año, con un teléfono de contacto que ya no existe y una cadena de aprobación que da por hecho que el correo corporativo funciona, precisamente el sistema que el atacante acaba de cifrar. El plan escrito no falla porque esté mal redactado; falla porque nunca se ha puesto a prueba con personas reales tomando decisiones reales bajo presión.

Un ejercicio de mesa (tabletop exercise) es la forma más barata y más eficaz de encontrar esos huecos antes de que los encuentre un atacante. No hace falta tocar un solo sistema: basta con reunir a las personas que tendrían que actuar en una crisis real, plantearles un escenario que se complica por fases, y observar qué decisiones se toman, quién falta en la sala y qué preguntas nadie sabe responder. Este artículo explica cómo preparar y facilitar uno, con un guion completo de crisis de ransomware como ejemplo.

1. Qué es un tabletop y qué no es

Un ejercicio de mesa es una discusión guiada, sin tocar ningún sistema, en la que un grupo recorre cómo respondería a un incidente hipotético. Se diferencia de otras formas de poner a prueba la respuesta a incidentes en que no valida capacidad técnica ni detección real: valida decisiones, comunicación y coordinación entre personas. Confundir estos formatos lleva a expectativas equivocadas sobre lo que un tabletop puede demostrar.

El tabletop es el escalón intermedio entre revisar el documento en una sala y ejecutar un failover real: barato, repetible con frecuencia, y capaz de sacar a la luz exactamente el tipo de fallo que una auditoría documental nunca detecta, porque el documento en sí puede estar perfecto y aun así nadie sabe seguirlo bajo presión.

2. Roles en la sala

Un tabletop mal repartido se convierte en una charla donde dos personas hablan y el resto escucha. La sala necesita roles definidos de antemano, con responsabilidades distintas durante el ejercicio.

• Facilitador: dirige el ejercicio, presenta el escenario y los inyectos, hace las preguntas incómodas y evita que la conversación se desvíe hacia detalles técnicos irrelevantes para el objetivo del día — idealmente no forma parte del equipo que va a ser evaluado, para no arrastrar sus propios sesgos
• Participantes: las personas que en una crisis real tendrían que decidir o actuar — no solo el equipo técnico, sino también quien decide sobre el pago de un rescate, quien gestiona la comunicación externa, legal, RRHH si hay datos de empleados afectados, y quien tiene autoridad para aprobar gastos de urgencia
• Observador(es) / relator: toma notas de decisiones, tiempos y huecos detectados sin intervenir en la discusión — es quien después redacta el acta de hallazgos, y conviene que no sea la misma persona que facilita, porque facilitar y tomar notas exhaustivas a la vez degrada ambas tareas
• Patrocinador: quien encarga el ejercicio y se compromete de antemano a que los hallazgos generen acciones con dueño y plazo — sin este compromiso previo, el tabletop corre el riesgo de quedar en una tarde interesante sin ningún cambio posterior

3. Preparar el escenario: inject inicial e inyectos escalados

Un tabletop no se improvisa en la propia sala. Se prepara con un guion escrito de antemano: un inject inicial que arranca la crisis y una serie de inyectos posteriores que la complican en momentos calculados, normalmente cada 15-20 minutos, para forzar decisiones bajo una presión de tiempo creciente similar a la real.

• Inject inicial: el primer aviso de que algo va mal, deliberadamente ambiguo — igual que en un incidente real, al principio no se sabe si es ransomware, un fallo de hardware o un error humano
• Inyectos de escalado: información nueva que el facilitador introduce en momentos fijados, sin que los participantes puedan anticiparla — un servidor más cifrado, una nota de rescate que aparece, un periodista que llama preguntando por el incidente, un empleado que jura haber visto el aviso de rescate en su pantalla antes de que nadie lo confirmara internamente
• Restricciones realistas: el escenario debería negar deliberadamente algún recurso que se da por sentado — el correo corporativo no funciona porque está en el dominio cifrado, el número de la persona clave de sistemas está apagado un domingo, el proveedor de backups tarda cuatro horas en responder
• Un final abierto, no una solución oficial: el objetivo no es que el grupo llegue a la respuesta «correcta» que el facilitador tiene en mente, sino observar el proceso de decisión y documentar dónde se atasca

Conviene escribir el guion completo antes del ejercicio, con los tiempos de cada inyecto y las preguntas de seguimiento que el facilitador lanzará si la conversación no llega sola a un punto crítico. Un guion improvisado tiende a derivar hacia lo técnico y a evitar sin querer las preguntas de gobierno y comunicación, que suelen ser las más reveladoras.

4. Guion de ejemplo: crisis de ransomware

Un guion completo de tabletop de ransomware recorre las mismas fases que un incidente real, con un inyecto por fase que obliga a decidir antes de avanzar.

El guion no necesita ser más largo que esto para generar una hora y media de discusión sustanciosa. La clave no está en la cantidad de inyectos sino en que cada uno obligue a una decisión concreta con dueño identificado, no a una conversación general sobre «lo que habría que hacer».

5. Las preguntas que revientan la reunión (y por qué eso es bueno)

El valor real de un tabletop suele concentrarse en dos o tres preguntas que nadie en la sala sabe responder con seguridad. Un buen facilitador las tiene preparadas de antemano porque son las que de verdad ponen a prueba el plan, no las que confirman lo que ya se sabía.

• «¿Quién llama al CEO un domingo a las tres de la madrugada, y con qué número?» — si la respuesta tarda en llegar o depende de que alguien busque un número en un sistema que está cifrado, el plan tiene un fallo real de contacto de emergencia
• «¿Tenemos los teléfonos y contactos clave fuera del directorio activo?» — si el árbol de llamadas de crisis vive solo en el correo corporativo o en un documento de la intranet, deja de estar disponible justo cuando más se necesita
• «¿Quién decide pagar o no pagar, y con qué información?» — muchas organizaciones no tienen esta autoridad asignada por escrito hasta que se ven forzadas a improvisarla en directo
• «¿Alguien ha hablado antes con la aseguradora de ciberriesgo sobre qué cubre y qué exige (proveedores de respuesta homologados, plazos de aviso)?» — descubrir las condiciones de la póliza durante el incidente, en vez de antes, puede invalidar la cobertura
• «¿La copia de seguridad que vamos a restaurar está verificada como limpia, o solo confiamos en que lo esté?» — restaurar y reinfectar en horas es uno de los fallos más comunes de las recuperaciones apresuradas

6. Cerrar con un acta de hallazgos, no con una sensación

Un tabletop que termina con la sensación de «ha ido bien» sin nada por escrito no ha generado ningún cambio. El facilitador y el observador deberían producir un acta corta pero concreta antes de que termine la semana, mientras el ejercicio sigue fresco.

• Hallazgo: descripción breve de qué falló o qué quedó sin respuesta durante el ejercicio
• Impacto: qué habría pasado en un incidente real si ese hueco no se hubiera resuelto durante la discusión
• Acción propuesta: el cambio concreto necesario — actualizar un número de contacto, redactar una plantilla de comunicación externa, formalizar por escrito quién tiene autoridad de pago
• Dueño y plazo: una persona con nombre y una fecha, no «el equipo de seguridad» sin más — un hallazgo sin dueño tiende a desaparecer en la siguiente revisión

El acta se revisa en el siguiente tabletop: empezar la sesión repasando qué se cerró de la anterior y qué sigue pendiente es lo que distingue un programa de ejercicios con madurez creciente de una serie de eventos aislados que se repiten sin aprender nada de la vez anterior.

7. Cadencia y madurez creciente

Un único tabletop anual con el mismo guion todos los años tiene rendimientos decrecientes: los participantes memorizan la respuesta «correcta» en vez de razonarla de nuevo. La cadencia y la variedad del escenario importan tanto como el ejercicio en sí.

• Frecuencia mínima razonable: al menos una vez al año para el escenario de mayor impacto (ransomware o brecha de datos masiva), y sesiones más cortas y frecuentes centradas en un solo rol o proceso (por ejemplo, solo comunicación externa, o solo la cadena de aprobación de pago)
• Rotar el escenario: alternar ransomware con otros supuestos realistas para la organización — fuga de un proveedor crítico, compromiso de un tercero con acceso privilegiado, exfiltración sin cifrado (solo extorsión por publicación de datos)
• Subir la dificultad progresivamente: un primer ciclo de ejercicios centrado en validar que el plan existe y se conoce; ciclos posteriores que introducen restricciones más duras (el proveedor de respuesta a incidentes no está disponible, el seguro pone condiciones inesperadas)
• Incluir a la cadena de mando real, no siempre a un suplente — un tabletop donde nunca participa quien de verdad decidiría en una crisis real solo ensaya la teoría, no la práctica

Conclusión

Un plan de respuesta a incidentes que nunca se ha ensayado en voz alta con las personas que tendrían que ejecutarlo es, en la práctica, un documento sin probar: puede estar perfectamente redactado y aun así fallar el día que hace falta, porque el fallo casi nunca está en el texto sino en la coordinación entre personas bajo presión.

Un ejercicio de mesa bien preparado —con roles claros, un guion que escala la presión por fases y un acta de hallazgos con dueño y plazo— cuesta una tarde y una sala, y es la forma más barata de encontrar esos huecos antes de que los encuentre un atacante real.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)