This 4-part mini-series will address some of the recent conversations going around on the challenges of data mobility in a Bring Your Own Device (BYOD) enabled enterprise.
The fact of the matter is, it's naive to think that even if your organization doesn't support BYOD that your data won't end up on a memory stick left on the couch of some coffee shop, or in a screening tray at the airport.
In a previous post I addressed the realities of accepting foreign bodies on your corporate network - so let's look at the BYOD issue from another angle. This 4-part series will touch on the challenges around the management of data from a productivity, security, and defensive point of view.
Whether we're talking about cloud computing, or BYOD, or hacking in general - the buck tends to stop with data. It's not a sane position to simply say that data cannot leave the corporate perimeter, as it does every single minute of every single day in most cases.
Few organizations have the ability to be fully operational while being self-contained, so locking your data off from the rest of the world is futile. Most organizations acquire, transact, and exchange data with various partners and their supply chain several key times each and every day - so whether you're accumulating data on credit card purchases, or performing background checks your organization has transient data virtually all the time.
The trick with data is that it can be anything. A cookie from one of your users' browsers, a name/account number pair, or a call log - all of this is data that your organization may possess or transact, and it's difficult to apply uniform protection mechanisms to data that lives in many disparate data stores.
Think about it. There are database servers, flat files, email boxes, log files, excel spreadsheets, PDFs, chat logs, phone logs, text files and on and on. When I was a BISO (Business Information Security Officer) I once had a presentation given to me by a vendor who claimed to solve my data mobility problems by putting an 'agent' (hint: install something) on every endpoint and then gateways in front of all of my data stores.
Sure, that sounds great if we're only talking about SQL servers and file servers... but what about all the workstations, laptops, tablets, mobile handsets, and everything else that generates data.
Oh, right, what about the printers which print data to this thing called paper ... or what about people who can hit that "PrtScn" button on their keyboard, or write things down to paper... yep, you can't easily control all that can you?
I can say with confidence that one of the biggest challenges to devising a data protection strategy is identifying all your critical data... as I still struggle with that at home in my home office. Mountains of data, from scanned images, to photos, to PDFs of statements and critical paperwork - what's critical and where is it? Wait ... how do I define critical?
This is all enough to make your brain hurt. Now try applying this to a working health care facility where data is the difference between a healthy patient and a lawsuit for malpractice, but we're not talking minutes here - this is a place where seconds count.
We can probably debate about how realistic it is to try and identify/classify all the [critical] data in your organization but I suspect we'd likely never come to a consensus - as I've had long discussions which made a great case for either side.
Some believe you can't ever identify/classify all of your data and you should move on, while others believe that without making your data custodians responsible for identification/classification of your critical data nothing else can happen. This is a difficult topic and I'll address this specifically in the next post.
Can we identify and classify enough of our corporate data? Let's hear your thoughts before the next post goes up...
Cross-posted from Following the White Rabbit