BYOD: How to keep your data safe on their mobile devices

Splitting the assets

Smartphone user on Tube

This article was produced in association with JAMF Software

Bring your own device (BYOD) is a novel concept that perturbs cynics. And in some ways I can't really blame them.

You appear to be saying to your users: “We are not going to give you a computer to work with. Instead we expect you to bring your own, and we will give you some kind of virtual desktop or Citrix-like session on which you can run corporate apps that are not simply available via the web browser on your device.”

In reality a well-run BYOD arrangement is more elegant than this. Many companies provide financial assistance to help staff buy their device.

It is a nice trade-off because users get to purchase a better device than they might otherwise be able to afford. And the company can relinquish responsibility for fixing the device if it breaks, and also gets to influence the device the user buys.

One company I can think of insists, for example, that BYOD devices must be purchased with three-year warranties, for obvious maintenance reasons.

It's personal

The fun with BYOD from the mobile device management (MDM) perspective is that you do not have total control over the content and configuration of the device.

A device is the user's own, so it would not be acceptable for the organisation to dip into or wipe any personal data. Hence you need to piggy-back the organisational stuff on top of the user’s stuff and must be able to remove it when the device is no longer used for work.

With JAMF’s Casper Suite, you achieve this through a personal device profile (which I will refer to as PDP). This is a somewhat cut-down offering compared with the full-blooded configuration profile.

A PDP has options to control device passcodes, Wi-Fi, VPN settings, ActiveSync, traditional POP/IMAP email, calendar and contact access, certificates and installed apps.

Note, incidentally, that there's a strong iOS orientation here: with Android devices you don't get a lot of these options, though you do get some additional Android security features.

Application support is something I have usually enforced by making browser-based apps available either via VPN (which you can do with Casper Suite) or by publishing them to an internet-accessible web interface with the appropriate security layers on top.

The beauty of accessing apps remotely is that it is a breeze to secure the data

The beauty of accessing apps remotely is that it is a breeze to secure the data on which they work. Because the data is sitting on the server and not on the user's device, you can prevent users from accessing it simply by blocking their login credentials at the server end.

Email and calendars, though, are the main things I have used personal devices for, and with these we are talking about downloading data and storing it on the device. I will talk about how to do it first, and then discuss how to secure the data.

Mail box

Let's look at email. Imagine I have my iPhone 5 with my personal Gmail account already configured.

I have already enrolled it by walking through the wizard. I have entered the right credentials so that the setup process can install the security certificate and device profile, and the server has confirmed that it can see and interact with the device.

So far so good. Now in the JAMF Software Server (JSS) PDP configuration screen we will set up a new account under “Mail (iOS only)”.

As you would expect, there are three sets of information: the general stuff – what to call the account, the user's name and the like – and then the incoming and outgoing email servers.

In my case the test account I have set up is also hosted by Google, so these are the standard Gmail IMAP server settings. Whack them in and click “Done”.

It can take a minute or two for the profile to be pushed to the device – longer if a device is busy – but you can monitor the status via the management pane in the device inventory. Wait until you see “No pending commands” and “No failed commands” in the progress window.

The new account will wink into existence in the front page of the Mail app on the iPhone. At this point there is a really important option in the setup screen: “Allow messages to be moved”. You want to untick this – we will come back to why later.

Set the date

Calendars are no harder than email to set up, once you have caught onto a small gotcha. As with my email example the test calendar is based on Google's application service, and again it is just a simple case of filling in the form with the name of the account, the URL for the calendar app on the handset to connect to, and of course the credentials.

The gotcha is that the “port number” in the config screen on the JSS portal defaults to port 8443, whereas the URL for the Google-based ICS descriptor is actually good old port 443 (HTTPS). It took me a minute or two to make it work.

I have already mentioned that using browser-based or Citrix-like access means that the phone holds no data. So how do we deal with the fact that the opposite is true in our email and calendar examples?

Yes, we could tell people to use browser-based email and calendar functions but that is a major productivity hit, as they can't do anything with it when their device is not able to talk to the server. How does one secure the data of a device that ceases to be used by the organisation?

Safety measures

Simple: the configuration aspects of the email and calendar application that were created by the MDM service are part of the profile that the MDM service sent to the device.

So if the MDM service tells the device it is no longer managed, the profile will be removed and the accounts belonging to it will similarly wink out of existence.

True, if the device is disconnected from the world then the data will remain on it, but as soon as it is able to talk to the internet once more it knows that it has become unmanaged and the data is wiped.

Moreover, if the user removes the management profile manually, guess what? Yup, the data is removed.

The important point, incidentally, is that only the data relating to items that you imparted through MDM will be deleted. The user's home-grown email and calendar detail will remain and just the institutional stuff will drain away.

So long, that is, as you took care not to tick the “Allow messages to be moved” box I mentioned earlier. By leaving this option blank you prevented the user from moving any data out of the sandbox that was under management via MDM during the time that the device was being used for legitimate company purposes.

In summary, the data items we have discussed are secured in two ways. First, by using browser-based apps you have secured the data by not actually putting the data onto the mobile device in the first place.

And second, by ensuring that the institutional data you decide to permit on the device is kept within the configuration items that are controlled through MDM, the user won't be able to access it once the profile is removed and the device is no longer managed. ®

The Register is running a series of BYOD workshop articles in association with Jamf.




Biting the hand that feeds IT © 1998–2018