Windows in some organizations is a free-for-all -- users have local administrator rights, install software to their hearts' content, never update it and generally are susceptible to running bad stuff on good machines. Fortunately for Windows administrators, there is a way to stop that.
Controlling what applications run in your environment sounds like a herculean effort, and make no mistake -- it is a lot of work. Setting up policies that restrict software installation and execution, and using the tools that make that possible, is not just a "check and refresh" type of administrative task. It takes trial, some error, most likely a pilot, and then a gradual rollout. But once you get on the other side, you experience benefits including:
- Malware being virtually eliminated. Applications that you do not approve, or whitelist, simply fail to execute.
- A reduction in desktop support issues related to users installing noncompany-approved applications, like iTunes and Dropbox.
- Enhanced protection against data leakage, since users cannot circumvent other security policies by using applications that, for example, do not recognize Group Policy settings.
Software restriction policies
Software restriction policies (SRPs) allow you to control the execution of certain programs through the use of Group Policy. In addition to enabling SRPs in your existing environment, it's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or download Internet applications and utilities.
These policies are powerful, but as I mentioned at the start of this piece, it's not without some work: Putting SRPs into place can really lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs.
It can also step on the toes of any user log-on scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, a bonus tip: When you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's access control list and explicitly deny the Apply Group Policy permission to the GPO; this will enable an administrator to reverse the policy and not lock herself out.
Once you're ready to create the policy, follow this procedure:
Microsoft describes AppLocker as "a new feature in Windows Server 2008 R2 and Windows 7 that advances the features and functionality of Software Restriction Policies. AppLocker contains new capabilities and extensions that allow you to create rules to allow or deny applications from running based on unique identities of files and to specify which users or groups can run those applications."
Put simply, AppLocker is the SRP feature on steroids. Perhaps its two best features are the ability to automatically build rules based on currently installed software, and the ability to run AppLocker in what is called "audit only" mode. This shows what software would run and what would be blocked without forcing you to actually enable the policies. It is a great setting for initial setup and troubleshooting scenarios.