In Depth

Protecting Data at Rest

New approaches to protecting data at rest (and avoiding the wrath of your customers).

By Simson Garfinkel

January 01, 2006 — CSO — Ever since California passed SB1386, organization after organization has disclosed that critical data banks have been compromised by hackers, couriers or consultants. The causes range from lost backup tapes to lost laptops to network hacks (you can read the sad litany in "The Five Most Shocking Things About the ChoicePoint Debacle"). What most of these cases have in common is the lack of strong technical measures to protect data that is by its nature highly sensitive.

From these and other cases we've learned that many companies seem to believe they can adequately protect their information with a combination of locked doors, firewalls and access controls. The problem with this approach is that attackers can frequently bypass such protective mechanisms and send raw commands written in the Structured Query Language directly to your database server. This is called an SQL injection attack. For example, if you have a table called "Customers," the attacker might be able to send through the SQL command "Select * from Customers," to dump your entire customer database as its reply.

Although there are numerous proposals for ending these kinds of attacksâ¬including fancy intrusion detection systems and governors that limit the amount of data that can be sent to a Web browser in response to an HTTP requestâ¬this column is about a variety of techniques that have been largely ignored but that show great promise.

All of the following approaches protect the data in the database against both outside attackers and malicious insiders. That's because these tactics work by either eliminating or scrambling sensitive information so that it no longer poses a security risk.

Option 1: Don't Collect Sensitive Data

The very best way to provide for the security of a database is to eliminate the large-scale collection of sensitive information in the first place. This is apparently less obvious than it should be. For example, many organizations still routinely collect Social Security numbers (SSNs)â¬or even worse, they use SSNs as their own employee or student identification numbers. Instead of using an identifier that has such a high potential for credit fraud and identity theft, it's far better for organizations to create their own randomly assigned 10- or 11-digit identification number. (And, indeed, any organization that deals with the public needs to have a provision for randomly generated numbers in any event, because not everybody has an SSN.)

Option 2: Get Rid of Sensitive Information Fast

For those who really must store sensitive data, make sure that the information is erased as soon as possible. For example, in many cases it is simply unnecessary to retain a customer's credit card number (CCN) after a transaction has been committedâ¬perhaps you can just keep the last four digits after 90 days. Those who need CCNs for auditing purposes may be able to move those numbers to a secondary database server not connected to the Internet.

• Email
• Print
• Comments
• Digg This
• SlashDot

• Confidential Data at Risk
• Five Evaluation Criteria for Data Loss Prevention Tools
• Dos and Don'ts for Data Loss Prevention