Read this article on DarkReading.com about whitelisting of applications. I like this point:
But whitelisting has a down side. These endpoint tools come with plenty of administrative overhead as well as security risks. “The institutional overhead in maintaining them is extreme,” says Thomas Ptacek, a researcher with Matasano Security. “Some poor group of souls in IT is charged with deciding which applications every sales person or project manager can run, and has to backstop all the ensuing arguments.”
What are the pros and cons of application whitelisting, and where do I stand?
First, when machines are imaged or supported by IT, they should have a list of applications that need to be loaded for new hires or replacement machines.
They should also have a list of applications to expect, that IT may or may not have to provide at least a little bit of support for (yes, we’ll help you with Outlook, no we won’t help you with Alefox or IE toolbars). Related to support, security persons responsible for keeping up to date on patches need a list of applications they should be checking. IT should not be expected to be knowledgable on patches for every toolbar app that may be used in the corporate environment.
Additionally, disaster recovery may require knowledge of what is necessary for groups such as sales people to do their jobs.
Much like firewall rules, default deny with a whitelist of allowances is much easier to maintain than a blacklist. You can blacklist categories of applications (P2P, IM, etc), but even those lines continue to blur. However, we already do see lines blurring in those categories.
Take this scenario. Sales requests a new application on their machine. Those “poor souls” in IT then have to research it and either add it to the whitelist or explain why it should not be allowed. With strong policies and management support of policies, this might be ok, but I believe most companies will put those “poor souls” in the unfortunate position of either saying “yes” to requests or being in a hard place when trying to say, “no.” The end result is wasted resources, unnecessary negative feelings towards IT by the sales group, and overall less authority. What if the sales group has already been using the application for 4 months? Those “poor souls” really are poor souls.
(Honestly, those “poor souls” need to be backed heavily by a manager-level person, otherwise anyone smart enough to do proper evaluations and even backstop the ensuing arguments is not going to be in this sort of a position for very long.)
And what if each department is asked to create such a whitelist of programs that are needed? I’ve seen managers throw back every single program they can think of, whether it is really necessary or not. “All of them.” Many managers and business users do not care to be bothered by such things, but will detest IT making the decisons for them.
As long as users run Windows, run as Administrator, and all sorts of things want to get installed or used (some even as benign as a proprietary web player like Flash or similar), trying to maintain a whitelist of programs that are necessary is difficult.
Whitelisting will stifle innovation and the ability to try out new applications and tools.
So, where do I stand in all of this?
I think some whitelisting is necessary, but it cannot end up being heavy-handed unless the company has some serious security requirements, small niches for their computer use, or is a majorly large network where application management is nearly impossible. IT certainly needs to maintain a list for proper imaging and support of workstations.
This goes back to what I said in my previous post: less rules.
Less rules. Smarter rules. Better mitigation, response, tracking. Better perception of organizational IT. Let people, within reason, do as they wish on their workstations in order to have a productive, happy life with the company.