Encryption--three different ways.

The SunPen company has created a database to track all of their client's financial information. They created the database with little thought to security. SunPen customers were, originally, happy because the database worked quickly and they were able to view their financial information easily. Unfortunately, the SunPen database was hacked and all of their client's financial information was stolen. Far too late, the SunPen company realized how important database security is for a successful company.

Making your database secure is not an easy task. Threats to your data can come from many different sources; both internal and external factors that can have a negative impact on your data. Internally, you are at risk from users mismanaging specific files, databases, and applications. Even incomplete backups can damage your data. Externally, your data is at risk from malicious users who may use illegal applications to gain access to your data. The application-level attacks are the primary vulnerability of pure database security and database encryption because most systems do not contain that level of security.

For databases that need the highest level of protection, such as an Internet-based database application, specialized intrusion prevention tools and application firewalls to track and eliminate suspicious activities are available. You must protect the source data and the critical paths to your source data in order to ensure the safety of your data. Usually, this is done by encrypting critical data and using cryptography keys to cipher the encrypted data.

The major DBMS products on the market provide many of the key functions within the three major DBMS security categories: vulnerability assessment, intrusion detection and prevention, and security monitoring. However, the major DBMS products do not provide a segregation of administrative roles and security roles. Third party products can solve this issue and provide the needed secure encryption technology to protect confidential data and careful management of access to the cryptography keys that unlock the encrypted data.

The challenge is to balance security and performance by narrowly focusing protection on the critical information that needs to be secured, and having an awareness of how that information is used by various applications. Not all approaches to database security have comparable performance curves, but there are approaches that can minimise the impact. A solution that can balance the security, performance and scalability is the key to any enterprise-wide solution. Best practice is to also provide a centralised security policy and reporting across different systems.

There are three main types of encryption services available: Native, Local and Distributed encryption services. Each type of encryption service has its own operational aspects such as performance, manageability and scalability that must be taken into consideration. You have more options in how you want the encryption services to interact with your database.

Going native

Native database encryption solutions area form of local encryption services that accomplish the actual encryption and decryption functions on each database server. This solution does not separate administrator from security roles within enterprise solutions.

Network attached encryption devices accomplish the actual encryption and decryption processes by sending a request to the network attached cryptology device. The data must be protected during that transmission. Typically, this is done via a secure socket of SSL connection. Encrypted data is sent out over the network where it is acted upon by the network attached device. This network attached device adds only central security and encryption support and is not satisfactory, as the process would always penalise system performance and most likely open new vulnerabilities into the encrypted data. Network attached encryption services do not scale when adding additional database servers and the number of processors on these servers. Network attached encryption services also introduce a high volume of network traffic and a high dependency of network bandwidth and availability. Because dedicated encryption machines are separate from the database, productivity is slower than local machines as the information must pass from the database to the dedicated machine and back again.

Keeping it close

A local software solution resides on the same server as the database. Because the encryption service resides on the same server as the data to be encrypted, there is no loss of productivity due to sending the data from one machine to another. This solution is suitable in most situations and provides a cost-effective solution to meet regulatory requirements. This solution is scalable because you can attach additional low cost systems to increase the power of the encryption.

The distributed approach

A distributed Encryption service is a hybrid that relies on a software solution as well as a central key server with an optional hardware security module (HSM). The HSM is used when compliance with FIPS 140 level 3 is needed. This distributed encryption service offers effective load balancing and optimisation with lower network traffic and less dependency of network bandwidth and availability. The encryption load can be distributed over a large number of distributed standard processors, located centrally in relation to enterprise applications and data stores. Because of this, the distributed encryption service is easily scalable. The encryption key management operations can optionally utilise standard HSM units, attached to central or local encryption services, which can reside either on the machine bus or attached network. In some situations, an HSM is an ideal way to add additional protection for the most important element of any encryption solution--the encryption keys. Going back to our original example, SunPen seemed to be using only native database security functions. Had SunPen used a distributed encryption implementation, with a separated security policy that controlled the encryption process, the access to sensitive data, and encryption keys, the hacker may not have been able to access the client's bank account numbers. The hacker could even be blocked at the application level by an integrated application firewall before the injected database commands hit the database system.

Database security takes a lot of forethought. Whether to use native, central or a distributed encryption service will greatly affect how your database will be configured, combined, and integrated with application level firewalls. Remember, database security is incredibly important, and it is your job to balance security and productivity to offer the best product to your users.

Ulf Mattsson is chief technology officer with Protegrity having created the initial architecture of Protegrity's database security technology, for which the company owns several key patents.