We don‘t need yet another database security czar.

I was reading this article about recent data breaches that was recommending Yet Another Government Agency® and (no surprise) I started getting mad:

A program to share best practices among agencies at all levels of government and create cybersecurity templates, even if they are not mandated, would be a big step forward in data security, Kleinfeld said. Data Breaches at State, Local Agencies Expose Data about Millions (redmondmag.com)

We already have one! It’s part of DHS!! Just because the appointee hired to run it lacks experience that most security professionals would consider requisite… Why not? We might be electing a president without any meaningful executive experience in a couple weeks. Government is never the answer to a domestic problem. The fact that we have government agencies collecting and storing so much sensitive data IS the problem!

In the meantime, we’ve already got more public resources on data security than the average DBA will ever read. Here are just a few:



http://iase.disa.mil/stigs/checklist/index.html (The 182-page database security checklist is interesting. It was updated in January 2008.)

I know that there are strict DOD guidelines which ought to serve as a template, and I’m pretty sure that I have bookmarks somewhere for NSA security resources, too. The information is out there! The problem is that the people being hired to be responsible for the data aren’t reading it and implementing it. That’s what happens when you (the taxpayer) are only willing to pay half of the market rate for government database management positions… and hiring your cousin’s nephew to be the county DBA is probably not a wise idea, either.

There are “industry standard” practices which were violated in nearly all of the data breaches cited above or publicly acknowledged in recent years. Another government agency won’t help the situation. Part of the problem is that everybody wants to “solve” the data security problem, but it’s not a "problem” which can be “solved”. It’s a risk that has to be managed. Constantly and continuously.

Here’s an example hypothetical situation to demonstrate the continuous problem (we’ll leave simple software security patching for later):

  • Steve the DBA has been conscientious and has encrypted his database backups made in 2008 and following with a strong a algorithm (AES-256).
  • Steve works in a moderately regulated industry (not to mention at a company that gets sued from time to time), hence the corporate data governance strategy requires that he has to maintain backups for a minimum of three years.
  • Because he has to maintain a disaster recovery strategy, too, his backups are taken offsite on a regular schedule by a 3rd-party vendor.
  • In 2010 (that’s in our hypothetical future), an advance in mathematics related to encryption demonstrates a heretofore unknown but readily exploitable flaw in AES-256.
  • If Steve isn’t constantly learning and monitoring trade magazines, especially in the realm of information security, he won’t even know that he now has TWO YEARS OF BACKUPS @ RISK!
  • What’s the solution to this problem?
  • Will Cousin Bob’s nephew known how to solve it?

Another part of the problem is employers which hire inexperienced people to manage their data. Companies and government agencies should be held liable for breaches, but ultimately the only thing which will “solve” this problem is individual data professionals insisting upon best practices for data handling and application security.

That means you.

Skip to main content