The Australian Cyber Security Centre (ACSC) lists application whitelisting as one of the essential eight strategies to mitigate cyber security incidents. More specifically, it is considered the most effective strategy to prevent malware delivery and execution, by disallowing execution of unapproved/malicious programs. Despite this, I’m amazed at how many organisations have this low on their list of actions within their cyber security strategy.
So why aren’t more organisations implementing application whitelisting? From my experience it comes down to three reasons:
- Confusion over exactly what application whitelisting is
- Limited guidance in how to approach an application whitelisting implementation
- Disruption to the business once application whitelisting is enforced
To begin with, I often encounter clients who are confused with the terms application whitelisting and application control – made even more unclear by the ACSC’s recent terminology change from the former to the latter. Oftentimes clients are asking for the ability to control who can execute what application packages – this is the traditional application control approach provided by legacy endpoint security vendors. However, from the perspective of preventing malicious code from executing, the who is not important. With application whitelisting, we are really only interested in whether or not the executables contain known, safe code. The who is typically covered using existing security controls within the organisation – administrative/privileged account access, software deployment rights and application authentication.
For this article, I am sticking with the traditional terminology of application whitelisting, where we are looking to only allow execution of approved executables, DLLs, scripts & installers. The misunderstanding of this distinction can leave businesses and IT professionals with an unclear understanding of what they are required to implement to align with the recommended security controls. The ACSC does, however, provide a good explanation of what application whitelisting is (and more importantly what it is not) in their publication Implementing Application Control.
Despite the name of the aforementioned article, the practical guidance provided by the ACSC for implementation of application whitelisting is very limited. A high level approach is given (identify applications, develop the execution rules and then maintain the rules), along with appropriate methods of enforcement (cryptographic hash rules, publisher certificate rules & file path rules), but the information provided is not enough to guide organisations through their journey. The US National Institute of Standards and Technology (NIST) offers a more in depth approach to implementation in their Guide to Application Whitelisting, though they stop short at recommending specific products or vendors, leaving readers unsure of how to execute.
Where most organisations progress to is trialing an implementation with Microsoft’s AppLocker – the software control mechanism built into Windows. Here, one of the best resources is the US National Security Agency (NSA) Information Assurance Directorate’s comprehensive guide to implementing Application Whitelisting using Microsoft AppLocker. But the deficiencies soon become apparent. Managing application whitelisting policies through Group Policy (assuming you are lucky enough to have Windows Enterprise licencing) is difficult and limited. Hopefully, you have a reasonable SIEM for collecting Windows logs to review blocked executions. If you progress past the audit stage into enforcement, you find yourself puzzling over how your IT Helpdesk will allow your CEO to execute the latest Zoom plugin she just tried to update from home.
So, what’s the solution?
- Understand what application whitelisting is and what it is not
- Familiarise yourself with a best practice implementation
- Prepare your environment – an organisation running a Standard Operating Environment (SOE), with restricted administrative privileges and SCCM software deployment is going to have a much easier time maintaining an application whitelisting solution
- Choose the right product – consider dedicated application whitelisting software that provides the ability for your IT Helpdesk or privileged users to enter an override code to temporarily allow execution when safe to do so
- Make use of features outside of cryptographic hash whitelisting – file paths, trusted publishers, parent process whitelisting and Microsoft blacklists can all reduce the overhead in managing exceptions
- Develop and document your new procedures – educate your IT Helpdesk and your users on what they can do to request (or even self-override) a blocked execution when appropriate
Many organisations can transition application whitelisting from audit mode to enforcement mode after a few weeks of monitoring executions and adding relevant exceptions. How you manage those exceptions going forward, though, will ultimately determine the success of your deployment.
