14 Reasons To Reconsider Software Restrictions

Software Restriction Policies is a terrific new security tool—if you know what it can’t do, as well as what it can.

• By Roberta Bragg
• April 01, 2004

In an ideal world, you’d be able to control your desktop and server environments so only the software you specify can run. Preventing the addition of new executables to the hard drive would be a moot point, because even if the code were saved to disk it wouldn’t run, as it wasn’t approved. Think about this. Regardless of the virus or worm launched against your network; regardless of attempts by users to add games or utilities to their desktops; regardless of the errors in judgment that junior administrators might make; no software—not even Windows components—would run unless specifically approved. A dream? Yes, but one that’s realizable, maybe.

Windows XP Professional and Windows Server 2003 provide a tool that appears to be the solution: Software restriction policies. In a Windows 2003 domain, they can be implemented using Group Policy; on standalone systems, they can still play a role. They can be used to prevent program execution, and they’re easy to set up. I think you should use them; but before you do, take a minute to examine my top reasons for not using them. I’m not providing these reasons to bash what I consider to be an excellent security tool. It’s because I don’t want you to gain a false sense of security. Software restriction policies can help you lock systems down. To do so, however, you must understand their limitations—many of which you can work around.

1. The Interface Is Confusing
Whoever built the public interface for software restriction policies sure has some funny ideas about the English language, especially the use of double negatives.

To use software restriction policies, you must set a generic security level for all software on the computer. The security level specifies whether all software is allowed to run, or prevented from running. Then you write rules for each piece of software (or path) that you want to explicitly allow or deny. You do that by giving each rule its own security level. Sounds simple, doesn’t it?

It isn’t. In the software restriction policies GUI, software is never classified as restricted or allowed. Instead, it’s “Unrestricted” or “Disallowed.” Do you get my drift? Instead of telling us that software can be used or can’t be, Microsoft feels compelled to say, “Yes, they can’t,” or, “No, they can.” If you want to use software restriction policies, you’re going to have to be very careful. Don’t be confused and prevent something that should run from running by marking it Disallowed or accidentally allow some Trojan or virus to run by using the security level Unrestricted.

2. Writing Policies Is Easy; Deciding What To Write Is Not
Writing policies is as easy as A, B, C—or, in the Windows vernacular, accounts, binary decisions and classification by rule type. First, you must decide which computer and user accounts will be managed by these policies. In a Windows 2003 domain you can implement different policies for every OU; that is, you can customize policies for specific computers and users depending on where their accounts exist. Second, you must choose the way you want them to work. Do you want to allow all software to run except that which you specifically identify as verboten? Or do you want to prevent all software from running except that which you explicitly identify? Which users should be constrained? Should you apply policies to computers or users? These binary decisions must be made and set for each policy before you do anything else. Then write individual rules for the policy that specify the exceptions to the overall policy. Rules are classified by their type.

Specify Policy Based on Computer and User Accounts
Software restriction policies can be applied to XP and Windows 2003 computers or users whose accounts are in a Windows 2003 domain. By default, software restriction policies on a standalone Windows 2003 or XP computer apply to all users of the computer except members of the local Administrators group, but they can be modified to apply to administrators as well.

Binary Decisions
Several on-off choices exist for software restriction policies.

Is all software Unrestricted or Disallowed? This is the basic security level, and must be set one way or the other. Then individual rules either allow or restrict specific software.

Are members of the local administrators group affected by the rules or not?

Will policies apply to all software files except libraries (such as .dlls)?

Should a specific file extension be considered an executable?

Can end users determine who’s a trusted publisher? Can local administrators? How about enterprise administrators?

What should be checked before trusting a certificate? Its publisher? Its timestamp?

Set the Security Level
By default, all software is allowed to run. If all you want to do is prevent a few games or well-known hacking tools from running, leave the default set and learn how to create rules that will explicitly disallow the software you identify. If you want total control over the desktop environment, set the general policy to Disallowed, as shown in Figure 1.

Figure 1. Setting the security level to Disallowed means you must define which software is allowed to run. (Click image to view larger version.)

3. Many Types of Software are Exempt From Policies
Like setting a breaker in an electrical box, making this binary choice determines what can happen next—it doesn’t do the job for you. Once you’ve made this choice, you’ll have to continue on and create rules accordingly. You should, however, understand the exceptions to the Disallowed security level setting. There are several.

By default, four path rules already exist. They guarantee that if you set the Disallowed state but don’t define software that may run Unrestricted, Windows will boot.

Drivers or other kernel mode software will still run.

Programs run by the SYSTEM account will still run.

Macros in Microsoft Office 2000 or Office XP documents are not restricted (manage macros in Office with the Office Macro security settings).

Programs written for the common language runtime aren’t restricted. (These programs are managed by using Code Access Security Policy.)

Note that you can still prevent the running of executables that reside within the paths allowed by the default rules. You can also still prevent drivers and other Unrestricted software from running. You’re just going to have to either write explicit rules to prevent them or use a different tool to do the job. Still, it’s easy to operate under a false sense of security. Remember: Setting the overall, generic security level to Disallowed doesn’t prevent all software from running.

4. Administrators are Exempt by Default
There’s one exception to your carefully planned rules based on computers or accounts. By default, members of the local Administrators group aren’t affected by software restriction policies unless you change the Enforcement setting, shown in Figure 2.

Figure 2. Administrators aren’t affected by software restriction policies unless you change this setting.

5. DLLs are Exempt
Another enforcement rule is the decision on how to treat .dlls. As you know, many applications have files beyond their executables that provide additional code. Many of these files are .dlls. There are two ways to manage them.

1. Assume that if you enable or disable an executable, all of its .dlls are to be treated the same way. This is the default.

2. Require that .dlls be treated as executables. In this scenario you must write a rule for every .dll as well as every executable. This is more thorough and secure, but can become quite tedious. To use it, you’ll need to know exactly which .dlls are related to which executables.

6. You Must Constantly Adjust the Definition of an Executable
The Designated File Types property page, shown in Figure 3, lists the file extensions that define what an executable is. .Exe, .dll and .vbs aren’t listed, but are considered to be executables by default. You can remove or add extensions, thus deciding, as far as the policy is concerned, what constitutes an executable. If the security level, for example, states that all executables are Disallowed (can’t run), but there is an attempt to run some new program with an extension not listed on the property page, what will happen? By default, the program will run. This means you must be on the alert for new types of executables, and keep this list updated.

Figure 3. Here’s the list of executable extensions upon which software restriction policies will act. If a program’s extension isn’t listed here, it will run.

7. Certificate Rules are Weakened by Default

Certificate rules allow you to specify that software signed by a specific certificate is Unrestricted or Disallowed. This control is important because you might wish to use your organization’s certificate to sign administrative scripts. You then can allow your signed scripts to run, while preventing others. However, software restriction policies, by default, indicate that ordinary users can identify trusted publishers. (Trusted publishers are those whose certificates can be used to sign software.) The setting here determines, for example, who can allow signed Active X controls to run.

In addition, a second setting, determining what should be checked about a certificate, allows no check to be performed at all. Or, you can select checking the publisher or the certificate timestamp.

Rule Classes
Four types of rules exist to help you identify software exceptions to your general statement. For each rule you can specify whether its result is to restrict software (mark the rule Disallowed), or allow it (mark the rule Unrestricted.) In most cases, of course, you’ll only write Unrestricted rules if your overall policy is Disallowed, and write Disallowed rules if your overall policy is Unrestricted.

There will, however, be exceptions. For example, drivers are exempt from the overall security level. No matter what the security level is, no driver is forbidden. If your overall policy is Disallowed—nothing should run without explicit permission—drivers will still run. To keep a specific driver from running, you’ll have to write a Disallowed rule to prevent a that driver from running.

8. Certificate Rules Require That Software Be Signed
Certificate rules require that a trusted publisher sign the software. Each rule can identify one trusted publisher by loading a copy of its certificate. Any software signed by the publisher will be treated according to the security level of the rule. This type of rule might be used to allow execution of any in-house developed software signed with a certificate obtained for this use.

The problem is that you can only use these rules if the software you want to allow to run, or prevent from running, is signed. What creator of malicious software is going to sign their software? Still, this is an extremely valuable way of allowing your own software to run. Remember, however, that signing software doesn’t make it safe to run; signing software just makes it identifiable.

9. Hash Rules Don’t Apply To Mutated Files
Hash rules solve the path rule issue. When a hash rule is created, you browse to a copy of the file and let the program create the hash—or, if a hash has been provided, enter it directly in the rule. If a hash rule is created that disallows running sol.exe and the user moves the file to another folder, he or she still won’t be able to run sol.exe. When the attempt is made, a hash is made of the executable and compared to the hash in any hash rules. If a match is found, the rule is triggered. In this case, the rule prevents the program from running. The problem with hash rules, however, is that if a new version of the executable is created, the hash will no longer match and the rule won’t be triggered. If, for example, you were to use a hash rule to block the execution of a virus and a mutated version of the virus were introduced, the hash rule wouldn’t block the execution of the mutated version.

10. Path Rules Only Apply To Paths
This is the simplest rule to understand and implement. Simply locate the executables the rule should affect, and enter the path as part of the rule definitions. Each rule can specify the complete path including the executable name, or it can point to a folder. If the latter is used, all executables within the folder are affected. For example, if your security level is Disallowed, and some custom executables in the C:\myprograms folder should be allowed to run, use the path C:\myprograms. However, if only one executable, like the myprog.exe program, should be allowed to run, use the C:\myprograms\myprog.exe path.

Unfortunately, if the executable lies in any other path or is moved there, the rule no longer applies. For example, if the security level is Unrestricted and you want to prevent Solitaire from running, you might write a path rule for C:\windows\system32\sol.exe. However, if the user copies sol.exe to any other place on the drive, he or she will be able to run it. Path rules can also be Registry path rules.

11. Internet Zone Rules Only Apply To Programs That Use the Windows Installer
Internet Zone rules are based on IE Security Zones. A rule can be created for one of the five zones:

Internet

Local computer

Local intranet

Restricted sites

Trusted sites

At first glance these seem like good rules. Wouldn’t it be nice to be able to specify what could be run from a Web site in one of these zones? Unfortunately, these rules only apply to software that uses the Windows installer.

Which Rule Rules? With all these different types of rules, it’s possible that more than one rule might apply to a specific piece of software. If this is so, which rule applies? The answer depends on the application of precedence; that is, the rule types are ordered. A hash rule takes precedence over a certificate rule, which takes precedence over a path rule, which takes precedence over an Internet Zone Rule. For example, if a hash rule for sol.exe prevents it from running, but a path rule identifies its location as one in which all software is allowed to run, sol.exe won’t be allowed to run, since a certificate rule takes precedence over a path rule. —Roberta Bragg

12. It’s Difficult To Put Even a Simple Policy in Place
Let’s assume you want to create a desktop software restriction policy that allows temporary clerical staff to run only Microsoft Word. They’re not allowed to browse the Internet, receive or send e-mail, play games or anything else.

Preventing all software from running except the software that you want seems like the way to go. The problems arise when you attempt to cover all your bases. Take Word, for example. Just expand the directory that houses Microsoft Office and start exploring. There are a lot of executables there. There are more in the Common Files folder. Which ones are necessary for our temp clerical staff? How many rules must be written? Perhaps a path rule should be used. However, if everything in the path for Office can run, what’s to prevent someone from copying some other executable there and running it? By default, ordinary users only have Read and Execute permissions on these folders. But many organizations still make ordinary users members of their local administrators group. And, as mentioned previously, administrators have Full Control.

Here’s a sample process that will result in a software restriction policy for our scenario. Although not perfect, it can be effective.

Start by identifying the OU where the computer accounts for the computers in this isolated location reside. If such an OU doesn’t exist, you may have to create one. Remember, when a computer-based software restriction policy is created in a GPO linked to an OU, it’ll affect all computers in that OU.

Next, create the policy in the GPO linked to the OU. Don’t forget to test this policy before implementation.

To create the policy:

1. Open the GPO in the Group Policy Object Editor.

2. Select the Software Restriction Policies container.

3. Right-click the Software Res-trictions Policy container, and select New Software Restriction Policy. This creates the software restriction containers.

4. Set the security level by expanding the Security Levels folder and double-clicking the Disallowed page. Click the “set as default” button. This will prevent any software from running except that which is exempted or software explicitly specified in rules. By default, several rules are set that allow critical system software to run.

5. Leave other defaults in place. It’s not a bad idea to start out leaving the Administrators group exempt from any policy. That way, if you screw up and prevent some critical piece of software from running, you can log on as a local administrator and correct the problem.

6. Create a path rule to allow Word programs to run. You’ll need at least two rules: One for the Program Files\Microsoft Office path and one for the Program Files\Common Files path. Set the security level on these path rules to Unrestricted.

7. Create a path rule to allow system software to run. A good strategy is to create an Unrestricted rule for the Windows directory, then create Disallowed rules for files such as regedit.exe and cmd.exe that users shouldn’t run. These rules can be hash rules to prevent a user from copying the file to another directory and running them.

8. Test these rules while logged on as an ordinary user.

13. It Only Works on Windows XP and Windows 2003
If you use other operating systems, or want to control software that runs on other network devices, software restriction policies won’t work for you.

14. There are Other Ways To Do This
There are third-party programs that purport to lock down Windows and allow you to explicitly determine what software to run. One of them is Abtrusion Security, www.abtrusion.com. This software, once loaded, makes a hash of every software executable on the desktop.

After this process has completed, no other software will be able to run. Each attempt at running software is delayed until a hash of the executable can be made. If the hash doesn’t match one already recorded as OK, the software won’t run.

An administrator, of course, can add new software and test whether it’s acceptable. Also note that it’s a desktop solution and not integrated with AD.

Another product, Tangram’s OverSight, www.tangram.com, is a centralized enterprise solution that works to prevent software from running unless it’s been approved by a policy.

I haven’t tested either solution, so I can’t speak for how well either does the job. You’ll want to do your customary investigation and testing before deploying. And you should remember one important consideration for third-party solutions: They cost money. Software restriction policies is free.