Fighting against False Positives

Since the inception of Apility.io the most recurrent question is ‘How can I fight against False Positives?‘ and I must admit there is not an easy way. But let’s start for the beginning. What the hell is a False Positive and why is it so important?

Apility.io was launched more than one year since and I’m not sure if this tool has been helpful (I would like to think so), but I’m quite sure there are a good amount of people using it on a daily basis. No matter if the API has been integrated into their apps and services, or used as a command line tool I can guarantee you I get frequent feedback about what they would like to see as new features in Apility.io and also how can I help them to deal with better blacklisting of the bad guys.

What is a False Positive?

For any user of Apility.io, a False Positive occurs when an IP address, domain or email is classified with a negative score and as result, it’s marked as ‘malicious’ or simply ‘bad’, but the resource is not ‘bad’ or at least is not ‘bad’ anymore.

I think the concept is easy to understand with the following examples: There is a list of IP address that belongs to very well known Cloud Services providers if this list is enabled then depending on the context some IP addresses could be marked as ‘malicious’. If a service wants to verify that an IP address is not a bot then including this list can be a bad idea because every single IP address hosted in any Cloud Service Provider will be marked as malicious. But if a user wants to verify that only desktop and mobile clients connect to the service then a connection from an IP address of this list looks very suspicious and as result enabling this list can be a good idea to reject bots mimicking real users. Same happens for a list of domains for Free Email service providers, or other lists that are simply informative.

List Sensitivity and Taxonomies

As I explained above there is not a single answer to this problem because every user has different needs and different thresholds. We want to help users to define the right level of accuracy of Apility.io and that’s why we now have two new properties: List Sensitivity and Taxonomies.

List Sensitivity is a new parameter that describes how any list that contains IP addresses, domains or emails can be more or less dangerous. A resource with a sensitivity closer to ‘1’ means that it is more dangerous than a sensitivity closer to ’10’ which normally means that the element is not very risky or for informative purposes only. As a rule of thumb, we recommend to start always with lists with ‘1’ sensitivity and include later on other lists.

So IPCATV4, the list that contains IP addresses from Cloud Providers has a sensitivity of level ’10’, which means it is an informative-type list and not risky in most contexts. But BOTSCOUT-LATEST has a sensitivity of ‘1’ because this list contains IP addresses from detected and verified Bots that can harm your customers or services.

The next property is Taxonomies. Now each list has a set of tags that can help users to find out which list can be better or not for a concrete purpose. If a user is only interested in lists with IP addresses of the anonymous network TOR, then she only needs to select the ‘TOR’ tag. Or if a user is only interested in crypto abuse lists he only needs to select the ‘crypto’ tag.

apilityio-blacklists-details

New Blacklist Advanced Search

Under the Blacklist menu, the users can find the page to select which lists are going to be looked up to determine if a resource is included in any of these lists or not.

apilityio-blacklists-overview

To select the right blacklists according to the requirements of the user there is an Advanced Search feature that let the user choose them according to sensitivity and taxonomies criteria combined. Clicking on Enable Advanced Search will show the different filters and then it will disable all the blacklists below. Clicking on Reload it will disable the advance search and will also reload the old values stored by the user.

apilityio-blacklists-advancedsearch

The user now should choose the right value for the sensitivity and the tags to include in the filter. Both can be combined to select the right blacklists. Once the blacklists have been selected the user has to click on Save to store the new blacklists in the database. The new filters will be applied immediately in all the different API servers.

Summary

By default, all lists are enabled after the registration process. We strongly recommend enabling only the lists needed to avoid False Positives. Don’t assume that the default lists are the best ones for you. Play with the search features, find out what lists are really valuable for your needs… and tell us how it worked!