Enabling a Mobile Workforce: Managing BYOD and Company-Owned Devices

Designing a strategy to enable a mobile workforce

This chapter has covered the factors that are driving enterprise mobility adoption and the core challenges you need to address when developing an enterprise mobility strategy. This section takes the elements shown in Figure 1-1 and explains how to use them to design an effective strategy to enable enterprise mobility.

Users

The first element is the user or employee. The user becomes a key element when companies start to move from a device-centric view to a user-centric view. Each user within your company has specific business needs; some have common business needs and some have unique business requirements. This part of the designing process is necessary to understand the user’s profile. This is accomplished by defining personas. The following list provides examples of typical user profiles:

• Executive This persona expects the company to buy them whatever device they want to use as their primary device. An Executive isn’t likely to be a BYOD user.
• Mobile worker This persona encompasses a large group of employees that are accustomed to using multiple devices.
• Technical/field worker This persona requires a robust device to perform their work. Usually, this type of user primarily accesses line of business (LOB) applications and email, and enters data into customer relationship management (CRM) tools.
• Deskbound information worker This persona uses a variety of devices and enrolls in the BYOD program. From taking notes in meetings on their own companion devices to potentially wanting to use their own machines while in the workplace, these users are likely to drive most of the BYOD adoptions in the company.
• Remote information worker This persona looks to optimize their workspace, blending personal priorities with company priorities. These users might be good candidates for the BYOD program.

Keep in mind that these are just some examples of user profiles for an enterprise. Different industries and business have different roles and requirements. It is important to identify the persona and comprehend the users’ needs based on their roles. You will identify these roles as part of the company self-assessment, which should be done before you start designing the enterprise mobility strategy.

You also need to consider the persona distribution, which is based on two elements: autonomy and mobility. Figure 1-5 shows the rationale behind the persona distribution. Receptionist

This persona distribution relates to the user’s work style and how the company can ensure that this user has what she needs to be productive. For example, some employees might always work at the same physical location (categorized as low mobility) while others might work at different branches, work from home, work from hotels, and so on (categorized as high mobility). The degree of autonomy is directly related to the balance between the freedom that the user needs to perform their business operations and the amount of restrictions added by the security policies.

Devices

Consider the type of devices that the company will allow. Access should be available from a broad set of device types, including managed devices, unmanaged devices, and consumer devices. Also, you should plan to include both Windows-based and non–Windows-based devices. Assuming your company will include a BYOD scenario, it is important to perform a survey of your employees to understand which devices they use and which operating systems they have installed on those devices.

When determining which devices will be supported by the company, carefully balance information security classification with the trustworthiness of the device and the point of connection. It is important to understand the device’s capabilities and define how those devices will access corporate information. The required capabilities of each device might vary according to the company’s security policy and business requirements. Figure 1-6 shows an example of some considerations regarding the device type and required capabilities. After you have defined the devices that will be supported, you need to define the required capabilities, such as data encryption, customization via policy, Mobile Device Management (MDM), and containerization.

It’s important for the IT department to understand if the devices that will be supported by the company have these capabilities. Once the device type is established, you need to define the access level that the device will have based on pre-established variables. User, device, location, and data can be used as variables to define the user’s experience when accessing corporate data. One variable, for example, can be the device’s location. Your company policy might allow full network access only for devices that are located on-premises. When the device is located on-premises, it will have one set of policies applied to it; if it is coming from the cloud, it will have a more restrictive policy. It is important to balance security with usability. You don’t want to enforce so much restriction that there is a negative effect on the user’s productivity. If you find the right balance, you will increase productivity. Figure 1-7 shows an example of some of these variables.

Using the diagram in Figure 1-7 as model, a sample policy can be defined as follows: if the device type is a Windows 8.1 phone and the device is located on-premises and it is trying to access an LOB application and the user has privileges to access that application, then the device should have full network access. Notice that each piece of the definition is connected to the next piece with “and,” which makes each part of the definition a test. By creating this test, all answers to these questions must be true in order to grant full network access. These tests can vary. For example, your company might choose to use “or” instead of “and,” which means only one requirement must be true to allow the device full access to the target resource.

Now that you have defined the key capabilities that are required by each device and the variables that will influence the user’s experience according to the device’s current state, the next important point to cover for the device is the supportability. If your company operates as a service provider, you could use a Service Level Agreement (SLA) to ensure that your users are aware of what to expect when they open an incident report with IT. An enterprise mobility strategy must include a plan to support the user’s device and also set the boundaries of this support. The fact is that not all devices will be treated equally and this will impact the supportability boundaries. This should be very clear not only to the IT team but to the user as well. By knowing what to expect from support, you mitigate the possibility of user frustration when that user opens an incident report and her device has limited support.

Apps

Although the industry tends to put more emphasis on devices, apps are the main gateway to information access. If your company doesn’t have mobile apps, embracing a mobile workforce won’t be very productive. As part of your design considerations, you must understand the current LOB applications that are used by your employees, how these apps will behave on the different operating systems that you are about to support, as well as the user’s skill level on each device that is approved by IT. When developing a strategy for apps, you must:

• Define which apps will be available for the users to consume using their devices
• Validate if those apps need any type of adjustment to correctly run on different platforms
• Perform a threat assessment on each app that will be available for mobile users and verify if there is any flaw that can lead to a security risk
• Mitigate potential flaws by fixing the root cause of the problem or adding countermeasures that can reduce the risk
• Verify how these apps will be available for user’s consumption from those different devices
• Enumerate the options that are feasible for your business to make those apps available (for example, deployment via web portal, access via remote app, access via VPN, and so on)

During this exercise, you will identify different gaps and each gap should be documented in detail. The output of this design consideration for apps might induce you to upgrade your server infrastructure to support this new model or adopt cloud-based apps for your mobile users.

Data

Remember, the CEO wants to enable users to be productive from anywhere, using the device of their choice, while keeping company data secure. The key to a successful enterprise mobility adoption is to allow users to consume company resources without compromising the data. The considerations regarding data protection should include:

• A security envelope to protect the data
• Safety net policies that control access and reporting
• An additional level of authentication, such as multifactor authentication
• Business-driven policies for data protection
• A classification of data according to sensitivity and business impact
• Access control to data based on identity and role
• Data encryption

You should understand how data can be protected on different platforms. Also, you should understand each platform’s capabilities so those capabilities can be leveraged to protect data. Some mobile platforms will use the principle of least privilege to protect and isolate data, such as the Windows Phone security model and its use of AppContainer as a secured isolation boundary.

While IT has full control over the data stored at the company’s data center, the same level of assurance can be a challenge with unmanaged BYOD devices. How data will be stored in users’ devices can directly impact how you choose to address data access and protection for enterprise mobility. Data encryption must be considered, and devices must allow IT to control when data encryption is enabled and for which types of data. Companies must review their policies and regulations to understand which types of data are allowed to leave the data-center and be at rest in remote devices’ storage.

Protecting the data is not enough; you must monitor how this data has been accessed so you can take measures to mitigate potential breaches. Part of you enterprise mobility strategy includes data governance. Choosing the right management platform to monitor your data access and take actions based on what you are able to find via reporting capabilities should be a very important decision point to your company. With the assumption that users can access data from anywhere, you must be vigilant to potential patterns that can help your company understand that an attack is in place.

Threat mitigation

After evaluating each element of your enterprise mobility strategy, you can now perform a threat modelling exercise to understand the interactions between each component and identify threats that might occur during those interactions that require mitigation. Using the core elements of Figure 1-1, you can determine who should be allowed to access the data. The first goal during threat mitigation is to reduce the attack surface by disallowing direct access to some of those elements. Figure 1-8 shows an example of the core elements of an enterprise mobility strategy. In the Before scenario, each element has direct access to the data. In the After scenario, direct access is limited to Apps only.

Another step of the threat mitigation process is to understand the risks on each interaction between these components. In Figure 1-8, for example, what risks are present when these apps have direct access to the data? You might conclude that the following actions must be performed:

• For apps to have access to data, the communication channel must be encrypted
• All mobile apps should be developed using a security development lifecycle
• Data at rest on the application server must be encrypted

To assist you through the process of understanding the risks of each interaction, you can leverage the Microsoft Threat Modeling Tool. Although this tool was created for another purpose, the rationale behind threat modeling is the same for interactions between the components of this model. Once you build the diagram and the data flows through the components, you can generate a report that will highlight the potential threats that must be mitigated. Figure 1-9 shows an example of this report.

This report also categorizes the threats according to priorities, which can also help you understand which threats should be addressed first. When you finish this designing process for enterprise mobility, you should have:

• A full understanding of how your company will benefit from the adoption of enterprise mobility
• A vendor-agnostic design of your enterprise mobility solution
• A threat mitigation report with core points that must be addressed during the implementation
• A list of requirements that must be met by the vendor