I have just read a sponsored, and semi-interesting White Paper headlined as ‘10 steps to implementing a BYOD program’ and titled ‘BYOD simplified into 10 steps’. I could potentially just end this blog there. Most readers, I hope, will already have the message. However there may be some value in expanding (if you read on it’s your own choice).
Bring Your Own Device has happened
My favourite Nokia ‘candybar’ of all time, the 6300 released
seven years ago (and it still works), has internet browsing on it. I can get
personal and work emails on it and I can access any corporate website for which
I have credentials. Most of the clever people at IBM’s Hursley research
laboratory in the UK have been using self-purchased and ‘unsupported’ Apple
devices since long before IBM sold its Thinkpad division to Lenovo, and about a
decade before the now ‘strategic relationship’ with the west coast fruit-design
factory. These are IBM’s brightest and best, they didn’t need support.
I have noticed that even staff in often beleaguered public
sector organizations are using their own devices, often without permission,
having gained that all important key to the wireless network after it was posted
on the board in the staffroom – but that is a subject for a future blog.
The White Paper suggested as step 4 ‘establishing a pilot
program’. Sorry this is 2014, it is too late for that. The proverbial horse has
bolted, and whilst to continue the metaphor, the CTO cannot now recapture and
‘break it in’, the best they can do is contain it in a field and ensure that
it’s actions do not result in harm.
What is the best rearguard action (for the CTO)?
Well first move quickly, and be positive. Establish in an
open way a working inventory of the range and numbers of devices that people
are using. Advise users on security, not just from a corporate basis, but for
themselves. ‘Sell’ security on a personal basis ensuring that users have pass
codes, and preferably encryption, on their devices. They wouldn’t want someone
finding their phone left on a train and then posting their ‘selfies’ to the
world, would they? Ensure also that corporate data cannot be stored on personal devices
unless encrypted and then preferably with a remote wipe option.
What are the other lessons from the paper?
I have to say that in fairness, the White Paper was very
measured, and it did contain many bits of good advice. sadly however ‘Preparing
support and help desk’ was step number 10 in the list of 10. Given my earlier
statements, for any CTO finally accepting that they have to go with the BYOD
flow, that needed to be number one.I fully accept that the support and help desk cannot have
examples of all the potential current devices (or even my seven year old Nokia)
for reference. Given the now six to nine-month production runs of many mobile
devices it will be impossible financially to keep up, but it would be sensible
for them to have a range of the most popular, and for the support staff to use
those devices as part of their operational role to establish familiarity, and
be seen as ‘champions’ of those models. You may even wish to label them a
‘genius’ or ‘guru’.
Despite the fact that I have argued before that people will
most likely self-train on devices that they have bought for themselves, they
will not instinctively know how to register with the VPN, or adjust the browser
settings to act safely when accessing corporate systems. This is where the
support and help desk function really needs to ‘step-up’. They need to aim to
automate such processes as much as possible. Every mistaken keyboard input by a
user is a potential security risk.
BYOD does not have to be the potential headache for the
support desk that the White Paper appeared to imply. But the paper did raise
the issue that it was not a ‘one way street’ with savings coming back to the
CTO’s budget, through reductions in procurement. There needs to be investment
in the security and communications infrastructure. Furthermore, to get the best
out of BYOD whilst maintain the corporate control, may require investment in
virtualization or migration to a cloud-supported infrastructure. Two more
subjects for future blogs.