Goodbye whitelist and blacklist, hello allowlist and blocklist!
The problem with whitelist and blacklist.
Whitelist and blacklist are a pair of very important tools and terms for cybersecurity.
So it’s kind of a bummer that they’re bad.
Why? Mostly because the terms aren’t nearly as clear as they could be. Whitelists and blacklists control who or what has access to a given device or service.
Whitelist: A list of who or what that is allowed access to a given device or service.
Blacklist: A list of who or what that is blocked access to a given device or service.
Admittedly, these terms are not complicated or difficult to remember. Once you’re regularly in the cybersecurity space, it’s easy to throw these terms around, forgetting that once upon a time, you didn’t know what they meant either. However, a big part of the job of a cybersecurity professional is to communicate with non-security professionals. Easier-to-understand terms would make this easier for everyone.
What should we call these lists instead? The hint is in their very definitions.
Allowlist: A list of who or what that is allowed access to a given device or service.
Blocklist: A list of who or what that is blocked access to a given device or service.
These two terms immediately describe the functionality of the lists to everyone, even those who aren’t in the know. Anything that makes communication easier is a good thing!
Additionally, these terms are more race and culture-neutral. Not all cultures view white and black in the same way that makes whitelist and blacklist more intuitive for western people.
This is why a large number of big tech players, including Google, Microsoft, and Apple are moving away from whitelist and blacklist.
So, for the remainder of this article (and all future writings at Fractional CISO), we’ll be using allowlist and blocklist instead of whitelist and blacklist.
Clearer communication benefits everyone.
Security professionals must work with all sorts of people, with varying technical skills and knowledge, across their organization. Effective implementation of a security program requires institutional change that must be supported and pushed with clear communication from leadership.
Jargon is helpful for talking with high-precision amongst peers knowledgeable in the same industry. It is not useful anywhere else, and it’s actually detrimental when trying to create a document, policy, or program easy for anybody to understand – and the whole organization must buy into a security program. Cybersecurity doesn’t work if people in the organization are left out – whether intentionally or accidentally.
Whitelist and blacklist can be used as a reminder to check your security-related communications for jargon and accessibility. Are the documents you’re sending out easily understandable? How can you check up on staff to make sure they understand the aim of the program? Do you have methodology in place to help employees who need extra help understanding their role and responsibilities in securing your organization?
Why not denylist, acceptlist, welcome-list, etc.?
This language is in flux across the industry right now and people have started using a couple of different terms. Blocklist returns millions more search results than denylist does, indicating that there is some centralizing on that term.
The same goes for allowlist over acceptlist and welcome-list. It either has more search results, or the search results are on-topic.
If the industry begins to centralize on a different term, we would happily adopt it.
When should you use allowlists and blocklists?
Typically (though not always), a given tool or service will adopt either an allowlist or a blocklist approach, not both at the same time. Allowlists will only allow whatever is on the list, blocking all other (non-listed) traffic. Blocklists do the inverse – they allow everything through with the exception of the specifically listed traffic.
Many personal security and privacy tools typically operate from a allowlist approach first, everything is blocked until an allowlist of permitted traffic is created. For example, a VPN can be set up so it only allows connections from a specific geographic area or IP address range.
A non-tech example of allowlists in action are RFID scanners at corporate office buildings. Only people who work there are allowed access to the building.
The blocklist approach can be used by VPNs, but a more common application would be a web server. Most traffic needs to be allowed through to a website, but there may be specific regions that a company wants to keep from accessing for security or copyright reasons. A whole range of IP addresses could be blocklisted, preventing those specific users from accessing.
A real life example of a blocklist in action is the TSA’s No Fly List. Everyone is allowed to fly in America, except for specific people on that list.
There is no one rule for implementing allowlists or blocklists.
Should your VPN/web server/email use a blocklist or an allowlist? The answer is…
It depends!
Like everything else in cybersecurity, the decision that you make needs to be based on your company’s unique use-case and needs.
One thing that is for sure – it’s time to start implementing allowlists and blocklists instead of whitelists and blacklists!
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.
