Application Whitelisting (AWL) is a technology created to keep computer systems safe from unwanted software, including malware. It works together with Application Blacklisting to keep malware and other unauthorized software from running on a system.
AWL controls the software that is allowed to run on a computer system. It does this by denying access to any application that has not been specifically whitelisted, i.e. deemed safe and allowed by the administrator.
Application blacklisting is another way to control the software allowed on a system. It denies access to any application that has been blacklisted, i.e. deemed malicious or unwanted.
From a security perspective, AWL is considered more secure. This is because it allows a set of trusted applications and blocks everything else. In theory, this would even stop dreaded “zero day” attacks.
Zero-day attacks are attacks that exploit a software vulnerability that was previously unknown or undisclosed by the software vendor. The first day one is observed is known as “day zero”.
Traditional blacklists cannot stop malware that uses a zero-day attack. This is because the attack has never been observed and therefore cannot be blacklisted.
However, application whitelisting can stop such an attack. All applications not whitelisted are blocked.
Whitelisting can be a safe approach to controlling the applications on a computer system – but it can also be onerous to manage.
The number of legitimate software applications stretches into the millions. While users may wish to install a safe application for legitimate reasons, they would be denied from doing so if the application was not on the system’s whitelist.
This can create inefficiency and frustration in the workplace, where dozens or even hundreds of users with a broad range of needs require many different applications to perform their roles.
AWL requires the total contents of a file to be read one time. This reading is used to create a hashed, aka digital signature of the file’s contents. The signatures are indexed by file name. When a new application enters the system, its signature is compared to the signature stored in the whitelist database. If the filename and the signature do not match, the application is denied.
Conversely, when an antivirus blacklist checks a file to see if it is legitimate, it must compare the file contents against the database of signatures of every previously identified malware variant. That activity takes up much of the CPU cycle on computers running antivirus software. Computers work harder to blacklist than they do to whitelist.
While AWL does a great job of protecting against malicious applications, it also can prevent access of legitimate applications. This can make a system difficult to use. Many IT admins only use blacklisting instead of what they see as the over-the-top security of whitelisting. There have been instances when AWL blocks non-malicious code, which then can cause a system to malfunction.
Many operating systems have “deny by default” systems. However, in order to manage these systems the IT administrator has to identify the individual files that should, and should not be allowed. Modern AWL systems are able to track when approved changes are made and manage the whitelist accordingly.
Another complaint about AWL is that it slows down the work of an end-user who needs to add a program to a system. However, modern AWL solutions can be configured so that trusted end users are enabled to make controlled changes to their systems. Another way to manage AWL is for an IT admin to pre-approve applications that are allowed to be installed, so when the end user attempts to install the application it proceeds without a problem.
Developers traditionally had a problem with AWL because it is their job to develop executable code, which is exactly what AWL solutions seek to block. However, the AWL solution can be programmed to “trust” development tools as they are used to create a new code. Once the AWL solution trusts a tool, all of the code developed with that tool will be automatically added to the whitelist.
An AWL solution should be built to work together with your system management and software deployment. If you manage your endpoints with Remote Management and Monitoring tools, then the AWL Solution should be programmed to “trust” the endpoint agents.
Whitelisting Software - Paid
An integrated single AWL solution is the best bet for an organization that does not have adequate staff to develop, test and deploy AWL policies.
Whitelisting Software - Free
Once the system is up and running, a designated IT admin should be responsible for keeping it up to date. Tasks should include updating the whitelist with new applications, applying any issued patches to the program, deploying the whitelisting to additional platforms, and performing periodic tests to ensure the software is working as promised.
In addition to only permitting accepted applications to run on a system, AWL has the following attributes:
The U.S. National Institute of Standards and Technology provides a Guide to whitelisting application technology. Recommendations include using the whitelisting mechanisms that are built into operating systems, and using mechanisms that identify applications by digital signatures, as well as path and file name.
There are many tools in the cybersecurity toolbox. Application Whitelisting can provide an added modicum of security. In the case of a high risk host, or a managed environment with central control, application whitelisting can provide a more secure system than a simple antivirus blacklisting program.
Deploying Application Whitelisting
Homeland Security AWL Strategic Planning Guide
NIST Guide to Application Whitelisting