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.
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
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
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.
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.
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
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
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.)
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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:
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
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.
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.
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
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