6.4 · Tabletop y ejercicios de crisis

11 min de lectura · purple-team / validacion / tabletop / respuesta-incidentes / gobernanza / crisis / toma-de-decisiones · ⎙ PDF

Panorama#

El capítulo anterior cerró con una limitación: todo lo que el purple valida son controles —sensores, reglas, telemetría, la cadena técnica que convierte un comportamiento en una alerta—. Queda fuera una clase de falla que ningún control detecta y que, en una crisis real, suele decidir el resultado: quién tiene autoridad para desconectar un sistema, cuándo se declara formalmente un incidente, quién habla en nombre de la organización, y con qué se cuenta si la infraestructura de la que depende la respuesta también cayó.

El ejercicio de mesa (tabletop exercise) valida precisamente eso. Es un ejercicio de discusión: no toca la infraestructura, no ejecuta técnicas, no produce reglas. Reúne a las personas que tendrían que responder a un incidente, les presenta un escenario que se va complicando, y observa cómo deciden. Su tesis, y lo que lo separa de todo lo anterior en esta Parte, es un cambio de sujeto: los tres capítulos previos validan controles; este valida decisiones, y el sujeto ya no es el sensor sino la organización. La pregunta deja de ser «¿esto se detecta?» y pasa a ser «¿sabemos qué hacer, quién decide y con qué contamos?».

El motivo por el que esa pregunta merece un ejercicio propio es empírico: lo que falla en una crisis real rara vez es la herramienta. El EDR alertó, o no —eso ya lo validaron 6.1 a 6.3—. Lo que se rompe es más arriba y más difícil de arreglar en caliente: nadie sabía quién podía autorizar apagar el sistema de facturación, el plan de respuesta estaba en el servidor de archivos que el ransomware cifró, la persona que decidía si se paga estaba de viaje y sin cobertura, y el equipo legal se enteró por la prensa. Ninguna de esas fallas la detecta un sensor, y todas se ensayan barato en una sala de reuniones.

Dos niveles: el técnico y el ejecutivo#

Bajo el mismo nombre conviven dos ejercicios que responden preguntas distintas y que conviene no mezclar, porque el error frecuente es correr uno creyendo que se corrió el otro.

El tabletop técnico pone a prueba al equipo de respuesta: ¿tenemos los procedimientos, sabemos usarlos, nos coordinamos? El escenario baja al detalle operativo —qué se aísla primero, cómo se preserva la evidencia, en qué orden se contiene— y su valor es descubrir procedimientos ausentes, contradictorios o que asumen accesos que el incidente elimina. Es el complemento en frío del ciclo de respuesta que 5.4 desarrolló; no lo reexplica —el ciclo NIST, la regla del tempo y la recuperación ya están allí— sino que verifica que el equipo sabe ejecutarlo bajo presión y con información incompleta.

El tabletop ejecutivo o estratégico pone a prueba a la dirección, y su materia no son los procedimientos sino las decisiones que solo la dirección puede tomar: cuándo se declara una crisis, quién asume el mando, qué se comunica y a quién, si se paga o no, si se interrumpe una línea de negocio. En este nivel el detalle técnico es deliberadamente secundario —al director financiero no le toca decidir qué comando ejecutar— y lo que se valida es la cadena de autoridad y la calidad de las decisiones bajo incertidumbre. Un programa maduro corre los dos, y a veces los conecta: el escenario técnico escala hasta que dispara una decisión que solo el nivel ejecutivo puede tomar, y ahí se ve si la transición entre ambos existe o si el equipo técnico se queda esperando una autorización que nadie sabe dar.

El plan que asume su propia infraestructura viva#

Hay un modo de fallo tan común que merece sección propia, y el tabletop es el lugar donde se descubre sin pagar el precio de descubrirlo en la crisis: el plan de respuesta que depende de la infraestructura que el incidente derriba. Los contactos de emergencia en un directorio corporativo que quedó inaccesible; el manual de respuesta —el runbook— en el servidor de archivos que el ransomware cifró; las credenciales de acceso al proveedor de respuesta en el gestor que también cayó; el canal de comunicación interno que corre sobre el mismo dominio comprometido.

Es exactamente el patrón que 5.4 identificó en dos formas: el plan rígido que WannaCry volvió inútil porque asumía condiciones que el ataque eliminó, y el backup que no sirve si está en línea y el ransomware lo alcanza junto con todo lo demás. La lección se generaliza: un plan de respuesta tiene que asumir que la infraestructura normal no está disponible, y por eso los contactos, los runbooks y las credenciales críticas viven también fuera de banda —en papel, en un sistema independiente, en un dispositivo que no comparte el destino del que se está defendiendo—.

La prueba que casi ningún plan pasa la primera vez. En el ejercicio, cuando el escenario establece que el dominio está comprometido y los sistemas de archivos cifrados, se hace una pregunta simple: ¿cómo se contacta ahora al proveedor de respuesta, y dónde está el runbook? La respuesta honesta, la primera vez, suele revelar que ambos están dentro de lo que acaba de caer. Ese hallazgo —barato en una sala, carísimo a las tres de la mañana de un incidente real— es de los que más justifican el ejercicio. La corrección es aburrida y efectiva: una copia fuera de banda de la lista de contactos, el runbook y las credenciales de emergencia, verificada periódicamente como cualquier otro control sujeto al drift de 6.1.

Las decisiones incómodas se ensayan en frío#

El aporte central del tabletop ejecutivo es forzar, en un momento sin consecuencias, decisiones que en la crisis real se toman bajo presión, con información parcial y sin tiempo para deliberar. Ensayarlas en frío no produce la respuesta correcta —muchas no la tienen— sino algo más útil: establecer de antemano quién decide y con qué criterios, para que en el incidente la discusión sea sobre los hechos y no sobre la autoridad.

Cuatro de esas decisiones aparecen en casi todo escenario serio. Pagar o no un rescate: una decisión con aristas legales, éticas, financieras y reputacionales que no puede improvisarse mientras un temporizador corre. Notificar al regulador: muchas jurisdicciones imponen plazos estrictos desde el momento en que se conoce una brecha de datos, y el reloj empieza antes de que se entienda el alcance —quién decide que el umbral se cruzó, y con qué asesoría, se define antes—. Comunicar públicamente: qué se dice, cuándo y quién lo dice, sabiendo que el silencio y la sobreexposición tienen costos distintos y que la primera versión condiciona todo lo que sigue. Y contener aunque interrumpa el negocio: desconectar el sistema comprometido puede detener la facturación, la producción o el servicio, y esa es una decisión de negocio, no técnica.

Ese último punto merece precisión porque conecta con un capítulo previo. La regla del tempo de 5.4 —contener solo con el alcance acotado, de forma completa y simultánea, para no alertar al adversario con una remediación prematura— se presentó allí como una decisión técnica de respuesta. Vista desde aquí es, en buena parte, una decisión ejecutiva disfrazada de decisión técnica: elegir el momento de contener implica sopesar la interrupción del negocio contra el riesgo de que el adversario avance, y ese balance no lo puede ni lo debe cargar en soledad el analista de turno. El tabletop es donde se descubre que esa decisión no tenía dueño, y donde se le asigna uno antes de necesitarlo.

flowchart TB
  DET["Incidente detectado\n(6.1–6.3 validaron\nque llega hasta aquí)"] --> DECL{"¿Se declara\ncrisis?\n¿quién?"}
  DECL --> CONT{"¿Contener ahora\naunque pare el\nnegocio?"}
  CONT -->|"decisión ejecutiva,\nno del analista"| OWN1["dueño: dirección\n+ criterio previo\n(tempo de 5.4)"]
  DECL --> REG{"¿Notificar al\nregulador?\n(plazo corriendo)"}
  REG --> OWN2["dueño: legal\n+ umbral definido\nantes"]
  DECL --> COM{"¿Comunicar\npúblicamente?\n¿quién habla?"}
  COM --> OWN3["dueño: comunicación\n+ vocero único"]
  DECL --> PAY{"¿Pagar\nrescate?"}
  PAY --> OWN4["dueño: dirección\n+ postura previa\n(legal/ético/seguro)"]
  OWN1 --> AAR["After-action:\nlagunas → dueños\ny fechas"]
  OWN2 --> AAR
  OWN3 --> AAR
  OWN4 --> AAR

Dependencias externas: el proveedor que también puede caer#

Una crisis rara vez se resuelve solo con recursos propios, y el tabletop expone las dependencias externas que el plan da por sentadas. El proveedor de respuesta a incidentes contratado por adelantado —el retainer de DFIR— puede tener un tiempo de activación de horas, no de minutos, y una cláusula sobre qué cubre y qué no. La aseguradora cibernética puede exigir notificación y aprobación previa de ciertos gastos, de modo que actuar sin avisarle compromete la cobertura. El proveedor de nube, el operador de telecomunicaciones o un servicio del que depende la operación pueden estar caídos por el mismo evento —o ser ellos el origen—. Ensayar «¿qué hacemos si el proveedor no responde en la ventana que asumimos?» convierte una dependencia invisible en un plan de contingencia, o al menos en una expectativa realista sobre los tiempos.

Aquí encaja también una dimensión que 5.9 señaló para el caso del insider y que aplica más allá de él: cuando el incidente involucra a una persona —un empleado desleal, un acceso a investigar— la respuesta técnica se subordina a la jurídica y la de recursos humanos. La regla de preservar antes de confrontar, y de mantener a las áreas legal y de personal informadas en silencio, es una decisión de gobernanza que el tabletop ensaya: un caso bien resuelto en lo técnico pero mal manejado en lo procesal no se sostiene después, por sólida que sea la evidencia.

Conducción y cierre del ejercicio#

Un tabletop se conduce con un escenario que arranca simple y se complica mediante inyecciones (injects): datos nuevos que el facilitador introduce en momentos elegidos —«ahora los medios están llamando», «ahora se confirma que hay datos de clientes en el volcado», «ahora el proveedor de respuesta dice que tardará seis horas»— para empujar al grupo hacia los puntos de decisión. El facilitador no busca que el grupo acierte: busca que las lagunas afloren, y por eso las mejores inyecciones son las que rompen los supuestos cómodos. Un observador registra no las respuestas correctas sino dónde se dudó, quién no sabía que le tocaba decidir, y qué información faltó.

El ejercicio termina, como el purple de 6.3, con un cierre que produce compromisos, no un acta. Cada laguna detectada se convierte en una acción con dueño y fecha: un contacto que hay que sacar fuera de banda, una autoridad que hay que definir por escrito, un plazo regulatorio que nadie conocía. Sin esa asignación, el tabletop degenera en la misma quinta salida tácita que 6.1 proscribió —el hallazgo registrado sobre el que nadie actúa— con el agravante de que aquí lo que quedó sin dueño no es una regla de detección sino una decisión de la que puede depender la supervivencia de la organización.

Postura#

Correr los dos niveles: el tabletop técnico valida procedimientos y coordinación; el ejecutivo valida autoridad y decisiones. No son intercambiables.
Asumir la infraestructura caída: contactos, runbooks y credenciales de emergencia fuera de banda, verificados periódicamente contra el drift.
Predecidir las decisiones incómodas —pago, notificación regulatoria, comunicación, contención con impacto de negocio— asignando dueño y criterio antes de la crisis.
Reconocer la contención como decisión ejecutiva cuando interrumpe el negocio: la regla del tempo de 5.4 necesita un dueño que no sea el analista de turno.
Ensayar las dependencias externas: retainer de DFIR, seguro, proveedores, con expectativas realistas de tiempo y las cláusulas que condicionan la cobertura.
Cerrar con dueños y fechas, no con un acta. Una laguna sin responsable es una decisión que en la crisis no tendrá quién la tome.

Cierre#

Con el tabletop, la validación completa su alcance: valida los controles que detectan (6.1–6.3) y valida las decisiones que se toman cuando la detección se convierte en crisis. El sujeto se amplió del sensor a la organización, y la disciplina se mantuvo —convertir supuestos en datos, cerrar cada hallazgo con un dueño—, solo que el supuesto que aquí se pone a prueba no es «esta regla dispara» sino «alguien sabe qué hacer y tiene la autoridad para hacerlo».

Queda una última pieza de la Parte, y devuelve el foco de las decisiones a los activos. Todo lo anterior valida qué tan bien se detecta y se decide frente a un adversario; falta ordenar el otro extremo —qué exposiciones existen, cuáles importan y en qué orden se cierran—, que es la diferencia entre escanear vulnerabilidades y gestionar la exposición real. Es el tema del capítulo 6.5, que cierra la Parte 6.

Referencias#

blue-dfir/defenders-advantage/cap-07 — Validate: los ejercicios de mesa como simulaciones basadas en discusión —estratégicas y técnicas— para evaluar las capacidades de respuesta del personal y afinar los procesos, distinguidas de las formas de validación que ejercitan controles técnicos.
La distinción operativa entre el tabletop técnico y el ejecutivo, el modo de fallo del plan que asume su propia infraestructura viva, el catálogo de decisiones que se ensayan en frío —pago, notificación regulatoria, comunicación, contención con impacto de negocio—, el tratamiento de las dependencias externas y la mecánica de conducción con inyecciones y observador son enriquecimiento propio.
El ciclo de respuesta a incidentes que este capítulo ejercita sin reexplicar está en 5.4 —incluidos la regla del tempo, aquí releída como decisión ejecutiva, y las lecciones de WannaCry y del backup fuera de línea—. La dimensión jurídica y de personal se apoya en el caso del insider de 5.9. El nivel estratégico como consumidor de inteligencia remite a 1.1, y el panorama de amenazas que alimenta los escenarios, a 1.6.

Mencionado en

6.1 · La función de validación: por qué un control no probado no existeEl capítulo que abre la Parte 6. Sostiene que sin validación una organización opera sobre supuestos —instalar cámaras sin verificar que graban—, que el enemigo silencioso es el drift de configuración porque la defensa se degrada sin que nadie lo decida, y que la asimetría temporal entre lo que tarda el adversario en comprometer y lo que tarda la defensa en advertirlo es lo que obliga a validar la detección y no solo la prevención. Incluye la taxonomía de ejercicios —pentest, red team, purple, simulación automatizada y tabletop— con qué pregunta responde cada uno y cuál no.
6.3 · El ejercicio purple: ciclo, instrumentación y cierre del lazoEl núcleo operativo de la Parte 6. Sostiene que el valor del ejercicio purple no está en descubrir que algo no se detecta —eso también lo hace un red team— sino en que la corrección y la re-ejecución ocurren dentro del mismo ejercicio: la re-ejecución es el paso que casi nadie da y el único que convierte un hallazgo en una mejora. Recorre los cuatro resultados posibles de cada prueba y por qué el registrado-pero-no-alertado es el más valioso, la instrumentación previa, el ciclo iterativo, la detección como código validada en CI, la trampa de la matriz de cobertura, el entregable —reglas, no informes— y la salida que el cierre del lazo rechaza: aceptar el riesgo sin dueño ni fecha.
6.5 · Gestión de exposición: de la vulnerabilidad al camino de ataqueEl capítulo que cierra la Parte 6. Sostiene una tesis doble: un escáner sin ciclo de remediación no produce seguridad sino ruido con apariencia de diligencia, y el salto de madurez no es escanear mejor sino dejar de puntuar hallazgos aislados para empezar a evaluar caminos de ataque —una vulnerabilidad media en un host que da acceso a las credenciales de dominio importa más que una crítica en un equipo aislado, y el CVSS no lo puede ver porque no conoce la topología—. Recorre el ciclo de gestión de vulnerabilidades, la velocidad como variable dominante, la priorización por explotación activa frente al CVSS estático, y la gestión de caminos de ataque como generalización de lo que BloodHound hizo para Active Directory. Cierra la Parte devolviendo el foco a la validación: el parche que se cree aplicado también es un supuesto.
7.1 · El marco de gobernanza: NIST CSF 2.0 y la función GOVERNEl capítulo que abre la Parte 7. Sostiene que la ciberseguridad no es un dominio técnico aislado sino un componente de la gestión de riesgo empresarial, y que el NIST CSF 2.0 ofrece una taxonomía de resultados —qué lograr, no cómo— cuya innovación estructural, la función GOVERN, es exactamente la capa que el manual no había construido: todo lo anterior implementó las cinco funciones operativas —identificar, proteger, detectar, responder, recuperar—, y GOVERN es el techo que las decide, las financia y las rinde. Presenta la jerarquía del Core, los perfiles organizacionales como instrumento de análisis de brechas que consume la validación de la Parte 6, y los cuatro Tiers de madurez como una decisión de apetito de riesgo, no como una escalera donde más siempre es mejor.
7.2 · Riesgo, política y cadena de suministro (C-SCRM)El capítulo que baja de la taxonomía del marco a la función GOVERN en detalle. Sostiene que la gobernanza traduce el apetito de riesgo de la dirección en autoridad, política y presupuesto, y que sin esa capa las decisiones operativas —qué se parchea, qué se acepta, quién desconecta— se toman sin mandato y no se sostienen: es la diferencia entre «el analista decidió» y «la organización decidió». Recorre las seis categorías de GOVERN —contexto organizacional, estrategia de riesgo, roles y autoridades, política, supervisión y gestión del riesgo de la cadena de suministro—, aterriza el apetito de riesgo en las cuatro salidas de la validación de la Parte 6, señala el modo de fallo político de las métricas que solo saben subir, y cierra con C-SCRM como la superficie que no se controla directamente y que solo se gobierna por contrato y monitoreo del ciclo de vida del proveedor.
7.3 · El programa de amenaza interna (IRMP)El capítulo que aplica la gobernanza a su caso más incómodo: el adversario que ya está adentro con acceso legítimo. Sostiene que la amenaza interna no se elimina sino que se gestiona con un programa estructurado, multidisciplinario y basado en evidencia —un Insider Risk Management Program, IRMP—, y que a diferencia del atacante externo el insider no se frena en el perímetro sino con least privilege y con la correlación de señales entre dominios que ninguna área ve completa sola: IT, recursos humanos, legal y seguridad física. Presenta los seis arquetipos de incidente y el ciclo de vida del empleado como eje temporal —con el despido y la renuncia como los desencadenantes empíricos más frecuentes—, distingue gestión de riesgo de vigilancia, y recorre las tres primeras prácticas del CERT: inventariar los activos críticos, formalizar el programa con patrocinio de la dirección, y aplicar los controles administrativos con una consistencia que es a la vez control preventivo y prueba jurídica. Enlaza la detección técnica a la Parte 5 y la crisis a la Parte 6 sin rehacerlas.