Analysis: Enterprise Key Management

CIOS don't roll out of their beds and think, "Hey, let's sink a few hundred grand into a cohesive enterprisewide encryption infrastructure." Instead, the process is a slow creep, starting with backup tapes and spreading as compliance issues bubble up or we realize that specific applications represent financial liabilities. The result? Layer upon layer of encryption management, replete with multiple key-management challenges.

It's time to stop and think: Will a piecemeal approach to encryption and key management cost us big? Maybe, but you have little choice.

"The bad news is that regulatory pressure is causing us to turn on security from the bottom up," says Benjamin Jun, VP of technology at Cryptography Research. Jun adds that key management is where identity management was five years ago--waiting for the industry to decide on common standards.

Don't hold your breath. Even though large enterprises have been fighting this problem for years, the hard truth is, there are no standards to enable unified management of keys from disparate systems.

RSA's Public-Key Cryptography Standard 11 and Microsoft's CryptoAPI are helpful, but they're not standards. The OpenSSL project is a standards-based toolkit for crypto implementation, but it doesn't address key management. Java JCA/JCE (Java Cryptography Architecture/Java Cryptography Extensions) is akin to Microsoft's CryptoAPI: If you're using Java and JCE, it might meet EKM (enterprise key management) requirements for those apps only. Sun's SKIP (Simple Key Management for Internet Protocols) provides key sharing only, no management.

Our analysis of available key-management offerings, at nwc.com/go/0430review, revealed that even without settled standards, a few vendors are taking baby steps in the right direction. For the most part, though, vendors using encryption are keeping the R&D close to home, focused on improving key management for their own offerings.

And, of course, we should be careful what we wish for. Convenience rarely comes without risk, and putting all your eggs in one basket demands hardware redundancy, secure backup and recovery capabilities, and strong authentication policies for system access.Companies just starting on the road to ubiquitous encryption should launch an EKM project before the number of disparate systems is overwhelming, and ensure new products are compatible with their strategies instead of trying to bolt on support later. Those who've adopted encryption on an ad hoc basis must realize that security is only as strong as its weakest link: If we can't handle our keys, eventually we will lose access to sensitive data, or worse, turn it loose and suffer the consequences.

Continue Reading This Story...

The State We're In

Given recent harrowing data breaches, we expected most enterprises would be working hard to build cohesive encryption plans. Not so, according to a recent Ponemon Institute study, which found that though 66 percent of 768 U.S. IT pros surveyed have some encryption strategy, only 16 percent are taking an enterprisewide approach.

That's partly because encryption drivers are diverse, from government and industry regulations, to contractual obligations, to auditor demands, to internal policies that too often cast a cynical eye toward the safe-harbor provisions written into mandatory disclosure laws. What should not be diverse, however, is your strategy for managing encryption keys. Key management is important not just because compliance officers want to know how keys are generated, stored and destroyed, but because data may be irretrievably lost if keys are mishandled. The need for a centralized key-management strategy will grow in importance as a company's encryption needs increase.Let's examine the problem from the bottom up.

Drivers for encryption fall into three general buckets: intangibles, laws and standards. Intangibles include maintaining a good brand reputation and honoring privacy policies and customer trust. Just 7 percent of respondents to the Ponemon study cited ensuring that privacy commitments are honored as a top reason to encrypt sensitive or confidential data. Self-preservation in the form of protecting brand or reputation fared better, at 40 percent.

Laws--especially mandated disclosure laws--intersect with intangibles. In the almost four years since California enacted Senate Bill No. 1386, 30 additional states have pushed through similar legislation stating that organizations must notify residents whose unencrypted personal information may have been disclosed as a result of a security breach ... emphasis on the loophole. Federal regulations like Gramm-Leach-Bliley, HIPAA and Sarbanes-Oxley are perceived as recommending or requiring encryption.

Security vendors don't hesitate to use these regs, along with e-discovery scare tactics, to sell product; we discuss these drivers further in "Prescription for Encryption," below. But one mandate that few can afford to be noncompliant with is the Payment Card Industry Data Security Standard. PCI DSS is set by the PCI Security Standards Council, which represents American Express, Discover, MasterCard, Visa and international credit issuer JCB.

PCI DSS 1.1, which became the standard for all credit-card processors on Jan. 1, mandates encryption before cardholder data is transmitted across public networks. Details go beyond that one broad imperative--the standard is explicit and covers many other situations where encryption may be required to limit data access.Key-handling requirements in PCI DSS are extensive as well: Key custodians and locations must be limited. All key-management processes must be documented and include generating strong keys as well as securely storing, transmitting, destroying, aging and revoking keys.

Why is it, then, that most stats we've seen on encryption don't seem to mesh with the number of organizations that handle credit-card transactions? Is the amount of encryption being under-reported? Our guess: Security pros are running into the biggest problem with the encryption market: too many solutions, too few standards.

Showstoppers

At this year's RSA conference, it was obvious that encryption is a growth industry. Of the 381 vendors exhibiting, one in five focused on data encryption or key management. That's a high percentage given the sheer number of categories represented. We saw companies exhibiting encryption for data at rest on tapes and hard drives, for data in motion with all flavors of VPNs, and for automatic transparent encryption as data travels through the network. Even the keynote from Microsoft's Bill Gates and Craig Mundie highlighted how IPsec can encrypt data automatically as it travels among network devices.

Let's look for a moment at how all these solutions work together--or don't, as the case may be.As we increase the amount of encryption occurring on our infrastructures and have keys deployed pervasively on multiple applications, the current model of letting each app manage its own keys becomes untenable. Sure, smaller organizations with relatively modest encryption needs will be able to juggle a few independent encryption silos, but for how long? Encryption requirements certainly aren't going away.

As far as cross-platform capabilities go, in the absence of an open key-management interface, switches, storage systems and tape drives that use encryption keys can cooperate only by publishing their key-management APIs for third-party use. No vendor presently provides a purpose-built key manager that can support the wide range of systems used for encrypting data in flight for network, disk and database applications, as well as data at rest on tape or disk.

Currently, most key-management vendors are emphasizing data at rest, because this represents one of IT's greatest challenges. Tape and backup applications require that a huge number of keys be generated, then securely maintained for decades. Keys may also be needed at remote locations to make data accessible for disaster recovery or e-discovery.

It's All About The Policies

Besides consolidating management overhead of multiple independent systems, the biggest indicator for EKM success is consistent policy application. Microsoft demonstrates a potential solution for this problem in its Windows Rights Management Services for Windows Server 2003. Of course, Windows RMS works only in homogeneous Microsoft environments; see "Going the All Microsoft Route" page 45. But for our purposes, it's the principle behind RMS that's important: Microsoft says RMS "augments an organization's security strategy by protecting information through persistent usage policies that remain with the information, no matter where the information goes."The magic word there? Policies.

The key to encryption (pun intended) is to protect access to data. It doesn't make sense to allow different people access to the same data based on its location. Why should network engineers have access to keys when data is traversing the VPN, the mail-server administrators have access while data is encrypted in the mail server, and the user have access when it's encrypted on his laptop?

The security industry is pushing policy compliance and policy-driven security hard--NAC demonstrates this trend--and products that follow directly from corporate policies are needed for data encryption too. Data security standards must be written first, and then we need security mechanisms to implement consistent protection measures based on those standards, no matter where the data resides.

Unfortunately, that's impossible with a silo approach, where every product or piece of the network has its own encryption mechanisms.

So What's The Solution?We want EKM products that can speak to encryption devices and software from different vendors and manage all our keys. Key management would be a tough enough nut to crack with one über suite, never mind integrating dozens of products of different types.

To be effective, an EKM suite must at a minimum address this wish list:

And those are the easy problems. Once they're solved, there are still tough issues to address, like how to turn human-language data-security standards into technical policies for each encryption mechanism. A product must be aware of not just where each device is and how to manage its keys, but how to configure a device with an appropriate policy for the data it will handle.

One big impediment to this ideal EKM reality is a lack of interface standards. Sure, there are many standards for proper implementation of encryption, for example, FIPS 140-2, and even for how keys can be encapsulated for transmission, like RFC3852. But there are no standards for how such a proposed EKM device could speak to multiple encryption products without learning APIs for each vendor's platform.

Public-Key Cryptography Standards 11 (PKCS#11) seems like a near-solution; it specifies an API called "Cryptoki," pronounced "Crypto-key" and meant for doing key management on devices that hold keys or perform cryptographic operations. PKCS#11 was built specifically to allow for enterprise management of cryptographic tokens, but it doesn't solve the whole problem. First, it's not a network API, and it requires higher-level wrappers to be made available over the network. Yes, there are ways of doing that, but none is based on a standard that ensures interoperability among different implementations.Additionally, PKCS#11 may not address the entire range of mechanisms and keys needed for complete EKM. Key management interoperability on an enterprise scale is not a problem PKCS#11 was meant to solve.

Microsoft's CAPI (CryptoAPI) is another potential piece of the puzzle in that it lets Windows apps be developed for a standard cryptographic interface and have their underlying mechanisms modified by modules. These modules let Windows apps integrate their key management into an EKM platform, but using CAPI solves the problem for Windows-based applications only, and it requires that a piece of the management application be installed on each end point that will use cryptographic features, making for a potentially onerous deployment scenario.

PKI (Public Key Infrastructure) initiatives deal with many issues core to EKM. Indeed, PKI seeks to solve key handling for many current forms of encryption that are identity-based, including secure e-mail and instant messaging, user authentication, and some forms of document rights management. However, PKI technologies aren't built to handle encryption keys not tied to a particular user, as in the case of tape backups, for example.

Almost, But Not Quite

Despite a lack of standards to unite different approaches to key management, several vendors provide tantalizing glimpses of what EKM needs to look like. NeoScale's CryptoStor KeyVault, nCipher's keyAuthority Solution Suite and RSA's Key Manager are all good starts, but they suffer from a lack of a unified industry-standard key-management interface, and none can be dropped into an existing enterprise environment and easily begin managing all the different applications currently doing encryption.And without an industry-accepted standard--or considerable customer pressure--point-solution encryption vendors have little motivation to change this reality. Key-management products will remain limited to one vendor's products or will demand major institutional efforts to integrate into existing encryption products.

For now, an enterprise could purchase one of the products we discuss in nwc.com/go/0430review and put pressure on its encryption vendors to integrate. Alternately, there are APIs for use with nCipher's and RSA's products for companies that want to develop their own encryption managers. The one universal truth is that, even without a complete solution, enterprises cannot wait until they have too many secrets and too many keys to keep track of. Start planning now so you'll be ready when standards finally arrive. n

Good Crypto, Bad Crypto

One of the great scenes from the movie "Sneakers" unfolds as the security consultants are split into two groups, one playing Scrabble and the other hacking on a faux answering machine they'd been coerced into "recovering." The only thing known about the black box is the code name, "Setec Astronomy." As the Scrabble players realize the code name is an anagram and not an acronym, the hackers begin to probe the special chip hidden in the device, eventually discovering an algorithm able to crack any encryption scheme. Suddenly, the true code name is spelled out on the Scrabble table: "too many secrets."

Quantum computers have a long way to go before they can process enough bits to divine modern cryptography keys, so the likelihood of our encryption suddenly unraveling remains comfortingly small. But the number of secrets we're encrypting is indeed growing at a tremendous rate, and choosing a crypto scheme can be tricky. "Good Crypto" and "Bad Crypto" sometimes look the same, but don't be fooled ... you definitely don't want Bad Crypto guarding your secrets. Here are some tips to help you tell the good from the bad.

Going The All-microsoft Route

With many technology problems, if you implement only related applications from a single vendor, the number of headaches you're likely to run into drastically decreases. Although this isn't always feasible for political, technical or other reasons, going whole hog with Microsoft can meet your enterprise encryption needs.

The cornerstone behind Microsoft's encryption architecture is Active Directory--not surprising since AD is the foundation for nearly all Microsoft enterprise applications. Using Group Policy, all endpoints can have IPsec profiles remotely mandated, resulting in end-to-end encryption throughout all domain clients and servers, or only where needed, as specified.

To address the threat of lost laptops containing sensitive information, Microsoft developed BitLocker Drive Encryption--though it's misnamed as it's really for volume encryption. New for Vista (Enterprise and Ultimate) and Longhorn, BitLocker can operate with or without an extra boot password or hardware token, though it does require a hardware token if operating without a TPM (Trusted Platform Module) chip. Older TPM 1.1 chips will not work, and TPM 1.2 has been shipping in laptops for only about a year.

EFS (Encrypting File System) has been built into NTFS since Windows 2000, but it operates only above and in conjunction with the existing NTFS file system and cannot be used to encrypt entire drives, or otherwise protect system integrity during boot-up. BitLocker, on the other hand, was specifically developed with the idea of using encryption as an easy and efficient (in terms of user interaction) method of authenticating the system as it boots.One priority for Microsoft when developing BitLocker was to minimize its impact, both to the hardware and the user. Thus, when run in its default mode, BitLocker allows the drive to remain encrypted and secure against the most common offline attacks, with no extra steps for the user.

This mechanism could still fall victim to attackers if they subvert the BitLocker process after the key has been extracted from the TPM, though that threat is minimal. Still, for high-risk environments, BitLocker should be configured to require a PIN or special USB key as a part of the boot process. Default key length and other encryption options can also be adjusted in response to more stringent requirements.

Another important feature in BitLocker is the ability to have drive keys escrowed using Active Directory, similar to the way EFS-encrypted content can have a data recovery agent specified. Escrow allows a hard drive, encrypted file or volume to be moved from one laptop to another--for example, in the case of a motherboard failure--and allow recovery of encrypted data.

Microsoft's Rights Management Services for Windows 2003 was developed to help enterprises address the digital rights management problem. With RMS, access to documents can be restricted to a certain subset of users, even a subset of behaviors--read-only, for example, but no printing. Of course, sharing documents with other organizations requires that you establish trust between your respective RMS systems, use Microsoft .Net Passport services for recipients within an RMS-enabled infrastructure, or forego protection.

Microsoft's full lineup of enterprise encryption and key management products is huge: From Exchange 2003 now fully supporting S/MIME for e-mail security, to Windows Server 2003 Certificate Authority to create and manage the key infrastructure, to the Microsoft Office Live Communications Server 2005 for encrypted IM communications, it's hard to find a single aspect of communication and data storage that can't be encrypted, seamlessly and automatically, if you're willing to go with Microsoft end-to-end. Prescription For Encryption Do regulations like GLBA And SOX really mandate encryption? Get 20 lawyers and auditors in a room and you'll get 30 heavily conditional opinions, but here's our take.

GLBA may not explicitly mention encryption, but it does state that financial institutions have an obligation to protect the "security and confidentiality of ... nonpublic personal information." HIPAA likewise doesn't directly describe appropriate forms of encryption, but rather directs the Secretary of Health and Human Services to create specific guidelines to cover electronic health records. It does, however, specify that everyone who maintains or transmits health information must safeguard the data against, among other threats, "unauthorized uses or disclosures of the information." Certainly, good access controls and encryption would be the primary tools in following that directive.

SOX, on the face of it, doesn't relate to information technology. Originally written to mandate best practices in corporate business and accounting after markets were shaken by the Enron and WorldCom scandals, SOX does specify that IT controls must be in place on systems that are used in the process of submitting financial data by some large organizations.

The twist in the midst of all these regulations requiring data be protected from accidental disclosure is the directive that companies be able to gather and disclose data, fast, when directed to by the courts.

The Federal Rules of Civil Procedure, set by the Supreme Court and approved by Congress to govern how federal civil cases should proceed, were updated in December 2006 to include e-discovery provisions that seem to mandate a guilty-unless-you-produce-the-evidence scenario. Because digital evidence is so easily manipulated, lost and expunged, under the new procedures, losing keys to encrypted content would be a quick way to run afoul of the law.See our Policy Workbook on E-Discovery, for more information on how to be prepared.

Jordan Wiens is an NWC contributing technology editor and a network security engineer at the University of Florida, where he works on IDS/IPS, vulnerability assessment and system security. Write to him at [email protected].

Steven Hill is an NWC technology editor. Write to him at [email protected].