Incident Response y forense digital

La Rev. 3 (abril de 2025) sustituye el ciclo de vida de cuatro fases de la versión anterior de 2012 (Preparation; Detection & Analysis; Containment, Eradication & Recovery; Post-Incident Activity) por un modelo articulado en torno a las seis funciones del NIST CSF 2.0. Govern, Identify y Protect constituyen la preparación: previenen incidentes, reducen su impacto y anclan la respuesta a incidentes en la gestión de riesgos. Detect, Respond y Recover forman la respuesta a incidentes propiamente dicha – desde la detección y el análisis, pasando por la contención y la erradicación, hasta la recuperación, incluidas las notificaciones y la comunicación. La novedad es el papel de la mejora continua: las lecciones aprendidas se reincorporan en todo momento a todas las funciones a través de la categoría Improvement (ID.IM), y no solo tras el cierre del incidente.

La respuesta a incidentes solo funciona con roles claramente asignados: la dirección pilota la respuesta y decide sobre medidas drásticas como la desconexión o la reconstrucción de servicios críticos; los incident handlers verifican el incidente, recopilan y analizan datos y evidencias, priorizan medidas y limitan el daño. SP 800-61r3 subraya que, además, participan muchas partes internas y externas – por ejemplo, el departamento jurídico, protección de datos, comunicación, proveedores de servicios y proveedores cloud. En la gestión de crisis alemana se ha consolidado para ello la organización de crisis dedicada denominada besondere Aufbauorganisation (BAO): un gabinete de crisis predefinido con sus propias vías de escalado y decisión, que descarga a la organización jerárquica en caso de emergencia. Las competencias de decisión y las disponibilidades deben definirse antes del incidente, no durante.

Según el Art. 23 de la Directiva NIS2 (UE) 2022/2555, las entidades esenciales e importantes notifican los incidentes significativos por etapas al CSIRT o a la autoridad competente – en Alemania al BSI conforme a la ley BSI reformada: alerta temprana en un plazo de 24 horas desde que se tenga conocimiento, notificación con una primera evaluación sin demora indebida y, en todo caso, en un plazo de 72 horas, informe final a más tardar un mes después de la notificación; los destinatarios afectados de los servicios deben ser informados sin demora indebida. Si se ven comprometidos datos personales, el Art. 33 del RGPD exige además una notificación a la autoridad de control de protección de datos sin dilación indebida y, de ser posible, en un plazo de 72 horas; si es probable un alto riesgo, también debe comunicarse a los interesados sin dilación indebida conforme al Art. 34 del RGPD. Un solo incidente puede, por tanto, poner en marcha varios relojes a la vez – por eso las responsabilidades, las vías de notificación y las plantillas de texto deben estar de antemano en el playbook.

ISO/IEC 27037:2012 describe los cuatro pasos básicos del tratamiento de posibles evidencias digitales: identificación, recopilación, adquisición y preservación. La integridad y la trazabilidad son fundamentales – copias de trabajo en lugar de originales, valores hash criptográficos y una chain of custody sin lagunas que documente quién accedió a qué y cuándo. SP 800-61r3 lo deja claro: aunque no se pretenda una persecución penal, los datos de incidentes recopilados se consideran evidencias y deben tratarse según los procedimientos de preservación y conservación de evidencias de la organización, manteniendo su integridad y procedencia. En la práctica, esto significa: asegurar los datos volátiles, como la memoria RAM, antes que los soportes de almacenamiento persistentes – y no reinstalar precipitadamente los sistemas comprometidos, pues eso destruye evidencias e impide el análisis de causas raíz.

SP 800-61r3 menciona expresamente, junto a los equipos propios, incident handlers contratados, por ejemplo un SOC externalizado a un proveedor de seguridad gestionada o el equipo de IR de un proveedor cloud. Un retainer de IR regula este acceso contractualmente por adelantado: tiempos de respuesta definidos, cuestiones de confidencialidad y de encargo de tratamiento aclaradas, y un onboarding con personas de contacto, conocimiento del entorno y accesos preparados – para que en caso de emergencia no se pierda tiempo con cuestiones contractuales y de acceso. Los playbooks traducen el plan de IR en pasos de actuación concretos por escenario, por ejemplo ransomware, cuentas comprometidas o fuga de datos; el NIST cita como ejemplo los Cybersecurity Incident & Vulnerability Response Playbooks de la CISA (2021). Los plazos de notificación, los puntos de decisión y las vías de comunicación deben figurar directamente en los playbooks.

El CSF 2.0 ancla expresamente los ejercicios en el proceso de mejora: según ID.IM-02, las mejoras se derivan de pruebas de seguridad y ejercicios – también de forma conjunta con proveedores y terceros relevantes. Los formatos van desde discusiones tabletop y simulaciones hasta pruebas técnicas; las bases metodológicas se describen en NIST SP 800-84. Los ejercicios comprueban en condiciones realistas lo que funciona sobre el papel: las disponibilidades, las vías de decisión de la BAO, el cumplimiento de los plazos de 24 y 72 horas y la calidad de los playbooks. Los resultados se reincorporan como lecciones aprendidas a los planes, playbooks y formaciones – así la madurez de la respuesta a incidentes se vuelve medible y crece con cada iteración.