Escalado de incidentes de seguridad: diagrama de flujo de SOC a CISO

¿Qué es escalado de incidentes de seguridad: diagrama de flujo de soc a ciso?

Un proceso de escalado de incidentes de seguridad es la respuesta a una única pregunta que se repite en cada nivel de severidad: quién necesita saberlo ahora, y quién puede decidir qué pasa a continuación. Empieza donde empieza el turno de un analista del SOC, con una alerta que hay que triar y confirmar como un evento real y no como ruido. A partir de ahí, el diagrama de abajo sigue un único evento escala arriba, a través de una decisión de severidad que determina si se queda con el SOC o pasa al gestor de incidentes, una segunda decisión que determina si el gestor de incidentes puede manejarlo solo o se incorporan el CISO y el equipo de crisis, una comprobación de datos personales que traspasa a un proceso de brechas dedicado cuando aplica, una decisión sobre si hay que avisar a alguien fuera de la organización, y una cadencia de actualizaciones a la dirección que se mantiene hasta que el incidente se confirma contenido y se vuelve a bajar la escala.

Este diagrama, deliberadamente, no es la respuesta técnica en sí: no contiene ingeniería de detección, manejo de evidencias, mecánica de contención ni pasos de erradicación, que pertenecen a un proceso dedicado de respuesta a incidentes de ciberseguridad que corre por debajo de él. Tampoco es la prueba de severidad que usa una mesa de servicio de TI genérica para calificar una caída ordinaria, ni es el flujo regulatorio detallado para una brecha de datos personales confirmada, que tiene sus propias decisiones y su propio reloj legal en un proceso aparte. Lo que este diagrama gobierna es más estrecho y, en un incidente en curso, igual de importante: la propia vía de escalado, a quién se avisa en cada umbral, y el punto en el que es seguro dar por cerrado el incidente. Trátalo como un punto de partida que adaptar a vuestro propio plan de respuesta a incidentes, a vuestras obligaciones regulatorias y al criterio de quien ocupe el rol de CISO o equivalente en vuestra organización, no como un sustituto de ninguno de los dos.

Dos decisiones cargan con el peso de la escala. '¿Alcanza el umbral S1/S2?' recae en el analista del SOC porque es la primera persona que ve las evidencias y puede tomar esa decisión, y equivocarse en cualquiera de los dos sentidos, o entierra un evento grave en la cola del SOC, o despierta al CISO por un reporte de phishing. '¿Está contenido el incidente?' recae en el carril de dirección y equipo de crisis por la razón contraria: la contención es un juicio técnico que se hace en otra parte de la organización, pero la decisión de desactivar el equipo de crisis y detener la cadencia de actualizaciones pertenece a quienes lo convocaron. Entre esas dos, las decisiones '¿Hay datos personales afectados?' y '¿Se requiere notificación externa?' están deliberadamente en el carril Legal / privacidad, porque si existe o no una obligación es una cuestión legal incluso cuando el disparador fue técnico.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles (Analista del SOC, Gestor de incidentes, CISO / dirección de seguridad, Legal / privacidad y Dirección / equipo de crisis) repartidos en siete fases: Detección y triaje, Clasificación de severidad, Nivel de respuesta, Contención y evaluación, Legal y notificación, Supervisión de la dirección y Desescalado y cierre
• Una decisión '¿Verdadero positivo?' justo después del triaje, de modo que un falso positivo confirmado se reconduce al ajuste de la regla de detección en lugar de limitarse a cerrarse, y solo un evento real sigue subiendo la escala
• La primera decisión de escalado, '¿Alcanza el umbral S1/S2?', que divide la escala en dos: los eventos S3 y S4 se quedan con el SOC, reciben un ticket y se resuelven sin llegar nunca al gestor de incidentes
• Una segunda decisión dentro de la rama escalada, '¿La severidad es S1?', que determina si el gestor de incidentes y el propietario del sistema manejan solos un evento S2, o si se incorpora al CISO y se activa el equipo de crisis para un S1
• La decisión '¿Hay datos personales afectados?' en el carril Legal / privacidad, cuya rama Sí traspasa el incidente a un proceso dedicado de brechas de datos en lugar de duplicar esa evaluación en este diagrama
• Una decisión '¿Se requiere notificación externa?' que alimenta la notificación a la autoridad de control, las fuerzas de seguridad, los clientes y la aseguradora donde cada una aplica, seguida de una cadencia de actualizaciones a la dirección regida por '¿Está contenido el incidente?', que se repite en bucle hasta que el equipo de crisis puede desactivarse

Cuándo usar esta plantilla

• Estás escribiendo o actualizando un plan de respuesta a incidentes y la vía de escalado está descrita en texto corrido que nadie puede seguir a las dos de la madrugada
• Vuestro SOC y vuestra dirección no se ponen de acuerdo sobre cuándo hay que despertar al CISO, y necesitáis dejar el umbral por escrito en lugar de discutirlo caso por caso
• Estáis construyendo un runbook de incidentes graves o de comunicación de crisis y necesitáis que el punto en el que entran en juego legal y la notificación externa quede explícito
• Un auditor, una aseguradora o un comité del consejo ha preguntado cómo escala y reporta vuestra organización un incidente de seguridad, aparte de cómo se contiene técnicamente
• Estáis incorporando a un nuevo gestor de incidentes o CISO y queréis los niveles, los traspasos y la decisión de desactivación en una sola página, en lugar de aprendidos del último incidente

Cómo funciona

1. Renombra los carriles con vuestra cadena de escalado real

   Sustituye Analista del SOC, Gestor de incidentes, CISO / dirección de seguridad, Legal / privacidad y Dirección / equipo de crisis por los roles que de verdad tienen cada decisión en vuestra organización. Una organización más pequeña suele fundir al gestor de incidentes con el carril del CISO, o enruta legal a través de un despacho externo; borra o fusiona un carril en lugar de dejarlo sin dueño.

2. Escribe vuestros criterios de severidad en la primera decisión

   Abre '¿Alcanza el umbral S1/S2?' y sustituye el marcador de posición por vuestras propias definiciones: sistemas o datos afectados, número de usuarios o clientes, si la producción está degradada, si hay algún impacto en la seguridad de las personas. Las etiquetas S1 a S4 de este diagrama son ilustrativas, no un estándar, así que haz que los criterios sean lo bastante concretos para que dos analistas en turnos distintos lleguen a la misma conclusión.

3. Nombra quién puede declarar cada nivel

   Indica en el diagrama, o en el plan enlazado, quién puede confirmar un S2 sin despertar a nadie más, y quién puede declarar un S1 y disparar la activación del equipo de crisis. Añade un suplente para ambos roles y una regla para lo que ocurre si no se localiza a ninguno de los dos dentro de un tiempo acordado, porque unos criterios de escalado que solo una persona puede aprobar fallan justo cuando más se necesitan.

4. Confirma vuestros disparadores de datos personales y notificación

   Trabaja con legal o con vuestro responsable de protección de datos para escribir la prueba real detrás de '¿Hay datos personales afectados?' y '¿Se requiere notificación externa?': qué cuenta como datos personales para vosotros, qué autoridades de control, clientes, cuerpos de seguridad y aseguradoras podrían necesitar aviso, y cuáles son los plazos legales o contractuales en vuestra jurisdicción. Apunta la rama de datos personales a vuestro procedimiento real de brechas en lugar de dejarla como una simple etiqueta.

5. Fija la cadencia de actualizaciones a la dirección

   Decide con qué frecuencia envía el equipo de crisis una actualización de estado mientras '¿Está contenido el incidente?' se sigue respondiendo que no, quién la recibe y qué debe contener: impacto actual, medidas tomadas y el próximo punto de decisión. Deja la cadencia por escrito antes de que ocurra un incidente; decidirla sobre la marcha es la forma en que las actualizaciones dejan de enviarse o acaban acaparando la respuesta.

6. Define qué significan contenido y cerrado

   Acordad las evidencias necesarias para responder que sí a '¿Está contenido el incidente?', y por separado qué tiene que cumplirse antes de que el equipo de crisis se desactive y el incidente se cierre. Los dos momentos no coinciden: un incidente puede estar técnicamente contenido mucho antes de que comunicación, legal y los propietarios de negocio afectados estén listos para dejar de tratarlo como activo.

7. Recórrelo contra un incidente pasado

   Coge un incidente que hayáis gestionado de verdad, idealmente uno que llegara al CISO o más allá, y síguelo a través del diagrama. Anota cada punto en el que el escalado real fue más rápido, más lento o siguió una vía distinta a la que muestra el diagrama, y usa esas diferencias como agenda para actualizar el plan antes del próximo incidente, no durante él.

Preguntas frecuentes

¿Cuáles son los pasos de un proceso de escalado de incidentes de seguridad?

Un analista del SOC ejecuta el triaje de nivel 1 sobre la alerta y confirma que es un verdadero positivo; un falso positivo se cierra y se devuelve a la regla de detección. El evento confirmado se contrasta con el umbral S1/S2: S3 y S4 se quedan con el SOC, reciben un ticket y se resuelven ahí. Un evento S1 o S2 pasa al gestor de incidentes, que comprueba si es específicamente S1. Un S2 lo maneja el gestor de incidentes junto con el propietario del sistema. Un S1 se escala al CISO, que dirige la contención mientras se activa el equipo de crisis. Legal comprueba entonces si hay datos personales afectados, traspasando a un proceso de brechas cuando los hay, y decide si hay que notificar a la autoridad de control, a las fuerzas de seguridad, a los clientes o a la aseguradora. El equipo de crisis envía actualizaciones con una cadencia fija hasta que el incidente está contenido, y entonces se desactiva y lo cierra con un informe posincidente.

¿En qué se diferencia esto de un proceso de respuesta a incidentes de ciberseguridad?

Responden a preguntas distintas sobre el mismo evento. Un proceso de respuesta a incidentes de ciberseguridad es el ciclo técnico: triar la alerta, acotar su alcance, contenerla sin destruir evidencias, erradicar la amenaza, verificar que ha desaparecido y recuperar, normalmente ejecutado por completo dentro del SOC y operaciones de TI. Este proceso de escalado trata de personas y autoridad en lugar de técnica: en qué punto un evento deja de ser una decisión solo del SOC, a quién se avisa mientras sube, y quién tiene que aprobar que vuelva a bajar. En un S1 en curso, los dos corren en paralelo, con el equipo técnico trabajando los pasos de contención y erradicación mientras esta escala decide quién más está en la sala y qué se comunica hacia fuera.

¿Por qué '¿Hay datos personales afectados?' traspasa a otro proceso?

Porque la evaluación detrás de esa decisión tiene sus propias pruebas y su propio reloj regulatorio, que merecen un diagrama propio en lugar de comprimirse en una sola casilla aquí. Si una brecha es notificable a una autoridad de control, y por separado si hay que avisar a las propias personas afectadas, son preguntas con umbrales distintos y propietarios distintos, normalmente el responsable de protección de datos y legal. Mantener esa evaluación en un proceso dedicado de brechas de datos significa que puede ser detallado y mantenerse al día con las normas de vuestra jurisdicción sin que cada cambio tenga que volver a revisarse también contra la escala de escalado. Este diagrama solo necesita saber que el traspaso ocurrió y que el caso se está siguiendo.

¿Cuál es la diferencia entre severidad y nivel de escalado?

La severidad describe el impacto del propio incidente: cuánto está afectado, con qué gravedad y para cuánta gente. El nivel de escalado describe quién es responsable de él en cada momento y a quién se ha avisado. Los dos están relacionados pero no son idénticos, por lo que este diagrama los trata como decisiones separadas en lugar de una sola. Un incidente puede confirmarse como S1 en severidad en el mismo momento en que se entiende, pero el escalado solo llega al carril del CISO y el equipo de crisis cuando esa severidad se ha declarado y transmitido realmente hacia arriba; a la inversa, un incidente que parecía menor en el primer triaje puede subir esa misma escala más tarde si llegan evidencias del tipo 'el impacto cambió en la siguiente actualización', sin que su etiqueta de severidad original se revise nunca.

¿Quién decide cuándo desactivar el equipo de crisis?

Quien lo convocó, partiendo de evidencias y no de la presión por pasar página. Este diagrama coloca deliberadamente '¿Está contenido el incidente?' en el carril Dirección / equipo de crisis: la contención en sentido técnico la confirman los equipos de seguridad y de TI que trabajan el incidente, pero replegar la estructura de crisis, detener la cadencia de actualizaciones y decir al resto de la organización que el evento ha terminado es una decisión aparte que corresponde a quien es dueño de la respuesta a la crisis. Dejad por escrito de antemano los criterios de salida, por ejemplo un periodo de observación definido sin repetición y todos los sistemas afectados verificados, para que la decisión no se tome solo en función de lo cansada que esté la sala.