Cómo preparar un plan de respuesta a incidentes que de verdad funcione
La mayoría de planes de respuesta se escriben para una auditoría y se leen por primera vez durante el incidente. Esta guía plantea el mínimo viable que sí se usa cuando suena el teléfono a las 3 de la mañana.
El problema no es no tener plan
Casi todas las organizaciones con las que trabajamos tienen un documento de respuesta a incidentes. Casi ninguna lo ha abierto durante un incidente real.
La razón es simple: se escribieron para pasar una auditoría, no para usarse bajo presión. Tienen cuarenta páginas, diagramas de flujo con quince cajas y referencias cruzadas a otros cuatro documentos. A las 3 de la mañana, con los servidores cifrados y el gerente general llamando, nadie abre eso.
Qué sí se usa
Un plan que funciona cabe en una página y responde cuatro preguntas:
¿A quién llamo? Nombres, teléfonos personales y un suplente para cada rol. No cargos: nombres. El teléfono de la centralita no sirve un domingo.
¿Qué apago y qué no? La reacción instintiva es desconectar todo. A veces es lo correcto; a veces destruye la evidencia que necesitarás para saber qué pasó y para la denuncia. Decidan esto antes, por escrito y por tipo de sistema.
¿Qué digo y a quién? Clientes, empleados, autoridades, prensa. Con plantillas ya redactadas. Improvisar un comunicado mientras gestionas un incidente es cómo se convierte un problema técnico en una crisis reputacional.
¿Cuándo escalo? Un umbral claro para pasar de "el equipo de TI lo está viendo" a "activamos el comité de crisis". Sin ese umbral, todo el mundo espera a que decida otro.
Las fases, en corto
El marco de referencia habitual es el del NIST (SP 800-61), que divide la respuesta en cuatro fases: preparación, detección y análisis, contención y erradicación, y recuperación con lecciones aprendidas.
Lo que casi siempre falla no es la parte técnica. Es la preparación —tener los accesos, los contactos y los respaldos probados antes— y la última fase: la reunión posterior donde se escribe qué falló y quién se encarga de arreglarlo.
Tres cosas que puedes hacer esta semana
- Escribe la página única. Las cuatro preguntas de arriba, con nombres reales. Imprímela. Que no dependa de tener acceso a la red.
- Prueba un respaldo. No revises que el trabajo de respaldo diga "correcto": restaura un archivo de verdad y ábrelo. Un respaldo que nunca se ha restaurado es una suposición.
- Haz un simulacro de 30 minutos. Sin tocar sistemas: sienta al equipo y plantea un escenario. "Son las 2 de la mañana del sábado y el ERP no responde. ¿Qué hace cada uno?" Los huecos aparecen solos.
Dónde encaja un CERT externo
Un equipo interno conoce el negocio; un CERT externo ha visto el mismo ataque en otras veinte organizaciones. La combinación importa sobre todo en las primeras horas, cuando la diferencia entre contener y propagar se decide rápido.
Si tu organización no tiene guardia 24/7, el plan debe decir explícitamente qué pasa entre las 18:00 del viernes y las 8:00 del lunes. Ese vacío es donde ocurren la mayoría de los incidentes graves.
