Plan de Respuesta a Incidentes segun NIST SP 800-61

Por que necesitas un plan de respuesta a incidentes

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 deteccion, 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 mas en restaurar operaciones.

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

Este articulo recorre cada fase con enfoque practico, proporcionando los elementos que necesitas para crear tu propio plan de respuesta a incidentes.

Fase 1: Preparacion

La preparacion es la fase mas importante y la que mas 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 escalacion, gestiona la comunicacion con la direccion. No necesita ser la persona mas tecnica, pero debe tener autoridad para tomar decisiones rapidas.

Analistas DFIR: realizan la investigacion tecnica, la adquisicion de evidencia y el analisis forense. Necesitan acceso a las herramientas y a los sistemas afectados.

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

Representante legal: asesora sobre obligaciones de notificacion, preservacion de evidencia para posibles acciones legales, y comunicacion con autoridades.

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

Direccion/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 adquisicion forense: discos externos cifrados, software de imagen forense (FTK Imager, KAPE, Arsenal Image Mounter), herramientas de captura de memoria (DumpIt, WinPMem, LiME).

Herramientas de analisis: plaso/log2timeline, Autopsy, Volatility, Wireshark, herramientas de Eric Zimmerman, YARA.

Documentacion: diagramas de red actualizados, inventario de activos, lista de contactos, procedimientos de contencion, plantillas de reporte.

Comunicaciones seguras: canal de comunicacion 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 clasificacion

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 propagacion.

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

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

La clasificacion de severidad determina la velocidad de respuesta, los recursos asignados y el nivel de escalacion.

Procedimientos de escalacion

Define la cadena de escalacion para cada nivel de severidad:

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

Alta: notificacion al Incident Manager en 30 minutos. Activacion del equipo IR tecnico. Informe al CISO en 2 horas.

Media: notificacion al equipo de seguridad en 4 horas. Investigacion y triaje por el analista asignado.

Baja: registro en el sistema de gestion de incidentes. Revision en el siguiente turno.

Fase 2: Deteccion y Analisis

Fuentes de deteccion

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).

Monitorizacion proactiva (threat hunting, analisis de logs).

Triaje y validacion

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 rapido 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 estan afectados, que tipo de actividad se observa).

Clasificar la severidad segun los criterios definidos.

Documentar la decision (por que se escalo o se descarto) en el sistema de gestion de incidentes.

Documentacion 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 analisis.

Que decisiones se tomaron y quien las tomo.

Los timestamps de cada accion (sincronizados a UTC).

Esta documentacion 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 practica 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 propagacion 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 trafico, implementar reglas de monitorizacion 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 configuracion de los sistemas que fueron accesibles para el atacante.

Recuperacion

La recuperacion restaura los sistemas afectados a operacion 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 monitorizacion reforzada para detectar signos de reinfeccion.

Restaurar servicios de forma gradual, empezando por los mas 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 articulos 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.

Actualizacion 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 clasificacion de severidad, mejoras en las herramientas, formacion adicional para el equipo.

Metricas de respuesta

Las metricas clave que NIST sugiere rastrear son:

Tiempo de deteccion (tiempo desde que el incidente ocurrio hasta que fue detectado).

Tiempo de respuesta (tiempo desde la deteccion 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:

Proposito 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 clasificacion de incidentes. Que es un incidente, niveles de severidad, criterios de clasificacion.

Procedimientos de notificacion y escalacion. Quien notifica a quien, por que canal, en que plazos.

Procedimientos de respuesta por tipo de incidente. Playbooks especificos 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 comunicacion. Plantillas de comunicacion para empleados, clientes, proveedores, reguladores y medios.

Procedimientos de revision y prueba. Frecuencia de ejercicios, tipos de simulaciones, criterios de actualizacion del plan.

Ejercicios de simulacion

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 tecnicas 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 extension 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 mas estan cifrados. El CEO quiere saber si hay que comunicar publicamente."

Simulaciones tecnicas

Las simulaciones tecnicas (red team/purple team exercises) prueban la capacidad real de deteccion 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 espanola y europea

ENS (Esquema Nacional de Seguridad)

El ENS requiere que las organizaciones del sector publico y sus proveedores tengan capacidad de gestion 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 notificacion 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 notificacion a la autoridad de proteccion de datos en 72 horas y, si el riesgo es alto, notificacion a los interesados.

El plan de respuesta a incidentes debe contemplar estas obligaciones con procedimientos especificos y plantillas de notificacion 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 organizacion: 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 dano mas rapido, recuperan operaciones en menos tiempo y cometen menos errores evitables durante la crisis.