Is your organization's mobile device strategy prepared for a device-agnostic future? In this five-part webcast, Craig Mathias, principal at wireless mobile advisory firm Farpoint Group and a well-known industry expert in the areas of wireless communications and mobile computing technologies, discusses the fundamentals of a mobile device strategy.
Here, in part three, Mathias explains how to avoid a BAD (bring any device) approach by answering the who, what, where, when and why questions that are an essential part of every mobile acceptable use policy.
The whole idea behind BYOD originally was, "Why buy a product that the user doesn't really want? They'd rather use their own handset." Nobody wants to carry two devices, after all, and it fits in very nicely with this whole consumerization-of-IT theme that we have going.
But what we ultimately learned was that if BYOD is properly implemented, there are big financial savings that come along with this. We don't have to spend all that money on capital for devices that no one really wants to use, and we can share the operating costs. We can provide a reimbursement on a fixed basis or an actual accounting basis.
Bring any device -- the acronym there is BAD.
BYOD was originally viewed as revolutionary, but it really isn't. A lot of people have pointed out that BYOD was going on in organizations whether IT or other management authorized it or not, and so I got to calling it "Guest Access 2.0." With guest access, you're letting foreign devices, user-owned devices, on your network generally for the purpose of Internet access but sometimes for other functions as well. So, why not just extend the model a little bit? And this led to the conclusion that BYOD is really just a new term for managing a set of restrictions that must be in place in every organization regardless.
Now, there are some new technical elements, product and service elements that go along with this, much as we saw in the mobile device application and information management spaces. There's management here as well. Now, we need to begin to come up with what those solutions are going to be by asking some fundamental questions: first of all, the usual who, what, where, when and why's.
Breaking down the W's for an acceptable use policy
Let's start with "who." The who question answers which users should be allowed to bring their own devices in, and what devices and operating systems [are allowed]? And, I've said many times, that does not mean every device. Bring any device -- the acronym there is BAD. We want to make sure that the devices and the versions of operating systems supported are in concert with the capabilities that are required under local policies.
Where can people use their own device? When can they use it? We can restrict these kinds of things in the building and in other locations as well. What activities are permitted? What resources can be accessed? What sensitive information might be stored on the device? That becomes again sort of a mobile information management kind of problem, but very much in concert with BYOD, and so, we need agreements.
We need a security policy. We need a BYOD policy, a BYOD agreement so that everybody knows their responsibilities, and of course, we need support. I've argued for some time that BYOD is really about two key functions -- authentication and policy -- so that's really what we're looking at here.
Along the lines of authentication, that might involve identity management of some form. We'll come back to that in a little bit, and again, guest access. There's no reason why that wouldn't be part of an overall BYOD solution.
More on mobile device policy from Craig Mathias
Crafting a device-agnostic mobile device strategy
Standard elements of any MDM program
Even with fixed access, it doesn't necessarily imply wireless and then regulatory compliance. You may be subject to such rules as HIPAA, PCI, Sarbanes-Oxley. We need to make sure that the BYOD elements that are in place are in concert with those as well. So let's look at a strategic framework for BYOD.
As I mentioned to you, we can put various restrictions in. We can restrict access to certain days or just allow it on certain days. We can restrict it to certain times of day, certain locations within a facility. That might vary based on whether we're talking about our own staff or whether we're talking about guests and visitors. We need to be able to define a broad set of permissions, and this is generally done by users. Users can belong to various classes that might be based on a role, a particular role that'll define what access to resources they have, and what performance they get. We can throttle throughputs, for example, based on different classes of use, other specific capabilities and handling exceptions and again, what devices are used.
We should not allow just any device on the network. So, which device? Which operating system? How they must be configured? Now, we're getting into Mobile Device Management and then what applications are allowed and that's Mobile Application Management. But again, everything revolves around policy and authentication.