Encryption no longer an optional technology

Unravel the ins and outs of how your organization should deploy encryption.

For many years, encryption was something companies could choose to use if they wanted an extra degree of security for their data. However, the days of optional encryption are gone forever. Today, companies in a variety of industries are subject to regulations that mandate encryption and other security measures, and face stiff penalties for failure to adequately protect their data. Even if a company is not subject to these types of regulations, many states have laws requiring companies to disclose security breaches in which unencrypted customer data has been compromised.

Consequently, it is no longer a question of whether a company should use encryption, but rather how a company should encrypt data. The first step in planning an encryption strategy is to understand the primary types of available encryption solutions: storage, network encryption and application-level. While each offers benefits, there are also drawbacks to take into account.

				compliance
				Details PCI is far more prescriptive than HIPAA when it comes to encryption. by Marcia Savage What do regulations such as HIPAA actually require in terms of encryption? The HIPAA Security Rule lists encryption as an "addressable" technical safeguard, which means it's not mandatory but must be addressed. "Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate," the rule reads. Like many regulations, HIPAA is intended as guidance rather than mandates, says Richard Mackey, vice president of consulting at SystemExperts. Ultimately, a risk analysis is required to determine the specific security measures a business should implement. "You're supposed to conduct a risk analysis to figure out the real risks, the likelihood of an attack, and what methods would be effective in protecting against those attacks," he says. Far more prescriptive is the Payment Card Industry Data Security Standard, which provides specific direction on encryption. Requirement 3.4 lists four ways organizations can make the Primary Account Number (PAN) unreadable wherever it is stored: strong, one-way hash functions; truncation; index tokens and pads; and strong cryptography with associated key management processes. Then, there are the state laws (at least 44) requiring notification of breaches involving personal information, many of which make exemptions for encrypted data.

STORAGE ENCRYPTION
Storage encryption is simply a mechanism that encrypts files stored on a hard drive or other media such as backup tapes. This type of encryption is used primarily as a contingency against a physical security breach such as a stolen laptop containing sensitive data. In such a situation, the Windows operating system will provide at least some protection. Assuming that the hard drive is using the NTFS file system and the appropriate file system permissions are being used, the thief shouldn't be able to access the user's data unless he knows the user's password.

However, a computer savvy thief could use one of the many utilities available to reset the local administrator's password as a means of getting access to the data, or he could just remove the hard drive, install it into another computer, and bypass Windows altogether. Unless the data on the drive is encrypted, both of these methods will allow the thief to quickly access the user's data.

Storage-level encryption is designed to protect data in these types of situations, but some encryption technologies work better than others. For example, the Windows Encrypting File System (EFS) can encrypt a volume containing data, but it cannot encrypt the system volume--the disk volume that contains the hardware-specific files needed to start Windows. This means EFS encrypted data can only remain protected if physical security is guaranteed.

If a computer is stolen, EFS encryption will prevent data from being compromised if an encrypted hard drive is removed and then installed into another machine. However, since the system volume is un-protected there is nothing stopping a thief from using a utility to reset the administrative password, booting Windows, logging in with the new password and gaining access to the data.

Windows Vista and Windows Server 2008 solve this problem by offering BitLocker, which uses the Trusted Platform Module (TPM) to encrypt the system volume. Since this is a BIOS-level encryption mechanism, it will protect against password reset attacks (assuming that the system volume is encrypted).

If you are considering using storage-level encryption, it is important to carefully plan for key management and to have a mechanism in place for key recovery. Encryption key loss is an extremely common problem. When the key is lost, the encrypted data becomes unreadable unless a backup key is available. The result is permanent data loss.

Most third-party storage encryption products on the market work similarly to EFS but offer better manageability. One important difference between EFS and some of the other products (besides the varying encryption algorithms they use) is how they store the encryption keys.

Windows stores the EFS encryption keys on the system drive, which can lead to a couple of problematic situations. First, if the system drive fails, the encryption keys are lost, which results in permanent data loss unless a backup key is available (Windows workstations that are a part of a domain always designate the domain administrator as a key recovery agent). Second, if a laptop is stolen, a skilled hacker may be able to extract the encryption keys from the system drive and use them to unlock the encrypted data. Many third-party encryption products protect against this by storing the encryption keys on USB flash drives or on network servers.

NETWORK ENCRYPTION
Encryption at the storage-level does a good job of protecting files residing on storage media, but it does nothing to protect data in transit. Data flowing across a network or the Internet is unprotected unless the session is encrypted. A hacker can easily use a packet sniffer to capture a copy of individual packets as they flow across the network, a technique used in recent high-profile credit card thefts from retailers. These packets can then be reassembled and the data within them extracted. At one time this was considered a fairly advanced type of attack. Today, though, utilities exist that take all the work out of a network sniffing attack. Even an unskilled hacker can use such a utility to steal data.

There are countless mechanisms available for protecting data as it flows across a network. Windows Server provides IPSec encryption. Mobile users accessing a Windows network through a Windows-based VPN can be protected by PPTP, L2TP or SSL encryption. Of course, these are just software-based encryption solutions native to Windows. There are also third-party encryption solutions that work at the hardware and software level.

There are two major drawbacks to encrypting network traffic. First, network encryption has traditionally been difficult to implement. For example, using IPSec encryption usually requires an organization to install an enterprise certificate authority. An administrator will also have to understand the key management process, and know how to set group policies that require network computers to use IPSec encryption. Additionally, IPSec encryption will fail unless network clients are using an operating system that supports IPSec.

The other major drawback to network traffic encryption is that it can degrade performance. Every time a client needs to communicate over the network, the client must establish a session and encrypt the data that is to be transmitted. The recipient must then decrypt the data. This process increases the amount of traffic flowing across the network, and forces network client machines to spend additional time and CPU resources encrypting and decrypting data.

Network cards exist that can offload the encryption and decryption process from the CPU. This doesn't decrease the traffic flowing across the network, but it prevents network clients from suffering from decreased performance.

APPLICATION-LEVEL ENCRYPTION
Application-level encryption is essentially a hybrid method. The basic idea is that the developers assume that their application will be used in an insecure environment, and therefore build proprietary encryption capabilities into it.

Many products on the market include application-level encryption capabilities. Some of the best known are file compression utilities such as WinZip, which allows a user to create an encrypted archive file. This file remains encrypted whether or not it is stored on a hard drive that has encryption enabled. Likewise, the file remains encrypted even if transmitted across the Internet using a non-encrypted session. This is because the encryption algorithm is applied directly to the data within the file and is independent of the storage medium or network connection being used.

Application-level encryption works well for augmenting your existing security but tends to be difficult to manage. Every application with built-in encryption capabilities works differently, but generally most require the user who creates a file to enter a password to access the file. This password is treated as an encryption key. The problem is that there is usually no way to centrally manage these passwords. If a user forgets the password they assigned to a file, the user loses access to the data in the file.

Furthermore, many encryption-enabled applications are not multi-user aware. This means that a user who wants to share a file with another user typically must also share the password to access the file.

Whatever solution you choose needs to be "end user proof." In most cases, applications that offer built-in encryption capabilities require users to choose to encrypt the data. Given a choice, they will often take the easy way out and not encrypt.

RIGHTS MANAGEMENT
Rights management is a more advanced form of application-level encryption that's starting to gain popularity. Rights management is a technology that allows permissions to be assigned to an encrypted file. For example, such a policy might prevent users from copying data out of the file or from printing a protected document.

The nice thing about rights management is that permissions are typically linked to a backend server. This means that if a user were to copy a rights managed file onto removable media and then leave the company, the administrator could prevent the data in that file from being accessed by the former employee by simply removing the rights.

Windows natively supports rights management, but third-party products offer similar capabilities. For the most part, rights management works very well, but the initial setup can be complicated, depending on the product. Also, depending on how rights management is set up, mobile users may not be able to open rights managed documents unless they have connectivity to the company's rights management server. Another potential downside is that not all types of data can be rights managed. On the upside, rights management does solve the management headaches typically associated with application-level encryption.

				Marketplace
				CLICK HERE for a guide to Marketplace tools (PDF).

HOW TO CHOOSE
With so many types of encryption available, it can be tough for a company to figure out which one is best suited to its needs. The first step is to determine whether your organization is subject to any federal or industry regulations that mandate how data is to be secured. If so, these regulations often provide guidance on the types of encryption solutions that must be used.

Most organizations will want to take a layered approach. When it comes to encryption, the general rule is that data needs to be protected at rest and in motion. If data is only encrypted at the storage level, or only while in transit, then the data is not fully protected against potential exposure. Although application-level encryption fulfills both of these criteria, it should be used only to augment your network's security, not as the sole encryption method. The reason is that not every application offers built-in encryption, and those that do have varying encryption strengths.

If a company is not subject to regulations requiring encryption, it's critical to consider the total cost and staff requirements associated with deploying and maintaining the technology. Encryption can cost a significant amount in terms of hardware, software and support, and it is important to make sure the benefits justify the expenditures.

Whatever encryption solution a company chooses, it should be transparent to end users and compatible with your network infrastructure. Some encryption solutions cause complications with backing up data or with accessing or encrypting data stored on a SAN. Make sure the solutions you are considering will not cause a significant administrative burden once the initial setup is complete.

While encryption definitely has its place in an enterprise security strategy, a company can't rely on encryption to solve its security problems. Most security experts agree that there is no such thing as a full-proof security solution. Any security mechanism can be circumvented with enough time and effort, including strong encryption. The key to good security is to make a breach more trouble than it's worth. This is best achieved by taking a layered approach to security that involves comprehensive policies and multiple technologies.

asdfghjkl

asdfghjkl
asdfghjkl

				asdfghjkl
				asdfghjkl asdfghjkl? asdfghjkl --asdfghjkl