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.

One of Those Must Read Books – The Cuckoo’s Egg

The Cuckoo's EggI was reading a book about network security monitoring and it mentioned The Cuckoo’s Egg by Cliff Stoll. Stoll’s book has been around for a long time, and it’s considered a classic book with regards to information security. If you’re not familiar with it, it’s the story of a gentleman who wasn’t an IT person who happened to uncover an international hacking attempt (a large one) during the Cold War era and helped track it to its source. The technology is dated – it covers incidents during the Cold War – but the basic techniques to detect, track, and catch are not.

If you have anything to do with information technology, this is one of those books you should try and read. It’s not a slow, academic tome. It’s a well-written tale based on events. You don’t have to be a security professional to appreciate it. After all, Mr. Stoll was not; he was an astronomer. Whatever your role in IT, I hope it’ll cause you to think deeper and longer about how best to implement security mechanisms and controls in what you do. It should also give you an appreciation for how the smallest detail can tip us off to something being wrong in our systems. After all, it was a tiny accounting error that led Cliff Stoll on his quest.

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.