At the Charlotte BI Group meeting last night, one of the questions I was asked after I gave my talk on Securing the ETL Pipeline was this:

“So you’re basically saying we should trust our DBAs?”

My response caught several people off guard:

“No, I’m saying to trust no one. Not even your DBAs.”

That received more than a few raised eyebrows. I went on to explain. I have two simple reasons to make this statement:

1) The difference between a trustworthy and untrustworthy employee is one life event.

Your DBA gets hammered in the divorce settlement and is now looking at barely scraping by. He or she has access to data that can be sold, and sold for a lot of money because (a) there is a lot of it and (b) it’s verified. You don’t think temptation is going to change a few folks’ behavior? Instead of divorce, substitute bankruptcy due to medical bills (especially if said person lost a loved one after all those bills) or a drug habit that becomes consuming.

A point I made along these lines is we often don’t know the personal lives of our co-workers, so it’s not a given that we’d catch such things. After all, a pilot who didn’t want to lose flying status was able to hide that he was shopping around doctors and we know how that ended up.

2) It might be your employee’s ID, just not your employee.

The Anthem hack tells us all we need to know on this topic. A telling quote from the article:

“An engineer discovered the incursion when he saw a database query being run using his credentials”

Trust No One Implicitly:

As #2 points out, even if you have trustworthy employees, you still have the case where an attacker can get in and steal data. Even though you trust your employees, you need to have controls in place that performs checks like you don’t trust them. That was my point last night. It’s no longer a matter of if an intruder is going to get in. It mostly definitely is now when and for how long.