El NIST Special Publication 800-61 Revision 3 (abril 2025) es el marco de referencia para la respuesta a incidentes en organizaciones de todo el mundo. No es cuestión de si ocurrirá un incidente, sino de cuándo — y estar preparado marca la diferencia entre una interrupción controlada y una crisis total.
DFIR (Digital Forensics and Incident Response) combina dos disciplinas: la respuesta inmediata para contener y erradicar una amenaza, y la forense digital para entender el alcance, origen y métodos del atacante. El NIST SP 800-61r3 organiza este proceso en seis fases secuenciales que forman un ciclo de mejora continua.
Fase 1: Preparación (Preparation)
Es la fase más importante y la que más se descuida. Sin preparación, las fases siguientes son reactivas y caóticas.
Elementos esenciales:
- Plan de respuesta a incidentes documentado y aprobado por la dirección
- Equipo de respuesta (CSIRT/SOC) con roles definidos: líder del incidente, analista forense, comunicaciones, enlace legal, TI
- Herramientas desplegadas antes del incidente: EDR en todos los endpoints, SIEM centralizado, registro de logs retenido por al menos 12 meses (SOC 2, ISO 27001), 6 años para entidades con requisitos HIPAA
- Playbooks por tipo de incidente: ransomware, filtración de datos, denegación de servicio, compromiso de cuenta, malware
- Canales de comunicación offline: si el ataque compromete el correo electrónico o Slack, ¿cómo se comunica el equipo?
- Contactos externos: proveedor de threat intelligence, agencias de ciberseguridad locales (INCIBE en España, CISA en EE.UU.), asesoría legal forense
Métricas de preparación:
- Tiempo medio de detección (MTTD): objetivo < 1 hora
- Tiempo medio de respuesta (MTTR): objetivo < 4 horas
- Cobertura de EDR: 100% de endpoints
- Retención de logs: mínimo 12 meses
Fase 2: Detección y Análisis (Detection & Analysis)
El NIST CSF 2.0 dedica la función Detect a esta fase. El objetivo es identificar un incidente en curso y determinar su alcance antes de que cause daño significativo.
Fuentes de detección:
- EDR (Endpoint Detection & Response): alertas de comportamiento anómalo, ejecución de procesos sospechosos, conexiones salientes a C2
- SIEM: correlación de logs de firewall, proxy, Active Directory, DNS y aplicaciones
- Threat intelligence feeds: IoCs compartidos por ISAC, MITRE ATT&CK, proveedores de TI
- Denuncias internas: usuarios que notifican comportamiento anómalo (phishing, lentitud, archivos cifrados)
- Notificaciones externas: agencias, proveedores, prensa, haveibeenpwned
Análisis de indicadores de compromiso (IoCs):
| Tipo de IoC | Ejemplo | Dónde buscarlo |
|---|---|---|
| Hash de archivo | e99a18c428cb38d5f260853678922e03 |
Volcado de memoria, registry, eventos de ejecución |
| Dirección IP | 185.130.5.173 |
Logs de firewall, proxy, DNS |
| Dominio | malware-c2.evil.com |
Logs de DNS, proxy, certificate transparency |
| Regla YARA | rule Ransomware_Generic { ... } |
Escaneo de archivos, memoria |
| Patrón de red | Beaconing cada 60s | Análisis de tráfico de red |
Triaje: determinar la gravedad
| Nivel | Impacto | Ejemplo | Tiempo de respuesta |
|---|---|---|---|
| Crítico | Datos críticos expuestos o sistemas de producción caídos | Ransomware en servidores de producción | Inmediato (< 1h) |
| Alto | Acceso no autorizado sin exfiltración confirmada | Cuenta de administrador comprometida | < 4h |
| Medio | Escaneos o intentos de explotación sin éxito | SQL injection probe en WAF | < 24h |
| Bajo | Phishing sin clic, FUD | Correo malicioso reportado | < 72h |
Fases 3, 4 y 5: Contención, Erradicación y Recuperación
La fase operativa más intensa. El NIST CSF 2.0 agrupa estas actividades en las funciones Respond y Recover.
Contención — detener la propagación
- Aislamiento de endpoints: desconectar de red los sistemas comprometidos (no apagarlos — la memoria volátil es clave para el análisis forense)
- Bloqueo de IoCs en firewall/proxy: IPs de C2, dominios maliciosos
- Revocación de credenciales: resetear contraseñas, revocar tokens de sesión, rotar claves API
- Segmentación de red: si el atacante se mueve lateralmente, aislar la VLAN comprometida
- Copia forense (imaging): crear una imagen bit-a-bit del disco y volcado de memoria RAM antes de cualquier acción de remediación
Erradicación — eliminar la amenaza
- Identificar la puerta de entrada inicial (phishing, VPN sin MFA, vulnerabilidad conocida)
- Eliminar malware, puertas traseras, persistencia (tareas programadas, servicios, registro de Windows)
- Parchear la vulnerabilidad explotada
- Rotar todas las credenciales del perímetro comprometido — no solo las del usuario afectado
Recuperación — volver a la operación normal
- Restaurar sistemas desde backups limpios (verificar que los backups no estén también comprometidos)
- Escalar gradualmente la conexión de sistemas restaurados mientras se monitoriza actividad anómala
- Comunicar el estado a stakeholders
- Documentar todo el proceso para la fase posterior
Dato real: Según el NIST SP 800-61r3, el 60% de las organizaciones que sufren un incidente grave descubren durante la erradicación que sus backups también estaban comprometidos o no eran recuperables. La regla 3-2-1 sigue vigente: 3 copias, 2 soportes diferentes, 1 fuera de línea.
Fase 4: Actividades Post-Incidente (Post-Incident Activity)
La fase más valiosa a largo plazo y la que más se salta. Sin esta fase, el ciclo de mejora continua se rompe.
Lecciones aprendidas (post-mortem)
Reunión a las 72 horas del cierre del incidente con todo el equipo involucrado. Preguntas clave:
- ¿Qué funcionó bien?
- ¿Qué no funcionó?
- ¿Qué se haría diferente?
- ¿Qué indicadores tempranos se pasaron por alto?
Actualización del plan de respuesta
Cada incidente real revela lagunas en el plan. Actualizar playbooks, añadir nuevos IoCs a las fuentes de inteligencia y mejorar las reglas de detección en el SIEM.
Informe final
El informe debe incluir:
- Línea de tiempo completa del incidente
- Artefactos y evidencias recolectadas
- Árbol de ataque (MITRE ATT&CK mapping)
- Costo del incidente (horas de personal, herramientas, pérdida de negocio, multas)
- Recomendaciones priorizadas
Herramientas DFIR Esenciales (Open Source)
Adquisición de evidencia
| Herramienta | Propósito | Sitio |
|---|---|---|
| FTK Imager | Imagen forense de discos | AccessData |
| dd / dc3dd | Imagen bit-a-bit (Linux) | GNU/Linux |
| WinPMEM / LiME | Volcado de memoria RAM | GitHub |
Análisis forense
| Herramienta | Propósito | Sitio |
|---|---|---|
| Volatility 3 | Análisis de memoria RAM | volatilityfoundation.org |
| Autopsy / Sleuth Kit | Análisis de sistemas de archivos | sleuthkit.org |
| Plaso (log2timeline) | Línea de tiempo super timeline | GitHub |
| YARA | Identificación de patrones de malware | virustotal.github.io/yara/ |
Análisis de red
| Herramienta | Propósito | Sitio |
|---|---|---|
| Wireshark / TShark | Captura y análisis de paquetes | wireshark.org |
| Zeek (Bro) | Monitorización de red | zeek.org |
| NetworkMiner | Extracción de artefactos de PCAP | netresec.com |
Integración con MITRE ATT&CK
Mapear cada incidente a MITRE ATT&CK permite comparar patrones de ataque entre organizaciones y sectores. Por ejemplo, un incidente de ransomware típico sigue esta cadena:
| Táctica | Técnica | ID |
|---|---|---|
| Acceso inicial | Phishing con enlace malicioso | T1566.002 |
| Ejecución | Ejecución de macro en Office | T1204.002 |
| Persistencia | Tarea programada | T1053.005 |
| Movimiento lateral | Pass-the-Hash / RDP | T1550.002 / T1021.001 |
| Exfiltración | Compresión de datos y subida a cloud | T1560 / T1048 |
| Impacto | Cifrado de datos para interrupción | T1486 |
Marco Regulatorio Aplicable
La respuesta a incidentes no es solo una buena práctica técnica — es un requisito legal en múltiples marcos:
- PCI DSS v4.0 Requisito 12.10: Las organizaciones que procesan tarjetas de crédito deben tener un plan de respuesta a incidentes que se pruebe al menos anualmente.
- GDPR Artículo 33: Notificación a la autoridad de protección de datos en un plazo máximo de 72 horas tras tener constancia de una violación de datos personales.
- HIPAA Breach Notification Rule: Notificación a individuos afectados sin demora injustificada, y a HHS en un plazo de 60 días.
- NIS2 Directive (2024): Las entidades esenciales en la UE deben reportar incidentes significativos a las autoridades nacionales en un plazo de 24 horas (early warning).
Checklist para un Plan de Respuesta a Incidentes
- Equipo CSIRT/SOC con roles definidos
- Plan de respuesta documentado y aprobado
- EDR desplegado en el 100% de los endpoints
- SIEM centralizado con retención de 12+ meses
- Playbooks por tipo de incidente
- Backups 3-2-1 verificados y fuera de línea
- Canales de comunicación offline alternativos
- Contactos de agencias y proveedores actualizados
- Análisis post-mortem tras cada incidente
- Pruebas del plan al menos cada 6 meses (tabletop exercises)
- Integración con MITRE ATT&CK para mapeo de técnicas
- Procedimiento de notificación GDPR/NIS2/HIPAA según corresponda
Conclusión
La respuesta a incidentes no es un documento que se archiva, sino un músculo que se entrena. El NIST SP 800-61 Revision 3 proporciona el marco, pero la efectividad depende de la práctica continua: ejercicios de mesa, simulacros de ransomware, y la mejora constante de los playbooks basada en incidentes reales. Invertir en preparación reduce el MTTR de días a horas, y eso salva negocios.
Artículos Relacionados
- Forense en la Nube: AWS, Azure y GCP — Investigación forense específica para entornos cloud durante incidentes
- Threat Hunting y Blue Team: Pirámide del Dolor — Detección proactiva de amenazas antes de que se conviertan en incidentes
- Ransomware: Protección para Empresas — Playbook específico para el tipo de incidente más destructivo
- SOC desde Cero: Centro de Operaciones de Seguridad — Cómo construir el equipo que ejecuta la respuesta a incidentes
- Tipos de Malware: Guía Completa con Ejemplos Reales — Ransomware, troyanos, gusanos, spyware, rootkits, fileless y wipers
- Forense Digital: Guía Completa de Análisis de Incidentes — Disk, memory, network y cloud forensics con Volatility, Autopsy, Plaso y más.