Geek of all Trades
AppLocker: IT’s First Security Panacea?
There’s a long-standing saying in our industry that nothing is a panacea. Defined as a “remedy for all diseases, evils or difficulties,” the oft-offered but neverrealized panacea would represent the IT solution to end all solutions.
It's conventional wisdom that no single product can ever fully offer you that one-stop fix for all your problems, no matter how hard that product's salespeople might try to convince you otherwise. Yet in exploring the new AppLocker functionality in Windows 7 and Windows Server 2008 R2, I have to wonder whether Microsoft has gotten close.
To fully understand the power of AppLocker, think about the basics of maintaining system security. Malware is a constant threat. Whether it infects your systems through an Internet browser or is pushed via a worm-style attack, it sometimes overwhelms even the best firewalls and anti-malware engines. Further, even with a layered approach to security in your environment, the combination of these tools can never be prepared for that dreaded zero-day attack.
Yet there's one common thread among virtually all pieces of malware: Its code has to be processed for it to damage your systems.
This single point raises the question for administrators: "If virtually all malware requires processing to be dangerous, could I protect myself by preventing that processing from occurring in the first place?"
The answer: Absolutely. And the solution for that problem is AppLocker.
AppLocker has its roots in the Group Policy technology called Software Restriction Policies (SRP), which debuted with Windows XP and Windows Server 2003. SRP introduced the concept of blacklists and whitelists in relation to disallowed and allowed executables in a Windows domain. The concept is simple:
- With a blacklist, you, the administrator, identify the specific executables that are disallowed from executing on computers in your domain. At the time of launch, processes are verified against the blacklist before being executed. If a process is on the blacklist, execution is prevented and the user is instead presented with an error message.
- With a whitelist, the opposite becomes true. Using a whitelist, you instead specify the processes that are allowed to run on your computers. Launched processes are verified against the whitelist before execution. Only those on the whitelist are allowed to run; those not on the whitelist are prevented from being executed.
With SRP, either of these two paradigms was possible, with the default focusing on the blacklisting of applications. Over time, however, it became obvious that the whitelisting concept could be dramatically more powerful. While whitelisting involved more work because each and every application approved to run had to be entered into the policy, it was a potent method for preventing everything else.
In effect, by leveraging SRP's whitelisting paradigm, an environment could specify which applications had been tested, verified and approved by its administrators and security policy. Everything else—including most forms of executing malware and other quasi-legitimate apps not approved by IT—would be explicitly denied execution. No processing, no malware, no infection.
But while simple in concept, SRP's technology was painful in implementation. Despite all its power, SRP was implemented by only a very few environments. Determining the exact set of acceptable applications was a painful and complex process with little automation support. Making even a small mistake in an SRP Group Policy could mean the prevention of all software execution in the domain. Too risky and too administratively complex in its configuration, SRP rarely made it onto most environments' radars.
AppLocker: More Than SRP Version 2
AppLocker's technology is intended to increase adoption levels by incorporating better management functionality. Integrated much more tightly into the Windows 7 and Windows Server 2008 R2 operating systems, AppLocker leverages SRP's concepts to create a more useable solution.
The first way in which AppLocker improves over SRP is through the addition of an Audit Only enforcement mode (see Figure 1). In this mode, configured computers and executable rules only report where violations of policies take place. By combining AppLocker's Audit only enforcement mode with an empty whitelist, it's possible to quickly identify the types of applications that are being run on computers across the domain. With audit information being deposited into each computer's AppLocker event log, details on those applications and their executables can be documented for later enforcement.
Figure 1 AppLocker in Audit only mode. (Click the image for a larger view)
A second mechanism improves rule creation through an automated wizard. Found in AppLocker's Group Policy console is a selection to Automatically Generate Rules (see Figure 2). This option launches a wizard that will scan any file structure on a reference computer, looking for executables. Any executable found in the assigned path or its subfolders can have a rule automatically generated for it. Pointing this wizard toward a reference computer with your environment's common software installed automatically generates a list of rules. That list can be used as your starting point for later customization.
Figure 2 AppLocker Automatically Generate Executable Rules Wizard (Click the image for a larger view)
AppLocker also simplifies rule generation by reducing the number of rule classes to three. They're designed to be used in combination, and you'll find that each rule class provides a different approach to limiting software execution:
- Path Rules create a restriction based on the name or location of the executable's file. For example, a Path Rule can be created for a particular filename (sol.exe) or a combination of filename and wildcard (sol*.exe) to capture limited modifications to a filename. Wildcards can also be used in combination with file paths (%PROGRAMFILES%\Microsoft Games\*).
- File Hash Rules are created to overcome some obvious limitations with Path Rules. Using a Path Rule, an executable can be accessed by moving it out of a managed path or by sufficiently altering its filename. Using a File Hash Rule, a cryptographic hash of a managed file is created. Basing rules off of file hashes means that they remain managed no matter where they're located on the system. While this increases the security of the overall solution, its downside becomes obvious as files change over time due to patches or updates. For that reason, using File Hash Rules requires additional due diligence as software is updated.
- Publisher Rules require that the managed executable is digitally signed. That digital signature enables the file to be restricted based on its publisher, product name, filename and file version. A sliding scale and custom value option gives you the ability to adjust which characteristics you care about and which are optional. For example, it's possible to restrict a file based on its publisher, product name and filename while setting a wildcard for the file version (see Figure 3). The net result: Any later version updates to that file are automatically approved.
Figure 3 Creating and customizing a publisher rule. (Click the image for a larger view)
A final useful addition is the ability to create special exceptions associated with any rule class. These exceptions enable a further definition of which executables are allowed for execution, as opposed to which are prevented. For example, you may allow the execution of any executable in the %PROGRAMFILES%\Microsoft Office\* folder, but specifically prevent WINPROJ.EXE due to licensing restrictions or other reasons.
Because AppLocker settings are typically created via Group Policy, the assignment of execution-prevention rules can be focused on the computers in your environment or the individual users. Inside the Group Policy Management Editor (GPME), AppLocker settings that are defined for computers are in the location Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies. Those defined for users are in the same location under User Configuration. As such, any combination of user and computer-focused configurations can be made based on the application of Group Policy. Policy-merging is additive, meaning that Group Policy won't override or replace rules already present in a linked Group Policy Object (GPO). Rules assigned via Group Policies will apply using the same application order as traditional GPOs.
Right now, AppLocker's main limitation is related to the OS versions that will enforce its rules. At the client side, only Windows 7 Ultimate and Windows 7 Enterprise can participate in AppLocker rule enforcement. For servers, any edition of Windows Server 2008 R2 except for Windows Web Server and Windows Server Foundation will enforce AppLocker rules. While Microsoft may back-port this functionality into earlier OS versions, this feature currently adds to the list of compelling reasons for a Windows 7 upgrade. (At this writing, no information has been released about a possible back-port to earlier OS versions.)
One piece of good compatibility news: AppLocker's Group Policy foundation requires no upgrade of domain controllers (DCs) to support the distribution of its policies. Existing Windows Server 2003 and Windows Server 2008 DCs can host AppLocker policies.
A Simple Deployment of AppLocker
If AppLocker's added security sounds useful to your small environment, your next steps involve implementing the solution. Obviously, implementation won't happen until you've upgraded a sizeable percentage of your desktops and laptops to Windows 7. Operating systems prior to Windows 7 and Windows Server 2008 R2 won't apply AppLocker rules, but they will respect those applied through SRP. While SRP and AppLocker rules aren't directly convertible, the information you gather through AppLocker's Audit Only mode can be manually converted for use in SRP.
Deploying AppLocker involves multiple steps, beginning with determining how to implement the technology and creating a reference computer for isolating your starting set of applications. Remember that, unlike SRP, AppLocker defaults to the assumption that you'll be creating a whitelist of applications. While creating a blacklist architecture is possible, doing so isn't recommended simply because that approach doesn't provide the same execution-prevention power offered by whitelists.
In its document titled "Planning and Deploying Windows AppLocker Policies
," Microsoft outlines a nine-step process for implementing AppLocker in an environment. While this document is in beta at this writing, the currently available version includes significant detail on how to properly build a complete AppLocker infrastructure. For simplicity's sake, however, here are a few steps that you need to get started.
First, create a list of applications that your IT organization considers acceptable for execution. You can create this list manually by interviewing application owners in your organization. Or you can begin by creating and interrogating a reference computer containing the commonly available applications in your business. Start that process by building the OS instance—or imaging it using your favorite image-deployment solution—and ensuring that the right applications are installed. Onto this computer, you should also install the Remote Systems Administration Toolkit (RSAT) for Windows 7, which can be found on the Microsoft Web site. The RSAT includes the GPME components necessary for creating AppLocker Rules.
When ready for analysis, create a new GPO and launch it within the GPME. Navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies | AppLocker and click the link in the right pane for Configure Rule Enforcement. In the resulting window, check the box marked Configured under Executable Rules and set the rule to Audit Only. This setting maintains your existing behaviors on managed systems while reporting AppLocker rule violations to the local event log.
You'll notice that this window has an Advanced tab, within which you can choose to Enable the DLL rule collection. AppLocker has the ability to create rules based on DLLs in addition to executable files. While you can implement this setting for added security, doing so will add an extra administrative burden because you'll need to isolate and configure rules for all DLLs in your environment in addition to executable files. Because an executable file can leverage multiple DLLs, that task can be a management headache. Enabling DLL rule collection also will impact system performance because the processing of each DLL will require validation prior to execution.
Your next step is configuring the default set of Executable Rules. Right-click the AppLocker sub-node of the same name and choose to Create Default Rules. Three rules are created by default. Two allow the execution of all files in the Windows and Program Files folders, while the third (shown in Figure 4) allows members of the local Administrators group to run all applications. This third rule effectively excludes local Administrators from rule processing.
Figure 4 Default rule excluding local administrators from execution prevention. (Click the image for a larger view)
Once that's complete, right-click the Executable Rules node again and choose to Automatically Generate Rules. This wizard will interrogate the local machine for potential executables for rule creation, which is why it must be run on the reference computer. By default, the wizard will check for executables in the C:\Program Files path, although alternate paths can be checked by editing them in the wizard's options.
Clicking Next in the wizard takes you to the Rule Preferences screen. Here, you have the option to create Publisher Rules for files that are digitally signed or to create Hash Rules for all files. Path Rules can be automatically created in this screen, but only when files haven't already been digitally signed by their publishers. Clicking Next again completes the system scan and takes you to a screen where you can review the list of rules. Rules that you don't wish to create can be eliminated by clicking the link to review the files that were analyzed, then deselecting the check box next to the appropriate files. Once that's complete, click Create.
Completing this task on a freshly built Windows 7 system adds four new rules. Although quite a few more executable files are found in this location, the wizard will by default group together rules to simplify their application. At this point, if you feel like monitoring for other executable types, it's possible to configure rules for scripts and Windows Installer-based executables in this same GPME location.
At this point, the GPO will begin configuring targeted clients based on OU membership. Because the rule-enforcement policy is set to Audit Only, no execution restriction will actually occur. During this period, it's a good idea to look through the event logs on various managed systems to see whether your rules are working for your environment or whether their application would prevent a necessary executable from running. Use that information to tweak your existing set of rules so that they function correctly for your environment.
When you're ready to move from reporting on executables to actually preventing them, just navigate back to the AppLocker node in the GPME and change the enforcement properties from Audit Only to Enforce Rules.
Obviously, you'll need more project planning and testing prior to deployment. But these simple steps will get you started. While AppLocker may not be the complete security panacea, its abilities to prevent all but your absolutely approved executables from running means that it comes really, really close.
MVP, is a partner at Concentrated Technology. Get more of Shields' Geek-of-All-Trades tips and tricks at ConcentratedTech.com