The touch of a human finger to a keyboard begins a journey. A journey in which the data that is born of this minor action must navigate with caution; for there in wait are gremlins, goblins and pirates waiting to disrupt or prematurely terminate this journey. These agony-hounds have an expensive taste. The most valuable and sensitive data that traverse these highways and byways are the ones that they target the most.

In the attempt to guard the data as it passes through these perilous crossroads the user interface developer may advocate that the protection of the data should reside in the business layer or data layer of the application. The database developer may advocate that the database is the prime location to apply data protection. Others may recommend that a hybrid of these options provides the most secure environment. The process of making this decision can be confounding. Below are some thoughts that may help in this decision:

Not All Data is Created Equal
The use and classification of the data stored within the database significantly contributes to the implementation of security. A database that stores aggregated survey results on North America's cola preferences may require only the running of backup routines to guard against data loss. A database that contains a financial institution's customer and transaction data will require much greater and complex protection efforts.

The beginning of any data protection effort is data classification. This process will identify the data and databases that are most sensitive and worthy of additional efforts.

The danger of over-securing data is additional maintenance costs and an unnecessary reduction to the database performance. The danger of under-securing data includes data loss, regulatory violation fines, loss of competitive edge, loss of customer confidence, financial ruin for customers and of course loss of your job. Applying security is as much an art as it is a science.

Data in Action/Data at Rest
When data is in transit across a network or cached in memory for use it is said to be "in action". When the data is being stored in media for retention it is said to be "at rest". Other dimensions of "in action" and "at rest" include the frequency in which the data is updated.

The primary goal for implementing data protection at the database level is to protect "data at rest". Transparent Data Encryption (TDE) is a good example of a feature that is designed for that purpose. TDE encrypts the physical data files and transaction logs so that their contents are protected from prying eyes when it is stored on the database server and various backup media. TDE also protects the "data at rest" from becoming "data in action" on a server in which it was not intended by requiring the appropriate keys to be in place prior to recovery.

This does not mean that there should not be efforts made to protect "data in action" at the database level. An example of this would be Cell-Level Encryption. Any decryption that occurs at the database level is cached into memory prior to use. This presents a level of vulnerability if the cache is being sniffed for goodies by the bad guys. This also means that when the data is pushed out to the user interface it is traveling the network unprotected. The use of the HashBytes method does offer some level of avoidance of these specific vulnerabilities since its cipher text is never decrypted.

If One Is Good, Two Is Better
In our relentless pursuit of ultra-performance and efficiency we often fail to remember that redundancy is not necessarily a bad thing. The design of our own bodies utilize redundancy brilliantly: Two eyes, two ears, two lungs... and the list could go on. In the event that one of these items fail there is another that preserves the original functionality of the pair.

When it comes to protecting data, implementing a hybrid of methods improves security significantly. In this specific case the redundancy is not only a fail-safe measure, it introduces complexity. Not unlike that gag-gift that we all certainly have received at some point where a gift is wrapped in a series of boxes. The implementation of complex security methods increases the skill and knowledge level required to achieve disclosure which reduces access by the unauthorized.

When data is encrypted at the business or data layer of the user interface its cipher text travels the network to the database. Once received by the database it can further be encrypted. If the database cipher text is broken, the sensitive data remains protected because user interface encryption is still in place. The illustration below demonstrates this dynamic:

In God We Trust, All Others Pay Cash
This title of the classic book by Jean Shepherd says it all. The DBA cannot be sure that the sensitive data that is flowing to the database has been sufficiently protected. The role of the DBA is one of great responsibility. If sensitive data is compromised while it is in storage there is no doubt that the DBA will be the first questioned. Applying protection methods regardless of methods used in the user interface ensures that some level of protection exist.

The road that our data travels is indeed a formidable one. With these considerations in mind the process of implementing protection for these journeys will be more effective.