Diagrama de flujo de respuesta ante incidentes de seguridad

¿Qué es diagrama de flujo de respuesta ante incidentes de seguridad?

Un proceso de respuesta ante incidentes de seguridad es la secuencia que sigue una organización desde que alguien detecta algo sospechoso hasta que se cierra el registro del incidente. A propósito, no es lo mismo que el proceso de gestión de incidencias de TI. El objetivo no es solo restablecer el servicio: es averiguar qué hizo el atacante, impedir que siga haciéndolo, mantener las pruebas intactas y decidir si el incidente debe comunicarse a una autoridad.

Casi todos los marcos publicados comparten el mismo esqueleto. NIST SP 800-61r2 lo divide en preparación, detección y análisis, contención, erradicación y recuperación, y actividad posterior al incidente. ISO/IEC 27035 habla de planificar y preparar, detección y comunicación, evaluación y decisión, respuestas y lecciones aprendidas. Este diagrama sigue esa forma y saca a la superficie las dos decisiones que más se discuten en pleno incidente: si esto es realmente un incidente de seguridad y si la brecha es notificable.

Lo que los equipos hacen mal bajo presión casi siempre son las reglas de orden. Contener un equipo apagándolo destruye las pruebas de la memoria volátil. Reconstruir un servidor antes de analizar el alcance te deja sin forma de demostrar qué se llevaron. Restaurar el servicio antes de verificar que los sistemas están limpios reinfecta todo el parque. Acordar la secuencia por adelantado, con un carril por rol, es lo que hace que esas reglas sobrevivan a una llamada a las tres de la madrugada.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles por rol (Notificante y detección, Equipo de seguridad, Coordinador del incidente, Operaciones de TI, y Legal y comunicación) repartidos en cinco fases: Detección y comunicación, Triaje y clasificación, Contención, Erradicación y recuperación, y Notificación y revisión
• Detección y comunicación: la actividad sospechosa se comunica por un único canal de incidentes y el equipo de seguridad registra el incidente e inicia la cronología
• Una decisión «¿Incidente de seguridad confirmado?» después del triaje, que manda los falsos positivos a un registro cerrado y los incidentes confirmados a «Clasificar severidad e impacto»
• Una decisión «¿Incidente de severidad alta?» que asigna un coordinador del incidente con nombre y apellidos en los casos graves y lleva el resto directamente a la contención
• La contención partida en dos (aislar primero los sistemas afectados y aplicar después la contención a largo plazo), con «Preservar pruebas e imágenes forenses» en medio, seguida del análisis del alcance, la erradicación y una comprobación «¿Sistemas verificados limpios?» que devuelve el flujo al aislamiento cuando falla
• Una decisión «¿Brecha notificable?» que vive en el carril de Legal y comunicación, con la notificación a la autoridad de control y a los interesados dentro del plazo legal, y después la revisión posterior al incidente y el cierre con las lecciones registradas

Cuándo usar esta plantilla

• Estás escribiendo o actualizando un plan de respuesta ante incidentes y necesitas una sola página que muestre quién hace qué y en qué orden
• Preparáis una auditoría de ISO 27001 o un cuestionario de seguridad de un cliente y os han pedido enseñar un proceso de respuesta documentado (el diagrama evidencia el proceso, no demuestra por sí solo la conformidad)
• Vais a hacer un ejercicio de simulación y queréis tener delante los puntos de decisión, los traspasos y el reloj de notificación para ponerlos a prueba
• Incorporáis analistas nuevos, o una guardia que incluye a personas ajenas al equipo de seguridad
• Queréis que seguridad, operaciones de TI y legal acuerden sus traspasos antes de un incidente y no durante uno

Cómo funciona

1. Renombra los carriles con vuestros roles reales

   Sustituye los cinco carriles por los roles que de verdad tienes: SOC o MSSP, service desk, responsable de seguridad, equipo de plataforma, delegado de protección de datos, forense externo o abogado especializado en brechas. Si un rol no existe, borra el carril en lugar de dejarlo sin nadie detrás.

2. Fija vuestros criterios de severidad

   Abre el paso «Clasificar severidad e impacto» y sustituye el comentario por vuestra propia matriz: qué convierte un incidente en severidad alta, quién está facultado para declararlo y a qué tiempo de respuesta os compromete cada nivel.

3. Ajusta el plazo de notificación y la autoridad

   Edita la decisión «¿Brecha notificable?» para que nombre los regímenes que os aplican: RGPD de la UE o del Reino Unido (72 horas ante la autoridad de control), NIS2, normativa sectorial y los plazos de aviso contractuales a clientes, que a menudo son más cortos que los legales.

4. Añade los contactos que hacen falta a las 3 de la madrugada

   Pon en los comentarios de cada caja el canal de incidentes, el teléfono de guardia, el turno del coordinador del incidente y dónde se custodian las pruebas, para que el diagrama sirva durante un incidente y no solo en una revisión posterior.

5. Ajusta los bucles y añade los pasos que falten

   Decide si la rama de «¿Sistemas verificados limpios?» que vuelve al aislamiento encaja con vuestra forma de trabajar, y añade lo específico de vuestro entorno: activar al proveedor forense contratado, notificar al seguro de ciberriesgo o aprobar la comunicación a clientes.

6. Ponlo en circulación para su aprobación y guarda la versión

   Comparte el diagrama con el responsable de seguridad, operaciones de TI y legal para que lo firmen, y conserva la versión aprobada. Un plan de respuesta ante incidentes es un documento controlado, y la versión que entrenáis debería ser la versión que publicáis.

Preguntas frecuentes

¿Cuáles son las fases del proceso de respuesta ante incidentes?

Este diagrama usa cinco: detección y comunicación, triaje y clasificación, contención, erradicación y recuperación, y notificación y revisión. Encaja de cerca con NIST SP 800-61r2, que habla de detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente. NIST tiene además una fase de preparación, pero la preparación es trabajo continuo (herramientas, turnos, simulacros, contratos de retén) y no un paso que se ejecute durante el incidente, así que no se dibuja en el flujo.

¿En qué se diferencia de la gestión de incidencias de TI?

Una incidencia de servicio de TI termina cuando el servicio está restablecido. Un incidente de seguridad no, porque hay un adversario. Restaurar demasiado pronto puede devolverle el acceso al atacante, y hay obligaciones que un proceso ITIL no lleva encima: preservar las pruebas antes de reconstruir, determinar qué datos se vieron afectados y notificar a autoridades y personas cuando corresponda. Por eso este diagrama pone la preservación de pruebas y las imágenes forenses antes de la erradicación, y añade una rama de notificación después de la recuperación.

¿Quién debe ser el coordinador del incidente y cuándo se nombra?

El coordinador debe ser quien tenga autoridad para decidir (sacar un sistema de producción, contratar asesoría externa, contactar con clientes), no necesariamente la persona más técnica disponible. Coordina, no investiga. En este diagrama solo se asigna cuando la decisión «¿Incidente de severidad alta?» responde que sí; los incidentes de menor severidad se quedan en el equipo de seguridad. En un incidente largo, el rol se traspasa de forma explícita en cada cambio de turno.

¿Cuándo empieza a contar el plazo de 72 horas para notificar una brecha?

Con el RGPD de la UE y del Reino Unido, las 72 horas corren desde que la organización tiene constancia de que se ha producido una violación de datos personales, no desde que empezó el ataque ni desde que concluye la investigación, y puedes notificar por fases si aún no tienes la foto completa. Avisar a las personas afectadas es una prueba distinta: se exige sin dilación indebida cuando la brecha entraña un alto riesgo para ellas. Otros regímenes cuentan plazos diferentes, así que escribe en la caja de decisión el que os aplique a vosotros.