Skip to content
Ciberseguridad

Respuesta a incidentes: qué se decide en las primeras horas

El resultado de un incidente se decide en las primeras horas, y casi todas esas decisiones son organizativas, no técnicas: quién manda, qué se apaga, a quién se avisa y qué se dice. Prepararlas después de que empiece es lo que convierte un incidente en una crisis.

A continuación: qué se decide al principio, quién debe decidirlo, qué exige criterio y cómo se prepara antes.

Cuando se detecta actividad sospechosa, la presión es inmediata y la información escasa. Nadie sabe todavía el alcance, y aun así hay que actuar.

Los equipos que salen bien de un incidente rara vez son los que improvisan mejor. Son los que ya habían decidido, con calma, quién decide qué.

Qué se decide al principio

Si se contiene o se observa. Desconectar detiene el daño y destruye evidencia y capacidad de entender el alcance. Observar conserva ambas y deja al atacante dentro. No hay respuesta universal y hay que elegir en minutos.

Quién dirige. Un incidente con varias áreas actuando sin coordinación produce acciones que se anulan entre sí. La figura que dirige debe estar nombrada antes, con autoridad reconocida para ordenar una desconexión.

A quién se notifica y cuándo. Dirección, legal, y según el caso clientes y autoridad. El plazo no siempre es discrecional, y descubrirlo durante el incidente es tarde.

Qué se comunica. El silencio prolongado se interpreta como ocultamiento y la información prematura suele resultar incorrecta. Ambos errores cuestan, y la salida es comunicar pronto lo que se sabe y lo que aún no.

Lo que exige criterio

La decisión de contener frente a observar depende del tipo de ataque y del valor de entender el alcance. Cuando hay cifrado en curso, contener es evidente; cuando hay un acceso silencioso de origen desconocido, desconectar puede impedir saber por dónde entró y garantizar que vuelva.

La preservación de evidencia también pide criterio temprano. Apagar un equipo puede borrar información que sólo existe en memoria, y esa pérdida no se recupera. Conviene saber de antemano qué se captura antes de tocar nada.

Y hay una decisión incómoda que conviene tener conversada: hasta dónde se restablece el servicio sin entender aún la causa. Restablecer rápido sobre un sistema todavía comprometido es la forma más común de tener el mismo incidente dos veces.

Qué obligaciones acompañan

Cuando el incidente involucra datos personales, aparecen obligaciones que no dependen de la voluntad de la organización. En Colombia el marco de Habeas Data (Ley 1581) y en México la LFPDPPP condicionan qué debe informarse y a quién.

Determinar si hubo acceso a datos personales, y a cuáles, forma parte del análisis desde el principio y no al final, porque de ello dependen plazos que corren aunque el equipo técnico siga trabajando.

Conviene que legal participe desde la primera hora y no cuando el análisis técnico termine. Su intervención temprana suele cambiar qué evidencia se preserva y cómo se documenta.

Cómo se prepara antes

Escriba el directorio de crisis y manténgalo fuera de los sistemas que podrían estar comprometidos. Un contacto que sólo existe en el correo corporativo es inútil el día que el correo es el problema.

Defina los umbrales que convierten un evento en incidente y quién los declara. Sin esa definición, la organización discute si esto "ya es un incidente" mientras el reloj corre.

Y ensaye. Un ejercicio de escritorio de dos horas, con el equipo real y un escenario plausible, revela más huecos que cualquier documento: normalmente que nadie sabe quién autoriza desconectar, o que el respaldo nunca se probó para ese sistema.

Qué se necesita antes

Un responsable nombrado con autoridad para ordenar contención, un canal de comunicación alterno y una lista de sistemas críticos con su dueño. Las tres se preparan en una tarde y cambian el resultado.

Conviene también acordar con anticipación el apoyo externo. Buscar proveedor de análisis forense durante el incidente añade horas de negociación al peor momento posible.

Las tres preguntas de la primera hora

Con información incompleta y presión alta, ayuda tener un guion corto. Tres preguntas ordenan casi cualquier arranque.

¿Qué sabemos con certeza? Separar lo confirmado de lo supuesto evita que una hipótesis temprana dirija todas las decisiones siguientes. En la mayoría de los incidentes mal gestionados, el error de origen fue tratar una suposición como un hecho.

¿Qué está en riesgo ahora mismo? No qué pudo haber pasado, sino qué sistemas y qué datos siguen expuestos en este momento. Esa respuesta define qué se contiene primero.

¿Qué perdemos si esperamos una hora? Es la pregunta que resuelve el dilema entre contener y observar, porque obliga a comparar el costo de actuar con el de entender.

Después del incidente

El cierre técnico no es el cierre del incidente. Falta la revisión posterior, y conviene hacerla pronto, mientras el detalle sigue fresco y antes de que el equipo vuelva a su carga habitual.

Esa revisión busca causas y no responsables. Un ejercicio que termina señalando a una persona garantiza que el próximo incidente se reporte más tarde, que es exactamente lo contrario de lo que se necesita.

Y produce un entregable concreto: qué se cambia en el sistema, en el proceso o en el guion de respuesta. Una revisión que no cambia nada es una reunión.

¿Conviene desconectar de inmediato?

Depende. Detiene el daño y también destruye evidencia y capacidad de entender el alcance. Con cifrado en curso suele ser lo correcto; ante un acceso silencioso puede impedir saber por dónde entró.

¿Quién debe dirigir un incidente?

Alguien nombrado antes, con autoridad reconocida para ordenar una desconexión. Decidirlo durante el incidente produce acciones descoordinadas que se anulan entre sí.

¿Cuándo se comunica?

Pronto, diciendo lo que se sabe y lo que aún no. El silencio prolongado se interpreta como ocultamiento y la información prematura suele resultar incorrecta.

¿Qué prepara mejor a un equipo?

Un ejercicio de escritorio con el equipo real y un escenario plausible. Revela más huecos que cualquier documento, empezando por quién autoriza desconectar.

Andrés Lozada
Andrés Lozada
LinkedIn

Explore más de SUMāTO

Inteligencia Artificial Transformación Empresarial Consultoría Estratégica AI Agent AI Contact Center Ciberseguridad