Es posible tener un plan de respuesta a incidentes técnicamente correcto y, aun así, no estar preparado para responder.
El problema aparece cuando el documento describe qué debería ocurrir, pero las personas que tendrán que actuar no saben cómo activarlo bajo presión.
Un incidente no suele llegar con toda la información disponible. Llega como una señal incompleta: un correo extraño, una cuenta con actividad inusual, un equipo que empieza a comportarse diferente, un archivo que desaparece, una alerta que no sabemos todavía si representa un incidente real.
En ese momento el valor del plan no está en cuántas páginas tiene. Está en si ayuda al equipo a responder preguntas concretas:
- ¿quién debe enterarse primero?;
- ¿dónde queda registrado lo que sabemos?;
- ¿quién puede tomar decisiones?;
- ¿qué evidencia debemos preservar?;
- ¿cuándo cambia la severidad?;
- ¿qué escenario operativo debemos activar?;
- ¿quién autoriza una comunicación?;
- ¿qué condiciones permiten cerrar?
Si esas respuestas no están claras, el plan existe documentalmente, pero no necesariamente existe como capacidad.
El incidente empieza con incertidumbre
Una respuesta madura no asume que desde el primer minuto conoceremos causa, alcance e impacto.
Por eso me parece más útil diseñar el proceso para administrar incertidumbre que para describir un camino perfecto.
Al inicio deberíamos ser capaces de registrar al menos:
- qué fue observado;
- quién lo reportó;
- cuándo ocurrió;
- qué activo, cuenta o proceso podría estar involucrado;
- qué acciones ya se realizaron;
- qué evidencia existe;
- qué preguntas siguen abiertas.
Ese registro inicial crea un punto común de trabajo y reduce un riesgo frecuente: que cada persona responda desde su propia versión de los hechos.
Tener un canal y un sistema de registro cambia la respuesta
Cuando un evento puede llegar por cualquier canal y quedar documentado en cualquier lugar, reconstruir después lo ocurrido se vuelve difícil.
Un modelo operativo necesita definir, como mínimo:
un canal oficial para reportar y un lugar oficial para registrar.
El canal facilita que el equipo sepa dónde activar la respuesta. El registro permite construir trazabilidad: decisiones, responsables, evidencias, cambios de severidad, acciones de contención y cierre.
No es burocracia por sí misma. Es memoria operacional durante una situación en la que la información cambia rápidamente.
Los playbooks ayudan, pero no reemplazan el criterio
Me gustan los playbooks porque reducen la carga cognitiva.
Ante escenarios conocidos —phishing, cuenta comprometida, malware, ransomware, pérdida de información, acceso no autorizado, problemas de recuperación— pueden recordar al equipo qué revisar y qué evidencia preservar.
Pero un playbook no debería convertirse en un guion rígido.
Un mismo incidente puede activar varios escenarios al mismo tiempo. Un correo de phishing puede terminar en credenciales comprometidas; una cuenta comprometida puede implicar acceso a información; una indisponibilidad puede revelar un problema de recuperación.
El playbook sirve para ordenar la respuesta. El juicio técnico sigue siendo necesario para decidir qué aplica, en qué secuencia y con qué prioridad.
La evidencia debe diseñarse antes de necesitarla
Durante un incidente es fácil concentrarse únicamente en “resolver”.
Eso puede producir otro problema: después nadie puede explicar con precisión qué ocurrió, qué decisión se tomó o por qué se cerró.
Por eso considero útil definir de antemano qué evidencias forman parte del ciclo de respuesta.
Por ejemplo:
- registro inicial;
- línea de tiempo de acciones y decisiones;
- evidencia técnica relevante;
- evaluación de impacto;
- informe de cierre;
- lecciones aprendidas;
- acciones correctivas pendientes.
La línea de tiempo es especialmente valiosa. No necesita ser sofisticada. Necesita permitir reconstruir quién hizo qué, cuándo y con qué información disponible en ese momento.
Cerrar un incidente no es dejar de recibir alertas
El cierre debería ser una decisión explícita.
Antes de cerrar conviene responder:
- ¿la amenaza fue contenida?;
- ¿el servicio o activo fue recuperado cuando aplica?;
- ¿el alcance está razonablemente entendido?;
- ¿se preservó la evidencia necesaria?;
- ¿quedan obligaciones de privacidad, legales o contractuales?;
- ¿se documentaron acciones posteriores?;
- ¿hay responsables y fechas para esas acciones?
Un incidente puede estar técnicamente controlado y todavía tener trabajo pendiente.
Cerrar bien significa separar lo que ya terminó de lo que debe seguir gestionándose.
La comunicación también forma parte de la respuesta
Durante un incidente, comunicar rápido no siempre significa comunicar bien.
La información puede estar incompleta, cambiar rápidamente o involucrar datos personales, terceros, clientes o responsabilidades contractuales.
Por eso el modelo debe definir quién puede comunicar, a quién y bajo qué condiciones.
La comunicación externa no debería depender de la iniciativa individual de quien descubre el problema. Debe formar parte del proceso de escalamiento y utilizar hechos confirmados en la medida posible.
El plan debe probarse
Esta es probablemente la diferencia más clara entre tener documentación y tener capacidad.
Un ejercicio de mesa puede revelar problemas que una revisión documental no muestra:
- nadie recuerda el canal de reporte;
- la severidad se interpreta de forma distinta;
- dos personas creen tener autoridad para la misma decisión;
- nadie sabe dónde registrar evidencia;
- el playbook correcto no es evidente;
- la ruta de privacidad se activa demasiado tarde;
- el cierre no tiene un responsable claro.
Encontrar esas fallas durante un simulacro es una buena noticia. Significa que podemos corregirlas antes de depender del proceso en una situación real.
Preparación significa reducir improvisación innecesaria
Ningún plan elimina la incertidumbre de un incidente.
Tampoco debería intentar eliminar el criterio de las personas que responden.
Lo que sí puede hacer es reducir improvisación donde no aporta valor: canales, roles, registro, evidencia, escalamiento, comunicaciones y cierre.
Para mí, esa es la prueba más útil de un plan de respuesta:
¿Puede un equipo utilizarlo para tomar mejores decisiones cuando la información es incompleta y el tiempo importa?
Si la respuesta es no, todavía tenemos un documento por mejorar, no una capacidad de respuesta terminada.
Trabajo relacionado
Diseño de un modelo operativo para gestionar incidentes de ciberseguridad