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: http://technet.microsoft.com/en-us/library/cc782792(WS.10).aspx. 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. . CHAPTER 5 277 application. AppLocker policies are located in the Computer Configuration Windows Settings Security SettingsApplication Control Policies node of a standard Windows 7 or Windows Server. 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. 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