Doug Ross @ Journal

Protecting Data At Rest

Picture credit: http://www.unixwiz.net
Over at RedmondMag, Roberta Bragg notes some good starting points for protecting data at rest. Data 'at rest' means data stored statically on some media: hard disk, tape backup, etc. When sensitive data items -- like SSNs -- are stored in the clear, they're literally sitting ducks for hacking attempts.

Overall her point is, as mine was a few days ago, that data 'at rest' needs a comprehensive set of data protection standards. Roberta provides a good checklist that IT teams can use to vet their standards against best practices.

However, I believe she's omitted one quite crucial step in protecting data:

Sensitive data should be encrypted at the application level. That is, even if you have an encrypted file system, don't trust that it alone will be sufficient to keep blackhats at bay. Go the extra mile and ensure that sensitive fields (SSNs, for instance) are encrypted at the application level. Force your application to securely retrieve decryption keys in order to convert the fields into cleartext data.

Why? What's the risk?

One with which I'm familiar is the old favorite, SQL injection. SQL injection permits an intruder to craft their own SQL statements and submit them against your databases. Thus, if SSNs are stored in the clear (at the field level), a SQL injection hack could rip the SSNs straight out of your tables. No muss and no fuss for the intruder.

Thus, I recommend that all sensitive data is encrypted -- at the application level -- in the tables themselves. At least then, if a rogue process were to compromise your database, they have an extra attack to make against the sensitive fields. Force the bad guys to go the extra mile.

Redmond: Data at Rest Is a Sitting Duck