RISK MANAGEMENT STRATEGIES
The ins and outs of database encryption
Rich Mogull, Contributor
04.15.2008
Rating: -3.62- (out of 5)
|
This tip is part of the SearchSecurity.com Data Protection Security School lesson, Database defenses for a new era of threats. Visit the school and lesson pages for additional learning resources.
There are few tasks in the practice of information security as daunting as encrypting an enterprise database. Aside from managing potential compatibility, reliability and performance requirements, security pros face a myriad of encryption options, key management pitfalls, and application integration requirements. Database encryption should never be taken lightly, but a little knowledge and planning will go a long way toward ensuring a successful project.
The first step in any encryption project is to determine what data to protect, and whom to protect it from. You'd be surprised at how many clients I've worked with who tried to skip this step and jump right into deploying technology. Before technology comes into play, questions must be answered, such as:
There are really only two use cases for encryption, each of which will directly determine the organization's architectural options.
Encryption for media protection
The first case is encryption for media protection. In this case, the entire database is likely being encrypted and the goal is to protect the database files or content from physical or virtual theft. The concern is that someone might steal the database files or the media they're stored on. This is the right choice if you're worried about someone hacking the server and stealing the database files, or losing them when you swap out hard drives. Although it is possible to protect the database from system administrators or other users with access to where it's stored, that won't prevent database administrators or users (or anyone who hacks their accounts) from accessing the data.
Media encryption is fairly straightforward and there are a number of good product and technology options available. Since the encryption
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
is outside of the database, it's less likely to affect performance and won't require any database or application changes. Some database management systems include this kind of encryption as an option, allowing encryption at the table or entire database level. Alternatively, it's possible to use nearly any high-performance file- and folder-encryption tool. In both of those cases, the cryptographic operations happen on the server, and if this adversely affects performance beyond acceptable limits, consider an inline encryption appliance with dedicated hardware to speed things up.
Encryption and separation of duties
The second organizational use case is encryption for separation of duties. This is the best choice if your enterprise needs to encrypt credit card numbers within a database to keep them from the eyes of administrators, and other similar circumstances. Encrypting for separation of duties is far more complex than encrypting for media protection; it involves protecting data from legitimate database users, requiring more changes to the database itself. In nearly every case, this means encrypting at the column level. If the column is an isolated field that isn't a primary or foreign key, doesn't rely on it's structure for indexing performance, and isn't subject to range searches, it's a good candidate for encryption. If not, it can still be encrypted, but major database and application changes will be required.
The process of designing a new database for column encryption is a straightforward one, since you can plan as you build. Alternatively, for a complex legacy system with heavy application dependencies requiring encryption of a primary key, the project could take 2-3 years. The duration of most encryption projects falls in the middle, and the difficulty is determined by key relationships, indexing and any necessary application changes.
Database encryption recommendations
All major database management systems offer column-level encryption, but none support pulling the keys out of the database by default. My recommendation is to use native encryption capabilities wherever possible, but use third-party key management products to get the keys out of the database. This strategy enables a security administrator, not the database administrator, to manage the keys to support separation of duties. No matter what anyone tells you, never try to encrypt a primary key. Finally, make sure you're really getting the benefits you expect -- database encryption does nothing to protect against SQL injection or a compromised account with access to the field.
In terms of field encryption, my advice is to avoid it on existing databases if at all possible, but to build it into new systems with sensitive data. For example, some of my large enterprise clients are building a secure central repository with encrypted credit card numbers for transactions while pulling them out of existing systems. If there is a need for separation of duties in an existing system, consider encryption for media protection and then adding another database security technology -- like database activity monitoring -- for separation of duties.
About the author:
Rich Mogull has more than 17 years experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, Rich spent seven years at well-known research firm Gartner Inc, most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies and has covered issues ranging from vulnerabilities and threats, to risk management frameworks, to major application security.
|
|
Rate this Tip
|
To rate tips, you must be a member of SearchSecurity.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.
|
|
|
|
|
|
|
