For Win Wonks, Software Restriction is Good Policy

Software Restriction Policies, Part One: One way to head worms and trojan malware off at the pass is to keep them from running at all. With Win Server 2003 Software Restriction Policy management, you can do just that, flexibly, with no additional software, and with little change to your carefully tuned Active Directory configuration.

By Drew Bird | Posted Dec 8, 2004
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Some of the most significant threats to your network's security and stability come from worms and trojan malware. These network threats can be transmitted through executable files attached to e-mails, via Internet downloads, or from Web pages. Although virus checkers are increasingly effective at protecting against threats embedded in executable files, there are still other measures you can use to protect the systems on your network. One of the most effective is to simply prevent people from opening unknown executable files in the first place. Windows Server 2003 provides a feature called Software Restriction Policies that allows you to do just that.

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.

Policies can be applied in one of two modes – "unrestricted" or "disallowed." After configuring the default mode for the policy, you can then create exceptions for software you do or do not want to run. For example, if you configure a software restriction policy with a default level of "unrestricted," you can configure exceptions that define those kinds of applications you don't want users to run. Conversely, if you configure a default level of "disallowed," you can specify exceptions for the applications you do want users to run. As you can imagine, the "disallowed" setting involves considerably more administrative overhead than "unrestricted," but it also provides a much more restricted, and thus secure, environment.

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 – 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 – 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 – 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 – 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 – 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!

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter