False Positives: What They Are, How to Identify Them and Why They Need to be Addressed

What is a False Positive? 

In security information and event management (SIEM) we rely on software to help identify patterns which indicate security threats. A series of failed login attempts, for example, will generate a ticket alerting a Security Operations Center (SOC) analyst that someone may be trying to hack into the system. (Note that SIEM solutions are increasingly being incorporated into overall Extended Detection and Response (XDR) solutions.  

With any monitoring solution, one of the biggest challenges is the dreaded false positive. A false positive is any alert triggered by a rule that’s written too broadly, causing it to issue a ticket over an event that’s not a legitimate security threat. A false positive is the equivalent of a home motion-sensor alarm that goes off every time the wind blows through the backyard trees. Before long, the homeowner ignores the alarms, leaving them off-guard when it really IS a burglar setting off the alarm. 

For IT teams that don’t have an in-house SOC or a managed service supporting them, the daily stream of false positives from a SIEM leads to alert fatigue, which produces frustration and growing inattention to alerts in general. One major IT survey found that 44% of alerts go uninvestigated. 

Clearly, narrowing the focus to real threats raises an IT team’s chances of spotting problems and fixing them. 

How We Identify False Positives 

Discovering false positives using SIEM can be a lot like playing the game Guess Who. The player’s objective is to guess the Mystery Person on the opponent’s card by asking one question per turn (Such as, “Are they a man?”) and eliminating any gameboard faces that don’t fit the Mystery Person’s description. In a SIEM setting, we are working to eliminate false positives so that the only alerts we see represent actual threats. 

Players usually start with generic questions, but broadstroke guesses still leave us with a board full of faces. On the other hand, asking questions that are too specific takes a long time to narrow down the options. In SIEM, if we write rules that are too generic, we’ll face numerous false positives that only cause clutter and confusion. If we write rules that are too specific, we may miss critical incidents that leave our systems vulnerable. The key is to make educated decisions based on the data (or gameboard faces) in front of us. We start with a wide data set and use logic to narrow the results. 

Continuing with our Guess Who analogy, let’s say we’ve narrowed the field to two options. Our final choices look very similar: Both are male, Caucasian, and bald, and both have orange hair. But we know they aren’t the same. If a SIEM solution’s rule is searching for Bill using the criteria listed above, Herman represents a false positive. Herman and Bill meet all of the same “threat” criteria we’ve listed so far. The solution is finding a factor unique to Bill, such as a small nose. If we add this final condition to the original filter criteria, the false positive disappears. 

How Expert SOC Analysts Can Help 

When dealing with a SIEM solution, this shows the value of an experienced, well-trained security analyst. As good as machines are with calculations and patterns, they often need the human element to spot a real threat and a false positive. At HBS, we constantly upgrade the ruleset of our SIEM solution based on the expertise of our security analysts and consultants.  

Our security analysts examine event logs to identify pieces of information that the software wasn’t considering. For example, in a case of failed logons, an analyst would look in the raw log for the error code that gives the reason for the authentication failure. If the error code indicates that the password has expired, the analyst could typically conclude that it is not a serious security incident. By adding that insight to the existing rule, the analyst can eliminate future false positives from this kind of event. 

Why False Positives Must Be Addressed 

Although most false positives don’t pose an immediate security threat, any false positive can be a major distraction from threatening incidents. For example, a DNS configuration problem might constantly produce authentication issues on a network. It may be tempting to ignore an alert once you’ve decided it’s a false positive. But if you do that with several false positives you’ve learned to ignore, and several of them generate multiple alerts each day, you’ll soon get lost in daily noise that distracts you from legitimate security problems.  

Remember that it costs the same amount of money to license a poorly tuned SIEM system as a well-tuned one. It’s worth investing in a managed service that can help you get the most from the tool you’re paying for. 

If you need help monitoring your system’s activities efficiently and eliminating false positives, contact an expert today!