Application whitelisting in Windows 7 and Windows Server 2008 R2

Microsoft's AppLocker, the application control feature included in Windows 7 and Windows Server 2008 R2, is an improvement on the Software Restriction Policies (SRP) introduced with Windows XP Professional. AppLocker allows application execution rules and exceptions to them to be defined based on file attributes such as path, publisher, product name, file name, file version, and so on. Policies can then be assigned to computers, users, security groups, and organizational units through Active Directory.

Reporting is limited to what can be pulled from log files, and creating rules for file types not defined in AppLocker can be difficult. But AppLocker's biggest drawback is that it's limited to Windows 7 Enterprise, Windows 7 Ultimate, and Windows Server 2008 R2 clients. Windows 7 Professional can be used to create policy, but cannot use AppLocker to enforce rules on itself. AppLocker cannot be used to manage earlier versions of Windows, although both Windows XP Pro's SRP and AppLocker can be similarly configured to affect an enterprise-wide policy.

[ Read the Test Center review of application whitelisting solutions from Bit9, CoreTrace, Lumension, McAfee, SignaCert, and Microsoft. Compare these application whitelisting solutions by the features. ]  

AppLocker can be configured locally using the Local Computer Policy object (gpedit.msc) or using Active Directory and Group Policy Objects (GPOs). Like a lot of Microsoft's latest Active Directory-enabled technologies, administrators will need at least one domain-joined Windows Server 2008 R2 or Windows 7 computer to define and administer AppLocker. Windows 7 computers will need the Group Policy Management console feature installed as part of the Remote Server Administration Tools (RSAT) for Windows 7 (a free download). AppLocker relies on the built-in Application Identity service, which is normally set to manual startup type by default. Administrators should configure the service to start automatically.

Within the local or group policy object, AppLocker is enabled and configured under the \Computer Configuration\Windows Settings\Security Settings\Application Control Policies container [screen image].

By default, when enabled, AppLocker rules do not allow users to open or run any files that are not specifically allowed. First-time testers will benefit by allowing AppLocker to create a default set of "safe rules" using the Create Default Rules option. The default rules allow all files in Windows and Program Files to run, along with allowing members of the Administrators group to run anything.

One of the most notable improvements over SRP is the ability to run AppLocker against any participating computer using the Automatically Generate Rules option [screen image] to quickly generate a baseline set of rules. In a few minutes, dozens to hundreds of rules can be created against a known clean image, saving AppLocker administrators anywhere from hours to days of work.

AppLocker supports four types of rule collections: Executable, DLL, Windows Installer, and Script. SRP administrators will notice that Microsoft no longer has the registry rules or Internet zones options. Each rule collection covers a limited set of file types. For example, executable rules cover 32-bit and 64-bit .EXEs and .COMs; all 16-bit applications can be blocked by preventing the ntdvm.exe process from executing. Script rules cover .VBS, .JS, .PS1, .CMD, and .BAT file types. The DLL rule collection covers .DLLs (including statically linked libraries) and OCXs (Object Linking and Embedding Control Extensions, aka ActiveX controls).

If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However, when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are permitted to run. For example, if you create an executable rule that allows .exe files in %SystemDrive%\FilePath to run, only executable files located in that path are allowed to run.

AppLocker supports three types of rule conditions for each rule collection: Path Rules, File Hash Rules, and Publisher Rules. Any rule condition can be used to allow or deny execution, and it can be defined for a particular user or group. Path and File hash rules are self-explanatory; both accept wild card symbols. The Publisher rules are fairly flexible and allow several fields of any digitally signed file to be matched with specific values or wild cards. By using a convenient slider bar in the AppLocker GUI [screen image], you can quickly replace the specific values with wild cards. Each new rule conveniently allows one or more exceptions to be made. By default, Publisher rules will treat updated versions of files the same as the originals, or you can enforce an exact match.

An important distinction between AppLocker and so-called competitors is that AppLocker is really a service, a set of APIs and user-defined policies that other programs can interface with. Microsoft coded Windows and its built-in script interpreters to interface with AppLocker so that those programs (Explorer.exe, JScript.dll, VBScript.dll, and so on) can enforce the rules that AppLocker policies have defined. This means that AppLocker is truly a part of the operating system and not easily circumvented when the rules are correctly defined.

However, if you need to make a rule for a file type that is not defined in AppLocker's policy table, it can take some creativity to get the desired effect. For example, to prevent Perl script files with the .PL extension from executing, you would have to create an executable rule that blocked the Perl.exe script interpreter instead. This would block or allow all Perl scripts and require some resourcefulness to gain finer-grained control. This is not a unique issue, as most of the products in this review have the same sort of limitation.

AppLocker's configuration and rules can easily be imported and exported as readable XML files, the rules can be quickly cleared in an emergency, and all can be managed using Windows PowerShell. Reporting and alerting are limited to what can be pulled from the normal event logs. But even with AppLocker's limitations, Microsoft's price tag -- free, if you are running Windows 7 and Windows Server 2008 R2 -- can be a strong lure for up-to-date Microsoft shops.

This story, "Application whitelisting in Windows 7 and Windows Server 2008 R2," and reviews of five whitelisting solutions for enterprise networks, was originally published at InfoWorld.com. Follow the latest developments in information security, Windows, and endpoint security at InfoWorld.com.