Adam's Site on systems administration

Difficulty Level: Intermediate\Advanced

Outline

1. Prerequisites
2. Background
3. Vocabulary 
4. Active Directory Functional Level for Recovery Keys
5. Machines with TPM Installed, and Enabled.
6. Group Policy Settings
7. PCR Settings
8. Commands to Manage BitLocker
   1. System Drive Partition
   2. Create the Recovery Key
   3. Create the TPM Key
   4. Enable Encryption
   5. Suspend BitLocker Encryption
   6. Check BitLocker Status
9. Life Cycle Management with Sample Scripts
   1. Provisioning
   2. Troubleshooting
   3. Re-imaging\Re-Provisioning
   4. Recovering from Recovery Mode
   5. Decommissioning
10. Caveats
11. Security Implications
12. Conclusion

Prerequisites\Requirements:

Server End:

1. Windows Server 2008 domain functional Level or higher
2. Any Endpoint Management Server – SCCM, Kace, LanDesk, etc…

Client End:

1. OS:
   1. Windows 7 Enterprise or greater
   2. Windows 8.1 Professional or greater
   3. Windows 10 Professional or greater
2. TPM 1.2 or greater – Required, no chance of automation without this.
3. Lenovo\Dell\any big name box systems with remote Bios manageability – Not required, but useful
   • “Physical Presence for Provisioning” is Disabled – In Bios\firmware
   • CSM\Legacy Bios

Background:

BitLocker is a free encryption feature in Windows that comes standard on most versions of Windows (specific requirements listed above). BitLocker allows for the encryption of drives on the system, as a layer of security.

With traditionally unencrypted disks (the vast majority of the world’s computers), perpetrators could extract all of the data available on the local disk. This can be done by simply docking the system’s HDD onto another computer to browse the file system. Or by running a live distro of Linux\WinPE where the data would be in clear text.

Not only is the local data on an unencrypted disk at risk, but other sensitive data like password hashes could also be recovered and used for other malicious purposes.

Therefore, drive encryption is an integral part of good security. With encryption in place, hackers would have to work extra hard to disarm the encryption, in order to recover any useful information.

The problem with enabling BitLocker, or any other security feature, is that it poses a significant burden on administrators in terms of: manageability, reliability, and required knowledge. Therefore, there is a large barrier to entry for most admins who do not have time or the skills to manage BitLocker, even if the environment supports it.

In this article, I piece together fragmented information from across the web to describe a truly zero touch, transparent encryption deployment. It is remotely administrable with full cradle-to-grave life-cycle manageability. This is without having to implement MBAM, or any third party products. The only requirements are those listed above, at the beginning of this article.

With all of that said, this form of implementation is the least secure available. There won’t be a pin code for users to remember, there won’t be a usb key required at logon, it will be 100% transparent as far as users are concerned. Therefore, no multi-factor authentication.

Instead, the goal is to provide “better than nothing” encryption, which is far superior to leaving the disks in clear text. And because the process is completely automated, there are no significant costs to this implementation, besides the initial costs of setting up the policies\scripts. This is enforceable onto to as many systems as supported. And can be integrated into pre-existing workflow\ task sequences via script.

Therefore, if you meet the requirements (and have the time) you should implement this.

Vocabulary:

TPM

The “Trusted Protection Module” is a microchip that comes built-into some laptops and desktops ordered today. It provides a way of creating and encrypting keys that could be used for BitLocker and for other security related features. With TPM & BitLocker, the system would automatically decrypt the PC on startup, without requiring the use of a pin, usb, or other form of authentication.

Owner Password

When TPM is enabled, an Owner Password is used to authenticate God-like rights over the chip. This password can be auto generated and stored. But in recent editions of Windows, it is auto generated and tossed. More information on this later.

FVEK

The “Full Volume Encryption Key” is a key used by BitLocker to encrypt the entire C: drive. The FVEK is stored in metadata which itself is encrypt by the VMK, explained below.

VMK

The “Volume Master Key” unlocks the FVEK, which in turn decrypts the C: drive. This is automatically generated and managed by BitLocker.

The VMK itself is further encrypted by “Key Protectors”. Knowledge of the VMK and FVEK is not necessary for BitLocker implementation, but knowledge of the key protectors is required (as discussed below).

Key Protectors

A key protector is yet another key that protects the VMK, which in turn protects the FVEK, which in turn protects the data. The key protector comes in many forms:

a. A USB drive could be configured as a so-called “key protector”. When this is done, that flash drive has to be plugged into the pc at boot up in order to unlock the drive and boot the system.

b. A passcode (whether short or long, numerical, alphabetical, or alphanumerical) could be used as a protector. When this is in place as a key protector, the end user must supply the passcode at each boot

c. A Recovery Key can be created and stored in Active Directory. This is a must, for data recovery in an emergency. -This is needed.

d. Finally, the TPM may be used to protect the FVEK. When this is used, no information is required on the part of the user. The system automatically decrypts the drive at boot up. – This is needed.

Furthermore, you may use any combination of these encryption methods together, in order to further strengthen security. But a multi-factor authentication approach must be manually configured, so it is not a zero touch deployment and is out of scope of this article.

Active Directory Functional Level

When preparing a zero touch deployment of BitLocker, you must first consider how the recovery information will be stored. By default, BitLocker will not backup a recovery key. It’s very important to keep a copy of the recovery key for each pc.

The recovery key will grant you access to the HDD in an offline\out-of-band scenario, it will also unlock the drive if recovery mode has been triggered. Microsoft allows these keys to be stored in Active Directory. To do this requires Windows Server 2008 domain functional level or greater.

There should be a tab in Active Directory Users & Computers under each computer object. The BitLocker Recovery tab will list all of the recovery keys available per machine. Each key is assigned a GUID and timestamp to better identify the key of interest.

Detailed info this is available here: https://technet.microsoft.com/en-us/library/dd875529(v=ws.10).aspx

Machines with TPM Installed and Enabled

TPM is a requirement for zero touch BitLocker deployments. Without TPM, a user would need to setup a pin code, usb, or combination of both to access the machine on boot up. TPM allows the computer to automatically boot into Windows without any user interaction at all. This works because TPM uses some type of hardware level encryption to store the BitLocker keys. TPM checks the computer at startup for signs of corruption\compromise. If the PC passes the tests (PCR settings) then Windows is automatically unlocked. At this point, the weakest link in your security would be the minimum complexity requirements for user account passwords on the computer. This is less secure than a multi-factor authentication, requiring a pin or usb at startup, but TPM provides unparalleled convenience.

The Trusted Protection Module is a chip, and so it is something that either comes with the machine or not. You can check the machines in your environment for the existence and enablement of TPM by running this WMI query in PowerShell:

(Get-WmiObject win32_tpm -Namespace root\cimv2\Security\MicrosoftTPM).isenabled() | Select-Object -ExpandProperty IsEnabled

WMI Filter:

Select * from win32_tpm Where IsEnabled_Initialvalue='True'

NOTE: It’s possible that the TPM value changes after the WMI object is instantiated. So running the IsEnabled() method would give a more up-to-date result. But the IsEnabled_InitialValue should suffice under normal circumstances.

It’s best to purchase machines with the TPM Enabled out of the box, less work for you. If the machine(s) require some type of configuration for TPM, follow directions provided by the manufacturer, which may entail manual configuration. A lot of newer machines come with TPM pre-enabled in the Bios\firmware.

Group Policy

There’s a myriad of different policies available for BitLocker. How BitLocker behaves in your environment is dependent upon the settings configured here. For decent security and zero touch consider the following settings:

Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption:

1. Choose drive encryption method and cipher strength – AES 256-bit
2. Store BitLocker recovery information in Active Directory Domain – Enabled
3. Services (Windows Server 2008 and Windows Vista): Require BitLocker backup to AD DS – Enabled
4. Select BitLocker recovery information to store – Everything (Recovery passwords and key packages)

Create a GPO with these settings and put it in an OU containing the target PCs. These settings must be applied prior to enabling BitLocker. These settings are pretty safe and have no adverse effects if applied to all machines.

PCR Settings

This is actually a setting that would be enforced via group policy or registry. But I am going to dedicate an entire section solely to this configuration, because this is where most of your time should be spent testing\configuring. The goal here is to avoid triggering Recovery Mode under normal use scenarios.

PCR stands for platform configuration register. Broadly speaking, the PCR settings configured for BitLocker establish the required integrity checks that a booting machine must pass prior to releasing keys stored in TPM (think FVEK, VMK, etc…). This is supposed protect against tampering or hacking attempts. If the machine passes these checks, the TPM will release a set of keys usable by BitLocker to unlock the OS.

In practice, when the integrity checks fail, the machine will enter the dreaded BitLocker Recovery Mode. In this state, the machine requires manual intervention by someone to either reboot it or input the recovery password and continue the boot process.

The PCR stores a signature of the boot configuration and system state at the time of encryption. For example, the Bios version, Bios settings, the boot configuration, the MBR state, BCD settings, DEP settings, etc. All of these environmental conditions are noted by the computer at the time of encryption and are considered to be the trusted state of the machine. After a machine has been encrypted, if something as simple as the boot order changes (even if using F12 on the fly) the Recovery Mode is triggered and the Recovery Password must be applied in order to continue the boot process. Once the Recovery password is entered in, the boot configuration state calculated during that last boot attempt becomes the new benchmark\trusted set of PCRs. So, future boots with the new Bios\environmental settings should no longer trigger the Recovery Mode.

As you can imagine this would be very difficult to deal with, if a fleet of machines were remotely configured to change one of these sensitive settings. Every machine would require manual intervention by a technician that is physically present.

To avoid this nightmare scenario to begin with, I suggest changing the default PCR settings for the TPM. In Group Policy, there are settings to limit the type of PCRs required for TPM to release the keys.

These settings are found in the ADMX template for BitLocker:

Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for Bios-based firmware configurations

The listed PCR indices are as follows:

PCR 0: Core Root of Trust Measurement (CRTM), Bios and Platform Extensions

This PCR is the most important as it is the core root of trust and establishes the validity of all other PCRs. If possible, this should be left on.

PCR1: Host Platform Configuration

This PCR detects unauthorized changes to Bios configuration. This includes things as SMBios structures, CMOS data, passwords, etc… By default, this is not used by BitLocker. You may consider using this with a Bios password implemented to further protect the machine from tampering. Furthermore, if Bios passwords are not used in your environment, this integrity check could be sufficient for your Bios security requirements. As the machine would refuse to boot the OS if the Bios had been changed by any means. So, a perpetrator could examine the Bios, but could not tamper with it expecting to boot into Windows.

In terms of life cycle management, you must remember to suspend BitLocker encryption on machines that have this PCR as a requirement, whenever a change to the Bios is made. This would include all settings in the Bios and actual Bios firmware upgrades. If you do not suspend BitLocker prior to performing any of the above changes, you will trigger recovery mode. Bitlocker can be suspended remotely by use of a simple command in a script, while the machine is loaded in Windows, more on that later.

PCR 2, 3: Option ROM Code

This PCR checks any option ROMs for change.

PCR 4 & 5: IPL Code and Configuration Data

These are responsible for checking the initial program loader code. This measures the handoff from the Bios to the OS. This PCR is the most difficult to deal with, as it creates a digest for the boot device on each boot. If the digest does not match what was last measured, then you’ve failed the integrity check. In practice, this makes a mixed environment with various boot methods\PXE booting options highly prone to accidental Recovery Mode. I suggest you do not use this, as the pros of enabling these 2 PCRs are heavily outweighed by the proliferation of recovery mode occurrences across the board. But there are security implications to be considered when disabling this as with any other PCR.

PCR 6: Measures Power State Transitions

I didn’t bother with enabling\testing this, as this is not among the default enabled PCRs recommended by Microsoft. Furthermore, if a machine fails to resume from any of the sleep states for any reason, there could be a chain of trust violation, i.e. Recovery Mode.

PCR 8: NTFS Boot Sector

This helps to validate the OS initialization code. This protects against rootkits and Trojans.

PCR 9: NTFS Boot Block

This PCR ensures that the NTFS boot block has not been tampered with.

PCR 10: Boot Manager

This PCR ensures that the Operating System boot has not been tampered with.

PCR 11: BitLocker Access Control

This is required to enable BitLocker with TPM.

By default, Bitlocker automatically selects and uses: PCRs: 0, 2, 4, 5, 8, 9, 10 and 11. But in my experience, the 2, 4, & 5 PCRs are too problematic in some complex environments. For example, by having 2, 4, & 5 selected, you are exposing yourself to the possibility of triggering Recovery Mode over something as mundane as escaping a usb boot attempt on startup.

What’s worse is the case where a machine successfully PXE boots to a PXE boot server on startup during the time of encryption. From there on after, the machine requires that the PXE boot server provide the PXE boot menu on every startup, in order to unlock the OS. If there is a network problem of any kind: a bad wire, unplugged Ethernet cable, problems with the switch, the NIC, or if the server goes down, or changes are made to the boot menu; all the machines that were configured to startup on that server will fail to boot. This could be a widespread issue. A DOS attack could be as simple as overloading the TFTP\PXE server in order to bring the entire BitLocker enabled network down.

So like all things security related, you must weigh the pros and cons. In my tests with Lenovo systems, it is best to use: 0, 1, 8, 9, 10, & 11 if the goal is to have a zero touch config. With this configuration, Recovery Mode will almost never be triggered by accident.

In my tests, the Recovery Mode would only be triggered when:

1. The Bios on the machine is updated, or any of the settings have been changed.
2. The system wide DEP/BCD settings are changed.
3. Any Hardware changes – Not including docking stations, but this varies per manufacturer and must be tested.

Other than that, Recovery Mode is not a concern. You must read in-depth articles on the pros\cons of enabling\disabling each of these PCR requirements.

Final note is that these settings are not transferable to UEFI firmwares. These have their own PCR indices, with their own meaning. However, the same principle applies.

https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf

Useful commands

In order to roll out BitLocker in an automated fashion, scripts must be used. I will list useful commands in both CMD and PowerShell:

Partition HDD for BitLocker

Before BitLocker can be enabled, the HDD has to be partitioned appropriately. You can run the useful BdeHdcfg.exe tool to automatically configure partition on the drive for BitLocker.

CMD: BdeHdCfg.exe -target %SystemDrive% shrink -quiet –restart

Create a recovery key (for emergency access only, stored in AD):

CMD: manage-bde.exe -protectors -add c: -recoverypassword

PS: Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector

Create the TPM key (used to auto boot encrypted OS):

CMD: manage-bde.exe -protectors -add %SystemDrive% -tpm

PS: Add-BitLockerKeyProtector -MountPoint $env:SystemDrive –TpmProtector

Enable BitLocker Encryption

CMD: manage-bde.exe -on %systemdrive%

PS: Enable-BitLocker -MountPoint $env:SystemDrive

Encryption begins after a reboot. During this boot, the PCRs kick in and creates a digest of the environmental conditions during that boot. Once the OS boots encryption starts, you could continue to use the PC as normal. It would continue encrypting in the background until complete, even after multiple reboots\sleeps\shutdowns.

All of the commands listed above should be implemented in full scripts, where prerequisites like the TPM state are checked prior to pulling the trigger on encryption. Sample scripts will be provided later on.

Check Status

To remotely (or locally) check on the status of encryption on a machine, you may use manage-bde command on its own or with psexec.

CMD: Manage-bde –status –cn %computername%

Suspension

To suspend BitLocker, run the following command in PowerShell. This makes the machine behave as though it were not encrypted at all, for a maximum number of reboots. This is to be used prior to making any changes to the Bios, boot process, HW changes, or BCD\DEP settings.

PS: Suspend-BitLocker -MountPoint C: -RebootCount 2

You may verify suspension by looking at the C drive icon, or using the status flag on manage-bde.exe.

 Life Cycle Management

Provisioning:

1. Run the same deployment tools you had previously to install Windows.
2. Post Install, place the machine in an OU containing the GPO settings for BitLocker.
3. Add the machine to the appropriate groups for the BitLocker provisioning scripts to run.
   • All of of the above should be automated via EMS, WMI filters, Group Membership, item level-targeting etc…

The sample scripts for #3:

Partition System Drive for BitLocker & Reboot

$TPM = Get-WmiObject win32_tpm -Namespace root\cimv2\security\microsofttpm | where {$_.IsEnabled().Isenabled -eq 'True'} -ErrorAction SilentlyContinue
$WindowsVer = Get-WmiObject -Query 'select * from Win32_OperatingSystem where (Version like "6.2%" or Version like "6.3%" or Version like "10.0%") and ProductType = "1"' -ErrorAction SilentlyContinue
$SystemDriveBitLockerRDY = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction SilentlyContinue

if ($WindowsVer -and $tpm -and !$SystemDriveBitLockerRDY) {
    Get-Service -Name defragsvc -ErrorAction SilentlyContinue | Set-Service -Status Running -ErrorAction SilentlyContinue
    BdeHdCfg -target $env:SystemDrive shrink -quiet
    Restart-Computer}

Create TPM Protector, Create Recovery Key,  Enable BitLocker, Backup Recovery Key to AD:

$TPM = Get-WmiObject win32_tpm -Namespace root\cimv2\security\microsofttpm | where {$_.IsEnabled().Isenabled -eq 'True'} -ErrorAction SilentlyContinue
$WindowsVer = Get-WmiObject -Query 'select * from Win32_OperatingSystem where (Version like "6.2%" or Version like "6.3%" or Version like "10.0%") and ProductType = "1"' -ErrorAction SilentlyContinue
$BitLockerReadyDrive = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction SilentlyContinue

 
#If all of the above prequisites are met, then create the key protectors, then enable BitLocker and backup the Recovery key to AD.
if ($WindowsVer -and $TPM -and $BitLockerReadyDrive) {
 
#Creating the recovery key
Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector
 
#Adding TPM key
Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -TpmProtector
sleep -Seconds 15 #This is to give sufficient time for the protectors to fully take effect.
 
#Enabling Encryption
Start-Process 'manage-bde.exe' -ArgumentList " -on $env:SystemDrive -em aes256" -Verb runas -Wait
 
#Getting Recovery Key GUID
$RecoveryKeyGUID = (Get-BitLockerVolume -MountPoint $env:SystemDrive).keyprotector | where {$_.Keyprotectortype -eq 'RecoveryPassword'} | Select-Object -ExpandProperty KeyProtectorID
 
#Backing up the Recovery to AD.
manage-bde.exe  -protectors $env:SystemDrive -adbackup -id $RecoveryKeyGUID
 
#Restarting the computer, to begin the encryption process
Restart-Computer}

Troubleshooting Machines:

Suspend BitLocker prior to any Hardware/BCD/DEP/ or Bios changes. This can be done remotely for x number of reboots using Mange-BDE.exe as mentioned earlier.

The Script\Command you need is this:

PS: Suspend-BitLocker -MountPoint C: -RebootCount 2

Re-imaging previously imaged\provisioned machines:

Follow the same steps for provisioning. Windows will re-provision the TPM automatically. You may redeploy and re-enable BitLocker N times with impunity, it seems. Only consequence of this is that the AD computer object will continue to keep record of the recovery keys through time, though not a big deal and may actually be desirable.

Recovering from Recovery Mode:

If ever Recovery Mode is triggered, you have two choices:

1. Undo the changes that caused it.
2. Go to AD Computer Object, get the recovery key with the latest timestamp, and use it to manually unlock the system.

Decommissioning Machines:

If the TPM on a machine only contains the randomly generated keys used for BitLocker (which is the default), then it is typically safe enough to merely format the C drive with One pass zero write (or even a simple format).

Caveats

When the TPM is initialized in Windows, the Owner password is generated, then tossed.  There is no record of it unless the machine is pre-configured to back up the Owner PW to MBAM or AD (which requires a Schema change). Another option would be to back up the Owner Password to the registry of the local machine. Because the machine would get encrypted, it is *theoretically safe*.

Best practice is to NOT do any of this, and leave it as default, allowing the password to be randomly generated then deleted, not knowing what it is.

From my tests, the TPM chip gets re-owned upon reinstallation of Windows. When Windows is installed, the TPM chip is recognized and automatically provisioned for use. This goes against what is commonly said online; that once a TPM chip has an owner, no software or user is capable of claiming ownership outside of manually resetting the chip to factory defaults.

To test this, I used the Get-TPM cmdlet to make note of the SHA-1 hash of a manually configured owner password. From there, Windows is redeployed to auto provision the TPM. Once installed, Get-TPM is used again to verify the hash. If the hash changes, then the owner password is not the same between installs. Thus, the TPM has been re-owned.

Results revealed that not only is the password not the same between installs, but that the OwnerAuth attribute\object does not contain any value upon auto-re-provisioning. I do not know if this is to be expected or not, but makes sense given how Windows keeps no record of the owner pw upon initial provision. Which means that software, in this case Windows, CAN take ownership of a previously configured TPM chip.

The Trusted Computer Group’s Spec sheet for TPM 1.2 Says:

Clearing the TPM is the process of returning the TPM to factory defaults. It is possible the platform owner will change when in this state.

The commands to clear a TPM require either TPM Owner authentication or the assertion of physical presence.

The TPM_ForceClear must only be possible when the issuer has physical access to the

platform. The manufacturer of a platform determines the exact definition of physical access.

The commands to clear a TPM require either TPM Owner authentication, TPM_OwnerClear,

or the assertion of physical presence, TPM_ForceClear.

TPM and platform manufacturers will determine the actual implementation approach. The strength of the protection mechanisms is determined by an evaluation of the platform.

For more information – https://trustedcomputinggroup.org/wp-content/uploads/mainP1DPrev103.pdf

Based on my findings in Windows, a new owner is set and so previous information has to be cleared upon installation of Windows. This could be caused by one of the following conditions:

1. The manufacturer (In this case, Lenovo) considers the installation and configuration of Windows as “physical access” and “Clearing the TPM” prior to taking ownership is part of Windows’ TPM provisioning process.

2. Provisioning the TPM does NOT require “Physical access” and “Clearing the TPM” prior to taking ownership is part of Windows’ TPM provisioning process.

I believe that I am experiencing condition number 2, as the systems I am dealing with comes with the following TCG Bios settings pre-configured:

“Physical Presence for Provisioning” is Disabled

“Physical Presence for Clear” is Enabled

Condition #2 is fine by me. Whether or not these settings are available is completely dependent upon TPM version, and manufacturer. The Bios settings should be remotely administrable in WMI. Anyone with more\better\accurate information on this is welcome.

End result is that you may re-image a BitLocked system as much as you want, and allow Windows to auto provision the TPM and subsequently BitLocker. You don’t have to actively manage this.

Security Implications\Countermeasures

Windows OS Security Matters

Implement least-privileges policy across the board if not done already, and require complex AD passwords. Configure a software firewall to your best ability. Have an antivirus active scanning agent on the OS. Also, run EMET to defend against zero days. Finally, run SCM on the image to further reduce attack surface.

Basically do best practices to harden Windows as much as possible via GPO or any EMS. Because, although the machine is encrypted, it will still boot to the Windows login screen automatically.

Owner Password (if stored in registry of local machine):

An attacker could allow the machine to auto decrypt and boot to the login screen. From there, the machine could be given network access, where exploits could be used to gain remote registry access over SMB\RPC. With the Owner Password stored in the registry, the attacker could use it to gain access to the encrypted drive.

A countermeasure for this would be to leave the owner password as default: Allow Windows to auto generate a complex password and delete it. Do not store it.

Implement a Lockout Policy

To protect the machine from brute force attacks on cached domain credentials, implement a lockout policy on BitLocker. If the system detects a brute force attempt, the machine is put into Recovery Mode

https://technet.microsoft.com/en-us/library/jj966264(v=ws.11).aspx

Direct Memory Access Attacks

This is harder to defend against. DMA can be done once the machine is running, or sleeping. What this means is that a tool can be used to read the contents in memory where the FVEK could be floating around somewhere.

This is less of an issue for modern systems, especially mobile systems, that do not even have DMA ports available.

But to protect against this:

1. Upgrade to Windows 10, as I could not find any point and shoot scripts that are proven to work for 10 as there are for 8.1 & 7.
2. Disable the SBP-2 driver in the BitLocker GPO. https://support.microsoft.com/en-us/kb/2516445
3. Force machines to hibernate rather than sleep. As the contents in memory are saved to disk during S4, therefore encrypted. I do not know if the PCRs I selected would prevent DMA when detected on startup or not. This requires more testing.
4. Implement multi-factor encryption. Not zero touch.
5. Implement EMET:

The BDESVC.dll is run under the svchost process. Protecting the svchost process with as many mitigation techniques as possible in EMET may help. While I have no clue as to the efficacy of using EMET under this scenario, the idea of memory randomization and obfuscation sounds like it could be useful to break hard coded DMA scripts. Anyone with more info on this is welcome.

Conclusion

Once implemented, this is a truly automated config that you do not have to actively manage. And you will enjoy better security as a result. Comment below with any additional knowledge\suggestions.

Script(s) Mentioned in This Post:

Enable BitLocker (https://adameyob.com/scripts/create-tpm-protector-create-recovery-key-and-enable-bitlocker/)

Partition Disk for BitLocker (https://adameyob.com/scripts/partition-system-drive-for-bitlocker/)