Hello Azure security community! Today’s blog post on anomaly detection systems is brought to you by Ram Shankar Siva Kumar from Azure Security Data Science, in collaboration with Andrew Wicker, Dan Mace and Kaidi Zhao.
The CISO of one of the premier National Labs in the country, said he is going to level with us: The lab invested millions of dollars on a bespoke security anomaly detection system that was built ground up, by their cream of the crop data scientists and sadly, the system did not yield any useful alerts. The false positive rates were just too high and for all intents and purposes, the security analyst team was being sent on a goose chase. The CISO and his team wanted to know how Azure Security Data Science, my team, would handle the alert deluge and what can we tell them from our experience, to help them whittle down the false positive rate, so that they can focus on catching attacks.
As a Data Cowboy in Microsoft’s cloud Security data science team, the stories I hear on anomaly detection systems from customers follow a particular pattern: an organization invests in SIEM, and then hires data scientists to build advanced detections from the gathered data only to find that the team of security analysts are unhappy with the results. There is more than disgruntled analysts at stake: a recent study by the Ponemon Institute, showed that organizations spend, on average, nearly 21,000 hours each year analyzing security false positives, wasting roughly $1.3 million per year due to inaccurate or erroneous intelligence. The immediate reaction is to invest in a newer, more complex algorithm that can reduce the false positive rate and surface better anomalies which threat analysts might not agree with.
This blog post has three takeaways:
- The end goal of security anomaly detection systems should not be to produce anomalies but actionable security alerts, that are useful i.e. interpretable, credible and elicit downstream action
- Increasing the complexity of the algorithm without actually instilling security domain knowledge has little effect on false positive rates
- A framework to show how to go from noisy outliers to the end goal of security, so that you can make an honest assessment of your anomaly detection system to see where you fit in.
Before we build an anomaly detection system, we enforce the following constraints to consider the result to be “useful”
- Interpretable: Every security risk we alert or report on must be explainable. For instance, it is not sufficient to say a process running on the host is anomalous. Instead, the detection system should alert that it has detected PowerShell.exe running in the App folder.
- Credible: The analyst must trust in the result, when he receives additional contextual information the alert. Continuing the anomalous process creation example, the IT admin may receive the command line arguments that were passed when PowerShell was invoked.
- Actionable: When results are interpretable and credible, they are more likely to lead to downstream action. Depending on the severity of the incident, this could be anything from rolling the credentials to getting forensics artifacts from the host machine.
Now using “Usefulness” as a dimension of comparison, our experience with anomaly detection systems can be summarized as follows:
- Blindly increasing the complexity of the system, without much security domain knowledge, does not increase the utility of the end results
- The biggest game changer happens, when we can get constant feedback from the security experts which in turn helps the data scientists to refine their behavioral detection at each step.
The following table shows how based on the complexity of the behavioral anomaly detection system and the amount of security knowledge that is instilled, we can have three different types of security alerts i.e. outliers, anomalies and “security interesting”. We chose to illustrate the table with a case of detecting suspicious activity based on login failure records alone. In practice, this could be done by monitoring the 4625 event id in the Windows Security Event Logs.
- Use the framework listed above to identify if your alerts are outliers, anomalies or security interesting. You can then use the grid to evolve your results to the end goal of actionable, credible and interpretable results.
- So what does an algorithm that generates useful security alerts look like, and how does one go about building such an algorithm? Stay tuned for additional blog posts delving into these topics.