If you would like to read the next part in this article series please go to Best practice security guide to built-in device control in Windows (Part 2).
In this 2-part article series, you will learn how to protect your Windows XP, Windows Server 2003 or Vista based computer from unwanted or built-in devices such as USB flash drives, iPods, CD-ROM’s, DVD’s, wireless intefaces, etc, using built-in features in Windows. We’ll walk through the options you have with the various Windows versions and also look at common myths and limitations from a security point of view.
The challenge
Let’s face it. External storage (of any kind) is both a blessing and an administrative nightmare in a domain based environment. The possibilities of having a huge amount of data on a small easily removable device, makes it an ideal tool for both users and administrators in their daily work. But it also challenges the security policies in companies, who are trying to protect their intellectual property or avoid contamination from malicious software. The challenge is the same for wireless network communication where you get a tremendous amount in freedom in terms of mobility, but also add new ways to invite malicious software or rogue users to enter your infrastructure.
Now, if you include the fact that most of the Windows operating systems today don’t include built-in support, that in a granular and central way helps you control the various devices that can be used on a computer, the challenge can seem somehow overwhelming.
With Windows XP and Windows Server 2003, you don’t get many options, when it comes to built-in device control. However there are a few things you can do. Let’s look at the options you have.
Registry settings
When Windows XP SP2 was released, you got the option to make USB storage devices work as read-only devices. By entering the Windows registry database and navigating to HKLM\System\CurrentControlSet\Control, you create a new key named StorageDevicePolicies. Within this key, you create a REG_DWORD value named WriteProtect and give it the value 1. When you’re done, you reboot the computer.
This feature doesn’t really solve the problem covered in this article. It’s a workable solution, if you want to protect your company’s intellectual properties and make it more difficult for a non-technical user, to copy data to an external USB device, but your infrastructure is still vulnerable in terms of being infected by malicious software that could be stored on the key or the user being able to install non-approved software. Besides, it only works with Microsoft’s own generic USB drivers.
Group Policies at your service
Out of the box, you only get a few limited GPO settings that allow you to control devices, as shown in figure 1.
Figure 1
But by tweaking various GPO settings, you can change the odds in your favor. The Microsoft KB article KB555324 explains how you can create an administrative template that allows you to disable various external storage devices, as displayed in figure 2.
Figure 2
The trick behind this template is that the generic Microsoft drivers for the various storage devices are being disabled during startup. If you like, feel free to extend the administrative template to control other devices such as the built-in Bluetooth driver that’s included with Windows XP SP2 and up.
This GPO approach does however carry some disadvantages. First of all it’s a computer based GPO, so it’s an either/or solution. For some this is fine, and for others it carries too many limitations. Secondly, it’s fairly easy to configure, as long as it is based on Microsoft generic drivers. However it quickly becomes an administrative pain if you want to control manufacturer specific drivers. There is a solution for this by making sure that the user runs as non-admin, which we’ll get back to later in this article. The third disadvantage is that this approach can be circumvented by a user, even if he has limited rights, i.e. runs as a non-admin. The tool gpdisable.exe from sysinternals.com (now part of Microsoft) can be used to disable this particular GPO along with other GPO’s, even if Software Restriction Policies are used. You can read more about this tool here:
http://www.sysinternals.com/blog/2005/12/circumventing-group-policyas-limited.html
User permissions at your service
If you’re building a new baseline client from scratch, then you actually have an option to control access to the various generic storage devices based on user groups. The Microsoft KB article KB823732 covers this in more detail, but the idea is that you change the permissions and deny one or more security groups access to the PNF and INF files associated with the driver you want to control.
There is however another way you can control this, by making sure that the user is running as a non-admin. You can find more information on this subject here:
- http://www.windowsnetworking.com/articles_tutorials/Running-Windows-Under-Non-Admin-Accounts.html
- http://www.windowsecurity.com/articles/Running-Windows-Under-Non-Admin-Accounts.html
What happens is that when a user tries to install a new piece of hardware for the first time, he will be denied this action, unless those rights specifically have been added as figure 3 shows.
Figure 3
Disable the PnP Service
Some administrators will go to extreme measures and decide to disable the PnP Service that’s automatically started in Windows XP and Windows Server 2003 and also control this service from a GPO. The advantage with this approach is that it will actually make the computer start faster and solve the problem with device control, assuming the devices haven’t been added to the computer before this setting was activated. However it does require that your deployment approach is based on a very strict deployment strategy, since the process can be very difficult to administrate. Secondly, technologies such as two-factor authentication in terms of smart cards or USB tokens will not work, since these technologies and their services depend on the PnP Service being started beforehand.
Conclusion
As you can see, there are several challenges with device control in Windows XP and Windows Server 2003 and there really isn’t a perfect built-in solution when it comes to device control. So the real question is what should you do?
- Wherever possible, make sure that your users don’t have local admin rights
- If you want real device control that works, then the best solution is a 3rd party solution from companies such as SecureWave, GFI or ControlGuard etc.
- Make sure that the device control is based on whitelists (maintaining a list of devices that are allowed) instead of blacklists (maintaining a list of devices that are not allowed). This will reduce the complexity, the administrative burden and actually strengthen the overall security
In the next article we’ll take a closer look at the above principles and also give you an insight into why and how Windows Vista is capable of delivering the missing pieces with respect to device control, compared to Windows XP and Windows Server 2003.
If you would like to read the next part in this article series please go to Best practice security guide to built-in device control in Windows (Part 2).
