This is the first of a three-part blog series exploring the issues and challenges with consumerization and BYOD. This first post will dive into the landscape of existing approaches to consumerization and some of the issues that arise at many enterprises.
Two of the biggest challenges IT departments face today are consumerization and its close cousin, Bring Your Own Device(BYOD). Both are hot topic issues, driven by the popularity of consumer computing platforms but, to be clear, these two terms are not one in the same. Consumerization broadly describes the effect of employee preference coming into play on the technology that IT provides, based on personal affinities to the functionality and usability of a given smart phone, laptop operating system or tablet. BYOD goes one step further, as employees purchase their own devices for use at work, with or without the support of the IT department.
For years, the effects of consumerization appeared in pockets, with small groups of users who expressed their own personal choices in applications and platforms. With the proliferation of consumer devices, it’s now become a mainstream issue that enterprises need to address. In the 2012 PriceWaterhouse Coopers Global State of Information Security Survey, only 43% of the respondents indicated that they had a strategy to deal with employee use of personal devices. What’s left unsaid is the fact that even with a strategy and policy in place, it can be maddening to enforce the rules on a diverse set of technologies. Consumerization’s effects on devices is a sprawling issue that touches on a number of different control points, and that can lead to a lot of administrative headaches and unmet needs. BYOD goes one step further than consumerization, because it manifests when employees use devices in spite of what the policy states. Every gap between the desired policy and the policy that can be enforced introduces pockets of unquantified risk, and that’s what scares security teams.
Many companies assume that consumerization is a device issue, and control should be at the device level itself. If we look at the spectrum of devices that fall under consumerization, then it seems like there are as many tools as there are devices. There’s one tool for managed laptops, another tool for managed mobile devices, and different tools for unmanaged laptops & mobile devices. For example, a vice president may have an IT issued Mac OS X laptop, a personally owned smart phone which is covered by corporate policy, and a personally owned iPad which is not. Logically, it would make sense if there was one management tool per user, but in this example, there are three different tools.
Managing laptops
Corporate laptops fall under the jurisdiction of desktop management tools. These systems provide the capabilities to recognize the endpoint, grant user access to the network, and push packages and patches. While these systems work just fine for corporate controlled assets, there’s a big world of operating systems that aren’t as easily supported. Consumerization added Mac OS X to the party, but it’s also remarkable to note that there are lots of Windows 7 desktops in use at companies that are still standardized on Windows XP. That’s not all; there are also Linux laptops and Chrome-OS netbooks in play, and now Windows 8 on ARM processor just around the corner. Ask any IT department and they’ll tell you it’s hard to manage desktops even with standardized hardware and corporate image. Add consumerization to the mix, and things get that much tougher to keep running and stay secure, especially with the addition of platforms that were not part of the original scope of requirements for the desktop management tool.
When it comes to personally owned computers, contractor laptops are a perfect example of how IT had to deal with non-standard corporate images on its network. Contractors sit side by side with employees, connected to the same subnet and accessing the same applications & resources. Yet the contractor’s laptop is not corporate imaged and it’s not being managed by IT, so it’s questionable whether that device meets the security standards expected of regular employees. Enterprise IT departments often worry about the risks that these endpoints pose, especially if an infected system makes it on the corporate network. With the influx of employees bringing additional non-corporate laptops due to consumerization, staying on top of malware prevention and patch management becomes much more difficult.
Smart phones and tablets under management
Device management for smart phones and tablets leverage an entirely different framework, collectively called Mobile Device Management (MDM). Most companies already have one mobile device management platform in production, the venerable BlackBerry Enterprise Server. In order to support consumerization and the introduction of other devices, some of which may be employee owned, enterprises are now adding a second MDM to replace or work in conjunction with their BlackBerry Enterprise Server. Mobile device management tools can provide policy controls for smart phones and tablets and have the advantage of being able to perform over the air policy changes to devices that are not physically within the corporate building.
A MDM can enforce policy on a managed corporate or employee owned smart phone or tablet, but by definition, it does not administer or control the existence of unmanaged devices on the network using corporate applications. As mentioned in the previous section, a MDM also does not manage any type of laptop. From the perspective of personally owned devices, the employee has to install either policy or an application that the IT department controls and that can be a source of some friction. For example, an MDM policy can lock down settings that the user can’t change on their own personal phone, and it can lead to scenarios where IT may need to execute a wipe on both corporate and personal data. In order to mitigate these issues, organizations look at additional measures to partition date, such as using wrappers around corporate applications on the mobile device to sandbox enterprise data from the rest of its storage.
Dealing with personally-owned unmanaged devices
The personally-owned tablet that the vice president uses at work does not fall under the jurisdiction of either desktop management or mobile device management. Instead of being able to control the device itself, some vendors proffer solutions based on blocking access to the network. Network Access Control (NAC) is one of those methods, which can identify permitted devices for use on a network, and ban any others.
The idea that NAC can profile and identify allowed devices is smart in principle, but there are a number of challenges that can make implementation tricky. The hard part to deal with is that there are a large number of devices that might be allowed under a BYOD, and weeding out what should be allowed and denied can be difficult work. For example, a device might be allowed for one set of applications but not for others, and it might not be easy to express which use is appropriate. It might be perfectly acceptable to permit tablet access to the Intranet, and yet restrict access to the CRM unless from a properly configured, company-owned endpoint. It can be thankless work trying to create a list of exceptions for all the possible devices that fall under an acceptable use policy, especially at the rate that employees join and leave the company and the number of devices that each one possesses. It’s especially trying on network operations personnel who do not typically deal with the high volume of change tickets that come from end user issues associated with the explosion of mobile devices.
Looking for New Approaches
In the examples above, it’s clear that there are a lot of places to get tripped up trying to develop a policy that is both practical and enforceable. In my next blog post, I’ll illustrate a different approach. Instead of tackling the problem from the standpoint of dealing with all the permutations of use cases, let’s start with how to put more effective network security controls to gauge who can access a particular application. Start with the network, and many of the use cases start to become much easier to handle. Stay tuned for more in the next blog post.