Diagrama de flujo de respuesta a incidentes de ciberseguridad (SOC)

¿Qué es diagrama de flujo de respuesta a incidentes de ciberseguridad (soc)?

Un proceso de respuesta a incidentes de ciberseguridad es el ciclo de trabajo que sigue un centro de operaciones de seguridad o un CSIRT en cuanto salta una detección. Triar y enriquecer la alerta, decidir si es un positivo real, declarar el incidente y fijar su severidad, poner a alguien al mando, encontrar todos los activos y cuentas que tocó el atacante, contener sin destruir la evidencia, eliminar la amenaza, demostrar que ya no está y solo entonces restaurar. Esta plantilla dibuja esa secuencia en cinco carriles: Detección / SOC, Analista de respuesta, Responsable del incidente, Operaciones TI y Dirección.

Conviene dejar claro qué no es este proceso, porque hay dos procesos vecinos que a menudo se le funden dentro y los tres salen perdiendo. No es la gestión de incidencias de TI, que se mide por restablecer un servicio interrumpido y se cierra cuando el usuario vuelve a trabajar; un incidente de seguridad no termina cuando el servicio vuelve, porque restaurar antes de tiempo puede devolverle el acceso al atacante. Tampoco es la notificación de brechas. Decidir si hubo datos personales afectados, si hay que informar a una autoridad de control o a un cliente y con qué reloj, corresponde a asesoría jurídica, al delegado de protección de datos y a comunicación, corre contra plazos legales y no técnicos, y vive en el proceso más amplio de respuesta ante brechas. Este diagrama corre en paralelo a ese trabajo en vez de absorberlo.

La forma sigue la secuencia que comparten casi todas las guías publicadas. El modelo de seis pasos de SANS (preparación, identificación, contención, erradicación, recuperación y lecciones aprendidas) encaja directamente, y la NIST SP 800-61 revisión 2 agrupa el mismo trabajo como detección y análisis; contención, erradicación y recuperación; y actividad posincidente. La revisión 3 reorganiza la guía en torno a las funciones del Cybersecurity Framework 2.0 en lugar de una lista fija de fases, pero el orden en el que trabaja de verdad un analista no cambia. La preparación no se dibuja como una caja porque es trabajo continuo (herramientas, turnos, contratos de retén, ejercicios) y no un paso que se ejecute durante el incidente. Lo que el diagrama está aquí para proteger es el orden: evidencia antes de erradicar, verificación antes de restaurar, y una persona con nombre que pueda autorizar sacar de línea un sistema en producción.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles de rol (Detección / SOC, Analista de respuesta, Responsable del incidente, Operaciones TI y Dirección) repartidos en seis fases: Detección y triaje, Declaración, Alcance y contención, Erradicación, Recuperación y Lecciones aprendidas
• El triaje en el carril del SOC: «Triar y enriquecer la alerta» alimenta la decisión «¿Verdadero positivo?», cuya rama No ejecuta «Cerrar la alerta y ajustar la regla», de modo que un falso positivo cambia la detección en lugar de limitarse a descartarse
• El traspaso y el mando: «Declarar el incidente y su severidad» mueve el trabajo del SOC al analista de respuesta, y «Designar responsable del incidente» pone nombre a quien decide durante el resto del incidente
• Una decisión «¿La contención interrumpe servicios?» propiedad del responsable del incidente, cuya rama Sí pasa por «Autorizar la contención con impacto» en el carril de Dirección antes de que Operaciones TI ejecute «Aislar equipos y cuentas afectados»
• Evidencia antes de la limpieza: «Preservar evidencias e imágenes forenses» se sitúa entre la contención y la columna de erradicación, que cubre buscar otros accesos del atacante, eliminar el malware y la persistencia, y rotar credenciales y parchear las vulnerabilidades explotadas
• Una decisión de verificación «¿Amenaza eliminada por completo?» que vuelve a «Identificar activos y cuentas afectados» cuando falla, y después reconstruir desde copias limpias, vigilar los sistemas restaurados desde el carril del SOC, la revisión posincidente y «Actualizar reglas de detección y playbooks» antes del cierre

Cuándo usar esta plantilla

• Tienes un SOC o un CSIRT, o lo estás montando, y quieres el ciclo técnico en una sola página, desde la cola de alertas hasta la regla de detección que saltará la próxima vez
• Estás escribiendo la parte operativa de un plan de respuesta a incidentes y necesitas dejar acordado el orden de contención, evidencia y erradicación antes de un incidente y no discutirlo durante uno
• Preparas un ejercicio de simulación o una prueba de equipo morado y quieres los puntos de decisión, los bucles y los traspasos dibujados para tener algo contra lo que probar
• Necesitas que seguridad, operaciones TI y dirección acuerden por adelantado quién puede autorizar sacar de línea un sistema en producción, y qué pasa cuando esa persona está durmiendo
• Estás incorporando analistas y quieres la ruta de escalado de triaje a analista y de analista a responsable del incidente dibujada de forma explícita en lugar de aprendida por ósmosis

Cómo funciona

1. Renombra los carriles con vuestra estructura real

   Sustituye Detección / SOC, Analista de respuesta, Responsable del incidente, Operaciones TI y Dirección por lo que tenéis de verdad: un MSSP externo, el nivel 1 y el nivel 2 en carriles separados, un equipo de plataforma o de cloud en lugar de operaciones TI, un proveedor forense contratado. Borra un carril antes que dejarlo sin nadie dentro, y funde el responsable del incidente en el carril del analista si una sola persona hace de verdad las dos cosas.

2. Pon vuestra matriz de severidad en el paso de declaración

   Abre «Declarar el incidente y su severidad» y sustituye la nota por vuestros propios criterios: qué convierte un incidente en crítico, quién está autorizado a declararlo y a qué os compromete cada nivel en tiempo de respuesta, personas asignadas y llamada fuera de horario. La severidad es lo que gobierna todas las decisiones posteriores de este diagrama, así que merece la pena concretarla.

3. Fija la regla de autorización de la contención

   La rama «¿La contención interrumpe servicios?» solo funciona si alguien puede responderla a las tres de la madrugada. Deja escrito qué sistemas pueden aislarse por decisión del propio analista, cuáles exigen una decisión de negocio, quién toma esa decisión y qué se hace si no se le localiza en un plazo acordado.

4. Cierra las reglas de evidencia antes de la contención

   Anota vuestro orden de recogida en «Preservar evidencias e imágenes forenses»: memoria y estado de red en vivo antes que el disco, disco antes que los registros archivados, siguiendo el criterio de orden de volatilidad del RFC 3227. Indica que los equipos se aíslan a nivel de red en lugar de apagarse, y di dónde se guardan las imágenes y quién firma su custodia.

5. Define qué significa «amenaza eliminada por completo»

   Escribe los criterios de salida junto a la decisión «¿Amenaza eliminada por completo?»: la ventana de observación sin actividad del atacante, cada indicador barrido en todo el parque, cada credencial comprometida rotada, la vulnerabilidad explotada parcheada. Decide también si la rama de fallo vuelve al alcance, como aquí, o a la contención.

6. Conéctalo con los procesos de al lado y versiónalo

   Añade enlaces explícitos a vuestra ruta de notificación de brechas, a gestión de problemas o de cambios para los arreglos definitivos, y al ciberseguro o a la notificación a proveedores si os aplican. Después haz circular el diagrama entre el responsable de seguridad, operaciones TI y dirección para su aprobación y conserva la versión aprobada, porque el plan que ejercitáis debe ser el plan que publicáis.

Preguntas frecuentes

¿Cuáles son las fases de un proceso de respuesta a incidentes de ciberseguridad?

Este diagrama usa seis columnas: detección y triaje, declaración, alcance y contención, erradicación, recuperación y lecciones aprendidas. Eso encaja con el modelo de seis pasos de SANS (preparación, identificación, contención, erradicación, recuperación y lecciones aprendidas) y con la NIST SP 800-61 revisión 2, que agrupa el trabajo como detección y análisis; contención, erradicación y recuperación; y actividad posincidente. La revisión 3 reorganiza la guía en torno a las funciones del Cybersecurity Framework 2.0 en lugar de una lista fija de fases. La preparación no se dibuja como paso porque es trabajo continuo (ingeniería de detección, turnos, contratos de retén, ejercicios) que se hace antes de cualquier alerta, no durante una.

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

La gestión de incidencias de TI restablece un servicio interrumpido y se cierra cuando el usuario vuelve a trabajar. En un incidente de seguridad hay un adversario dentro, así que restablecer el servicio no es la meta: es el momento de máximo riesgo si la amenaza sigue presente, y por eso este diagrama pone una decisión de verificación antes de la recuperación. La notificación de brechas es el otro vecino. Decidir si hubo datos personales afectados, si hay que informar a una autoridad de control o a un cliente y dentro de qué plazo legal, es trabajo jurídico y de comunicación con un reloj legal, y corre en paralelo a la respuesta técnica en lugar de dentro de ella.

¿Por qué la preservación de evidencias va antes que la erradicación?

Porque las acciones de contención más habituales destruyen justo la evidencia que vas a necesitar. Apagar un equipo pierde el malware residente en memoria, las conexiones de red vivas, el material descifrado y los procesos inyectados. Reconstruir un servidor antes de entender el alcance elimina los artefactos que muestran cómo entró el atacante y hasta dónde llegó. El principio de orden de volatilidad descrito en el RFC 3227 es la regla práctica: captura primero memoria y estado en vivo, después el disco y por último los registros archivados. En este diagrama el paso de evidencias va después del aislamiento y antes de cualquier trabajo de erradicación, y los equipos se aíslan a nivel de red para que sigan encendidos.

¿Cómo se decide que la amenaza está eliminada del todo?

Con criterios escritos antes del incidente, no con un juicio del momento. Lo habitual: ninguna actividad del atacante observada en todo el parque durante una ventana de observación acordada; todos los indicadores de la investigación barridos en todos los equipos, no solo en los que alertaron; todas las credenciales que pudieron capturarse rotadas, incluidas cuentas de servicio y de máquina; y cerrada la vulnerabilidad o la mala configuración que permitió el acceso inicial. Cuando la respuesta es no, casi siempre significa que el alcance estaba mal y no que la limpieza fuera descuidada, y por eso aquí la rama de fallo vuelve a «Identificar activos y cuentas afectados» y no al aislamiento.

¿Quién autoriza una contención que deja fuera de línea un servicio en producción?

Alguien con autoridad para asumir el impacto de negocio, que rara vez es el analista que detectó el problema. Este diagrama enruta ese caso por el carril de Dirección, pero lo importante no es el nombre del carril: es que la decisión, el rol concreto y el plan alternativo si no se le localiza estén acordados de antemano. Muchos equipos preautorizan el aislamiento para una lista definida de sistemas y severidades, de modo que los casos comunes nunca esperan a una llamada, y reservan el escalado para los servicios que generan ingresos o afectan a la seguridad de las personas. Sin eso, la discusión ocurre mientras el atacante sigue trabajando.