How Software Restriction Policies Work

In simple terms, Software Restriction Policies allow you to define what applications can or cannot be run on a computer. The restrictions are configured and applied through Group Policy, so there is no additional software to install, nor is there any major reconfiguration of Active Directory.

Many complex applications, like Microsoft Office, invoke other smaller applications as they run. You should test all aspects of an app, not just the main program.

In this article, we'll look at how you can use software restriction policies to provide an additional level of protection to your network. In next week's article we'll look at how you go about configuring and implementing software restriction policies on your network.

Which applications can be run in a "disallowed" environment, or cannot be run in an "unrestricted" environment, are defined through a set of rules. These rules provide different evaluation criteria by which a file that is attempting to be opened can be evaluated. There are four types of rules that can be created ¨C hash, certificate, path and Internet zone. Each takes a different approach to determining whether a file will be permitted or prevented from running.

• Hash rule ¨C The hash rule works by using a hashed value of the executable file as criteria to determine if it should run. When an attempt to start the executable is made, the hash value for the file is calculated and compared to the hash value stored when the rule was created. If the two match, then the file is allowed or disallowed based on the default security level that is configured. If the hash value does not match because, for example, a virus has infected it since it was created, the hash values won't match and the file will be prevented from opening.
• Certificate rule ¨C Certificate rules use digital certificates to determine whether or not a file should be allowed to open. The certificate you use for the rule must be supplied to you by the software creator, and is then used to verify the validity of the executable when you attempt to use it. Like the hash rule, a certificate verifies that the software has not be altered or manipulated since it was created.
• Path rule ¨C The path rule uses the location from which the executable is launched as the criteria for determining whether access is permitted. For example, if you were using the "disallowed" default rule, you could provide access to certain folders from which users are permitted to run an executable file. An attempt to run a file from another location would be blocked. To increase the flexibility of path rules, you can use folder variables such as %windir% and %userprofile%.
• Internet zone ¨C The Internet zone rule uses the zones defined in Internet Explorer to identify from where a file is retrieved, and then determine whether a file can be executed. To view the zones and get an idea of locations and objects included in each zone, open Internet Explorer and click Tools > Internet Options. Then choose the Security tab. By configuring rules based on Internet zones, you can override the default setting for the Software Restriction Policy on executables obtained from that zone. So, for example, if you configured an Internet Zone rule when the default security level was "unrestricted," any software run directly from the Internet, perhaps as part of a web page, could be prevented from running. It should be noted, though, that at this time only Windows Installer packages are covered by Internet zone rules.

In some cases it is possible for an executable file to be subjected to more than one rule. When this happens, the rules are applied in order starting with the hash rule, followed by the certificate rule, then the path rule, and finally the Internet zone rule.

Another configurable aspect of Software Restriction Policies is the specification of what files types are covered by the policy. By default a wide range of executable files types such as BAT, COM, VBS, EXE and MSI are included. You can choose to add or remove file types as needed. The advantage of a configurable list is that as new programs become available or new threats are identified, you can add that file type to the list.

A Word of Caution

It should go without saying that implementation of Software Restriction Policies should only take place after considerable testing. The basic premise behind the technology is that it prevents people from opening files that they shouldn't. With this comes the inherent risk that a misconfiguration will result in people not being able to open files that they need.

Also keep in mind that many complex applications, like Microsoft Office, invoke other smaller applications or components as they run. As a result, you should test all aspects of an application, not just the main program.

Summary

Although the implementation of Software Restriction Policies can require a reasonable amount of administrative overhead, particularly on a large network, there are few other methods of providing such comprehensive control over what applications can be run and from where. In the next article, we'll look at the actual process of implementing Software Security Policies on a Windows Server 2003 system. Until then!