Plan de respuesta a incidentes de ciberseguridad
Cómo montar un plan de respuesta a incidentes: fases, roles, qué decidir antes de que pase, plazos de notificación y por qué conviene hacer simulacros.
Por Zyro
Casi todas las empresas acaban sufriendo un incidente de seguridad antes o después: un correo fraudulento que funciona, un equipo infectado, una cuenta comprometida. Lo que distingue a unas de otras no es que les ocurra, sino cómo reaccionan. Un plan de respuesta a incidentes es el documento que evita improvisar en el peor momento.
Qué es un incidente (y qué no)
Un evento es cualquier cosa que se observa en un sistema, como un inicio de sesión fallido. Un incidente es un evento que compromete, o puede comprometer, la confidencialidad, integridad o disponibilidad de la información o de los servicios. El plan debe definir con claridad qué se considera incidente y con qué gravedad, para saber cuándo activarlo.
Las fases de la respuesta
El modelo más extendido, recogido en la guía NIST SP 800-61, organiza la respuesta en cuatro bloques:
- Preparación: todo lo que se hace antes (este plan, las herramientas, la formación, los contactos).
- Detección y análisis: darse cuenta de que pasa algo, confirmarlo y entender su alcance.
- Contención, erradicación y recuperación: frenar la propagación, eliminar la causa y volver a la normalidad de forma segura.
- Actividad posterior: analizar qué ocurrió, qué falló y qué se mejora.
Qué debe contener el plan
Roles y responsabilidades
Una persona responsable de coordinar la respuesta (y un suplente), alguien técnico con autoridad para aislar sistemas, alguien que gestione la comunicación y un contacto legal o de protección de datos. En una empresa pequeña, una misma persona puede cubrir varios papeles, pero deben estar asignados por escrito.
Una lista de contactos que funcione sin tus sistemas
Teléfonos de quienes tienen que intervenir, del proveedor de informática, del seguro cibernético si lo hay y de los organismos de ayuda (por ejemplo, el 017 de INCIBE). Guárdala impresa o en un lugar al que se pueda acceder aunque el correo y la red estén caídos.
Criterios de gravedad y decisiones previas
Qué incidentes son menores y cuáles críticos, y qué decisiones se pueden tomar sin esperar: por ejemplo, aislar un equipo, cortar un acceso remoto o desactivar una cuenta. Decidirlo antes ahorra horas cuando importa.
Conservación de evidencias
Qué registros guardar, quién los custodia y cómo se evita alterarlos. Sin evidencias es difícil saber qué pasó, cumplir con las autoridades o reclamar al seguro.
Comunicación
- Interna: qué se cuenta al resto de la plantilla y por qué canal.
- Clientes y proveedores: cuándo y cómo se avisa a quien pueda estar afectado.
- Autoridades: las obligaciones de notificación. El RGPD exige comunicar a la AEPD las brechas de datos personales en un máximo de 72 horas, y el NIS2 prevé alerta temprana en 24 horas y notificación en 72 para las entidades incluidas.
Contener sin destruir
El impulso natural ante un problema es apagar y reinstalar. Suele ser un error: se pierden las pruebas y no se sabe cómo entró el atacante, así que puede volver a hacerlo. La contención debe ser rápida pero ordenada: aislar de la red, bloquear cuentas y accesos comprometidos, proteger las copias de seguridad y registrar cada decisión con la hora.
Recuperar con cabeza
Restaurar sistemas no es suficiente si no se elimina la causa. Antes de volver a conectar nada hay que comprobar que las copias que se restauran están limpias, cambiar credenciales (también las de servicio), corregir la vulnerabilidad por la que se entró y vigilar de cerca los sistemas recuperados durante los días siguientes.
Después: aprender sin buscar culpables
Una reunión de análisis posterior, sin ánimo de señalar a nadie, responde a cuatro preguntas: ¿qué ocurrió?, ¿cómo lo detectamos y cuánto tardamos?, ¿qué funcionó y qué no?, ¿qué cambiamos? Las respuestas se convierten en mejoras concretas con responsable y fecha.
Practica: los simulacros
Un plan que nadie ha ensayado se rompe al primer contacto con la realidad. Un ejercicio de mesa (tabletop) de una hora, en el que el equipo recorre un escenario ficticio, como "un portátil de contabilidad con ransomware", revela lagunas con un coste mínimo. Para ir más allá, los ejercicios que combinan ataque y defensa (ver purple team) miden cuánto tarda de verdad tu defensa en reaccionar.
Lo que mide la rapidez
Dos tiempos resumen la calidad de una respuesta: cuánto tardas en detectar (MTTD) y cuánto en contener (MTTR). Reducirlos depende de tener visibilidad y, cuando es posible, respuestas automáticas para lo evidente. Es la idea de la plataforma defensiva de ZyroShield, BRABUS, que puedes ver en nuestra página de ciberseguridad. Si quieres ayuda para preparar tu plan, cuéntanos tu caso.