BitLocker Pain Points: Guiding Better BitLocker Management

If you have been following our blogs you know that the ideal FDE architecture has two main components. The actual encryption component is a separate layer from the key management. The encryption can be done by the OS (e.g. BitLocker for Windows or FileVault2 for Mac), by Self-Encrypting Drives (SEDs) or by ISVs such as WinMagic’s FIPS140-2 validated software cryptographic engine.

In the case of BitLocker it is a good encryption method when combined with an application aware management system that is designed to ease its deployment and operation. That is, a system that addresses the pain points of using BitLocker while retaining its advantages.

For example, in an enterprise environment when an IT Admin prepares a machine and encrypts it often, the end user for the laptop is not known. When the machine is finally put in the hands of the end user, the end user needs to complete the registration process. With MBAM BitLocker management, or most other BitLocker management software for that matter, this is a manual step that the end user may skip. If they do skip this step the laptop remains unsecure and out of compliance with the company’s security policy. This is major pain point with BitLocker management that our customers have brought to our attention and hi-lights the need for intelligent application aware management.

What they have asked for is a deployment process where:

  • The IT Admin can provision and encrypt the machine without knowing who the end user will be and
  • A seamless way for the end user to take possession and the machine to become compliant and secure without relying on the end user to complete a registration.

This is where the concept of the secure-moment comes in. Read our blog on the “Two-Stage Model for Key File Deployment” for a full explanation. But here is the gist of it, when the machine is provisioned and the end user is not known the device (e.g. laptop) contains a temporary provisioning key file. This file is not specific to the user; it is present simply to enable the device to provide basic operations until the actual user can be identified. The device at this point is encrypted but set up for autoboot with automatic unattended pre-boot authentication. When the device is provided to the end user for the first time and they login to Windows the secure-moment occurs.  In the Secure Moment, the device “owner” is identified and authenticated, the user’s key file for the device is prepared, the key file is transferred to the device and stored, and finally the provisioning key file is removed. The end user cannot bypass the secure-moment (“registration”) yet the system is smart enough not to confuse the IT Admin who configures the machine as the end user.

This was just one example of how BitLocker pain points can be addressed with intelligent application aware key management.  For more examples read our eBook “A Guide to Better BitLocker Management”.

Previous Post
CloudSync: Last Defense For Intellectual Property on EFSS
Next Post
Encryption Challenges in a Changing Tech World