En resumen: un ejercicio tabletop de TI simula un incidente de seguridad sobre la mesa: un moderador va dando paso a paso nueva información sobre la situación, los participantes deciden como en una emergencia real y al final queda una lista de mejoras concretas. Para servidores web resulta adecuado un escenario según el patrón de PHP2Shell, porque afecta a la vez a la técnica, las decisiones bajo incertidumbre, la protección de datos y la comunicación.
Por qué un plan solo funciona cuando se practica
Muchas empresas tienen hoy un plan de emergencia. Pero si funciona solo se ve cuando alguien lo usa bajo presión de tiempo. ¿Está dentro el número de teléfono correcto? ¿Sabe la dirección que debe decidir sobre una desconexión? ¿Conoce el proveedor de servicios los accesos? Un ejercicio sobre la mesa aclara estas preguntas en pocas horas.
La semana de octubre de 2026 mostró lo rápido que puede escalar una situación: preaviso de php.net el 20 de octubre, parches el 21 de octubre a las 16:00 hora alemana, nivel de alerta naranja del BSI (Oficina Federal alemana para la Seguridad de la Información), desconexiones de sitios web públicos según informaciones de los medios. Quien había ensayado antes esta secuencia tuvo que improvisar menos. El desarrollo en detalle lo describe la cronología de PHP2Shell. Cómo construir el propio plan se explica en Crear un plan de emergencia TI para servidores web; aquí se trata de practicarlo.
Ejercicio tabletop de TI: roles y preparación
Un buen ejercicio necesita poco material, pero roles claros. El moderador guía a través del guion, introduce la información y controla el tiempo. No discute, sino que plantea preguntas. Un acta registra las decisiones, las preguntas abiertas y cada momento en que alguien dice «eso ahora no lo sabría». Opcionalmente, otra persona observa cómo transcurre la comunicación.
Los participantes son las personas que actúan realmente en una emergencia: dirección, TI interna o proveedor externo, delegados de protección de datos, comunicación y, si hace falta, compras o el departamento jurídico. Es importante que haya suplentes, porque los incidentes no respetan los planes de vacaciones.
La preparación incluye: el plan de emergencia actual en papel, la lista de contactos, un resumen de los sitios web y servidores y una sala sin interrupciones. Establezca de antemano que se trata de aprender, no de poner notas. Quien teme hacer el ridículo no dice lo que no sabe.
Un guion listo: vulnerabilidad crítica de PHP un viernes por la tarde
El escenario siguiente es ficticio, pero se orienta en el patrón de una situación real. Adapte los sistemas y los nombres a su entorno. Cada inyección recibe de diez a veinte minutos de debate.
| Paso | Inyección del moderador | Pregunta guía para la ronda |
|---|---|---|
| 1 | La prensa especializada informa de una vulnerabilidad crítica en PHP; los parches están anunciados, pero aún no han llegado. | ¿Quién se entera primero y a quién hay que informar? |
| 2 | Los parches aparecen por la tarde. El BSI recomienda la actualización inmediata o, si no, la desconexión temporal. | ¿Cuáles de nuestros sistemas están afectados y cómo lo sabemos? |
| 3 | El proveedor de alojamiento no responde. Un servidor propio funciona con una versión de PHP sin actualización oficial. | ¿Parchear, desconectar o esperar, y quién lo decide? |
| 4 | La tienda debe lanzar una promoción el fin de semana. Ventas insiste en no desconectar nada. | ¿Cómo sopesamos ventas y riesgo y cómo documentamos la decisión? |
| 5 | Un administrador encuentra el lunes un archivo PHP desconocido en la carpeta de subidas. | ¿Qué hacemos primero y qué dejamos conscientemente? ¿Quién asegura las pruebas? |
| 6 | No está claro si se han filtrado datos de clientes. | ¿Quién valora una posible obligación de notificación y cuándo corre el plazo? |
| 7 | Una periodista pregunta por qué el sitio web está fuera de línea. | ¿Quién habla hacia el exterior y qué decimos mientras sabemos poco? |
El paso 6 toca el RGPD. En el ejercicio basta con aclarar el procedimiento: quién implica a los delegados de protección de datos y cuándo. La valoración jurídica sigue en manos de especialistas; las líneas generales sobre el plazo figuran en el art. 33 del RGPD.
Conclusiones típicas y cómo registrarlas
Ciertas lagunas aparecen en casi todo primer ejercicio. Falta una lista completa de qué sitios web se ejecutan en qué servidores y con qué versión de PHP. Los datos de contacto del proveedor de alojamiento están anticuados o solo guardados en un buzón al que no se puede acceder en caso de emergencia. Nadie sabe con certeza si la dirección puede ordenar por sí misma una desconexión o si alguien tiene que dar su aprobación.
Registre cada conclusión en tres partes: qué hemos constatado, qué vamos a cambiar y quién lo hará y para cuándo. Según la experiencia, una conclusión sin responsable se queda sin hacer. Ordene los puntos por impacto: un número de emergencia que falta se arregla rápido y ayuda de inmediato; una nueva solución de monitorización necesita planificación.
Para la evaluación estructurada tras el ejercicio sirve el mismo procedimiento que tras un incidente real. Está descrito en el artículo Lessons learned: mejorar después del incidente. La lista de contactos, que en el ejercicio suele mostrar debilidades, se trata en Contactos de emergencia: ¿a quién hay que avisar y cuándo?.
Repita el ejercicio al cabo de seis a doce meses con otro escenario, por ejemplo un sitio web hackeado con redirección a páginas ajenas. Así comprueba si las medidas de la primera ronda se han aplicado de verdad.
¿Cómo ayuda PHP SOS en concreto?
- Adaptamos el guion a sus sitios web, servidores y proveedores reales y preparamos las inyecciones.
- Moderamos el ejercicio de forma remota o por videoconferencia y nos contenemos con las valoraciones hasta que la ronda haya decidido.
- Después entregamos un acta con conclusiones, medidas, responsables y fechas.
- Si lo desea, practicamos a continuación la parte técnica, es decir, inventario, parche y búsqueda de rastros, tal como la despacha nuestra respuesta a incidentes en una emergencia.
Conclusión
Un ejercicio de emergencia sobre la mesa es el camino más económico para encontrar las debilidades de un plan de emergencia antes de que lo haga un incidente real. Una tarde, un guion realista y una evaluación honesta bastan para empezar. Lo decisivo es que de cada conclusión salga una tarea con nombre y fecha.
Preguntas frecuentes
¿Qué es un ejercicio tabletop?
Un ejercicio en el que los participantes repasan juntos un incidente sobre la mesa, sin trabajar en sistemas reales. Un moderador introduce paso a paso nueva información, y el grupo decide y justifica. Así quedan a la vista las lagunas en el plan, las responsabilidades y las listas de contactos.
¿Quién debería participar en un ejercicio de emergencia?
Todos los que en un caso real deciden o actúan: dirección, TI o proveedor de servicios, protección de datos, comunicación y, si existe, la persona responsable de las cuestiones de seguros. Más de ocho a diez personas vuelven pesada la ronda.
¿Cuánto dura un ejercicio tabletop?
Para una primera ejecución bastan dos o tres horas, incluida la evaluación. Más importante que la duración es que se registren los resultados y se asignen medidas con fecha.
¿Tiene que ser realista el escenario?
Debería encajar con su entorno, pero no tiene que ser exacto en cada detalle. Un escenario según el patrón de una situación real como PHP2Shell resulta creíble y dirige el debate hacia las decisiones en lugar de los detalles técnicos.