Testing Microsoft’s Windows Application Whitelisting Tool

Recently, eWEEK Labs took at look at the emerging Windows security strategy of application whitelisting: the practice of identifying which applications are allowed to run on a system, rather than those that are not allowed to run.

For that package, we focused on add-on products that bring whitelisting capabilities to Windows, but it’s possible to implement whitelisting with out-the-box functionality that’s been available for Windows systems since the release of Server 2003.

The Windows feature, called Software Restriction Policies, or SRP, enables administrators to control whether applications and libraries are allowed to run on a Windows machine based on the path, digital certificate, hash or extension attributes of the executable in question.

SRP affords administrators less granularity in crafting these control schemes than do full-fledged application whitelisting products such as Bit9’s Parity 4.1 or CoreTrace’s Bouncer 4.0. What’s more, SRP doesn’t deal as well with change management as do these and other third-party whitelisting options.

However, as part of Windows, SRP doesn’t carry any additional licensing costs, and the tool works both with large networks of Windows clients (through Group Policy) and with individual Windows machines (through the local security policy). As such, SRP is well worth further evaluation for Windows shops interested in tightening security and doing more with less.

Looking forward to Windows 7 – the forthcoming version of Windows at which Microsoft recently gave the general public a peek – SRP will morph into something with the more marketing-friendly name AppLocker, which will come with a handful of worthwhile feature enhancements.

To put SRP to the test, I set out to lock down a test desktop running Windows XP Service Pack 3 in such a way that only applications installed in the program files or system directories would be allowed to run. When paired with a limited-rights user account (as opposed to an administrator account), this SRP tactic will prevent executables stored in user-accessible places from running, thereby reserving all judgments over permitted applications to administrators.

On the XP machine I sought to lock down, I ran the secpol.msc tool to modify my system’s local security policy. To make these changes through Group Policy, I would have used gpedit.msc. In the “Security Levels” folder within “Software Restriction Policies,” I clicked on “Disallowed,” entered its properties dialog and opted to make “disallow” my default on the system.

When I made this change, Windows automatically generated four exception rules for particular registry locations to prevent SRP from completely locking me out of my system. In addition to these, I added path-based rules that made my C:Program Files and C:Windows directories into free run zones.

I could have avoided granting this en masse permission to everything in my Program Files and Windows directories by calculating hashes of every application and library in those locations, but this approach could leave my system unusable in case of updates to those files. The new, patched applications and libraries would have different hashes than those they replaced, and as a result, the system would have prevented updated files from running.

I also adjusted the enforcement options to exclude administrators from enforcement and to include DLLs in my controls scheme – both of which differed from the system’s defaults.

Another place where I diverged from defaults was in removing *.lnk, the file type for Windows shortcut files, as a blocked file extension. Without this change, none of the shortcuts in my start menu would have worked.

After I made these changes, I switched over to a limited rights user on my machine and tried to run the Firefox Web browser I’d previously installed. The application fired up without a problem. I then tried to run a copy of the handy SSH (Secure Shell) client, Putty, from my desktop – a restricted location under my SRP regime – and, sure enough, Windows informed me that the application had been blocked by policy, and that the system had logged the attempt in the event logs.

To make this controls scheme work, I had to add a rule to allow Microsoft’s shortcut files, which are typically not installed in one of my policy-blessed locations, but are required for the Windows start menu to function properly. I made this adjustment with the extension-based controls.

Windows also offers the option of whitelisting libraries and applications based on the certificate with which they’ve been signed. This option can accommodate change more gracefully than does the hashing approach, as long as the files you wish to manage are actually signed. In Windows XP, few of the files that comprise the system are signed in this way, and many more applications, such as the Putty utility I mentioned above, also lack signatures. What’s more, I found the certificate controls for the current iteration of SRP awkward to use.

Fortunately, improved support for certificate-based software restriction policies is one of the enhancements that jumped out at me in the Windows 7 iteration of SRP, which will be known as AppLocker. AppLocker sports a new rules generation wizard that rolls up the different policy control types offered under previous SRP versions into a single process.

For instance, in order to allow all the applications and libraries under the Program Files directory of my test Windows 7 machine, I launched the automatic rulemaking tool, browsed to my Program Files directory, and selected the local users group as the set of users to be governed by my policy. On the next screen, Windows 7 gave me the option of creating certificate-based rules for all signed files, and of creating hash- or path-based rules for the unsigned files. I could also opt to create hashes of all files under Program Files.

The tool then told me how many files my new rule set would protect and how many rules the set would span, as well as offering me the option of reviewing the analysed files and the yet-unmade rules before clicking create. If I wished to exclude some of the analysed files from my policy, I could do so at this point.

Windows 7’s overhauled SRP also allows administrators to determine how tightly to control subsequent versions of a given application. For instance, an administrator could allow all versions of an application signed by the same publisher to run, or could allow only applications with a particular version number to run.

AppLocker also allows administrators to export or import rule sets – a nice option to have if you plan on reusing policies or wish to have the option of rolling a modified or deleted rule set to an earlier version.

Microsoft’s reworked SRP tools still have a few rough edges: AppLocker-specific help is nonexistent at this point, and the new AppLocker tools ride, confusingly, beside the old SRP-specific tools in Windows 7’s secpol tool. However, given that the version of Windows 7 I used for testing is the PDC prebeta build, I was impressed by the relative completeness of the tools.