Diagrama de flujo de respuesta a incidentes de ciberseguridad (SOC)
Diagrama de flujo con carriles del ciclo técnico de respuesta a incidentes de ciberseguridad que ejecuta un SOC o CSIRT: triaje de alertas, contención, erradicación, recuperación y ajuste de reglas.
Cómo funciona
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.
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.
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.
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.
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.
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.