Respuesta a incidentes

La respuesta a incidentes (IR) es el proceso ordenado para detectar, contener, erradicar y recuperar un sistema tras un compromiso, aprendiendo para que no vuelva a ocurrir. Un IR improvisado destruye evidencias y prolonga el daño; uno preparado minimiza el impacto y el tiempo de parada.

flowchart LR
    A[Preparación] --> B[Identificación]
    B --> C[Contención]
    C --> D[Erradicación]
    D --> E[Recuperación]
    E --> F[Lecciones aprendidas]
    F -.-> A

El ciclo de IR (NIST SP 800-61)

1. PREPARACIÓN   plan, equipo (CSIRT), herramientas, contactos, playbooks, formación
2. DETECCIÓN Y ANÁLISIS  identificar el incidente, su alcance y severidad (ver def-soc)
3. CONTENCIÓN    frenar la propagación (corto plazo) sin destruir evidencia
4. ERRADICACIÓN  eliminar la causa (malware, cuentas, persistencia)
5. RECUPERACIÓN  restaurar a operación normal (ver def-backup) y vigilar reincidencia
6. LECCIONES APRENDIDAS  postmortem sin culpa -> mejoras de controles y detección

SANS usa un modelo equivalente de 6 fases (PICERL). Lo esencial: proceso definido ANTES del incidente.

Clasificación y severidad

- severidad por impacto (datos, servicios críticos, alcance) y por tipo (ransomware, brecha, DoS)
- disparar el nivel de respuesta y las notificaciones (legal/RGPD, dirección, autoridades)
- un ransomware con cifrado activo != un phishing aislado: el runbook y los tiempos cambian

Contención (el equilibrio delicado)

Corto plazo   aislar host de la red (no apagar: se pierde la memoria, ver dfir-memoria),
              deshabilitar cuentas comprometidas, bloquear IOCs/C2
Preservar     capturar RAM y disco ANTES de limpiar (dfir-memoria/dfir-disco)
Largo plazo   parches/hardening temporales para operar mientras se erradica
# aislar sin alertar al atacante cuando se quiere observar; depende de la estrategia

Erradicación y recuperación

- quitar TODA persistencia (mal-persist), cuentas de atacante, webshells, tareas, servicios
- resetear credenciales (especialmente privilegiadas y krbtgt si hubo DC, ver ad-persist)
- restaurar desde copias limpias verificadas (def-backup); no confiar en un host "limpiado"
- monitorización reforzada post-incidente para detectar reaparición

Comunicación y aspectos legales

- quién decide y quién comunica (interno, clientes, reguladores)
- RGPD: notificación de brecha a la AEPD en 72h si hay datos personales (ver grc-rgpd)
- preservar cadena de custodia por si hay acción legal (ver dfir-cadena)

Blue Team / operación

Tener playbooks por tipo de incidente (ransomware, BEC, intrusión) probados con ejercicios de mesa.
Preservar evidencia (orden de volatilidad) antes de contener; coordinar con DFIR (Forense de disco/memoria).
Medir MTTD/MTTR y hacer postmortem sin culpa que genere mejoras concretas.
Integrar con SOC (Operaciones SOC), backup (Backups & recuperación), threat intel (Fundamentos de CTI) y comunicación/legal.

Casos reales

NotPetya (2017): la falta de contención y de backups resilientes convirtió el incidente en catastrófico (Maersk).
SolarWinds (2020): IR a gran escala; la erradicación completa (tokens, federación) fue el reto clave.
Ransomware moderno: la velocidad de contención y el estado de los backups deciden el desenlace.

Checklist de prueba

Plan de IR, CSIRT y playbooks preparados y probados (tabletop)
Detección/análisis: alcance y severidad determinados
Preservar evidencia (RAM/disco) antes de contener
Contención sin destruir evidencia ni alertar prematuramente
Erradicar toda persistencia y resetear credenciales
Recuperar desde backups limpios verificados
Notificaciones legales (RGPD 72h) y cadena de custodia
Postmortem sin culpa → mejoras de control y detección