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.
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).
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.
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
