Windows Server 2008 : Choosing Data Security Solutions

Data protection features vary not only in their application but also in the cost and complexity of their adoption. In general, you need to review the features of each technology and then decide whether your security needs warrant the implementation of the technology in question. In general, the higher your needs to protect specific data, the higher the cost and complexity you should consider to meet your security requirements.

Protecting Volume Data with BitLocker

BitLocker is a data protection feature available in Windows Server 2008 that provides data encryption for full volumes and integrity checking for early boot components. The purpose of BitLocker is to protect data on a drive that has been stolen or that has been accessed offline in a way that bypasses file permissions (for example, by booting the computer from a stealth operating system).

BitLocker is designed primarily for use with a TPM, which is a hardware module included in many new laptops (as well as some desktops) that are available today. TPM modules must be version 1.2 for use with BitLocker. The TPM module is a permanent part of the motherboard.

If a TPM 1.2 module is not available, a computer can still take advantage of BitLocker’s encryption technology as long as the computer’s BIOS supports reading from a USB flash device (UFD) before the operating system is loaded. However, you cannot use BitLocker’s integrity checking capabilities without a TPM 1.2 module.

BitLocker Drive Encryption

In Windows Server 2008, BitLocker encrypts system volumes and data volumes. (In Windows Vista, BitLocker can encrypt only system volumes.) To encrypt the full volume, a cryptographic key known as the Full Volume Encryption Key (FVEK) is used. This key is stored in the volume metadata and is itself encrypted by another key known as the Volume Master Key (VMK). The VMK is then encrypted again by the TPM, if one is available, or by a startup key located on a user-provided UFD accessed during the startup phase.

BitLocker Performance Issues

Windows Server 2008 and Windows Vista encrypt and decrypt disk sectors on the fly as data is read from and written to encrypted volumes. As a result, BitLocker does affect performance because these cryptographic operations consume some processor time. However, the actual impact depends on multiple factors, such as caching, hard disk speed, and processor grade.

Choosing a BitLocker Authentication Mode

BitLocker supports four separate authentication modes. The mode you choose depends on the computer’s hardware capabilities and the level of security you desire for the computer:

• BitLocker with a TPM only In this authentication mode, BitLocker uses only a TPM to unlock the VMK and enable a volume to be read. Advantages of this mode are that it requires no user intervention, that it protects the data from being read if the drive is stolen, and that it protects the drive against rootkits and other low-level malware. The disadvantage of this authentication mode is that it does not protect data from being read if the entire computer is stolen because the TPM is attached to the internals of the computer.

• TPM with USB flash device In this mode, both a TPM and a UFD are required. To start the computer, a user must insert a UFD containing an external key. This effectively authenticates both the user and the integrity of the computer. The advantage of this method is that in principle it protects the data even if the entire computer is stolen (because a thief needs access to the UFD to read the data). The disadvantage is that it requires user intervention every time the computer is started.

• TPM with PIN This authentication mode requires both a TPM and a user to provide a PIN every time the computer is started. The advantage of this method is that it protects the volume data if the entire computer is stolen and that it is often easier to provide a PIN than to provide a UFD during startup. The disadvantage of a PIN is that, although this mode is more secure than BitLocker with a TPM only, it is potentially less secure than providing a UFD on a TPM-supplied computer.

• USB flash device only This is the only authentication mode that can be used on computers that do not have a TPM. In this mode the user during startup provides a UFD that includes an external key enabling encrypted volumes to be read. The advantage of this method is that it can be used on all computers with a BitLocker-compatible BIOS. The disadvantage of this method is that it does not provide data integrity checking.

BitLocker Security Design Considerations

Use the following list to help you determine whether to use BitLocker, which authentication mode to implement, and which type of operating system to use.

• Only BitLocker allows you to encrypt all files on a volume, including the page file, hibernation file, registry, and temporary files. If you want to prevent these files from being read if a computer or drive is stolen, use BitLocker and not another encryption technology, such as EFS.

• If you want to protect data stored on all volumes and not just the data on system volumes, you must use BitLocker on Windows Server 2008 and not on Windows Vista.

• If you want BitLocker to detect changes to system data, such as those that might occur from malware or rootkit infection, you must use a system supplied with a TPM. You cannot choose the UFD only authentication method.

• If you want to protect BitLocker with two-factor authentication, you must use a system supplied with a TPM. You can then use a UFD or PIN for authentication in addition to the TPM.

Planning for EFS

EFS is the file encryption technology built into Windows that is used optionally to encrypt files stored on NTFS volumes. When a user or program attempts to access a file that is encrypted with EFS, the operating system automatically attempts to acquire a decryption key for the content and, if successful, silently performs encryption and decryption on behalf of the user. When users do not have access to the encryption key, they are not able to open an encrypted file even if they have been assigned Read permissions to that file.

EFS relies on both symmetric and public key cryptography. To support public key cryptography, EFS uses certificates and key pairs. In a workgroup environment these certificates and keys are stored locally on each computer. However, in a domain environment the certificates can be issued by an enterprise certification authority (CA) and managed by Group Policy. With an enterprise CA, a domain user can read his or her encrypted files while logged on to any computer in the domain. In addition, when EFS is deployed with an enterprise CA, a domain user designated as a data recovery agent (DRA) can recover encrypted files stored in the domain.

In general, the advantage of EFS is that it provides a simple method to protect a file from being read on a disk even if that file is accessed offline. The biggest disadvantage of EFS is that it does not protect data sent over the wire or data copied to an alternate location. EFS can protect data only while it stays on an NTFS volume.

When you are planning EFS policy for an organization, it is useful to determine the threats to your system, how EFS handles these threats, and whether to deploy a CA.

To properly plan for and implement EFS, follow these steps:

In addition, be sure to follow these EFS best practices:

• Use Group Policy to ensure that the Documents or My Documents folder is encrypted for all users. This practice secures by default the data in which most documents are stored.

• Instruct users to encrypt folders instead of individual files. Encrypting files consistently at the folder level ensures that files are not unexpectedly decrypted.

• The private keys that are associated with recovery certificates are extremely sensitive. These keys must be generated either on a computer that is physically secured, or their certificates must be exported to a .pfx file, protected with a strong password, and saved on a disk that is stored in a physically secure location.

• Recovery agent certificates must be assigned to special recovery agent accounts that are not used for any other purpose.

• Do not destroy recovery certificates or private keys when recovery agents are changed. (Agents are changed periodically.) Keep them all, until all files that might have been encrypted with them are updated.

• Designate two or more recovery agent accounts per organizational unit (OU), depending on the size of the OU. Designate two or more computers for recovery, one for each designated recovery agent account. Grant permissions to appropriate administrators to use the recovery agent accounts. It is a good idea to have two recovery agent accounts to provide redundancy for file recovery. Having two computers that hold these keys provides more redundancy to allow recovery of lost data.

• Implement a recovery agent archive program to make sure that encrypted files can be recovered by using obsolete recovery keys. Recovery certificates and private keys must be exported and stored in a controlled and secure manner. Ideally, as with all secure data, archives must be stored in a controlled access vault and you must have two archives: a master and a backup. The master is kept on-site, while the backup is located in a secure off-site location.

• Avoid using print spool files in your print server architecture, or make sure that print spool files are generated in an encrypted folder.

• EFS does take some CPU overhead every time a user encrypts and decrypts a file. Plan your server usage wisely. Load balance your servers when there are many clients using EFS.

Using AD RMS

AD RMS is a technology that allows an organization to control access to, and usage of, confidential data. With an AD RMS–enabled application such as Office, you can create a usage policy to protect a file in the application by controlling rights to that file even when it is moved outside of the company network.

Whenever you choose to protect data by using AD RMS, users who later want to read the data must first be authenticated against the AD RMS server. This authentication can occur anywhere in the world as long as the AD RMS server is accessible over the network and as long as the user’s computer is running the AD RMS client, which is built into Windows Vista and Windows Server 2008.

AD RMS is installed as a server role and managed through the Active Directory Rights Management Services console, shown in Figure 1.

Figure 1. The Active Directory Rights Management Services console

AD RMS usage policies define three elements for protected files:

• Trusted entities Organizations can specify the entities, including individuals, groups of users, computers, and applications, that are trusted participants in an AD RMS system. By establishing trusted entities, AD RMS can help protect information by enabling access only to properly trusted participants.

• Usage rights and conditions Organizations and individuals can assign usage rights and conditions that define how a specific trusted entity can use rights-protected content. Examples of usage rights are permission to read, copy, print, save, forward, and edit. Usage rights can be accompanied by conditions, such as when those rights expire. Organizations can exclude applications and entities from accessing the rights-protected content.

• Encryption AD RMS encrypts information, making access conditional on the successful validation of the trusted entities. When information is locked, only trusted entities that were granted usage rights under the specified conditions (if any) can unlock or decrypt the information in an AD RMS–enabled application or browser. The application will then enforce the defined usage rights and conditions.

Creating and Viewing Rights-Protected Information

To protect data with AD RMS, information workers simply follow the same workflow they already use for their information.

Figure 2 illustrates how AD RMS works when users publish and consume rights-protected information.

This process includes the following steps:

This 11-step process is essentially the same whether the recipient is within the publishing organization or outside of it. The recipient is not required to be inside the author’s network or domain to request a use license. All that is required is a valid account certificate for the recipient and access to the licensing server that issued the publishing license.

AD RMS Applications

AD RMS–enabled applications are those that are specifically designed to encrypt and control usage of the information through AD RMS. AD RMS–enabled applications include the following:

• Office System 2003 – Word, Excel, PowerPoint, Outlook

• Office 2007 – Word, Excel, PowerPoint, Outlook, InfoPath

• SharePoint Portal Server 2007

• Exchange Server 2007

• XPS (XML Paper Specification) v1.0

• Internet Explorer 6.0 or later (through use of the RM Add-on for IE)