Automated Root Cause Analysis of Security Incidents Using Causal Machine Learning

Cuando un sistema de seguridad hace sonar una alarma, el desafío inmediato no es simplemente notar que algo anda mal, sino comprender exactamente dónde comenzó el problema. Las redes modernas generan un flujo constante de datos: quién inició sesión, qué programas se ejecutaron, qué archivos se abrieron y cómo cambiaron los permisos. A menudo, un pequeño error al inicio de una reacción en cadena puede desencadenar una cascada de eventos extraños que parecen igualmente sospechosos. Si un investigador observa únicamente la señal más fuerte o inusual, podría confundir un síntoma con la causa, persiguiendo un efecto derivado mientras el problema real permanece oculto río arriba. Para resolver esto, los investigadores están recurriendo a una forma de pensar llamada razonamiento causal. En lugar de solo preguntar qué eventos ocurren al mismo tiempo, este enfoque pregunta qué eventos hacen que otros eventos ocurran realmente. Trata al sistema como un conjunto de engranajes conectados: si un engranaje gira, empuja al siguiente, el cual empuja al siguiente. El objetivo es encontrar el primer engranaje que fue movido, en lugar de solo aquel que giró más rápido.

Una investigadora llamada Rehana Devani ha probado un método específico para encontrar ese primer engranaje en un entorno simulado controlado. El estudio no analiza intentos de hackeo del mundo real o redes corporativas vivas. En su lugar, construye un modelo digital de un sistema de seguridad con seis partes distintas, que representan cosas como el acceso, la política y la ejecución. En este modelo, los investigadores saben exactamente cómo están conectadas las partes y cómo se influyen entre sí. Luego introducen una perturbación específica y artificial —un cambio repentino de cuatro unidades en el comportamiento de una de las partes iniciales— y observan cómo la onda expansiva se propaga a través del resto del sistema. El experimento plantea una pregunta simple pero difícil: si ves que todo el sistema actúa de forma extraña, ¿puede un programa informático identificar correctamente cuál de las partes iniciales fue la que cambió, o se distraerá con el ruido de las partes que reaccionaron al cambio?

Los investigadores compararon dos formas de observar los datos. El primer método, que llaman puntuación marginal, es como observar cada parte de forma aislada y preguntar: "¿Qué tan inusual es esta parte en comparación con lo normal?". Este enfoque a menudo falla porque una parte que simplemente está reaccionando a un problema puede parecer tan extraña como la parte que lo causó. El segundo método, conocido como puntuación residual, es más sofisticado. Utiliza un mapa de las conexiones para preguntar: "Dado lo que las partes que alimentan a esta están haciendo, ¿se está comportando esta parte de forma extraña?". Si una parte actúa de forma extraña solo porque sus vecinas están actuando de forma extraña, este método reconoce que la parte en sí no es la fuente. Sin embargo, si una parte actúa de forma extraña incluso cuando sus vecinas se comportan normalmente, se marca como el probable culpable.

En la versión más limpia del experimento, donde los datos eran perfectamente claros y libres de cualquier ruido de fondo, el método sofisticado funcionó notablemente bien. Identificó correctamente el punto de partida de la perturbación en casi el 98 por ciento de los casos. El método más simple, que ignoraba las conexiones entre las partes, fue correcto solo alrededor del 87 por ciento de las veces. Esta brecha muestra que comprender la estructura del sistema ayuda a separar la causa verdadera de los síntomas. Sin embargo, el estudio también probó cómo se mantiene este método cuando los datos son desordenados, que es como suelen comportarse los sistemas del mundo real. Los investigadores añadieron estática aleatoria, o ruido de sensor, a las mediciones para simular una recolección de datos imperfecta. A medida que el ruido aumentaba, la precisión del método sofisticado caía, descendiendo a aproximadamente el 81 por ciento cuando el nivel de ruido era moderado. El método más simple tuvo dificultades aún mayores, cayendo a aproximadamente el 62 por ciento. Este resultado confirma que, si bien conocer las conexiones ayuda, la calidad de los datos es igual de crítica. Si las mediciones son demasiado difusas, ni siquiera el mejor mapa puede guiar al investigador hacia la respuesta correcta.

El estudio también exploró qué sucede si el mapa mismo es ligeramente erróneo. En una prueba, los investigadores eliminaron deliberadamente una conexión conocida del modelo, pretendiendo que no sabían que una parte influía en otra. El método siguió funcionando bien, identificando correctamente la causa aproximadamente el 94 por ciento de las veces en los datos limpios, pero la precisión disminuyó a medida que el ruido aumentaba. Esto sugiere que el enfoque es algo tolerante a la información faltante, pero no es perfecto. Los investigadores también comprobaron si encontrar la causa correcta ayudaría realmente a solucionar el problema. Simularon una reparación revirtiendo el cambio que habían inyectado en el sistema. Cuando se dirigieron al punto de partida correcto, el comportamiento extraño en el sistema desapareció casi por completo. Cuando se dirigieron al punto incorrecto, el sistema permaneció perturbado. Esto confirmó que el método no es una mera suposición; está identificando la palanca específica que, si se acciona hacia atrás, detendría la reacción en cadena.

A pesar de estos resultados prometedores, el artículo es cuidadoso al declarar lo que no ha hecho. Todo el experimento tuvo lugar dentro de una simulación informática con un modelo diminuto de seis partes. Los investigadores no probaron esto en redes corporativas reales, hackers reales o registros de seguridad reales. No afirmaron que su método pueda descubrir nuevos tipos de ataques o que funcione sin un mapa predefinido del sistema. El estudio demuestra que, si ya sabes cómo está conectado un sistema, puedes usar un tipo específico de cálculo para encontrar un problema inyectado de manera más precisa que simplemente buscando los números más extraños. No demuestra que esto vaya a funcionar en la realidad caótica, ruidosa y compleja de una empresa activa. El valor del trabajo reside en su claridad: separa la idea de encontrar una causa de la idea de descubrir el mapa, y muestra exactamente cuánto importa la calidad de los datos. Antes de que este método pueda ser utilizado para proteger a organizaciones reales, debe ser probado en entornos donde las conexiones no se conocen de antemano y los datos no son perfectamente limpios. Por ahora, constituye una demostración precisa y reproducible de cómo el razonamiento causal puede mejorar la búsqueda de la fuente de un incidente de seguridad, siempre que las reglas del juego estén claramente entendidas.