Manage Learn to apply best practices and optimize your operations.

Prevent unauthorized USB devices with software restriction policies, third-party apps

In the conclusion of his series on preventing unauthorized USB device use on your network, Brien Posey discusses the pros and cons of using software restriction policies such as certificate rules, hash rules, Internet zone rules, and path rules to prevent users from employing a USB device to bring unauthorized software into the organization. He also discusses some third-party software applications that can be of use.

So far in this series, I have talked about using techniques such as BIOS settings, group policies, and even glue to prevent the unauthorized use of USB storage devices. In this article, I want to conclude the discussion by showing you a couple more techniques you can use to keep unauthorized USB devices from becoming a problem on your network.

Software restriction policies

Although not actually intended for use in the fight against removable storage devices, software restriction policies can be of some assistance. Software restriction policies are group policy settings that are designed to prevent users from installing unauthorized software onto their workstations. As such, software restriction policies will not prevent the use of USB storage devices, nor will they prevent users from copying data to those devices. They can, however, be used to prevent users from employing a USB device to bring unauthorized software into the organization.

Read more on blocking USB devices
USB storage devices: Two ways to stop the threat to network security

Using Windows Vista group policy to prevent unauthorized USB device use

You can create software restriction policies by opening the Group Policy Object Editor and navigating through the console tree to Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies. Next, right-click on the Software Restriction Policies container and select the New Software Restriction Policies command from the resulting shortcut menu. Windows will then create two sub-containers: Security Levels and Additional Rules.

When you create a software restriction policy, security levels are applied to security rules. The security levels are created by default. They consist of "Allowed" and "Disallowed." This means that all you have to do is to create the policy rules and then tell Windows whether applications being installed that meet the criteria of those rules should be allowed or disallowed.

You can create a rule by right-clicking on the Additional Rules container and then selecting the type of rule that you want to create. There are four types of rules: certificate rules, hash rules, Internet zone rules, and path rules. I could probably write a book on these four types of rules, but for the purposes of this article, I will try to keep things simple and just give you an idea of the strengths and weaknesses of each type of rule.

Certificate rules are by far the most secure type of rule. The basic idea is that many software publishers digitally sign the code that they release in order to prove that the code is authentic. You can create certificate rules that work based on these digital signatures. This allows you to permit applications from some publishers while denying unsigned applications or applications from publishers that you have not approved. The biggest downside to certificate rules is that not every publisher signs its code.

A hash rule allows you to create a digital hash of a file (a mathematical equation based on the file's contents) and then either approve or deny the file based on that hash. The nice thing about hash rules is that they work even if a user attempts to rename a file or install a file to an unconventional location. The problem with hash rules, though, is that hashes are file specific. If a new version of a file is released, or if even a single byte of a file is modified, the hash is no longer valid.

Path rules are designed to permit or deny an application based on its location within either the file system or the Windows registry. For example, if you wanted to prevent users from running video games, you might create a path rule that blocked applications located at \Program Files\Microsoft Games\. The problem with path rules is that if a user moves a file to a different location that is not under the jurisdiction of the path rule, then the application is free to execute. Even so, the fact that path rules can contain environment variables or registry keys means that you can create some rather powerful path rules if you know what you are doing.

Internet zone rules are almost worthless in my opinion. They are designed to prevent users from executing applications that they download from the Internet. Even so, Internet zone rules will work only if a user downloads a file from a website that exists in a restricted zone. If another machine is used to download the file, the Internet zone rule won't stop the user from running the file, because the computer doesn't know that the file came from the Internet. Furthermore, Internet zone rules can be used only to restrict Windows Installer files (*.MSI files).

Third-party applications

Probably the best defense against USB storage devices is to use third-party applications. GFI makes a product called EndPoint Security that is specifically designed to prevent the use of USB storage devices.

If your goal is to keep unauthorized software off your network, you might check out a product called Parity from a company named Bit9. Parity is designed to allow you to control which processes are and are not authorized to run on workstations.


In this series, I have discussed the problems that USB storage devices pose within an organization and have talked about several possible solutions to these problems. There is a much more detailed whitepaper on this topic on my website, where you can read more about software restriction policies or Bit9's Parity.

About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at

This was last published in January 2008

Dig Deeper on Working With Servers and Desktops