The Myth of the Malicious DBA
There is this idea driven by the combination of regulatory compliance requirements and money-hungry vendors well-intentioned solution providers that there is a malicious database administrator operating within most organizations. This database administrator is likely a part of a large network of information traders attempting to fence their ill-gotten goods to the highest bidder. They can strike at any time and are, most likely, deciding which other choice pieces of information in your organization will subsidize the purchase of their fourth Murciélago. There is no question that this scenario makes for a great (read: terrible) Hollywood film premise. Presently, however, this is nothing more than a work of fiction.
Whatever the intentions of those that are propagating this myth of the malicious DBA, the current data available does not tell us such a story. Even a cursory glance at this data paints a completely different picture. Feel free to explore the data yourself. In the chart below you can see that a malicious DBA was responsible for 3% of data-related breaches. You should also know that I was being generous with the descriptions. It was most likely *not* a DBA, but then perhaps you’d think *I* was making this up if there were no DBA-related activity.
For all this breach data there still are companies out there that tell you that their state of the art encryption technology will help you defend your organization from the malicious DBA threat. It seems odd to spend so much on the “Malicious DBA” threat when it accounts for probably less than 5% of the overall threats to confidential data. I think these product vendors know this. This is why they attempt to tell you that their database encryption products “protects the data within the DBMS and also protects against a wide range of threats, including storage media theft, well known storage attacks, database-level attacks, and malicious DBAs.”
Database encryption won’t help you with the laptop problem, it won’t help you with the paper problem, it won’t help you with process problems and it won’t help you with the hacker problem. It helps you, if you want to make the stretch (and to be charitable I will), with the tape problem (assuming your undefined processes backup data that is still important to bad guys, but is not required to be protected according to regulatory requirements), it will help you, maybe, with the disk-in-server-gone-missing problem, and it may help you with the malicious DBA problem. But, wait, there isn’t a malicious DBA problem. So what does database encryption do again?
References:
http://www.privacyrights.org/ar/ChronDataBreaches.htm#Total
http://www.ingrian.com/resources/sol_briefs/implementation-sb.pdf
Dan on 20 Aug 2007 at 7:27 pm #
Great stats Rudy! Do your percentages represent # of breaches (events, so to speak) or # of customers impacted? I’m asking because those are two different ways of running metrics on breaches which may result in different conclusions. It’s similar to the ‘air travel is the safest’ stats — is this determined by counting miles traveled or time in the air? When comparing these two figures with those of car travel, the variable measured changes the stat.
I agree that DBAs are typically not the perpetrator of these crimes, however when / if they are, the impact can be significant. For example, in July, a Certegy DBA stole 2.3M records…. that certainly skews the stats based on how you measure it: Only one breach but 2.3M people impacted.
This is neither here nor there with respect to database encryption…. just an interesting factoid.