.svg)
.svg)
Cybersecurity suffers greatly from noise fatigue. The immediate reaction is to call for a reduction in the false positive rate. You hear people banging the drum about it all the time. It’s obvious - we have too many false alerts, so we just reduce the number of false positives. How hard can it be!
The reaction is completely understandable. Alert fatigue, wading into yet another massive report of vulnerabilities that each need to be verified, can waste considerable time and resources. Security teams are often spending too much time on looking into the false alerts, and not enough time actually prioritizing and mitigating the risks that matter.
Part of the problem is the lack of understanding of what reducing the false positives actually means in AI/ ML. Without a clear understanding of the way false positives are calibrated and understood, in the overall context of accuracy, it’s impossible to really understand what’s going on behind the scenes.
Let’s take some examples. Here we have a typical attack distribution, with the attacker data points in red, and the normal behaviour in blue. This could be a typical pattern, for example in an account take-over attack as shown in the figures below.
The Machine Learning attempts to interpret the data, and establish clear cut off lines that are separating the attacks from the normal traffic.
For example below, we can see we do have fairly clear distribution.
On the left is all the normal distribution, on the right the attack data. However, there is one pesky blue data point, completely circled by the red attack data. Looking at the blue team data, we’ve also got four red data points co-mingled and two right on the line. If we follow the distribution line and have a cut off where the line is drawn, of course we have a problem with the outliers on both sides of the cut-off line.
On the left we have attackers that we are proposing to label as legitimate. This is a much more serious problem than the legitimate blue user who has falsely been flagged as a potential attacker. In order to fully understand the machine learning parameters, it's important to understand the full consequences of the data distribution, and this is done through the confusion matrix as described below.
The Confusion Matrix in Cybersecurity AI
True Positive: No attack occurs The model predicts no attack. 100% Correct.
True Negative: An attack occurs. The model predicts an attack as well. 100% correct.
False Positive: No attack occurs. The model says it did and falsely labels normal data as attack data.
False Negative: An attack occurs. The model says it didn't occur and completely mislabels attacks as legitimate users.
Now let’s look at the data. We are showing a simple confusion matrix of all the options here for the account take over attack showing what actually happened versus what the model predicted.
These results from the confusion matrix show that the model is largely correct.
True Positive: No attack occurs The model predicts no attack. 19,734 results are correctly labelled.
True Negative: An attack occurs. The model predicts an attack as well. 20,234 results are correctly labelled.
False Positive: No attack occurs. The model says it did and falsely labels 523 legitimate users as attacks.
False Negative: An attack occurs. The model says it didn't occur and completely mislabels 8 attackers as legitimate users.
False Negatives are the real problem
Given both false outcomes, which is worse?
The False positives grab all the headlines, but at least we err on the side of caution. More annoying than fatal.
The small number of false negatives, (8) is the major cause of major concern.
In this case our system says all is normal, but really we’ve missed an attack. That’s a real problem.
Typically, the data science team then goes to work on the reasons for the mis-labeling of the dataset, and seeks to improve the model fit.
What it wants to do is to eliminate the False Negatives here - if our model is mislabelling attacks as normal behaviour, and continues to do so, it’s effectively allowing attackers free reign, and the model will be reinforced over time with the mislabeled data. The relatively high number of false positives isn’t such a concern for the model. Yes, it can be frustrating, but these are legitimate users who may be inconvenienced with false alerts. Yes, it can result in too many false alerts, but you aren’t letting the attackers through. So now we know why there tends to be lots of alert fatigue and models quite often produce false positives.
The Dangers of Overfitting
Let’s look now as the data science team attempts to refine the model and improve the overall performance. They go away and work on the data set and have come up with a perfect score.
Exactly what everyone wants, no false positives or false negatives.
Although the goal is high accuracy, we don’t want to see a perfect score. Typically this means the model is over-fitted to the dataset, or even that it’s using its own training dataset and marking its own homework. Whenever we see this result, it's usually a rookie mistake. The developer is briefly ecstatic, everyone else just groans, and we try again.
No two attacks are usually the same, our model needs to be flexible and generalized.
We also don’t necessarily want to see a super low false-positive rate. If we misclassify less attacks, we may be making it easier for the model to actually miss the real attacks altogether.
Let’s go back to our blue / red attack distribution. This time we are more accurate with our model. We've got all the attackers correctly labelled. Don’t forget the data science team is dealing with its own data set here. Very few cybersecurity teams are building their own ML models from scratch using their own data.
There is one pesky blue normal event that is misclassified and represents an outlier, but at least the attack data is correctly picked up. However, the model looks like it’s again overfitting. It’s too closely aligned to each of the attack data points, and is highly unlikely to work as a generalised attack model for a variety of different data sets..
How does VerifiedThreat alleviate the false positives?
Ultimately, the quest for a perfect, zero-noise cybersecurity model is a siren song that leads to dangerous oversights. While the instinct to eliminate false positives to alleviate alert fatigue is understandable, it is a critical error to treat this as a simple tuning exercise. Aggressively silencing false positives often inadvertently widens the door for false negatives—allowing genuine, high-impact attacks to slip through undetected.
So how does VerifiedThreat alleviate false positives? Instead of building generalized models, we concentrate on the attack vectors that attackers typically use to search for vulnerabilities as well as the tools and methods used to penetrate the defences.
We provide the evidential proof of the attack method along with the actual code so that it can be reproduced. You can see in the example below we are looking at detecting weak defences from account take over (ATO). Each stage of the simulated red team attack is shown, along with the time stamp of the simulation so that it can be checked in the logs, and the actual code, so that it can be re-produced.
Effective security demands a hybrid approach: one where intelligent, scalable AI handles the heavy lifting of detection, while human expertise provides the essential business context, validation, and oversight. By prioritizing actionable risk, as shown above over mere volume and embracing continuous, intelligent validation, organizations can stop chasing "perfection" and instead start building the resilient, proactive defense that the latest AI threats demand.
.webp)
_11zon.webp)
.svg)
.svg)