Intrusion Detection Systems (IDS) rely on binary signatures or known-bad-behavior of malware in order to detect threats. It has become very clear that this approach has limited success due to the fact that in most cases it will miss new threats and variants.

My question is, rather than taking the more-or-less "black listing" approach, what would be the drawbacks of taking an integrity-based approach or "white listing" safe applications and system components? The integrity auditing could easily be done through an external hyper visor that hashes the binary of a program before it's executed.

While this approach won't stop certain attacks that make use of the vulnerable program to run malicious commands, it seems to me that it would be effective in preventing a persistent foothold on a machine.

  • That's along the lines of what Bit9 sells. Their approach to endpoint protection is based on application whitelisting. There was a bit of a kerfuffle a couple of years ago when an attacker managed to infiltrate them and add malware to their whitelist.
    – Xander
    Dec 9, 2014 at 22:16

1 Answer 1


Some vendors sell systems that work like you describe. The biggest problem is lack of active cooperation from vendors; there is no reliable way to build a list of hashes of "allowed binaries" since:

  • What looks like "an application" from the user's point of view may be a collection of many executable files (to a large extent, that's what DLL are).

  • Any software update will break the hash values and require recomputing them. This is especially an issue with applications that auto-update automatically on a daily basis (as is typical of some modern Web browsers).

  • Some applications rely on on-the-fly generation of executable files, e.g. to optimize things with regards to the local hardware (I think Adobe Reader does that). Notice too that the .NET framework comes with a C# compiler (csc.exe) and that compilation process can be invoked programmatically (this is what powers ASP.NET Web pages, and it is rather mainstream).

So, in practice, systems that work that way are coupled with a learning phase (where information is gathered about what files are executed by a given user on a "typical day"), explicit exceptions for corner cases, and a streamlined process by which the user may request addition of a given application to the whitelist.

Be warned that if you apply such a system, your users will hate you thoroughly, because they will feel it to be an intolerable intrusion in their private world. User hatred has its own cost, security-wise (security works much better when users are willingly collaborating), so this had better be counterbalanced by a net gain from the whitelist system.

Also, consider that malware is not necessarily a .exe or .dll file. Word macro virus are a well-known example.

  • 2
    I love your "User Hate" comment, which applies to the entire security domain and is almost never mentioned in public, and almost never recognized in security practices at corporates. Dec 9, 2014 at 23:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .