¿Qué es la respuesta a incidentes en ciberseguridad y cómo gestionarla en IT?

No me gusta, pero voy a empezar con un tópico, porque tiene toda la razón: Con los incidentes de ciberseguridad, la pregunta no es si se producirán, sino cuándo. Y ante lo inevitable en la vida, solo podemos hacer dos cosas: prepararnos lo mejor posible y responder lo mejor posible cuando suceda. Hoy, trataremos a fondo lo segundo.
La IA generativa está aumentando todavía más los ataques de phishing, los hackers emplean métodos cada vez más sofisticados y los actores maliciosos se multiplican, incluyendo los estatales en un ambiente de tensión. Dicho de otra manera, hoy día, los responsables de ciberseguridad son un puñado de marines coloniales rodeados de aliens.
Y no paran de venir más.
Por eso, la delgada línea que separa una crisis catastrófica de un daño controlado durante un incidente está hecha de nuestro proceso metódico de respuesta.

¿Qué es la respuesta a incidentes de seguridad?

Un proceso metódico es la clave, porque correr como pollos sin cabeza apagando fuegos a salto de mata nunca funciona ante incidentes, ya que:

• Los actores maliciosos aprovecharán cualquier descuido en la resolución para seguir haciendo daño.
• La legislación de ciberseguridad caerá sobre nosotros con multas cuantiosas (que se unirán a las pérdidas del ataque en sí) si nuestra respuesta es deficiente.

Por eso, una gestión de incidentes de ciberseguridad es un proceso sistemático para detectar, contener y erradicar amenazas que comprometen la confidencialidad, integridad o disponibilidad de activos digitales.
Esta respuesta la realizaremos:

• Integrando equipos especializados (SOC, CSIRT…).
• Tecnologías y herramientas clave (SIEM, SOAR, IDS…).
• Las mejores prácticas, basadas en estándares como NIST SP 800-61r2 o la ISO/IEC 27035.

Con eso, trataremos de conseguir los objetivos de una buena gestión de incidentes de seguridad:

• Minimizar daños operativos y reputacionales
• Acortar el tiempo de detección y contención (MTTD/MTTR)
• Cumplir requisitos legales (GDPR, NIS2…)
• Que esos incidentes sirvan para fortalecernos ante futuras amenazas.

Elementos clave de un plan de respuesta a incidentes

Antes de ver los pasos de la receta, debemos tener claros y preparados los ingredientes necesarios. Por eso, he aquí los elementos clave de un plan de respuesta a incidentes.

Componente	Descripción	Ejemplo
Roles definidos	Responsabilidades claras durante incidentes.	Líder de respuesta a incidentes, forense, encargado de comunicaciones, etc.
Playbooks técnicos	Procedimientos para tipos específicos de incidentes.	Playbook para ransomware con pasos de contención.
Matriz de comunicación	Protocolos para notificar a stakeholders.	Alertar a la Agencia de Protección de Datos en <72h si hay fuga de datos personales.
Inventario de activos	Mapeo de sistemas críticos y sus dependencias para conocer el territorio como la palma de la mano.	Disponer de una excelente CMDB como la integrada en Pandora SIEM.

Fases del proceso: Del incidente a la recuperación

Reinventar la rueda no tiene sentido cuando podemos poner a nuestro coche unas con eficacia probada. Por eso, vamos a ver paso a paso cómo gestionar un incidente de seguridad. Por practicidad y claridad, la estructura de pasos que usaré estará alineada con las mejores prácticas de la NIST SP 800-61r2.
En realidad, toda buena gestión de incidentes seguirá las fases que vamos a ver. Puede que algunas estén más agrupadas en menos etapas, como en la ISO 27035, o incluso más desglosadas, pero el tren de toda respuesta adecuada a un incidente de ciberseguridad pasa por las siguientes estaciones.

Fase 1: Preparación

Quien practica deportes de contacto suele escuchar el proverbio: Hard training, easy fight. Aunque no lo parezca, la ciberseguridad también es una pelea full contact y se aplica lo mismo. Cuanto más nos preparemos antes del incidente, más sencilla y rápida será la respuesta.
El objetivo de esta fase es construir una fortaleza lo más inexpugnable posible con los defensores más temibles en las murallas. O dicho en corporativo cuando tengas que vender el plan de respuesta a incidentes al consejo de administración: Construir resiliencia proactiva.
Algunas acciones críticas en esta fase son:

• Hardening de sistemas (parcheo, configuración segura…)
• Simulacros y/o tabletop exercises para equipos, o prácticas de Equipo Rojo / pentesting.
• Instalación y configuración personalizada del SIEM…

Fase 2: Identificación

No todo el humo es fuego en ciberseguridad, o al menos no todo requiere sacar el camión pesado y las sirenas, por eso el objetivo principal es validar y clasificar eventos sospechosos.
Aquí es donde brilla una herramienta SIEM como Pandora SIEM, haciéndonos la vida fácil.
Hoy día, las técnicas más habituales en esta fase son:

• La correlación de eventos en SIEM.
• Análisis de IOC (Indicadores de Compromiso) y comportamientos con un EDR. Esto va más allá de la identificación de antivirus tradicionales, basados en firmas o una heurística demasiado tosca para un entorno profesional.

Lo ideal es un trabajo conjunto de SIEM más EDR. Un ejemplo práctico de esto es Pandora SIEM detectando conexiones anómalas a IPs de C2 (Command & Control) gracias a que correlaciona logs de firewall y endpoints (vía EDR o bien agente propio instalado).

Fase 3: Contención

Ha sucedido, los dos pasos anteriores no han podido mitigar a tiempo la amenaza y tenemos ratas en las paredes (una referencia literaria demasiado geek quizá).
En esta fase, el objetivo es limitar la propagación.
Para ello, normalmente emplearemos primero estrategias de corto plazo como quien hace un torniquete en la batalla y, por ejemplo, aislaremos segmentos de red, equipos, etc. Luego implementamos acciones más globales, como resetear credenciales comprometidas.
En la contención rápida a corto plazo, la automatización puede ayudar y aquí es donde brilla el SOAR ejecutando playbooks.
Un ejemplo de playbook ante el ejemplo de conexión anómala que he puesto en la fase anterior podría ser:

• Bloquear la IP maliciosa en el firewall.
• Aislar el endpoint infectado vía integración con el EDR.
• Crear un ticket en Pandora ITSM para el equipo forense.

Fase 4: Erradicación

Hora de eliminar esas ratas y, especialmente, cualquier otra sorpresa como APTs (Advanced Persistent Threat) que permita a los atacantes mantener acceso residual tras la gestión del incidente. Por ejemplo, un rootkit de UEFI puede resistir una reinstalación del sistema operativo.
La cuestión aquí no es eliminar síntomas, sino causas raíz con acciones como:

• Erradicación de malware.
• Parcheado de vulnerabilidades explotadas (ej: CVE-2023-34362).

La cuestión clave en esta fase es que la buena erradicación no solo requiere lanzallamas, sino una comprensión completa de lo que ha ocurrido.
Si no sabemos cómo consiguió penetrar nuestra muralla el actor malicioso, o no ubicamos ese rootkit en la BIOS, será como matar cucarachas sin encontrar el nido. Al día siguiente, fiesta otra vez en cuanto demos la luz de la cocina.

Fase 5: Recuperación

En esta fase, el objetivo no es solamente recuperar la actividad y que la vida siga igual, como dice la canción. La clave es restablecer el servicio con controles reforzados.
Es decir, que nos volvemos más fuertes y seguros. Prácticas clave en esta fase son, por ejemplo:

• Restauración desde backups inmutables.
• Monitoreo post-recuperación para detectar actividad residual (como esos posibles APTs y actividades sospechosas).

Fase 6: Revisión post-mortem

Como el objetivo es que la adversidad nos haga más fuertes, la clave aquí es aprender qué ocurrió exactamente, por qué ocurrió y qué medidas hemos puesto para que no suceda de nuevo.
En esta fase, el entregable práctico podría consistir en:

• Un informe con el timeline del incidente y las técnicas ATT&CK identificadas que se han usado contra nosotros.
• Una actualización de playbooks y reglas de detección que muestren que de verdad hemos cambiado.

Equipos de respuesta a incidentes: CSIRT, CERT y SOC

A la hora de afrontar un incidente, los equipos humanos dependerán de la organización de la entidad y sus recursos.
Normalmente, si la organización posee cierto tamaño, habrá un SOC (Security Operations Center) que se encarga de la vigilancia diaria y las tareas preventivas.
Cuanto más efectiva sea su labor, menos probabilidades de incidentes.
Luego, están el CSIRT (Computer Security Incident Response Team) y/o el CERT (Computer Emergency Response Team). ¿En qué se diferencian? En la práctica en más bien poco, la verdad, pero en ciberseguridad las abreviaturas gustan mucho y CERT es un término registrado de la Universis Carnegie Mellon. En general, se refiere a equipos especializados en respuesta a incidentes, que conocen lo que estamos viendo como la palma de su mano.
Muchas veces, una organización no dispondrá de CSIRT/CERT. En ese caso, empresas especializadas en ciberseguridad disponen de equipos de respuesta que puedes contratar para gestionar dicho incidente si tienes al equipo interno sobrepasado.
Esta tabla resume sus atribuciones.

Equipo	Función principal	Diferenciadores clave
SOC (Security Operations Center)	Monitorización proactiva 24/7	Foco en detección temprana y respuesta operativa
CSIRT/CERT	Manejo de incidentes críticos	Especialización en análisis forense y coordinación de crisis

Herramientas tecnológicas imprescindibles

Buena suerte acudiendo con una espada de madera a un bombardeo orbital, en el que los actores maliciosos parecen disponer de torpedos de fotones ilimitados.
La realidad es que la ciberseguridad se ha vuelto tan compleja e imposible de abarcar, que no gestionaremos bien un incidente sin herramientas especializadas que ayuden a detectar, mitigar, analizar y, en general, levantar un peso que es casi imposible gestionar de forma artesanal.
Entre esas herramientas de respuesta a incidentes, cabe destacar:

SIEM (Security Information Event Management)

Una aplicación que actúa como Ojo de Sauron que todo lo ve en nuestra infraestructura IT. O al menos, todo lo que le conectemos, normalmente mediante agentes que, instalados en dispositivos de todo tipo, envían información de su actividad.
Su poder se basa en la correlación centralizada de esos registros.
Los SIEM más avanzados, como Pandora SIEM, también utilizan inteligencia artificial para la detección avanzada de patrones complejos de ataque, que cada día son más sofisticados esquivando sistemas de detección.
Su fortaleza está en esa capacidad de análisis instantáneo y extensivo, junto con la personalización de alertas ante posibles incidentes, aumentando las probabilidades de detenerlos en la muralla antes de que hagan brecha.

SOAR (Security Orchestration, Automation Response)

Si la fortaleza del SIEM es su capacidad de análisis, la del SOAR es la de desplegar acciones automatizadas basadas en dicho análisis.
Esto aporta una enorme ventaja en la gestión de incidentes a muy corto plazo, deteniendo el incendio cuando todavía es chispa y no llama.
Esta actividad la realiza mediante la ejecución de playbooks automatizados.
Por ejemplo, un playbook de respuesta a phishing podría ser:

• Aislar al usuario comprometido de dedo inquieto que pincha en todo lo que ve.
• Eliminar emails maliciosos de los buzones.
• Enviar una alerta al SOC para que investigue.

Como vemos, SIEM y SOAR pueden colaborar para una gestión de incidentes óptima y, hoy día, las fronteras entre estas aplicaciones se diluyen. Así, un SIEM puede tener prestaciones de automatización de respuestas y un SOAR ciertas características de SIEM, según sea la herramienta.

EDR/XDR (Endpoint Detection Response / Extended Detection Response)

Este software se instala en los endpoints y los monitoriza. Al igual que los antivirus tradicionales, puede realizar diversas acciones ante amenazas, pero estamos hablando de una evolución mucho más sofisticada que consultar un archivo de firmas.
Así, conectado a un SIEM, este puede analizar lo que le llega y, si tiene capacidad de respuesta, ordenar al EDR que actúe.
Un ejemplo de acción del EDR en un incidente de ransomware sería poner en cuarentena el equipo afectado, mitigando la amenaza y ahorrándonos mucho trabajo.
Otras herramientas útiles, según la organización y la infraestructura IT, podrían ser:

• UEBA (User and Entity Behavior Analytics): capaz de ir más allá del análisis clásico de virus y malware, detectando comportamientos sospechosos en usuarios o equipos.
• IDS/IPS (Intrusion Detection/Protection System): que se usan en detección y bloqueo de tráfico malicioso en red.

Casos prácticos de respuesta a incidentes

Cada incidente y organización son un mundo, sin embargo, he aquí algunos ejemplos de incidentes de seguridad y su ciclo de vida a vista de pájaro.

Caso 1: Ataque de ransomware

El clásico que nunca dejará de fastidiar. Alguien pincha donde no debe y comienza la fiesta. Este sería el proceso básico de gestión de incidentes.

• Identificación: El EDR del equipo infectado alerta sobre cifrado masivo de ficheros. Salta la alarma.
• Contención: La organización tiene SOAR y este aísla endpoints afectados en menos de 5 minutos. El SOC investiga.
• Erradicación: Se procede a la eliminación de malware y, si el origen era un phishing se envía al usuario a los campos de reeducación, advirtiendo también al resto. Se restauran los backups limpios que estaban a salvo.
• Lección aprendida: Quizá la organización necesitaba una mejor segmentación de red, porque se extendió demasiado donde no debía.

Caso 2: Fuga de datos por amenaza interna

En esta ocasión, tenemos al enemigo en casa, un empleado descontento por esos campos de reeducación en ciberseguridad decide tomarse la justicia por su mano.

• Identificación: Pandora SIEM detecta descargas anómalas por el usuario desde el log del EDR.
• Contención: Salta la alerta y se conecta con el EDR para bloquear el equipo. Pandora SIEM envía la alarma al SOC y abre ticket en ITSM.
• Recuperación: Pandora SIEM permite ver la línea de tiempo con logs de acceso, por si el usuario ha intentado algo similar de maneras más discretas anteriormente. Se investiga la posible brecha de datos y se toman medidas contra el usuario.
• Mejora tras post-mortem: Se decide implementar un DLP (Data Loss Prevention) más estricto.

Caso 3: Ataque DDoS

Un incidente de denegación de servicio es otro clásico intemporal, que afecta a webs, servicios, etc.

• Identificación: El IDS detecta un pico de tráfico UDP en la red.
• Contención: Se redirige el tráfico a un Scrubbing Center que, por suerte, el becario geek decidió montar como proyecto personal mientras el resto se reía.
• Mejora post-mortem: Faltaba un plan claro, de modo que se asciende al becario y se habla con Cloudflare, por ejemplo, para contratar medidas anti DDoS.

Como vemos, las fases de gestión de incidentes no están escritas en piedra y son un marco guía adaptable.
En una DDoS o exfiltración de datos interna, la parte de erradicación en sí no aplicaría (a menos que la organización sea la banda de Tony Soprano y lo que se erradique sea el usuario).

Cómo optimiza Pandora SIEM la respuesta a incidentes

Nos encantaría decirte que Pandora SIEM conseguirá que no tengas que aprenderte todo esto, porque te protegerá al 100% de incidentes. Pero nadie puede prometer eso. De hecho, si alguien lo hace, corre (en dirección contraria a quien lo diga, claro).
Lo que sí es cierto es que Pandora SIEM:

Minimizará las probabilidades de que ocurra el incidente todo lo posible.

Reducirá el tiempo necesario para la resolución del incidente de seguridad.

¿Cómo? De 3 formas principales.

1. Correlación avanzada

La gran clave es su correlación avanzada de eventos que por separado no parecen nada, pero juntos presagian el desastre.
Así, tiene reglas personalizadas para detectar patrones complejos de ataque, al aglutinar toda la información y tener un Palantir en nuestra infraestructura que nos diga si se nos están colando por detrás hobbits con un anillo peligroso.

2. Gestión unificada del incidente

Integrado de manera nativa con Pandora ITSM, Pandora SIEM permite gestionar todo el ciclo de vida del incidente desde una única plataforma. Eso incluye:

• Sistema de tickets personalizable para trazar acciones, estado y responsables.
• La CMDB integrada para conocer cada activo, su estado, qué pasó en cada uno…
• Gestión de cambios realizados.
• Control de los SLA para la posible afectación de los niveles de servicio por el incidente.
• Capacidad de emprender acciones automatizadas en conexión con un SOAR y mucho más.

3. Toda la información post-mortem de un vistazo y cómodamente

Ante un incidente, hay que rendir cuentas. Y en algunos casos, no solo ante responsables o clientes. Una brecha de información puede precisar una comunicación con la Agencia de Protección de Datos, o bien afrontar una auditoría si somos una organización de importancia estratégica.
Pandora facilita todo lo posible ese trago permitiendo extraer toda la información necesaria, además de que esa misma consolidación permite reconstruir el incidente de forma clara.
Eso otorga la clave principal que no me cansaré de repetir: El conocimiento profundo de lo sucedido.

Buenas prácticas y errores comunes en la gestión de incidentes

Nos acercamos al final del camino y no está de más dejar claros algunos errores y buenas prácticas en incidentes de seguridad.
En cuanto a errores, en Pandora hemos visto patrones demasiado comunes como:

• Silos tecnológicos aislados entre SIEM, EDR, ITSM… Esa fragmentación nos hace ciegos a ataques complejos y dificulta una detección y su resolución.
• Ignorar la revisión post-mortem y las mejoras. Porque todos sabemos cómo son las reuniones, que se asiente, se está muy de acuerdo y luego viene esa extraña amnesia que hace que todo siga igual.

Y en cuanto a buenas prácticas, además de hacer lo contrario a esos errores, es recomendable:

• Realizar simulacros trimestrales de incidentes.
• Implementar automatización para respuestas básicas.
• Mantener backups inmutables y offline.

La realidad a la que nos enfrentamos es que tarde o temprano habrá un incidente. Citaría escalofriantes estadísticas sobre la prevalencia actual, pero las estadísticas no persuaden y, por otro lado, estoy convencido de que se quedan cortas. Al fin y al cabo, el mejor hacker es el que no detectas y he conocido algunos que parecen magos.
Por eso, la clave de la gestión de incidentes es recordar aquella horrible, pero cierta, frase corporativa: Resiliencia proactiva.
Es decir, blindarnos lo que podamos y no bajar la guardia, aprendiendo y aplicando constantemente nuevas técnicas y herramientas. Al fin y al cabo, es lo que están haciendo los actores maliciosos, ellos son la demostración de que la mejora continua no es un mito.