Whitelisting is a network security approach that blocks resource access to all but a select few trusted entities. Also referred to as permit lists, allowlists, or passlists, whitelists can contribute to your access control strategy by making highly sensitive resources harder for adversaries to penetrate.

In this article, we will introduce whitelisting and explain how it differs from blacklists. We will also review common applications of whitelists and the limitations of this security tactic. There are ways, however, to overcome these limitations and make whitelists an effective part of your access control strategy.

Before we continue, we wanted to highlight that although the terms “whitelist‚ and “blacklist‚ have long been used by the security industry (you probably discovered this article by Googling for one of those words), we believe that these terms carry undesired connotations that we should be sensitive to and, as is the trend within the technology community, should be replaced with terms such as “allowlist‚ and “denylist.‚

What is Whitelisting?

Whitelists protect resources by creating a registry of the trusted entities that may access that resource. Just as a bouncer lets listed guests into a private party and blocks everyone else, a whitelist denies access to all but the listed entities.

Depending on the implementation, the entity list may comprise user or device identities, applications, IP addresses, or other criteria.

What all whitelists have in common is the trust of security administrators. That trust grants certain entities with access and excludes all others. Examples of whitelists in action include:

• An ad blocker’s list of websites that may display ads.

• An access point’s list of MAC addresses determining which devices may connect.

• A firewall’s list of public IP addresses dictating what traffic may pass through.

The goal of whitelisting is to constrict a resource’s threat surface by preventing all but a few, known, trusted entities from accessing that resource.

Whitelisting vs. blacklisting

Blacklists are registers of known threats that the system specifically stops from accessing a resource. Where a whitelist is like a bouncer at a private party, a blacklist is like a no fly list. People on the list are barred from boarding commercial aircraft, while everyone else is permitted.

Antivirus and anti-malware applications are the most common blacklisting applications. They compare files on a system to a list of known threats and act against those files.

Let’s compare the two approaches to access control:

Whitelist vs. blacklist comparison chart

In an online context, blacklists document the users, devices, IP addresses, or other entities that cannot be trusted with access to a resource. Of course, you can only create this list if you know what those threats are in the first place. Blacklists will not stop threats that you do not know about yet. On the other hand, you can base a whitelist on something you always know — who or what you can trust.

Administrative overhead is another disadvantage of blacklists. The few trusted entities on a whitelist normally do not (or should not) change very often. Blacklists, on the other hand, constantly change. You see this with antivirus and anti-malware software. Vendors must constantly push updates to their blacklists to keep their software effective against the latest threats.

What are common use cases for whitelisting?

We mentioned some simple whitelisting examples earlier. Whitelists are also used to build security into network architectures, control access to cloud-hosted resources and third-party solutions, and protect resources from malicious software.

Application management

System administrators use whitelists to control what software may run on managed devices such as company-issued laptops or application servers. Starting with a clean system, you create a list of all the applications, libraries, and other software needed for the system to function. The deployed application whitelist can now block any other software from running on the managed devices.

Application whitelisting enhances device security by blocking the execution of malware. System administrators also use application whitelisting to counter shadow IT by preventing users from installing unauthorized software. Locking down a managed system like this prevents users from opening security holes and avoids potential software licensing issues.

Network access control

Whitelists can protect company resources by restricting traffic to a limited number of IP addresses. System administrators often use whitelists to secure network perimeters and reinforce security between subnets.

Routers near a network’s perimeter may have whitelists that only allow traffic from firewalls and gateways onto the private network. Likewise, whitelists can protect industrial control systems by severely restricting the source of incoming network traffic.

SaaS access control

SaaS whitelisting is an extension of network access control that protects a company’s cloud-based resources. Within the SaaS provider’s security settings, you can tell the service which IP addresses to permit access. SaaS whitelisting ensures that traffic to the cloud service only comes from authorized network paths.

You should, however, consider the drawbacks of SaaS whitelisting. Each service has its own whitelisting system. And some services do not offer the feature at all. As a result, this whitelisting patchwork will increase your administrative overhead.

Is whitelisting required for secure access control?

Whitelisting can significantly enhance security. They reduce attack surfaces by strictly limiting access sources. Whitelists also minimize the impact of successful security breaches by flagging unauthorized connection attempts and placing more barriers in the adversary’s path.

But whitelists are not complete security solutions. They have limitations that you should consider before using whitelists for secure access control.

Setting up whitelists is resource-intensive

Creating an effective whitelist system requires an up-front commitment of time and resources. Every entity on the list, whether a user or an IP address, must be carefully considered. If the whitelist is too restrictive, then business operations will suffer. If the whitelist is too permissive, then you lose the security benefits.

An example of one approach to mitigate this is in a SaaS access control context. Instead of whitelisting IP addresses for each individual authorized user, a company may choose to whitelist the IP address of a trusted VPN gateway (or a Twingate Connector). To access the SaaS application, a user must first sign into the VPN. This allows companies to centralize whitelist management at the VPN level, and reduces the number of IP addresses that must be whitelisted with each SaaS application. (The drawback of this approach is that all traffic must flow through the gateway.)

Whitelist best practices recommend a phased approach to ensure that the rules make resources more secure while giving administrators enough time to minimize or mitigate impacts on business operations.

Whitelists are less convenient and responsive

Whitelists work best with centrally managed and relatively static systems where users have few expectations of control. In more dynamic environments, whitelists become difficult to manage and may degrade the user experience.

IP address whitelists, for example, only work when you can count on users to have static IP addresses. Remote workers, traveling executives, and others accessing company resources away from the office may run afoul of the whitelist.

Whitelists are also difficult to execute well in scenarios where user roles and access needs change frequently. Shared IP addresses become tempting workarounds, but they undermine the security that the whitelist was supposed to provide.

Whitelists depend on trust

As we discussed earlier, whitelists consist of the entities you trust with access to a resource. From that respect, a better word for whitelists would be “trustlist‚. And that trustlist contains an inherent security weakness:

Your resources become exposed when you do not realize that a whitelisted entity is no longer trustworthy.

Make whitelists more secure by removing trust

A former employee’s unrevoked credentials, a BYOD laptop used without a VPN, or a compromised system on the private network are just as dangerous to whitelists as they are to any other security system.

Despite their limitations, whitelists can be an element — but only one element — of a layered security strategy that includes perimeter defenses, endpoint protections, anti-malware systems, and more.

The best way to implement whitelists is to take trust out of the equation. Twingate’s Zero Trust Network Access (ZTNA) solution lets you benefit from whitelist access control while mitigating their trust-driven limitations.

Furthermore, Twingate enhances whitelist security by applying principles of least-privileged access and tying trust verification to the actual identities of users and their devices - rather than IP addresses which are often more loosely tied to individuals. Additionally, rather than always granting access to listed entities, Twingate layers on top context-aware rules to refine evaluation of allow/deny decisions with each connection attempt.

Whitelists secure resources but need help

Whitelists are powerful tools for protecting a company’s resources. By creating a list of the entities you trust with access to a resource, you can deny access to everything and everyone else. These trust lists significantly constrain access to resources and reduce those resources’ threat surfaces. But whitelists are far from perfect. When not implemented correctly, they disrupt business operations and leave resources open to attack.

Removing the risk of trust makes whitelists easier to implement as one layer of your defense-in-depth security strategy. Twingate’s Zero Trust Network Access solution lets you:

• Create a consolidated, identity-based whitelist within your company’s access control system.

• Extend whitelists to services and applications that do not natively support whitelists.

• Supplement whitelist capabilities with context-sensitive rules.

Twingate’s modern approach to access control lets you easily apply principles of least-privileged access and software-defined perimeters to protect company resources from today’s dynamic threat environment.

Contact Twingate to learn more about implementing whitelist security in a ZTNA strategy.