Automated Root Cause Analysis of Security Incidents Using Causal Machine Learning

When a security system sounds an alarm, the immediate challenge is not simply noticing that something is wrong, but understanding exactly where the trouble began. Modern networks generate a constant stream of data: who logged in, what programs ran, which files were opened, and how permissions changed. Often, a single small mistake at the start of a chain reaction can trigger a cascade of strange events that look equally suspicious. If an investigator looks only at the loudest or most unusual signal, they might mistake a symptom for the cause, chasing a downstream effect while the real problem remains hidden upstream. To solve this, researchers are turning to a way of thinking called causal reasoning. Instead of just asking which events happen together, this approach asks which events actually make other events happen. It treats the system like a set of connected gears: if one gear turns, it pushes the next, which pushes the next. The goal is to find the first gear that was nudged, rather than just the one that spun the fastest.

A researcher named Rehana Devani has tested a specific method for finding that first gear in a controlled, simulated environment. The study does not analyze real-world hacking attempts or live corporate networks. Instead, it builds a digital model of a security system with six distinct parts, representing things like access, policy, and execution. In this model, the researchers know exactly how the parts are connected and how they influence one another. They then introduce a specific, artificial disturbance—a sudden, four-unit shift in the behavior of one of the starting parts—and watch how the ripple spreads through the rest of the system. The experiment asks a simple but difficult question: if you see the whole system acting strangely, can a computer program correctly identify which single starting part was the one that was changed, or will it get distracted by the noise of the parts that reacted to the change?

The researchers compared two ways of looking at the data. The first method, which they call marginal scoring, is like looking at each part in isolation and asking, "How unusual is this part compared to normal?" This approach often fails because a part that is merely reacting to a problem can look just as strange as the part that caused it. The second method, known as residual scoring, is more sophisticated. It uses a map of the connections to ask, "Given what the parts feeding into this one are doing, is this part behaving strangely?" If a part is acting oddly only because its neighbors are acting oddly, this method recognizes that the part itself is not the source. However, if the part is acting oddly even when its neighbors are behaving normally, it is flagged as the likely culprit.

In the cleanest version of the experiment, where the data was perfectly clear and free of any background noise, the sophisticated method worked remarkably well. It correctly identified the starting point of the disturbance in nearly 98 percent of the cases. The simpler method, which ignored the connections between parts, was correct only about 87 percent of the time. This gap shows that understanding the structure of the system helps separate the true cause from the symptoms. However, the study also tested how this method holds up when the data is messy, which is how real-world systems often behave. The researchers added random static, or sensor noise, to the measurements to simulate imperfect data collection. As the noise increased, the accuracy of the sophisticated method dropped, falling to about 81 percent when the noise level was moderate. The simpler method struggled even more, dropping to roughly 62 percent. This result confirms that while knowing the connections helps, the quality of the data is just as critical. If the measurements are too fuzzy, even the best map cannot guide the investigator to the right answer.

The study also explored what happens if the map itself is slightly wrong. In one test, the researchers deliberately removed a known connection from the model, pretending they did not know that one part influenced another. The method still performed well, correctly identifying the cause about 94 percent of the time in the clean data, but the accuracy dipped as the noise increased. This suggests that the approach is somewhat forgiving of missing information, but it is not perfect. The researchers also checked whether finding the right cause would actually help fix the problem. They simulated a repair by reversing the change they had injected into the system. When they targeted the correct starting point, the strange behavior in the system disappeared almost entirely. When they targeted the wrong point, the system remained disturbed. This confirmed that the method is not just guessing; it is identifying the specific lever that, if pulled back, would stop the chain reaction.

Despite these promising results, the paper is careful to state what it has not done. The entire experiment took place inside a computer simulation with a tiny, six-part model. The researchers did not test this on real corporate networks, real hackers, or real security logs. They did not claim that their method can discover new types of attacks or that it works without a pre-defined map of the system. The study proves that if you already know how a system is connected, you can use a specific type of calculation to find a single, injected problem more accurately than by just looking for the strangest numbers. It does not prove that this will work in the chaotic, noisy, and complex reality of a live enterprise. The value of the work lies in its clarity: it separates the idea of finding a cause from the idea of discovering the map, and it shows exactly how much the quality of the data matters. Before this method can be used to protect real organizations, it must be tested in environments where the connections are not known in advance and the data is not perfectly clean. For now, it stands as a precise, reproducible demonstration of how causal reasoning can improve the hunt for the source of a security incident, provided the ground rules are clearly understood.