Application Whitelisting Concepts: Definition, Types, Implementation and Best Practices
Application Whitelisting Is a Fundamental Cybersecurity Practice. Learn How to Add It to Your Corporate Network.
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 and how can you use our tool to do this.
What Is a Whitelist?
First of all, you need to understand what a whitelist is. A whitelist, also known as a passlist or allowlist, serves basically as an index containing entities that are approved, thus serving as a list with a set of apps and their components that are allowed to be installed on a host following closely an established baseline, as NIST describes it. If we speak of an InfoSec context, systems go through a regular workload in environments that are centrally managed and that is where whitelisting can do its magic, being efficient. A whitelist can also index various components of the approved applications. Some examples, in this case, would be plugins, extensions, software libraries, or configuration files.
According to the NIST’s Guide to Application Whitelisting, the programs used to perform an application whitelisting process are found under various names like application control programs, application whitelisting technologies, or simply whitelisting programs.
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.
How Application Whitelisting Works
Simply put, here is how an application whitelisting process works: let’s say you want to execute certain software on your endpoint. If this was not previously included in a list of whitelisted apps, so apps that are already approved by admins, then it will be blocked, thus not allowed to be launched. The programs’ hash can also be analyzed to determine if that’s real software and not a malicious copy of the original one.
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 name,
- digital signature/publisher whitelisting.
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.
An MD5 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.
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.
Digital Signature/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.
Application Whitelisting vs. Blacklisting
A core difference between application whitelisting and blacklisting would be that whitelisting plays a more restrictive role allowing only pre-approved programs to be executed, while blacklisting blocks unwanted programs to run, programs that are already on a defined list against which they can be compared. The difference between application whitelisting and application blacklisting can be easily understood as the first process works with a list of pre-approved apps, blocking everything else by default, the latter works with a list of denied apps, allowing everything else by default to execute.
That’s why maintaining a list of programs you need to make use of is far more efficient than maintaining an ever-growing list of programs you don’t intend to use because they are malicious.
Why Is Application Whitelisting Important?
Application whitelisting is important because it can help your organization keep zero-days and ransomware attacks away and lets your IT admins have better control over what applications are deployed on a host. There are many benefits to application whitelisting. It’s an easy process for system administrators to manage, and if set up correctly it provides a high level of protection against malware infections and other malicious programs.
There are many benefits of application whitelisting, but I will emphasize some of them:
It keeps ransomware, zero-days, and other malware types away
You keep cyberattacks employing different malware types, ransomware attacks away, keyloggers, APTs, fileless attacks, or zero-days away so no malicious code will be run in your organization. The usual antivirus is designed based on signature and somehow it works as a process of blacklisting. That means, if a file wants to run on a machine, then the av solution will take that hash of a file to compare it with an existing database that contains examples of compromised code. If it does not find it on that list, it lets them launch. And that is why application whitelisting is far more efficient than a basic antivirus because no file can be launched if it wasn’t previously whitelisted, therefore pre-approved.
And since the malware gamut is expanding day by day with new types and forms, no antivirus, whatsoever, will be able to keep pace with all those changes, so its malicious code database becomes inaccurate. Just look at the numbers, 350 000 new malware strains are being identified every day.
It supports software license compliance
The Software license compliance remains on the same page with audit requirements. Because through this process, only whitelisted apps are allowed to be launched, this will significantly reduce the risk to have software without a license being installed in a company. That means, no software license violation when the audit time knocks on your door.
It gives admins control over executed applications
It provides control over what application will be executed in a network where sensitive data should be well safeguarded. In the application whitelisting process, the administrators are the decision-makers. So, they will decide which application goes on the whitelist and can be launched on an endpoint making the system safer. If any end-user would be been let to be part of the decision-making process, that this could have led to security breaches, as a usual end-user could unintentionally let any program be executed, either harmful or not.
System speed is enhanced and system interruption decreased
It increases system speed and decreases system interruption. That means that maintaining a list of whitelisted apps will cover better resources management across networks, triggering, of course, a better cybersecurity strategy.
Less IT assistance needed
Users won’t constantly need IT assistance. Since users will only be allowed to install whitelisted programs, that also means that the risk of them installing any software that will interfere with another installed software and thus lead to system bugs resulting in IT assistance is reduced. This means less money for a company spent on its service desk.
It provides you with reporting capabilities
Application Whitelisting tools let you have access to reports on applications in terms of data usage, what new installations have been performed on a host and this will help in the long run of keeping up with the latest application versions.
Application Whitelisting Challenges
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.
Another challenge would be that establishing the inventory of approved apps is a time-consuming feat that requires constant improvement and monitoring. Application whitelisting can be an excessively complicated and hard to manage process for some reasons: for instance, in order to perform the initial whitelisting compiling there are some data necessary like what tasks are associated with what users and what applications they specifically need in order to finalize those assigned tasks. Then, the maintenance of such a complex list can be challenging, as an organization has many processes and applications that might be interrelated.
Another challenge could also be represented by the possibility of hackers employing techniques like replacing the already whitelisted application with malicious ones that will facilitate the infiltration of malware into the network. This could happen if threat actors build a malware version with the same file name and the same size of a real whitelisted application and then make the switch between them, so the malicious copy will replace the real whitelisted app.
Application Whitelisting Best Practices
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 and also other application whitelisting best practices you need to implement today.
#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.
In this case, you can use, for instance, our Patch and Asset Management Tool. Why? Because it provides you in a matter of a few seconds with a thorough asset inventory report of all the installed software within your organization.
#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.
#4 Whitelist both on-premises and cloud applications
Both on-premises and cloud applications are important for all enterprises. Admins should distinguish between essential business apps belonging to both categories and whitelist them to enhance the organization’s safety.
#5 Check the publisher
One of the best practices for application whitelisting is to always verify the publisher of the software before installing it on your computer. This way you can ensure that you are not installing any malware onto your computer.
#6 Whitelist specific admin tools
Some admin tools should be whitelisted too. By whitelisting these specific admin tools, the user will be able to use these tools without triggering the restriction. A selective access protocol can help with the restriction of who has access to what tools.
#7 Use application whitelisting along with other cybersecurity measures
Application whitelisting is not the sole method you should implement for your organization’s safety. It only adds to other tools that are designed to protect your networks: like antivirus, e-mail security, patch management, DNS filtering, and so on.
For instance, application whitelisting can work with an automated Patch Management Tool, patches can be actually approved before they are deployed in your organization, as normally whitelisting tools will not let a new software version be executed. This means that a patch management tool will let admins approve the patch before deploying it and thus adding it to the whitelist.
Heimdal™ Application Control
- Default approval for system applications;
- Handle access by File Path, MD5, Publisher, Certificate or Software Name;
- Ability to easily manage spawns of any files executed;
- And much more than we can fit in here...
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.
Do you enforce application whitelisting in your company? What are your thoughts on it? Let me know in the comment section below!
This article was written in collaboration with my colleague, Alina Georgiana Petcu.