"Encryption is the ultimate protection mechanism, because even if someone …. gains access … they will not be able to read the data without further breaking the encryption."
Is this quote from the Payment Card Industry (PCI) Data Security Standard enough to make your company leap into database encryption with both feet?
Encryption is a powerful security tool, and nearly every compliance standard or industry regulation addresses data security in some manner, often at least implying a role for encryption. For instance, the Gramm-Leach-Bliley Act (GLBA) requires organizations must "insure the security and confidentiality of customer records and information," and California's SB 1386 breach-notification law states that any breach of the security of unencrypted personal information must be disclosed.
But before you make the leap, there are some fundamental considerations. Database encryption can be put into two broad categories: communication encryption and field encryption.
Communication encryption is commonly achieved through the implementation of tunneling protocols such as SSL or IPsec, wrapping the transmission of data from the server to any client applications or the processing server. Communications encryption is essential for two-tier applications that interface directly with the database server, since the requesting clients may be anywhere. This isn't necessarily the case for three-tier applications, where there is a middle layer on a server that interfaces with the database and passes results on to the clients. In this situation, (most common in Web-based applications), it is often not necessary to have encrypted communication between the database and the Web server, as it's assumed that link is trusted.
Field encryption is another ballgame entirely. Companies often jump into database encryption as a quick fix for compliance without considering several key factors. The greatest among these factors is the speed or performance of the application, because poorly implemented database encryption could impact production applications. Your customers won't be happy, and neither will the CIO. That's too high a price to pay for compliance and data security.
Various database optimization methods could help counterbalance the performance hit that encryption imposes, but these alone will not do the trick. These methods include leveraging stored procedures and consistent indexing. Diving deeper, the specific performance degradation due to encryption is fully dependant on a few crucial elements: database size, encryption type and element size.
Here are some simple guidelines that will help you secure your database without impeding the business you're trying to protect:
- Never encrypt foreign or super keys (encrypted keys used for indexing could cause usage and performance issues).
- Use symmetric over asymmetric cryptography when available (again, for performance).
- Full database encryption is rarely advised or a feasible option. Security best practices would teach you to encrypt everything with multiple keys and differing algorithms. However, the significant performance hit you must selectively choose.
- Encrypt only sensitive data columns. This is typically all that is required or recommended by regulations and, after all, is what needs protection.
Determining key fields or data elements is a daunting task and should be driven by compliance and threat mitigation. Since no regulation comes right out and states "X" columns must be encrypted, it falls back on good judgment. Identifying your most sensitive data and all the places it may reside, from primary databases to backups, is one of the toughest parts of implementing encryption, which is why companies may attempt to solve the problem by deciding to simply, if misguidedly, "encrypt everything."
Choosing an appropriate encryption method also depends on your data. If it mainly consists of images and Web content, then a weaker algorithm -- such as DES or SSL -- may be adequate. However, if you are storing personally identifiable customer information or the company design for a nuclear disintegrator, choose strong encryption with a larger key space, such as AES, Blowfish or 3DES.
The choice of encryption products is improving, as database encryption has made significant strides in the past few years, and the market has continued to mature. Major database vendors, mainly Oracle Corp., Microsoft, and MySQL AB, have all added more robust encryption capabilities coupled with features to permit additional layers of role-based user access control. Oracle 10g, for example, permits granular AES encryption of database columns and features expanded PKI support. Microsoft's SQL Server 2005 was a long-awaited answer to many of the features built within Oracle since 2000, with an enhanced crypto library.
Third-party vendors, such as nCipher Corp., Protegrity Corp. and Application Security Inc., offer software database encryption products, while Ingrian Networks Inc. offers an appliance-based solution.
While compliance pressures have stoked keen interest in database encryption, it doesn't solve all database security concerns, which are at least as much about preventing abuse by privileged insiders as external attackers. There are no shortcuts. Hastily implementing database encryption simply to comply or assuming it alone will make your data secure will cost extra time, money, manpower and brain power better spent elsewhere.
About the author
James C. Foster has authored more than 20 books, including Buffer Overflow Attacks and Writing Security Tools and Exploits.
