These are the top 10 questions you should ask yourself and your vendor(s) before choosing a file encryption or whole drive encryption product.
Whole drive encryption is definitely not the security panacea the vendors make it out to be. It's not even a silver bullet for Data Loss Prevention (DLP), the latest buzzword in this field. The vendors are often not very helpful in guiding you through these issues because they want to sell you something, and the free products might cost a lot more than you think when you include technical support and user training, so keep the following questions in mind as you search for a data encryption solution.
Does The Solution Match Your Threats?
Perform a quick risk analysis and ask yourself exactly what you are trying to prevent. Disk encryption by itself won't stop most malware infections, network worms, password sniffing, attacks against listening TCP/UDP ports, malicious insiders, SQL injection attacks, or a hundred other bad things. Whole drive encryption is simply not a panacea.
If you are mainly worried about laptop theft, then ask your favorite vendors how well their products withstand 1) cold boot attacks and 2) attacks using a laptop's 1394 Firewire port. These well-known attacks often allow hackers to simply bypass the encryption entirely. Ask your vendor if they are familiar with these techniques, and if they've never heard of these attacks (bad sign), then e-mail them these URLs and insist on a response:
http://en.wikipedia.org/wiki/Cold_boot_attack
http://www.net-security.org/dl/articles/windows7_firewire_physical_attacks.pdf
Whatever your favorite encryption product is, do a Google search on "cold boot attack <productname>" and "firewire attack <productname>".
Be honest, are you really only worried about lawsuits and regulatory compliance, not actually protecting your data? These are in fact separate issues. If you are more worried about lawyers than hackers, then do you really have to buy the most expensive and user-obtrusive solution with all the bells and whistles in order to show responsible due care? Will a jury understand the nuances of file-based vs. sector-based encryption or TPM vs. smart card or AES vs. 3DES or ... ? (Talk to an attorney, I'm only posing questions to consider.)
And something else to ponder: If your encrypted server can reboot unattended without any human interaction, and the server doesn't have a cryptographic hardware module (like a TPM), then why can't its boot-up process be reverse engineered in order to reveal the key? From power-on to live listening ports, it's just a dumb deterministic machine following coded rules, and the keying material has to be somewhere on the drive...
At What Layer(s) Do You Want To Encrypt Data?
There are many different ways to encrypt data. You can encrypt files by changing their format (which is independent of the filesystem, e.g., an GnuPG file), have a mountable encrypted file (with its own internal filesystem, e.g., a TrueCrypt drive), the encryption can be built into the "real" filesystem (like EFS or BitLocker), or the encryption could be handled by special hardware with any of these. How does your vendor do it? What method is best for your organization? It's important to at least understand the difference.
There are also some special cases, and not all products will encrypt them: the boot sector, master boot record, partition table, hibernation file, swap files, temp files, databases, database transaction logs, rendered print spool files, and the operating system's own files. Generally, whole-drive encryption products can encrypt all of these, but file-based products often cannot.
And what about when files are being sent over the network? Do they stay encrypted in transit? Will you use IPSec? How will you enforce these policies on all systems?
How Much User Training And Technical Support Will Be Required?
If a product is obtrusive or bug-ridden, the user training and technical support will cost more in the long run than the licenses! Make sure to perform focus group testing before wide-scale deployment. Will users actively resist the product or just grumble a bit? Will users install or configure the product themselves, or can it be all handled centrally? Will users choose what gets encrypted? Can you realistically trust users to encrypt the correct files? Will users create and back up their own recovery keys? How much extra training will the help desk require when users call for assistance? Often, these expensive "soft" issues are ignored until it's too late.
Is The Product Compatible With Your Applications And Infrastructure?
To centrally manage your encryption solution, will you need a PKI, Active Directory, RADIUS, a new special-purpose server, or new cryptographic hardware? If you don't currently have the infrastructure or expertise for this, the solution may be more expensive than originally thought. On the other hand, if you already have an infrastructure in place, like a PKI or Active Directory, maybe you should try to leverage these sunk costs to maximize the value of your investment.
Are you absolutely certain your user applications are compatible with the encryption product? Are you trusting what the vendor just says or has your own IT department done hands-on testing? This can really burn you down the road if you're not careful. And what about your anti-virus scanners, can they scan encrypted files? What about your database software which directly accesses the sectors of the hard drive, is it trying to bypass the encryption layer? What about your IDS/DLP network sensors being unable to decipher encrypted traffic?
Does the encryption product require physical human interaction when the machine reboots, such the entry of a PIN or passphrase? If you have hundreds of servers scattered around the world, this can be very inconvenient and you will likely have to entrust other people with these secrets.
What Operating Systems And Platforms Are Supported?
Windows Vista is thankfully dead, but will the encryption work on Windows 7? What about your Macintosh laptops and Linux netbooks? All the world is migrating to 64-bit platforms, so is your favorite encryption product 32-bit only? You might not think you have any Linux or Mac computers, but your IT and advertising departments might disagree.
Will The Product Encrypt PDAs, Backups, Portable Drives, Etc.?
Sensitive data exists not just on laptops, but on USB drives, backup tapes, user-burned CD/DVD disks, PDAs, mobile phones, iPod/Zune players, digital cameras, etc. Will your encryption solution encrypt files on these media? Can your DLP solution prevent the storage of data on unauthorized and/or unencrypted devices? Will you be alerted when users attempt to save data on unencrypted USB drives or to burn plaintext files onto CD/DVD disks? How will you force users to only save sensitive data on encrypted drives? Will you have to manage keys or passwords for your backup tapes separately?
Can You Recover Encrypted Data When Keys Are Lost?
Without a reliable recovery method, encryption is just a self-imposed denial of service attack waiting to happen. It is inevitable that hard drives will become corrupted, TPM chips will short out, users will forget passwords or lose their USB dongles, software applications will have bugs, etc. Can you recover data when keys or passwords are lost? Does the recovery method scale to your size of organization? Is the recovery method itself secure so that it won't be the path of least resistance for hackers or malicious insiders?
How Are Keys Created, Stored, Changed and Archived?
Vendors always emphasize cipher algorithm and key length in their brochures, as though these are the most important criteria for making an encryption solution secure, but short keys and snake-oil ciphers are rarely the vulnerabilities to worry about. Most vulnerabilities stem from key management issues.
For example, if the encryption key is protected by (or derived from) the user's own password, can you enforce a strong password policy? Can the password hash be sniffed from the network, extracted from the hard drive, or stolen from the user's computer by malware? Is the same password also used for web applications, VPN, dial-up, RADIUS, eBay, Amazon, Facebook, etc.? If so, then there are more opportunities for compromise (users love to recycle their favorite passwords).
If the encryption key is on the hard drive, where is it and how is it secured? Your vendor might not even be willing to tell you (not a good sign).
If the key is on a USB dongle, will your users simply keep the dongle in their laptop cases, to be stolen at the same time as the laptop? Will the USB dongle also require a PIN? If the key is in the user's smart card or USB dongle, will the card or dongle self-erase after too many failed PIN guesses?
Can the encryption key be changed if you suspect compromise? Will the help desk have to decrypt and then re-encrypt the entire drive to change the key?
Where are backup keys stored on the network? Who can extract these backups? How are they secured? Is anyone monitoring these events?
In general, the above questions illustrate an important point: How your encryption keys are created, stored, changed, archived and otherwise managed is almost always much more important than the particular cipher or key length used. If your keys are only 40 bits long or your cipher is some homebrew garbage, this is of course bad, but you are unlikely to be even considering these.
How Does The Product Fail When It Fails?
No security system is perfect, so we must have a response plan for when the system fails. In general, we don't want cascading, silent, catastrophic failures; we'd rather have self-limiting failures which are easy to detect and recover from. For example, is the same key used on all/many systems, so that the compromise of that one key leads to the compromise of all/many systems? Is the same poorly-secured recovery key used everywhere? Can one bad apple administrator circumvent all security controls whatsoever?
When a USB flash drive is stolen, a key is lost, a laptop goes missing, encrypted files are left permanently unencrypted, backups are made in plaintext or some other bad event occurs, is there a way these events can trigger an alert, be detected or at least be audited after the fact? This is very difficult, but we want to be able to respond quickly to compromise in order to limit the scope of damage. Silent and undetectable failure which spreads is the worst, it's like a slow-growing metastatic cancer.
In your own organization, do you have an incident response team? If so, planning for the failure of your encryption/DLP solution should be a part of their training.
What About The Future - Will You Be Vendor-Locked Forever?
After choosing a vendor and deploying your encryption solution, will you be vendor-locked forever? What happens if your vendor goes bankrupt or get purchased three years from now? Does your vendor have a history of keeping up with technological changes or do they only grudgingly adapt and then charge you for the upgrade? Today you may not even know what a "tee pee hem" chip is, but tomorrow the use of a TPM or some other cryptographic hardware may be mandatory for your industry — yet that doesn't mean your vendor will support it.
If a programming bug is disclosed and a patch must be applied, can the patch be pushed out automatically or must it be applied by hand? Can we remotely scan systems to confirm the presence of the patch? Even if you are vendor-locked, does that mean you will also be version-locked by the difficulty of upgrading? If your vendor's upgrade plan is to "decrypt all laptops and USB drives, uninstall the old software, install the new stuff and encrypt again", the time and effort required for this may be far more expensive than the new licenses themselves.
Conclusion
Please don't let the foregoing discourage you from encrypting your sensitive data, just be aware that it's more complicated than it first appears. Hopefully these questions will help guide you in making the best decision for your organization. Print this article and then start asking your vendor some questions, you might be surprised what they've not been telling you all along. Good luck!
