Cuando suena la alarma de un compromiso de seguridad, las primeras horas deciden si la organización gestiona un incidente controlado o una crisis abierta. La respuesta a incidentes (Incident Response, IR) y la forense digital son las disciplinas que convierten ese caos inicial en un proceso ordenado: contener el daño, entender qué ocurrió y preservar las evidencias con validez probatoria. Este artículo recorre el ciclo de vida del IR, los principios forenses que sostienen la cadena de custodia y las obligaciones legales que en 2026 hacen de la notificación un asunto regulado, no opcional.
El ciclo de vida de la respuesta a incidentes
El marco de referencia más extendido es el del NIST, en su guía SP 800-61, que estructura el IR en cuatro fases iterativas: preparación; detección y análisis; contención, erradicación y recuperación; y actividad post-incidente. SANS describe seis fases con un detalle similar. Lo importante no es el número de etapas sino entender que el IR es un bucle: lo aprendido en un incidente alimenta la preparación del siguiente.
- Preparación: es la fase más rentable y la más descuidada. Incluye el plan escrito, los manuales de actuación (playbooks) por tipo de amenaza, la formación del equipo (CSIRT), el inventario de activos y la instrumentación de telemetría. Un equipo que improvisa durante el incidente ya ha perdido.
- Detección y análisis (triage): distinguir el evento real de la avalancha de alertas. Se prioriza por impacto en el negocio y alcance del compromiso.
- Contención, erradicación y recuperación: aislar lo afectado, eliminar la persistencia del atacante y restaurar el servicio verificando que la amenaza ya no está presente.
- Lecciones aprendidas: la reunión post-mortem sin culpas que documenta qué falló y qué controles añadir.
Triage: priorizar bajo presión
El triage es el arte de decidir rápido con información incompleta. Tres preguntas guían la priorización: ¿qué sistemas están afectados y cuál es su criticidad para el negocio?, ¿el atacante sigue activo dentro de la red?, y ¿hay datos personales o regulados comprometidos? Una infección de ransomware en un servidor de ficheros de producción con datos de clientes es un incidente de severidad máxima; una baliza de malware en un equipo de pruebas aislado, no. La matriz de severidad debe estar definida en la fase de preparación, porque calibrarla en caliente lleva a errores caros. Un principio operativo clave es no apagar las máquinas comprometidas de inmediato: hacerlo destruye la memoria volátil, donde a menudo reside la evidencia más valiosa.
Forense digital y el orden de volatilidad
La forense digital adquiere, preserva y analiza evidencia electrónica de forma que sea admisible y reproducible. Su principio rector es el orden de volatilidad, definido en el RFC 3227: se recolectan primero los datos más efímeros. La jerarquía habitual es:
| Prioridad | Fuente de evidencia | Volatilidad | Herramienta típica |
|---|---|---|---|
| 1 | Registros de CPU, caché, tabla de rutas, conexiones de red activas | Segundos | Comandos del sistema, scripts de recolección |
| 2 | Memoria RAM (volcado completo) | Hasta el apagado | Volatility, FTK Imager, LiME |
| 3 | Procesos en ejecución y ficheros temporales | Minutos a horas | osquery, EDR |
| 4 | Disco (imagen bit a bit) | Persistente | dd, Guymager, write blocker |
| 5 | Logs centralizados y backups | Días a meses | SIEM, almacenamiento WORM |
El análisis de RAM con un marco como Volatility permite reconstruir procesos maliciosos que nunca tocaron el disco —el llamado malware fileless—, recuperar claves de cifrado en memoria y mapear conexiones de mando y control. La imagen de disco se obtiene siempre mediante un bloqueador de escritura (write blocker) para garantizar que el original no se altera durante la copia.
La forense no se limita a los discos y la memoria de los endpoints. Las fuentes de evidencia se han multiplicado: los registros de los proxies y cortafuegos revelan el tráfico de exfiltración; los logs de autenticación del directorio activo muestran movimientos laterales y escaladas de privilegios; en entornos cloud, los registros de auditoría de la plataforma —quién creó qué recurso, desde qué IP y con qué credenciales— suelen ser la pieza clave para reconstruir un compromiso que nunca tocó un servidor físico. La forense en la nube añade un reto particular: la evidencia es efímera y compartida, por lo que activar y preservar el registro de auditoría antes del incidente es decisivo. Una organización que descubre, en mitad de la investigación, que sus logs cloud solo se retienen siete días, ha perdido la mayor parte de la historia que necesitaba contar.
Reconstrucción de la línea temporal y atribución
El producto central de una investigación forense es la timeline: una cronología unificada que ordena cada artefacto —creación de ficheros, ejecuciones de procesos, conexiones de red, eventos de autenticación— en una secuencia coherente. Herramientas como Plaso y su motor log2timeline fusionan marcas de tiempo de decenas de fuentes en un único hilo que permite responder a las preguntas que importan: cuándo entró el atacante (el vector inicial), qué hizo a continuación, qué datos tocó y cuándo se le detectó. La fiabilidad de esa cronología depende por completo de la sincronización horaria: si los relojes no apuntan a una fuente NTP común, las marcas de distintos sistemas no se pueden alinear y la reconstrucción se vuelve conjetura.
La atribución —determinar quién está detrás— es deliberadamente prudente en forense seria. En lugar de señalar nombres, se mapea el comportamiento observado contra marcos como MITRE ATT&CK para caracterizar al adversario por sus tácticas y técnicas, y se contrasta con inteligencia de amenazas para asociarlo, con grados de confianza explícitos, a campañas conocidas. La atribución precipitada es una trampa habitual: lleva a conclusiones que no resisten un contrainterrogatorio y que pueden desviar toda la respuesta hacia el sospechoso equivocado.
Cadena de custodia: la integridad como requisito legal
La cadena de custodia es el registro documental ininterrumpido de quién ha tenido acceso a cada evidencia, cuándo, dónde y con qué fin, desde su adquisición hasta su presentación. Si se rompe, la evidencia pierde valor probatorio aunque sea técnicamente correcta. Los pilares son:
- Hashing criptográfico: se calcula un resumen SHA-256 de cada imagen en el momento de la adquisición y se verifica en cada copia posterior. Si el hash coincide, la evidencia es idéntica al original; si no, ha sido manipulada.
- Trabajo sobre copias: el análisis nunca se realiza sobre la evidencia original, sino sobre una copia verificada, preservando la fuente intacta.
- Documentación completa: formularios de custodia firmados en cada transferencia, con fecha, hora y responsable.
- Almacenamiento seguro: acceso restringido y registrado a la evidencia almacenada.
Errores comunes
El primero y más grave es actuar sobre el sistema vivo sin recolectar la memoria: reiniciar o apagar borra evidencia volátil irrecuperable. El segundo es analizar el original en lugar de una imagen, contaminando la única copia auténtica. El tercero es no sincronizar relojes: si las marcas de tiempo de distintos sistemas no están alineadas con una fuente NTP fiable, reconstruir la cronología del ataque se vuelve imposible. El cuarto es comunicar mal: avisar al atacante sin querer (cambiando contraseñas de forma visible antes de tener el cuadro completo) o, al contrario, notificar tarde a las autoridades incumpliendo los plazos legales.
Obligaciones de notificación: NIS2 y RGPD
En 2026 la notificación de incidentes ya no es discrecional. La Directiva NIS2 (UE 2022/2555), traspuesta a las legislaciones nacionales, obliga a las entidades esenciales e importantes a notificar a su CSIRT nacional un incidente significativo con una alerta temprana en un plazo de 24 horas y un informe completo en 72 horas. De forma paralela, cuando el incidente implica una violación de datos personales, el RGPD impone notificar a la autoridad de control —la AEPD en España— en un plazo máximo de 72 horas desde que se tiene conocimiento, e informar a los afectados si existe alto riesgo para sus derechos. Estos plazos transforman la velocidad del triage en una cuestión de cumplimiento legal, y refuerzan por qué la fase de preparación debe incluir los procedimientos de notificación ya redactados.
Preguntas frecuentes
¿Necesito un equipo forense interno o puedo externalizarlo?
Muchas organizaciones combinan un CSIRT interno para el triage y la contención con un proveedor especializado para la forense profunda y la pericial. Lo crítico es que los contratos de retención estén firmados antes del incidente, no negociados durante la crisis.
¿Qué diferencia hay entre un IOC y un TTP?
Un indicador de compromiso (IOC) es un dato concreto —un hash, una IP, un dominio— que delata una intrusión conocida. Las tácticas, técnicas y procedimientos (TTP), catalogados en marcos como MITRE ATT&CK, describen el comportamiento del atacante y son mucho más difíciles de evadir que un simple cambio de IP.
¿Cuánto tiempo debo conservar la evidencia?
Hasta que prescriban las posibles acciones legales y se cierren las obligaciones regulatorias, lo que suele implicar varios años. La política de retención debe definirse con asesoría jurídica.
¿El cifrado de los discos complica la forense?
Sí, si el sistema está apagado. Por eso la adquisición de memoria en caliente es tan valiosa: las claves de cifrado de volúmenes montados suelen residir en RAM mientras el equipo está encendido.
Conclusión
La respuesta a incidentes no se demuestra el día del ataque, sino en los meses previos de preparación silenciosa: playbooks ensayados, telemetría desplegada, relojes sincronizados y procedimientos de custodia y notificación escritos. La forense digital añade el rigor que convierte una sospecha en evidencia admisible, y la cadena de custodia es lo que sostiene esa evidencia ante un juez o un regulador. La lección operativa es contundente: cada minuto de la primera hora consume evidencia volátil que no vuelve, y cada hora de las primeras 72 acerca o aleja a la organización del cumplimiento de NIS2 y RGPD. En Summum Sistemas estructuramos el IR como una capacidad permanente y no como una reacción, porque la única respuesta a incidentes que funciona es la que estaba lista antes de que el incidente ocurriera.