Chapter 1: Planning Considerations
Published: May 29, 2007
The process of deploying data encryption tools to protect data in your organization requires you to thoroughly understand the technologies included in Microsoft operating systems, as well as the security concerns of your specific environment. You must also be prepared to identify and resolve potential deployment issues involving your choice of client hardware and its configuration, your organization’s security policy, and the complex issues of regulatory compliance and auditing.
This chapter of the Planning and Implementation Guide focuses on the planning considerations involved in deploying Windows Vista™ with Microsoft® BitLocker™ Drive Encryption (BitLocker) and the Encrypting File System (EFS) component of Windows Vista and Microsoft Windows® XP.
BitLocker and EFS planning considerations discussed in this chapter include hardware and software requirements, determining what computers and data items need protection, and choosing appropriate configurations. Other considerations include Active Directory® directory service and Group Policy deployment issues, manageability, usability, and planning for effective data recovery.
For EFS, additional considerations involve integrating EFS with an existing public key infrastructure (PKI), deploying the Microsoft Encrypting File System Assistant (EFS Assistant), and planning for effective key recovery.
Plan for BitLocker Drive Encryption
The following actions must be performed to complete a plan to deploy BitLocker:
The following subsections discuss these BitLocker planning issues in more detail.
Understand BitLocker Deployment Options
BitLocker is an effective mitigation against many security threats. Understanding which threats BitLocker mitigates, and which additional threats can be mitigated by combining BitLocker with EFS, requires you to understand BitLocker's security model and the deployment options it supports. The Security Analysis document included with this Toolkit describes a range of risks and how BitLocker mitigates them. You should thoroughly familiarize yourself with its contents before proceeding with your planning process.
Evaluate BitLocker Readiness
To use BitLocker, a computer requires the following components:
You can confirm these requirements manually by using a Windows Management Instrumentation (WMI) script or PowerShell to query each client computer and gather information about its capabilities. Most organizations prefer to use a management tool such as Microsoft Systems Management Server (SMS) or a third-party equivalent, because these tools provide automated inventory and reporting facilities.
BitLocker Hardware Requirements
BitLocker can be run on any computer that complies with the system requirements for Windows Vista. (For more information about specific CPU, memory, and disk requirements, see the Windows Vista Enterprise Hardware Planning Guidance.) Although Microsoft has established separate “Windows Vista Capable” and “Windows Vista Premium Ready” categories for hardware that supports various Windows Vista features, BitLocker will work on any computer that supports Windows Vista.
To take advantage of the BitLocker support for TPM hardware, your computers must include TPM 1.2 or later hardware. Many manufacturers include TPM support as part of their standard products, and others offer it in limited subsets of their portable computer lines or not at all. There is no way to add TPM support to computers that do not already have it. However, you can use a USB key to store BitLocker encryption keys on computers that don’t include TPM hardware.
Computers that include TPM hardware must also have a BIOS version that enables Windows Vista to use the full set of TPM capabilities. Some computers that contain TPM 1.2 hardware might still require BIOS upgrades if they were shipped before January 2007. If you want to use BitLocker with a USB key, the BIOS must be able to read from the USB key during the boot process.
Note Some BIOS implementations support USB for booting the computer, but then disable this ability if the computer is booted from the hard disk or other device. These implementations are not compatible with BitLocker because it reads the USB key later in the boot process.
Each computer protected by BitLocker must have two disk partitions: one for the operating system and data, and a smaller partition used only when the computer is booted or during operating system upgrades. (You should not use this startup partition for other data storage.) Microsoft recommends that the startup partition have at least 1.5 GB of free space. Both of these partitions must be formatted using the NTFS file system (NTFS).
Users of Windows Vista Ultimate can use the Windows BitLocker Drive Preparation Tool to create the utility partition dynamically to enable the use of BitLocker. Users of the Enterprise edition can obtain the Drive Preparation Tool as described in Microsoft Knowledge Base article 930063, "Description of the BitLocker Drive Preparation Tool." Obtaining the tool requires a call to Microsoft Customer Support Services, but there is no charge for the call or for the tool. Microsoft does not support manually creating or moving partitions to create the required BitLocker partition configuration. You should either perform a clean installation of Windows Vista (creating partitions as part of the setup process) or use the Drive Preparation Tool.
If you plan to use USB flash drives as part of your BitLocker deployment, the models you use must implement the USB Mass Storage Class Bulk-Only Transport specification on the Universal Serial Bus Web site.
Understanding the TPM
Most organizations that deploy BitLocker will want the security benefits offered by computers that incorporate TPM hardware. Understanding this hardware and what it can provide is a critical part of choosing the appropriate BitLocker configuration for your organization. (A comprehensive examination of the TPM is outside the scope of this guide. For more specific information about the TPM and the Trusted Computing Group, see the Trusted Platform Module (TPM) Specifications page on the Trusted Computing Group Web site.)
It is important to understand the nature of the TPM, which is essentially a special-purpose microprocessor with its own I/O system and onboard storage. The TPM holds an endorsement key (EK) that is used to sign and encrypt data that comes directly from the TPM or that is passed to the TPM for signing or encrypting. The EK must be loaded onto the TPM, either by the computer manufacturer or automatically as part of BitLocker initialization.
You should also understand that the TPM can exist in one of several states at a given time:
These states can be combined. For example, some vendors ship TPM-enabled computers for which the TPM is in a default state of disabled, deactivated, and unowned. To use BitLocker on such a computer, you must establish ownership of the TPM, activate it, and enable it. These operations are automatically performed when you use the standard BitLocker user interface. When BitLocker is turned on, it will automatically enable, activate, and take ownership of the TPM if one is present.
You also need to understand the requirement for physical presence for some TPM operations. The Trusted Computing Group TPM specifications require that a person interact directly with the physical computer to perform some commands, and this person cannot be replaced or imitated through a script. Physical presence indicates that a user is asserting ownership and is physically present at the computer to perform basic TPM administrative tasks, such as:
BitLocker Software Requirements
Windows Vista is available in several different editions, but only the Enterprise and Ultimate editions support BitLocker. Microsoft includes the Windows Anytime Upgrade feature (described in the Windows Vista online help), which you can use to upgrade individual computers. For example, you can upgrade from the Business Edition to the Ultimate Edition with the Anytime Upgrade feature. (Some upgrade types might require reinstallation. For example, 32- to 64-bit upgrades require a reinstallation of the 64-bit version of Windows Vista.)
Note The guidance and tools in the Data Encryption Toolkit for Mobile PCs apply to both EFS (available in Windows XP Professional SP 2 and all versions of Windows Vista) and BitLocker (available in Windows Vista Enterprise and Windows Vista Ultimate). However, Windows Vista Ultimate has not been rigorously tested for support of all features of the guidance and tools. The Toolkit is primarily intended for use with Windows XP Professional SP 2 and the Enterprise and Business editions of Windows Vista.
Deploying Windows Vista
The Solution Accelerator for Business Desktop Deployment provides comprehensive guidance and tools for deploying Windows Vista to your organization's client computers. As you plan your Windows Vista deployment strategy, remember that enabling BitLocker will probably require you to have physical contact with each computer because the TPM cannot be initialized or reprogrammed except from the affected computer's console. Also, you might need to update the BIOS of your computers to take full advantage of BitLocker's features.
One critical deployment decision is whether to upgrade existing computers from Windows XP to Windows Vista or whether to perform a clean installation of the new operating system. BitLocker cannot be enabled until you install Windows Vista. However, you should be aware that BitLocker requires a particular disk partitioning configuration (as described in the Windows BitLocker Drive Encryption Step-by-Step Guide). If you need to upgrade existing computers that run Windows XP, your deployment plan must provide for building the required partition structure before you can activate BitLocker on those computers.
The Windows Vista Business Desktop Deployment (BDD) toolkit supports automatic enablement of BitLocker under some circumstances. See the Lite Touch Installation Guide for details about how to use the BDD tools to enable BitLocker as a part of the operating system deployment process.
Determine the Scope of BitLocker Deployment
After evaluating which parts of an organization have hardware and software that support one or more modes of BitLocker, the next step is to determine exactly where BitLocker should be deployed. The following questions need to be answered to complete this step and determine the eventual scope of BitLocker deployment:
Which Computers Need Protection?
Security decisions usually involve a tradeoff between protection and cost, and a BitLocker implementation is no exception. The best security strategy might seem at first to be to deploy Windows Vista on all client computers in an organization and to enable BitLocker on them. However, most organizations will need to synchronize widespread implementation of Windows Vista (and therefore BitLocker) with their overall IT deployment plan. Still, every organization can benefit from targeted implementation of Windows Vista and BitLocker to computers that pose the greatest potential risk. These computers include:
To determine which computers in your environment need protection, use an automated asset inventory (if possible) to identify computers that fit one of the above groupings. You might want to supplement an automated inventory with a manual cross-check that matches employees who work with sensitive data and the organization-owned computers that they routinely use. If your organization uses a pool of mobile computers that are assigned to specific locations, or that are available for employees to check out, consider including them as a separate category of computers that require protection.
Which Data Items Need Protection?
One of the greatest benefits of BitLocker is that it protects all contents of the system volume. This functionality removes much of the uncertainty about which data items should or should not be encrypted. Every file that the user creates or touches will be encrypted if it is stored on the operating system volume.
However, it is important to identify specific categories or classes of data that might require BitLocker protection so you can better identify which users and computers are allowed to process those kinds of data. Candidate data types for protection include:
Choose BitLocker Configuration
This planning phase will determine which configurations are appropriate for your organization and outline the configuration and deployment process.
The Security Analysis guide in this Solution Accelerator contains a complete description of the security methods that can be used with BitLocker to protect the volume encryption keys. Use the information in the Security Analysis guide to choose BitLocker modes that are appropriate for your organization. The choice of BitLocker modes can depend on the availability of hardware and software as discussed previously or on different security requirements in different parts of the organization. The available modes are:
The following figure shows a decision tree that you can use to evaluate BitLocker configuration options for your environment.
Figure 1.1. BitLocker configuration options decision tree
The output of your decision process might be similar to what is shown in the following table. Information should include hardware roles, supported hardware types, and the associated BitLocker policy and configuration.
Table 1.1. BitLocker Policy and Configuration Guidelines
BitLocker with TPM Considerations
The BitLocker with TPM mode provides protection with no user intervention required, and volume encryption, boot, and operation are all transparent to the user. This BitLocker mode is not generally appropriate for a baseline BitLocker implementation, but should only be considered in the following situations:
Plan for BitLocker with TPM
The planning steps for the BitLocker with TPM mode include the following:
BitLocker with TPM and PIN Considerations
BitLocker with a TPM and a PIN adds the ability to prevent domain users who don't know the PIN from reading data from the protected computer. It protects against attacks on the computer that would succeed if the computer booted to the logon screen.
The planning phase should determine whether users might resist having to learn and remember an additional PIN and take steps to overcome this resistance. The additional security of requiring an extra authentication factor makes this solution a good choice for protecting valuable assets.
Plan for BitLocker with TPM and PIN
To plan for the BitLocker with TPM and PIN mode, you need to follow all of the planning steps for the BitLocker with TPM mode. You must also construct a plan for the following:
BitLocker with USB Considerations
BitLocker with a USB device provides protection on computers that do not contain a TPM. This mode provides basic functionality but does not provide boot-time integrity checking, and it does not prevent domain users from logging on to the computer and reading data after the system is booted using the USB device.
Plan for BitLocker with USB
If you plan to use BitLocker with a USB startup key, you will need to perform the following planning actions:
BitLocker with TPM and USB Considerations
In this mode, BitLocker provides boot-time integrity checking and encryption and the USB token must be present at boot time to allow the computer to boot. The planning considerations for this mode are a hybrid of those required for the TPM-only and USB-only modes, because you must verify that your computers can use BitLocker with a TPM as well as prepare to support USB key storage.
Plan for BitLocker with TPM and USB
If you want to use this mode, you must perform the same planning steps as described in the "Plan for BitLocker with TPM" section earlier in this chapter, plus the steps in the "Plan for BitLocker with USB" section.
Plan for Data Recovery
BitLocker provides powerful encryption for your data. There are no "back doors" or other ways to recover data from a disk protected by BitLocker if you don't have the correct recovery password. This fact increases the importance of recovery planning, because without a good copy of the recovery password you will not be able to recover any data from a protected volume.
During computer startup, BitLocker could detect a condition that prevents it from unlocking the drive on which Windows is installed. Examples of these conditions include disk errors or changes to the computer's startup files. If one of these conditions occurs, you will not be able log on and access your protected files until you unlock the volume using your BitLocker recovery password. If you try to mount the hard disk in a different computer, you will still need the BitLocker recovery password.
There are four basic recovery password storage strategies:
Microsoft recommends that you choose a combination of recovery methods for your environment. Because BitLocker volumes are unrecoverable without the password, storing recovery passwords using a single recovery method introduces a single point of failure into your data recovery process. Each recovery method has advantages and disadvantages; you should be sure to understand these issues when choosing a method.
Microsoft strongly recommends that you plan for and deploy Active Directory storage of recovery passwords for your BitLocker-protected computers. Using this method, recovery information is stored as attributes on the computer object in Active Directory. Recovery information includes the recovery password for each BitLocker-enabled volume, the TPM owner password, and the information required to identify which computers and volumes the recovery information applies to. Optionally, you can also save a package that contains the actual keys used to encrypt the data as well as the recovery password required to access those keys. This method of storing the recovery password has the following major advantages compared to other storage methods:
Using Active Directory to store BitLocker recovery passwords introduces the following requirements:
Note Computers that go into recovery mode unexpectedly might have been attacked by malware. You should ensure that any computer that goes into recovery mode without a known cause is examined by your support staff before the user executes a recovery.
Printing the recovery password, or storing it in a file, is a simple process that has some important advantages:
However, it also has some significant disadvantages:
USB Device Method
Storing the recovery password on a USB device provides the following advantages:
However, this method also has its disadvantages:
Define a Recovery Policy
It is important to define a policy that specifies who may recover data from a computer protected with BitLocker. BitLocker recovery requires physical access to the computer so that the recovery password can be entered. This requirement significantly influences the process of defining a recovery policy, because you might need to enable scenarios in which a remote or mobile user needs to regain access to a BitLocker-protected volume when they are away from the office.
By default, all domain administrators can read BitLocker recovery passwords that are stored in Active Directory Domain Services (AD DS). Domain administrators can delegate this capability to other users by assigning "control access" and "read property" permissions to those users. Similarly, administrators can delegate the capability to read stored TPM owner information. For example, you can grant help desk or telephone support staff the ability to access users' recovery passwords. However, before doing so you should ensure that allowing such access aligns with your organization's security policies, because any user who has access to the recovery password for a volume can read data on the volume without restriction.
Before you specify a mandatory recovery method, ensure that you meet any prerequisites necessary for that particular method. These prerequisites include:
Plan for Manageability
An important step in the BitLocker planning process is deciding how BitLocker affects the organization's IT management processes. BitLocker affects the following ongoing processes that are found in any organization:
Software Update Management
Three primary software update management scenarios affect BitLocker deployment planning.
The first scenario involves BIOS updates. BitLocker monitors a variety of components, including some aspects of the BIOS configuration, for changes. If any of these parameters change unexpectedly, BitLocker will force a recovery at each reboot. To avoid this problem, you should disable BitLocker before updating the system BIOS, update the BIOS, and then re-enable BitLocker.
The second scenario involves updates or patches to Windows Vista. If BitLocker is enabled with a TPM, there are two sub-scenarios:
Note If BitLocker is enabled but the TPM is not used, there is no trusted path for boot-time integrity and system updates cannot force a recovery or configuration update.
The third scenario involves version or edition upgrades (for example, moving from Windows Vista Enterprise to Windows Vista Ultimate). In such a scenario, you must decrypt the drive and disable BitLocker before applying the upgrade. After the upgrade is complete, you can enable BitLocker and re-encrypt the drive.
Hardware Updates and Replacement
A BitLocker-encrypted disk volume cannot be mounted and read in another computer unless you have access to the recovery password. When you boot Windows Vista, you can recover the volume by entering the recovery password so that the boot process can proceed. This functionality might require changes to your hardware repair and upgrade policy. Specific changes would vary according to how and when you replace computers, whether you use disk imaging or backup software to move data from one computer to another, and how you grant access to BitLocker recovery data.
Integration with Imaging, Backup, and Antimalware Software
BitLocker encrypts data at the disk volume level. Programs or utilities that directly access the disk while Windows is not running will be able to read data from the disk, but the data will be encrypted. For example, imaging tools will be able to capture the encrypted contents of a BitLocker-protected disk, but not the plaintext contents.
Most backup, restore, and antimalware tools that run while Windows is running will work as expected on a computer that uses BitLocker.
In addition, tools that change Windows system files or modify system configuration parameters may cause BitLocker to request a recovery password at the next boot. (Policy changes, such as switching from TPM-only to TPM with PIN modes, might also trigger the recovery process.) For more information about the impact of BitLocker encryption on software update management, see Chapter 3: Operations and Recovery Scenarios in this guide.
Managing BitLocker Configuration
Along with Group Policy, BitLocker supports the use of scripting to control and manage the fundamental behavior of the technology. For more information about scripting interfaces such as ProtectKeyWithTPM, see the BitLocker Drive Encryption Technical Overview document. Some organizations might decide to use scripting to enforce BitLocker policy and others will choose Group Policy. This decision should be made relatively early in the planning process.
The BitLocker control options that are available in the Windows Vista Group Policy Management Console (or on other computers that have the Windows Vista Administrative Templates installed) allow you to control the following:
The remainder of this section describes each of the settings in the template. You can access these settings at \Computer Configuration\Administrative Settings\BitLocker Drive Encryption.
Turn On BitLocker Backup to Active Directory Domain Services
This policy setting allows you to manage the Active Directory Domain Services (AD DS) backup of BitLocker Drive Encryption recovery information. By default, this setting is marked as Not Configured. If you enable this policy setting, BitLocker recovery information is automatically and silently backed up to AD DS when BitLocker is turned on for a computer.
BitLocker recovery information includes the recovery password and some unique identifier data. You can also specify that Windows should back up a recovery key package, which contains a BitLocker-protected volume's encryption key, along with the recovery password. This key package is secured by the recovery password and can help perform specialized recovery when the disk is damaged or corrupted.
If you select the Require BitLocker backup to AD DS option, BitLocker cannot be turned on unless the computer is connected to the domain and the AD DS backup succeeds. This option is selected by default to help ensure that BitLocker recovery is possible. If you turn this option off, BitLocker still attempts to register recovery keys in Active Directory, but if the registration fails, BitLocker setup can continue. Backup is not automatically retried and the recovery password might not have been stored in AD DS during BitLocker setup.
Important To prevent data loss, you must have a way to recover BitLocker. If you disable or do not configure this policy setting, BitLocker recovery information is not backed up to AD DS.
Control Panel Setup: Configure recovery folder
This policy setting allows you to specify the default path that displays when the BitLocker Drive Encryption setup wizard prompts the user to enter the location of a folder in which to save the recovery password.
If you enable this policy setting, you can specify the path that is used as the default folder location when the user chooses the option to save the recovery password in a folder. You can specify either a fully-qualified path or include the target computer's environment variables in the path. If the path is not valid, the BitLocker setup wizard will display the computer's top-level folder view.
If you disable or do not configure this policy setting, the BitLocker setup wizard displays the computer's top-level folder view when the user chooses the option to save the recovery password in a folder.
Note The user will always be able to select other folders in which to save the recovery password.
Control Panel Setup: Configure recovery options
This policy setting allows you to configure whether the BitLocker Drive Encryption setup wizard prompts the user to save BitLocker recovery options.
Users have two recovery options for unlocking access to BitLocker-encrypted data:
The recovery keys or passwords are generated at the time of BitLocker setup. If you enable this policy setting, you can configure the options that the setup wizard exposes to users for recovering BitLocker. For example, disallowing the 48-digit recovery password prevents users from being able to print or save recovery information to a folder.
If you disable or do not configure this policy setting, the BitLocker setup wizard presents users with ways to store recovery options. Saving to a USB flash drive stores the 48-digit recovery password as a text file, and the 256-bit recovery key as a hidden file. Saving to a folder stores the 48-digit recovery password as a text file. Printing will provide the 48-digit recovery password.
Note If TPM initialization is needed during the BitLocker setup, TPM owner information is saved or printed with the BitLocker recovery information.
Control Panel Setup: Enable advanced startup options
This policy setting allows you to configure whether the BitLocker Drive Encryption setup wizard prompts the user to set up an additional authentication that is requested each time the computer starts. In this policy setting, you can control the following aspects of BitLocker startup:
If you enable this policy setting, the wizard displays a page that allows the user to configure advanced startup options for BitLocker. You can also configure setting options for computers with and without a TPM.
If you disable or do not configure this policy setting, the BitLocker setup wizard displays basic steps that allow users to enable BitLocker on computers with a TPM. In this basic wizard, no additional startup key or startup PIN can be configured.
If you want to use BitLocker without a TPM, or with a TPM plus a PIN or startup key, ensure that the Local Computer policy (or the cumulative effective Group Policy) is configured for Advanced Startup options (see the following figure). This configuration must be set before BitLocker is enabled, and can be found at Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Control Panel Setup: Enable advanced startup options.
Figure 1.2. Enable Advanced Startup options dialog
Configure encryption method
This policy setting allows you to configure the algorithm and key size used by BitLocker. This policy setting applies to a fully decrypted disk. Changing the encryption method has no effect if the disk is already encrypted or if encryption is in progress. The policy setting has four options:
If you enable this policy setting, you can configure the encryption method that is used to encrypt an unencrypted volume. If you disable or do not configure this policy setting, BitLocker uses the default encryption method of AES 128-bit with Diffuser or the encryption method specified by a local administrator's setup script.
Prevent memory overwrite on restart
This policy setting controls computer restart performance at the risk of exposing BitLocker secrets. BitLocker secrets include key material used to encrypt data. This policy setting applies only when BitLocker protection is enabled.
If you enable this policy setting, Microsoft Windows does not instruct the computer to overwrite memory on restarts. Preventing memory overwrite might improve restart performance, but it increases the risk of exposing BitLocker secrets.
If you disable or do not configure this policy setting, Windows helps ensure that BitLocker secrets are removed from memory when the computer restarts. By default, this policy is not configured.
Configure TPM platform validation profile
This policy setting allows you to configure how the computer's TPM security hardware secures the BitLocker encryption key. This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker has already been turned on with TPM protection.
If you enable this policy setting before turning on BitLocker, you can configure the boot components that the TPM validates before unlocking access to the BitLocker-encrypted operating system volume. If any of these components change while BitLocker protection is in effect, the TPM will not release the encryption key to unlock the volume and the computer will enter into recovery mode during boot.
If you disable or do not configure this policy setting, the TPM uses the default platform validation profile or the platform validation profile specified by a local administrator's setup script. The default platform validation profile secures the encryption key against changes to the Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (Processor Configuration Register 0, or PCR 0), the Option ROM Code (PCR 2), the Master Boot Record (MBR) Code (PCR 4), the NTFS Boot Sector (PCR 8), the NTFS Boot Block (PCR 9), the Boot Manager (PCR 10), and the BitLocker Access Control (PCR 11).
Important Changing from the default profile affects the security and manageability of your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending upon inclusion or exclusion (respectively) of the PCRs.
You should include decommissioning as part of your planning. For example, what will you do when a BitLocker-protected computer needs to be reassigned, moved outside the organization, or discarded because of a hardware failure? Because of the algorithm strength of the AES algorithm that BitLocker uses, erasing the recovery password effectively prevents access to a protected volume. You should consider policies and procedures that help you verify that all protectors are removed from Active Directory or other locations when you decommission a computer. (For more information about how to remove protectors for decommissioning, see BitLocker Drive Encryption and Disk Sanitation.)
Plan for Usability
BitLocker is designed to provide strong security while remaining transparent to users during typical operations. However, users must know a number of things to use BitLocker effectively and securely. You should develop a written encryption policy that describes the use, requirements, and operational issues that surround encryption. Users and support staff must be educated about the appropriate use of encryption prior to deployment.
An encryption policy should address issues related to using encryption for confidential data protection, including:
Use your typical educational channels to share encryption information with users, including online and written sources, with hands-on lessons and classes as necessary. This effort can be conducted in parallel with the rest of your deployment process.
Plan for Active Directory and Group Policy Implementation
The output of the previous planning steps describes the extent to which Active Directory will be used to help manage the BitLocker environment. The possibilities include:
Plan for Storage of Recovery Passwords in Active Directory
As discussed earlier in the "Plan for Data Recovery" section, the use of Active Directory to store recovery passwords requires an extension to the Active Directory schema. Implementing this extension is a significant undertaking and must be planned well in advance of the BitLocker deployment to ensure that the schema extension is successful and that that the environment properly stabilizes.
The planning process for BitLocker Active Directory actions should also include discussion and decisions about who will be designated as key and data recovery operators. A key point to consider is whether the recovery operator function will be separated from the Domain and Enterprise Administrator roles. Some organizations with strict segregation of duties requirements are forced to separate these roles, and other (possibly smaller) organizations will want to allow Domain Administrators to perform data and key recovery simply because these personnel are already trained in the complex technical tasks of managing Active Directory.
Controlling BitLocker Data Encryption with Group Policy
Previous planning steps determined which BitLocker-related Group Policy options will be used. Group Policy options to be planned for include:
Plan for Encrypting File System
The following actions must be performed to complete a plan for EFS deployment:
Understand EFS Deployment Options
EFS is an effective mitigation against several security threats. Understanding which threats EFS mitigates, and which additional threats can be mitigated by combining EFS with BitLocker, requires you to understand the EFS security model and the deployment options it supports. The Security Analysis document included with this Toolkit describes a range of risks and how EFS mitigates them. You should thoroughly familiarize yourself with its contents before proceeding with your planning process.
Evaluate EFS Readiness
Before you can create an EFS deployment plan, you must evaluate your organization's readiness to deploy and use EFS.
Note You can greatly simplify your EFS deployment plans if you use the Active Directory credential roaming feature. For more information, see the Understanding credential roaming page on Microsoft TechNet.
Hardware and Software Requirements
EFS does not require any special hardware other than a computer capable of running a version of the Windows operating system that supports EFS. Specific information about using EFS on any operating system besides Windows XP Professional or the Business, Enterprise, or Ultimate versions of Windows Vista is beyond the scope of this guide.
In addition to the hardware and software requirements listed earlier, EFS requires the following:
Determine the Scope of EFS Deployment
EFS deployment planning involves decisions regarding the designation of computers and users who will use EFS as well as what data on each computer should be protected with EFS. Because EFS can be used on most Windows–based computers, an analytical process that starts with determining what data should be protected and then identifies the users who have copies of that data and on which computers can fully define the scope of an EFS deployment.
Consider the following questions to help identify what data you need to protect:
Examples of data that should be encrypted might include the following:
The intent of this list is to stimulate security-aware thinking habits; it is not a comprehensive list.
Files and Folders That Cannot Be Encrypted Using EFS
Many files and folders cannot be encrypted using EFS no matter what the user’s permissions. To protect the user from an inoperable state, Windows specifically prevents the encryption of critical items that should not be encrypted. These files and folders include:
Note Some of these folders will allow some of the files that they contain to be encrypted, just not critical files.
Most of the files and folders that cannot be encrypted by EFS are explicitly denied from encryption to protect the user and the participating computer. For example, the user’s private EFS decryption keys are stored in the user’s profile. If the user could encrypt their user profile, Windows would have no way to obtain the decryption key to decrypt the user profile. Therefore, Windows blocks users from encrypting these files.
Note You can use BitLocker to encrypt critical system files prior to booting.
Windows Vista allows you to encrypt some critical files and folders that were not previously allowed in earlier versions of Windows, including the system page file (pagefile.sys).
Files and Folders That You Should Not Encrypt
There are other types of files and folders that users should not usually encrypt, even if the operating system allows it. Examples include:
Note Shared database files should not be encrypted, because the file must be encrypted so that it can be accessed by all users as well as the database program. Database files are better protected using field/attribute-specific encryption.
Identify Data and Data Locations
A common EFS scenario involves the protection of text, graphics, spreadsheets, and slide show documents created by products such as the Microsoft Office suite. A survey should be performed to determine whether all users in your organization use the default location for such documents. If so, plan to encrypt this entire folder on each computer to be protected.
In addition, the %TEMP% folder should be encrypted to protect any temporary application files that might be created in this folder.
Other applications that interact with confidential data must be examined to determine where the data they create is stored.
After all confidential data and default application data locations are identified, a written policy should be drafted to inform users how to enable encryption on those folders. A plan to configure and deploy policy automation to enable encryption automatically should also be developed.
Common Encrypted Directory Structures
Finding out where users currently keep sensitive data files will likely provide some surprises. The main point of this effort is not to specify, for example, that users must keep documents in My Documents\Sensitive, but to ensure that they do not store them in directories that should not or cannot be encrypted, such as C:\ or C:\WINDOWS.
Creating a common directory structure for all protected laptops will simplify maintenance. The simplest approach, of course, is to set a policy to keep all documents under My Documents, and encrypt the entire My Documents tree. Although this approach might suffice for many organizations, some will find it too restrictive and define more complex and flexible policies.
Some applications create temporary or cache files that might contain sensitive data. You might be able to use EFS and the EFS Assistant tool that accompanies this guide to protect the directories containing these files. However, you will need to test your applications to ensure that they work properly when their temporary or cache directories are encrypted.
Choose EFS Configuration Options
When the scope of the EFS deployment is determined, the next step in the EFS planning process is to choose which EFS options and configurations for the organization's computers. The options that must be considered and planned for include:
Note This feature is included in Windows Vista. To use it in Windows XP, see Microsoft Knowledge Base article 912761, "Encrypting File System (EFS) generates a self-signed certificate when you try to encrypt an EFS file on a Windows XP-based computer."
Windows Vista–based computers offer several additional options, including the following capabilities:
Because some of the configuration options are only possible on Windows Vista, you might need to plan an upgrade of the operating system on certain computers based on the security requirements for part of the organization.
Choosing a Digital Certificate Strategy
EFS digital certificates can be self-signed or issued from a trusted CA. The first time a user attempts to encrypt a file or folder using EFS, Windows checks to see if they have an existing certificate and key that can be used. If not, Windows attempts to contact an issuing CA to obtain a certificate and key. Failing that, Windows generates a self-signed certificate for the user. A self-signed certificate is one in which the digital certificate does not have a higher-level trusted signing authority attesting to its authenticity. Generally, self-signed digital certificates should not be relied upon externally by third parties. However, self-signed digital certificates are often appropriate for internal applications such as EFS.
In general, self-signed EFS digital certificates are easier to implement initially and harder to manage operationally. CA-generated certificates should be chosen if the appropriate PKI services are already implemented.
Note Enterprises without a PKI platform should strongly consider implementing Certificate Services before enabling and using EFS. Certificate Services is available in Microsoft Windows 2000 Server and later server products. The benefits for EFS digital certificate life cycle management and automating a recovery solution will result in decreased overall effort and expense.
Group Policy or Local Computer Policy can be used to allow or disable the ability of a computer to generate a self-signed EFS certificate when a participating CA is not present. This option is discussed in the following section.
Administrators should study the benefits and disadvantages of each digital certificate method and make a purposeful decision to use one solution or the other. It can be cumbersome to change the EFS digital certificate trust chain method after initially implementing EFS.
Benefits and Disadvantages of EFS Self-Signed Certificates
Self-signed certificates are the easiest way to establish a functional EFS infrastructure. Self-signed certificates are automatically issued to EFS clients if no participating and compatible PKI CA is detected. Generation and installation of self-signed digital certificates are fast and transparent to the participating user. By default, self-signed certificates have a validity period of 100 years.
However, self-signed digital certificates have some significant disadvantages, including the following:
Benefits and Disadvantages of EFS Certificates from a Certification Authority
Issuing EFS certificates from a centralized CA has some compelling benefits. This method offers centralized management of digital certificates, and it decreases the security risk because generated digital certificates have shorter useful life period. Renewal, revocation, rekeying, and archival are all easier to automate because the key and certificate material remain accessible through the CA. You can also adjust various certificate parameters by modifying the certificate template. In addition, you can publish the certificates to Active Directory to make it easier for users to locate each other's certificates for sharing EFS-encrypted files.
However, CA-issued EFS certificates have their own disadvantages. First, you must implement a participating EFS-compatible CA before deploying EFS. Second, the shorter validity period of CA-issued certificates might require more frequent rekeying of the certificates. Most significantly, Windows–based computers issue their own self-signed EFS certificates if they cannot contact a participating CA. This capability could lead to a mixed environment of CA-signed and self-signed certificates, complicating EFS digital certificate management. You can work around this potential problem by configuring Group Policy to disable the use of self-signed certificates for EFS or by disabling EFS entirely until you implement the necessary CA services.
If you plan to use auto-enrollment to issue client certificates for use with EFS, carefully review the "Plan for Active Directory and Group Policy" section later in this chapter to ensure that your Active Directory infrastructure will support auto-enrollment (which requires at least one Windows Server 2003 domain controller in your forest).
EFS and Smart Cards
Windows XP and Windows Vista both support the use of smart cards with EFS. As described in the Security Analysis, when you use smart cards with EFS you help mitigate the risk that an attacker will obtain a user's password and use it to log on to a computer and recover EFS-protected files—one of the primary risk factors for EFS. Requiring the use of smart cards with EFS helps effectively add protection, but the ways to require EFS smart card use differ between Windows XP and Windows Vista.
In Windows XP, the smart card can be required for logon. Optionally, it can be required to unlock an inactive or locked desktop. In such a scenario, the additional protection for EFS keys comes from the required presence of the smart card, which is the only way to unlock the EFS keys and use them on files.
In Windows Vista, the smart card can be required for logon and unlocking. However, it is also possible to require the card to be present each time an EFS-protected file is encrypted or decrypted. By default, Windows Vista derives a cryptographic key and caches it for use in EFS operations. For added security, Windows Vista can instead use the smart card directly for every cryptographic operation. However, this approach is less convenient for users and is much slower than cached key mode, so it may not be desirable in some environments.
Note For more detail about the EFS modes supported in Windows Vista and Windows XP, see "Chapter 3: Encrypting File System" in the Security Analysis.
Benefits of Smart Cards
Smart cards are designed to offer strong cryptographic security in a portable, physically secure package. They add security because they offload signature, verification, encryption, and decryption from the host computer to the smart card itself. Cryptographic keys are securely stored on the smart card and are generally considered safe from all but the most sophisticated and well-funded attackers. The certificates associated with a smart card can be used for a variety of security enhancements, including S/MIME protection for e-mail, certificate-based authentication for Web applications and remote access, and more secure desktop logon. Requiring the use of smart cards essentially forces the use of two-factor authentication, because any user who wants to authenticate must have the card and the associated pass phrase or PIN. In addition, there is no need to set up credential roaming systems, because each user's credentials are stored on the card.
Disadvantages of Smart Cards
Smart cards have several notable drawbacks. First, they require deployment of the cards themselves along with readers, which can be prohibitively expensive for some organizations. The cards' certificate issuance and control mechanism must be integrated with a PKI, which can increase the cost and complexity of smart card deployments. Organizations that require smart cards must also implement procedures to issue and track the cards, a security-related activity that must be carefully managed to avoid introducing vulnerabilities. Microsoft Identity Lifecycle Manager 2007 (ILM 2007) can be deployed to help smooth the smart card deployment process.
Choosing an Encryption Cipher
EFS can be implemented with a variety of ciphers and key strengths. It is important to understand that the cipher type and key strength can be chosen on two different EFS objects: the user’s personal EFS asymmetric key and a file’s shared symmetric file encryption key (FEK). Every EFS-protected file has a single symmetric FEK. The file data in each EFS-protected file is encrypted with the file’s FEK.
Each authorized user (or recovery agent) is assigned a copy of the file’s FEK, which is encrypted with the public key in the user's EFS certificate (and can then only be decrypted by the user’s corresponding private key). When the user needs to access an EFS-protected file, the user’s personal private asymmetric EFS encryption key is used to decrypt the user’s encrypted copy of the file’s FEK. The now unencrypted symmetric FEK is used to decrypt the EFS-protected file. It is important to understand the difference between the two EFS key types when deciding on cipher type and key strength.
Encryption algorithm ciphers for the FEK include, in order of weakest to most secure:
Windows Vista, Windows XP Professional (SP1 and later), and Windows Server 2003 use the strong AES cipher by default. Earlier versions of Windows XP Professional use DESX by default, but can be switched to the stronger 3DES cipher. To do so, the Use FIPS compliant algorithms for encryption, hashing, and signing security policy option should be enabled in Group Policy, Local Computer Policy, or by editing the registry directly. Windows 2000 uses DES or DESX ciphers for EFS. DESX is automatically used for any version of Windows 2000 SP1 or later.
If the FIPS option is enabled on Windows XP Professional SP1 (or later versions) or in Windows Server 2003, it actually changes the cryptographic protection from AES to 3DES. However, if the FIPS option is enabled, Internet Information Service (IIS) servers and Microsoft Internet Explorer® clients are required to use Transport Layer Security (TLS) instead of the weaker Secure Sockets Layer (SSL) for secure Web transactions. Requiring stronger TLS can also be done at the server level, without enabling FIPS security and decreasing symmetric key security on legacy Windows XP–based clients.
The default asymmetric cipher algorithm used to encrypt FEKs is RSA for both self-signed keys and keys issued by a Microsoft-based certification authority.
Note The default algorithm used is always the most secure cipher available at the time. Each version of Windows is capable of handling all ciphers supported by previous versions. Microsoft recommends that you do not change the cipher settings for EFS except as required by regulatory or compliance needs.
EFS Key Sizes
Windows XP and Windows Vista allow flexibility in both the user’s asymmetric and the file’s FEK cipher key sizes, although there is less flexibility in the FEK key size. Choosing the FEK’s cipher algorithm determines the FEK’s symmetric key strength. Using larger key sizes might result in stronger EFS protection, but might also result in a greater performance penalty, depending on the algorithm in use.
User Asymmetric Key Sizes
In general, EFS asymmetric key sizes can range from 1,024 to 16,384 bits. Typical key sizes are: 1,024, 2,048, 4,096, 8,192, and 16,384 bits. In Windows Vista, the default key size is 2,048 bits, which is secure enough for almost all EFS applications. Microsoft strongly recommends keeping this default key size for new EFS deployments. Prior versions of Windows used a default key size of 1,024 bits.
Symmetric FEK Sizes
EFS symmetric FEK ciphers generally range from 56-bit in earlier versions of Windows to 256-bit AES in Windows Vista. Windows 2000 uses 128-bit DESX keys when the High Encryption Pack or SP1 or later is installed; otherwise, a 56-bit key is used. Windows XP SP 1 (or later) and Windows Server 2003 use 256-bit AES by default. Prior to SP1, Windows XP used DESX but could be set to use 168-bit 3DES.
Generally, most users are well served by allowing the default EFS FEK ciphers to be used. However, some organizations require earlier encryption ciphers or custom key sizes to be used instead.
EFS and Windows Vista
Windows Vista offers some significant enhancements in EFS. You should consider where and how to deploy Windows Vista to make appropriate use of these improvements, which include:
If these features are important to your organization, you should consider how to coordinate your EFS deployment and your Windows Vista deployment. The Windows Deployment Wizard allows you to enable BitLocker as part of a Lite Touch deployment. The EFS equivalent is to enable auto-enrollment for user certificates, then install the EFS Assistant (either as part of the Windows Vista image or through other means) so that sensitive files can automatically be protected.
EFS and File Sharing
Starting with Windows XP Professional, EFS-protected files and folders can be shared with additional users. The first user (or an EFS data recovery agent) to encrypt a file or folder must add the additional users to the file or folder. The additional users must already have valid EFS digital certificates.
Other users who have Write, Delete, or Modify permissions may be able to modify or delete EFS-protected files and folders even if they do not have the ability to encrypt or decrypt those same files or folders. EFS protects confidentiality (that is, unauthorized users cannot read, view, or print protected files), but they might still be able to otherwise manipulate the file without viewing or reading its contents. If the ability to share files between multiple users is important, you should ensure that your organizational policies are clear about who is responsible for encrypting files, who is allowed to read them, and who has the authority to add or remove shared users for encrypted files.
Plan for Key and Data Recovery
Organizations that choose to deploy EFS will need to carefully plan for how to recover data in certain situations, such as when a user leaves the organization, is locked out of their workstation, or the EFS certificate and keys are corrupted. The most important planning tasks for EFS data recovery are documented in the "Data Protection and Recovery in Windows XP/Data Recovery Overview" section of the Windows XP documentation. This section provides additional guidance about issues you should consider during your planning.
EFS is a secure file encryption solution. If the encryption keys used to decrypt the protected files become unavailable, it is possible that the protected files will become unavailable as well. If a backup of the data in unencrypted form does not exist, or if an encryption recovery method is not deployed, the protected files could be permanently unavailable.
As discussed earlier in this guide, EFS uses a combination of symmetric and asymmetric (public/private) key algorithms to protect data. In the default scenario, a symmetric file encryption key (FEK) is generated, which is then encrypted using the public key from a X.509 certificate. There are two different approaches to a backup strategy for EFS-encrypted data:
Key recovery implies that the private key portion of a public-private key pair may be archived and recovered if needed. If the user's copy of the private key is lost or corrupted, whether it is stored on a smart card or on a local computer, then the key can be recovered from the backup location. After a private key is recovered, any data (or more accurately, any encrypted symmetric keys such as an FEK) can be decrypted. In Windows, this capability is provided in two ways: using key recovery agents or manual key archival.
Using a Key Recovery Agent
If Certificate Services or another compatible CA is used, a key recovery agent (KRA) can be used to provide file recovery. The issuing CA can automatically archive EFS digital certificates as it issues them, and the KRA can be used to recover lost EFS keys from this archive. The primary operational difference between an EFS DRA and a KRA is that EFS DRAs have explicit access to all participating EFS-protected files, whereas KRAs can only recover stored copies of other people’s keys. KRAs can also participate in digital certificate key recovery events beyond EFS.
Automatic key archival is done as part of the certificate enrollment process if certificate templates are configured to require key archival. When configured in this way, the private key will be sent to the CA as part of the certificate request and the private key will be archived automatically by the CA.
For more information about planning and implementing a key archival and recovery mechanism, see Key Archival and Management in Windows Server 2003.
Manual Key Archival
If the EFS deployment relies on self-signed certificates, manual key archival is the only way to back up the private key needed to decrypt the FEK. By default, all EFS users can make a backup of their EFS digital certificate and private EFS decryption key. Windows Vista prompts users to back up their keys whenever they are created or changed. All versions of Windows later than Windows 2000 allow users to manually back up their EFS keys, using two or more methods. If allowed by their security policy, users should back up their EFS keys and store them in two or more separate, secure locations using reliable storage media.
With manual key archival, users manually export private keys and send them to a CA administrator who then imports them to the protected CA database.
This approach allows users to take responsibility for their own recovery keys. However, it is difficult to monitor and regulate in large organizations, and there is no reliable way to determine whether a user has or has not archived an EFS key, both of which might be important for policy compliance.
Data recovery is a somewhat different process that doesn't involve the archival of the keys associated with any particular X.509 certificate. Instead, this process creates redundant paths to accessing an encrypted file by creating additional encrypted FEKs, each encrypted with the public key from a different X.509 certificate. The additional keys created by this process are called data recovery agents.
When any file is encrypted, Windows automatically makes a copy of the file’s FEK and encrypts it with the DRA’s public EFS key. This functionality means a DRA can decrypt any EFS-protected file.
The primary benefit of a DRA is that every EFS-protected file automatically has a copy of the file’s FEK created by default. It does not require a user to manually make backup keys. The biggest disadvantage is that if the DRA’s user account is compromised, the intruder can access EFS-protected files.
Note Increased security methods should be used to protect any DRA user account. Also, the recovery agent’s EFS recovery key can be exported and stored externally to prevent an EFS compromise if the agent's account is compromised. The EFS recovery key can be imported in the future if needed.
By implementing data recovery and data recovery agents, every encrypted file's encryption key is encrypted using the DRA's public key in addition to the user’s public key. By using the associated private key, any designated DRA can decrypt any encrypted file within the scope of the EFS recovery policy.
Defining a Recovery Policy
The recovery policy defines who is permitted to recover data and in what circumstances recoveries can be performed, and it is a key part of your EFS planning. Your policy should define:
Where possible, Microsoft recommends that you choose one of two best practices for your recovery policy. The preferred method of recovery is to issue a DRA certificate on a smart card, then secure the smart card and its PIN separately. A Windows Vista–based computer can use this smart card and the associated certificate to recover data from any client in the domain. This combination provides strong two-factor protection for the DRA credentials, and you can enforce separated access to the smart card and PIN to ensure separation of recovery duties.
In environments in which this is not feasible, Microsoft recommends that you define and configure separate computers that are used only for data recovery. These recovery workstations should be physically secured and have additional auditing and security measures applied, commensurate with the value of the data that might be recovered.
Planning for DRA Expiration
EFS data recovery agents use certificates which, like any other certificates, will eventually expire. However, conventional certificates are typically used to provide forward secrecy: they protect material that should remain encrypted for some period into the future. Preserving forward secrecy requires that the key associated with the certificate expire at some future time so that it can be rekeyed.
DRAs provide the opposite of forward secrecy: they allow past data to be recovered. This functionality means an expired DRA certificate is still useful to recover data that was encrypted during the DRA certificate's validity period. To preserve your ability to recover data no matter how old it is, you should plan to archive DRA certificates to a secure storage medium so that they can be used when necessary.
When a DRA certificate expires, you can reissue or rekey it. After you do so, the DRA can be used to recover newly encrypted data. However, you must maintain a copy of the previous DRA certificate to recover data protected by the previous DRA. When you develop procedures and policies for handling (or preventing) DRA expiration, consider the following:
Determine Data Recovery Policy Level
A default recovery policy is automatically put in place for the domain when the administrator logs on to the domain controller for the first time, which makes the administrator the recovery agent for the domain. Windows XP, Windows Vista, and Windows Server 2003 no longer require a recovery policy to be in effect to encrypt files.
The default recovery policy is configured locally for stand-alone computers. For computers that are part of an Active Directory–based domain, the recovery policy is configured at the site, domain, organizational unit (OU), or individual computer level, and applies to all Windows 2000, Windows Server 2003, Windows XP, and Windows Vista–based computers within the defined scope of influence. Recovery certificates can be issued by a CA and managed using the Microsoft Management Console (MMC) Certificates snap-in.
In a network environment, the domain administrator controls how EFS is implemented in the recovery policy for all users and computers in the scope of influence. In a default Active Directory installation, when the first domain controller is set up, the domain administrator is the specified recovery agent for the domain. The way the domain administrator configures the recovery policy determines how EFS is implemented for users on their local computers. To change the recovery policy for the domain, the domain administrator uses the Group Policy editor from any client computer or server connected to the domain. For a stand-alone computer (not joined to a domain), the expiration period of a self-issued administrator account DRA certificate is 100 years. For a domain-joined computer, the default DRA certificate issued to the domain administrator has an expiration period of three years.
Administrators can define one of three types of policies:
Although the domain administrator is the default DRA in an Active Directory environment, this capability should be delegated or assigned to one or more users.
Choosing the Right Mechanism
Key recovery and data recovery strategies can be used separately or in tandem. There are many security and operational issues to consider. Additional information can be found in Key Archival and Management in Windows Server 2003. You are strongly encouraged to review this information before deciding which strategy, or combination of strategies, to use.
Plan for Manageability
An important step in the EFS planning process is deciding how EFS affects the organization's IT management processes. EFS affects the following ongoing processes that are found in any organization:
Integration with Imaging, Backup, and Antimalware Software
Most third-party imaging, backup, and antimalware applications are designed and tested to work with EFS. Understanding the types of such tools used by an organization and then testing them in conjunction with EFS is a necessary planning step to ensure that the IT service agreements are satisfied. The testing criteria should include whether the applications work correctly with encrypted data as well as whether the tools retain the encrypted status or not, depending on the organization's requirements.
Copying and Moving Files
Copying or moving EFS-protected files might result in changes to the file's encryption status. The general rules for how copying or moving files affects encryption are:
Maintenance utilities that copy files in their entirety without reading the file data should work as expected. For example, the Windows Backup utility (and most other backup programs) read the entire set of all NTFS stream data for files they back up, so the backup can proceed without having access to the user's key material. Files backed up using this method will remain encrypted on the backup media.
Note The backup utility included with Windows Vista cannot back up EFS-encrypted files. If you are not using a third-party backup tool, you can still use the Robocopy tool with the /efsraw switch to automate backup of EFS-protected files on computers that run Windows Vista.
Disk Imaging Tools
Similarly, disk imaging tools that capture the contents of the entire file system will preserve the EFS state of protected files because they read individual blocks from the disk. Imaging a computer that contains EFS-protected data will include the EFS-encrypted data as part of the image. Some imaging tools allow you to open an image and view or modify individual files in the image without restoring the image to a target computer. These tools usually do not work properly with EFS-encrypted files, and you will not be able to open or modify encrypted files captured in an image unless the computer on which you open the files has the correct key material.
Antimalware programs (including antivirus and spyware-fighting software) generally work in two ways:
Individual antimalware programs might combine these two approaches. Review the documentation for your antimalware solutions and test them to ensure that they work properly with EFS-protected files in your environment.
Plan for EFS and File Sharing
If your organization needs to share sensitive data between multiple users, there are two possibilities for doing so: storage in typical shared folders on file servers or the use of Web folders. Both methods require configuration to support EFS, and you should understand the issues, benefits, and risks, which include the following.
Plan for Decommissioning
EFS only encrypts selected files, and the key material may be retained on the system volume in some operating modes. When you decommission a computer that contains EFS-protected content, you must follow your normal decommissioning practices to ensure that all sensitive files are removed.
Plan for Usability
EFS is a secure method for encrypting files and folders on NTFS volumes. A written encryption policy should be created and distributed that describes the use, requirements, and operational issues surrounding encryption. Users and support staff must be educated about the appropriate use of encryption prior to deployment.
An encryption policy should describe issues related to confidential data encryption, including:
Use typical educational channels to share encryption information with users, including online and written sources, with hands-on lessons and classes as needed. This effort can be conducted in parallel with the rest of your deployment process.
Plan for Active Directory and Group Policy
Active Directory and Group Policy provide the most effective way to manage EFS configuration and policy. The following GPO settings can affect the behavior of EFS.
Planning for Migration to Domain Accounts
For reasons discussed in the Security Analysis guide of this Solution Accelerator, EFS offers optimal security only for users with Active Directory domain accounts. It is possible to use Syskey to achieve similar levels of security, but the user impact of advanced levels of Syskey is somewhat negative. For this reason, EFS users should be domain users. Part of the planning for EFS should include a survey of potential users to ensure that they have domain accounts and that they only use those domain accounts when they log on to a computer to access confidential data protected by EFS.
Planning for Active Directory Password Policy
Unless smart cards are used with EFS, EFS file encryption keys are protected by the user's password. Anyone who can obtain a user ID and password can log on as that user and decrypt that user's files. Therefore, a strong password policy in addition to strong user education must be a component of each organization's security practices to ensure the protection of EFS-encrypted files.
Planning Migration from Self-Signed to CA-Issued Certificates
Some users may have begun using EFS in advance of your formal EFS deployment. If a user attempts to encrypt a file on a computer with no EFS certificates, the EFS subsystem will generate a new self-signed certificate. When you deploy EFS to your organization's computers, you should plan to replace these self-signed certificates with certificates issued by your certification authority. This replacement process standardizes the lifetime and key strength of certificates used for EFS on computers with self-signed certificates and other computers on which EFS is deployed.