Volume encryption and Exchange

Computer security’s a complex and fairly arcane topic, but it’s become a mainstay of press coverage in outlets like the Wall Street Journal and the New York Times. There’s one area of security that gets comparatively little press, though: encrypted stored data so that an attacker who has physical access to the data and can copy it can’t read it.

This encryption of “data at rest” is of particular interest to Exchange admins because the Exchange public folder and mailbox databases can easily be mounted and inspected through a variety of methods. Thus an attacker who can connect to your server and steal the databases may end up being able to read every message that users in those databases have sent or received. (Of course, Exchange already supports TLS, IPsec, and other methods of encrypting data in transit, so I’m going to skip over them here.)

This risk is exacerbated by Exchange 2010’s support for DAGs. Why? DAS, that’s why. If your Exchange database is on a SAN, or a RAID array, an attacker who steals a single drive probably won’t end up with anything useful. On the other hand, if you subscribe to the one-disk-per-database DAS model, an attacker who steals a drive may get an entire, completely usable, database in her pocket.

Of course, strong physical security is a good way to mitigate this risk. Gates, guards, and guns FTW! Not everyone can apply a high level of physical security to their servers, though, and some of us like to have defense in depth anyway.

Enter disk encryption.

There are four primary methods for encrypting data at rest on a disk. The goal of all these solutions is to protect stored data on disk, not to protect messages in transit, provide non-repudation, or improve your golf game.

First, consider two solutions that we can’t really use with Exchange:

•  third-party full-volume encryption (FVE) products. These solutions, such as TrueCrypt and PGP,  typically work by installing a Windows driver that handles volume encryption. They encrypt the entire disk volume, which means that they may also need a custom boot loader. The individual vendors may claim their solutions are supported, and they may be right.. but not by Microsoft, and not for Exchange. These solutions can be very useful for desktops and mobile PCs, but avoid them on your Exchange servers.
• the Encrypting File System (EFS) , the Old Faithful of Windows-related encryption technology. EFS has been part of Windows for a long time now and is very mature. EFS has the advantage of being tightly integrated with Windows and taking automatic advantage of group policies, the Windows PKI, and other technologies. There’s one small fly in the ointment, though: it’s not supported for use with Exchange.

Next up, we have self-encrypting disks (SEDs). Over time, hardware always wins. Software functions that can be assimilated into hardware generally  will be. Think of how we used to do floating-point math in software, for example… or polygon fills, or SSL handshaking, or any number of other operations that can now be performed directly by hardware. Encryption’s no different. Vendors such as Seagate and Hitachi offer disk drives that incorporate encryption as part of the drive controller.  You plug the drive in, and from the minute it’s initialized the data on it are encrypted by the drive controller. Key management is an issue for SEDs, though. If you store the key on the drive, it goes with the drive and is thus available to an attacker. To prevent the drive from being reused in another server after being stolen, there’s usually an authentication step that must take place, either via a BIOS password or a boot loader. You can also use a controller, such as LSI’s SafeStore line, to provide more advanced key management.

Then there’s BitLocker, Microsoft’s FVE solution. It’s designed to be used with computers that have a TPM for securely storing the volume encryption key and performing boot-time measurement to prevent tampering. One weakness of software-only FVE systems is that it’s very difficult to detect when the boot chain has been tampered with in some manner; the TPM allows BitLocker to measure boot-time parameters and compare them with stored values from the TPM. (That’s why in its default configuration, a BitLocker-protected machine won’t boot with a CD-R or DVD-R in the boot drive– changing the boot source represents a change to the boot parameters.) BitLocker has a number of other interesting security features that I don’t have space to go into here, although the Data Encryption Toolkit for Mobile PCs does a good job of explaining them.

One important aspect of BitLocker is that’s it’s fully supported for use with DAG members (see the bottom part of this Exchange team blog post). In fact, it’s supported for use on Exchange 2007 databases as well. That automatically makes it my preferred solution. It’s true that BitLocker imposes a very small performance penalty (on the order of 3-5%) compared to SEDs, but it’s also true that BitLocker is disk-agnostic and can be used to protect all the volumes on a server, irrespective of their type.

One additional, and very useful, feature of both SEDs and BitLocker is that they provide essentially instant secure drive erasure for decommissioning drives. If you instruct an SED to erase its onboard encryption key, or remove a BitLocker-protected volume from the machine to which it’s sealed, the drive is no longer decryptable. At that point, the encrypted data is indistinguishable from random noise. As described here, this benefit is attracting a great deal of attention because it reduces the risk of inadvertently leaking sensitive data when removing drives from service for repair or reuse.

If you’re not currently encrypting your Exchange data on disk, I believe you should strongly consider doing so. BitLocker and SEDs both provide solid protection against theft or unauthorized access to machines that are shut down (though admittedly this doesn’t help Exchange much), and given the potential cost of lost data, the cost of deploying them may be money well spent.