Plan de Respuesta a Incidentes segun NIST SP 800-61

Por que necesitas un plan de respuesta a incidentes

TL;DR: El plan NIST SP 800-61 es un marco normativo que estructura la respuesta a ciberataques mediante fases de preparación, detección, contención y recuperación. A diferencia de las empresas que improvisan, las organizaciones con planes probados reducen significativamente el tiempo de detección y el impacto financiero de una brecha. Es esencial designar roles técnicos y de gestión específicos antes de que ocurra un incidente para asegurar una coordinación efectiva.

Un incidente de seguridad no es cuestion de si ocurrira, sino de cuando. Las organizaciones con un plan de respuesta a incidentes probado y documentado reducen significativamente el tiempo de detección, el coste del incidente y el impacto en el negocio. Las que improvisan durante la crisis cometen errores evitables: destruyen evidencia, comunican de forma inadecuada, toman decisiones reactivas y tardan más en restaurar operaciones.

NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) es el marco de referencia más adoptado para estructurar la respuesta a incidentes. Define cuatro fases que cubren desde la preparacion previa hasta las lecciones aprendidas posteriores.

Este artículo recorre cada fase con enfoque práctico, proporcionando los elementos que necesitas para crear tu propio plan de respuesta a incidentes.

Fase 1: Preparacion

La preparacion es la fase más importante y la que más se descuida. Todo lo que hagas antes de un incidente determina la calidad de la respuesta cuando ocurra.

Equipo de respuesta a incidentes

Define quien participa en la respuesta y que rol tiene cada persona:

Incident Manager: coordina la respuesta, toma decisiones de escalación, gestiona la comunicación con la dirección. No necesita ser la persona más técnica, pero debe tener autoridad para tomar decisiones rapidas.

Analistas DFIR: realizan la investigación técnica, la adquisición de evidencia y el análisis forense. Necesitan acceso a las herramientas y a los sistemas afectados.

Administradores de sistemas/red: ejecutan las acciones de contencion y recuperacion bajo dirección del equipo IR. Conocen la infraestructura y pueden implementar cambios rapidamente.

Representante legal: asesora sobre obligaciones de notificación, preservacion de evidencia para posibles acciones legales, y comunicación con autoridades.

Comunicaciones: gestiona la comunicación interna (empleados) y externa (clientes, proveedores, medios, reguladores).

Dirección/CISO: toma decisiones de negocio (pagar o no un rescate, comunicar publicamente, activar el seguro cyber).

Herramientas y recursos

Prepara un kit de herramientas de respuesta a incidentes antes de necesitarlo:

Herramientas de adquisición forense: discos externos cifrados, software de imagen forense (FTK Imager, KAPE, Arsenal Image Mounter), herramientas de captura de memoria (DumpIt, WinPMem, LiME).

Herramientas de análisis: plaso/log2timeline, Autopsy, Volatility, Wireshark, herramientas de Eric Zimmerman, YARA.

Documentación: diagramas de red actualizados, inventario de activos, lista de contactos, procedimientos de contencion, plantillas de reporte.

Comunicaciones seguras: canal de comunicación fuera de la infraestructura corporativa (los atacantes pueden estar monitorizando el correo y la mensajeria interna). Un grupo de Signal o WhatsApp dedicado, un canal de Slack en un workspace separado, o una conferencia telefonica son opciones comunes.

Definiciones y clasificación

Define que constituye un incidente de seguridad y los niveles de severidad:

Severidad critica: impacto en la continuidad del negocio, compromiso confirmado de datos sensibles, ransomware activo, compromiso de infraestructura critica.

Severidad alta: compromiso confirmado de un sistema, acceso no autorizado a datos, malware activo con capacidad de propagación.

Severidad media: alerta de seguridad confirmada sin compromiso confirmado, actividad sospechosa que requiere investigación, vulnerabilidad critica explotable.

Severidad baja: alertas informativas, intentos de ataque bloqueados, incumplimiento de politicas sin impacto.

La clasificación de severidad determina la velocidad de respuesta, los recursos asignados y el nivel de escalación.

Procedimientos de escalación

Define la cadena de escalación para cada nivel de severidad:

Critica: notificación inmediata al CISO y al Incident Manager. Activacion del equipo IR completo. Notificación al CEO si hay impacto en el negocio o riesgo reputacional.

Alta: notificación al Incident Manager en 30 minutos. Activacion del equipo IR técnico. Informe al CISO en 2 horas.

Media: notificación al equipo de seguridad en 4 horas. Investigación y triaje por el analista asignado.

Baja: registro en el sistema de gestión de incidentes. Revision en el siguiente turno.

Fase 2: Detección y Análisis

Fuentes de detección

Los incidentes se detectan a traves de multiples fuentes:

Alertas automaticas del SIEM, EDR, IDS/IPS, antivirus, firewall.

Reportes de usuarios (emails sospechosos, comportamiento inusual del sistema, ficheros cifrados).

Notificaciones externas (proveedor de servicios, CERT nacional, investigador de seguridad, cliente afectado, fuerzas de seguridad).

Threat intelligence (IOCs que coinciden con actividad observada en la red).

Monitorización proactiva (threat hunting, análisis de logs).

Triaje y validación

No toda alerta es un incidente. El triaje determina si la alerta es un falso positivo, una actividad legitima, un evento de seguridad o un incidente confirmado.

El triaje debe ser rápido y seguir un proceso definido:

Verificar si la alerta es un falso positivo conocido.

Correlacionar con otras fuentes de datos (otros logs, otros sistemas, threat intelligence).

Determinar el alcance inicial (que sistemas están afectados, que tipo de actividad se observa).

Clasificar la severidad segun los criterios definidos.

Documentar la decisión (por que se escalo o se descarto) en el sistema de gestión de incidentes.

Documentación desde el primer momento

Desde que se confirma un incidente, toda la actividad debe documentarse:

Quien detecto que, cuando y como.

Que acciones se tomaron y por que.

Que se encontro en cada paso del análisis.

Que decisiones se tomaron y quien las tomo.

Los timestamps de cada accion (sincronizados a UTC).

Esta documentación es critica para la revision post-incidente, para posibles acciones legales y para cumplir con obligaciones regulatorias.

Fase 3: Contencion, Erradicacion y Recuperacion

NIST agrupa estas tres actividades en una fase porque en la práctica se ejecutan de forma iterativa, no estrictamente secuencial.

Contencion

El objetivo de la contencion es limitar el alcance del incidente y prevenir que empeore. Hay dos tipos:

Contencion a corto plazo: acciones inmediatas para detener la propagación sin eliminar la causa raiz. Aislar sistemas afectados de la red, bloquear IPs o dominios de C2 en el firewall, deshabilitar cuentas comprometidas.

Contencion a largo plazo: acciones que permiten mantener el sistema en un estado controlado mientras se prepara la erradicacion. Aplicar parches temporales, redirigir tráfico, implementar reglas de monitorización adicionales.

La contencion debe equilibrar la urgencia de detener el ataque con la necesidad de preservar evidencia. Apagar un sistema detiene el ataque pero puede destruir artefactos volatiles en memoria.

Erradicacion

La erradicacion elimina la causa raiz del incidente: el malware, la vulnerabilidad explotada, las cuentas comprometidas y los mecanismos de persistencia.

Identificar y eliminar todos los mecanismos de persistencia (servicios, tareas programadas, claves de registro, claves SSH).

Parchear la vulnerabilidad explotada para el acceso inicial.

Resetear las credenciales de todas las cuentas comprometidas o potencialmente comprometidas.

Verificar que no quedan backdoors en los sistemas afectados.

Revisar la configuración de los sistemas que fueron accesibles para el atacante.

Recuperacion

La recuperacion restaura los sistemas afectados a operación normal:

Restaurar desde backups verificados (si los sistemas fueron destruidos o cifrados).

Reconstruir sistemas comprometidos desde cero (no confiar en la limpieza de un sistema comprometido si la erradicacion no puede verificarse al 100%).

Implementar monitorización reforzada para detectar signos de reinfeccion.

Restaurar servicios de forma gradual, empezando por los más criticos.

Verificar que los sistemas restaurados funcionan correctamente antes de abrirlos a los usuarios.

Fase 4: Actividad Post-Incidente

Reunion de lecciones aprendidas

NIST recomienda una reunion post-incidente (post-mortem) dentro de las dos semanas siguientes al cierre del incidente. Los artículos siguientes de esta serie cubren esta fase en detalle.

Los puntos clave son:

Que ocurrio y cuando (timeline del incidente).

Que funciono bien en la respuesta.

Que se puede mejorar.

Que acciones concretas se toman para prevenir recurrencia.

Actualización del plan

Cada incidente real es una oportunidad para mejorar el plan de respuesta. Los hallazgos de la reunion post-mortem deben traducirse en actualizaciones del plan: nuevos procedimientos, ajustes en la clasificación de severidad, mejoras en las herramientas, formación adicional para el equipo.

Metricas de respuesta

Las metricas clave que NIST sugiere rastrear son:

Tiempo de detección (tiempo desde que el incidente ocurrio hasta que fue detectado).

Tiempo de respuesta (tiempo desde la detección hasta el inicio de la contencion).

Tiempo de contencion (tiempo desde el inicio hasta que el incidente esta contenido).

Tiempo de recuperacion (tiempo hasta restaurar operaciones normales).

Coste del incidente (horas de trabajo, sistemas afectados, datos perdidos, impacto en el negocio).

Estas metricas permiten medir la eficacia de la respuesta a lo largo del tiempo y justificar inversiones en capacidad de respuesta.

Estructura de un plan de respuesta a incidentes

Un plan de respuesta a incidentes completo incluye los siguientes apartados:

Propósito y alcance. Define el objetivo del plan y a que sistemas y organizaciones aplica.

Roles y responsabilidades. Lista de miembros del equipo IR con sus roles y datos de contacto.

Definiciones y clasificación de incidentes. Que es un incidente, niveles de severidad, criterios de clasificación.

Procedimientos de notificación y escalación. Quien notifica a quien, por que canal, en que plazos.

Procedimientos de respuesta por tipo de incidente. Playbooks específicos para ransomware, compromiso de cuenta, malware, DDoS, fuga de datos, etc.

Procedimientos de preservacion de evidencia. Como adquirir y preservar evidencia digital manteniendo la cadena de custodia.

Contactos externos. Autoridades (CCN-CERT, INCIBE-CERT, Policia Nacional), aseguradora cyber, proveedores de IR, asesores legales.

Inventario de herramientas y recursos. Kit de herramientas IR, sistemas de backup, comunicaciones alternativas.

Plan de comunicación. Plantillas de comunicación para empleados, clientes, proveedores, reguladores y medios.

Procedimientos de revision y prueba. Frecuencia de ejercicios, tipos de simulaciones, criterios de actualización del plan.

Ejercicios de simulación

Tabletop exercises

Los ejercicios de mesa son simulaciones basadas en escenarios donde el equipo IR discute como responderia a un incidente hipotetico. No requieren herramientas técnicas y duran entre 2 y 4 horas.

Un escenario tipico podria ser: "Es viernes a las 17:00. Un usuario reporta que sus ficheros tienen una extensión extrana y hay un fichero README.txt en su escritorio pidiendo 500.000 dolares en Bitcoin. Que hacemos?"

El moderador introduce variables a medida que avanza el ejercicio: "Han pasado 2 horas. Descubris que 15 servidores más están cifrados. El CEO quiere saber si hay que comunicar publicamente."

Simulaciones técnicas

Las simulaciones técnicas (red team/purple team exercises) prueban la capacidad real de detección y respuesta. Un equipo simula un ataque real contra la infraestructura y el equipo IR debe detectarlo, contenerlo y erradicarlo como si fuera un incidente genuino.

Adaptacion a normativa española y europea

ENS (Esquema Nacional de Seguridad)

El ENS requiere que las organizaciones del sector público y sus proveedores tengan capacidad de gestión de incidentes proporcional al nivel de seguridad del sistema. Para nivel Alto, esto incluye un equipo IR dedicado, procedimientos documentados y capacidad de respuesta 24/7.

NIS2

NIS2 establece obligaciones de notificación de incidentes para entidades esenciales e importantes: alerta temprana al CSIRT en 24 horas, informe completo en 72 horas, e informe final en un mes.

RGPD

Si el incidente afecta a datos personales, el RGPD requiere notificación a la autoridad de protección de datos en 72 horas y, si el riesgo es alto, notificación a los interesados.

El plan de respuesta a incidentes debe contemplar estas obligaciones con procedimientos específicos y plantillas de notificación preparadas.

Conclusion

Un plan de respuesta a incidentes no es un documento que se escribe una vez y se archiva. Es un documento vivo que se prueba, se actualiza y se mejora continuamente. El marco NIST SP 800-61 proporciona la estructura, pero el contenido debe adaptarse a la realidad de cada organización: su infraestructura, sus riesgos, sus obligaciones legales y su capacidad de respuesta.

La inversion en preparacion tiene un retorno claro: las organizaciones preparadas detectan los incidentes antes, contienen el daño más rápido, recuperan operaciones en menos tiempo y cometen menos errores evitables durante la crisis.