This content is part of the Essential Guide: Secure Web gateways, from evaluation to sealed deal

application whitelisting

Contributor(s): Peter Loshin

Application whitelisting is the practice of specifying an index of approved software applications that are permitted to be present and active on a computer system. The goal of whitelisting is to protect computers and networks from potentially harmful applications.  

In general, a whitelist is an index of approved entities. In infosec, whitelisting works best in centrally managed environments, where systems are subject to a consistent workload. The National Institute of Standards and Technology suggests using application whitelisting in high-risk environments, where it is vitally important that individual systems be secure and less important that software be useable without restrictions. To provide more flexibility, a whitelist may also index approved application components, such as software libraries, plug-ins, extensions and configuration files.

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, or it can be provided by a third-party vendor. The simplest form of whitelisting allows the system administrator 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 system administrators 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.

See also: application security, Trojan horse, spyware, adware, drive-by download, pop-up download, barnacle, rootkit, malvertisement, clickjacking, scareware

This was last updated in January 2017

Continue Reading About application whitelisting

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What kind of application whitelisting technologies have you worked with, and how well have they performed?

Whitelisting the best way to secure your environment, ThreatLocker application whitelisting is simple to use and also has  storage controls, which whitelists devices like USB drives and external storage devices.

How do you unwhitelist files?
We've always used an ever-changing list of USE THIS, NOT THAT (or whitelist, blacklist if you prefer).

When we launch a new project, we expect our hire to follow the list. Since many arrive with installed programs, we test those while closely track their use. By the time the project wraps, the new programs will be on one list or the other.... 
@Snogherjsk: The answer to your question depends on the kind of file, and the way you are doing application whitelisting -- and I don't have specific expertise in doing this (maybe someone else has such an answer?).

However, that said, application whitelisting systems may offer some control over which types of files that are opened with particular applications, such as Word or Excel files.

Other types of files, such as configuration files or plugins or any other type that might be considered "executable" would also likely to be covered by controls provided by the application whitelisting system in use.
In an environment in which employees have the latitude to download and install application for expedient purposes is well ripe for application whitelisting so as to prevent rogue application and limit infection and application vulnerabilities that can create a security risk for the organization.
Whitelisting is a great strategy for preventing information security incidents related to malicious (or otherwise unwanted) applications -- but whitelisting is just one such strategy.

By itself, whitelisting is not going to be a complete security solution.

And all organizations, even those that don't allow users to install any software at all, can still benefit from implementing whitelisting as a part of a fully in-depth security strategy.
Is whitelisting the domain the solution on Windows 10 to gain access to a secure domain?
Maybe -- though I'm far from an expert on Windows 10. 

Presumably, you already have access to that domain (if you don't, you probably shouldn't be trying to access it without permission), in which case (I guess?) it would work.

But, again, I'm not an expert...
Normally when in a room full of cybersecurity engineers I start with two questions:
(1) Have you heard of Application Whitelisting (AWL)?  They nod yes, but show their disdain.
(2) Have you ever known someone to deploy it successfully?  They generally burst out in laughter.

Only one person said they had some kind of success.  Here’s my experience ...

I've developed three cybersecurity products acquired by Cisco, Wheelgroup Corp., Netranger (NIDS/NIPS) and NetSonar (a network scanner), in 1998; and Psionic Software, First Response (an automated remediation system) in 2002.

My first experience with Application Whitelisting was when I took over as the VP of Engineering for Coretrace, an Application Whitelisting company, in Dec 2011, which was acquired by Lumension Security in Nov 2012 and re-licensed to Sophos in 2013.   After my experience and eight cybersecurity patents for NIDS/NIPS, which use blacklisting technologies (no matter how clever they appear they're a default-allow strategy), Application Whitelisting (a default-deny strategy) made perfect sense.  But what I found was that AWL in 2012 was very difficult to deploy and manage, especially in a network of heterogenous computers or OS images.

While I was able to clean up the Coretrace product before it was acquired by Lumension, it had a problem scaling beyond 300 to 500 endpoints because it, like many other AWL systems, have complicated rules and user interfaces for adding EXEs and DLLs to the whitelist. (Coretrace never got their execution control for scripts working.  Their "learn mode" and "trusted change" were even worse.  But the company was sold before I could implement architectural changes to address the fundamental problems of its usability.)  It blocked everything (except scripts) the way it was intended, but it just wasn't manageable.  Coretrace's Bouncer was not the only AWL product with management issues.  One competitor tried to use a rating system that force you to access some unwanted Apps just to enable those you needed.  With some AWL products, you had to exclude entire directories from enforcement just so system could work with some Apps, a situation which essentially defeats the purposes of AWL once someone knows there’s a hole in the armor.

In 2013, Steve Snapp and I launched White Cloud Security, which resolved the laundry list of architectural issues I'd identified in the Coretrace product.  The first goal was to make it easy to deploy and manage, along with the ability to easily share the load of the whitelist management between trusted Admins.  We also addressed several major security holes now apparent in traditional AWL, the SHAttered Attack (which spoofs an App's SHA-1 identity) and malicious "lone-wolf" security admins who intentionally add unauthorized Apps to the trust-list.

We released the product in July 2015, and have added features to make it easier to use, including execution control for systems that use software that dynamically generate scripts that can never be added to the whitelist because they are different on each invocation.  This is an important feature, because an Enterprise or SMB can't use a whitelisting technology if it can't handle every kind of App and Script that the business needs to run within their network.

Another important thing we did was to eliminate the "whitelist push" model in favor of a client-server model.  This keeps the trust-list secure, while also eliminating the need to constantly push the whitelist out to all endpoints.

We've also implemented Trusted Scripts, which applies execution control to scripting languages, a feature missing in many AWL systems. If you can't control the scripts running on an endpoint, then you're not really controlling what runs on the endpoint.

It has been a hard sell to most IT people.  Because of the black-eye they got when punched in the face by their first (and only) AWL deployment, most of them are unwilling to believe that there's a simple paradigm that dramatically reduces the Trust-Listing workload.  But we find that once a user or organization is locked down, they rarely go back to relying upon blacklisting technologies alone.  Those that do, often come back with two black-eyes and a broken nose from a ransomware infection that their blacklisting technology didn't stop.

We're always looking for feedback and enjoy answering questions about blacklisting vs whitelisting, because both interactions help us improve our product.

i like your post


File Extensions and File Formats

Powered by: