Question:

How do you optimize BitLocker and Windows OS security settings in a large-scale deployment?

We use WorkSpace One to manage BitLocker keys for ~300 laptops, but we still face issues with recovery mode during BIOS updates. We have enabled Intel TXT, Virtualization, VT Direct I/O, Core isolation, Security processor, Secure boot, and VBS in the BIOS and Windows 10\11 settings, as well as some GPOs to harden the OS against various attacks. However, we are not sure if these settings are compatible with BitLocker, or if they improve its performance and reliability. We would like to know how other BitLocker users have configured their BIOS and Windows settings to achieve optimal security and stability.

Answer:

How to optimize BitLocker and Windows OS security settings in a large-scale deployment

BitLocker is a Windows security feature that provides encryption for entire volumes, addressing the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices. BitLocker works best when used with a Trusted Platform Module (TPM), which is a hardware component that ensures the device hasn’t been tampered with while offline. BitLocker can also be configured with additional options such as a PIN, a startup key, or a password to provide multifactor authentication.

However, BitLocker is not the only security feature that Windows devices can benefit from. There are other technologies that can harden the OS against various attacks, such as Intel Trusted Execution Technology (TXT), Virtualization, VT Direct I/O, Core isolation, Security processor, Secure boot, and Virtualization Based Security (VBS). These features can enhance the system integrity, isolation, and protection of sensitive data and credentials.

But how do you configure BitLocker and these other security features in a large-scale deployment? And how do you ensure that they are compatible and effective? In this article, we will share some best practices and tips based on our experience of managing BitLocker keys for ~300 laptops using WorkSpace One, and enabling the aforementioned security features in the BIOS and Windows 10\11 settings, as well as some Group Policy Objects (GPOs).

There are different ways to configure BitLocker depending on the management solution you use for your devices. You can use one of the following options:

• Configuration Service Provider (CSP): this option is commonly used for devices managed by a Mobile Device Management (MDM) solution, like Microsoft Intune. The BitLocker CSP is used to configure BitLocker, and to report the status of different BitLocker functions to the MDM solution. With Microsoft Intune, you can use the BitLocker status in compliance policies, combining them with Conditional Access. Conditional Access can prevent or grant access to services like Exchange Online and SharePoint Online, based on the status of BitLocker.
• Group Policy (GPO): this option can be used for devices that are joined to an Active Directory domain and aren’t managed by a device management solution. Group Policy can also be used for devices that aren’t joined to an Active Directory domain, using the local group policy editor.
• Microsoft Configuration Manager: this option can be used for devices that are managed by Microsoft Configuration Manager using the BitLocker management agent.

Note that Windows Server doesn’t support the configuration of BitLocker using CSP or Microsoft Configuration Manager. Use GPO instead.

While many of the BitLocker policy settings can be configured using both CSP and GPO, there are some settings that are only available using one of the options. To learn about the policy settings available for both CSP and GPO, review the section BitLocker policy settings.

BitLocker policy settings

This section describes the policy settings to configure BitLocker via CSP and GPO. Note that most of the BitLocker policy settings are enforced when BitLocker is initially turned on for a drive. Encryption isn’t restarted if settings change.

Choose drive encryption method and cipher strength

This policy setting allows you to configure the encryption algorithm and key size used by BitLocker. The default encryption method is AES 128-bit with Diffuser. The other available options are AES 256-bit with Diffuser, AES 128-bit, and AES 256-bit.

The Diffuser is an additional layer of protection that makes the encrypted data more resistant to manipulation. However, it also reduces the performance of BitLocker. Therefore, you may want to choose a different encryption method depending on your security and performance requirements.

To configure this policy setting via CSP, use the following URI:

./Vendor/MSFT/BitLocker/EncryptionMethodAndCipherStrength

To configure this policy setting via GPO, use the following path:

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

Choose how BitLocker-protected operating system drives can be recovered

This policy setting allows you to configure how BitLocker-protected operating system drives can be recovered in the absence of the required startup key information. This can happen when the TPM is disabled or cleared, the PIN is forgotten or lost, the startup key is lost or corrupted, or the BIOS or UEFI firmware is updated or changed.

You can choose to allow or deny the following recovery options:

• Data recovery agents: these are certificates that can be used to unlock BitLocker-protected drives. You can specify one or more data recovery agents for each drive type. Data recovery agents must be issued by a certification authority (CA) that is trusted by all computers in the domain.
• BitLocker recovery password: this is a 48-digit numerical password that can be used to unlock BitLocker-protected drives. You can choose to generate a recovery password for each drive type, and store it in Active Directory Domain Services (AD DS), Azure Active Directory (AAD), or a device management solution.
• BitLocker recovery key: this is a 256-bit key that can be used to unlock BitLocker-protected drives. You can choose to generate a recovery key for each drive type, and save it to a USB flash drive, a file, or a device management solution.

You can also configure the following settings related to the recovery options:

• Number of times users can sign in using BitLocker recovery information before they must reset it: this setting allows you to limit the number of times users can use the recovery password or key to unlock a BitLocker-protected drive before they must reset it. This can prevent unauthorized users from repeatedly using the same recovery information to access the drive. The default value is 15.
• Omit recovery options from the BitLocker setup wizard: this setting allows you to hide the recovery options from the BitLocker setup wizard. This can prevent users from saving the recovery password or key to a location that is not secure or managed. However, this also means that users must rely on the administrator or the device management solution to provide the recovery information when needed.
• Save BitLocker recovery information to AD DS for operating system drives: this setting allows you to automatically back up the recovery password and the key package for operating system drives to AD DS. The key package contains the full volume encryption key and other information that can be used to recover the drive. The key package is required if the drive is physically corrupted and needs to be recovered to another drive.
• Do not enable BitLocker until recovery information is stored to AD DS for operating system drives: this setting allows you to prevent BitLocker from encrypting the operating system drive until the recovery information is successfully backed up to AD DS. This can ensure that the recovery information is always available in case of a recovery scenario.

To configure this policy setting via CSP, use the following URIs:

./Vendor/MSFT/BitLocker/OperatingSystemDrives/AllowDataRecoveryAgent ./Vendor/MSFT/BitLocker/OperatingSystemDrives/AllowRecoveryPassword ./Vendor/MSFT/BitLocker/OperatingSystemDrives/AllowRecoveryKey ./Vendor/MSFT/BitLocker/OperatingSystemDrives/RecoveryPasswordNumberOfFailedAttemptBeforeReset ./Vendor/MSFT/BitLocker/OperatingSystemDrives/HideRecoveryPage ./Vendor/MSFT/BitLocker/OperatingSystemDrives/ActiveDirectoryBackup/RequireActiveDirectoryBackup ./Vendor/MSFT/BitLocker/OperatingSystemDrives/ActiveDirectoryBackup/RequireKeyPackage ./Vendor/MSFT/BitLocker/OperatingSystemDrives/ActiveDirectoryBackup/RequireStartupKeyWithTPM

To configure this policy setting via GPO, use the following path:

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

\Operating System Drives

Configure use of passwords for operating system drives

This policy setting allows you to configure whether users can use passwords to unlock BitLocker-protected operating system drives. This option is only available for devices that don’t have a TPM. If a device has a TPM, users must use a PIN or a startup key instead.

You can choose to allow or deny the use of passwords for operating system drives. If you allow it, you can also configure the minimum password length and the password complexity.

To configure this policy setting via CSP, use the following URIs:

./Vendor/MSFT/BitLocker/OperatingSystemDrives/AllowPassword ./Vendor/MSFT/BitLocker/OperatingSystemDrives/MinimumPasswordLength ./Vendor/MSFT/BitLocker/OperatingSystemDrives/PasswordComplexity

To configure this policy setting via GPO, use the following path:

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

\Operating System Drives

Configure TPM platform validation profile for BIOS-based firmware configurations

This policy setting allows you to configure which system measurements are used by the TPM to validate the preboot components when BitLocker is used with a TPM. The TPM compares these measurements with the values stored in the TPM when BitLocker was enabled. If the values don’t match, BitLocker will enter recovery mode.

The system measurements are based on the Static Root of Trust Measurement (SRTM) process, which is defined by the Trusted Computing Group (TCG). The SRTM process measures the BIOS code, the boot manager code, and the master boot record (MBR) code. The measurements are stored in the Platform Configuration Registers (PCRs) of the TPM.

You

can choose which PCRs are used to validate the preboot components. The default PCR profile is.