From user-installed greyware to drive-by Trojan downloaders, a shocking percentage of business PCs are plagued with unwanted applications. With Windows 7 AppLocker, Microsoft fires another salvo in the ongoing battle to secure business PCs by limiting the programs they run. In part one of this two-part technical tip, we will explore how AppLocker differs from Windows XP/Vista Software Restriction Policies and how to define AppLocker rules.
APPLICATION BLACKLISTS HARD TO DEFINE
The desire to block execution of unwanted or unknown applications is nothing new. For years, admins have searched to strike a workable balance between desktop security strength and flexibility, effectiveness and maintainability.
Stripping administrative privileges from end users has met with mixed success ...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.co.UK
and does nothing to block non-business programs that do not require privileges to run. Brute force techniques such as verifying each program's cryptographic hash prior to execution kick off an endless race to keep up with software patches, but easily maintained approaches such as blocking greyware based on registry key or filename/path are trivial to circumvent.
These reasons are why few admins bother with Windows XP/Vista Software Restriction Policies (SRP). Businesses that do use SRP usually develop blacklists: Group Policy Objects (GPOs) that block known malware based upon source network zone, path name, hash or signed certificate. Specifically, SRP rules override a defined default security level by removing restrictions (if the default is "disallow") or adding restrictions (if the default is" unrestricted"). However, because robust SRP rules are hard to define, most businesses default to "unrestricted," giving any program not explicitly disallowed a free pass.
APPLOCKER ENCOURAGES WHITELISTING APPLICATIONS
Microsoft's replacement for SRP is AppLocker, now available in Windows Server 2008 R2 and Windows 7 Enterprise and Ultimate editions. For backwards compatibility, GPOs can include both SRP and AppLocker rules. In such cases, AppLocker rules are only applied to PCs running Windows 7, while SRP rules are only applied to older PCs.
Like SRP, AppLocker can allow or deny program launch. However, AppLocker turns policy definition inside out by imposing a default "disallow" stance. After you start the Application Identity (AppID) service and apply even a single AppLocker rule, any program not encompassed by AppLocker rules will fail to launch, displaying the message: "The program is blocked by group policy."
In this way, AppLocker strongly encourages businesses to define whitelists rather than blacklists. Although AppLocker whitelists still require maintenance, they make it easier to reliably identify all of the programs you wish to permit than to exhaustively identify all unknown and potentially harmful programs that wish to block. To understand why, let's look at how AppLocker rules are defined.
HOW APPLOCKER RULES ARE DEFINED
SRP rules apply to all users (or all but administrators), but every AppLocker rule must be bound to specified users or groups, making it easier to assemble a collection of coarse and fine-grained rules to meet business needs. Most admins will start with a few coarse AppLocker rules that apply to everyone and then fine-tune with rules that permit "typical user" programs with very selective exceptions.
SRP rules were based on methods that were easily bypassed, too limited for practical use, or too difficult to maintain. AppLocker drops two of those methods, extends the most useful method, and strikes a better balance between effectiveness and maintainability. Specifically, AppLocker rules allow or deny program launch based upon three methods: publisher rules (recommended), hash rules (for programs without signatures), and path rules (as a last resort for everything else).
Publisher Rules allow or deny program launch by checking digital signatures found on signed executables (exe files), installers (msi and msp files), scripts (including batch, javascript and VBS files) and libraries (dll files, eventually). A publisher rule is created by browsing to a reference copy of the program that you wish to allow or deny. The rule then is auto-populated with values obtained from that program's signature: software publisher, product name, filename and (file) version. Finally, a slider is used to adjust rule granularity -- enabling anything from denying all programs by a given publisher to allowing a minimum version of an individual product. As a result, publisher rules are far more flexible and can be applied to many more programs than SRP certificate rules.
Hash Rules can check the cryptographic digest for any program file against a fingerprint previously generated for that file, independent of its name or location. But unlike SRP hash rules, AppLocker can apply hash rules at a per user/group level, with specified exceptions. Although hash maintenance is still a headache, AppLocker reduces overhead by recommending hash rules only for programs that lack usable signatures.
Path Rules check a program file's actual location (local folder, network path) against a required path specification. This method is also used by SRP, but AppLocker path rules are considered a last resort, only for programs where publisher or hash rules would be too onerous or difficult to apply. A good example of a path rule is a one that allows everyone to execute any program in the Windows directory. Assuming that your end users don't have permission to add files to that directory, this is a safe-but-easy way to give everyone permission to run the operating system.
Finally, unlike SRP rules, every AppLocker rule can include specified exceptions. This tweak alone makes it much easier to enforce real-life security policies that so often apply to most (but not all) groups or users. However, note that AppLocker rules can only be applied to (or exclude) groups and users, not Internet zones or individual computers.
Lisa Phifer is vice president of Core Competence Inc. She has been involved in the design, implementation and evaluation of networking, security and management products for more than 25 years, and has advised companies large and small regarding security needs, product assessment, and the use of emerging technologies and best practices.
