Look before leaping into database 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 o

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Data Protection Essentials By addressing data privacy, companies avoid public scrutiny Lessons learned: The LendingTree case Lessons learned: The Countrywide Financial breach The Societe Generale fraud story: Keith White on fraud Institutionalizing risk management for ongoing management support Risk assessments: Internal vs. external Putting risk analysis into words Lessons learned: The Texas Insurance Claims Services case Lessons learned: The Montgomery Ward breach Lessons learned: The Citibank ATM breach Data encryption techniques Download presentations from Financial Information Security Decisions 2009 Data encryption: Pre-implementation best practices Data encryption: Lessons learned from implementation Data encryption: Q&A with Eric Leighninger Community banks to increase security spending, survey finds Lessons learned: The State Street Corp. breach Removable media encryption adds extra layer to laptop security Key management challenges and best practices Using full disk encryption in the battle against laptop data theft Laptop encryption options

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

f 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:

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.

Rate this Tip To rate tips, you must be a member of SearchFinancialSecurity.com. Register now to start rating these tips. Log in if you are already a member. DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.