I recently wrote about the Australian Signals Directorate (ASD) Essential 8 and today will be covering one of the most effective of the 8 strategies, one that sits proudly in the original ASD top 4. Application whitelisting only allows known good applications to execute on a computer. If unknown applications can’t run on a system, then execution of malware and other malicious code is much less likely. Of course, it’s not foolproof and multiple layers of protection and strategies will always be required. For example, application whitelisting does not stop a known good program like a web browser from executing malicious code in memory. We of course need to make sure other strategies are in place like application patching and hardening.
It would be nice to flick a switch and just turn on whitelisting. To pick a system like a client PC in the finance department and enforce that only the finance application and Microsoft Office can run. Unfortunately implementation can be tricky and whitelisting is one of the most difficult essential strategies to implement. The cost and effort to implement and maintain the solution, and possible negative impacts on business operations need to be considered. It might be the case that strict whitelisting is not suitable or necessary across all systems. On the workstations of high risk users, full application whitelisting and the blocking of all unauthorised components (executables, scripts, libraries etc.) is most likely warranted, but on low risk users and machines perhaps an audit only mode or simpler path based implementation may be suitable. This is where a risk assessment can be used to determine if the security benefits warrant the implementation in a particular environment.
When evaluating application whitelisting products, I recommend looking first to any capability that is built into the operating system before considering third party whitelisting products. If the capability is built into the OS it makes sense to evaluate it first, especially from a cost perspective. AppLocker is a good example when it comes to the Microsoft Windows. This Microsoft built whitelisting capability is suitable for many environments, but also has its limitations and can be difficult to manage and maintain. A third part product may be preferable due to its centralised reporting and management capabilities. Airlock Digital is a good example here and addresses the limitations of AppLocker.
When it comes to implementation, getting a basic level of protection in place is often a good first step. This baseline can be achieved using path based whitelisting, that allows software to run from approved locations. This level of implementation is suitable for many environments and can be built on for higher risk users and machines. These approved locations need to be folders that can’t be written to by standard users. In a Windows environment you let applications run that have been installed to standard locations like program files, and then you only need to whitelist specific applications that run under folders that a standard user (and a malicious one) could write to. This of course is dependant on the user not being an administrator on the machine and also assumes that the software installed by administrators should be allowed to run on machines.
I have had great success implementing this approach quickly without third party tools, using Microsoft AppLocker or Microsoft's Software Restriction Policies. I have seen companies planning a full whitelisting implementation and struggling for months to implement properly and roll out widely. It's a matter of getting a level of protection in place that can be built upon, rather than just the dream of the ultimate solution.
Colin has over 20 years consulting experience working with organisations ranging from small business to large enterprises. He has consulted in the United Kingdom, Canada and Australia. He specialises in Microsoft based technology solutions, disaster recovery implementations and information security.