If you go solely by top-level stats on encryption use, you'll come away feeling pretty secure--86% of the the 499 business technology professionals responding to our InformationWeek Analytics State of Encryption Survey employ encryption of some type. But that finding doesn't begin to tell the real story. Only 14% of respondents say encryption is pervasive in their organizations. Database table-level encryption is in use by just 26%, while just 38% encrypt data on mobile devices. And 31%--more than any other response--characterize the extent of their use as just enough to meet regulatory requirements.

The reasons for this dismal state of affairs range from cost and integration challenges to entrenched organizational resistance exacerbated by a lack of leadership. The compliance focus is particularly galling. Encrypting a subset of data amounts to a "get-out-of-jail-free card" because it may relieve companies from having to notify customers of a breach. But knowingly doing the bare minimum to check a compliance box isn't security; it's a cop-out.

Admittedly, IT pros often face stiff resistance when they try to do more. "Our IT staff is working to increase the use of encryption, but frankly, users are more interested in quick and easy access to their data and don't really think about security," says one respondent. "The idea of getting data on a flash drive or laptop encrypted never enters the minds of most of the staff, from the director on down."

We say entrenched resistance because this isn't a new phenomenon--back in 2007, a Ponemon Institute survey found that just 16% of U.S. companies take an enterprise-wide approach to encryption. Network Computing examined the state of enterprise encryption at the time and found adoption to be a gradual process, often starting with backup tapes and spreading from there. A piecemeal approach was the norm then, and we're still moving in fits and starts, despite the momentum generated by compliance frameworks such as PCI, which requires encryption of credit card data in transit.

The Interoperability Factor

Part of the problem is that standards efforts have yielded exactly zero breakthroughs where we need them most--in interoperability, which would make encryption management easier and less expensive. We don't expect that situation to get better anytime soon.

When we asked IT pros what would increase their companies' use of encryption, responses ranged from built-in operating system support for creating encrypted files and folders (something Microsoft is working toward, as we'll discuss) to improved ease of use and performance, lower cost, and better key management. A few desperate souls wished for more regulation, or even a breach that would require notification of customers, to use as leverage for gaining funding and management buy-in.

"I'd like to think that it would only take the force of will to do the right thing," says a network director at an educational institution. "In reality, it would probably require a breach or exposure to shine the light on the problem."

Our favorite response: "I wish I knew so I could exploit it."

The prevailing CYA attitude substantiates why regulatory compliance is now--and will be for years--the leading driver of encryption. Currently, 44 states have data breach laws, with many basically saying that even if you throw a backup tape loaded with personal information into a tchotchke bowl at Black Hat, as long as it's encrypted, you don't have to notify customers. Companies that implement encryption can avoid literally millions of dollars in notification expenses if they're breached, and that's not even calculating the soft costs of lost customer goodwill and erosion of trust.

That's what we call ROI.

Now, we're not saying that covering one's rear flank isn't a worthy investment. It has definitely allowed some IT leaders to get real risk-reducing projects under way. But in our experience, undertaking an enterprise-wide initiative as complex as encryption mainly to comply with regulations will generally result in a project that's poorly planned and likely to end up costing more than mapping out a comprehensive program to reduce risk.

On a positive note, 28% of survey respondents say they do want to expand their encryption use beyond just the minimum. That's good, because encryption alone isn't the ultimate solution; at some point, some part of a critical application will need to access unencrypted data, and if an application can see data unencrypted, so can an attacker.

Time For Tokenization?

The biggest change in the encryption scene since 2007 is the advent of tokenization, which helps offset some of the same risks as encryption. Simply put, tokenization is the use of a service where a system inputs a sensitive piece of information, such as credit card numbers, and receives a one-time token, such as a 64-digit number. This number is then used in applications wherever you would have used the credit card numbers, including databases. It's clear how this setup reduces risk: If the data is compromised, the attacker doesn't have any way to reverse the 64-digit number back to the credit card numbers.

Companies can buy tokenization software and hardware themselves, or they can use a third-party service. Heck, we've even seen IT groups build their own tokenization technologies, though we don't advise trying this at home. The key is that the infrastructure that performs the tokenization, whether outsourced or internal, is as secure as humanly possible because, in effect, you're transferring risk from your database and application to the servers that store and perform the sensitive data-to-token mapping. If the tokenization system is more secure than your overall infrastructure, you may have reduced your risk, but you also introduce the "all your eggs in one basket" problem. The more you use tokenization technology, the more you will store your most sensitive data in a central spot.

Centralization is also a problem with encryption keys. In our survey, we focused on key management, asking about how keys are handled and the level of faith respondents have in their ability to control encryption keys so that data can be recovered. Most respondents, 88%, say they're somewhat or very confident that keys are managed properly. But a number of respondents expressed worries around permissions and the catastrophic results of lost keys.

"Some of the systems we use are designed to destroy the key in an emergency without the possibility of recovery," says the chief operating officer of a large nonprofit. "For these systems, which hold the majority of [personally identifiable information], key recovery is not an issue. The data will be inaccessible to all."

That's the stuff of CIO nightmares.

To see how key management methods have evolved, we looked back at our 2007 article, where we identified this as a major problem, and found that, again, we haven't come very far. About half of survey respondents today use individual encryption products' key management utilities, while 39% manage keys manually.

Most are still using each encryption product's native key management capabilities, even though companies were then, and still are, very interested in a single, standardized, specialized key management system. That this is indeed the way to go is one thing most researchers agree on, and our experience confirms. This model is referred to as the "encryption platform" approach, where a single, central application manages multiple types of encryption keys (disk, backup, database).

The main driver for this platform approach is the promise of reduced operational costs and increased efficiency, since those are the big barriers to adoption. Vendors in this market, including PGP and Sophos, say their products are selling like hotcakes. Maybe--but because the cost of these platforms is so high, the challenge is to sell CIOs and CISOs on the concept that having one vendor and one single management tool for all their separate (and also expensive) encryption technologies pays off.

Now, we have to draw attention to a caveat in this model, in that we really need to nail down the term "platform." Say you use a single vendor for e-mail encryption, and the company has a backup encryption option you can enable for an additional fee. If you switch on the backup encryption, technically, you're using one platform for your e-mail and backup encryption. However, to our way of thinking, that's less a platform than a single-vendor system. To be a true platform, you need multivendor support, such as that offered by Thales.

This distinction is largely academic today because no key management platform has taken over the enterprise market, most likely because of cost. These systems start at around $40,000 for the key manager, and you still need to buy all the individual products and licenses the key manager manages. We've seen a number of enterprise-wide projects quickly run into the hundreds of thousands of dollars.

Given that, we can't blame IT groups for not aggressively pursuing an open approach. Using each encryption application's native key management capabilities was the only realistic way to go in 2007, and in the past few years, consolidation of the encryption industry as well as continued development have created an environment where most encryption vendors sell multiple encryption products as unified platforms. Money has been tight, so the native management utility approach has naturally dominated.

But we also think that a unified yet multivendor platform approach is the future. To make these systems a realistic option within the enterprise sooner rather than later, vendors must stop their arguing and actually implement an interoperability standard. There are a number to choose from: Oasis has its Key Management Interoperability Protocol (KMIP), and the IEEE has a spec, P1619, that seems to be gaining momentum, though it's only for storage devices. A follow-on, P1619.3, contains details on key management but it's still in draft form. The problem? P1619.3 and KMIP basically do the same thing.

Another issue is that few encryption vendors have experience managing keys from different providers, yet many different people are in the kitchen helping cook up these standards. We'll keep an eye on progress.

All Roads Lead To Redmond

Everyone bemoans the price of encryption and the fact that vendors can't seem to get their standards act together. So what are the chances that while encryption specialists spar over details, free and low-cost products will move in and take over?

We wouldn't bet against it, and to see why, take one more trip back to 2007. Some technical hurdles are gone, but they've been replaced with decision and policy problems. For example, many identity management products offer the capability to store certificates or keys along with identities. So instead of, "Where do we store keys for each of our laptops?" we're now asking, "How do we handle expiring and renewing keys?" One thing that hasn't changed is that a central directory of keys that is easy to manage, update, and report on is essential, and this is where Microsoft has the opportunity to become the leading encryption vendor, courtesy of its Active Directory installed base and the fact that new features are being released into Microsoft operating systems that are manageable via Group Policy Objects in Active Directory.

Now, some may not consider AD the best directory service available to businesses, but it is the most used, and plenty of IT engineers know how to work with Group Policy. All of Microsoft's major endpoint encryption offerings--including BitLocker, BitLockerToGo, and DirectAccess--offer centralized management through Active Directory, as do Microsoft's enterprise encryption technologies. The latest updates to Windows 2008 and Windows 7 provide additional settings for administrators to configure via Group Policy.

What's the downside to using Microsoft encryption technologies? In-house expertise is essential for key length, cache sizes, recovery options, and other considerations. If you support Mac OS or Linux boxes, you won't be able to leverage these technologies enterprise-wide. But Windows shops can get powerful full- and portable-disk encryption, mobile device encryption, e-mail encryption, folder and file encryption, and database encryption for free. You can't beat that price.

Beyond Microsoft, TrueCrypt is a free full disk and file system encryption product that performs faster than many commercial applications we've tested. As the open source community continues to develop these and other applications and provide key management (a vital feature lacking from TrueCrypt but available from Microsoft), we expect many encryption categories to become commodities. And creation of a public interoperability standard--if it ever happens--will give the open source community an even more level playing field.

Not that all is lost for commercial vendors, by any means. In the end, the best management interface will win, and open source technologies aren't known for having the best management capabilities compared with commercial products. Still, there's nothing like competition to keep everyone on their toes.

Plan Of Action

We're concerned after analyzing the results of our survey and talking with a number of CISOs that so much emphasis on encryption for checking off compliance boxes means that the technology isn't being used properly or to its full extent. For example, in our survey, top applications that organizations are encrypting or planning to encrypt include VPNs, file systems, and e-mail systems. Problem is, these reduce risk very minimally, if at all. Encrypting files on the desktop doesn't stop the user from e-mailing unencrypted versions or copying them to a USB device, and e-mail encryption works only if the entity on the other end is using the same or compatible e-mail encryption, too, which most companies don't do.

While we all wait for standards to shake out, organizations should adopt a risk management approach to implementing encryption, based on the type of data being handled--and not the storage medium or database name.

We should also keep the pressure on vendors to bring interoperability to encryption and key management. Unfortunately, even though standards have been produced, we don't see much uptake. Only 14% of survey respondents have ever heard of Oasis KMIP, which was started in late 2006 and finalized this year. Brocade, EMC, Hewlett-Packard, IBM, LSI, Seagate Technology, and Thales have all signed on to Oasis and have promised results by the end of this year.

The devil is in how you define "results." It's clear that vendors are more interested in building standards with storage providers than other encryption vendors. Most of the IT and infosec professionals we work with seem to get this and are dissatisfied with the interoperability efforts being put forward. Call us skeptics, but we don't think that KMIP will have any real effect any time soon. For now, it's up to us to move beyond the minimum needed for regulatory compliance.

Michael A. Davis (mdavis@nwc.com) is the CEO of Savid Technologies, a technology and security consulting firm, and an InformationWeek Analytics contributor.