Thursday, May 7, 2015

Learn the rules to the game or get off the field!

The war of data classification and preventing data exfiltration

I've been working for a company for a few months now and it's been pretty interesting to start.  However, as time has dragged on and the new and shiny things aren't so shiny any more, the badness starts to rear it's head.  It's following the same pattern as most engagements.  You start off and they love your energy and ideas.  Eventually, you get a feel for the lay of the land and start making some recommendations that require real work.  After initially balking about not wanting to do real security work, they start throwing out terms and catchphrases that they hope will buy points and effectively allow them to buy some security.  Spoiler Alert...yeah, those advanced technologies that are all the buzz right now...they require work too.  And what's worse, they have some heavy prerequisites, like defining and learning more than a few rules.

Some notes on a debate with a friend has been sitting here in my account as a draft and just waiting for me to polish it off into some complete and coherent thoughts.  This particularly long flight between JFK and SAN seemed like a good time to weave a few ideas together that have been pooling up in my idea box. Enough of the side trip, lets get back on the path.

My friend and I were discussing the initial problem stated above and a point was made about the tools of the trade need to be dumbed down.  First, I find that idea pretty offensive.  The idea that we Americans, I should be correct to say North Americans, and specifically all those flabby people that can't pull themselves away from the latest reality show to bother to learn a bit about computers that have become embedded in our lives...what was I saying?  Oh yeah, that we USA folk can't be bothered to learn enough to innovate or even understand something unless you put it in a beer commercial during and NFL game and we need to have security dumbed down.  Heck, we can dig into the NFL rules enough to know the expected inflation pressure of a NFL football, but we have a really tough time figuring out an effective way to put a security label on data and consistently handle that data in a secure manner.

So what does that rant boil down to?  Companies need to pull their heads out of their collective backsides and realize that security is not just a footnote, but a key component of their business plan, as much as finance, HR, and legal.  It is as important to have solid security strategy as it is to have solid business strategy and solid legal and HR strategy. When I keep seeing security as an afterthought or relegated to a sub-group of IT, I know that it is going to be a bumpy engagement and I'll need a Valium at the end of each day just to keep going back.  And it's not just mid-size corporations.  Look at what happened to Sony just recently (well, not so recently, these notes are old, but still...the point is salient).  I wouldn't call them mid-sized.  These are not isolated incidents.  It is a systematic and willful ignorance of the rules of the game that is being played.  How can you ask the team owner for the right player skills and equipment when you don't understand the basic rules of the game, much less the advanced strategy that is built upon the thorough understanding of the basic rules?

Bad assumptions make the game harder 

Another point brought up in our discussion was about the importance of watching for and noticing the exfiltration of important data. Well, yes, that is very important, and I tried to argue that my friend was making a false assumption that companies know what is important and what is not and can readily recognize the difference between the two.  How can you expect most companies to know what is important and what is not when they put dumb policies in place that append stupid legalese to the end of emails that needlessly label every single email as confidential and proprietary data?  That is an abomination.  We all intuitively know that not every email is confidential or proprietary.  So why would you label it as such?  Now you have to handle it as such or admit that you don't know what is confidential and what is not and don't know how to handle it anyway.  Friends, this is the stuff that goes on out there every day.  I wish I were making this up, but I'm not.

My current client and numerous past clients all had some level of concern about data exfiltration.  Of course the obvious questions are asked of their 'trusted security advisor;' I put that in quotes because that is how they think of you until you tell them that it's gonna take some work, and then they label you a nut-job.  So, they ask you, how do we keep the important stuff from going out the front door?

"Well, what stuff is important?"
"You know...the secret stuff."
"No, I don't know.  How would you suggest that I tell the very complex tools what to watch for if you can't tell me?"

So much for dumbing down the tools...no, it's more impotant to learn the rules before you can begin to play and have any expectation of winning.

So where do you begin?

How do you begin playing a game?  Well, you start simple and work your way up.  Start with bulk classification and putting some rules in place to ensure that a big pile of data that is pretty much important to us can get nowhere near the front door. Make sure everyone understands the rule and knows their role in ensuring the team plays by it.  That idea alone is pretty big, because you have build on that as the rules get more complex. As you get better, you can start to add more complexity.  Different data types, different rules about who can see it, however, it is important to keep in mind that in every game there has to be a referee.  In this game it is the data custodian.  Basically a fancy term for someone who gets to decide if a bit of data makes the cut for a particular classification or not.  This person needs to be on their game and engaged at all times because we all know that if players aren't constantly watched, someone will try to sneak something past you.