Trust No One Implicitly

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.

Guest Editorial Live on SSC

My guest editorial is live on SQLServerCentral.com. My argument is a simple one: we don’t care about data and IT security. I don’t just mean IT folks. I mean most everybody. I include myself in this characterization. I know a few exceptions, but they are truly exceptions.

In the editorial I include links as to why I make such an assertion. The TD;DR version: despite repeated breaches, our behavior hasn’t changed. Therefore, while we say we care, what we put into practice shows that we don’t.

A summary of the SQL Server security #datachat is live

Recently I posted about participating in a #datachat about SQL Server security. As it turned out, we didn’t talk about SQL Server security, but data security. It was a good discussion with quite a few knowledgeable folks joining in. A summary of the discussion including some highlighted tweets can be found here:

Four Critical Challenges in Implementing Data Security: A Conversation with SQL Server and Security Experts

The #datachats are community open forum discussions. You just have to know when to show up on Twitter! To see what topics are coming up and when they’re scheduled, check out the #datachat schedule.