Skip to content

Bring Your Own Device: a skills disaster even if it's secure

Cyber education

10:00 Wednesday, 04 August 2021

UK Cyber Security Council

ISACA’s glossary defines Bring Your Own Device, commonly referred to as BYOD, as: “An enterprise policy used to permit partial or full integration of user-owned mobile devices for business purposes”. BYOD does not mean connecting non-company devices to the company network in the same way as one would with company-owned (and hence company-managed) devices; the connectivity is generally significantly less integrated than with the firm’s own systems, with systems and their security configured specifically to cater for the additional security risk that user-owned devices bring.

BYOD is a curious phenomenon, because although one might expect the combination of user-owned devices and corporate networks to be a major security concern, the task of mitigating the risk is often not overly complex. A common approach is to implement virtual desktops that are accessed from a client application on the user device with all transfers between the local device and the virtual desktop forcibly disabled; another is to go for a Mobile Device Management (MDM) app that “sandboxes” the corporate data in a company-controlled corner of the device that can be remotely destroyed if required. In the general case, then, securing corporate data that’s being accessed from non-corporate devices is non-trivial, but really not tremendously complex.

So, given that security is not the primary concern, let us look at the problems that it does present us with.

The first issue is one of convenience. As is normal in the realm of security, one tends to compromise usability. User-owned devices need to be secured more rigorously than company-owned devices, so although they’re secure you can probably do less with user-owned systems. The primary inconvenience tends to be with email and office applications: while one’s users will generally be permitted to download documents and data onto their work laptops and use local applications to edit and process them (Microsoft Office and Outlook being the common examples) this will be absolutely forbidden for BYOD systems as it’s usually a bridge too far to secure them and ensure they have up-to-date patches and anti-malware software. Users therefore have to rely on either browser-based versions of Office applications (which rely on internet connectivity and, particularly in the case of the Microsoft Office suite, are significantly under-featured relative to their desktop equivalents) or on the desktop versions on virtual desktops (which are full-featured but still need internet connectivity to be used at all). So just because the BYOD systems are secure, this doesn’t mean they are particularly usable.

The second issue is one of support, and this is where many BYOD regimes fall down: there is a gulf between the BYOD policy and the reality of dealing with your staff’s BYOD devices. The BYOD policy is generally very clear on the line of demarcation of technical support between the company’s systems and the user’s own device ... unfortunately, though, the line can be difficult to enforce, particularly when a senior manager is insisting that the Service Desk look at a user’s device because even though it is not the company’s problem, an issue with it is negatively impacting the user’s work.

While we are discussing demarcation between personal and company, we come across the inevitable issue of privacy. Particularly when we are using the previously mentioned MDM approach to enable access to work materials on personal devices, the user’s concerns about security surface: will the company be able to see my private data or even destroy it on my device? Generally speaking: no and yes, in that order. These are common worries, and the flurry of questions can often test the communication skills of the IT or security teams in to explain (in user-friendly terms) and reassure them of their privacy whilst still getting across the point that the user must accept, if he or she is to access corporate data on a personal device, that in the event of a device loss the company may be able to damage or even destroy the content of their phone or tablet. This is, of course, a question not just of skills but of ethics – even if the security team could read your data, would they? – and communicating effectively in both senses is essential.

There is yet another area of demarcation to address in this context, too: managing the MDM platform. In one sense the security team is more likely than the core IT team to have the necessary skills – not so much in operating the MDM system but in understanding the context of (say) a device theft and considering how draconian they need to be with their remote-wipe facilities. On the other hand, perhaps the IT team’s skills would be better suited to the hands-on element but might be a little more trigger-happy with the destruct button.

Back in the area of support, the issue becomes worse, ironically, in the areas that would traditionally already be grey in the BYOD technology: the software that sits at the boundary between the user’s equipment and the company’s, such as the virtual desktop application on the laptop or the tablet app driving the local element of the MDM suite. Even the most strictly enforced BYOD policy will tend to flex when the issue is with the interface between personal and corporate – but problems with those components can often be more nuanced than basic issues with the devices or its operating system simply not working properly. And this, of course, brings another, potentially greater skills requirement.

BYOD is, then, not inherently insecure. It does, however, bring challenges to the support team. And more importantly, it brings with it one of the key downsides of security: implementing the extra security one needs when dealing with users’ own equipment. Extra security in this sense means less usability, and less usability leads users to work around security to restore ease of use. It is the first step on a slippery slope onto which the company ought not to step.