BYOD - Challenges of protecting data - Part 1

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.


Abstract Data Stream.pngWhether 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...

random-name-u-cant-google-me-and-find-me(anon) | ‎07-05-2012 03:52 PM

Raf, i am in the camp that you have to set initiative to identify your critical data. At least, it should be a priority (technically it should be a business priority but its one that they dont necessarily knwo they need to know so it has to come from security to drive them needing to know). 


As far as data custodians, i think that its a maturity process. And most large enterprises aren't to that level of maturity. I think priority should be on classification/identification and custodians only being identified after your other processes, for example security protections, have been tweaked to account for where the "critical" data is. 


Data classification efforts are always long, but in my opinion completely worthwhile. Always an eye-opener and pave the way for things like Data Masking for dev/qa environments and better policy tuning for existing security controls (note, i stayed away from jumping right on the implement new product bandwagon, though some may help after data classification!). 


Sladey(anon) | ‎07-05-2012 04:23 PM

I've been battling with my organisation for some time to get a data classification scheme in place. There is little business appetite to retrospectively categorise data.

As new systems are developed, I engage with the relevant business unit to ascertain the cost of a. data leakage, b. data corruption and c. system unavailability. using these values gives me the ability to correctly categorise the information and, significantly, provides justification for spending on protective and detective measures. The data gathering phase also identifies threat sources, threat actors etc. so a relevant risk assessment can be performed.

For the historic electronic information, the locations in which it is currently stored have been through a similar process effectively bundling the data into classification 'lumps' Of course, some information is inappropriately classified but it's likely to be classified to high rather than too low. data should retain its classification when it is moved from these stores and should be afforded relevant protection where it ends up.

Does this actually work in practice? Not yet. It's a slow process, I've been working on it for 18 months inside an organisation that has not had an information classification scheme for 17 years. I never expected to gain an immediate win but the process has been accepted by the business and is gaining traction. At least the various business units are at least thinking of the value of their information.


ScreamingByte(anon) | ‎07-05-2012 05:07 PM

This is a great subject and one that I think will need to be addressed very closely in the future because, in my opinion, each individual organization needs to identify the extent to which it is going to identify the data that is critical and implement controls for that data.  Obviously, for some it will not be a big deal, and for others, it will be crucial.  Getting a discussion going about identification methods and process flows that will accompany new methods of identifying and categorizing data is essential.


My gut reaction to BYOD is almost always negative because it inherrently degrades the potency of governance and policy.  Of course, we know that a talented, experienced, and well-equipped person with ill intent is not likely to be stopped easily, but I'm more concerned with where the future is going to take us with relation to the information model.  Moving away from the traditional manufacturing model has meant that information is the new source of wealth.  It seems intuitive to suggest that, in the future, control of information will not only be SOP, but will be central to protecting investments and interests.

This is a great subject to discuss because the data footprint of any organization will only continue to get larger as more and more businesses eliminate silos and work toward implementing architectures that  are modular.  Identifying critical data is a manual process for now, but IMO, we need to develop solutions which can help organizations identify critical data through management applications that can tag files in the same manner in which we can now flip an archive bit.  I am of the opinion that eliminating HI from processes in which automation can streamline and improve management practice is preferable.  But that also brings us back to SDLC and appsec (not to mention human error in configuration)...

slightly anon(anon) | ‎07-05-2012 07:01 PM

I think that some significant risks are being overlooked in the BYOD debate at least in the medium to large organizations (2K plus users). Even in situations where the big risk of data loss is mitigated (think VDI) BYOD re-introduces multiple risks that IT have just gotten under control in the past few years. You can't ask IT to support hundreds of different device configurations, software loads, and patch levels that come along with the BYOD crowd but if you let them wash their hands how do you control the spread of malware on the endpoints your employees are using? Sure you addressed data loss but what about productivity isn't that what you are supposed to be enabling in the first place? What happens when employee X's workstation is so bogged down by spyware it takes five minutes to load a webpage? What if employee Y's workstation redirects all browser requests to porn sites? How do you protect your company's reputation when employee Z's workstation is sending spam from your domain? Where do you draw the line for support and what is the real cost? This is not a dismissal of the idea but I do think these questions need addressing before BYOD can be seriously considered.

Tony DeLaGrange(anon) | ‎07-06-2012 06:47 AM

Having an inventory of information (identifying where the data is located) and classifying the information is as important as having an inventory of IT systems and classifying them based on criticality, and likely these two would align (at least you would hope so).  Many larger organizations will have guidelines and even policies that provide guidance on HOW to classify information, which then drive security requirements on how to protect each classification of data (e.g. Confidential data must be encrypted when transmitted over a public network).  However, the ability to effectivly inventory information, and thus apply the appropriate controls on that information where it is located, was already a challenge prior to the explosion of mobile devices and removable media.  Now with BYOD, organizations may have to consider how employee personal information is handled (depending on the type of mobile solution that's been implemented).  If an employee's device is managed by a company, and that device includes employee personal information, what is the company's responsibility of protecting that information?  If the company syncs all the data on the device, or performs forensics on the device as part of an investigation, is the company required to protect the employee's personal information from being revealed?  What if that personal information was disclosed internally or publicly, revealing that the employee is going through rehab, anger management therapy, a divorse, or a civil suit, does that expose the company to some form of litigation?  What if a company wipes the entire device, which included an employee's personal information?  Depending on the information, could an employee sue the company, in the same manner that a company could go after an employee who did the same to a corporate server?  The point of these "what iff" scenarios should not be used to scare decision makers from BYOD, but rather to think about BYOD from perspectives other than just IT or security.  It is critical that IT engages legal, compliance, HR, etc when establishing a BYOD strategy to better understand all the risks, and what policies, procedures, and controls are required to manage those risks effectively.

Tunn3lR47(anon) | ‎07-10-2012 02:04 PM

Although not diminishing the importance of data classification, it comes with a challenge: human nature.  When data is classified, the freshly minted categories are (ideally) given control standards which are particularly helpful to developers.  If I know my shiny new app is going to be processing healthcare data, then I can go to the control standard for the "Critical" or "Sensitive" data classification and get the right infomation to build my app the "Company" way. 


That's great at the higher classification levels.  It may even work for mediums.  But when you get to "Lows", people just stop caring.  No one is going to consult the security checklists or guides or standards or whatever-you-feel-like-inserting-here when they're building a phonebook.  And with low-risk apps comes the pressure to get it done fast - "oh that app?  That's no big deal right?  Done by the end of the week right?"  Bow before the holder of the paycheck.


Let's get real.  We all know that little mindless app isn't sitting in it's own concrete bunker with a dedicated trunk line.  It's probably sitting in an app pool with 5 other apps, on an OS with 100 other processes, on a VM with 100 other nodes, on an ESX host with 10 racks on either side, and in a data center with 3 redundant hot-sites, many of which containing all the juicy details you ever wanted.  And that's if we're lucky.


More than likely, the app's low "criticality" means it's probably destined to run on some guy's BYOD "server" that he uses as a footrest under his desk, running Windows Server 2000 SP-nothing, which has a persistent connection to a backend DB because the guy got bored one time.  Oh and he's a domain admin is he?  Lovely. 


The days of silos and stand-alone apps are gone.  Every app - EVERY SINGLE ONE - encapsulates an interstate highway to every other app in your inventory (or even in the world).  Sure, if your infrastructure-sec guys really have their stuff together, a malicious actor may run into traffic.  But if he/she is committed, eventually he/she will find the bypass.  One needs only to look at RSA to see a great example of this in action.  "All you need to do is get your foot in the door," Dad used to tell me about making it to the top.  Sadly, Dad didn't know how right he was. 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation