Qué hacer en la primera hora de un incidente de ciberseguridad

Cuando se confirma que algo anda mal, una cuenta comprometida, un sistema cifrado, información expuesta, las primeras decisiones que se toman suelen determinar cuánto daño termina teniendo el incidente. Existe un marco ampliamente reconocido para ordenar esas primeras horas: la guía de manejo de incidentes del NIST (el instituto de estándares de Estados Unidos), organizada en cuatro grandes fases.

Las cuatro fases, resumidas

• Preparación: lo que se hizo antes de que ocurriera cualquier incidente, como tener un plan escrito y roles definidos.
• Detección y análisis: confirmar qué está pasando realmente, sin sacar conclusiones apresuradas.
• Contención, erradicación y recuperación: limitar el daño, eliminar la causa y volver a operar con normalidad.
• Actividad posterior: revisar qué pasó y qué se puede mejorar, sin buscar culpables individuales.

Lo que hay que hacer, en orden, apenas se confirma un incidente

1. Contener sin borrar nada: aislar la cuenta o el sistema afectado, pero sin apagar ni reiniciar equipos antes de preservar la evidencia, porque eso puede destruir información clave para entender qué pasó.
2. Preservar registros: guardar copias de los archivos de registro (logs) relevantes antes de que se sobrescriban automáticamente.
3. Formar hipótesis, no certezas: en las primeras horas rara vez se sabe con exactitud qué ocurrió; es normal y correcto trabajar con varias explicaciones posibles a la vez.
4. Comunicar internamente con claridad: informar a quien corresponda dentro de la organización, sin exagerar ni minimizar lo que todavía no se sabe con certeza.
5. Evaluar obligaciones legales: en muchos países, ciertos incidentes que involucran datos personales deben notificarse a una autoridad o a las personas afectadas dentro de plazos determinados. Esto requiere asesoramiento legal, no solo técnico.

Un error frecuente que agrava las cosas

Un error muy común es apagar inmediatamente el equipo afectado, pensando que así se detiene el daño. Muchas veces, esa acción borra información volátil en la memoria del sistema que habría sido clave para entender exactamente qué ocurrió y cómo evitar que se repita. Antes de cualquier acción drástica, conviene preservar lo que se pueda.

Comunicación externa: otro frente que no se puede improvisar

Además de la respuesta técnica, un incidente de cierta magnitud suele requerir comunicar algo hacia afuera, a clientes, socios o al público en general, y ese mensaje puede ser tan importante como la respuesta técnica misma. Un comunicado apresurado, con datos que después resultan incorrectos, daña la credibilidad de la organización tanto o más que el incidente original. Por eso conviene tener, incluso antes de que ocurra nada, un borrador de procedimiento de comunicación de crisis, con un único vocero designado y un canal de aprobación claro antes de publicar cualquier información hacia afuera.

El caso de Target, 2013

En 2013, la cadena minorista estadounidense Target sufrió una intrusión que expuso datos de decenas de millones de tarjetas de clientes. Según el informe del Comité de Comercio del Senado de Estados Unidos (2014), el sistema de detección de la empresa había emitido alertas tempranas sobre actividad sospechosa, pero esas alertas no fueron investigadas con la urgencia necesaria. El caso ilustra que tener buena tecnología de detección no sirve de nada sin un proceso claro de qué hacer apenas suena la alarma.

Lo que viene después de resolver el incidente

Una vez controlado el incidente, la fase de actividad posterior no debería saltarse por cansancio del equipo. Una reunión de revisión, hecha sin buscar culpables individuales sino entender fallas de proceso, suele revelar mejoras concretas y de bajo costo: quizás faltaba un procedimiento escrito, quizás una alerta existía pero nadie sabía a quién avisar, quizás el plan de comunicación no estaba definido de antemano. Documentar esas conclusiones y, sobre todo, implementar los cambios que surgen de ellas, es lo que realmente convierte un mal momento en una organización más preparada para el próximo incidente, que tarde o temprano va a ocurrir.

Practicar este proceso antes de que ocurra un incidente real, con un simulacro simple de mesa donde el equipo repasa qué haría ante un escenario ficticio, suele revelar huecos en el plan que nadie había notado, y es mucho más barato descubrirlos en un simulacro tranquilo que en medio de una crisis real, con el reloj en contra.

Fuentes: NIST, Computer Security Incident Handling Guide (SP 800-61, revisión vigente); Comité de Comercio del Senado de EE. UU., A "Kill Chain" Analysis of the 2013 Target Data Breach (2014).