6.3 Software Restriction Policies

     

Software restriction policies (SRP) allow you to classify applications and restrict their use, preventing users from running unauthorized software applications. Software restriction policies use one of four methods to identify applications:

• A hash rule, which is a cryptographic hash (or checksum) that uniquely identifies a particular file

• A certificate rule, which identifies the digital key pair used to sign a particular piece of software

• A path rule, which identifies software by its location on a computer's hard drive

• An Internet zone rule, which identifies software by the Internet domain the software is retrieved from

Software restriction policies can be configured either as part of a local computer's policies or, for more effective centralized management, as part of a group policy applied to all domain computers and users.

6.3.1 Configuring Software Restriction Policy

By default, enforcement of software restriction policies is disabled. To enable enforcement, you need to modify the appropriate policy. To configure the Group Policy settings that apply to software restriction policies, you should follow this procedure. Note that this procedure uses the Default Domain Policy, but you can apply the policy anywhere in your domain.

1. Open the Group Policy Management snap-in.

2. Open the Default Domain Policy Group Policy Object.

3. Navigate to the Software Restriction Policies node as shown in Figure 6-5, later on in this chapter.

4. Right-click the Software Restriction Policies node, and then click New Software Restriction Policies.

Notice that, by default, there are no software restriction policies in force. You cannot configure this policy in detail until you actually create a basic policy by choosing New Software Restriction Policies.

You can now specify what types of files policy enforcement applies to, as well as whether these restrictions apply to members of each computer's local Administrators group. This is done through the Enforcement option of the policy as shown in Figure 6-1, which is displayed when you double-click the Enforcement Group Policy setting.

Avoid enforcing policies on DLL and other library files. If you do, you'll have to configure rules to allow those files to execute, and it can often be difficult to determine which library files an application needs to use. If you forget to authorize a DLL, applications that need it won't run properly.

By default, all software is allowed to run unless you create a policy that specifically disallows it. Software restriction policies do contain a Disallowed policy under the Security Levels folder, shown in Figure 6-2, which you can configure to be the default action for any software not specifically mentioned in its own policy.

Figure 6-2. Configuring the Disallowed policy to be the default

Once policy enforcement is enabled, the default policy (Unrestricted or Disallowed) will affect all software that does not have a specific software restriction policy defined. For software that does have a defined policy, the policy itself will determine whether the software is allowed to run.

6.3.1.1 Creating a new hash rule

When you create a new software restriction policy, or rule, you define the software that the rules will apply to and whether Windows should allow the software to run. The following procedure shows how to create a new hash rule that disallows execution of the Windows Calculator.

1. Within the Software Restriction Policy node, right-click Additional Rules, and then click New Hash Rule.

2. Click Browse to find the desired file. In this case, browse to C:\Windows\System32 and double-click calc.exe .

3. In Security level, select Disallowed as shown in Figure 6-3, and then click OK.

Figure 6-3. Creating a new hash rule

As shown in Figure 6-3, you configure three key items in a hash rule:

The hash

You can use the Browse button to select a file (in this case, calc.exe ), and Windows will calculate the file's hash for you. Theoretically, you can type in a hash if the file is not available on the local computer, but this is not often done.

The security level for the application

Which is either Unrestricted or Disallowed.

A description for the rule

Which helps to identify the rule and its purpose later.

Once you apply a rule to a computer and enable software restriction policy enforcement, Windows immediately starts restricting software use. If you specified Disallowed as the default policy, only applications you have specified as Unrestricted in a rule will be allowed to run. Be sure you test your software rules thoroughly to ensure users' applications will still run properly.

6.3.1.2 Creating a certificate rule

Another powerful rule you can create with software restriction policies is a certificate rule. This type of rule applies to all code that chains to a specific root certificate. You can choose to allow or disallow the code based on the root certificate that its signature chains to.

For example, let's assume that the private key of a specific root certificate issued by Thawte has been compromised. You want to block all signed code that chains to this root certificate. You do that with a certificate rule as shown here:

1. Ensure that the certificate exists in a CER file on your hard drive. If it's in your certificate store, you must export it to a file using the process described in Chapter 9.

2. Within the Software Restriction Policy node, right-click Additional Rules, and then click New Certificate Rule.

3. Click Browse to find the desired CER file, and then click Open.

4. In Security level, click Disallowed as shown in Figure 6-4, and then click OK.

Figure 6-4. Working with software restrictions

Now all signed software that chains to this root certificate will be disallowed and will not run. Note that this can affect software you previously trusted. You should verify the impact of this rule on your network before deploying it.

6.3.2 Example: Allowing an Application to Run on Computers

Kim Yoshida, an employee in one of your company's branch offices, informs you of a new software application that the branch uses. The application allows the branch to calculate local bank tariff fees, which are unique to the county that Kim's branch is located in. Although Kim was able to install the application, your company's software restrictions are preventing her from executing it. Your software restriction policies are enforced through a Group Policy Object. You test the application and determine that it does not adversely affect your company's computers and decide to allow it to run on any company computer. Here's what to do:

1. Open the Group Policy Object that contains your software restrictions.

2. Locate the Software Restriction Policies section, as shown in Figure 6-5.

3. Right-click on the Additional Rules folder, and select New Hash Rule.

4. Click the Browse button, and double-click the new application's executable file.

5. Change the Security level selection to Unrestricted.

6. Type a description for the rule, such as Rule to allow the new tariff calculator to execute .

7. Click OK to save the modified Group Policy Object.

Figure 6-5. Configuring software restrictions to allow an application to run

If you didn't want to allow the calculator to run on all your company's computers, you could create a new Group Policy Object that contains the hash rule for the calculator's executable and then link that Group Policy Object to an organizational unit that contains only the computers on which the calculator is allowed to run. You could also link the policy to the Active Directory site that represents Kim's branch office, which would allow the calculator to run on the computers in that office.

6.3.3 Example: Allowing Applications with a Specific Extension to Execute

You company's software developers create a new scripting language used in your company's branch offices. The script files are named with a .wbx filename extension, and the script processing application is installed on all your company's computers. As the network administrator, you want to ensure that WBX files are treated as executable files by your company's software restriction policies. Your company already has a Group Policy Object named SoftRestrict that defines software restriction policies for each domain in the company. Here's how you can modify the SoftRestrict Group Policy Object to include WBX files:

1. Open the SoftRestrict Group Policy Object and locate the Software Restriction Policies section.

2. Double-click on the Designated File Types policy.

3. Type WBX in the File Extension text box, as shown in Figure 6-6, and click Add.

4. Cick OK.

Figure 6-6. Adding a new file extension that is allowed to run

Once the procedure is completed, the appropriate software restriction policies will apply to your WBX files.

6.3.4 Best Practices for Software Restrictions

Software restrictions can be complex and, if not carefully configured, can cause as much disruption to your users as a virus. Here are some tips for configuring effective software restrictions in your environment:

• If you choose to make the default policy Disallowed, be sure to thoroughly test your software rules on a test computer in a test domain before deploying the rules to your production users. Although this policy can be the most effective at blocking unsafe code, it can also have the largest impact on user productivity and cause a profoundly negative perception of security.

• Use file hash and certificate rules whenever possible, since they are the most accurate and most difficult to circumvent. Path rules can be circumvented by simply copying the software to a different location, and Internet zone rules can be defeated by acquiring the software from a different Internet domain. Hash and certificate rules are nearly impossible to circumvent, because they identify the software itself, not the location the software comes from or resides at.

• Configure policy enforcement so that it doesn't apply to DLL and other libraries. Then, you'll only have to configure rules for actual executable (EXE) files.

• Don't rely on rules to disallow files that are infected with a virus. While a rule can identify an infected executable that you've discovered , the rule will not identify other executables infected with the same virus. Antivirus software is still your best line of defense against viruses.

• Apply SRP at the OU level, and ensure that OUs are created to contain users with similar software needs. This allows you to customize the SRP at every OU to allow exactly the software necessary for the workgroup. The beneficial side effect of this administration is that you get a cheap software metering solution!