Un plan de respuesta a incidentes es lo que separa a las empresas que sobreviven un ciberataque de las que salen en las noticias por no tener ni idea de qué hacer. Si estás leyendo esto, probablemente te preguntas ciberataque qué hacer cuando todo se va al garete —o, mejor aún, quieres prepararte antes de que pase—. La gestión de incidentes no es opcional: según el informe de IBM Cost of a Data Breach 2024, las organizaciones con un plan de incident response probado ahorran una media de 1,49 millones de dólares por brecha. Y no, "llamar a mi sobrino que sabe de informática" no cuenta como respuesta a incidentes. Aquí te explicamos paso a paso cómo montar un plan que funcione de verdad, con herramientas reales y sin humo.
Qué es un plan de respuesta a incidentes y por qué lo necesitas ya
Un plan de respuesta a incidentes (o IRP, Incident Response Plan) es un documento que define exactamente qué hacer, quién lo hace y cómo comunicarlo cuando sufres un ciberataque. No es un PDF de 200 páginas que nadie lee: es una guía operativa, clara y ensayada.
El framework más reconocido es el del NIST (National Institute of Standards and Technology), concretamente su publicación SP 800-61, que divide la gestión de incidentes en cuatro fases:
- Preparación: herramientas, formación, equipo designado.
- Detección y análisis: identificar que algo raro está pasando.
- Contención, erradicación y recuperación: parar el golpe, limpiar y volver a la normalidad.
- Actividad post-incidente: lecciones aprendidas (la parte que todo el mundo se salta).
En la Unión Europea, el Reglamento General de Protección de Datos (RGPD) te obliga a notificar brechas de datos personales a la autoridad competente —en España, la AEPD— en un máximo de 72 horas. Sin un plan de respuesta a incidentes, esas 72 horas se convierten en un caos de llamadas, emails y señalamientos. Con la Directiva NIS2, vigente desde octubre de 2024, las obligaciones se extienden a muchos más sectores.
Fase 1: Preparación — antes de que el fan se llene de materia orgánica
La preparación es el 80% de un buen plan de incidentes. Si esperas a tener el ransomware cifrándote los archivos para empezar a pensar en qué hacer, ya llegas tarde. Esto es lo que necesitas tener listo:
Monta tu equipo de respuesta (CSIRT)
Tu Computer Security Incident Response Team no tiene por qué ser un batallón. En una pyme puede ser el responsable de IT, alguien de dirección y un contacto externo de ciberseguridad. Lo importante es que cada persona sepa su rol:
| Rol | Responsabilidad |
|---|---|
| Incident Manager | Coordina toda la respuesta, toma decisiones clave |
| Analista técnico | Investiga el incidente, recoge evidencias, analiza logs |
| Comunicaciones | Gestiona la comunicación interna, externa y con autoridades |
| Legal/Compliance | Evalúa obligaciones RGPD, NIS2, notificaciones regulatorias |
| Dirección | Aprueba decisiones críticas (desconectar sistemas, pagar o no rescates) |
Herramientas que deberías tener configuradas
No puedes responder a lo que no ves. Estas son herramientas básicas que deberían estar funcionando antes del incidente:
- SIEM (Security Information and Event Management): Wazuh (open source), Splunk o Elastic Security para centralizar logs.
- EDR (Endpoint Detection and Response): CrowdStrike Falcon, SentinelOne o el gratuito ESET Endpoint Security.
- Backups offline: copias desconectadas de la red, verificadas periódicamente. Si el ransomware puede alcanzar tus backups, no son backups.
- VirusTotal y Any.Run: para analizar archivos y URLs sospechosas en sandbox.
- Have I Been Pwned: para verificar si credenciales de tu organización han sido filtradas.
Si gestionas servidores propios, te recomendamos también revisar nuestra guía de hardening básico de Linux, porque un servidor bien configurado desde el inicio reduce drásticamente la superficie de ataque.
Fase 2: Detección y análisis — Houston, tenemos un problema
La detección rápida es crítica. Según el informe de Mandiant M-Trends 2024, el tiempo medio de detección global (dwell time) ha bajado a 10 días, pero en Europa sigue rondando los 20. Eso son 20 días con un atacante campando por tus sistemas. Cada día extra multiplica el daño.
Las señales de que algo va mal suelen ser:
- Tráfico de red inusual: conexiones a IPs o dominios desconocidos, especialmente en horarios extraños. Un ataque de DNS spoofing puede pasar desapercibido si no monitorizas tus consultas DNS.
- Procesos desconocidos: consumo anómalo de CPU o RAM, servicios que no reconoces.
- Emails sospechosos reportados: si un empleado reporta un email con una factura falsa, no lo ignores. Donde hay una, suele haber más.
- Alertas del SIEM/EDR: para eso están, léelas.
- Cuentas con comportamiento anómalo: logins a las 3 de la madrugada desde otro país, cambios masivos de permisos.
Cuando detectas un posible incidente, lo primero es clasificarlo. No todos los incidentes son iguales ni requieren la misma respuesta:
| Severidad | Ejemplo | Tiempo de respuesta |
|---|---|---|
| Crítica | Ransomware activo, exfiltración de datos confirmada | Inmediato (minutos) |
| Alta | Acceso no autorizado a sistemas, malware detectado | 1-4 horas |
| Media | Phishing exitoso sin compromiso confirmado | 24 horas |
| Baja | Intentos de acceso fallidos, spam masivo | 48-72 horas |
Fase 3: Contención, erradicación y recuperación — manos a la obra
Aquí es donde la respuesta a incidentes se pone seria. Tienes tres objetivos: parar la hemorragia, eliminar la causa y volver a funcionar.
Contención: aislar para no contaminar
La regla de oro: no apagues el equipo afectado. Apagarlo destruye evidencia volátil en RAM que puede ser crucial para entender el ataque. En su lugar:
- Aísla el equipo de la red: desconecta el cable de red o desactiva el WiFi, pero déjalo encendido.
- Bloquea las cuentas comprometidas: cambia contraseñas, revoca tokens de sesión, desactiva accesos VPN.
- Preserva los logs: copia los registros de firewalls, proxies, servidores de correo y Active Directory a un almacenamiento seguro fuera del alcance del atacante.
- Documenta todo: hora, acción tomada, por quién. Un incidente sin documentar es un incidente que se repetirá.
Si el ataque involucra malware como Emotet o cualquiera de sus variantes, la contención es especialmente urgente porque se propagan lateralmente a una velocidad alarmante.
Erradicación: fuera bichos
Una vez contenido, toca encontrar y eliminar la causa raíz. Esto implica:
- Identificar el vector de entrada: ¿fue un email de phishing? ¿Una vulnerabilidad sin parchear? ¿Un USB que alguien conectó sin pensar?
- Escanear todos los sistemas con herramientas como Malwarebytes, ESET Online Scanner o Microsoft Safety Scanner.
- Revisar indicadores de compromiso (IoCs): hashes de archivos maliciosos, IPs de C2, dominios sospechosos. Plataformas como MISP o AlienVault OTX te ayudan a cruzar estos datos.
- Parchear la vulnerabilidad explotada. Si fue un CVE conocido, aplicar el parche inmediatamente.
Recuperación: volver a la vida
La recuperación debe ser gradual y verificada:
- Restaura desde backups limpios (verificados como no comprometidos).
- Reconstruye sistemas afectados desde cero si es necesario. Si el atacante tuvo acceso root, no te fíes de "limpiar": reinstala.
- Monitoriza intensivamente durante las primeras 48-72 horas post-recuperación. Los atacantes suelen dejar puertas traseras.
- Restablece servicios por prioridad: primero los críticos para el negocio, después el resto.
Un error común es precipitarse en la recuperación. Volver a conectar un sistema que aún tiene el malware latente es como apagar un incendio y volver a entrar al edificio sin comprobar la estructura. La gestión de incidentes efectiva requiere paciencia.
Fase 4: Lecciones aprendidas — la que nadie quiere hacer
Esta fase es la que convierte un desastre en una inversión. Dentro de las 48 horas posteriores al cierre del incidente, reúne al equipo y responde a estas preguntas:
- ¿Qué pasó exactamente y cuál fue la línea temporal?
- ¿El plan de incidentes funcionó? ¿Qué falló?
- ¿Cuánto tardamos en detectar, contener y recuperar?
- ¿Qué herramientas nos faltaron?
- ¿Necesitamos formación adicional?
Documenta las conclusiones y actualiza el plan. Un plan de incident response que no se actualiza después de cada incidente es pura decoración. Si además gestionas dispositivos conectados en tu red, conviene echar un vistazo a cómo proteger los dispositivos IoT revisando las guías de domótica segura.
La clave está en hacer simulacros regulares. El estándar ISO 27035 (gestión de incidentes de seguridad) recomienda ejercicios de tabletop al menos dos veces al año: escenarios ficticios donde el equipo practica la respuesta sin presión real. Es como un simulacro de incendio, pero para bits.
Preguntas frecuentes
¿Debo pagar un rescate de ransomware?
La recomendación de las autoridades (INCIBE, Europol, FBI) es no pagar. El 80% de las organizaciones que pagan vuelven a ser atacadas, según un estudio de Cybereason de 2024. Pagar financia al crimen organizado y no garantiza la recuperación de los datos. Invierte ese dinero en backups y prevención.
¿Cuánto tiempo tengo para notificar una brecha de datos según el RGPD?
Dispones de 72 horas desde que tienes conocimiento de la brecha para notificar a la autoridad de protección de datos (AEPD en España). Si afecta a derechos y libertades de los afectados, también debes notificarles a ellos sin dilación indebida. El incumplimiento puede acarrear multas de hasta 20 millones de euros o el 4% de la facturación global.
¿Qué diferencia hay entre un CERT, un CSIRT y un SOC?
Un CERT (Computer Emergency Response Team) y un CSIRT son esencialmente lo mismo: equipos que gestionan incidentes de seguridad. El SOC (Security Operations Center) es más amplio, monitoriza en tiempo real 24/7 y se encarga también de la detección proactiva. En pymes, suele externalizarse como SOC-as-a-Service.
¿Un plan de respuesta a incidentes es obligatorio legalmente?
Depende del sector. Con la Directiva NIS2 y el Esquema Nacional de Seguridad (ENS), muchas organizaciones en España están obligadas a tener procedimientos formales de gestión de incidentes. Incluso si no estás obligado, el RGPD exige medidas técnicas y organizativas adecuadas, y un plan de respuesta es una de las más básicas.
¿Puedo gestionar un incidente grave yo solo si soy autónomo?
Puedes gestionar incidentes menores, pero ante un ataque grave, contacta con el INCIBE-CERT (017, gratuito y confidencial). También existen empresas de respuesta a incidentes que trabajan por retainer. Tener un contacto preestablecido es parte de la preparación: buscarlo con el pelo en llamas no es lo ideal.
Montar un plan de respuesta a incidentes no es glamuroso ni viral, pero es lo que marca la diferencia entre una crisis gestionada y un desastre con portada. Empieza por lo básico: identifica tu equipo, documenta tus activos, haz backups verificados y ensaya. Y si quieres seguir mejorando tu postura de seguridad, explora el resto de artículos de nuestro blog — tenemos material para mantener a los malos lejos de tu bandeja de entrada y de todo lo demás.
