Las primeras 24 horas de un incidente.

La mayor parte del daño en un incidente de seguridad no proviene del atacante, sino de la respuesta: máquinas borradas antes de que nadie capturara evidencias, sistemas restaurados directamente sobre el mismo agujero, responsables a los que no se dijo nada hasta que fue una crisis. Una checklist existe para evitar eso. Esta sigue las fases de la guía de gestión de incidentes NIST SP 800-61, comprimidas en lo que hay que hacer realmente en las primeras 24 horas.

Está escrita para un equipo pequeño o una única persona responsable, la situación en la que de verdad se encuentra la mayoría de la gente cuando algo sale mal. Léela antes de necesitarla.

Fase 1 — Confirmar y registrar

Antes de actuar, establece lo que sabes. El pánico actúa; la disciplina registra primero.

• Confirma que es real. ¿Es un incidente genuino o una falsa alarma? Una sola línea de log extraña todavía no es un incidente. Corrobora antes de escalar.
• Empieza una cronología. Abre un documento y anota la hora, lo que viste y lo que hiciste, desde el primer minuto. Este registro vale más de lo que esperas, tanto para la investigación como para cualquier informe posterior.
• Anota a quién se ha informado. Decide pronto quién necesita saberlo (un responsable, un encargado de protección de datos) y registra cuándo le informaste.

Fase 2 — Contener

La contención limita el daño sin destruir las evidencias que vas a necesitar. El orden importa:

• Aísla, no borres. Desconecta la máquina afectada de la red (quita el cable, desactiva la interfaz), pero déjala encendida siempre que sea posible. Borrar destruye evidencias; aislar detiene la propagación mientras las preserva.
• Preserva la evidencia volátil. Si tienes los conocimientos, captura la memoria y el estado de los procesos en ejecución antes de que algo se reinicie. Si no, con solo no apagar el equipo ya preservas muchísimo.
• Rota las credenciales expuestas. Si hay cuentas o claves que puedan estar comprometidas, cámbialas desde una máquina de confianza y limpia, no desde la sospechosa.

Fase 3 — Erradicar y recuperar

Solo una vez que se entiende el alcance eliminas el problema y restauras el servicio:

• Encuentra primero la causa raíz. Restaurar antes de saber cómo entraron solo los invita a volver por la misma puerta. Entiende el punto de entrada.
• Reconstruye desde limpio. Cuando sea viable, restaura desde una copia de seguridad de confianza o reconstruye desde cero, en lugar de fiarte de una máquina que crees haber limpiado. "Probablemente limpia" no es un estado de seguridad.
• Verifica antes de reconectar. Confirma que el agujero está cerrado y que hay monitorización en marcha, y entonces vuelve a poner el sistema en servicio, vigilándolo de cerca.

Fase 4 — Aprender

La fase que todo el mundo se salta y que todo el mundo lamenta haberse saltado:

• Haz una revisión sin culpas. Qué pasó, qué funcionó, qué no, qué lo habría detectado antes. Sin culpas, porque la culpa a toro pasado solo enseña a la gente a ocultar los incidentes.
• Convierte los hallazgos en cambios. Cada incidente debería producir al menos una mejora concreta: una nueva regla de detección en tu SIEM, una brecha parcheada, un proceso corregido.
• Actualiza esta checklist. La mejor versión de este documento es la que has revisado después de usarlo.

Los errores que esta checklist evita

Es más fácil recordar el orden cuando sabes contra qué protege cada paso. Los cuatro errores del primer día más comunes, y más caros:

• Apagar o borrar demasiado rápido. El instinto de "limpiarlo y seguir adelante" destruye las evidencias que te dicen el alcance. Aísla en su lugar; siempre puedes reconstruir más tarde, pero no puedes deshacer el borrado de una imagen de memoria.
• Restaurar sobre el mismo agujero. Volver a poner un sistema en marcha antes de entender el punto de entrada solo reinicia el reloj para el atacante. La causa raíz va antes que la recuperación, siempre.
• El silencio. No avisar a quienes necesitan saberlo (un responsable, un encargado de protección de datos, a veces un regulador) convierte un incidente gestionado en un fallo de confianza y cumplimiento. Decide pronto la vía de notificación y regístrala.
• No dejar registro. Fiarte de la memoria en lugar de una cronología escrita. Bajo presión, la memoria es poco fiable e indefendible; un registro con marcas de tiempo es el artefacto más valioso que produces.

Fíjate en que tres de los cuatro tratan de contención, no de acción. Ese es el corazón contraintuitivo de la respuesta a incidentes: en las primeras 24 horas, el movimiento lento y disciplinado suele ganar al reflejo rápido. La checklist existe para que el movimiento disciplinado sea el predeterminado, de modo que no estés improvisando el criterio mientras la adrenalina está alta.

Adaptarla a tu situación

Es deliberadamente mínima para que encaje con un respondedor en solitario o un equipo pequeño. Una organización más grande añade más por encima (roles definidos, participación legal y de comunicación, forense formal), pero las fases no cambian, y la guía del NIST escala el mismo esqueleto hacia arriba. Empieza con esto y añade estructura a medida que crezcan tus responsabilidades, en lugar de intentar adoptar un manual de empresa que todavía no necesitas.

La idea más importante aquí es la secuencia: confirmar, contener, entender y luego restaurar, con una cronología escrita corriendo durante todo el proceso. Un incidente gestionado en ese orden es recuperable y defendible. Uno gestionado por reflejo normalmente no lo es.