The good, the bad, and the ugly of user software installation

User installed software is a huge focus area for nearly every organization today due to a multitude of reasons including:

• Unlicensed software installation, which is a liability for the organization
• Software that contains spyware and malware
• Software that is not compatible with the rest of the organization
• “Time wasting” applications (this does not include Internet Explorer ) such as digital music software, social media software, instant messaging
• Security vulnerabilities exposed through unapproved software
 
When we look at how to control the installation of applications, snap-ins, add-ins and anything else that ends in “ins” by users we really have 3 options available to us and you may find you use a combination of the technologies available.

The first option is to simply lock down the desktop thoroughly by making sure users are not local administrators and block the user’s ability to install anything. This sounds like the perfect answer and solves many challenges however just blocking the user from installing anything is likely to result in a very unproductive user, even more unproductive than if you let them install their digital music and social media applications. Different users need different applications and so blocking users from installing what they need to do their job is not really an option. If we take the locked down approach we need to make sure every application and “-in” that may be needed by anyone in the organization is available through the organization’s software deployment solution such as System Center Configuration Manager from Microsoft. This approach requires a lot of management to ensure every possible application is available through the deployment solution and since this packaging takes time it will likely slow down the ability for applications to be available to the employees. Additionally many applications are not in a position to lock down the desktop so thoroughly.

The next option is to not fully lock down the users’ desktops and allow them to install applications but to block specific bad applications or publishers of applications. This again sounds like a nice option, however I always think back to a great episode of Malcolm in the Middle, Lois vs Evil, which if you’ve not seen it is basically a Mum (I’m English, I can say Mum not Mom) who works in a pharmacy and has three sons who are always getting in trouble. They come to visit her at work and she goes through this huge list of what they mustn’t touch, mustn’t do, mustn’t say then leaves them on their own for 5 minutes while she finishes her shift. As the camera pans to Lois we see her running through the list of things she told them not to do and then panic as she realizes she forgot about the new steam cleaner with hyper forming-action. She dashes to the steam cleaner and sure enough the boys are wrestling with each other, foam coming out of their clothes, covering the entire store. I think of blocking specific applications the same way; we may block most of the bad applications but we only need to miss one, and remember new bad ones are coming out all the time, and our desktop environment is exposed and compromised.

The final option gives us the best flexibility for our users and the best security and that’s to whitelist applications. With whitelisting, every application is implicitly blocked and we explicitly allow the applications we want to allow users to install and use. We don’t have to package the applications and make available through the organizations software deployment system, we just need to basically say “yes, that application can be used” which allows new applications to be made available to the users very quickly. Whitelisting can work in different ways. We can say “this specific application version x from vendor y is allowed”, we can say “any version of application x from vendor y is allowed” or even “allow any application from this vendor”. We may create a template machine with all the different software packages we commonly use and tell the whitelisting solution that anything on that template machine is allowed which really simplifies creating the initial whitelist rules. We may allow any application that sits within a certain path such as c:Windows is generally pretty important! With the right whitelisting solution we enable users to run the applications they need while blocking the bad applications and giving us a first line of defense against malware and spyware from getting to the machines (but you should still run malware/spyware protection software, always defense in depth!).

I’m not going to say who was bad and who was ugly, but whitelisting is definitely the good and as I’ll dive into in the next blog post it gives us not just great flexibility while protecting the users and the enterprise but really can be a single solution across our whole environment.