This post originally appeared in TechBeacon.
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.
If that’s the quandary you face, you’ve come to the right place. Below, we define whitelisting and blacklisting, and explain which approach best complements your security strategy.
What Is Blacklisting? What Is Whitelisting?
The concepts themselves are easy enough to understand. 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 particular ones that you believe to be malicious or otherwise wish to avoid.
I use the term “entities” here because I want to make clear that 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 have taken 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 because we want as many people as possible to be 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, then, blacklisting usually makes the most sense. If you want to maximize your user base or offer a service to the public, you typically will need to make it open by default, and exclude malicious parties on a case-by-case basis.
When to Whitelist
On the other hand, 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 very 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 particular microservice to run on a particular host and consume a particular amount of resources, and shut 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 why 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, however, you could still 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 in the way described above. Under this strategy, you’d be blacklisting at one layer of your infrastructure (the network) and whitelisting others (application behavior).
To sum up, 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 can allow you to control access more rigidly. It also enables things that just aren’t possible using blacklisting, like managing application or microservice behavior for security reasons.
- Application Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
What Integrated Security Really Means — and Why It MattersRead the Blog
A DevOps Approach to Compliance: What It Really Takes to Build Compliant AppsRead the Blog
CISOs: 5 Essential Features in a Cloud Native Security PlatformRead the Blog
Making CI/CD Fast and SecureRead the Blog
Leveraging Webhooks for Security Alerts with TwistlockRead the Blog