Implementing application whitelisting
Application whitelisting is a multi-purpose control. The technology was originally created to prevent users from running unapproved or unlicensed software. With the rise of unauthorised downloads and malicious email attachments, this technology has proven to help with security and prevent unauthorised files execution.
In order for application whitelisting to be effective, it must be implemented in tandem with other controls. For example, if an application has a vulnerability and it’s whitelisted then it’s an easy path for an attacker.
Application whitelisting is a control that can be implemented in many different ways to reach the same end goal. It largely depends on what resources your organisation has available and how ready the organisation is for change. Below are steps that you can follow to get started with implementing this control.
1. Set a scope
Assess the resources you have and the devices in your network, to help set a scope of devices for your implementation. Think about the:
- people responsible for implementing and managing the control
- software that can be used to manage and distribute policies
- time and money to conduct a thorough implementation plan.
When assessing the devices in your network, determine which devices to cover first. These should be higher risk devices that access internet services, such as end-user laptops and desktops.
2. Understand what is used in your environment
Analyse which files are executed in your environment. You need to understand who needs specific application access and which files are executed to run those applications. This includes analysing client devices like laptops, desktops, and servers.
Application whitelisting technology usually has two policy modes: audit and enforce. In audit mode, file execution attempts are checked against a policy and a log entry is generated. The file will continue to execute, but this will allow you to understand if rules need to be added or modified. Enforce mode means that the file execution attempts will be checked and actioned if there is a match.
3. Create policies for different user groups and devices
When creating or modifying rules, you can use several rule conditions:
Hash - This is the cryptographic hash value of the file. This is the strongest rule condition you can use because it uses the file attributes (ex: file content, name, and size) to generate a unique one-way hash value. If any of these attributes were changed the hash value would change. A current hashing algorithm family should be used, such as SHA-2, as these algorithms do not have any known or feasible collision techniques.
File attributes - A combination of file attributes can be used to create a rule and is reliant on strong file permissions. This includes combining file path, file name, file size, and file type.
Signature or publisher - The creator can sign their file digitally using their private key. You can verify the identity of the file publisher by checking their public key. A rule condition could be created to trust any file that is signed by a specific publisher. Publishers may sign multiple files for different applications using one key, or they may have a separate key for each application. If these files are modified, they would no longer be digitally signed and would trigger a deny action by a publisher-based rule.
When selecting a rule condition, it is best to start with the strongest rule condition (hash) and decide if it is manageable. If your organisation does monthly patching for a specific suite of applications, using hashes for your rule conditions would be difficult to manage because these hashes would change monthly. In this case using file path and file names may be easier to manage.
If your organisation does not have strong access controls and/or there are a large number of local administrators, it can be challenging to create rules. For example, if your policies are based on file attributes, local administrators can bypass these. Put access controls in place to minimise these types of bypasses. Train your staff, especially those with administrator privileges, to know what application whitelisting is and what it is protecting against.
TIP: There may be cases where a policy requires an exception for a specific user or group. Before creating that exception and a hole in the policy, the reason behind it should be assessed. Other controls may be better suited to manage that need, such as a sandbox or an isolated device.
4. Test the policies before implementing
Once you have your rule conditions set and your policy is prepared, you need to test them.
Do several rounds of testing and refining before you switch the policy to enforce mode. Remember to check the default rule is the deny file execution or else the whitelist is not effective. Thoroughly test the policies with positive and negative tests. Positive tests mean applications are permitted and blacklisted files are denied. Negative tests mean files that are not whitelisted are permitted.
TIP: When policies are set to enforce mode, ensure your change and incident management processes know how to handle any issues. Changes to the policy should go through a change management process, but if the issue is blocking business operations then you may need to use an incident management process.
5. Stay informed of bypass strategies
Application whitelisting policies can be bypassed using trusted and whitelisted files. For example, msbuild.exe is a Windows binary file that comes with the .NET framework and is used for compiling and executing code. Applocker, the Windows application whitelisting software, will whitelist files in the Windows folder by default , which includes this binary file. An attacker could use this file to execute malicious code without getting stopped by AppLocker.
Stay up-to-date with bypass strategies for the technology you use. You may be able to mitigate a bypass technique to your application whitelisting policy by refining the whitelist rule or adding a blacklist rule.
6. Review your policies regularly
Review the application whitelisting policies you set at least once a year. Your organisation can change a lot over a year and this includes the applications that you use. Review your policies regularly so that you can check for:
old rules that are no longer applicable
temporary exceptions that should be changed into new rules or removed
rule conditions that can be changed to be more strict and specific. For example, moving from a file path rule condition to a file path, file name, and file type rule condition.
You may need to create temporary exceptions or new rules over time. The reason for these new rules or exceptions should be reviewed because alternative controls could be used, like network segmentation or access controls.