Everyone knows you need to block the bad stuff from getting onto your network and calling home to its masters. However, what happens when something good gets incorrectly flagged as malicious? You’ve been hit with a false positive, and in some cases, this can be just as bad as letting something truly dangerous get through.

False positives can result in lost traffic and revenue for the wrongfully accused, wasting time and resources for those investigating and resolving the issue. When false positives become a recurring problem, you start to lose trust. Is this IP really good? Is that IP really bad? Resulting in either over investigation or a lapse in standards.

False positives can cause potentially fatal breaks in service. An extreme example (that has happened without any fatalities) is a hospital using a SAAS paging service. This paging service was hosted on an IP that was simultaneously hosting multiple phishing sites. With this, the pager service didn’t work until they added that IP to their custom whitelist.

 

False positives can happen in a number of ways.

The most common source of false positives is human error. Analysts at threat intelligence providers tend to have a bias towards blocking, as threat removal is often difficult.

Faulty algorithms are an additional source of false positives. Many companies use machine learning and data mining to find malicious addresses that are not always 100% accurate.

A common example of both cases is when malicious content is served from one URL (or a couple), and onto an IP address that hosts thousands of domains. The innocent sites get caught up in being part of a bad neighborhood.

In this example, it’s not so much a false positive as not having the correct level of granularity to deal with multi-hosts. Basically, any critical service that’s connected through a shared public IP has the potential of being blocked in a false positive.

Another frequent false positive is when companies self-list through misconfiguring auto-protection services, such as DenyHosts. If DenyHosts are misconfigured not to exclude reporting of their own IP addresses (especially their system monitoring servers), an organization’s own DenyHosts can send their IP addresses to the shared database, locking themselves out.

IPs can change ownership or domains can change. Because of this, false positives often occur if the IP or domain was previously serving up malicious traffic, has been since cleaned up, but not aged off the intelligence source in question. Since the majority of reputational services use manual delisting, their advertised large lists are likely to contain many false positives Another cause is selecting policies that block either too wide in scope or entire geographies as a whole.

To some, false positives have become an acceptable consequence of having “good” security. For others, the denial of service risk is too high. Companies will either use threat intelligence in only a forensic manner, or use very limited policies that let a lot of known bad traffic through. Therefore, they rely on other tools that may or may not catch the malware. (Especially if it is new, targeted, or polymorphic) The good news is that these don’t have to be the only choices. In addition to threat intelligence you can trust, customizable policies set to fit your unique needs are key to having a successful reputational based security platform.

While ThreatSTOP cannot claim that we have never had a false positive, our service includes full customization for users, including immediate whitelisting of domains and IP addresses through the Web UI. So, if a user finds a false positive, they can instantly remediate it. Users can include custom lists of trusted partners or sites they want to block for their own reasons, with the ability to update them manually or automatically.

Until May of this year, ThreatSTOP was the provider of Infoblox’ DNS firewall subscription service. (Infoblox calls this the “Legacy DNS Firewall Subscription”) As a result, in cases where users complained of false positives, Infoblox support contacted ThreatSTOP to address the issue. Recently, we were contacted regarding the blocking of army.mil, which we were not blocking. It turned out that a customer using Infoblox’s ActiveTrust found that army.mil, the U.S. Army’s website, was incorrectly on their block list. Needless to say, this was a problem for the customer.

Because Infoblox doesn’t offer custom lists as part of their current DNS Firewall subscription service, the problem could not be resolved until the customer went through a lengthy escalation process.

 

This didn’t have to happen.

This customer could have kept the curated, real-time threat intelligence and customization capabilities with ThreatSTOP’s DNS Firewall Service instead of switching to the ActiveTrust. If you’re an Infoblox customer who bought the “Legacy DNS Firewall Subscription” and received a notification about migrating to ActiveTrust, you have a choice. You can keep the ThreatSTOP intelligence you have been using and know you can trust, with the additional features available in our Next Generation DNS Firewall product. These features include full customization from over 40 different sources of data, your own User Defined Lists, powerful research tools, fully graphical reporting and alerting at no additional cost.

Contrary to the notice you have received, the infrastructure you are connecting to is not going away. ThreatSTOP continues to maintain and enhance the service you already have. ThreatSTOP will honor your existing subscription through its current termination date, with the option of extending our terms of service for as long as you want.

 

Ready to try ThreatSTOP in your network? Want an expert-led demo to see how it works?