Case Study: Contoso Pharmaceuticals

Applies To: Windows 7, Windows Server 2008 R2

This case study shows the process that Contoso Pharmaceuticals used to design its BitLocker strategy.

Audit and build process

The Contoso IT department reviewed its current build process and security policies to determine if any changes were needed to deploy BitLocker and incorporate it into the company's infrastructure.

Current IT department structure

The Contoso IT department consists of three distinct IT groups: a central IT department and two business IT departments. The Contoso IT department manages a mix of centralized and decentralized organizations.

Central IT

This department manages the company-wide IT technologies and core infrastructure services, such as user authentication, e-mail services, networking services, and core desktop deployment and management services.

Business IT

The two business unit–focused IT organizations, Sales and Research, manage IT functions and engineering for their respective organizations. However, they do not provide support to the larger organization.

The following table shows that new desktop deployments at Contoso occur within all three of the company's organizations. It is important to know where computers enter and exit the organization, as well as how they are configured and deployed when they arrive.

Contoso IT department service roles and scope

IT organization Service roles Users supported Desktop computers supported

Central

  • All networking support

  • E-mail services for all users

  • User authentication

  • Desktop management services

  • Operating system help desk support

  • New desktop deployment and decommissioning

  • Corporate security

120,000

100,000

Sales

  • Business unit application support

  • Business unit help desk

  • New desktop deployment

30,000

35,000

Research

  • Business unit application support

  • Business unit help desk

  • New desktop deployment

45,000

55,000

Complicating deployment and management, Contoso has several physical locations. The following figure shows the physical layout of Contoso.

System build process

When new computers enter the Contoso environment, the delivery location is determined by the computer's destination.

For example, if a new computer was ordered for an IT administrator who is part of the Central IT department, the computer is configured in Chicago, IL. If this computer is destined for a sales location in the southwest region, then it is shipped directly to the destination site for configuration.

The following table shows how the basic system configuration tasks are handled at Contoso.

System configuration tasks

IT department System configuration Configuration location

Central

Central IT configures new computers at a central location and delivers them to the users.

Chicago, IL

Sales

Research

Users get their new computers directly, and Sales and Research IT must configure them remotely.

Sales or Research office location

Each of the three groups has created its own new method of building and deploying Windows 7 operating systems that use Windows 7 deployment tools. Contoso is installing only Windows 7 as the standard corporate operating system.

The process that each business unit follows is independent. However, they do share some infrastructure dependencies. The following table shows the processes that each business unit uses, as well as the infrastructure components that they rely on.

Contoso build processes

Business unit Windows deployment method Windows delivery method Application delivery method Infrastructure dependencies

Central

Windows 7 imaging format

Pre-Boot Execution Environment (PXE) boot

Windows Preinstallation Environment (Windows PE)

Integrated with image

PXE boot servers

File share servers

Authentication

Sales

Windows 7 unattended setup

PXE boot

Windows PE

Scripted, unattended installation

PXE boot servers

File share servers

Authentication

Research

OEM-applied, sector-based image

OEM-applied image

Some integrated with image, others scripted

File share servers

Authentication

Various Contoso departments use unattended setup, sector-based, and file-based imaging technology to build computers before issuing them to users' computers. Some departments have the computers preconfigured by the OEM.

The following figure shows a comparison among the three build processes that exist at Contoso.

Each vertical pillar represents a build process flow for an individual business unit. More information about the tasks are described in the BitLocker Drive Encryption Deployment Guide for Windows 7 (https://go.microsoft.com/fwlink/?LinkID=140286). These tasks are described because they relate to deploying Windows 7 with BitLocker Drive Encryption. Most of these tasks span all three build processes, even though each build process is different.

BitLocker authentication methods for operating system drives

Contoso used the following questions to evaluate the BitLocker authentication methods.

What do you want to protect with BitLocker?

Contoso's security organization recently mandated that all computers running Windows 7 will use BitLocker Drive Encryption on their operating system drives and data drives. Contoso recently purchased new computers to support Windows Vista. These computers are also able to run Windows 7 without requiring any additional hardware upgrades. Not all of the computers that were replaced have a Trusted Platform Module (TPM) version 1.2. However, most of the replacement computers received in the last two shipments from the OEM have this capability. Because of the mix of TPM and non-TPM hardware and the security mandate, they have decided to support BitLocker on both TPM-based and non-TPM-based computers.

How strong do you want the BitLocker protection?

Most Contoso computers that are managed by Central IT and will be running Windows 7 with BitLocker do not contain highly sensitive data and are not portable computers. For this reason, Contoso wants to configure these computers with the most easily implemented configuration of BitLocker and the configuration that will have the least impact on users. They have decided to enable BitLocker by using the TPM-only mode on these types of computers.

There are several areas in the Contoso environment where the level of data protection needs to be increased because of the sensitivity of data on these computers. In the Research and Sales departments, the data that is stored on these computers is classified as very sensitive. These groups also have more portable computers than desktop computers in the environment. For this reason, Contoso has decided to use TPM + PIN on the portable computers and the TPM + USB startup key on the desktop computers.

Contoso decided to use multifactor authentication on computers that contain highly sensitive data. For portable computers, Contoso chose to use a PIN rather than a USB startup key because of the possibility that a user might leave the USB startup key with the computer in an unprotected situation. For desktop computers, Contoso has chosen a USB key because all of these computers are located in field sales locations where the USB startup keys can be secured when the computers are left unattended.

Contoso does not have a public key infrastructure (PKI), so BitLocker-protected removable drives will be password-protected instead of using smart cards. Because Contoso requires that all operating system drives be BitLocker-protected, users will be allowed to configure their removable drives to automatically unlock when they are inserted in a BitLocker-protected drive at a Contoso facility. Contoso requires that complex passwords be used in its organization and will enforce password complexity rules for BitLocker passwords.

How do you want to recover BitLocker-protected drives?

Contoso wants to record the situations that cause a drive to enter recovery to ensure that its resources are being protected and that users understand the BitLocker security requirements. Therefore, Contoso will require users to call the help desk to recover access to BitLocker-protected drives. To make it easier for the help desk to provide recovery support, Contoso will require that BitLocker recovery information and TPM recovery information is backed up to Active Directory Domain Services (AD DS) when BitLocker is turned on.

Contoso standard configuration

For security and secure asset management purposes, Contoso has decided to support and enable BitLocker on all corporate desktop and portable computers. The following table outlines the corporate standards support matrix for enabling BitLocker on Contoso corporate computers.

Corporate standards for enabling BitLocker on Contoso computers

Computer classification Description

Corporate desktop (secure site)

Computers will use BitLocker encryption with a TPM or USB startup key, depending on hardware availability. This will be used to control data exposure and manage asset retirement.

Corporate desktop (field site)

Computers will use BitLocker encryption with a TPM and a USB startup key. These desktop computers are shared-use computers in field sales locations with limited security. USB drives will contain startup keys and will be locked in a safe when not in use. This will be used to control data exposure and to manage asset retirement.

Corporate portable

New computers will use a TPM and a PIN for all computers. Non-TPM computers will use startup keys on USB drives, but all new computers will be purchased with TPM devices. This will be used to control data exposure and manage asset retirement.

AD DS configuration

Contoso's domain controllers are running Windows Server 2008, which supports the storing of BitLocker recovery keys in AD DS by default. Central IT used the information in Backing Up BitLocker and TPM Recovery Information to AD DS (https://go.microsoft.com/fwlink/?LinkId=164428) to help them enable key escrow with AD DS.

Contoso support processes

There are three supported BitLocker configurations. For each of these supported configurations, there is a required level of support and a defined process:

  • Corporate desktop (secure site)

  • Corporate desktop (field site)

  • Corporate portable

The following is an example of the process flow for BitLocker system recovery at Contoso:

  1. A user's computer enters recovery.

  2. The user calls the help desk.

  3. The help desk technician creates a support ticket and initiates the recovery process.

  4. The help desk technician questions the user and identifies the cause of recovery.

  5. The help desk technician validates the user's identity and gives the user the recovery password to unlock the drive.

  6. The user unlocks the drive by typing the 48-digit recovery password into the BitLocker recovery console.

  7. The help desk technician verifies that the user has successfully unlocked the drive.

  8. The help desk technician creates a new recovery password and backs it up to AD DS.

  9. The used recovery password is deleted from AD DS.

  10. The help desk technician documents the cause of the recovery for organizational tracking and closes the support ticket.

Inventory and tracking processes

Central IT uses an asset management system to track hardware based on custom attributes (for example, computers that have TPMs versus computers that do not). The department also tracks required BIOS updates based on the corporate standard Contoso computers. If a BIOS update is required, Central IT works with the OEM to obtain the BIOS and create a deployment method.

Deployment

As part of its deployment planning, Contoso identified both Group Policy settings and key management policies.

BitLocker and Windows 7 Group Policy settings

In the Contoso enterprise deployment of BitLocker, users are not allowed to change the existing configuration or affect the initial configuration, other than choosing a PIN.

To configure BitLocker computers in the Contoso environment, three top-level domain Group Policy objects (GPOs) will be created to control the three computer types that are identified in the computer matrix: Contoso-BitLocker-Desktop-SecureSite, Contoso-BitLocker-Desktop-FieldSite, and Contoso-BitLocker-Portable. Because the Contoso BitLocker computers are organized by computer type and location, the Contoso IT department configured the Group Policy settings to use Windows Management Instrumentation (WMI) filtering so that the policies apply only to computer types that are defined in the standard configuration. Settings that are not shown in the following tables are left at the default setting.

Contoso-BitLocker-Desktop-SecureSite

Setting Configuration

Choose how BitLocker-protected operating system drives can be recovered

Require AD DS backup of BitLocker recovery passwords and key packages

Turn on TPM backup to Active Directory Domain Services

Require AD DS backup of TPM owner information

WMI filter

Root\CimV2; select * from Win32_OperatingSystem where Version = "6.1"

Contoso-BitLocker-Desktop-FieldSite

Setting Configuration

Choose how BitLocker-protected operating system drives can be recovered

Require AD DS backup of BitLocker recovery passwords and key packages

Turn on TPM backup to Active Directory Domain Services

Require AD DS backup of TPM owner information

WMI filter

Root\CimV2; select * from Win32_OperatingSystem where Version = "6.1"

Contoso-BitLocker-Portable

Setting Configuration

Choose how BitLocker-protected operating system drives can be recovered

Require AD DS backup of BitLocker recovery passwords and key packages

Require additional authentication at startup

Require startup PIN with TPM

Turn on TPM backup to Active Directory Domain Services

Require AD DS backup of TPM owner information

WMI filter

Root\CimV2; select * from Win32_SystemEnclosure where ChassisTypes = "10" or ChassisTypes = "9" or ChassisTypes = "8"

WMI filter

Root\CimV2; select * from Win32_OperatingSystem where Version = "6.1"

Note

Client support for WMI filters exists only on computers running Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows 7, Windows Vista, or Windows XP. WMI filters are available only in domains that have at least one domain controller running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003.

Other Group Policy settings

Additional Group Policy settings establish a default power plan and restrict access to the Power Options Control Panel item. This applies to the computer object portion of the Group Policy. The following tables detail the specific Group Policy settings that are configured in the Contoso environment.

Contoso-BitLocker-Desktop-SecureSite

Computer setting Configuration

Allow Standby States (S1-S3) When Sleeping (Plugged In)

Not configured

Allow Standby States (S1-S3) When Sleeping (Battery)

Not configured

Configure use of passwords for removable data drives

Require complex passwords with a minimum of 12 characters in length

Contoso-BitLocker-Desktop-FieldSite

Computer setting Configuration

Allow Standby States (S1-S3) When Sleeping (Plugged In)

Not configured

Allow Standby States (S1-S3) When Sleeping (Battery)

Not configured

Configure use of passwords for removable data drives

Require complex passwords with a minimum of 12 characters in length

Contoso-BitLocker-Portable

Computer setting Configuration

Allow Standby States (S1-S3) When Sleeping (Plugged In)

Disabled

Allow Standby States (S1-S3) When Sleeping (Battery)

Disabled

Require a Password When Computer Wakes (Plugged In)

Yes

Require a Password When Computer Wakes (Battery)

Yes

Configure use of passwords for removable data drives

Require complex passwords with a minimum of 12 characters in length

Prebuild configuration

Contoso has defined its prebuild configuration by using the OEM-specific configuration and defining the disk configuration that will be implemented for each department.

OEM-specific configuration

All three business units have their computers preconfigured from the OEM with the following settings:

  • Endorsement keys are generated and managed by a computer reseller after the computer is manufactured.

  • TPMs are shipped in the enabled and activated state.

  • Default BIOS administrator passwords are set.

The Research IT business unit at Contoso also has the OEM apply a Contoso image before the computers are shipped. The other business units apply the operating system to their computers after they receive them from the OEM.

Post-build configuration

Contoso has created definitions for TPM management and encryption configuration.

TPM management

Taking ownership of the TPM is automated during the computer build process. This is accomplished by automatically logging on to the computer at the end of the build process with a domain user account. Logon with a domain account is required because the Contoso BitLocker Group Policy settings require the TPM owner information be backed up to AD DS. During the take-ownership process, a hash of the TPM owner password is saved to the computer's object in AD DS. This backup process happens at the point ownership is taken of the TPM, so it is important that the logged on account has write access to AD DS and the computer object.

To automate the process, Contoso added the following entries to the Windows-Shell-Setup section of the unattended installation answer files used in the image-based and unattended build processes.

<AutoLogon>
    <Enabled>true</Enabled>
    <Username>ContosoBuildAccount</Username>
    <Password>ContosoStrongPassword</Password>
    <LogonCount>1</LogonCount>
</AutoLogon>
<FirstLogonCommands>
     <SynchronousCommand>
          <Order>1</Order>
          <CommandLine>enablebitlocker.vbs /on:tpm /l:%temp%\enablebde.log</CommandLine>
          <Description>Take ownership of the TPM</Description>
     </SynchronousCommand>
</FirstLogonCommands>

Encryption configuration

At Contoso, there are three standard BitLocker configurations: secure site computers, field site computers, and portable computers. During the build process at Contoso, one of the last steps is to enable BitLocker and start the drive encryption. Contoso modified the sample scripts downloaded from the BitLocker Deployment Sample Resources (https://go.microsoft.com/fwlink/?LinkID=151997) to accomplish this. The following tables show the commands that are issued on the various computer types, depending on the desired configuration.

Contoso-BitLocker-Desktop-SecureSite

Command Description

Enablebitlocker.vbs /on:tpm /promptuser /l:%temp%\enablebde.log

For computers with a TPM, enable BitLocker by using a TPM. ,. The results of the process are saved to the specified log file.

Enablebitlocker.vbs /on:usb /promptuser /l:%temp%\enablebde.log

For computers without a TPM, enables BitLocker by using a startup key. The results of the process are saved to the specified log file.

Contoso-BitLocker-Desktop-FieldSite

Command Description

Enablebitlocker.vbs /on:tsk /promptuser /l:%temp%\enablebde.log

Enables BitLocker by using a TPM plus a startup key. The results of the process are saved to the specified log file.

Contoso-BitLocker-Portable

Command Description

Enablebitlocker.vbs /on:tp /promptuser /l:%temp%\enablebde.log

For portable computers with a TPM, enable BitLocker by using a TPM + PIN. The results of the process are saved to the specified log file.

Enablebitlocker.vbs /on:usb /promptuser /l:%temp%\enablebde.log

For computers without a TPM, enables BitLocker by using a startup key . The results of the process are saved to the specified log file.

Note

The Enablebitlocker.vbs script will attempt to create a recovery password regardless of which /on option is used to enable BitLocker. If BitLocker is configured to back up recovery information to Active Directory Domain Services (AD DS), backup will occur during this process. If AD DS backup is required and the process fails because it cannot contact AD DS, then all of the protectors that were previously created will be deleted, and the script will exit with a failure code. If AD DS backup is not required, the script will query the event log for event IDs 513 and 514. Event ID 514 means a successful backup of the computer recovery information to AD DS. Event ID 513 means a failure to back up computer recovery information to Active Directory. If either of these events is found, it is sent to the script log.