Un ejercicio de simulación (tabletop) necesita una sala, un escenario, dos horas y alguien que anote lo que sale mal. No hace falta un proveedor, un presupuesto ni un plan de respuesta a incidentes terminado. Lo importante es averiguar, mientras nada está en llamas, quién decide realmente desconectar un servidor de la red y dónde se guardan los números de teléfono.
Elija un único escenario y a las personas adecuadas
Elija un solo escenario. El ransomware en un servidor de archivos y el robo de una cuenta del buzón de finanzas son los dos más útiles para un equipo pequeño, porque ambos obligan a tomar decisiones sobre aislamiento, comunicación y recuperación. No intente cubrir los dos en una misma sesión.
No tiene que redactar el escenario desde cero. Exercise in a Box, del NCSC, es gratuito, incluye ejercicios tabletop sobre temas como ransomware y phishing, y aporta material para preparar, planificar y ejecutar el ejercicio, así como para identificar las acciones posteriores. Los Tabletop Exercise Packages de CISA ofrecen objetivos de plantilla, preguntas para el debate, un formulario de valoración y un After Action Report, e incluyen escenarios de ransomware y de administración local. Utilícelos como andamiaje y adapte los detalles a sus propios sistemas.
Invite a quienes realmente estarían en la llamada:
- la persona que administra el directorio y las copias de seguridad
- quien pueda autorizar una parada del servicio (un responsable, no solo alguien de TI)
- alguien que se encargue de la comunicación externa, aunque sea el responsable de oficina
- un facilitador que no participe en el juego y no responda a preguntas
El facilitador es importante. Si la misma persona dirige el escenario y defiende su propia configuración, el ejercicio se convierte en una demostración.
La agenda de dos horas
| Tiempo | Bloque | Resultado |
|---|---|---|
| 0:00 - 0:10 | Reglas, alcance, supuestos | Hechos de partida acordados |
| 0:10 - 0:40 | Detección y triaje | A quién se avisó y en qué orden |
| 0:40 - 1:10 | Contención | Decisiones de aislamiento y quién las tomó |
| 1:10 - 1:30 | Recuperación y comunicación | Estado de las copias, mensajes a empleados y clientes |
| 1:30 - 2:00 | Revisión de carencias | Registro de carencias con responsables |
Fije una regla al comenzar: las respuestas deben ser lo que haría realmente con los accesos y las herramientas de que dispone hoy, no lo que dice la política. Si alguien dice "revisaríamos los logs", el facilitador pregunta qué logs, dónde y quién tiene acceso a ellos a las 07:40 de un lunes.
Injects para la versión de ransomware
Introduzca el escenario por pasos en lugar de todo de golpe. Una secuencia viable:
- Un usuario informa de que los documentos de una unidad compartida han cambiado de extensión y de que en cada carpeta hay un archivo de texto con una nota de rescate.
- Dos usuarios más comunican lo mismo. El servidor de archivos va lento.
- La consola de copias de seguridad muestra que la última tarea terminó, pero el servidor de backup está unido al dominio.
- La nota del atacante amenaza con publicar datos en 72 horas.
- El correo no funciona porque el conector de correo se ejecuta en un host afectado.
Cada paso lleva asociada una pregunta. ¿Quién puede aislar el host y necesita aprobación para hacerlo? ¿Se puede acceder a las copias con las mismas credenciales de administrador que podría tener el atacante? ¿Dónde está la lista de contactos si el directorio y el correo no están disponibles? ¿Quién decide si se avisa a la policía o a un regulador, y quién contacta con su aseguradora?
Injects para la versión de robo de cuenta
Comience con un usuario de finanzas que informa de solicitudes repetidas de MFA que él no ha iniciado. Después añada un inicio de sesión desde un país desconocido, seguido del descubrimiento de una regla de bandeja de entrada que reenvía el correo a una dirección externa y, por último, una factura con datos bancarios modificados enviada a un cliente. Pregunte cómo se revocan las sesiones y los tokens, y no solo cómo se restablece la contraseña. Pregunte hasta cuándo se remontan sus logs de inicio de sesión y quién revisa el buzón en busca de reglas y accesos delegados. Si desea comprobar de forma rápida si las credenciales de su personal ya aparecen en brechas públicas, nuestro verificador de contraseñas filtradas es un paso razonable antes del ejercicio.
Registre las carencias mientras están frescas
El secretario anota un registro sencillo. No lo pula durante la sesión. Una línea tiene este aspecto:
Inject 3 | Backups reachable with domain admin | Gap: backup server domain-joined,
no offline copy confirmed | Owner: infra lead | Fix by: 30 days | Severity: high
Toda carencia necesita un responsable y una fecha, o se queda en un deseo. Ordénelas según lo que les habría impedido trabajar, no según lo vergonzosas que fueran. Los hallazgos típicos son mundanos: nadie conocía el acceso al registrador de dominios, el número de guardia estaba desactualizado, la persona con autoridad para parar producción estaba de vacaciones y no tenía suplente.
Pida a los participantes comentarios por escrito antes de que se marchen. El paquete de CISA incluye una plantilla de formulario de valoración y un After Action Report, lo que le ahorra diseñar ambos.
Convierta el registro en un runbook
En el plazo de una semana, convierta el registro en un runbook breve. Basta con una o dos páginas por escenario. Un runbook que nadie lee durante un incidente es peor que no tener ninguno.
Incluya:
- La primera hora: acciones numeradas, cada una con un rol designado en lugar del nombre de una persona.
- Derechos de decisión: quién puede aislar sistemas, quién puede aprobar el pago de ayuda externa, quién habla con los clientes.
- Contactos: impresos o almacenados sin conexión, con personal, proveedores, su ISP, la aseguradora y los equipos de respuesta externos.
- Gestión de evidencias: qué no debe borrarse ni reiniciarse antes de que alguien haya tomado imágenes y logs.
- Orden de recuperación: qué sistemas se restablecen primero y qué demuestra que están limpios.
Para una estructura más amplia, la Computer Security Incident Handling Guide del NIST, SP 800-61 Rev. 2, es una referencia muy extendida, pero el NIST la retiró el 3 de abril de 2025 y la sustituyó por la Rev. 3, así que utilice la revisión vigente como referencia. Si desea una opinión externa sobre el runbook o ayuda para dirigir la sesión, consulte nuestros servicios de respuesta a incidentes y de consultoría.
A continuación, programe la repetición. Ejecute el otro escenario dentro de tres a seis meses y vuelva a probar las correcciones del primer registro de carencias.
Por dónde empezar
- Reserve dos horas esta semana y bloquee las agendas de las cuatro o cinco personas que estarían en la llamada.
- Descargue un escenario de ransomware o de phishing de Exercise in a Box o de un paquete de CISA y edítelo para que refleje sus sistemas reales.
- Nombre a un facilitador que no participe en el juego y a un secretario que lleve el registro de carencias.
- Realice la sesión con las herramientas reales abiertas: consola de backup, directorio, logs de inicio de sesión, lista de contactos.
- Asigne un responsable y una fecha a cada carencia antes de que la sala se vacíe.
- Redacte el runbook de una página en siete días y guarde una copia en un lugar al que se pueda acceder aunque su red no funcione.
