Whitelisting is a cybersecurity strategy under which a user can only take actions on their computer that an administrator has explicitly allowed in advance. Instead of trying to keep one step ahead of cyberattackers to identify and block malicious code, IT staff instead compiles a list of approved applications that a computer or mobile device can access. In essence, the user has access to only a limited set of functionality, and what they can access has been deemed safe by the administrator.
Whitelisting is a fairly extreme lockdown measure that, if implemented properly, can keep many cybersecurity problems at bay. However, it can be quite inconvenient and frustrating for end-users, requires careful implementation and proper ongoing administration, and isn’t a foolproof barrier to attacks.
A blacklist is a slightly more familiar concept — a list of things that are dangerous and need to be blocked from the machines you’re trying to protect. Many antivirus and anti-malware programs are, essentially, blacklists: they include a list of known malicious code, and automatically leap into action when those programs are detected on the protected computer. Blacklists have a fairly obvious disadvantage in that they need to be constantly updated to stay ahead of the latest attacks. By definition, antivirus software can’t protect you against a zero-day attack.
A whitelist is the inversion of a blacklist. If you’ve implemented a whitelist, you’ve essentially blacklisted everything out there in the universe except the stuff that’s on your list. At first blush, this seems to make security a snap: you don’t have to worry about new malicious code emerging as a threat to your infrastructure because the only things your machines can access are things you already know are safe.
But there are drawbacks to whitelisting too that should be pretty obvious. For one thing, it restricts the users’ freedom to use their machines the way they want (and generally people think of their work computers as “their” machines, since they sit in front of them eight hours a day). There’s also quite a bit of work that needs to be put into building a whitelist; after all, while a blacklist of known malware and attack sites can be put together by a vendor for widespread use, every organization’s whitelist of the programs they need to use will probably be unique. And there are of course ways that wily attackers can “put themselves on the list.”
In general, the kind of whitelisting we’ve been talking about so far is application whitelisting — that is, only allowing a certain set of applications to run on the protected computer. (The term has a somewhat different meaning when it comes to email or IP addresses, which we’ll discuss at the end of the article.) The National Institute of Standards and Technology (NIST) has a guide to application whitelisting, and while it’s a few years old at this point, it’s still a great introduction to the topic. It goes in great depth on a number of topics; we’ll touch on the basics here.
What threats does whitelisting fight? Application whitelisting is a great defender against two different kinds of security threats. The most obvious is malware: malicious software payloads like keyloggers or ransomware won’t be able to execute if they’re not on the whitelist. But that’s not the only benefit; whitelisting can also be a tool to fight “shadow IT.” End users or individual departments may try to install programs on their computers that are insecure or aren’t properly licensed. If those apps aren’t whitelisted, the rogue departments are stopped in their tracks, and IT will be informed about the attempt.
How do you create an application whitelist? There are two different approaches here. The first is to use a standard list, supplied by your whitelist software vendor, of applications typical for your type of environment, which can then be customized to fit. The other is to have a system that you know is clear of malware and other unwanted software, and scan it to use as a model for a number of other machines. The second method is a good fit for kiosks or other public-facing devices, which run a limited set of applications and don’t require much by way of customization.
How does whitelisting software distinguish between unapproved and approved applications? The NIST guide breaks down the various attributes that can be used for this purpose:
Which attributes should be used and how much weight should be given to each is key to the art of whitelisting. For instance, if your whitelisting software allows any application with a specified file name or in a specified folder to execute, then all a hacker has to do bypass that protection is to place malware with that file name in the permitted location. Specifying a precise file size or requiring a check against a cryptographic hash makes it harder to trick the whitelisting software, but this information would have to be updated in the whitelist every time the application file changes — whenever it’s patched, for instance. And if patching is deferred because it potentially interferes with the whitelisting software, that can itself open up security holes.
And as NIST points out, full-on applications aren’t the only potential threat to a computer. Whitelisting software needs to keep on top of various libraries, scripts, macros, browser plug-ins, configuration files, and, on Windows machines, application-related registry entries. Different vendors can deal with these with varying levels of granularity. Some whitelisting software can also whitelist specific behavior from even approved applications, which can come in handy if hackers manage to hijack them. And whitelisting software should also integrate with the permissions structure of your operating system, whitelisting applications for some users (like administrators) but not others.
How can you make sure to get the most out of whitelisting? Follow these tips:
Whitelisting isn’t a one-size-fits-all tool, and it may not be an ideal endpoint solution for every computer under your purview. Calyptix Security suggests three scenarios where application whitelisting makes sense:
The truth is that whitelisting isn’t a security panacea, and has to fit into a larger security landscape within your organization. You’ll still need anti-malware, endpoint protection, and perimeter defense systems to protect computers for which whitelisting isn’t appropriate, or to catch what whitelisting misses.
Most commercial operating systems have some whitelisting functionality built in, including Windows 10 and macOS. App stores, of the sort used to install applications on iOS and Android devices, can be seen as a form of application whitelisting; they ostensibly only allow applications that are certified to be safe. Most mobile management software allows more granular controls.
But there are third-party vendors who offer more powerful or more granular application whitelisting software, which is often rolled into larger offerings or security suites. Popular examples include:
A last note here on two other contexts where you might see the word “whitelist” used in IT security: e-mail and IP addresses. In these areas, whitelisting doesn’t have quite the same meaning as it does with application whitelisting: obviously if you only allowed a narrowly defined list of email addresses to contact you, or computers from a specific list of IP addresses to reach your website, you would lost most of the utility of having a website or using email.
In these contexts, “whitelisting” generally means taking manual steps to ensure that a certain IP address isn’t blocked from accessing your site by some automated security process, or ensuring that email from a particular recipient doesn’t go into your spam folder. The latter is of course an obsession of email marketers, who are keen to share instructions on how to whitelist email addresses to make sure that their own email doesn’t get deemed spam. The former is a product of overzealous firewalls, which can sometime result in people being unable to access their own websites.
This story, “Whitelisting explained: How it works and where it fits in a security program ” was originally published by
Josh Fruhlinger is a writer and editor who lives in Los Angeles.
Copyright © 2020 IDG Communications, Inc.