Planning Considerations for BYOD and Consumerization of IT (Part 1)

by [Published on 13 Aug. 2014 / Last Updated on 13 Aug. 2014]

In the first part of this series on planning considerations for security BYOD and consumerization of IT, we'll look at the BYOD problem domain and discuss key aspects of planning and design.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.

Introduction

We’ve talked about the consumerization of IT trend before. Its growing popularity has to do with the fact that employees want to be able to use their own devices to do some or all of their work. People are more comfortable working on the devices that they select and own. It’s good for the employees, and it’s good for the company in that it saves a lot of money in equipment costs. It’s not always so great for security, though.

In the past, IT organizations had total control over the devices that could access corporate data. There was a good reason for this – corporate data needs to be secured against the possibility of theft or data leakage. In order to protect the data from getting into the wrong hands, IT organizations tightly managed the devices that users could use to access that information. This included hardening the operating systems, limiting the user roles on the devices, and maintaining copious logs recording the users’ usage of the corporate owned devices. The bottom line typically was “you can use the device for anything you like, as long as you use it only for approved work.”

Fast forward to the year 2014. Everyone has a smart phone and many people have tablets and convertible PCs that they use for personal enjoyment and productivity. Many of them also have laptops and desktops that are not company owned. Employees expect to be able to use whatever device they prefer using, at the place they happened to be at the time, to get their work done. This is in stark contrast to how things were in the past.

Of course, users always had their own devices and in the past they were told that they couldn’t use them because of the security concerns. The security issues haven’t gone away and they’re as valid as they’ve always been. However, those decisions are being made, in many cases, far above the level of the IT department. Monetary savings and employee satisfaction (resulting in greater productivity) are the driving factors.

IT response to BYOD

If it sends a shiver down your spine when you think about embracing the Bring Your Own Device approach to IT, you’re not alone. Consumerization of IT and BYOD have the potential for creating havoc within your organization if not implemented properly. There is a proliferation of different devices that users own and there is an expectation that you will support those users when they need to access corporate information from those devices. That expectation comes not only from the users themselves, but from corporate decision makers and bean counters who like the impact on the capital expenditures ledger when the users have to purchase their own devices, thus transferring the cost away from the company and back to the user. In addition, many of those “higher ups” want to bring their own devices, as well.

And that may be the crux of the issue: “users” include those decision makers, and the decision makers want to be able to work from anyplace, anytime, using any device they might have. If that also means the company won’t need to spend as much money on purchasing devices for the users, so much the better. But what about the security implications?

Unfortunately, many IT departments have taken an ostrich-like approach to this problem and handle it by putting their heads in the sand and hoping that the problem will go away. They manage the BYOD devices in a reactive way; that is, they wait until something bad happens, and then they try to fix the problem. When the next bad thing happens, they then attempt to fix that problem. I would argue – and I think most strategists would agree – that this is a recipe for disaster, as there are an infinite number of problems that can occur with a BYOD enabled workforce, and one of those problems could potentially do grave damage to your company, as well as your career.

The BYOD-centric infrastructure

If your company is considering allowing users to use their own devices to connect to the corporate network and do work for your company, then you really should think about how to design an infrastructure that will support your users based on the requirements you define for this scenario. I hesitate to call this a “BYOD infrastructure” because the infrastructure elements that are required to support BYOD are probably already in place. Supporting a BYOD enabled workforce is more about defining the requirements you want to impose on the users and devices and then creating a collection of policies that will satisfy your requirements.

When you stop to think about it, this is just good solution architecture: start with the planning process that defines your requirements and then, after you have a clear view of your requirements, complete a design exercise that ends up with a design that enables you to meet all the requirements.

It might seem obvious, but this approach is quite different from that we see all too often in the wild. More typically, even in enterprise IT organizations, we see the process start with the design exercise. The systems designers make themselves aware of the technologies they have that will support BYOD policies, and then they create a systems design that they think will work, using those technologies. The problem with this is that they haven’t really thought about what their requirements were, so the design is based on “what our stuff can do” rather than “what we need our stuff to do.” The result too often is a BYOD support system design that will end up with a lot of “gotcha’s” and will have you (or management) asking “Why doesn’t it do that?” and “How did we end up with a BYOD support system that allowed the user to do THAT?”

Planning vs. design

The best place to start is almost always at the beginning, and the beginning of the road to BYOD device support is the planning process. “Planning” seems like a simple concept that we should all inherently understand, but I’ve found that there is a great deal of confusion out there regarding exactly what planning is and how planning is different from design. The result of this confusion leads to the problem that I talked about earlier, which occurs when organizations start with the design process, and then you end up with the unfortunate results that can ocur when you begin with design.

Even for those who understand the different between planning and design, you’ll find that there is a wide range of opinion regarding the specific definitions of planning and design. I’m not going to go through the range of definitions here because that’s not what this article series is about. However, I will give you the definitions that I have found the most useful when I’m going through a planning and design process:

  • Planning – during the planning phase of a BYOD implementation (or any other project) you need to be aware of the questions that you need to ask that will provide answers that define the requirements for your BYOD support system design. This is not as easy as you think. If you’re new to the BYOD problem domain (or new to any problem domain) the most difficult part is to figure out what it important and determine the best questions you need to ask in order to get the information you need so that you will have a BYOD system design that does what you want it to do. If you don’t ask the right questions, you’re not going to get the right answers and the result of the wrong questions or missing questions will be the wrong design or missing elements in the design.
  • Design – The design process takes place only after you finish your planning process. At the end of the planning process, you will have answered all the questions you need to ask and the answers to those questions will comprise the requirements for your design. It’s important to note that the requirements are not for technologies, they are for capabilities. And by their very nature, capabilities are software and hardware vendor agnostic. Your requirements are never “I need Cisco stuff” or “I need Microsoft stuff” (although that might end up being an ultimate implementation requirement because of established relationships with certain companies). During the design process, you must make yourself aware of the universe of design options that are available to you across a number of vendors and then you can select those options that most effectively solve the problems (or requirements) that you defined during the planning process.

It’s important to note that planning and design exercises are not, and should not, be linear. The reason for this is that you will always be learning more about the problem domain that you’re working with, and thus you might add more questions that define new requirements. Or you might remove a requirement because of unintended consequences that you later learn about. The same applies to the design process. When you go through a design exercise, you might make a design decision that conflicts with a later design decision. You will then have to go back to the original design decision and determine whether there is an alternate option available that enables you to keep the later decision. If not, then you’ll need to weigh your options and determine whether one requirement takes precedence over another requirement, and proceed accordingly.

BYOD planning considerations outline

With all of this as background, let’s introduce what we’re going to do in this article series on BYOD planning considerations. First, our problem domain is BYOD or the Consumerization of IT (CoIT). Within that domain are several subdomains. Within the subdomains are technical capabilities that must be addressed and then enabled to complete a design for the problem domain. For our BYOD planning discussion, we’ll address the following subdomain and the technical capabilities within each of them:

  • Users and devices
    • Profiles
    • Devices
    • Network
  • Data Access and Protection

    • Storage
    • Network
    • Directory
    • Authentication
    • Authorization
    • Policy and Compliance
  • Management

    • Monitoring
    • Reporting
    • Compute
    • Storage
    • Automation
    • Deployment and Provisioning
  • Applications

    • Experience
    • Platform
    • Directory
    • Deployment
    • Storage
    • Network
    • Security

In this series, we’ll go over all of these and point out some key questions that you need to ask in order to determine your requirements for technical capabilities within each of the subdomains. By the time we’re finished, you should have a very clear idea of what you need your final design to support.

Summary

BYOD and the consumerization of IT is a two-pronged trend that enables users to use their own devices to perform work related activities from almost anywhere and at any time. It has advantages for both users and the company, but it also creates challenges, especially in the security realm. In order to prevent BYOD-related security breaches and potential catastrophic data losses that might cripple your company, you need to create a collection of policies that are enabled by your technical infrastructure.

In order to define the policies and design a technical infrastructure that will allow for safe and effective support for BYOD device access to corporate resources, you’ll need to perform a planning exercise that defines your requirements and then perform a design exercise that creates a design that solves the problems defined by your requirements. In the next article in this series, we’ll take a look at the questions you’ll need to ask within the user and devices subdomain.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.

Advertisement

Featured Links