I'm trying to control the applications that people in my organization run for the sake of security. Is there a centrally-managed way to do this in Windows 7?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Before Windows 7, you could restrict programs through software restriction policies. These policies used Group Policy Objects to "fingerprint" allowed applications so that only programs designated safe by the administrator would work. Many programs in the Windows XP and Vista eras needed administrator privileges to function properly. This constituted a security risk, and software restriction policies were a way to cut down on the attack surface created by such programs.
Microsoft took many of the concepts in software restriction policies and rolled them into a new feature in Windows 7 called AppLocker. While AppLocker has the same basic premise as software restriction policies, it also offers a slew of features and functional changes that make it easy to manage and deploy.
AppLocker's rules and regulations
With AppLocker, an admin can define a set of rules about a given program, including its file name, its internal name (i.e., the product name), its revision number, its publisher, a hash code generated from the file, or some combination of those pieces of information. These rules can then be enforced by a user or group.
More advice from our Windows expert:
This allows you to set a rule as broad as "Trust all content signed by this publisher to this user group" to a rule as narrow as "Trust only Revisions 3.5 or greater of this program from this publisher to this particular user." The latter might be useful if you've been informed that versions earlier than 3.5 have security problems, even when running as a non-admin user. Exceptions can also be set for rules so that you can exclude a given file or folder from the actions of a particular rule.
In addition, AppLocker works in audit mode, a setting that can be applied so that rule enforcements are logged to AppLocker's event log but not actually enforced. This lets you to see the outcome of a particular rule without risking the behavior of a live system or having to set aside a "guinea pig" system for testing.
Another feature that saves time on creating rules is the rule-generation wizard. This wizard scans a directory hierarchy and automatically generates rules for all the programs in that directory. Those rules can be based on a publisher's signature for the program or, failing that, either the file hash or pathname for the application.
Furthermore, AppLocker adds management features that software restriction policies didn't have, such as PowerShell scripting support or the ability to import/export policies.
Possible AppLocker gotchas
AppLocker has a few caveats. First, the feature only works with Windows 7. If you have Vista or XP machines in your organization, you'll need to continue using software restriction policies. On the plus side, any expertise you built up with software restriction policies will remain valuable if you're in a mixed-OS environment.
AppLocker policies need to reflect how things work in your organization. For example, if you allow removable drives to be attached to your computers and you expect applications to be run from those drives, it might be more realistic to restrict software by hash rather than by pathname, since pathnames for attached drives can change a great deal. If you don't allow removable drives, then it makes sense to restrict by pathname or hash plus pathname.
A feature that AppLocker supports is the ability to create rules based on dynamic-link libraries (DLLs) as well as executables. This rule is off by default because it can be difficult to create the rules for it -- you might not list all the DLLs needed for a given application, especially if they're scattered across multiple directories. It's also a performance burden because each DLL has to be checked when it's loaded. This function grants more security -- i.e., it could prevent an application from loading unwanted third-party components -- but it should only be used if you don't have a choice in the matter.
Finally, one thing that software restriction policies had that AppLocker does not is the ability to restrict software based on registry paths. Since the two can run side by side, however, it is possible to set up software restriction policies in one set of Group Policy Objects and AppLocker policies in another and apply them as needed to cover any corner cases that might arise.
ABOUT THE AUTHOR
Serdar Yegulalp is editor of the "Windows Power Users Newsletter." Check it out for the latest advice and musings on the world of Windows network administrators.