Getting Real with False Positives
Before you start testing your antivirus software for triggering false positives, we need to describe where they’re important and whether or not they’re actually an issue. False positives are where your antivirus software convicts (determines) a file is malicious and you believe it isn’t. The grey area is where a file is arguably malicious, such as piece of advertising riddled freeware, but you trust it.
However, in a corporate environment with fairly mature IT controls, most of the software on a machine should be corporate in nature, and so it’s rare to see any deliberately installed greyware, such as games and downloaded admin tools. Contrast this with a home user who trusts they myriad of random applications they’ve installed from the Internet. Applications and services can have shades of grey in their maliciousness, and so an “acceptable” piece of software to one person may be “unacceptable” to another.
Some antivirus products are more corporate in their nature and so have a more aggressive conviction rate, e.g. greyware applications have a higher chance of being detected as malicious. Other antivirus products are more home-user friendly and are less stringent in their blocking. The downside is that they will miss the potentially malicious elements of some applications.
Ultimately, you’ll need to decide which end of the spectrum you want to be on for your organisation and then test accordingly.
The facts are that false positives are a problem in two areas:
- On initial antivirus deployment
- During ongoing management
But these two scenarios are very different and must be treated as such.
Initial Antivirus Deployment False Positives
When you install an antivirus software onto a machine it’ll usually be configured to monitor background activity, watch for new file activity and maybe scan the full hard drive. This means that you’ll probably see false positives being flagged pretty quickly, but then will need to open up some of your applications to verify they operate okay.
False positives you find here will most likely exist on other machines so once you’ve resolved the false positive in your central policy (e.g. with an exclusion) then this shouldn’t be a problem again. In turn, you’ll find that if your AV testing is on a good range of live builds, you’ll resolve all the false positives very quickly.
When you’re testing AV for false positives, assess why they are occurring. Is it because the applications you’re using are coded in a similar way to malware (e.g. using obfuscation methods or encryption) or is it simply because the AV is being far too aggressive? An AV convicting some freeware as potentially malicious is one thing, but it should not be triggering a false positive on Outlook.exe.
Ongoing Management False Positives
Once your AV software has been tuned to your environment (hopefully in a very quick and painless process), new false positives should really not be happening in a well controlled environment. Most organisations shouldn’t be permitting users to have administrative rights to install untrusted applications, so the rate of change of greyware should be minimal. However, if you are seeing false positives now, then you’ve got some investigating to do to see what’s going wrong.
A One-Off Problem Only?
After the initial installation you may rarely see a false positive in day-to-day operation. So how big of an issue should we make of False Positives?
If you look at some independent testing of AV software, they will often find a huge pool of software online and push that against the AV. But this doesn’t reflect your organisation and what you are using. Arguably, a more aggressive product with a higher rate of initial false positives is better than a less aggressive product with a higher rate of ongoing false negatives (missing the bad).
Considering that it might take a matter of hours to weed through several false positives of your non-standard applications one-time, it may be a small price to pay for better protection over the many years of life you’ll get from a solid product.
Testing False Positives
To test for false positives, just enable your AV product for the highest levels of detection and logging, and then start using all of your software.
Handling/Removing False Positives
- The First Rule of False Positive Club is don’t always assume something is a false positive. Your AV might have found something that you didn’t realise was malicious.
- If you’re sure something is a false positive, find out why. There’s usually a reason and this’ll help you understand better how the AV works and if it’s over-sensitive for you.
- Add a File Exclusion (Hash Value) – If there’s a specific file you want to permit, add a policy to exclude that file’s hash value, e.g. SHA256. This ensures that only that exact file and not some variant or pretend copy is being accidentally permitted.
- Add a Trusted Certificate – If the file you wish to permit is signed by a trusted party, e.g. Microsoft, your AV product should include the option to add the certificate of that trusted Issuer. This means that any file that is signed by that party will be trusted implicitly. This technique is useful if you have different builds, versions and hashes of files from the same issuer that you wish to permit. This can be common in development environments with home grown applications you need to permit.
- Add a Folder Exclusion (Be Careful) – If you wish to exclude a number of files then you could exclude a whole folder, but this is potentially dangerous. A malicious file could be dropped into the excluded folder and thus become assumed good (a false negative). Exclude folders with care, and ideally only exclude folders that have restricted write access, or maybe exclude the folder for scanning but don’t permit execution.