Configuring Windows 7 (Training Kit) - Part 31 pdf

Lesson 2: Managing AppLocker and Software Restriction Policies CHAPTER 5 273
FIGURE 5-12 Software Restriction Policy security levels
Enforcement
You can use the Enforcement Properties policy, shown in Figure 5-13, to specify whether
Software Restriction Policies to all software files except libraries, such as DLLs, or all software
files, including DLLs. If the default level is set to Disallowed and you configure the enforcement
policies to apply to all software files, you need to configure rules for all the DLL files used
by a program to use that program. Microsoft recommends that you do not include DLLs
unless you are managing computers in a highly secure environment. This is primarily because
managing rules for DLLs adds significantly to the amount of work that an administrator has to
undertake to maintain Software Restriction Policies successfully.
FIGURE 5-13 Software Restriction Policy enforcement
You can use the Enforcement policy to apply Software Restriction Policies to all users or
all users except for members of the local administrators group. You can also use this policy
2 7 4 CHAPTER 5 Managing Applications
to specify whether certificate rules will be enforced or ignored. The drawback to enforcing
certificate rules is that it can degrade a computer’s performance significantly.
Designated File Types
The Designated File Types policy, shown in Figure 5-14, allows you to determine which file
extensions should be recognized as executable files and hence fall under the influence of
Software Restriction Policies. Using the Add and Remove buttons, administrators modify the
list of application extensions that are managed by Software Restriction Policies. Although
an administrator is able to modify this list, she cannot remove the standard executable
extensions, such as .com, .exe, and .vbs. These extensions are always recognized as executable.
FIGURE 5-14 Designated File Types
Path Rules
Path rules, shown in Figure 5-15, allow you to specify a file, folder, or registry key as the target
of a Software Restriction Policy. The more specific a path rule is, the higher its precedence.
For example, if you have a path rule that sets the file C:\Program files\Application\App.exe to
Unrestricted and one that sets the folder C:\Program files\Application to Disallowed, the more
specific rule takes precedence and the application can execute. Wildcards can be used in path

rules, so it is possible to have a path rule that specifies C:\Program files\Application\
*.exe. Wildcard rules are less specific than rules that use a file’s full path.
The drawback of path rules is that they rely on files and folders remaining in place.
For example, if you created a path rule to block the application C:\Apps\Filesharing.exe, an
attacker could execute the same application by moving it to another directory or renaming
it something other than Filesharing.exe. Path rules work only when the file and folder
permissions of the underlying operating system do not allow files to be moved and renamed.
Lesson 2: Managing AppLocker and Software Restriction Policies CHAPTER 5 275
FIGURE 5-15 Software Restriction Policy path rule
Hash Rules
Hash rules, shown in Figure 5-16, work through the generation of a digital fingerprint that
identifies a file based on its binary characteristics. This means that a file that you create a hash
rule for will be identifiable regardless of the name assigned to it or the location from which
you access it. Hash rules work on any file and do not require the file to have a digital signature.
The drawback of hash rules is that you need to create them on a per-file basis. You cannot
create hash rules automatically for Software Restriction Policies; you must generate each rule
manually. You must also modify hash rules each time that you apply a software update to an
application that is the subject of a hash rule. Software updates modify the binary properties of
the file, which means that the modified file does not match the original digital fingerprint.
FIGURE 5-16 Hash rule for Minesweeper
2 7 6 CHAPTER 5 Managing Applications
Certificate Rules
Certificate rules use a code-signed software publisher’s certificate to identify applications
signed by that publisher. Certificate rules allow multiple applications to be the target of a
single rule that is as secure as a hash rule. It is not necessary to modify a certificate rule in
the event that a software update is released by the vendor because the updated application
will still be signed using the vendor’s signing certificate. To configure a certificate rule, you
need to obtain a certificate from the vendor. Certificate rules impose a performance burden
on computers on which they are applied because the certificate’s validity must be checked
before the application can execute. Another disadvantage of certificate rules is that they

apply to all applications from a vendor. If you want to allow only 1 application from a vendor
to execute but the vendor has 20 applications available, you are better off using a different
type of Software Restriction Policy because otherwise users can execute any of those other
20 applications.
Network Zone Rule
Internet zone rules apply only to Windows Installer (.msi) packages obtained using Internet
Explorer. Zone rules do not apply to non msi applications, such as .exe files, obtained using
Internet Explorer. Zone rules function by differentiating installer packages based on the site
from which they were downloaded. Possible locations include Internet, Intranet, Restricted
Sites, Trusted Sites, and My Computer.
More Info SOFTWARE RESTRICTION POLICIES
To learn more about Software Restriction Policies, consult the following Web site on
Microsoft TechNet: />Quick Check
n
What is the advantage of using a hash rule over a path rule?
Quick Check Answer
n
Hash rules are like digital fingerprints that identify a unique file. A path rule only
works based on a file name and path, which means that malware can be inserted
into locations covered by path rules and executed.
AppLocker Application Control Policies
AppLocker is a feature new to Windows 7 that is available only in the Enterprise and Ultimate
editions of the product. AppLocker policies are conceptually similar to Software Restriction
Policies, though AppLocker policies have several advantages, such as the ability to be
applied to specific user or group accounts and the ability to apply to all future versions of
a product. As you learned earlier in this chapter, hash rules apply only to a specific version
of an application and must be recalculated whenever you apply software updates to that
Lesson 2: Managing AppLocker and Software Restriction Policies CHAPTER 5 277
application. AppLocker policies are located in the Computer Configuration\Windows Settings\
Security Settings\Application Control Policies node of a standard Windows 7 or Windows

Server 2008 R2 GPO.
AppLocker relies upon the Application Identity Service being active. When you install
Windows 7, the startup type of this service is set to Manual. When testing AppLocker, you
should keep the startup type as Manual in case you configure rules incorrectly. In that
event, you can just reboot the computer and the AppLocker rules will no longer be in effect.
Only when you are sure that your policies are applied correctly should you set the startup
type of the Application Identity Service to Automatic. You should take great care in testing
AppLocker rules because it is possible to lock down a computer running Windows 7 to such
an extent that the computer becomes unusable. AppLocker policies are sometimes called
application control policies.
Default Rules
Default rules are a set of rules that can be created automatically and which allow access
to default Windows and program files. Default rules are necessary because AppLocker
has a built-in fallback block rule that restricts the execution of any application that is not
subject to an Allow rule. This means that when you enable AppLocker, you cannot execute
any application, script, or installer that does not fall under an Allow rule. There are different
default rules for each rule type. The default rules for each rule type are general and can
be tailored by administrators specifically for their environments. For example, the default
executable rules are path rules. Security-minded administrators might replace the default
rules with publisher or hash rules because these are more secure.
You can create the default rules by right-clicking the Executable Rules, Windows Installer
Rules, or Script Rules node, and then clicking Create Default Rules. The default executable
rules are shown in Figure 5-17.
FIGURE 5-17 Default executable rules
Rules That Block
You can configure AppLocker rules to allow or block applications. Explicitly defined Block
rules override any Allow rule, no matter how that rule is defined. This is different from how
Software Restriction Policies work, where one rule type can override another. The fallback
Block rule, mentioned earlier in this lesson, does not override any rules. The fallback Block
2 7 8 CHAPTER 5 Managing Applications

rule just restricts the execution of any application that has not been allowed specifically.
You need to add a Block rule only if another AppLocker rule allows an application, installer,
or script to be executed. For example, suppose that you want to allow everyone in your
organization to use an application named Alpha.exe except members of the Accounting
group. You would need to create two rules. The first rule would allow everyone to run Alpha.
exe. The second rule would block members of the Accounting group from running Alpha.exe.
Although AppLocker rules include exceptions, you cannot apply exceptions on the basis of
group membership.
You can use explicitly defined Block rules to stop the execution of applications that are
enabled through the default rules. For example, the default rules allow the application
Solitaire.exe to be executed on a computer running Windows 7. You can block Solitaire from
executing by creating an explicit Block rule. You could also block Solitaire from executing by
configuring an exception to the default rules. Exceptions are covered later in this lesson.
Executable Rules
Executable rules apply to files that have .exe and .com file extensions. AppLocker policies
are primarily about executable files, and it is likely that the majority of the AppLocker
policies that you work with in your organizational environment will involve executable rules.
The default executable rules are path rules that allow everyone to execute all applications in
the Program Files folder and the Windows folder. The default rules also allow members of the
administrators group to execute applications in any location on the computer. It is necessary
to use the default executable rules, or rules that mirror their functionality, because Windows
does not function properly unless certain applications, covered by these default rules, are
allowed to execute. When you create a rule, the scope of the rule is set to Everyone, as shown
in Figure 5-18, even though there is not a local group named Everyone. If you choose to
modify the rule, you can select a specific security group or user account.
Windows Installer Rules
Windows Installer rules cover files with .msi and .msp file extensions. You can use installer
rules to block or allow the installation of software on computers. The default Windows
Installer rules allow the Everyone group to use digitally signed Windows Installer files, all
Windows Installer Files in the %Systemdrive%\Windows\Installer directory and allow members

of the local administrators group to run any .msi or .msp file. The default rules allow the
installation of software and software updates through Group Policy.
It is important to remember that even if an AppLocker rule allows everyone to access
a particular installer file, they still need the relevant administrative permissions to install
software on the computer. Installer rules are most useful when your organization has portable
computers running Windows 7 that require you to give users local administrator access.
After removing the default rule that allows local administrators to use any installer, you can
restrict which installer files the local administrator can access. In this scenario, you also have
to restrict access to the Local Group Policy Editor, or else the local administrator could modify
this policy setting.
Lesson 2: Managing AppLocker and Software Restriction Policies CHAPTER 5 279
FIGURE 5-18 Default rule scope
Script Rules
Script rules cover files with the .ps1, .bat, .cmd, .vbs, and .js file extensions. Although it is
possible to use publisher rules with scripts, most scripts are created on an ad-hoc basis by
administrators and are rarely digitally signed. You should use hash rules with scripts that are
rarely modified and path rules with directories containing scripts that are regularly updated.
If you use path rules, you should ensure that the permissions on the folders hosting the
scripts are configured so that nefarious scripts cannot be placed in this folder. The default
script rules allow the execution of all scripts located in the Program Files and Windows
folders. The default script rules also allow members of the built-in administrators group to
execute scripts in any location.
DLL Rules
DLL rules cover files known as libraries, which have the .dll and .ocx file extensions. Libraries
support the execution of applications. DLL rules are not enabled by default when you enable
AppLocker. DLL rules provide a maximum level of security but also involve performance
drawbacks. You need to create a DLL rule for each DLL that is used by the applications on
2 8 0 CHAPTER 5 Managing Applications
your client running Windows 7. Although creating rules is made easier by the ability to
generate rules automatically, users experience a performance reduction as AppLocker needs

to check each DLL that an application loads each time it is loaded. To enable DLL rules, right-
click the Computer Configuration\Windows Settings\Security Settings\Application Control
Policies\AppLocker node in Group Policy, select the Advanced tab, and check the Enable The
DLL Rule Collection, as shown in Figure 5-19.
FIGURE 5-19 Enabling DLL rule collection
Publisher Rules
Publisher rules in AppLocker work on the basis of the code-signing certificate used by the
file’s publisher. Unlike a Software Restriction Policy certificate rule, it is not necessary to
obtain a certificate to use a publisher rule because the details of the digital signature are
extracted from a reference application file. If a file has no digital signature, you cannot restrict
or allow it using AppLocker publisher rules.
Publisher rules allow you more flexibility than hash rules because you can specify not only
a specific version of a file but also all future versions of that file. This means that you do not
have to re-create publisher rules each time you apply a software update because the existing
rule remains valid. You can also allow only a specific version of a file by setting the Exactly
option, as shown in Figure 5-20.
Lesson 2: Managing AppLocker and Software Restriction Policies CHAPTER 5 281
FIGURE 5-20 AppLocker publisher rule
Using the slider, you can also vary the scope of the publishing rule so that it applies to
a specific file name signed by the publisher, a specific product signed by the publisher, any
product signed by the publisher, or any product signed by any publisher. This last setting
does not apply to any application, only to applications digitally signed by publishers. If you
applied an Allow rule that had the slider set to Any Publisher, then all applications signed by
publishers could be executed, but applications that were not signed would not fall under the
scope of the rule.
Hash Rules
Hash rules in AppLocker function in the same basic way that they do in Software Restriction
Policies. Hash rules allow you to identify a specific binary file that is not digitally signed by
creating a digital fingerprint of that file. This fingerprint is known as a file hash. File hashes
in AppLocker are more manageable than file hashes in Software Restriction Policies because

you can use the Rule Creation wizard to automate the creation of file hashes for all files in
a specific location. As mentioned earlier, the drawback to hash rules is that it is necessary
to re-create file hashes each time a software update is applied because software updates
2 8 2 CHAPTER 5 Managing Applications
can modify the properties of the file, so the hash file digital fingerprint no longer matches
it. To create a hash, navigate to the file and select it. It is also possible to browse to a folder
and create hashes of all files within that immediate folder. When you browse to a folder, files
contained in subfolders are not included. A file hash rule is shown in Figure 5-21. Because file
hashes are specific to individual files, you cannot create exceptions to file hash rules.
FIGURE 5-21 AppLocker file hash rule
Path Rules
AppLocker path rules work in a similar way to Software Restriction Policy path rules that
you learned about earlier in this lesson. Path rules let you specify a folder, in which case the
path rule applies to the entire contents of the folder, including subfolders, and the path to
a specific file. The advantage of path rules is that they are easy to create. The disadvantage of
path rules is that they are the least secure form of AppLocker rules. An attacker can subvert
a path rule if they copy an executable file into a folder covered by a path rule or overwrite
a file that is specified by a path rule. Path rules are only as effective as the file and folder
permissions applied on the computer. An AppLocker path rule is shown in Figure 5-22.