Respuesta a incidentes:
el ciclo NIST y los playbooks que hay que tener escritos ya
Blue Team y Forense Digital | unfantasmaenelsistema.com
El día que un incidente es real no es el momento de decidir quién llama al proveedor de hosting, si se apaga o no el servidor, o a partir de qué hora hay que avisar a la Agencia Española de Protección de Datos. Todo eso se decide antes, por escrito y con calma, y se guarda en un sitio al que se pueda llegar aunque el correo interno esté caído.
Este artículo resume el ciclo de respuesta a incidentes de la guía NIST SP 800-61, describe los playbooks concretos que toda organización debería tener redactados (phishing, ransomware, cuenta comprometida, servidor comprometido), y baja a lo operativo: roles, árbol de decisión, cuándo aislar y cuándo observar, qué comunicar y a quién, y qué guardar para el análisis posterior. Es el marco que ordena piezas que ya hemos tratado por separado: análisis de memoria, líneas de tiempo forenses, copias de seguridad y detección.
Qué aprenderas en este articulo
Las cuatro fases del ciclo NIST SP 800-61 y qué se hace en cada una · Qué es un playbook y cuáles son los cuatro imprescindibles · Roles del equipo y un árbol de decisión para las primeras dos horas · Contención: cuándo aislar el sistema y cuándo conviene observar primero · Comunicación: interna, plazo de 72 h a la AEPD, clientes, INCIBE y FCSE
1. El ciclo NIST SP 800-61
La guía NIST SP 800-61 (Computer Security Incident Handling Guide) organiza la respuesta en un ciclo de cuatro fases. No es lineal: durante un incidente se salta entre detección, contención y análisis varias veces.
| Fase | Objetivo | Actividades típicas |
|---|---|---|
| Preparación | Estar listos antes de que pase | Playbooks, contactos, herramientas y accesos de emergencia, formación, ejercicios de mesa, logging suficiente, copias probadas |
| Detección y análisis | Confirmar que hay incidente y entender su alcance | Triaje de la alerta, clasificación y prioridad, determinar sistemas y cuentas afectados, establecer una línea temporal inicial |
| Contención, erradicación y recuperación | Frenar el daño, expulsar al atacante y volver a producción con garantías | Aislar o segmentar, revocar credenciales y tokens, eliminar persistencia, restaurar desde copia limpia, parchear la vía de entrada, vigilancia reforzada |
| Actividad posterior al incidente | Aprender y cerrar | Post-mortem sin culpables, acciones correctivas con responsable y fecha, actualizar playbooks y detecciones, informe final |
La fase que más rinde es la primera. Un equipo con playbooks, contactos actualizados y copias que sabe que restauran resuelve en horas lo que a otro le lleva días.
2. Clasificación y prioridad
No todos los incidentes merecen la misma respuesta. La prioridad se fija cruzando impacto (qué se ve afectado y cómo de grave) con urgencia (a qué velocidad se está extendiendo).
- Impacto funcional: ¿hay servicios parados o degradados? ¿cuántos usuarios?
- Impacto sobre la información: ¿hay datos personales, credenciales, propiedad intelectual o secretos expuestos, alterados o cifrados?
- Recuperabilidad: ¿se puede volver con los recursos propios, hace falta ayuda externa, o hay pérdida irreversible?
- Con eso se asigna una categoría (por ejemplo P1-P4) que determina quién se activa, con qué frecuencia se informa y si se convoca al comité de crisis
3. Roles y árbol de decisión
| Rol | Responsabilidad | Quién suele asumirlo |
|---|---|---|
| Coordinador del incidente | Dirige la respuesta, mantiene la línea temporal, decide escaladas | Responsable de seguridad o de IT designado |
| Analista técnico | Investigación, contención técnica, recolección de evidencia | SOC / equipo de sistemas / forense |
| Enlace de negocio | Prioriza servicios, aprueba paradas, traslada impacto a dirección | Responsable del área afectada |
| Comunicación | Mensajes internos, a clientes, a medios si procede | Comunicación / dirección |
| Asesoría legal y protección de datos | Obligaciones de notificación, relación con autoridades, preservación de pruebas | DPD, asesoría jurídica |
Un árbol de decisión sencillo para la primera hora, que el playbook debe concretar por tipo de incidente:
- ¿La alerta es un incidente real? Si hay duda, se trata como incidente hasta descartarlo
- ¿Está activo y extendiéndose? Si sí, contención inmediata prima sobre la investigación fina
- ¿Hay indicios de datos personales afectados? Si sí, se avisa a legal/DPD desde el minuto uno para que corra el reloj de las obligaciones
- ¿Se necesita ayuda externa (forense, INCIBE-CERT, el CERT de referencia, FCSE)? Decidirlo pronto; los recursos externos tardan en incorporarse
- ¿Hay que preservar evidencia para un procedimiento judicial? Si sí, se documenta la cadena de custodia desde el primer paso
4. Contención: aislar frente a observar
La decisión más delicada de las primeras horas. Aislar de golpe frena el daño pero avisa al atacante y puede destruir evidencia volátil; observar un rato más da contexto pero deja que el incidente crezca.
| Situación | Acción recomendada | Motivo |
|---|---|---|
| Ransomware cifrando activamente | Aislar ya (red y, si procede, apagar por energía) | Cada minuto son más ficheros; la prioridad es cortar |
| Cuenta comprometida sin actividad destructiva | Contención sigilosa: forzar cierre de sesión y rotación, monitorizar | Entender el alcance antes de que sepa que le has visto |
| Servidor con webshell, servicio crítico en producción | Segmentar (ACL, VLAN de cuarentena) en vez de apagar; capturar memoria antes | Preservar volátiles y mantener el servicio mientras se prepara la migración |
| Movimiento lateral en curso hacia sistemas clave | Contención amplia: bloquear cuentas, segmentar, cortar C2 | El coste de esperar supera al de la interrupción |
- Antes de apagar, si hay capacidad forense: captura de memoria RAM, conexiones activas, procesos, y una imagen de disco si el caso lo pide (ver nuestros artículos de Volatility y de líneas de tiempo forenses)
- Erradicación: no basta con borrar el fichero visible. Hay que quitar toda la persistencia (tareas, servicios, claves, cuentas creadas) y cerrar la vía de entrada, o el atacante vuelve en días
- Recuperación desde copia limpia: restaurar de una copia anterior a la intrusión, verificada, y con el sistema ya parcheado. Vigilancia reforzada las semanas siguientes
5. Los cuatro playbooks imprescindibles
Un playbook es un documento corto y accionable: disparador, primeros pasos, criterios de escalada, pasos de contención y erradicación, y checklist de comunicación. Los cuatro que cubren la mayoría de los casos reales:
- Phishing / correo malicioso. Preservar el correo original con cabeceras, buscar quién más lo recibió y quién hizo clic, revocar sesiones de los afectados, bloquear el dominio y las URL, purgar de los buzones. Enlaza con nuestro artículo de análisis forense de cabeceras
- Ransomware. Aislar, identificar la variante y la vía de entrada, valorar alcance de cifrado y exfiltración, activar recuperación desde copias inmutables, no pagar sin decisión de dirección y asesoría legal, notificaciones. Enlaza con el artículo de copias 3-2-1
- Cuenta comprometida. Rotar credenciales y revocar tokens/sesiones y claves de aplicación, revisar reglas de reenvío y delegaciones creadas, MFA, buscar accesos desde la cuenta a otros sistemas, revisar registros de auditoría
- Servidor / endpoint comprometido. Triaje en vivo, captura de volátiles, contención por segmentación, análisis de persistencia y de movimiento lateral, reconstrucción desde imagen limpia, cierre de la vulnerabilidad explotada
Qué debe tener a mano el equipo (fase de preparación)
Lista de contactos actualizada: interna, proveedores, INCIBE-CERT (o el CERT de referencia), asesoría legal, aseguradora, FCSE — en papel o fuera del dominio afectado · Accesos de emergencia (break-glass) guardados de forma segura y probados · Un canal de comunicación alternativo por si el habitual cae · Copias de seguridad con restauración probada y, al menos una, inmutable u offline · Logging suficiente y con retención adecuada ANTES del incidente: sin logs no hay análisis
6. Comunicación y obligaciones legales
La comunicación mal llevada convierte un incidente técnico en una crisis de reputación. Y algunas comunicaciones no son opcionales:
- Interna: dirección y áreas afectadas informadas con una cadencia fija (por ejemplo, cada 2-4 horas en un P1), con hechos confirmados y sin especular
- Brecha de datos personales: si hay riesgo para los derechos y libertades de las personas, el RGPD obliga a notificar a la AEPD en un máximo de 72 horas desde que se tiene conocimiento; y a los afectados «sin dilación indebida» si el riesgo es alto. La decisión y la redacción las lleva el DPD con asesoría legal
- INCIBE-CERT para el tejido empresarial (y el CCN-CERT para sector público, o el CERT sectorial que corresponda): apoyo en la gestión y, en su caso, coordinación
- Clientes y terceros afectados según los contratos y la relación; mejor un mensaje sobrio y a tiempo que el silencio
- Denuncia ante las FCSE (Policía Nacional, Guardia Civil) cuando hay delito; preservar la cadena de custodia hace que esa denuncia sirva de algo
Marco de actuación
La respuesta a incidentes se ejecuta sobre sistemas propios o sobre aquellos para los que se tiene mandato expreso (contrato de servicio, encargo de tratamiento, orden de la dirección) · Perseguir al atacante fuera de tu perímetro, acceder a sistemas de terceros o «contraatacar» no es respuesta a incidentes: puede ser delito de acceso ilícito o de daños (en España, arts. 197 bis, 197 ter y 264 del Código Penal). La atribución y la persecución son competencia de las FCSE y la autoridad judicial · Manipular o no preservar la evidencia puede invalidarla en un procedimiento y, si hay datos personales, agravar la responsabilidad ante la AEPD
Referencias
NIST SP 800-61 — Computer Security Incident Handling Guide · ENISA — guías de respuesta a incidentes y taxonomía de referencia · INCIBE-CERT — ‘Guía de gestión de ciberincidentes’ y canal de contacto para empresas · AEPD — ‘Guía para la notificación de brechas de datos personales’ · Plantillas de playbooks: repositorios públicos de IR playbooks y el material de mesa (tabletop) de tu CERT · Nuestros artículos de Volatility 3, líneas de tiempo forenses y copias 3-2-1 para la parte técnica
Conclusión
Responder bien a un incidente es sobre todo un problema de preparación. El ciclo NIST da la estructura, pero lo que marca la diferencia el día malo es tener los playbooks escritos, los contactos a mano, las copias probadas y los logs ya activados.
Escribe primero los cuatro playbooks básicos (phishing, ransomware, cuenta comprometida, servidor comprometido), prueba cada uno con un ejercicio de mesa, y ata la fase de comunicación a las obligaciones reales: 72 horas para la AEPD, INCIBE-CERT como apoyo, y las FCSE cuando hay delito. Después de cada incidente, un post-mortem sin culpables que actualice los playbooks y las detecciones. Ese bucle es el que hace que el siguiente incidente se resuelva más rápido.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)