You are here

Whitelisting, blacklisting, and your security strategy: It's not either-or

Ben Bernstein, Co-founder and CEO, Twistlock

Windows vs. Mac. AWS vs. Azure. Kubernetes vs. Swarm. If you work in IT, these are some of the big decisions you may need to make at one point or another in your career.

And if you work in security, you can add another item to that list: whitelisting vs. blacklisting. Both strategies can help to keep applications, infrastructures, and networks secure. But you can’t always whitelist and blacklist at the same time, which means you may need to decide which approach makes the most sense for your needs.

Here's what you need to know about whitelisting and blacklisting, with an explainer for which approach might best complement your security strategy.

[ Get Guide: Best Practices for GDPR and CCPA Compliance ]

Blacklisting and whitelisting defined

As you might presume, whitelisting refers to the practice of blocking all entities except those that are explicitly allowed to communicate with you or your infrastructure. Blacklisting means accepting most entities, but excluding those you believe to be malicious or otherwise wish to avoid.

I use the term “entities” here because the things that you are whitelisting or blacklisting could take many different forms. Most commonly, you’d be whitelisting or blacklisting individual network hosts. But you might also decide to whitelist or blacklist applications, websites, subnets, or anything else to which you want to grant access to your network (or not).

[ Webinar: SecOps Innovation—A Look Into the Future of Security Insights ]

When to blacklist

Traditionally, blacklisting has been the most common approach security teams use for securing their networks or environments.

If you think about the history of the Internet, and software in general, that makes sense. We usually design systems so that as many people as possible are able to use them. So we let everyone in by default, and only blacklist those whom we determine to be a threat.

For applications or infrastructure that meets the description above, blacklisting usually makes the most sense. If you want to maximize your user base or offer a service to the public, you typically need to make it open by default, excluding malicious parties on a case-by-case basis.

When to whitelist

Whitelisting makes more sense in situations where you do not want a service to be public. An obvious example is a corporate application that only select employees need to access. In that case, you’d want to whitelist the computers (or IP addresses, etc., depending on how you choose to manage access control to the app) of those users, and keep everyone else out by default.

Whitelisting can also prove beneficial in cases where you want to define what an application or service can do, and prevent it from doing anything else. For instance, you might define a policy that allows a given microservice to run on a particular host and consume a specific amount of resources—and that shuts down the microservice if it attempts to move to a different host or consume more resources. This policy would effectively whitelist a certain type of behavior and prevent behavior that does not meet predefined criteria.

It’s easy to see how such an approach could help to mitigate a security breach. If your microservice is compromised and attempts to perform non-whitelisted behavior, it will be stopped automatically.

This type of security strategy is not practical to implement using blacklisting. In most cases, it’s difficult to define everything that an application shouldn’t do, because it’s hard to anticipate every type of action an application might perform when it has been compromised. It’s much more practical to define what an application should be doing, and prevent it from doing anything else.

This ability to control behavior and limit security risks is part of what makes whitelisting so powerful and innovative.

When you rely on blacklisting alone, you limit yourself primarily to allowing or preventing access based on identity, not behavior. Behavior-based access control is possible only through whitelisting.

Whitelisting and blacklisting in tandem

Keep in mind that although we tend to talk about blacklisting and whitelisting as binary opposites, there is no reason you can’t use both approaches at the same time.

You could, for example, whitelist network access to a service based on geographic region by allowing users to connect only from regions where you know legitimate users are located. At the same time, you could maintain a blacklist that blocks malicious users within those regions.

You could also blacklist hosts based on IP address while taking advantage of whitelisting to manage application behavior as described above. Under this strategy, you’d be blacklisting at one layer of your infrastructure (the network) and whitelisting others (application behavior).

It's not an either-or choice

Don’t think of whitelisting and blacklisting as an either-or choice. Instead, recognize that while blacklisting may be a more rudimentary approach to controlling access in some cases, it’s still a powerful tool.

At the same time, whitelisting allows you to control access more rigidly. It also enables things that aren’t possible using blacklisting, such as managing application or microservice behavior for security reasons.

[ Get Report: How to Get the Most From Your App Sec Testing Budget ]