Unlike some of my counterparts here at eWEEK, I am among those who think application whitelisting is definitely an interesting idea whose time has come for greater exploration in the enterprise. But administrators don’t need to buy into the concept over the whole enterprise, as there are places where it makes more sense – particularly from an ease of administration perspective. But with the right tools and the right plan, whitelisting is feasible.
A few vendors are already doing application whitelisting for enterprise customers with some interesting results. For instance, I reviewed Bit9’s Parity earlier this year and found it to be a pretty compelling product that just needed a little more polish. What I liked most about the product, however, were the tools Bit9 had created to identify and vet applications on the Web. Their ParityCenter and FileAdvisor services actively acquire software from the Web, determining who signed the file and scanning it for malware – then placing the code found into buckets of unsafe vs. safe applications, thereby giving administrators a frame of reference to base policy decisions upon.
Also, Lumension (formerly Patchlink, which bought SecureWave) has been mining the whitelist area for awhile, teaming it with excellent port blocking controls, something Bit9 has also improved upon in their latest version.
If other vendors with more clout and more resources (like Symantec) want to get into the practice of vetting and giving a seal of approval (for whitelisting purposes) to applications – rather than just finding and IDing malware – then I see that as a good thing for the security industry. Since their automated tools are undoubtedly already culling and examining “good” code anyway in their sweep for bad code, an actionable list of that “good” code would be easy to produce and could lead to much more secure computing environments for those willing to take the leap to whitelisting.
With some tools and technology already out there to do whitelisting, and it is up to the administrator to decide if and where such a technology would be best utilized. For instance, application whitelisting is absolutely intriguing when we are talking about servers. If you have a virtual server farm, with each instance performing a limited, core set of functions, why not whitelist? You already know what should be on there and you want to prevent anything else from running.
On the desktop, obviously the argument for application whitelisting is more complicated, as various deployments will stray mightily from the golden image when you account for all the different task-specific permutations of applications that are necessary to do this job or that. In our Bit9 test, I found it easier to deploy whitelisting with fresh systems rather than on an in-place desktop or laptop fleet, due to the large disparity of configurations.
But when beginning the project from a known starting place, whitelisting can be a fine complement to a Least Privileged User configuration. Administrators can then adjust whitelist policy, by knowledge-group, to adjust for the different approved applications needed for workers to do their jobs – whether these applications are bought, open-sourced or homegrown.
The big question with application whitelisting should instead rest on who ultimately has control over the list. If an AV vendor like Symantec – or a security software company like Bit9 or Lumension – rules the whitelist with absolute authority, then no, whitelisting will not work. But if the IT administrator has the flexibility to adjust the whitelist, along with the tools to identify differing applications and adjust policy accordingly, then I think whitelisting is a feasible approach.
