Application whitelisting

Multi-layered defence is a very good thing, but only if the applied layers are more or less independent of each other. Are application whitelisting and AV scanning statistically independent?

I will resist the temptation to discuss whether different AV scanners are independent nowadays [1] – and only say that they are not as independent as I would like them to be.

Let us look at the process of how a program becomes whitelisted. The classification can be made for two reasons: either because the software is trusted, or because it has produced negative AV scan results.

In the case of ‘trusted’ software developers, the program inherits the trust of the company that has developed it, on the assumption that whatever they release is clean. Is this because we know with certainty that the development process is free from possible infection? No – in the past even major software developers have released infected executables. But having learned from these experiences, an intensive AV scan (with multiple-scanner systems) is now incorporated by these developers into the release process of their products. So the trust is based on the fact that the release software goes through virus scanning.

In the case of untrusted developers the file is whitelisted if it comes up negative against an extensive virus search.

Either way, the decision to whitelist a program comes from a negative virus scan result at some point in the process. In short, whitelisting is currently nothing more than (admittedly careful and extensive) inverted blacklisting by AV software.

In order to become a really valuable component of a layered defence, whitelisting must be independent of AV scanning. This would require a thorough analysis of indexed files. The problem is not only that there are several orders of magnitude more files to be whitelisted than blacklisted. In addition, a lot more analysis is required to declare that a file is clean than to declare that it is malicious. For a malicious file, the analysis can be stopped at the first sign of malicious behaviour (during dynamic analysis) or at the first malicious procedure encountered in the code (during static analysis). For a clean file, all procedures have to be checked to be certain that they are incapable of malicious act.

In short, only a full, detailed analysis can verify the decision to whitelist a file – a lot more resources need to be dedicated to a good whitelisting database than to a virus database. It is resource-intensive and time-consuming, but not impossible.

Latest articles:

Bulletin Archive