application whitelisting

Application whitelisting vs. blacklisting

Unlike technologies that use application blacklisting, which prevents undesirable programs from executing, whitelisting is more restrictive and allows only programming that has been explicitly permitted to run. There is no consensus among security experts over which technique -- blacklisting or whitelisting -- is better. Proponents of blacklisting argue application whitelisting is too complex and difficult to manage. Compiling the initial whitelist, for example, requires detailed information about all users' tasks and all the applications they need to perform those tasks. Maintaining the list is also demanding because of the increasing complexity and interconnections of business processes and applications.

Proponents of whitelisting argue it is worth the time and effort needed to proactively protect systems and prevent malicious or inappropriate programs from entering the network. Using a whitelist that allows only applications that have been explicitly approved offers more protection against malicious software, rather than the looser standard used by application blacklists, which permit any software to run unless it has been discovered to be malicious and has been added to the blacklist.

How application whitelisting works

Implementation of application whitelisting begins with building a list of approved applications. The whitelist can be built into the host operating system (OS), or it can be provided by a third-party vendor. The simplest form of whitelisting allows the system administrator (sys admin) to specify file attributes associated with whitelisted applications, such as file name, file path and file size.

Windows AppLocker, which Microsoft added to Windows 7 and Windows Server 2008 R2, allows sys admins to specify which users or groups of users are permitted to -- or not permitted to -- run particular applications. In addition to restricting access to specific applications, AppLocker can be used to restrict users from installing new software, define which versions of a piece of software are permitted to be run and provide control for running licensed software.

Risks of using application whitelisting

Attackers can replace whitelisted applications with malicious apps with relative ease by creating a version of their malware that is the same size and has the same file name as a permitted application and then replacing the whitelisted application with the malicious one. Therefore, it is much more effective for application whitelisting software to use cryptographic hashing techniques coupled with digital signatures that are linked to the software developers.

Application control vs. application whitelisting

Although the terms are often used interchangeably, application control and application whitelisting are two different things. Both of these technologies are designed to prevent the execution of unauthorized applications. However, application control is not as stringent as true application whitelisting.

Application whitelisting is designed to monitor an OS in real time and prevent the execution of unauthorized files. This goes beyond simply preventing unwanted applications from running. Application whitelisting may also restrict the use of PowerShell scripts and other types of scripts in an effort to prevent ransomware attacks.

Although application control can be thought of as a form of application whitelisting, it is primarily designed as a tool for preventing unauthorized applications from being installed. When someone attempts to install a new application, the installation package is compared against a list of authorized applications. If the application is found to be authorized, then the installation process is allowed to continue.

While it is true that application control can be an effective tool for preventing the installation of unauthorized applications, the technology has two significant shortcomings. First, application control works at the installation package level, not at the file level. This means that it does nothing to prevent someone from running a stand-alone executable file or an application that is already installed on the system. This means that, while application control can be a useful tool for application management, it isn't particularly effective at preventing ransomware attacks.

The other major shortcoming associated with application control is that application control tools do not perform a granular inspection of application installation packages. When someone attempts to install an application, the application control mechanism only checks to see whether or not the application itself is allowed. If the application is authorized, then the application control tool assumes that the application installation package is trustworthy. It does not verify the integrity or authenticity of the files within the application installation package. As such, an attacker could conceivably install unauthorized code by slipping it into an otherwise legitimate application package.

Advantages

There are a number of benefits associated with using application whitelisting. It is worth noting, however, that some application whitelisting tools are more feature-rich than others and that not every tool delivers all of the benefits discussed in this section. For example, Microsoft's AppLocker, which is a part of the Windows OS, provides basic whitelisting capabilities but lacks the rich reporting and alerting capabilities that are commonly found in third-party solutions.

The best advantage to using application whitelisting is that it provides protection against ransomware attacks and other types of malware attacks. Traditional antivirus software tends to be signature-based. In other words, when a user attempts to launch an executable file, the antivirus software compares the file's hash against a database of code that is known to be malicious. If no match is found, then the file is allowed to execute.

In some ways, the use of antivirus software is similar to application blacklisting. The antivirus software explicitly forbids the execution of software that is known to be malicious. The problem with this approach, however, is that new malware is created every day, and it is impossible for any antivirus software application to maintain a completely comprehensive database of malicious code.

In contrast, application whitelisting is far more restrictive. It does not allow any executable code to run unless an administrator has explicitly granted approval. This greatly diminishes the chances of a ransomware attack or other malware infection occurring.

Depending on an application whitelisting tool's reporting capabilities, such a tool may help the organization to determine which users are engaging in risky behavior. Some application whitelisting tools are able to create reports detailing which users have attempted to install or run unauthorized applications, as well as any malware that has been detected.

Another benefit to using application whitelisting is that doing so can simplify software license compliance. To be fair, most application whitelisting tools are not designed to perform license metering. At the same time, however, restricting the use of unauthorized applications prevents situations in which an auditor flags the organization for a license violation as a result of someone using an unlicensed application that the IT department did not even know about.

One more potential benefit to using application whitelisting is decreased help desk costs. Application whitelisting allows an organization's IT staff to not only restrict which applications users are allowed to use, but also to control which versions of an approved application can be run. These restrictions have the potential to drive down help desk costs since they eliminate the possibility of users installing a piece of software that interferes with another application on the system. It also gives the IT staff the ability to make sure that users are running application versions that are known to be stable and reliable.

Uses

Because application whitelists can be tedious to configure and maintain, the technology is used primarily within organizations that demand the best possible security, as well as extremely tight control over application usage. An organization might, for instance, have contractual or compliance mandates that require specific applications to be used.

Although somewhat counterintuitive, application whitelisting has also been successfully used by small organizations. Small and medium-sized businesses (SMBs), by their very nature, tend to rely on a small and relatively static collection of applications, which makes application whitelisting relatively easy to deploy and maintain.

Implementation

The application whitelisting implementation process varies considerably depending on which whitelisting tool is being used. Regardless, there are several best practices that should be adhered to during the implementation process.

First, before an organization begins deploying the application whitelisting software, it is critically important to compile a comprehensive inventory of the applications that are used throughout the organization. Remember, all of these applications will need to be included in the company's whitelisting policy. The application whitelisting software is designed to enforce endpoint security, so any software that is not explicitly listed within the policy that the company creates will not be allowed to run. This is why it is important to create a comprehensive inventory of the applications that the organization uses. Failure to identify an application and include it in the whitelisting policy will result in the application being made unavailable to users.

Another best practice is to be careful about how you define whitelisted applications. Some organizations choose to whitelist specific folders or file names. However, using this approach may make the organization vulnerable to ransomware attacks and other threats.

The problem with identifying applications by their files or by the folders that they use is that malware authors can easily create malicious code that uses the same file names or folders as legitimate applications, thereby fooling the application whitelisting software.

The best way to ensure good endpoint security is to identify applications by using the publisher's signature or by using a cryptographic file hash. Most application whitelisting tools will allow you to base your whitelisting policy around both of these identifiers.

A slightly less effective, but still viable technique is to identify applications based on the registry keys that they create. The main problem with building a whitelisting policy around a series of registry keys is that not all executable code utilizes the registry. Most PowerShell scripts, for example, do not create registry entries.

Similarly, building a whitelisting policy that is based primarily on registry keys can expose your organization to various threats to endpoint security simply because it is easy for a malware author to spoof a legitimate application's registry keys.

Management of application whitelisting

If an organization plans to use application whitelisting, it must consider how it will handle the long-term management of the whitelists. Any time that the organization adopts a new application, that application must be added to the whitelist policy before it can be used. Similarly, an organization typically cannot upgrade an existing application to a new version unless it first adds the new version to the whitelist.

The bigger challenge associated with application whitelisting is that of intertwining the application whitelist management and patch management processes. Unless an organization has a plan for dealing with the patch management process, application patches will cause the whitelisting software to cease to recognize the patched application as being legitimate.

Most organizations use Windows Server Update Services (WSUS) or a similar tool for patch management. These types of tools give administrators the chance to approve patches rather than simply allow endpoints to download patches automatically. As administrators approve a patch for deployment, they can also add the patch to the whitelist policy.

Another possible solution is to base the application whitelisting policy around vendor digital signatures. That way, if a vendor releases a patch, then the patch will automatically be approved for use because it contains the same digital signature as the application that it is updating.

One more possible solution is to look for a vendor that keeps up with patch releases on your behalf and automatically updates whitelists to reflect newly released patches. Of course, this approach might be slightly less desirable since the vendor may whitelist a patch that the organization does not wish to deploy.