So if whitelisting is more secure than blacklisting, why is it not as widely deployed as blacklisting solutions? The answer is that if a blacklisting solution does a poor job, it may let malicious code execute, but it will never prevent you from using your system the way you intend (unless you are trying to use actual malicious code). And if whitelisting does a poor job, it may keep you extremely secure, but it will interfere with your ability to use the system the way you intend by erroneously blocking non-malicious code. So most people have traditionally traded proper security for ease of use. Another reason that AWL has not traditionally been widely deployed is that the theoretical premise described in the previous paragraph has often been too true with the earliest AWL solutions brought to market and has given AWL somewhat of an undeserved reputation in light of the modern AWL solutions available that have come very far toward solving those issues that plagued earlier versions. In other words, early versions of AWL solutions did do a “poor job” of deciding what to block and what to allow, but almost all AWL solutions on the market today have long since done away with those “poor job” behaviors. The rest of this article intends to dispel many of the misconceptions that still exist amongst even the most well-educated security experts.
1. Application whitelisting solutions are not needed because Windows and UNIX have the technology built in for free
Most popular operating systems (Windows, Linux, etc.) have some sort of “deny-by-default” technology built into it. Here are some examples:
Windows has AppLocker In newer versions of Linux, using the integrity measurement architecture, module signing, and Secure Boot, it’s possible to have a system where almost any change is detected. http://lwn.net/Articles/488906/ NetBSD has the Veriexec subsystem
If there is no other “deny-by-default” functionality that is part of your security strategy, then these tools should be considered for closing the gaps that antivirus blacklisting leaves. Using these tools is much better for security than not using them. However, the problem is that in the real world, they are very difficult to use and manage. The management interfaces for most of these tools requires the IT admin to identify specific files that should and should not be allowed. On an operating system that is in use for any purpose, there are thousands (typically hundreds of thousands) of files involved, many of which have legitimate needs to change dynamically on the fly. Manually managing the list of specific files that need to be approved or denied can be a burden that far outweighs the security gains. Detractors of AWL often cite the existence of these tools as a reason to not use AWL solutions. But I put forth that if these built-in tools are a viable alternative, why do the vast majority of IT admins ignore them and use only blacklisting for security defense?
2. Application whitelisting is difficult to manage
Yes, the hardest part of AWL is admittedly managing what is and is not on the whitelist. As explained in the previous bullet, it is extremely difficult to keep the list of what is and is not allowed on a system where there are hundreds of thousands of files and many of them have a legitimate need to dynamically change at runtime. But this is one of the core problems that modern AWL solutions exist to solve. And it is a very solvable problem. What makes it solvable is not expecting end users or IT admins to figure out the details, but to ask them only for high-level approval of an entire action and then using software to track the gory details of exactly what files need to change. Modern AWL systems are quite adept at tracking what is happening on a system when approved changes are made and managing the whitelist database accordingly. In a proper AWL solution, there should never be a need to use a feature that adds or removes individual files from the whitelist database. Rather, users should simply approve learning of entire change actions, such as installing a new software package. A properly design AWL solution makes management as non-intrusive as possible.
3. Application whitelisting will put all end users at the mercy of waiting for approval from admins for every task
Some AWL solutions are designed to follow a paradigm that all decisions about what should be allowed or denied need to be solely in the hands of IT admins or security experts. But that is an artificial choice, and while that may work well for some organizations, for others it may be better to put more trust in the end user. If I have a population of users that I trust will only install applications known to be good, I should be able to have my AWL solution configured so that end users can make controlled changes to their systems. Alternatively, if I want to reserve all approval for the admins and not give any explicit trust to end users, I should still be able to do that without making end users wait for approval. I should be able to have an admin configure the AWL solution to pre-approve certain applications that are okay to install on user’s systems, and when the end user tries to install those, they should proceed immediately. This can all be done while still keeping the deny-by-default protections that are protecting the entire system.
4. Application whitelisting prevents developers from doing their jobs
For most users, the types of files they create and edit as part of their jobs are harmless data files. But developers are creating executable code as part of their normal jobs and executable code is exactly what AWL solutions look to block without prior approval. That can be problematic if the AWL solution is not configured properly. But if done correctly, even developers can use AWL to protect their systems without interfering with their normal work. The easiest way to accommodate developers is to have the AWL solution “trust” the development tools they use to create new code. If a Windows developer uses Visual Studio to develop code, having the AWL solution trust Visual Studio would mean to allow any executable code produced by Visual Studio to automatically be added to the whitelist database and be authorized to run. With such a situation you would obviously want to control who can run Visual Studio and how it can be run, but that can easily be done with operating system permissions. Of course this does allow for the possibility of malicious code to somehow run Visual Studio in order to create persistent malicious code. But, as with all security being about “raising the bar”, you’ve raised the bar much higher by using AWL than by forgoing it because you believe it to be incompatible with developer environments.
5. Application whitelisting will require an IT admin to change how they deploy software and manage systems
If your AWL solution is built properly, this does not have to be true. A good AWL system will work seamlessly with your existing methods of software deployment and system management. For instance, if you use a Remote Management and Monitoring (RMM) tool such as Altiris, Kasaya, LanDesk, etc. to manage your endpoints, your AWL solution ought to work seamlessly with it. By simply having your AWL solution “trust” the endpoint agent for these systems, you should be able to continue to manage systems via the existing mechanisms you already use in your RMM tool and have your AWL solution automatically learn and trust the updates and changes that you make legitimately through the RMM system.
6. Application whitelisting will not work alongside existing security solutions like Antivirus
There is no reason why application whitelisting and antivirus blacklisting should not work well together on the same endpoint. In fact, for a proper defense-in-depth strategy, you should be using both at the same time. AWL will actively protect against zero-day attacks that AV would otherwise let slip through, and AV would eventually flag any potentially malicious program that may have been inadvertently allowed on the whitelist database. From a technical point of view, all AWL solutions should work well next to all AV solutions. Both are typically implemented using file system filter drivers, and that technology is specifically designed to allow for multiple simultaneous implementations.
7. Application whitelisting can be circumvented using interpreted code
This is just entirely untrue. Any competent modern AWL solution will include the capability to designate certain programs as interpreters and restrict what code files they will be allowed to interpret. Of course interpreter programs (such as java.exe, python.exe, etc.) can be all-powerful and therefore must be restricted to not allow arbitrary code to run. AWL solution vendors are not so foolish to leave such a gaping hole.
8. Application whitelisting can be circumvented using built-in OS components
Similarly to the potential threat of interpreters, AWL solution vendors would not leave such a gaping hole. While core OS components obviously need to be allowed to run, they do not need to be wholly allowed to make persistent changes to the file system that could be used to launch an attack. There is a big difference between allowing a component to run and allowing it to make damaging changes.
9. Application whitelisting can be breached while changes are being applied to systems
This misconception stems from the way that early versions of AWL solutions worked. If you needed to make an approved change to the system, such as installing a new software package, the protections would be temporarily lifted so that the changes could be applied and learned, meaning that whatever changes were made during this approved window would be allowed going forward according to the whitelist. Modern AWL solutions should no longer rely on such an open window and instead should follow and learn only those changes made by the approved process being learned, while still protecting and rejecting unauthorized changes made by any other process on the system.
10. Application whitelisting can introduce performance overhead
This assertion is just not true at all of any modern AWL solution. Especially when compared to the overhead required of antivirus blacklist solutions. For a blacklist solution to check a file before deciding whether to allow or block it, it must compare the entire contents of the file against a database of signatures of every malware variant ever identified. That’s no easy task and it’s what the CPU on any system running an AV tool spends a very large part of its cycles doing. With AWL, the entire contents of a file must be read but only once in order to create a hashed signature of that file’s contents. That signature is then simply compared to the signature stored for that file in the whitelist database. It does not even have to search the list of all signatures in the database because the signatures can be indexed by filename. If the filename and signature don’t match, it’s denied. For AWL solutions where the whitelist database is stored locally on the endpoint, the need for reaching across the network to consult the database at any point is eliminated.
