Plan de Respuesta a Incidentes

¿Que es un plan de respuesta a incidentes?

287 dias. Ese es el tiempo medio que una organizacion tarda en identificar y contener una brecha de seguridad, segun el informe “Cost of a Data Breach 2024” de IBM. Las empresas que disponen de un plan de respuesta a incidentes probado y de un equipo dedicado reducen ese tiempo en 54 dias y ahorran una media de 2,66 millones de dolares por incidente. En Espana, el INCIBE gestiono 83.517 ciberincidentes en 2023 y 122.223 en 2024 (un incremento del 26%), lo que refleja un panorama de amenazas en crecimiento constante. Sin embargo, segun datos de ENISA, menos del 30% de las pymes europeas cuenta con un plan de respuesta a incidentes documentado. La ausencia de este plan no solo retrasa la contencion del ataque, sino que compromete la preservacion de la evidencia digital necesaria para acciones legales, reclamaciones al seguro y notificaciones obligatorias a la AEPD.

Un plan de respuesta a incidentes (IRP, Incident Response Plan) es un documento estrategico y operativo que define, antes de que ocurra un ciberincidente, quien hace que, cuando, como y con que herramientas. Se basa en marcos reconocidos como NIST SP 800-61 (Computer Security Incident Handling Guide) y establece procedimientos claros para cada fase del incidente: desde la deteccion inicial hasta las lecciones aprendidas posteriores.

Marco NIST SP 800-61: las cuatro fases de la respuesta a incidentes

El National Institute of Standards and Technology (NIST) de Estados Unidos publico la guia SP 800-61 Revision 2, que se ha convertido en el estandar de referencia mundial para la gestion de ciberincidentes. Define cuatro fases principales:

Fase 1: Preparacion

La preparacion es todo lo que se hace antes de que ocurra un incidente. Es la fase mas importante y la que mas organizaciones descuidan.

Elementos clave de la preparacion:

Fase 2: Deteccion y analisis

Esta fase abarca desde la primera alerta hasta la confirmacion de que se trata de un incidente real, su clasificacion y su priorizacion.

Fuentes de deteccion:

• SIEM (Security Information and Event Management): Correlacion de logs de multiples fuentes para detectar patrones anomalos.
• EDR (Endpoint Detection and Response): Deteccion de comportamiento malicioso en endpoints (ejecucion sospechosa, movimiento lateral, escalada de privilegios).
• IDS/IPS: Deteccion de trafico de red anomalo (firmas de malware, comunicaciones C2, exfiltracion).
• Alertas de usuarios: Empleados que reportan correos sospechosos, comportamiento inusual del sistema, o archivos cifrados.
• Inteligencia de amenazas: Feeds externos (INCIBE-CERT, MISP, AlienVault OTX) que alertan sobre campanas activas contra el sector.

Clasificacion y priorizacion:

Documentacion inicial del incidente:

FORMULARIO DE REPORTE DE INCIDENTE
===================================
ID Incidente: INC-2026-0042
Fecha/Hora deteccion: 2026-02-10 08:15 UTC
Detectado por: SIEM (regla: multiple-failed-logins-admin)
Tipo sospechado: Compromiso de credenciales / Acceso no autorizado
Sistemas afectados: DC01.empresa.local, VPN Gateway
Severidad inicial: P2 (Alta)
Asignado a: Maria Garcia (IR Lead)
Estado: En investigacion

Fase 3: Contencion, erradicacion y recuperacion

Esta es la fase operativa central donde se contiene el dano, se elimina la amenaza y se restauran los sistemas.

Contencion a corto plazo (primeras horas):

Contencion a largo plazo:

• Redirigir trafico a traves de infraestructura limpia.
• Aplicar parches de emergencia a vulnerabilidades explotadas.
• Reforzar controles de acceso (MFA, rotacion de credenciales).
• Desplegar agentes EDR adicionales para monitorizacion ampliada.

Erradicacion:

• Eliminar malware de todos los sistemas afectados.
• Cerrar puertas traseras (backdoors) instaladas por el atacante.
• Identificar y remediar el vector de entrada original.
• Verificar que no existen mecanismos de persistencia (tareas programadas, servicios maliciosos, claves de registro).

Recuperacion:

• Restaurar sistemas desde backups verificados (no comprometidos).
• Reconstruir sistemas comprometidos desde cero si es necesario.
• Monitorizar intensivamente durante 30-90 dias post-recuperacion.
• Validar integridad de datos restaurados mediante hashes.

Fase 4: Actividad post-incidente (lecciones aprendidas)

Reunion post-mortem (realizar dentro de las 2 semanas posteriores al incidente):

Entregables post-incidente:

• Informe ejecutivo para direccion (resumen no tecnico).
• Informe tecnico detallado (timeline, IoCs, acciones tomadas).
• Informe pericial forense (si hay acciones legales o notificacion AEPD).
• Plan de mejora con acciones correctivas priorizadas.

Roles del equipo de respuesta a incidentes

Estructura del equipo IR (CSIRT)

Playbooks: procedimientos por tipo de incidente

Un playbook es un documento operativo que detalla paso a paso las acciones a realizar ante un tipo especifico de incidente. Cada organizacion debe adaptar sus playbooks a su infraestructura, pero la estructura general es comun.

Playbook ransomware

PLAYBOOK: RANSOMWARE
=====================
Trigger: Deteccion de cifrado masivo de archivos, nota de rescate
Severidad: P1 (Critica)
Tiempo objetivo contencion: menos de 2 horas

PASO 1 - CONTENCION INMEDIATA (0-30 min)
  [ ] Aislar sistemas afectados de la red (NO apagar)
  [ ] Desactivar shares de red (SMB, NFS)
  [ ] Bloquear conexiones salientes sospechosas (C2)
  [ ] Capturar dump de memoria RAM de equipos cifrados
  [ ] Tomar snapshots de VMs afectadas
  [ ] Notificar IR Lead y perito forense

PASO 2 - EVALUACION ALCANCE (30 min - 2h)
  [ ] Identificar variante ransomware (nota rescate, extension archivos)
  [ ] Determinar vector de entrada (phishing, RDP, vulnerabilidad)
  [ ] Mapear todos los sistemas afectados
  [ ] Verificar integridad de backups (no cifrados)
  [ ] Consultar No More Ransom (herramientas descifrado gratuitas)

PASO 3 - ERRADICACION (2h - 24h)
  [ ] Identificar y cerrar vector de entrada
  [ ] Eliminar malware de todos los sistemas afectados
  [ ] Verificar ausencia de persistencia (scheduled tasks, services)
  [ ] Rotar TODAS las credenciales del dominio
  [ ] Aplicar parches a vulnerabilidades explotadas

PASO 4 - RECUPERACION (24h - 7 dias)
  [ ] Restaurar desde backups verificados
  [ ] Reconstruir sistemas comprometidos si backups no disponibles
  [ ] Monitorizar 24/7 durante 30 dias post-recuperacion
  [ ] Validar integridad datos restaurados

PASO 5 - POST-INCIDENTE (7 - 14 dias)
  [ ] Informe pericial forense completo
  [ ] Notificacion AEPD si hay datos personales (72 horas)
  [ ] Denuncia ante Policia Nacional / Guardia Civil
  [ ] Reclamacion seguro cyber
  [ ] Reunion lecciones aprendidas
  [ ] Actualizar este playbook con mejoras

Playbook phishing/BEC

PLAYBOOK: PHISHING / BEC (Business Email Compromise)
=====================================================
Trigger: Empleado reporta email sospechoso o transferencia fraudulenta
Severidad: P2-P3 (depende de si hubo click/transferencia)

PASO 1 - TRIAJE (0-15 min)
  [ ] Confirmar si el usuario hizo click en enlace o abrio adjunto
  [ ] Si transfirió dinero: escalar a P1 y contactar banco inmediatamente
  [ ] Obtener headers del email (evidencia)
  [ ] Bloquear remitente en gateway de correo

PASO 2 - CONTENCION (15 min - 1h)
  [ ] Si click en enlace: resetear credenciales del usuario
  [ ] Si adjunto abierto: aislar equipo y escanear con EDR
  [ ] Buscar otros destinatarios del mismo email (IoC en logs)
  [ ] Bloquear dominio/IP del phishing en firewall y proxy

PASO 3 - INVESTIGACION (1h - 4h)
  [ ] Analizar headers email (origen real, SPF/DKIM/DMARC)
  [ ] Analizar URL/adjunto en sandbox
  [ ] Verificar si hubo movimiento lateral post-compromiso
  [ ] Documentar toda la evidencia preservando cadena de custodia

Forensic readiness: preparacion forense proactiva

La forensic readiness (preparacion forense) es la capacidad de una organizacion de maximizar la recopilacion de evidencia digital util mientras minimiza el coste de la investigacion forense. Se implementa como parte de la fase de preparacion del plan de respuesta a incidentes.

Configuraciones esenciales:

Sincronizacion de relojes (NTP): Todos los sistemas deben estar sincronizados con la misma fuente de tiempo NTP. Sin sincronizacion precisa, la correlacion de eventos entre diferentes sistemas durante la investigacion forense se vuelve imprecisa o imposible.

Caso practico: respuesta a incidente ransomware en pyme espanola

Nota: El siguiente caso esta basado en investigaciones forenses reales. Los datos especificos (nombres de empresas, cantidades exactas, IPs) han sido anonimizados para proteger la confidencialidad de los afectados, preservando los aspectos tecnicos relevantes para fines educativos.

Contexto: Una pyme de 45 empleados del sector logistico en Espana sufre un ataque de ransomware un viernes a las 19:30 (fuera de horario laboral). Los atacantes cifran 3 servidores de produccion y exigen 2.5 BTC (aproximadamente 160.000 euros).

Cronologia del incidente y respuesta:

Viernes 19:30 - Compromiso inicial
  Vector: Credenciales RDP expuestas a internet (puerto 3389)
  Atacante: IP 185.220.xxx.xxx (nodo Tor de salida)
  Accion: Login como Administrador via RDP sin MFA

Viernes 19:30-21:00 - Movimiento lateral
  Atacante enumera red interna (Nmap, ADRecon)
  Desactiva Windows Defender via GPO
  Obtiene hash NTLM del Domain Admin (Mimikatz)
  Accede a 3 servidores criticos: DC01, FILE01, ERP01

Viernes 21:00-23:00 - Despliegue ransomware
  Ransomware: LockBit 3.0 (builder filtrado)
  Cifrado: AES-256 + RSA-2048
  Archivos cifrados: 480 GB (146.000 archivos)
  Nota de rescate: "README.txt" en cada carpeta

Sabado 07:15 - Deteccion
  Empleado de guardia detecta que no puede acceder al ERP
  Notifica al responsable de TI via telefono

Sabado 07:30 - Activacion del plan de respuesta
  TI contacta a perito informatico forense (contrato retainer)
  Perito llega en 2 horas (09:30)

Respuesta del perito forense:

Sabado 09:30-11:00 - Preservacion de evidencia
  1. Dump memoria RAM de DC01 (32 GB) via WinPmem
  2. Dump memoria RAM de FILE01 y ERP01
  3. Captura de logs de Windows Event Log (Security, System)
  4. Copia forense del disco de DC01 (imagen bit-a-bit con FTK Imager)
  5. Exportacion logs de firewall (ultimos 7 dias)
  6. Documentacion fotografica de las notas de rescate

Sabado 11:00-14:00 - Analisis inicial
  1. Identificacion variante: LockBit 3.0
  2. Vector entrada: RDP expuesto + credenciales debiles
  3. Timeline del ataque: viernes 19:30 a 23:00
  4. Herramientas del atacante: Mimikatz, Nmap, ADRecon, PsExec
  5. Exfiltracion: NO detectada (no habia EDR para confirmarlo)

Sabado 14:00 - Evaluacion de backups
  Backup en NAS local: CIFRADO (atacante accedio via red)
  Backup cloud (Azure): INTACTO (ultimo backup viernes 18:00)
  Datos perdidos: 1.5 horas de transacciones (18:00-19:30)

Sabado 14:30 - Decision: NO pagar rescate
  Razon: Backups cloud disponibles, perdida de datos minima

Recuperacion:

Sabado-Domingo: Reconstruccion
  1. Servidores reconstruidos desde cero (no restaurar sobre comprometidos)
  2. Datos restaurados desde backup Azure
  3. RDP cerrado a internet (acceso solo via VPN con MFA)
  4. Credenciales de TODOS los usuarios rotadas
  5. EDR desplegado en todos los endpoints (CrowdStrike Falcon)

Lunes 08:00: Negocio operativo
  Tiempo total de inactividad: 60 horas (viernes 19:30 - lunes 08:00)
  Datos perdidos: 1.5 horas de transacciones
  Coste estimado: 35.000 EUR (tiempo inactividad + perito + mejoras)
  Coste evitado (no pagar rescate): 160.000 EUR

Acciones post-incidente:

• Informe pericial forense presentado ante Policia Nacional (denuncia).
• Notificacion a AEPD dentro de las 72 horas (datos personales en FILE01).
• Reclamacion al seguro cyber: 28.000 EUR cubiertos (70% del coste).
• Plan de mejora: MFA obligatorio, EDR, backup 3-2-1, VPN para acceso remoto.

Marco legal en Espana

Directiva NIS2 (UE 2022/2555)

La Directiva NIS2, cuya transposicion al derecho espanol esta prevista para 2025-2026, amplia significativamente las obligaciones de gestion de ciberincidentes:

• Entidades esenciales e importantes: Deben disponer de politicas de gestion de riesgos y planes de respuesta a incidentes.
• Notificacion obligatoria: Alerta temprana al CSIRT en 24 horas, notificacion completa en 72 horas, informe final en un mes.
• Sanciones: Hasta 10 millones de euros o 2% de la facturacion global anual para entidades esenciales.
• Responsabilidad de la direccion: Los organos de direccion son personalmente responsables de aprobar y supervisar las medidas de gestion de riesgos.

Real Decreto-ley 12/2018 (Directiva NIS)

Actualmente en vigor, transpone la primera Directiva NIS y establece obligaciones para operadores de servicios esenciales y proveedores de servicios digitales, incluyendo la obligacion de gestionar y notificar incidentes al CSIRT de referencia (INCIBE-CERT para empresas privadas, CCN-CERT para sector publico).

RGPD (Reglamento UE 2016/679)

• Articulo 33: Notificacion de brechas de datos personales a la autoridad de control (AEPD) en un plazo maximo de 72 horas desde su conocimiento.
• Articulo 34: Si la brecha entrana alto riesgo para los derechos de las personas, notificacion directa a los afectados.
• Sanciones: Hasta 20 millones de euros o 4% de la facturacion global anual.

En la practica, cumplir con el plazo de 72 horas del RGPD requiere tener un plan de respuesta a incidentes operativo. Sin el, la organizacion difcilmente podra evaluar el alcance de la brecha y preparar la notificacion en tiempo.

Codigo Penal y denuncia

El plan de respuesta a incidentes debe contemplar la denuncia ante las Fuerzas y Cuerpos de Seguridad del Estado:

• Policia Nacional: Brigada Central de Investigacion Tecnologica (BCIT).
• Guardia Civil: Grupo de Delitos Telematicos (GDT).
• El informe pericial forense elaborado durante la respuesta al incidente es fundamental para respaldar la denuncia y la investigacion policial.

Herramientas relacionadas

Herramientas de deteccion y monitorizacion

Herramientas de preservacion de evidencia

Frameworks y playbooks

Relacion con otros conceptos

• Ransomware: El ransomware es uno de los incidentes mas criticos que un plan de respuesta debe contemplar. El playbook de ransomware es frecuentemente el primero que las organizaciones desarrollan, dado el impacto devastador que este tipo de ataque puede tener en la operativa del negocio.

• ISO 27037: Esta norma internacional establece las directrices para la recopilacion y preservacion de evidencia digital. El plan de respuesta a incidentes debe incorporar los procedimientos de la ISO 27037 para garantizar que la evidencia recopilada durante la respuesta sea admisible judicialmente.

• Evidencia Digital: La preservacion de evidencia digital es un objetivo transversal a todas las fases de la respuesta a incidentes. Cada accion tomada durante la respuesta debe documentarse y cada artefacto forense debe preservarse siguiendo la cadena de custodia.

• Cadena de Custodia: La cadena de custodia documenta quien tuvo acceso a la evidencia digital, cuando y que acciones realizo. Un plan de respuesta a incidentes robusto integra procedimientos de cadena de custodia desde la fase de contencion, garantizando que cada imagen forense, dump de memoria y log exportado mantiene su integridad probatoria.

FAQ

P: ¿Que diferencia hay entre un plan de respuesta a incidentes y un plan de continuidad de negocio? R: El plan de respuesta a incidentes (IRP) se centra en detectar, contener y erradicar la amenaza, asi como en preservar la evidencia. El plan de continuidad de negocio (BCP) se centra en mantener las operaciones criticas durante y despues del incidente. Ambos son complementarios: el IRP gestiona la amenaza tecnica mientras el BCP gestiona el impacto en el negocio.

P: ¿Con que frecuencia debe probarse el plan de respuesta a incidentes? R: Minimo una vez al ano mediante un ejercicio tabletop (simulacion en mesa) y, idealmente, un simulacro tecnico completo. Ademas, el plan debe revisarse y actualizarse tras cada incidente real y cuando haya cambios significativos en la infraestructura.

P: ¿Una pyme de 10 empleados necesita un plan de respuesta a incidentes? R: Si. Aunque el plan sera mas sencillo que el de una gran empresa, incluso una pyme necesita saber a quien llamar, que NO hacer (no apagar equipos, no borrar nada) y como preservar la evidencia basica. Un plan de 2-3 paginas con contactos del perito forense, pasos iniciales y protocolo de comunicacion ya marca una diferencia critica.

P: ¿Cuanto cuesta implementar un plan de respuesta a incidentes? R: Depende del tamano de la organizacion. Para una pyme, un perito informatico puede elaborar un plan basico con playbooks por 2.000-5.000 euros. Para empresas medianas, con formacion y simulacros incluidos, entre 8.000-20.000 euros. El coste medio de un ataque de ransomware en Espana supera los 100.000 euros, lo que convierte al plan en una inversion con retorno claro.

Referencias y Fuentes

1. NIST. (2012). “SP 800-61 Rev. 2: Computer Security Incident Handling Guide”. nist.gov — Guia de referencia mundial para la gestion de incidentes de seguridad informatica. Define las 4 fases: preparacion, deteccion/analisis, contencion/erradicacion/recuperacion, y post-incidente.

2. IBM Security. (2024). “Cost of a Data Breach Report 2024”. ibm.com — Tiempo medio de identificacion y contencion de brechas: 287 dias. Las organizaciones con IR plan y equipo ahorran $2.66M por incidente.

3. INCIBE. (2025). “Balance de Ciberseguridad 2024”. incibe.es — 122.223 ciberincidentes gestionados en Espana en 2024, un 26% mas que en 2023.

4. ENISA. (2024). “NIS Investments Report 2024”. enisa.europa.eu — Menos del 30% de las pymes europeas cuentan con un plan de respuesta a incidentes documentado.

5. Parlamento Europeo. (2022). “Directiva (UE) 2022/2555 relativa a medidas para un elevado nivel comun de ciberseguridad (NIS2)”. eur-lex.europa.eu — Obligaciones ampliadas de gestion y notificacion de incidentes para entidades esenciales e importantes.

6. RGPD. (2016). “Reglamento (UE) 2016/679 relativo a la proteccion de datos personales”. eur-lex.europa.eu — Articulos 33 y 34: notificacion de brechas de datos personales en 72 horas.

7. SANS Institute. (2024). “Incident Handler’s Handbook”. sans.org — Manual practico con templates, checklists y mejores practicas para equipos de respuesta a incidentes.

8. MITRE. (2025). “ATT&CK Framework”. attack.mitre.org — Marco de referencia de tecnicas, tacticas y procedimientos de adversarios. Esencial para documentar las TTPs utilizadas en un incidente.

9. Real Decreto-ley 12/2018. Transposicion de la Directiva NIS al ordenamiento juridico espanol. boe.es — Obligaciones de gestion y notificacion de incidentes para operadores de servicios esenciales.

10. CCN-CERT. (2025). “Guias de Respuesta a Incidentes”. ccn-cert.cni.es — Guias y herramientas de respuesta a incidentes para el sector publico espanol.

11. Codigo Penal espanol. Arts. 197 (revelacion de secretos), 264 (danos informaticos), 264 bis (obstaculizacion de sistemas). boe.es

12. AEPD. (2024). “Guia para la gestion y notificacion de brechas de seguridad”. aepd.es — Guia practica de la Agencia Espanola de Proteccion de Datos para la gestion y notificacion de brechas.

Ultima actualizacion: 10 Febrero 2026 Categoria: Seguridad (PRI-001) Nivel tecnico: Intermedio-Avanzado Relevancia forense: MUY ALTA (plan necesario para preservar evidencia desde el primer momento)