Share via


Windows Vista Security Guide

Chapter 3: Protect Sensitive Data

Each year, hundreds of thousands of computers without appropriate safeguards are lost, stolen, or improperly decommissioned around the world. The 2006 CSI/FBI Computer Crime and Security Survey reported that the costs associated with data loss have grown 65 percent in the previous year.

Effective technology features and services to help counter the risk of data theft or exposure was a primary customer request for Microsoft to include in Windows Vista™. This is in part because malicious users can often run a different operating system on a client computer, move its disk drive to another computer, or use other offline attack methods to view data on lost or stolen computers. In many cases, recent legislation and government regulations to safeguard consumer information and privacy also have made securing data a legal requirement.

For these security reasons, Microsoft has developed both new and enhanced features and services to help organizations better protect the data that resides on their client computers. The features and services that this chapter discusses are designed to protect data on client computers running Windows Vista in the Enterprise Client environment. The configuration of these features depends on your specific requirements and environment. This chapter provides you with a design process to identify how to configure the following features and services to better meet your data protection needs:

  • BitLocker™ Drive Encryption
  • Encrypting File System (EFS)
  • Rights Management Services (RMS)
  • Device control

You can use BitLocker, EFS, RMS, and device control to help protect sensitive data in the enterprise. However, each technology and method performs specific functions to help secure data. In fact, all these technologies and methods are complimentary elements of data protection, and Microsoft highly recommends using them in an enterprise’s overall security strategy. You can use each separately or together, depending on the security needs of your organization. The following table provides examples of how these technologies and methods work to protect different scenarios within an enterprise.

Table 3.1 Data Protection Technology Comparison in Windows Vista

Scenario BitLocker EFS RMS Device control

Laptop data protection

 

Branch office server data protection

   

Local single-user file and folder protection

   

Desktop data protection

 

Shared computer file and folder protection

 

   

Remote file and folder protection

 

   

Untrusted network administrator protection

 

   

Remote document policy enforcement

   

 

Protect content in transit

   

 

Protect content during collaboration

   

 

Protect against data theft

     

On This Page

BitLocker Drive Encryption BitLocker Drive Encryption
Encrypting File System Encrypting File System
Rights Management Services Rights Management Services
Device Control Device Control
More Information More Information

BitLocker Drive Encryption

BitLocker Drive Encryption helps protect data on a client computer. The entire Windows volume is encrypted to help prevent unauthorized users from breaking Windows file and system protections, or viewing information offline on the secured drive. Early in the startup process, BitLocker checks the client computer's system and hardware integrity. If BitLocker determines an attempt has been made to tamper with any system files or data, the client computer will not complete the startup process.

BitLocker helps prevent a thief who starts another operating system or runs a software attack tool from bypassing the Windows Vista file and system protections or performing offline viewing of the files stored on the protected drive.

BitLocker Drive Encryption can lock the normal boot sequence until the user supplies a personal identification number (PIN) code or inserts a USB flash drive that contains the appropriate decryption keys. The maximum protection is obtained when the computer has a Trusted Platform Module (TPM 1.2) to protect user data, and to help ensure that a client computer running Windows Vista cannot be tampered with while the system is offline. For information on TPM technology, refer to the specifications and materials maintained on the Trusted Computing GroupWeb site. If no TPM is available, BitLocker can still help protect the data, but no system integrity validation is performed.

BitLocker is available in the Windows Vista Enterprise and Ultimate editions of the operating system for client computers.

Note   BitLocker provides protection for the Windows partition and is not a replacement for EFS. BitLocker does not encrypt data stored outside the Windows partition, but it does provide an added security layer for EFS by encrypting the EFS keys within the Windows partition.

Risk Assessment

Mobile computers are typically exposed to environments that are not secure in which there is a higher risk of them becoming lost or stolen. If malicious users gain physical control of a system, they can bypass many security measures designed to protect the system and data. Desktop computers in shared or public environments may also be at significant risk. The primary risk BitLocker is designed to mitigate is data theft from stolen or lost mobile computers.

When an attacker gains physical access to a computer, the potential consequences include:

  • The attacker can log on to Windows Vista and copy files.
  • The attacker can restart the client computer into an alternate operating system to:
  • View file names.
  • Copy files.
  • Read the contents of the hibernation file or paging file to discover plaintext copies of in-process documents.
  • Read the contents of the hibernation file to discover plaintext copies of software private keys.

Even if files are encrypted using EFS, a careless user might move or copy a file from an encrypted location to an unencrypted location, which could leave the file information formatted in plaintext. Uninformed IT staff might also neglect to encrypt hidden folders, where applications keep backup copies of in-process files. There are also operational risks, such as unauthorized personnel tampering and modification of system and boot files, which may prevent normal system operation.

Risk Mitigation

To mitigate these risks, the computer should protect the boot sequence so that the system will only start when authorized. In addition, the operating system and data files should be protected.

Mitigation Considerations

BitLocker can mitigate the risks defined in the previous “Risk Assessment” section. However, before you use BitLocker, it is important to consider the following requirements and best practices for this data protection feature:

  • In order to use BitLocker in the optimal configuration, the motherboard on the client computer must provide a TPM 1.2 chip that includes a Trusted Computing Group–compliant BIOS implementation. In addition, a startup key is optionally required to provide an additional authentication factor. The startup key is either an additional physical key (a USB flash drive with a machine-readable key written to it) or a PIN entry that the user sets. Strong user logon and password protocols are also required.

  • You must partition the computer hard drive correctly to use BitLocker. Two NTFS drive volumes are required for BitLocker: one for the system volume, and one for the operating system volume. The system volume partition should be at least 1.5 GB.

  • BitLocker configurations that do not take advantage of external key authentication might be susceptible to hardware-based attacks.

  • If you use BitLocker with a USB key or a PIN, you must establish procedures to address lost keys and forgotten PINs.

  • BitLocker does have a small effect on system performance, but this is typically unnoticeable. However if system performance is critical, for example on a server, you must thoroughly test the configuration to ensure that the overhead that BitLocker causes does not significantly affect performance.

  • Depending on the computer vendor, TPM management tools may require manual steps to configure the TPM device state and a BIOS administrator password during the build process, which may prevent fully automated or scripted system deployments and upgrades.

  • To use a TPM device, it must have an Endorsement Key (EK) Credential applied to it, which the computer vendor can provide or a Value Added Reseller (VAR), or IT support staff could provide after the system has been delivered. The EK must be securely stored, and tracked while the computer is in use.

  • If TPM is not available on the computer, the computer should support USB devices when it starts to use a startup key to unlock the volume during the boot sequence.

  • BitLocker may have an impact on your software distribution procedures if software or system updates are distributed remotely and overnight, and you restart user computers without the user present. For example:

  • If a computer has a protector type of TPM and a PIN or TPM and a startup key, and at 2:00 A.M. you deploy a software update to the computer that requires the computer to restart, the computer will not restart without the PIN or startup key.

  • If you currently use Wake-on-LAN or a BIOS auto-power on feature to start computers for maintenance purposes, these computers would also be affected by a TPM and PIN or startup key protector.

  • OEM-distributed BIOS/TPM firmware updates may affect BitLocker-enabled computers. You will need to review OEM installation instructions to determine whether recovery information (recovery passwords and keys) will be preserved after the update, and if additional protectors (PINs or startup keys) also will be preserved.

  • Application updates may affect BitLocker-enabled computers. If, during installation or updating, the updates make changes to the boot manager or files that BitLocker measures, this will cause a system boot failure and force the computer into recovery mode. Before installing or updating applications that affect the Windows Vista boot environment, test them on BitLocker-enabled computers.

  • All domain controllers in the domain must be running Microsoft® Windows Server® 2003 with Service Pack 1 (SP1) or later.

Note   Windows Server 2003 requires you to extend the schema to support storing BitLocker recovery information in the Active Directory® directory service.

Mitigation Process

Use the following risk mitigation process to assess how best to configure BitLocker to help protect sensitive data on the client computers that you manage.

To use this mitigation process

  1. Investigate BitLocker technology and capabilities.
  2. Assess the need for BitLocker in your environment.
  3. Confirm that the hardware, firmware, and software that your organization uses meets BitLocker requirements.
  4. Identify the systems in your organization that require BitLocker protection.
  5. Identify the level of protection your systems require. A PIN or USB key containing encryption keys can be required to start the operating system. The operating system will not start without these keys.
  6. Install necessary drivers on a test system.
  7. Use Group Policy objects (GPOs) to configure BitLocker on test systems.
  8. After a successful test, install the drivers and configure BitLocker on production systems.

Using Group Policy to Mitigate Risk for BitLocker

There are two Group Policy templates that Microsoft recommends using to manage the configuration of BitLocker. These templates allow you to manage TPM configuration separately from the rest of the BitLocker. The following table outlines the Group Policy settings that are available for BitLocker in the VolumeEncryption.admx template. You can configure these settings in the following location within the Group Policy Object Editor:

Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption

Table 3.2 BitLocker Drive Encryption Settings

Policy setting Description Windows Vista default

Turn on BitLocker backup to Active Directory Domain Services

Enables the backup of BitLocker recovery information in Active Directory. This recovery information includes the recovery password and some unique identifier data.

Not configured

Control Panel Setup: Configure recovery folder

Configures whether the BitLocker setup wizard asks the user to save the recovery key to a folder. Specifies the default path that displays when the BitLocker Setup Wizard prompts the user to type the location of a folder in which to save the recovery key.

Not configured

Control Panel Setup: Configure recovery options

Configures whether the BitLocker Setup Wizard asks the user to create a recovery password. The recovery password is a randomly generated 48-digit sequence.

Not configured

Control Panel Setup: Enable advanced startup options

Configures whether the BitLocker Setup Wizard asks the user to create a PIN on the computer. The PIN is a 4–20 digit sequence that the user types each time the computer starts. You cannot use policy to set the number of digits.

Not configured

Configure encryption method

Configures the encryption algorithm and key size that BitLocker uses. This policy setting applies to a fully decrypted disk. If the disk is already encrypted or if encryption is in progress, changing the encryption method has no effect.

Not configured

Configure TPM platform validation profile

Configures how the TPM secures the disk volume’s encryption key. This policy setting does not apply if the computer does not have a compatible TPM, nor does changing this policy affect existing copies of the encryption key.

Not configured

The previous table provides a simple description for each setting. For more information about a specific setting, see theExplain tab of the setting in the Group Policy Object Editor.

The following table outlines the Group Policy settings available for the TPM in the TPM.admx template. You can configure these settings in the following location in the Group Policy Object Editor:

Computer Configuration\Administrative Templates\System\Trusted Platform Module Services

Table 3.3 Trusted Platform Module Settings

Policy setting Description Windows Vista default

Turn on TPM backup to Active Directory Domain Services

Manages the backup of (TPM recovery information in Active Directory. This recovery information includes a cryptographic derivation of the TPM owner password.

Not configured

Configure the list of blocked TPM commands

Manages the Group Policy list of TPM commands blocked by Windows.

Not configured

Ignore the default list of blocked TPM commands

Manages enforcement of the computer’s default list of blocked TPM commands.

Not configured

Ignore the local list of blocked TPM commands

Manages enforcement of the computer’s local list of blocked TPM commands.

Not configured

This table provides a simple description for each setting. For more information about a specific setting, see the**Explain** tab of the setting in the Group Policy Object Editor.

Your security policies must effectively support BitLocker password and key management. These policies should be comprehensive enough to secure the information, but not so restrictive as to make supporting BitLocker difficult. The following list includes policy examples:

  • Always require backup of recovery passwords in Active Directory.
  • Always require backup of TPM owner information in Active Directory.
  • Use recovery keys along with recovery passwords as a backup or alternate recovery method.
  • If you are using TPM and a PIN or USB startup keys, change them on a regularly scheduled basis.
  • On TPM-enabled computers, use a BIOS administrator password to prohibit access.
  • Ensure that users do not store key material such as USB startup keys with the computer.
  • Save recovery keys to a central location for support and disaster recovery purposes.
  • Backup recovery material to secure offline storage.

Top Of Page Top of page

Encrypting File System

You can use Encrypting File System (EFS) to encrypt files and folders to help protect data from unauthorized access. EFS is integrated into the NTFS file system and its operation is completely transparent to applications. When a user or program attempts to access an encrypted file, the operating system automatically attempts to acquire a decryption key for the content, and then silently performs encryption and decryption on behalf of the user. Users who have authorized keys are able to access and work with encrypted files just as they would with any other file, whereas other users are denied access. Windows Vista includes many new security, performance, and manageability features for EFS. The following are new features in Windows Vista for EFS:

  • You can store User keys on smart cards.
  • You can store recovery keys on smart cards, allowing secure data recovery without a dedicated recovery station, even over Remote Desktop sessions.
  • You can encrypt the Windows paging file using EFS with a key that is generated when the system starts up. This key is destroyed when the system shuts down.
  • You can encrypt the Offline Files cache with EFS. In Windows Vista this encryption feature employs the user’s key instead of the system key. Thus, each file in the Offline Files cache can only be accessed by the user on whose behalf it is cached.
  • Many new configuration options are provided in Group Policy to help enforce enterprise policies.
  • EFS supports a wider range of user certificates and keys.

A number of new Group Policy options have been added to Windows Vista to help administrators define and implement organizational policies for EFS. These include the ability to require smart cards for EFS, enforce page file encryption, stipulate minimum key lengths for EFS, and enforce encryption of the user’s Documents folder.

Note   Microsoft recommends using BitLocker and EFS in combination to maximize data protection.

Risk Assessment

Unauthorized access to data can compromise business processes and profitability. Especially where multiple users have access to the same system or you use mobile computer systems, data is at risk of compromise. The risk area that EFS is designed to mitigate is data theft or compromise due to lost or stolen mobile computers, or due to exposure by an insider. Shared computers might also be subject to this data risk.

When an attacker gains physical access to a computer with unencrypted data, the potential consequences include:

  • The attacker may restart the computer and escalate their user privilege to local Administrator to access the user's data. An attacker also could download tools to mount a brute-force attack to obtain the user's password, so they can then log on as the user and access the user's data.
  • The attacker could attempt to log on to Windows Vista and copy all data that is available to the user to a removable device, send it via e-mail, copy it over the network, or transmit it using FTP to a remote server.
  • The attacker could restart the computer into an alternate operating system and copy files directly from the hard drive.
  • The attacker could plug the computer into another network, start the stolen computer, and then log on to it remotely.
  • If a user caches their network files in Offline Files, an attacker can escalates privilege to Administrator/LocalSystem and inspect the contents of the Offline Files cache.
  • A curious coworker could open sensitive files owned by other users of a shared computer.
  • An attacker could restart the computer using an alternative operating system, read the contents of the paging file, and discover plaintext copies of in-process documents.

Risk Mitigation

To mitigate these potential data compromise risks, you can encrypt data when it is stored on the hard disk. Improvements in the EFS technology in Windows Vista help you to mitigate the following situations:

  • You can use EFS to prevent an attacker from reading encrypted files through another operating system by requiring the attacker to obtain a key that is capable of decrypting the content. You can store such a key on a smart card for added security.
  • You can enforce the strength of encryption that EFS uses through Group Policy.
  • You can thwart an attacker who attempts to access a user’s data using a brute-force password attack by storing the user’s EFS keys on a smart card, or by using BitLocker in combination with EFS to deny the attacker access to the user’s password hashes and cached credentials.
  • You can prevent an attacker from accessing a user’s confidential data by enforcing encryption of the user’s Documents folder through Group Policy. Alternatively, you can enforce encryption of other locations or the user’s entire data partition through a logon script.
  • You can use EFS to provide encryption on multiple drives and network shares.
  • You can use EFS to protect the contents of the system paging file and the Offline Files cache.

Mitigation Considerations

You can use EFS in Windows Vista to mitigate the risks described in the previous Risk Assessment section. However, before deploying EFS, consider the following:

  • You must implement tested procedures for key management and data recovery requirements. In the absence of reliable and well-defined procedures, critical data may become inaccessible if keys are lost.
  • Under normal operation, the overhead due to EFS is not noticeable. However, if system performance is critical, you must perform thorough testing to ensure that EFS does not adversely affect performance.
  • If you enable EFS on a volume, you cannot also compress files on the same volume.
  • If necessary, deploy and test additional scripts to encrypt sensitive file locations.
  • Users and IT staff must be properly trained to avoid issues, such as:
  • copies or file moves from an encrypted location to an unencrypted location, which could leave the files formatted as plaintext files.
  • Failure to encrypt hidden folders where applications maintain backup copies of in-process files.
  • Thoroughly test your EFS configuration to ensure that encryption is set on all sensitive file locations, including Documents, the Desktop, and temporary folders.

Note   You can only deploy EFS on the following Windows Vista editions: Business, Enterprise, and Ultimate.

Mitigation Process

Use the following risk mitigation process to assess how best to configure EFS to help protect sensitive data on the client computers that you manage.

To use this mitigation process

  1. Investigate EFS technology and capabilities.

Note   For more information, see the "Best practices for the Encrypting File System" article on Microsoft.com.

  1. Assess the need for EFS in your environment.

  2. Investigate the configuration of EFS using Group Policy.

  3. Identify the computer systems and users that require EFS.

  4. Identify the level of protection that you require. For example, does your organization require using smart cards with EFS?

  5. Configure EFS as appropriate for your environment using Group Policy.

Specific Mitigation Steps for EFS

To use Group Policy to manage EFS there are several security settings in this location:

Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System

To add or create a Data Recovery Agent (DRA), right-click Encrypting File System, and then click Properties to open the Encrypting File System Properties dialog box.

Figure 3.1 The Encrypting File System Properties dialog box

Figure 3.1 The Encrypting File System Properties dialog box

There are also four Group Policy templates that include EFS settings, which are listed in the following table.

Table 3.4 EFS Group Policy Settings

Template and setting Path and description Windows Vista default

GroupPolicy.admx
EFS recovery policy processing

Computer Configuration\
Administrative Templates\
System\Group Policy

Determines when encryption policies are updated.

Not configured

EncryptFilesonMove.admx
Do not automatically encrypt files moved to encrypted folders

Computer Configuration\
Administrative Templates\
System\

Prevents Windows Explorer from encrypting files that are moved to an encrypted folder.

Not configured

OfflineFiles.admx
Encrypt the Offline Files cache

Computer Configuration\
Administrative Templates\
Network\Offline Files\

This setting determines whether offline files are encrypted.

Note   On Windows XP, these files are encrypted with the system key whereas on Windows Vista they are encrypted with the user’s key.

Not configured

Search.admx
Allow indexing of encrypted files

Computer Configuration\
Administrative Templates\
Windows Components\
Search\

This setting allows encrypted items to be indexed by Windows Search.

Note   There may be data security issues if encrypted files are indexed and the index is not adequately protected by EFS or another means.

Not configured

 

This table provides a simple description for each setting. For more information about a specific setting, see the Explain tab of the setting in the Group Policy Object Editor.

Top Of Page Top of page

Rights Management Services

Rights Management Services (RMS) is designed to provide security and usage policy enforcement for sensitive e-mail, documents, Web content, and other types of information. RMS provides information security by encrypting information persistently so that as a file or e-mail message is transmitted through the enterprise or the Internet, only those who are authenticated and explicitly authorized to access it can do so. There are three components to RMS:

  • RMS server. Windows Vista requires Windows Rights Management Services for Windows Server 2003 or later.
  • RMS client. This is included with Windows Vista.
  • RMS platform or application. This is a platform or application that is designed to encrypt and control usage of the information it manages.

Risk Assessment

The risk to an organization that RMS can help mitigate is that unauthorized personnel may be able to view sensitive information. This information may have been distributed or made available to unauthorized users either in error or maliciously. Specific examples of this type of risk include:

  • Unauthorized users sniff the network, access USB flash and portable hard drives, or access insufficiently protected server shares and storages.
  • Authorized users send sensitive information to unauthorized recipients inside or outside the organization.
  • Authorized user’s copy or move sensitive data to unauthorized locations or applications, or from an authorized device to an unauthorized device, such as a removable storage device.
  • Authorized users accidentally provide access to sensitive information to unauthorized recipients via peer-to-peer (P2P) technologies or instant messaging.
  • Authorized users print sensitive files, and the printed documents are found by unauthorized users and distributed, copied, faxed, or sent via e-mail.

Risk Mitigation

To effectively protect information that users share and collaborate with regardless of the mechanism they use, Microsoft recommends securing the information directly via RMS so that it is seamlessly protected as it is transmitted between hosts, devices, and shares.

Mitigation Considerations

You can use RMS to mitigate the risks described in the previous “Risk Assessment” section. However, before deploying RMS, consider the following:

  • RMS requires Windows Rights Management Services for Windows Server 2003 or later, as the RMS server, and rights-enabled applications installed on the client computer.
  • Microsoft SharePoint® Server is required if you want to make use of SharePoint-RMS integration (where RMS protects documents and information that reside on SharePoint sites).
  • If you want to take advantage of the optional smartcard integration of the RMS solution, ensure that each client computer that you use to access the content is compatible with the smartcards.
  • To use Web-based applications such as Outlook Web Access (OWA) with RMS, the Rights Management Add-on for Internet Explorer is required.
  • IT staff will require training to successfully deploy, support, and troubleshoot RMS.

Mitigation Process

Use the following risk mitigation process to assess how best to configure RMS to help protect sensitive data on the client computers that you manage.

To use this mitigation process

  1. Investigate Rights Management Services technology and capabilities.
  2. Assess the need for Rights Management Services in your environment.
  3. Identify support of applications and services for Rights Management Services.
  4. Assess potential RMS deployment architectures, such as:
  • Single server (or single cluster)
  • Single certification, single license
  • Single certification, multiple license
  • Multiple certification, single license
  • Multiple certification, multiple license
  1. Identify information that you want to secure using Rights Management Services.
  2. Identify users and groups that require access to specific information.
  3. Configure Rights Management Services to allow only required access to information.

Managing RMS Using Group Policy

The Group Policy settings for the configuration of RMS are not part of the Windows Vista installation. RMS is primarily a server-based solution so the configuration of the services behavior should be configured on the RMS server.

In addition, RMS-aware applications may have individual settings that govern how they will handle RMS protected content. For example, there are RMS related settings for Microsoft Office 2003 or later, and applications such as Microsoft Outlook® and Microsoft Word. For more information on these settings see the Office 2003 Policy Template Files and Deployment Planning Tools.

Top Of Page Top of page

Device Control

The ability of users to add new Plug and Play (PnP) hardware to their client computers such as USB key drives or other removable storage devices creates significant security issues for IT administrators. Not only can these types of devices make client computers harder to maintain when users use them to install unsupported hardware, but they can pose threats to data security.

A malicious user can potentially use a removable storage device to steal a company’s intellectual property. An attacker also could use a removable storage device with malicious software configured on it that includes an "autorun" script to install malicious software on an unattended client computer.

Windows Vista enables IT administrators to use Group Policy to help manage installation of unsupported or unauthorized devices. For example, you can allow users to install entire classes of devices (such as printers), but disallow any kind of removable storage device. An administrator can be allowed to override these policies, to install authorized hardware.

However, it is important to understand that a device is installed for a computer not for particular users. After a user has installed a device, it is typically available for all users of that computer. Windows Vista now supports user-level access controls for read and write access to installed devices. For example, you can allow full read and write access to an installed device such as a USB flash drive to one user account, but only allow read access to another user account on the same computer.

Risk Assessment

Unauthorized addition or removal of devices comprises a high security risk because it can enable an attacker to run malicious software, remove data, and add unwanted data. The following includes some examples:

  • An authorized user may copy sensitive files from an authorized device to an unauthorized removable storage device, either intentionally or unintentionally. This may include copying from an encrypted location to an unencrypted location on a removable device.
  • An attacker may log on to Windows Vista and copy data to a removable storage device.
  • An attacker could use a removable storage device with malicious software to use an AutoRun script to install malicious software on an unattended client computer.
  • An attacker could install an unauthorized key-logging device, which could be used to record user account details that could be used to launch a further attack.

Risk Mitigation

To mitigate these risks, Microsoft recommends protecting the computer systems you manage against the installation and use of unauthorized devices. You can use Group Policy settings to control the use of PnP devices, such as USB flash drives and other removable storage devices.

Mitigation Considerations

You can use Group Policy in Windows Vista to mitigate the risks described in the previous "Risk Assessment" section by using the Device Installation settings. However, before deploying device control to the client computers in your environment, take into account the following mitigation considerations:

  • Restricting devices may block legitimate file sharing or mobile users from working most effectively.
  • Restricting devices can prevent you from using a USB key as part of the BitLocker drive encryption process. For example, if the Removable Disks: Deny write access policy setting is in effect for a user, even if that user is an administrator, the BitLocker setup program will not be able to write its startup key to a USB flash drive.
  • Some devices identify themselves with both a "removable storage" and a "local storage" ID, for example some bootable USB flash drives may do this. Therefore, it is important to thoroughly test your GPOs to ensure that the correct devices are restricted and allowed.

Mitigation Process

Use the following risk mitigation process to assess how best to configure device control to help protect sensitive data on the client computers that you manage.

To use this mitigation process

  1. Investigate the device control capabilities of Windows Vista.
  2. Assess the need for device control in your environment.
  3. Investigate the Group Policy settings for device control.
  4. Identify removable devices that you require in your environment and record the required Hardware or Compatibility IDs for these devices.
  5. Identify the computer systems and users that require the removable devices.
  6. Configure Group Policy to enable installation of specifically required device classes.
  7. Configure Group Policy to enable installation of devices on computer systems that specifically require the capability.

Using Group Policy to Control Device Installation

To manage the control of device installation, Microsoft recommends using the DeviceInstallation.admx Group Policy template. Table 3.5 outlines the Group Policy settings available in that template. You can configure these settings in the following location in the Group Policy Object Editor:

Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions

Table 3.5 USB Device Control Settings

Policy setting Description Windows Vista default

Allow administrators to override Device Installation policies

Allows members of the Administrators group to install and update the drivers for any device, regardless of other policy settings. Otherwise, administrators are subject to all policies that restrict device installation.

Not configured

Allow installation of devices using drivers that match these device setup classes

Specifies a list of device setup class GUIDs describing devices that users can install, unless specifically prevented by the following policy settings:
Prevent installation of devices that match these device IDs
Prevent installation of devices for these device classes
Prevent installation of removable devices
.
Only use this setting when the Prevent installation of devices not described by other policy settings setting is enabled.

Not configured

Prevent installation of devices using drivers that match these device setup classes

Specifies a custom message that displays to the user in the title of the notification balloon when this policy prevents the installation of a device.

Not configured

Display a custom message when installation is prevented by policy (balloon title)

This setting specifies a custom message that displays to the user in the title of the notification balloon when a policy setting prevents an installation from installing.

Not configured

Display a custom message when installation is prevented by policy (balloon text)

This setting specifies a custom message that displays to the user in the text of the notification balloon when policy prevents the installation of a device.

Not configured

Allow installation of devices that match any of these device IDs

Specifies a list of Plug and Play hardware IDs and compatible IDs that describe devices that can be installed, unless the following settings specifically prevent this:
Prevent installation of devices that match these device IDs
Prevent installation of devices for these device classes
Prevent installation of removable devices
.
Only use this setting when the setting for Prevent installation of devices not described by other policy settings is enabled.

Not configured

Prevent installation of devices that match any of these device IDs

Specifies a list of Plug and Play hardware IDs and compatible IDs for devices that users cannot install.
Note   This policy setting takes precedence over any other policy settings that allows a device to install.

Not configured

Prevent installation of removable devices

If you enable this setting, users may not install removable devices, and existing removable devices cannot receive driver updates.
Note   This policy setting takes precedence over any other policy settings that allows a device to install.
For this policy to apply, the drivers for the device must correctly identify that the device is removable.

Not configured

Prevent installation of devices not described by other policy settings

If you enable this setting, any device that is not described by the following settings cannot update their drivers:
Allow installation of devices that match these device IDs
Allow installation of devices for these device classes
.

Not configured

This table provides a simple description for each setting. For more information about a specific setting, see the Explain tab of the setting in the Group Policy Object Editor.

Using Group Policy to Control Device Usage

In addition to helping you control the installation of devices, Windows Vista allows you to control the level of access users have to particular device classes after they have been installed. There are two other templates described in the following tables that contain settings that can affect the behavior of devices: RemovableStorage.admx contains the following setting for removable storage devices, and it is located at the following location in the Group Policy Object Editor:

Computer Configuration\Administrative Templates\System\Removable Storage Access

Table 3.6 Device Settings

Policy setting Description Windows Vista default

All Removable Storage classes: Deny all access

Configures access to all removable storage devices classes.

Not configured

All Removable Storage: Allow direct access in remote sessions

This setting grants standard user accounts access to removable storage devices in remote sessions. The default configuration does not allow this access for remote sessions.

Not configured

CD and DVD: Deny read access

This setting denies read access to the CD and DVD removable storage class. The default setting will allow read access.

Not configured

CD and DVD: Deny write access

This setting denies write access to the CD and DVD removable storage class. The default setting will allow write access to this device class.

Not configured

Custom Classes: Deny read access

This setting denies read access to custom device classes. The default setting allows read access.

Not configured

Custom Classes: Deny write access

This setting denies write access to custom device classes. The default setting allows write access to this device class.

Not configured

Floppy Drives: Deny read access

This setting denies read access to floppy drives. The default setting allows read access.

Not configured

Floppy Drives: Deny write access

This setting denies write access to floppy drives. The default setting allows write access to this device class.

Not configured

Removable Disks: Deny read access

This setting denies read access to removable drives. The default setting allows read access.

Not configured

Removable Disk: Deny write access

This setting denies write access to removable drives. The default setting allows write access to this device class.

Not configured

Tape Drives: Deny read access

This setting denies read access to tape drives. The default setting allows read access.

Not configured

Tape Drives: Deny write access

This setting denies write access to tape drives. The default setting allows write access to this device class.

Not configured

WPD Devices: Deny read access

This setting denies read access to Windows portable devices, such as media players and mobile phones. The default setting allows read access.

Not configured

WPD Devices: Deny write access

This setting denies write access to Windows portable devices such as media players, mobile phones, and so on. The default setting allows write access to this device class.

Not configured

This table provides a simple description for each setting. For more information about a specific setting, see the Explain tab of the setting in the Group Policy Object Editor.

Using Group Policy to Control AutoPlay and AutoRun

The Autoplay.admx template contains the following settings that affect the AutoPlay and AutoRun behavior for removable storage devices and removable media in Windows Vista. You can find the settings for this template in the following location the Group Policy Object Editor:

Computer Configuration\Administrative Templates\Windows Components\AutoPlay Policies

Table 3.7 AutoPlay Policy Settings

Policy setting Description Windows Vista default

Turn off Autoplay

Allows you to disable the autoplay feature for CD, DVD-ROM, and removable drives or all drives.

Not configured ‡

Default behavior for AutoRun

This setting configures the default behavior for AutoRun commands. By default Windows Vista prompts the user to confirm whether the AutoRun command should run.

Not configured

This table provides a simple description for each setting. For more information about a specific setting, see the Explain tab of the setting in the Group Policy Object Editor.

These settings also appear under the user configuration at the following location the Group Policy Object Editor:

User Configuration\Administrative Templates\Windows Components\AutoPlay Policies

If the device control settings conflict, the setting in the computer configuration takes precedence over the user configuration setting.

Note   Some policy settings specify the use of device setup class GUIDs, and others use Plug and Play device setup class GUIDs For more information, see How Setup Selects Drivers.

Top Of Page Top of page

More Information

For additional information about the new and enhanced security features and technologies to help protect sensitive data in Windows Vista, see the following resources:

Top Of Page Top of page

In This Article

Download

Get the Windows Vista Security Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions