Microsoft happily admits that its current approach to restricting unauthorised software in desktop environments has some flaws. Will the new AppLocker software built into Windows 7 help fix those problems?
Apart from the elementary step of not allowing users administrative privileges, Microsoft has relied on software restriction policies (SRPs) to eliminate unwanted software within standard operating environments since Windows XP and Windows Server 2003. Those policies define either a specific set of applications which are allowed, blocking all others, or identifies specific programs that should never be allowed to run.
However, that approach has some obvious disadvantages. The system largely relies on blocking specific versions of programs, which can create problems with rapidly changing packages or if a company wants to block older versions of an approved application. And as Microsoft's own support documents point out, not all the settings are particularly obvious are comprehensive (the system can restrict MSI files accessed within an Internet zone but not executables, for instance).
All of that means that SRPs tend to be something of a blunt instrument when trying to maintain a secure SOE. "Our software restriction policies weren't that flexible and didn't let us do a hell of a lot," said Jeff Alexander, IT pro evangelist at Microsoft Australia. "That presents a headache for IT departments."
Windows Vista enhanced desktop security in a general sense by restricting the ability of even administrative users to run installation scripts through its User Account Control (UAC) system. However, Windows 7, which is scheduled for release on October 22, takes a rather more comprehensive approach to desktop lockdown via AppLocker,
"AppLocker is a Windows 7 solution that allows you to eliminate known and unknown threats," Alexander said. The feature has been part of Windows 7 since the earliest public builds.
Rules in AppLocker are effectively built up using a combination of allow, deny and exception policies. While SRP tended to rely on blocking a single executable (identified either by name or file hash), AppLocker can be used to restrict applications to a single version (only allowing version 9.1 of Adobe Reader) or a version range (allowing version from 8.0 onwards, or not allowing versions after 6.0, for instance.)
AppLocker can also query the publisher signature information embedded in executables, allowing applications to be restricted to approved or registered publishers. (However, such a policy might require frequent tweaking, as most small open source publishers and many larger companies still appear as 'Unknown' within the Microsoft hierarchy as they're not registered with the organisation.)
AppLocker will feature in the Enterprise and Ultimate versions of the Windows 7 release. While such features could also be useful in smaller business environments, Microsoft is not offering AppLocker as part of the mass-market Professional installation, a decision that parallels its failure to include BitLocker drive encryption on those versions of the OS either.
In environments running Windows Server 2008, group policy can be used to set security policies, drawing on whatever Active Directory attributes are deemed relevant. While policies can be set individually via the GUI, Alexander says that importing pre-defined policies will be the most common management approach in larger enterprise environments.
PowerShell can also be used to query and alter AppLocker settings, providing the option of automating policy management in this areas. As Microsoft's PowerShell blog points out, this makes it possible to (for example) set up a policy to enable a specific program with a single command line entry, as well as run queries to determine which policy is responsible for blocking a particular application.
Despite a generally enthusiastic reception compared to its predecessor, Windows 7 is unlikely to be widely deployed in enterprise environments for some time after its release. As deployment testing becomes more widespread, pre-baked AppLocker policies and scripts should also become more prevalent.