Ulf Mattsson, Protegrity Corporation: Look before selecting a database encryption solution
October 2008 by
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. 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.
Database encryption can be put into two broad categories: communication encryption and data at rest (field, table) 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, unless internal threats need to be addressed.
Field encryption is another ballgame entirely. 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 how search operations are performed on encrypted fields. Database size, encryption type and element size is usually not relevant. You may encrypt of foreign keys but be careful when encrypting indexed fields (could cause usage and performance issues).
Use symmetric over asymmetric cryptography when available (again, for performance). Full database encryption is advised and an feasible option when database schema changes are not an option. Security best practices would teach you to encrypt each data field with a different key. This will not impact the performance hit.
Encrypt only sensitive data columns. This is typically all that is required or recommended by regulations and, after all, is what needs protection. Determining fields to encrypt should not be a daunting task if driven by compliance and threat mitigation. Several regulations comes right out and states specific columns that must be encrypted. 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 encrypt each sensitive data field at the point of acquisition instead of encrypting 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 may be adequate. However, if you are storing personally identifiable customer information or the company confidential information, choose strong encryption with a larger key space, such as AES 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 and IBM have added more robust encryption capabilities but limited level of separation of duties and no enterprise level key management. Microsoft’s SQL Server 2005 was a long-awaited answer to many of the features built within Oracle since 2000, with a basic crypto library. Third-party vendors, such as nCipher Corp., and Protegrity Corp. offer both hardware and 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. Additional monitoring and blocking of suspect data access patterns can solve additional database security concerns.