Best practice security guide to built-in device control in Windows

Thanks to: http://www.windowsecurity.com/

Your security should be proactive and fail well

When it comes to security, you should always try to implement proactive security measures whenever possible. By that, I mean trying to protect your systems from both known and unknown threats. You may ask yourself how this can be done, since you probably wouldn’t know where to start or end when trying to protect against the unknown? Well the keyword here is least privilege and whitelists. It’s impossible to protect your system against any known or unknown attack; however it is possible to limit the damage, if or when it occurs. The way you do this is by making sure that your systems fails well. In other words, you should ensure that if one of your systems is compromised, then the damage is limited to a very small area of your system. It’s almost considered an art (and most often a challenge) trying to design a secure system that fails well. One of the principles you should use when designing such solutions is “security in depth”, which you've probably heard a lot about before. This principle is illustrated in figure 1.

Figure 1: Layered security a.k.a. “security in depth”

The idea behind “security in depth” is to design solutions that consist of several independent security layers, that all have the purpose of protecting your assets. In order for a malicious user to gain access to the assets you’re trying to protect, he’ll have to circumvent each of the defensive measures you (hopefully) have implemented at each layer including the human layer which is not illustrated in figure 1. This principle will help your system fail well, in case it gets compromised in one or more of the layers. With those principles in mind, let’s move on and look at some examples on how we can implement proactive security measures with respect to device control in Windows Vista.

Device Installation Control

Windows Vista is loaded with various security features, compared to its predecessors that we covered in part 1 of this article series. One of these features is Device Installation Control, which basically gives you a granular way to control how and which hardware devices a user is allowed to install on his computer. Microsoft has written an excellent step-by-step on how to get started with device installation control, but we’ll try to go beyond Microsoft’s article and show you a few examples on how to apply our before mentioned principles in using least privilege and whitelists. Before we show you how, beware of the following caveats:

• Devices must not have been installed ahead of time on the computers you want to control. This means that if you use a standard installation deployment image, make sure that no unwanted devices have been used beforehand when maintaining your baseline image.
• Because of the first piece of advice explained in the previous bullet, you should use a separate computer, where you extract the various device classes or device IDs you may want to restrict or use for your whitelists.
• Note that built-in device control in Vista is computer based. This means that all users on the computers being controlled will be affected. One workaround is to create different device restriction GPO’s and filter the scope of the GPO’s according to security group membership. However if you want true user based device control, then you still need to look at 3rd party solutions.

With these pointers in mind, it’s time to move on and look at some examples.

Example 1: Least privilege device control

In this example we’ll show you how to prevent any user (including those with local admin rights) from installing any additional hardware devices on a Vista computer.

We will use the Group Policy Management Console, so from Vista you’ll have to log on with a domain account that has the rights to modify Group Policies

At the Vista Start | Search command prompt you type GPMC.MSC and press Enter

1. Navigate to Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions
2. Configure the following settings (as displayed in figure 2 below)
   • Allow administrators to override device installation policy: Here you select Disabled
   • Display a custom message when installation is prevented by policy (balloon text) : Select Enabled and insert your own customized text
   • Display a custom message when installation is prevented by policy (balloon title) : Select Enabled and insert your own customized text
   • Prevent installation of devices not described by other policy settings: Here you select Enabled
     Note: Some of the policy settings have the same function as above if they have the default setting “Not configured”. This is due to Vistas’ secure by default design. However, I recommend you still configure the settings specifically since the settings are more self-explanatory for example, when you use the reporting feature in the Group Policy Management console.

Figure 2: Prevent anyone from installing any additional hardware

3. After we have applied the GPO, it’s time to take our settings  for a test run as figures 3, 4 and 5 show you

Figure 3: A USB key is inserted into the computer

Figure 4: Our device restriction policy is working using a custom message

Figure 5: In Device Manager you see that the USB key hasn’t been installed

Let us move on to the next example.

Example 2: Device control using whitelists

In this example we’ll show you how to prevent any regular user from installing any additional hardware devices except those that are on a whitelist. Now, before we proceed you should know a few things about device classes and device IDs (a.k.a. hardware IDs). Figures 6 and 7, show you what we mean by device classes and device IDs taken from the Device Manager console.

Figure 6: A quick overview of device classes

Figure 7: A quick overview of device IDs

For this example we’ll show you how to use the most granular feature in Windows Vista with respect to device restrictions, which is based on device IDs.

You can either gather the device classes and device IDs for devices you want to restrict or allow, using the GUI in Device Manager which by any means is the most user friendly approach or you can be cooler and use the command line. In this article we’ll show you how to use a nifty little command line tool from Microsoft called DevCon which can be found here.

Copy the DevCon command line utility to your Vista reference machine and open the command line as an Administrator. We’re not going to go through all the command line options here, but simply show you how to use DevCon for our particular example.

1. At the command line you type the following command as displayed in figure 8:
   
   devcon classes
   This command will display all the device classes there are on your reference computer, where we’ll use the USB device class in the next step.

Figure 8: Here’s a complete list of all device classes on our sample computer

2. In our example we’ll only allow a 4GB USB key, so we need the device ID from this device. Assuming the device that has already been installed on our reference computer, we type the following command as displayed in figure 9:
   
   devcon hwids usb*
   Notice a couple of things with this command line example. The second parameter ‘usb’ was located when we used the previous DevCon command where we located the various device classes. Secondly we add an ‘asterix’ since this will cover all USB devices installed on our reference machine. Locate the hardware ID as shown in figure 9 and copy the hardware ID before you continue.

Figure 9: Here’s one way to locate a specific hardware ID from the command line

Note: It is important that you are aware of which hardware ID you copy. When working with whitelists, you should always copy the topmost hardware ID for a specific device. This will give you more granular control of which devices are allowed when using whitelists. If you implement blacklists, then you should consider using the lowermost hardware ID, since this will increase your security with respect to older devices, such as USB 1.1 storage devices etc. unless you want to restrict a specific device such as Ipod, etc.

Again, we’ll use the Group Policy Management Console, so from Vista you’ll have to log on with a domain account that has the rights to modify Group Policies

At the Vista Start | Search command prompt you type GPMC.MSC and press Enter

3. Navigate to Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions
4. Configure the following settings
   • Allow administrators to override device installation policy: Select Enabled
   • Display a custom message when installation is prevented by policy (balloon text) : Select Enabled and insert your own customized text
   • Display a custom message when installation is prevented by policy (balloon title) : Select Enabled and insert your own customized text
   • Allow installation of devices that match any of these device IDs: Select Enable and click Show… as showed in figure 10
   • Click Add... and add the hardware ID from step 2
   • Prevent installation of devices not described by other policy settings: Enabled

Figure 10: Here we add the hardware ID for a device that should be on our whitelist

5. Test your settings by adding both devices on the whitelists and devices not on the whitelists

Conclusion

Even though it’s not perfect, Device Installation Restrictions in Vista is a great feature and it actually has some additional benefits which we also briefly touched in part 1 of this article series, namely wireless communication devices. It is important that you realize that wireless devices can be used by a malicious user if not properly secured. By using Vista's Device Installation Restriction feature, you have the option to control how and what wireless communication devices are allowed. Now combine that with NAP or NAQ for compliance and Windows Advanced Firewall with IPSec for domain isolation and most importantly, user education. You’ll then be well on your way to building secure clients that are based on proactive security which fails well.