I’ve had a few discussions recently where people talked about the ‘new risk’ of Bring Your Own Device (BYOD), but then mentioned risks – loss/theft of device, use in public place, etc. – that already exist on organisation-managed mobile devices. Turning that around, it struck me that one way to develop a BYOD policy might be to start from the mobile device policy you already have. I’d be interested in comments on how this approach might work.
And if you don’t think you have a mobile device policy, check if you have some official laptops or phones, or provide a webmail service. If so, then how you provide and manage them is likely to have established a de facto mobile policy, and maybe even a BYOD one, even if it’s not written down!
A mobile device policy can be summarised under four main headings:
- Which services and information you make accessible from mobile devices;
- What controls are implemented on the servers and networks providing those services;
- What controls are implemented on the mobile devices themselves;
- What controls are implemented by the users of the devices.
For a mobile device policy each service or information that you make available is protected by the combination of controls implemented by the server, the device and the user. That protection is presumably sufficient for the organisation’s risk appetite, otherwise the service wouldn’t have been made available on mobile devices in the first place.
With BYOD the server, network and user controls are the same as for mobile. The only difference is that rather than the organisation managing the controls on the device it has to rely on the device owner to do it. That may still be sufficient, particularly where owners know that the same behaviour will protect their own information on the device. If it isn’t then the organisation either needs to compensate by strengthening the other controls (presumably those on the server and network) or else decide that that particular service or information can’t safely be provided on BYOD.
On the server side there are several different options for providing mobile access. Here they are illustrated with access to e-mail, but similar approaches can be used for calendar, filestore and most other types of information service:
- Don’t provide the service at all: e-mail can only be accessed from fixed desktop machines;
- Provide the service as a virtual desktop or application: the organisation’s virtual desktop includes an e-mail client where the organisation can limit functions such as local save and ensure that anti-virus is kept up to date;
- Provide a web interface: indeed webmail may now be the norm for many Internet users;
- Provide a dedicated application: for example providing e-mail access as part of a campus smartphone app;
- Permit access from a native application: i.e. allow remote access to the mail store by the native e-mail clients on smartphones, tablets and laptops.
At each stage the users’ control increases so information security becomes more dependent on their behaviour and the controls implemented on the device itself. In particular if the service is provided to an application running on the device, then information is likely to be automatically cached there too. This enables off-line access, which may well be convenient or essential, but also increases the impact if the device is stolen. Though, of course, even a tightly-controlled virtual desktop can’t prevent a user reading a sensitive document on a crowded train.
How the organisation chooses to provide a service therefore influences the controls that are needed on the device itself. Depending on the device and the software it runs, some or all of the following may be available:
- Password/PIN to prevent a casual passer-by or thief from obtaining immediate access to the information;
- Encrypted communications (e.g. TLS/SSL) to protect passwords and other sensitive information transmitted across networks;
- Encrypted storage to protect stored information against more determined thieves who can remove disks to another device;
- Remote wipe to reduce the opportunity for information on a lost/stolen device to be misused;
- Separate application containers to reduce the threat from other, possibly malicious, programs running on the same device;
- Controls on what applications can be installed or run, to prevent unauthorised or insecure use;
- Monitoring of use, or of information transferred on or off the device;
- Remote discovery of the location of the device.
These don’t map directly to the server-side categories, though decisions on one side to affect the requirements on the other: for webmail it may be sufficient if devices have a PIN and encrypted communications; for a native e-mail client with off-line storage that storage may need to be encrypted and capable of being wiped remotely. CPNI have a paper on the technical controls likely to be available on mobile devices and Intel have a paper on deciding which information and services require which BYOD controls, available from http://www.intel.com/IT.
Once you have written (down) your mobile device policy, extending it for BYOD should just be a case of reviewing the controls you need on the device. The same server and network controls are still available and you still have the same reliance on users/owners behaving securely with information. Since you are relying on owner behaviour already it may be acceptable to rely on the owner to manage some of the device-side controls, too. But some controls may need to change if:
- The control isn’t available, for example the owner’s chosen device may not support separate containers for applications;
- Relying on the owner to implement and manage a control may be too great a risk;
- The control may be unsuitable for a BYOD setting, for example the Information Commissioner’s BYOD Guide expresses concern about employers monitoring the usage or location of a device that the owner may well lend to members of their family (the list of device controls above is roughly in increasing order of intrusion into the owner’s privacy and use of their personal device).
If a control can’t be implemented on BYOD then it may be possible to shift it back to the server, either just for BYOD or for managed devices too. Or you may have to conclude that that service can’t be provided safely on that type of owner-managed device. In that case you need to configure the server and network to restrict access only to suitable devices, and you need to explain to device owners why they shouldn’t try to get around those controls.
Once you’ve made those decisions, I think you pretty much have your BYOD policy. And it should be consistent with your use of other mobile devices, too.
As was discussed at UCISA’s BYOD conference earlier this year, you also need to provide both network and human support for a wide range of devices and to protect the network from equipment that may be insecure or hostile. But you’ll need that anyway to support visitor and student machines. Choosing not to allow/support BYOD probably won’t significantly reduce the demands on your wireless network.
