Automated Root Cause Analysis of Security Incidents Using Causal Machine Learning

Quando um sistema de segurança dispara um alarme, o desafio imediato não é simplesmente notar que algo está errado, mas entender exatamente onde o problema começou. Redes modernas geram um fluxo constante de dados: quem fez login, quais programas foram executados, quais arquivos foram abertos e como as permissões mudaram. Frequentemente, um único pequeno erro no início de uma reação em cadeia pode desencadear uma cascata de eventos estranhos que parecem igualmente suspeitos. Se um investigador olhar apenas para o sinal mais alto ou mais incomum, ele pode confundir um sintoma com a causa, perseguindo um efeito secundário enquanto o problema real permanece oculto a montante. Para resolver isso, pesquisadores estão recorrendo a uma forma de pensar chamada raciocínio causal. Em vez de apenas perguntar quais eventos acontecem juntos, essa abordagem pergunta quais eventos realmente fazem outros eventos acontecerem. Ela trata o sistema como um conjunto de engrenagens conectadas: se uma engrenagem gira, ela empurra a próxima, que empurra a próxima. O objetivo é encontrar a primeira engrenagem que foi tocada, em vez de apenas aquela que girou mais rápido.

Uma pesquisadora chamada Rehana Devani testou um método específico para encontrar essa primeira engrenagem em um ambiente simulado controlado. O estudo não analisa tentativas de hacking do mundo real ou redes corporativas vivas. Em vez disso, constrói um modelo digital de um sistema de segurança com seis partes distintas, representando coisas como acesso, política e execução. Neste modelo, os pesquisadores sabem exatamente como as partes estão conectadas e como elas influenciam umas às outras. Eles então introduzem uma perturbação específica e artificial — um deslocamento súbito de quatro unidades no comportamento de uma das partes iniciais — e observam como a ondulação se espalha pelo restante do sistema. O experimento faz uma pergunta simples, mas difícil: se você vir todo o sistema agindo de forma estranha, um programa de computador consegue identificar corretamente qual parte inicial única foi a que foi alterada, ou será que ele será distraído pelo ruído das partes que reagiram à mudança?

Os pesquisadores compararam duas maneiras de analisar os dados. O primeiro método, que eles chamam de pontuação marginal (marginal scoring), é como olhar para cada parte isoladamente e perguntar: "O quão incomum é esta parte em comparação ao normal?". Essa abordagem frequentemente falha porque uma parte que está meramente reagindo a um problema pode parecer tão estranha quanto a parte que o causou. O segundo método, conhecido como pontuação residual (residual scoring), é mais sofisticado. Ele utiliza um mapa das conexões para perguntar: "Dado o que as partes que alimentam esta estão fazendo, esta parte está se comportando de forma estranha?". Se uma parte está agindo de forma estranha apenas porque seus vizinhos estão agindo de forma estranha, este método reconhece que a parte em si não é a fonte. No entanto, se a parte está agindo de forma estranha mesmo quando seus vizores estão se comportando normalmente, ela é sinalizada como a provável culpada.

Na versão mais limpa do experimento, onde os dados eram perfeitamente claros e livres de qualquer ruído de fundo, o método sofisticado funcionou de forma notável. Ele identificou corretamente o ponto de partida da perturbação em quase 98 por cento dos casos. O método mais simples, que ignorava as conexões entre as partes, estava correto apenas cerca de 87 por cento das vezes. Essa lacuna mostra que entender a estrutura do sistema ajuda a separar a verdadeira causa dos sintomas. No entanto, o estudo também testou como esse método se sustenta quando os dados são desordenados, que é como os sistemas do mundo real costcnamente se comportam. Os pesquisadores adicionaram estática aleatória, ou ruído de sensor, às medições para simular a coleta de dados imperfeita. À medida que o ruído aumentava, a precisão do método sofisticado caía, chegando a cerca de 81 por cento quando o nível de ruído era moderado. O método mais simples teve dificuldades ainda maiores, caindo para aproximadamente 62 por cento. Este resultado confirma que, embora conhecer as conexões ajude, a qualidade dos dados é tão crítica quanto. Se as medições forem muito nebulosas, nem o melhor mapa pode guiar o investigador para a resposta certa.

O estudo também explorou o que acontece se o próprio mapa estiver ligeiramente errado. Em um teste, os pesquisadores deliberadamente removeram uma conexão conhecida do modelo, fingindo que não sabiam que uma parte influenciava outra. O método ainda teve um bom desempenho, identificando corretamente a causa cerca de 94 por cento das vezes nos dados limpos, mas a precisão caiu conforme o ruído aumentava. Isso sugere que a abordagem é um tanto tolerante à falta de informação, mas não é perfeita. Os pesquisadores também verificaram se encontrar a causa certa ajudaria de fato a resolver o problema. Eles simularam um reparo revertendo a mudança que injetaram no sistema. Quando visaram o ponto de partida correto, o comportamento estranho no sistema desapareceu quase inteiramente. Quando visaram o ponto errado, o sistema permaneceu perturbado. Isso confirmou que o método não está apenas adivinhando; ele está identificando a alavanca específica que, se puxada de volta, interromperia a reação em cadeia.

Apesar desses resultados promissores, o artigo é cuidadoso ao declarar o que não fez. Todo o experimento ocorreu dentro de uma simulação de computador com um modelo minúsculo de seis partes. Os pesquisadores não testaram isso em redes corporativas reais, hackers reais ou logs de segurança reais. Eles não alegaram que seu método pode descobrir novos tipos de ataques ou que funciona sem um mapa pré-definido do sistema. O estudo prova que, se você já sabe como um sistema está conectado, pode usar um tipo específico de cálculo para encontrar um problema injetado de forma mais precisa do que apenas procurando pelos números mais estranhos. Não prova que isso funcionará na realidade caótica, ruidosa e complexa de uma empresa viva. O valor do trabalho reside em sua clareza: ele separa a ideia de encontrar uma causa da ideia de descobrir o mapa, e mostra exatamente o quanto a qualidade dos dados importa. Antes que este método possa ser usado para proteger organizações reais, ele deve ser testado em ambientes onde as conexões não são conhecidas de antemão e os dados não são perfeitamente limpos. Por enquanto, ele permanece como uma demonstração precisa e reproduzível de como o raciocínio causal pode melhorar a busca pela origem de um incidente de segurança, desde que as regras do jogo sejam claramente compreendidas.