The fundamentals of FDE: Comparing the top full disk encryption products

FDE criteria No. 1: Device deployment

It would seem that OS-provided FDE software would have a distinct advantage in device deployment because the software is already installed as part of the OS. This isn't the case, however.

Configuring the software -- and keeping the configuration locked down -- is often a much greater challenge than software installation in FDE deployment. If users can modify the FDE configuration, they are likely to either inadvertently or intentionally weaken or disable the technology, rendering it useless. Users can also commit a denial of service against their own systems by deleting encryption keys or otherwise making unwise configuration changes.

The commercial FDE products offer remote deployment capabilities, so that a system administrator does not need to physically visit each end user device. This can be an invaluable time saver, plus a necessity for remote users (e.g., teleworkers, those on extended travel). The OS-provided Microsoft BitLocker is somewhat manageable through Group Policy, but it's really intended for local management, as is Apple FileVault 2. The open source products generally require local installation and configuration, and they typically assume a benign end user will not alter the FDE configuration.

FDE criteria No. 2: Product management

With FDE, management isn't strictly limited to FDE configuration. There are many facets of management to consider, including key rotation, password changes, patch installation, and cryptographic upgrades (e.g., longer key sizes, new encryption algorithms).

The importance of centralized management for enterprise FDE deployments cannot be overemphasized. The main cost of FDE is not the software itself, but the management and support of it. Just because a solution has a lower initial cost does not mean that it will actually cost less to operate in the long run. Open source solutions generally do not offer any sort of centralized management capability, which can make them particularly expensive to manage and support, especially in a sizable enterprise.

One of the most surprising things about FDE is that the OS-provided products are often considered difficult to manage and are supplemented by the use of other FDE products. Some of the commercial products reviewed in this article, such as Dell Data Protection | Encryption, McAfee Complete Data Protection and Sophos SafeGuard, and WinMagic SecureDoc, actually have the ability to add management features to OS-provided FDE. This can be advantageous from a performance standpoint -- enabling the use of native FDE capabilities while ensuring that there is a single, robust centralized management framework in place that addresses both FileVault and BitLocker.

FDE criteria No. 3: Compatibility

In terms of compatibility with the existing environment, organizations should be most concerned about how an FDE solution handles a device (typically a laptop) going into a hibernation or standby mode. The concern is that a laptop in one of these modes will be lost or stolen, and if FDE is not strongly protecting its storage, then sensitive data will be susceptible to compromise.

Since compatibility will vary from product to product and operating system to operating system (and possibly even from environment to environment), it is highly recommended that organizations test their own devices with each FDE solution being considered -- be it native OS (Microsoft BitLocker, Apple FileVault 2); third-party (Check Point Full Disk Encryption, Dell Data Protection | Encryption, McAfee Complete Data Protection, Sophos SafeGuard and Symantec Endpoint Encryption); or open source (DiskCryptor). That way they can see how the various FDE solutions behave during hibernation or standby in their particular environments.

There can also be conflicts between FDE software and applications that access the hard drive directly -- some obvious, such as disk utilities, and others less so, such as certain asset management programs. It is highly recommended that organizations test each prospective FDE product against any applications that may have direct hard drive access to identify any incompatibilities, then follow up with the affected products' vendors for a possible resolution.

FDE criteria No. 4: Authentication service integration

It is generally recommended that organizations usemultifactor authentication (MFA) for FDE, so products that simply reuse OS password authentication are generally not acceptable. The FDE software should either have its own authentication or should leverage enterprise MFA, such as Active Directory, smart cards or cryptographic tokens, (preferably the latter). All the commercial products mentioned in this article support MFA, including smart cards and cryptographic tokens, while Dell Data Protection | Encryption is noteworthy in that it also specifically supports biometrics. For the Apple FileVault 2 and Microsoft BitLocker features, authentication service options are quite limited unless a third-party commercial product that can add centralized management and other features is used on top of FileVault or BitLocker.

FDE criteria No. 5: Key recovery

Cryptographic key recovery is a particularly important FDE management function, because if key recovery fails or is not possible, the affected user may permanently lose access to all locally stored data. Sophisticated centralized key recovery functions are only provided by commercial add-on products. FileVault provides some centralized key recovery: It will store a recovery key with Apple and allow a user to call Apple to recover that key. However, having a third party hold encryption keys could violate organizational security policies, so enterprises must be aware of where recovery keys are stored when evaluating potential products. Microsoft BitLocker offers no centralized key management when used on its own.

Commercial products support centralized key recovery activities performed by administrators, and some, such as Check Point Full Disk Encryption and Symantec Endpoint Encryption, also support self-service recovery for users. It is important to carefully evaluate recovery options for their own security.

For example, self-service recovery products may involve users answering questions, such as their favorite color or pet's name. Such questions can often be exploited to gain unauthorized access to a user's password and therefore circumvent FDE on that user's device. When evaluating recovery options, an organization should first determine if users or administrators (or both) will be performing key recovery.

FDE criteria No. 6: Brute force mitigation

The most common mitigations against brute force password attacks are having an increasing delay between authentication attempts, suspending authentication attempts for a time period or wiping a device after too many failed attempts. The need for any of these mitigations will be greatest if single-factor (password) authentication is being used. None of the products mentioned in this article, except for Check Point Full Disk Encryption and Symantec Endpoint Encryption, promote mitigations against brute force attacks, so it is important to ask vendors for additional information on this.

FDE criteria No. 7: Cryptography

Given the current state of cryptographic technologies, it is generally expected that an FDE product utilizes the Advanced Encryption Standard (AES) algorithm, preferably with a key that is 256 bits long. All of the products mentioned in this article use AES and all support the use of 256-bit keys.

It is also recommended, and actually required by some organizations, that FDE products be formally evaluated to determine if their cryptographic implementations are robust; the most common certification is Federal Information Processing Standard (FIPS) 140-2 compliance. Information on FIPS 140-2 compliance is available here.

All the commercial products and FDE capabilities built into operating systems, mentioned in this article are FIPS 140-2 compliant. Open source products, such as DiskCryptor, are not FIPS 140-2 compliant, most likely because of the financial burden involved in achieving certification. Therefore, organizations needing to use FIPS-compliant products may have to fund the certification process for these open source products themselves if they want to implement them.

Another facet of cryptography to consider is where cryptographic keys are stored -- locally or remotely, and if locally, where on the device. For example, Dell Data Protection | Encryption and Microsoft BitLocker can use a local Trusted Platform Module, or TPM, to strongly protect storage. If keys are stored locally and that storage is not properly secured, attackers may be able to recover the keys and circumvent the FDE-provided protection, thus breaching the device.

Conclusion

All of the software addressed in this article would provide a basic FDE product. What most differentiates the products for enterprise use is overall software management capabilities. For example, many organizations purchase FDE products even though they already have OS-provided FDE software because of challenges involved in managing the OS-provided FDE. There are also open source products, which provide a free FDE capability, but they lack management features and are best suited for use by individuals and one-off systems, not for standard enterprise deployment.

Among the commercial products, there is not a great deal that truly distinguishes one from another. It is up to each organization to review the products and determine which best meets its own needs. In many cases this will mean purchasing a product from the same vendor that supplies other security products in use within the enterprise. Organizations should feel comfortable using any of the commercial products for enterprisewide FDE deployments.