Government and industry mandates coupled with the fear of a data breach have made it more important than ever for financial organizations to protect their data. Encryption can go a long way toward protecting that data. However, a broad "encrypt everything" strategy is rarely an effective one, as there are database and storage performance penalties for encrypting too much data.
For that reason, determining what data to encrypt and where to keep it is a vital early step in the encryption deployment process.
Before getting started with products, work with your organization's legal counsel to determine what data will be protected and where the protection should be located. Will data be protected both "in motion" and "at rest," or just in the database itself? Will all data or just some data be protected? If you have a storage area network (SAN), encrypting data in flight may be the best decision. If you are using database software that has an encryption option, that might be the best decision. It's possible your storage array already supports encryption.
Next, specifically establish a database encryption strategy. Determine which fields and columns contain sensitive information in need of encryption and then create policies that encrypt the data as it is modified in or transmitted from the fields and column.
Encrypting only the fields that contain sensitive data is a wise best practice, as it will minimize the number of bytes encrypted and exact the smallest possible performance impact on your infrastructure.
When it's time to choose a technology, there are three distinct ways in which database encryption can be implemented:
- As software in or integrated with the database: Oracle Database 10g Release 2 Transparent Database Encryption is one of a number of products that promises to simplify encryption of sensitive personal information, such as credit card and Social Security numbers. Sybase's SQL Anywhere offers simple, Advanced Encryption Standard and RSA, as well as Federal Information Processing Standards encryption.
- Via hybrid software/hardware devices: IBM first built encryption into its mainframe computers in the 1980s when ATM and point-of-sale PIN processing required it. In 1991, IBM built crypto into the IBM S/370 mainframe and in 1997 it added the S/390 Cryptographic Coprocessor Facility, which was certified as Federal Information Processing Standard (FIPS) 140-1 Level 4 compliant.
- Through storage-level encryption tools: Storage-level encryption is the most commonly used encryption method. An appliance lets enterprises encrypt data on the storage subsystem, either on file-level network-attached storage devices or at the block-level on the SAN. This type of encryption, while well-suited to encrypting files, directories, storage blocks and tape media, is not as well suited for protecting databases. Storage-level encryption products can not encrypt single fields in the database; only the entire database itself. In doing this, database performance is significantly affected.
Both of these products allow partial data encryption of sensitive information. They also, like most encryption schemes, exact a performance tax.
There may be no perfect choice when it comes to an encryption product. For instance, a network-attached encryption appliance, including those from Ingrian Networks, Vormetric or nCipher, resides on the network, where it houses the encryption keys and executes all the cryptographic operations. When a user requests encrypted data, the appliance manages the retrieval of the data, authenticates the user to the system and decrypts the data. Because all data flows through it on the way to the storage media, system performance may be affected.
Disk space also an issue in database encryption, as encrypted data fields are larger than unencrypted fields. Encrypting only those fields that contain sensitive information may be the way to go, as the less data being encrypted, the smaller the performance task. Encrypting data with a separate appliance can also be a costly affair that adds administrative overhead to the network.
While broad, across-the-board encryption strategies are often burdensome and unnecessary, partial encryption of data on disk or of sensitive database fields, rows and columns may be a panacea for many financial institutions, where so much information needs to be protected and encrypted.
About the author:
Deni Connor is principal analyst for Storage Strategies Now, a research firm in Austin, Texas.
This was first published in March 2008