Database application security: Balancing encryption, access control

This tip is part of SearchSecurity.com's Data Protection School lesson, Locking down database applications. For more learning resources, visit either the lesson page or the Data Protection School main page.

Some of the most sensitive data in a company is stored in databases. Medical records, credit card numbers, employee records, Social Security numbers and other such data are subject to privacy regulations and must be protected.

At the same time, however, security must be balanced with the need to access the data for legitimate business use, including backups and remote replication for business continuity. The most powerful tool for data privacy is encryption, but it must be applied carefully in order to be effective for security and not disruptive to business. Here are some best practices for database application security when it comes to protecting sensitive data and establishing an encryption/access control balance:

Data minimization and obfuscation
The best and most effective way to protect sensitive data is to not store it in the first place. Thus, companies should always ask the following data minimization questions:

Will the data be needed beyond today?Can we store only partial data for verification (e.g., last four digits of SSNs)?Can we use other, less sensitive data for authentication (e.g., name of pet)?Can we use or store a hash instead of the original data (e.g., MD5, SHA)?

In many cases, these questions can lead to a smaller, less sensitive set of stored data.

Data encryption
Companies can encrypt database data to protect against theft or accidental disclosure. There are three key issues that come with database encryption: where the data is encrypted, how it is encrypted and where the keys are stored. Let's address each below:

Where to encrypt data -- Encryption can be applied at the application layer, in the database or in the underlying storage. Within the database, data can be encrypted in a specific field, a column, a table or across the entire database. Each of these choices has pros and cons.

Application-layer encryption ensures the data is encrypted at the highest layer in the system, thus making it invisible to all the layers below. If encrypted in the application, the database, OS, network and all other components through which the data passes will only see the encrypted form.

The problem with encrypting at the highest level is that there are usually several high-level applications that need access to the data and will therefore need copies of the keys to decrypt it. The more the keys are distributed, the more vulnerable they are.

But if you encrypt at the lower levels, then you need to add other layers of encryption further up; for example, data will need to be encrypted in the network flows between database and application, otherwise it will be visible. This introduces other encryption keys that will need to be secured. It's a delicate balance that depends on the architecture of the application and the data flows.

How to encrypt -- Encryption can be implemented in software, in software with hardware assistance or entirely in hardware. Depending on the throughput you are trying to support (Mbit/sec), you may need some hardware acceleration. One choice is clear though: Always use a modern, strong and standards-based encryption and key management system; don't try to invent your own system that may or may not do the job properly. Some high-end server processors now have built-in encryption primitives supporting AES, which allow for much faster (up to nine times faster) encryption than software-based algorithms.

Where to store the keys -- The biggest challenge is not encryption per se, but key storage and distribution. The encryption is only as secure and only as accessible as the keys. Keys must be protected from attackers and stored separately from the encrypted data, but accessible to the encryption/decryption algorithm. At the same time, the keys must be backed up and replicated, so that backup data can also be decrypted if the primary data or primary key storage is lost due to a disaster. Any key management technology you select must support:

Secure storage of keys.Authenticated and audit-trail access of keys.Escrow or recovery keys to protect against loss.The ability to backup and securely transfer keys to a remote location for recovery.

Encryption standards
Many encryption and key management systems are certified by one of two useful standards: Federal Information Processing Standard (FIPS) 140, levels 1 through 4, and Common Criteria Evaluation Assurance Level (EAL), levels 1 through 7. These standards offer a metric to compare the security of different systems' encryption algorithms, key storage and key management mechanisms: Higher numbers mean better encryption algorithms, better key storage, tamperproof hardware and better key management practices. For example, FIPS considers 11 different areas of security to assign a level of certification. You should pick the appropriate level of security depending on the sensitivity of the data and any regulatory requirements you face.

Database applications are complex and made of multiple tiers of loosely coupled components. They are difficult to secure, yet contain the most sensitive data in an organization. But by using data minimization and encryption, companies can strike the right balance between security, accessibility and availability for their data.

About the author:
Andreas M. Antonopoulos is a Senior Vice President and Founding Partner with Nemertes Research, where he develops and manages research projects, conducts strategic seminars and advises key clients. Andreas is a computer scientist, a master of data communications and distributed systems, a Certified Information Systems Security Professional (CISSP), with an engineering, programming and consulting background. For the past 16 years, has advised a range of global industries on emerging technologies and trends.

View the original article here