Simulacro de ciberseguridad: cómo ejecutar un tabletop útil

Define una decisión y un servicio crítico antes del escenario

Un simulacro de ciberseguridad resulta útil cuando prueba decisiones que la empresa tendría que tomar durante un incidente. El punto de partida no es inventar el ataque más espectacular, sino elegir un servicio de negocio y una duda real: quién declara la crisis, qué proceso se detiene, cómo se informa a dirección, cuándo se llama a un proveedor o qué evidencia permite iniciar la recuperación. Si el objetivo solo dice «mejorar la respuesta», después no podrá comprobarse qué funcionó.

La pregunta concreta es: ¿qué decisión quieres observar? El objetivo se redacta como una capacidad verificable. Por ejemplo: validar que el equipo identifica al responsable de activar el plan, que obtiene una situación común en un canal autorizado y que decide si una aplicación puede seguir operando. NIST SP 800-84 diferencia formación, ejercicios y pruebas; una conversación puede ejercitar un plan, pero no demuestra que un sistema se restaure. Esa distinción evita presentar el resultado con más alcance del que tiene.

Después se fija el alcance: servicio, sedes, procesos, participantes, duración y supuestos. Un escenario de ransomware puede limitarse al ERP y a los documentos compartidos, mientras correo y telefonía siguen disponibles; otro puede suponer que el proveedor principal no responde. Esos supuestos condicionan todas las decisiones. Deben entregarse al inicio o aparecer como información del ejercicio, no cambiarse para atrapar a los participantes.

Los perfiles se eligen por su responsabilidad real. Tecnología puede analizar y contener; operaciones valora si el servicio puede continuar; dirección acepta prioridades; comunicación prepara mensajes; el área jurídica o de protección de datos revisa obligaciones dentro de su competencia. Si una función está externalizada, se representa cómo se contactaría con el proveedor. No conviene asignar durante el ejercicio poderes que esas personas no tendrían en una crisis real.

Antes de empezar se acuerda qué quedará fuera. Un tabletop no envía malware, no prueba credenciales, no corta servidores y no sustituye un pentest, una restauración ni una evaluación legal. Tampoco exige compartir contraseñas o datos personales para dar realismo. El alcance y los límites protegen producción y permiten que las conclusiones sean honestas.

Elige entre tabletop y simulación técnica sin mezclar objetivos

INCIBE distingue el tabletop, la simulación en paralelo y la interrupción total. El tabletop es ejecutivo y teórico: presenta una situación y permite debatir la respuesta sin interrumpir la operación normal. La simulación en paralelo utiliza un entorno controlado para practicar un componente o proceso. La interrupción total recrea una pérdida grave de operatividad y necesita una planificación mucho más exigente para controlar su impacto.

La elección depende de la pregunta. Si se quiere saber quién autoriza una desconexión, qué canal reúne al equipo o cómo se eleva una decisión, el tabletop permite observar coordinación. Si la duda es si una copia restaura una base o si la telefonía de contingencia funciona, hace falta una prueba técnica controlada. Conversar sobre la restauración puede descubrir que nadie conoce al propietario, pero no mide su duración ni su integridad.

La empresa puede avanzar de menor a mayor impacto: primero discutir el plan, después probar componentes concretos y, cuando exista preparación suficiente, ensayar una operación más amplia. Esa secuencia es un criterio prudente, no una obligación universal. Cada ejercicio mantiene objetivos, autorización, entorno, condiciones de parada y responsables propios.

Mezclar modalidades sin indicarlo genera falsas conclusiones. Un participante que describe correctamente una llamada no ha demostrado que el número esté actualizado. Un equipo que restaura una máquina aislada no ha validado el proceso de crisis completo. El informe separa lo conversado, lo observado y lo probado para que dirección no convierta una sesión formativa en una garantía técnica.

Diseña injects, roles y reglas que permitan observar decisiones

El escenario necesita un estado inicial coherente: qué servicio falla, qué se conoce, qué herramientas siguen disponibles y qué hora del negocio representa. ENISA recomienda alinear la historia con los objetivos y el panorama de amenazas de la organización. Un fabricante, una asesoría y un centro comercial no comparten las mismas dependencias. El caso debe ser plausible para sus procesos, sin copiar un incidente ajeno que obligue a inventar decisiones irrelevantes.

La historia avanza mediante injects: piezas de información que llegan en un orden previsto. Pueden ser una alerta del sistema, una llamada simulada de un proveedor, una consulta de un cliente, una captura preparada o un mensaje interno identificado como ejercicio. Cada inject existe para activar una decisión relacionada con el objetivo. La lista maestra recoge momento, destinatario, contenido, respuesta esperada y criterio de observación; ENISA la denomina Master Scenario Events List o MSEL.

Un buen inject no contiene la respuesta. Si el ejercicio entrega desde el principio un informe perfecto con causa, alcance y activos afectados, no prueba cómo el equipo obtiene una situación común. La información debe ser suficiente para avanzar y permitir que los participantes pidan datos adicionales. El facilitador puede ajustar el ritmo cuando una decisión abre un camino no previsto, pero no cambia los hechos para forzar el desenlace que esperaba.

La facilitación y la observación se separan. CISA describe el tabletop como una discusión guiada, y ENISA pide que quien facilita mantenga el flujo sin conducir a una respuesta predeterminada. Los observadores registran acciones y decisiones sin corregirlas durante la sesión. Quienes han diseñado todos los detalles del escenario no deberían actuar como participantes principales porque conocen información que el equipo real no tendría.

Las reglas de juego se comunican antes: canales autorizados, marca visible de «ejercicio», datos sintéticos, sistemas que no se tocarán, tratamiento de información sensible y palabra de parada. Nadie envía avisos reales a clientes, reguladores, emergencias o proveedores. Si una acción exigiría una comunicación externa, se registra la decisión y se entrega al facilitador en el canal simulado. Así se practica el proceso sin crear una alarma verdadera.

Convierte las observaciones en acciones con propietario y verificación

El cierre comienza con una revisión inmediata. Los participantes explican qué información tuvieron, qué decisiones tomaron y dónde encontraron fricción. Los observadores aportan la cronología. Se separan tres tipos de hallazgo: una capacidad que funcionó, una carencia del plan o la organización y un defecto del propio ejercicio. Si un inject era ambiguo, no debe presentarse como fallo del equipo.

El informe posterior conserva alcance, objetivos, supuestos y límites. Para cada observación cita la evidencia disponible: una decisión sin propietario, un canal desconocido, un contacto desactualizado, una aprobación que nadie podía emitir o una dependencia no inventariada. CISA orienta el resultado hacia un informe posterior y un plan de mejora; ENISA insiste en convertir los hallazgos en acciones concretas y medibles.

Cada mejora necesita responsable, fecha y forma de verificación. Actualizar una lista de contactos se comprueba llamando por el canal de prueba acordado; aclarar una autoridad se valida en el plan aprobado; preparar una restauración exige después una prueba técnica. «Mejorar la comunicación» no es una acción cerrable. Tampoco conviene usar un tiempo universal para calificar al equipo si la empresa nunca había definido ese requisito.

Las conclusiones se distribuyen según audiencia. Dirección necesita impacto, decisiones bloqueadas y prioridades; los equipos operativos necesitan tareas y procedimientos; quienes planifican necesitan corregir el escenario y la observación. Los detalles sensibles no se copian en presentaciones generales. La documentación debe ayudar a actuar, no exponer configuraciones ni convertir errores individuales en señalamientos.

El ciclo termina cuando se verifica la mejora. Puede repetirse una parte del escenario, probar un canal, ejecutar una restauración controlada o realizar otro tabletop con una variante. Élite Solutions Tech puede ayudar desde Murcia a preparar formación en ciberseguridad y ejercicios de mesa adaptados a procesos empresariales, con objetivos, materiales, observación y entregables acordados. Para una primera valoración puedes indicar el servicio crítico, los perfiles participantes y la decisión que quieres practicar en el formulario de contacto, sin enviar credenciales ni información confidencial.