Essential Application Whitelisting Concepts: Definition, Types, Implementation

The simplest way to stop malicious code from infiltrating your network is by automatically blocking it before it even enters the system. A straightforward and efficient way to achieve that is through application whitelisting. Sounds pretty easy, right? But how does it work? Let’s find out.

In the following lines, I will go over what application whitelisting is, as well as discuss the types of application whitelisting that you can add to your network. As always, stay tuned until the end for actionable steps that you can take to implement this cybersecurity practice in your company’s infrastructure.

What is Application Whitelisting?

Application whitelisting is a cybersecurity practice that entails creating a directory of software applications that are approved to run on your organization’s network. As opposed to how blacklisting only blocks a predetermined tally of apps, whitelisting is a more proactive approach to system protection. Its purpose is to prevent harmful files from executing themselves on your devices.

By putting an application whitelisting strategy into place, you are effectively blocking all programs that are not pre-approved. This not only actively prevents malware from infiltrating your corporate infrastructure but also leads to more competent resource and productivity management by prioritizing traffic flows.

Nevertheless, the very nature of application whitelisting poses some challenges. For one, it restricts how employees can use their work devices. This is not only frustrating but can also be detrimental to efficiency in the long run as new software has to go through a lengthy approval process to enter the workflow. What is more, establishing the inventory of approved apps is a time-consuming feat that requires constant improvement and monitoring.

Types of Application Whitelisting

Application whitelisting is not a singular concept, as it can be achieved in multiple ways. According to the National Institute of Standards and Technology (NIST), the five main types rely on:

file size,
file path,
file name,
cryptographic hash,
or

In the subsections below, I have explained each type of application whitelisting, along with its benefits and drawbacks.

File Size Whitelisting

A simple attribute that you can use for application whitelisting within your company’s systems is that of file size. As soon as a cyber attacker messes with a file on any device and injects it with malicious code, its size will change. This will be an instant red flag and no longer allow that software to run, protecting your enterprise from digital harm in the process.

Unfortunately, this comes with many drawbacks. Most importantly, it can become cumbersome to track as it involves accounting for individual files based on a volatile criterion. Plus, the size of a file can change without any malicious interference. For example, if an employee edits a vital document and adds new text and media to it, it will jump from (let’s say) 1MB to 5MB. In cases such as this, application whitelisting by file size is not desirable.

File Path Whitelisting

Application whitelisting by file path entails that your system allows all applications in a defined path to execute in the network. To achieve it, you can go for either directory-based whitelisting, complete file path whitelisting or both. Directory-based whitelisting involves approving entire folders, while complete file path whitelisting deals with specific files.

So, for example, if you choose to whitelist the pathway C:/Windows/Program Files, every single subfolder in there will be approved to run. However, if you choose to whitelist C:/Windows/Program Files/Microsoft Office/filename.xml, only that specific file in the Microsoft Office subfolder will be allowed to execute out of the entire folder. For enhanced security, my suggestion here is to use the two variants in tandem, with a higher focus on complete file path whitelisting if possible.

File Name Whitelisting

As an alternative to application whitelisting by file path, you also have the option to approve applications by file name. This is more accessible and straightforward than the previous alternative, but it also comes with additional risk. Malicious actors can easily infiltrate your network with compromised files that have been renamed to mimic the titles on your system’s whitelist.

Let’s take the example of the aforementioned filename.xml. Mirroring the same file path in the C:/Windows/Program Files/Microsoft Office requires more time and effort on the part of hackers. However, simply infecting your infrastructure with a macro executable that has been renamed to filename.xml is a lot quicker and easier for them. This is why I recommend never applying file name whitelisting on its own and considering the additional layer of MD5 hash whitelisting as well.

Cryptographic Hash Whitelisting

An MD5 cryptographic hash attributes a unique alphanumerical value to a file. Application whitelisting procedures that follow this criterion thus allow the execution of hashed files only regardless of their name or path. While this type of whitelisting is undoubtedly the most secure, it also poses novel challenges to your network admin.

Cryptographic hashes change when files are updated. Therefore, whitelisting conditions must be revised accordingly when this happens. What is more, outdated hashes for software versions with known vulnerabilities must be deleted from the whitelist as well. Thus, this type of application whitelisting is advantageous in terms of security but can be quite a hassle to manage as well.

Publisher Whitelisting

Application whitelisting based on publisher identity follows the premise that programs from reliable developers are trustworthy and thus can be safely approved onto your corporate network. In this case, the whitelist needs to be updated only when new software is released or when the published changes its signature key. The team handling the process will thus have an easier task cut out for them as opposed to when using other whitelisting alternatives.

Nevertheless, the main disadvantage of allowing programs to execute according to their publisher is that this includes vulnerable software that has reached the end of life as well. In addition to this, popular developers usually have more than one app on their roster, and not all of them might suit the purposes of your business. Thus, differentiating between what to approve and what to restrict can become difficult.

How to Whitelist an Application

Enforcing application whitelisting in your enterprise infrastructure unfolds in three essential steps: establishing a baseline for the process, whitelisting trusted applications, and monitoring the resulting inventory for necessary updates. I’ll paint a more detailed picture of each step in the subsections below, so let’s get into it.

#1 Audit Your Corporate Network

The first step towards successful application whitelisting is auditing your corporate network. Provided that your system is clean, my recommendation is to scan it along with any external storage drives and detect what applications and processes are necessary for the functioning of your business. This will help you establish a baseline of what programs you need to approve. In doing so, you will also weed out superfluous or potentially malicious applications running on the network.

#2 Whitelist Trusted Applications

Once you’ve established which applications you can trust, it’s time to whitelist them. This pretty much means that you decide what software you allow to run on your enterprise network, effectively blocking everything else. You should do this as promptly as possible to further reduce risks. It’s at this point that you should also determine what type of application whitelisting you want to enforce.

As previously mentioned, you can choose between file size, file name, file path, cryptographic hash, and publisher. My recommendation is to implement a balanced mix of multiple criteria to cover all your bases. Our Heimdal Security Application Control software can help you with that and more.

Handle access to all systems by software name, file path, MD5 hash, publisher, or certificate and achieve completely granular supervision over your access governance strategy. Application control is a complex cybersecurity strategy that goes beyond whitelisting. Our software allows you to keep both whitelists and blacklists in tandem, tailoring them as you go. What is more, it provides full integration with the Heimdal™ Privileged Access Management solution for comprehensive admin rights monitoring.

#3 Constantly Update the Whitelist

Now that you’ve created your whitelist and have the software to strengthen it, don’t forget to keep it up to date. As I’ve discussed in this article, new versions of applications are released all the time due to vulnerabilities detected in older variants. Updating the system whitelist is the next best cybersecurity practice in this case after automatic software patching.

Wrapping Up…

Application whitelisting is a competent way to keep the noses of malicious attackers out of your business infrastructure. When part of a larger application control strategy and assisted by strong software solutions, it is even more efficient.