NIST SP 1800-4: Mobile Device Security: Cloud and Hybrid Builds

NIST SPECIAL PUBLICATION 1800-4

Mobile Device Security Cloud and Hybrid Builds Includes Executive Summary (A); Approach, Architecture, and Security Characteristics (B); and How-To Guides (C)

Joshua Franklin Kevin Bowler Christopher Brown Spike E. Dog Sallie Edwards Neil McNab Matthew Steele

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4

The original draft of this publication is available free of charge from: https://www.nccoe.nist.gov/projects/building-blocks/mobile-device-security/cloud-hybrid

NIST SPECIAL PUBLICATION 1800-4

Mobile Device Security: Cloud and Hybrid Builds Includes Executive Summary (A); Approach, Architecture, and Security Characteristics (B); and How-To Guides (C)

Joshua Franklin National Institute of Standards and Technology Information Technology Laboratory Kevin Bowler Christopher Brown Spike E. Dog Sallie Edwards Neil McNab Matthew Steele The MITRE Corporation McLean, VA

February 2019

U.S. Department of Commerce Wilbur Ross, Secretary National Institute of Standards and Technology Walter G. Copan, Undersecretary of Commerce for Standards and Technology and Director

NIST SPECIAL PUBLICATION 1800-4A

Mobile Device Security Cloud and Hybrid Builds Volume A: Executive Summary

Joshua Franklin National Institute of Standards and Technology Information Technology Laboratory

Kevin Bowler Christopher Brown Spike E. Dog Sallie Edwards Neil McNab Matthew Steele The MITRE Corporation McLean, VA

February 2019 This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4 The original draft of this publication is available free of charge from: https://www.nccoe.nist.gov/projects/building-blocks/mobile-device-security/cloud-hybrid

Executive Summary This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

◼

Adopting mobile devices without the necessary policies and management infrastructure in place increases the opportunities for attackers to breach sensitive enterprise data.

◼

The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST) developed example mobile device and enterprise mobility management solutions that organizations can use to reduce the likelihood of a data breach.

◼

The security characteristics in this guide are informed by guidance and best practices from standards organizations.

◼

The NCCoEʼs approach uses commercially available products that can be included alongside your current products in your existing infrastructure.

◼

The example solutions are packaged as a “how to” guide that demonstrates implementation of standards-based, commercially available cybersecurity technologies in the real world. The guide helps organizations utilize technologies to reduce the risk of intrusion via mobile devices while saving them research and proof of concept costs.

CHALLENGE Information technology (IT) environments have changed drastically because of the increasing popularity of smartphones, tablets, and other highly capable, rapidly maturing mobile devices. These devices have many functional similarities to traditional IT systems — including access to a wide range of enterprise applications and data, as well as additional functionality particular to mobile computing. This has greatly expanded the utility and value of mobile devices, enabling employees to do their jobs more effectively and efficiently. Unfortunately, security controls have not kept pace with the security risks that mobile devices can pose, not only in bring your own device (BYOD) scenarios but also in corporately owned and personally enabled (COPE) mobile device deployments, where mobile devices are adopted on an ad hoc basis. This gap in protection mechanisms means that data stored on or accessed from mobile devices is at increased risk of being breached. For example, suppose that an organization has enabled mobile access to its email, calendaring, and contact management services regardless of the origin of the employeesʼ mobile devices (organizationowned and employee-owned, organization-provisioned and employee-provisioned, etc.). If sensitive data is stored on a poorly secured mobile device that is lost or stolen, an attacker may be able to readily gain unauthorized access to that data. Even worse, a mobile device with remote access to sensitive organizational data could be leveraged by an attacker to gain unauthorized access to not only that data but also any other data that the user can access from a mobile device.

SOLUTION The NIST cybersecurity practice guide Mobile Device Security: Cloud and Hybrid Builds demonstrates how commercially available technologies can meet your organization's needs to secure sensitive enterprise data accessed by and/or stored on employees' mobile devices. In our lab at the NCCoE, part of the National Institute of Standards and Technology (NIST), we built an environment based on typical mobile devices and an enterprise email, calendaring, and contact management solution. NIST SP 1800-4A: Mobile Device Security

2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

We demonstrate how security can be supported throughout the mobile device life cycle. This includes how to configure a device to be trusted by the organization, how to maintain adequate separation between the organization’s data and the employee’s personal data stored on or accessed from the mobile device, and how to handle de-provisioning a mobile device that should no longer have enterprise access (e.g., device lost or stolen, employee leaves the company). This guide… ◼

identifies the security characteristics needed to sufficiently reduce the risks from mobile devices storing or accessing sensitive enterprise data

◼

maps security characteristics to standards and best practices from NIST and other organizations

◼

describes two detailed example solutions, along with instructions for implementers and security engineers on installing, configuring, and integrating the solutions into existing information technology (IT) infrastructures

◼

selects mobile devices and enterprise mobility management systems that meet the identified security characteristics

◼

provides example solutions that are suitable for organizations of all sizes, and evaluates those solutions3

While the NCCoE used a suite of commercial products to address this challenge, this guide does not endorse these particular products, nor does it guarantee compliance with any regulatory initiatives. Your organization’s information security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a solution.

BENEFITS The NCCoE’s practice guide to Mobile Device Security: Cloud and Hybrid Builds can help your organization… ◼

reduce risk so that employees can access the necessary enterprise data from nearly any location, over any network, by using a wide variety of mobile devices

◼

enable the use of BYOD, COPE, and other mobile device deployment models, which may provide cost savings and increased flexibility for organizations

◼

leverage cloud services to secure sensitive corporate data that uses the latest industry best practices and defense-in-depth security strategies, which may reduce infrastructure costs for organizations

◼

enable identity federation between an on-premise identity store and associated cloud services, which may improve user experience and enhance enterprise security

◼

enhance visibility for system administrators into mobile security events, quickly providing notification and identification of device and data compromise

◼

implement industry standard mobile security controls, reducing long-term costs and decreasing the risk of vendor lock-in

NIST SP 1800-4A: Mobile Device Security

3

SHARE YOUR FEEDBACK

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

You can view or download the guide at https://www.nccoe.nist.gov/projects/building-blocks/mobiledevice-security/cloud-hybrid. Help the NCCoE make this guide better by sharing your thoughts with us as you read the guide. If you adopt this solution for your own organization, please share your experience and advice with us. We recognize that technical solutions alone will not fully enable the benefits of our solution, so we encourage organizations to share lessons learned and best practices for transforming the processes associated with implementing this guide. To provide comments or to learn more by arranging a demonstration of this example implementation, contact the NCCoE at mobile-nccoe@nist.gov.

TECHNOLOGY PARTNERS/COLLABORATORS Organizations participating in this project submitted their capabilities in response to an open call in the Federal Register for all sources of relevant security capabilities from academia and industry (vendors and integrators). The following respondents with relevant capabilities or product components (identified as “Technology Partners/Collaborators” herein) signed a Cooperative Research and Development Agreement (CRADA) to collaborate with NIST in a consortium to build this example implementation.

Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose. The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity challenges. Through this collaboration, the NCCoE develops modular, easily adaptable example cybersecurity solutions demonstrating how to apply standards and best practices using commercially available technology.

NIST SP 1800-4A: Mobile Device Security

LEARN MORE Visit http://nccoe.nist.gov nccoe@nist.gov 301-975-0200

4

NIST SPECIAL PUBLICATION 1800-4B

Mobile Device Security Cloud and Hybrid Builds Volume B: Approach, Architecture, and Security Characteristics

Joshua Franklin National Institute of Standards and Technology Information Technology Laboratory

Kevin Bowler Christopher Brown Spike E. Dog Sallie Edwards Neil McNab Matthew Steele The MITRE Corporation McLean, VA

February 2019 This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4 The original draft of this publication is available free of charge from: https://www.nccoe.nist.gov/projects/building-blocks/mobile-device-security/cloud-hybrid

DISCLAIMER Certain commercial entities, equipment, products, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST or NCCoE, nor is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

National Institute of Standards and Technology Special Publication 1800-4B, Natl. Inst. Stand. Technol. Spec. Publ. 1800-4B, 61 pages, February 2019, CODEN: NSPUE2

FEEDBACK As a private-public partnership, we are always seeking feedback on our Practice Guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at mobile-nccoe@nist.gov.

National Cybersecurity Center of Excellence National Institute of Standards and Technology 100 Bureau Drive Mailstop 2002 Gaithersburg, MD 20899 Email: nccoe@nist.gov

NIST SP 1800-4B: Mobile Device Security

i

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners — from Fortune 50 market leaders to smaller companies specializing in IT security — the NCCoE applies standards and best practices to develop modular, easily adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to recreate the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Md. To learn more about the NCCoE, visit https://nccoe.nist.gov. To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align more easily with relevant standards and best practices and provide users with the materials lists, configuration files, and other information they need to implement a similar approach. The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

ABSTRACT This document proposes a reference design on how to architect enterprise-class protection for mobile devices accessing corporate resources. The example solutions presented here can be used by any organization implementing an enterprise mobility management solution. This project contains two distinct builds: cloud and hybrid. The cloud build makes use of cloud-based services and solutions, while the hybrid build achieves the same functionality but hosts the data and services within an enterpriseʼs own infrastructure. The example solutions and architectures presented here are based upon standardsbased, commercially available products.

KEYWORDS mobile; mobile device; mobile device management; mobility management; mobile security

NIST SP 1800-4B: Mobile Device Security

ii

ACKNOWLEDGMENTS We are grateful to the following individuals for their generous contributions of expertise and time.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Name

Organization

Rick Engle

Microsoft

Kevin Fiftel

Intel

Paul Fox

Microsoft

Steve Kruse

Symantec

Tim LeMaster

Lookout

Nate Lesser

NIST National Cybersecurity Center of Excellence

Adam Madlin

Symantec

Kevin McPeak

Symantec

Rene Peralta

Microsoft

Atul Shah

Microsoft

Steve Taylor

Intel

NIST SP 1800-4B: Mobile Device Security

iii

The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build the example solutions. We worked with:

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Technology Partner/Collaborator

Build Involvement

Intel

Lenovo Miix 2.8 Mobile Device

Lookout

Enterprise Mobility Management Application

Microsoft

Microsoft Cloud Service, Company Portal, Intune, Office 365 Enterprise E3, Outlook & Community Portal Mobile Applications, System Center 2012 R2 Configuration Manager SP1, Windows Phone OS

Symantec

X.509 Certificate

NIST SP 1800-4B: Mobile Device Security

iv

Contents

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3.4.1

Threats ..........................................................................................................................7

3.4.2

Vulnerabilities ...............................................................................................................8

3.4.3

Risk ................................................................................................................................9

3.4.4

Security Control Map ....................................................................................................9

4.1.1

Cloud Architecture Benefits ........................................................................................20

4.1.2

Cloud Build Security Characteristics ...........................................................................21

4.2.1

Hybrid Architecture Benefits ......................................................................................24

4.2.2

Hybrid Build Security Characteristics ..........................................................................25

4.3.1

Default Policies ...........................................................................................................25

NIST SP 1800-4B: Mobile Device Security

v

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6.3.1

Data Protection ...........................................................................................................42

6.3.2

Data Isolation ..............................................................................................................42

6.3.3

Device Integrity ...........................................................................................................42

6.3.4

Monitoring ..................................................................................................................43

6.3.5

Identity and Authorization ..........................................................................................43

NIST SP 1800-4B: Mobile Device Security

vi

List of Figures Figure 3-1 Mobile Technology Stack....................................................................................................8 Figure 4-1 Cloud Build Architecture .................................................................................................. 20 Figure 4-2 Hybrid Build Architecture ................................................................................................. 22

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Figure 5-1 Android Workflow ........................................................................................................... 35 Figure 5-2 iOS Workflow................................................................................................................... 36 Figure 5-3 Windows Phone Workflow ............................................................................................... 37

List of Tables Table 3-1 Security Characteristic Standards Mapping (Data Protection) ............................................. 10 Table 3-2 Security Characteristic Standards Mapping (Data Isolation) ................................................ 10 Table 3-3 Security Characteristic Standards Mapping (Device Integrity) ............................................. 11 Table 3-4 Security Characteristic Standards Mapping (Monitoring) .................................................... 12 Table 3-5 Security Characteristic Standards Mapping (Identity and Authorization) ............................. 13 Table 3-6 Security Characteristic Standards Mapping (Privacy) .......................................................... 13 Table 3-7 Technology Security Characteristic Mapping ...................................................................... 14 Table 4-1 Legend for Hybrid Build Architecture Diagram ................................................................... 23 Table 4-2 SP 800-124 Mapping to Security Characteristic ................................................................... 26 Table 6-1 Cybersecurity Framework Subcategory Evaluation ............................................................. 40

NIST SP 1800-4B: Mobile Device Security

vii

1 Summary

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide addresses the challenge of securely deploying and managing mobile devices in an enterprise. In many organizations, mobile devices are adopted on an ad hoc basis, possibly without the appropriate policies and infrastructure to manage and secure the enterprise data they process and store. Introducing devices in this fashion increases the attack surface of an enterprise, requiring that additional controls be implemented to reduce the risk of intrusion. The NIST SP 1800-4 series of documents contains… ▪ descriptions of a mobile device deployment alongside an associated enterprise mobility management (EMM) system to implement a set of security characteristics and capabilities, along with a rationale for doing so ▪ a series of How-To Guides — including installation and configuration of the necessary services — showing system administrators and security engineers how to achieve similar outcomes The solutions and architectures presented are built upon standards-based, commercially available products and can be used by any organization deploying mobile devices in the enterprise that is willing to have at least part of the solution hosted within a public cloud. This project contains two distinct builds: cloud and hybrid. The cloud build uses cloud-based data storage and management services for mobile devices, while the hybrid build achieves the same functionality as the cloud build but hosts a portion of the data, services, and physical equipment within an enterprise’s own infrastructure.

1.1 The Challenge Mobile devices allow an organization’s users to access information resources wherever they are and whenever they need. This presents both opportunities and challenges. The constant internet access available via a mobile device’s cellular and Wi-Fi connections has the potential to make business practices more efficient and effective, but it can be challenging to ensure the confidentiality, integrity, and availability of the information that a mobile device accesses, stores, and processes. As mobile technologies mature, users increasingly want to use both organization-issued and personally owned mobile devices to access enterprise services, data, and other resources to perform work-related activities. Despite the increased security risks posed by the coexistence of enterprise data with personally owned devices, organizations are under pressure to accept them due to several factors, including anticipated cost savings, increased productivity, and users’ demand for more convenience.

1.2 The Solution This NIST Cybersecurity Practice Guide demonstrates how commercially available technologies can enable secure access to the organization’s sensitive email, contacts, and calendar information from users’ mobile devices. In our lab at the National Cybersecurity Center of Excellence (NCCoE) at NIST, we built an environment to simulate a lightweight enterprise architecture, including common components present in most organizations such as directory services. Our approach to mobile device security (MDS) includes…

NIST SP 1800-4B: Mobile Device Security

1

▪ determining the security characteristics required to mitigate in large part the risks of storing enterprise data on mobile devices and transmitting enterprise data to and from mobile devices ▪ mapping security characteristics to standards and best practices from NIST and other organizations recognized for promulgating security information, such as the National Security Agency (NSA) and the Defense Information Systems Agency

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ architecting a design for our example solutions ▪ selecting mobile devices and EMM systems that provide the necessary controls ▪ evaluating our example solutions Although corporately owned, personally enabled (COPE) and bring your own device (BYOD) scenarios are not specifically addressed by this project, the necessary features to enable a secure demonstration of either scenario are available. Those making information technology (IT) policy and infrastructure decisions within an organization will need to use their own judgment to decide where on the device management spectrum they choose to exist. To make these security controls available, organizations must securely configure and implement each layer of the technology stack, including mobile hardware, firmware, operating system (OS), management agent, and the applications used to accomplish business objectives. This document provides but one method of accomplishing this task.

1.3 Benefits Our proposed solutions provide the following value to organizations: ▪ reduce risk so that employees are able to access the necessary enterprise data from nearly any location, over any network, when using a wide variety of mobile devices ▪ enable the use of BYOD, COPE, and other mobile device deployment models, which may provide cost savings and increased flexibility for organizations ▪ enhance visibility for system administrators into mobile security events, quickly providing notification and identification of device and data compromise ▪ implement industry standard mobile security controls, reducing long-term costs and decreasing the risk of vendor lock-in

2 How to Use This Guide This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design and provides users with the information they need to replicate this approach to mobile security. This reference design is modular and can be deployed in whole or in part. Before implementing this guide, readers may also want to review other mobile security efforts such as those from the National Information Assurance Partnership (NIAP), the U.S. Government Chief Information Officer (CIO) Council, and the Open Web Application Security Project. This guide contains three volumes:

NIST SP 1800-4B: Mobile Device Security

2

▪ NIST SP 1800-4A: Executive Summary ▪ NIST SP 1800-4B: Approach, Architecture, and Security Characteristics — what we built and why (you are here) ▪ NIST SP 1800-4C: How-To Guides — instructions for building the example solution Depending on your role in your organization, you might use this guide in different ways:

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Business decision makers, including chief security and technology officers, will be interested in the Executive Summary, NIST SP 1800-4A, which describes the following topics: ▪ challenges enterprises face in implementing and using mobile devices ▪ example solutions built at the NCCoE ▪ benefits of adopting the example solutions Technology or security program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in this part of the guide, NIST SP 1800-4B, which describes what we did and why. The following sections will be of particular interest: ▪ Section 3.4.3, Risk, which provides a description of the risk analysis we performed ▪ Section 3.4.4, Security Control Map, which maps the security characteristics of this example solution to cybersecurity standards and best practices You might share the Executive Summary, NIST SP 1800-4A, with your leadership team to help them understand the importance of adopting standards-based access management approaches to protect your organization’s mobile and digital assets. IT professionals who want to implement an approach like this will find the entire practice guide useful. You can use the How-To portion of the guide, NIST SP 1800-4C, to replicate all or parts of the build created in our lab. The How-To guide provides specific product installation, configuration, and integration instructions for implementing the example solutions. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products in our environment to create an example solution. This guide assumes that IT professionals have experience implementing security products within the enterprise. Although we have used a suite of commercial products to address this challenge, this guide does not endorse these particular products. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a mobile device management solution. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope that you will seek products that are congruent with applicable standards and best practices. Section 3.5, Technologies, lists the products we used and maps them to the cybersecurity controls provided by the reference solutions. A NIST Cybersecurity Practice Guide does not describe “the” solution, but a possible solution. Comments, suggestions, and success stories will improve subsequent versions of this guide. Please contribute your thoughts to mobile-nccoe@nist.gov.

NIST SP 1800-4B: Mobile Device Security

3

2.1 Typographic Conventions The following table presents typographic conventions used in this volume. Typeface/ Symbol

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Meaning

Example

Italics

file names and path names; references to documents that are not hyperlinks; new terms; and placeholders

For detailed definitions of terms, see the NCCoE Glossary.

Bold

names of menus, options, command buttons, and fields

Choose File > Edit.

Monospace

command-line input, on-screen computer output, sample code examples, and status codes

mkdir

Monospace Bold

command-line user input contrasted with computer output

service sshd start

blue text

link to other parts of the document, a web URL, or an email address

All publications from NIST’s NCCoE are available at https://nccoe.nist.gov/.

3 Approach Enterprises traditionally established boundaries to separate their trusted internal IT network(s) from untrusted external networks. When enterprise users consume and generate enterprise data on mobile devices, this traditional boundary erodes. Due to the rapid changes in today’s mobile platforms, enterprises have the challenge of ensuring that mobile devices connected to their networks can be trusted to protect sensitive data as it is stored, processed, and transmitted while still giving users the features they have come to expect from mobile devices. Additionally, some enterprises host enterprise data in a public cloud infrastructure, which also needs to be protected. This guide proposes a system of commercially available technologies that provides enterprise-class protection for mobile platforms accessing and interacting with enterprise resources. The implementations presented here can be used by any organization interested in implementing an EMM solution. This project contains two distinct builds: one focuses on cloud-based data, management, and services; the other leverages the same EMM infrastructure in-house. The cloud build may be useful to smaller organizations wanting to rapidly deploy a mobile solution or offload services hosted in-house to the

NIST SP 1800-4B: Mobile Device Security

4

cloud. The hybrid build uses the same services as the cloud build but hosts services and data on site within an organization’s premises.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

When conceptualizing the project, the project team looked to EMM systems deployed by industry. Users were sometimes frustrated with policies pushed from enterprises, and system administrators were confused about the most appropriate policies to push to mobile devices. This information was the impetus for creating the scenarios included in the building block definition document [1]. A number of security characteristics and capabilities are documented within the building block definition. We analyzed the content and concepts from multiple standards to generate the necessary security characteristics. These include NIST Special Publication (SP) 800-124, Guidelines for Managing the Security of Mobile Devices in the Enterprise [2]; NIST SP 800-164 (DRAFT), Guidelines on HardwareRooted Security in Mobile Devices [3]; NSA mobile access capability package [4] and the appropriate NIAP protection profiles [5], [6], [7].

3.1 Audience The cloud build is geared toward organizations wanting to operate and maintain systems external to their enterprise environment to lower operational expenses. These organizations elect to leverage a software as a service cloud provider for services such as office productivity tools for workstations. The addition of mobile devices into this environment adds complexity because the organization requires protection of its sensitive data, but this data is not under its direct control. The hybrid build is meant for organizations that are concerned with the risks associated with storing and processing confidential enterprise information in the cloud. These organizations have the willingness and technical expertise to implement and manage the necessary infrastructure to host the services on premises and may need to prevent cloud-based authentication and not wish to expose their existing identity repository to the cloud. The hybrid build includes a combination of enterprise assets likely to be present in an organization’s existing network and adds cloud services for EMM, making it a starting point for an organization that has significant investment in or dependence on an internal Active Directory (AD) server.

3.2 Scope This publication seeks to assist organizations in developing and implementing sound EMM deployments for securely accessing email, contacts, and calendaring. It provides practical, real-world guidance on developing, implementing, and maintaining secure, effective mobile devices, mobile applications, and EMM solutions in an enterprise. The publication presents EMM technologies from a high-level viewpoint and then provides a step-by-step guide to implementing a specific solution. The OSes and applications storing and transmitting the data must be securely configured and implemented. The EMM used within this build accomplishes this by sending policies to the mobile device and enforcing these policies by leveraging the device’s OS protections. The problem statement for this building block [1] describes a large number of security and functional characteristics and capabilities. It is important to note that this document does not employ each and every one of them. For instance, topics such as mobile application vetting, privacy, continuous

NIST SP 1800-4B: Mobile Device Security

5

monitoring, and comprehensive security testing of our build are important complementary steps to securing devices in an enterprise but are out of scope for this phase of the building block. The specific security characteristics and capabilities used in the cloud and hybrid builds are noted later in Section 4.3. The scope of these two builds demonstrates the following objectives: ▪ secure implementation of email, contacts, and calendaring

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ installation, implementation, and configuration of an EMM system ▪ hardened mobile devices securely accessing enterprise data for which the user and device are authorized Privacy issues can be complex and difficult to implement, particularly since these issues often span a broad range of topics, from law and policy to technology. Although privacy protections are listed within our desired capabilities, these goals are out of scope for this publication and will be addressed in subsequent efforts. In the meantime, organizations may want to follow a more comprehensive privacy engineering effort to satisfy these goals, such as National Institute of Standards and Technology Internal Report 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems [8]. Finally, the breadth of technologies in this building block was intentionally limited to organizations that have entered into a National Cybersecurity Excellence Partnership (NCEP) with the NCCoE, meaning that only NCEP partners of the NCCoE were allowed to participate in the build phase of this project. We anticipate significantly expanding on the technologies used within the next phase of this MDS project by leveraging Cooperative Research and Development Agreements (CRADAs) with other interested collaborators. Organizations wishing to participate in future efforts should visit the NCCoE’s website for more information about participating.

3.3 Assumptions The following assumptions exist for this project: ▪ Both the cloud and hybrid builds are highly dependent on Microsoft’s cloud platform, including Microsoft Office 365 and Microsoft Intune. Organizations trust these services to function properly and to appropriately handle sensitive information ▪ Organizations manage their own domains with the ability to alter Domain Name System (DNS) information on an ad hoc basis to prove ownership of a DNS name space so it can be associated to Office 365 services, email authority, mail exchanger records, and establishment of federation services ▪ Within the hybrid build, organizations place a system outside a perimeter firewall that proxies the connection between their Active Directory Domain Services and Microsoftʼs cloud services ▪ Organizations trust the mobile OSes within this build (e.g., Android, iOS, Windows) to store and process sensitive information

3.4 Risk Assessment NIST Special Publication (SP) 800-30, Guide for Conducting Risk Assessments, states that risk is “a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs and NIST SP 1800-4B: Mobile Device Security

6

(ii) the likelihood of occurrence.” The guide further defines risk assessment as “the process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place.”

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The NCCoE recommends that any discussion of risk management, particularly at the enterprise level, begins with a comprehensive review of NIST 800-39, Managing Information Security Risk [9], which is freely available to the public. NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems [10], proved invaluable in giving us a baseline to assess risks, from which we developed the project, the security characteristics of the build, and this guide. The nature of mobile devices creates a set of unique risks in the modern enterprise. Future phases of this guide will include a NIST SP 800-30 based risk assessment, but it is currently out of scope for this effort. However, it is useful to highlight broad categories of threats and vulnerabilities. We have used NIST SP 800-124 [2]; NIST SP 800-163 [11]; and the United States Computer Emergency Readiness Team (US-CERT) Technical Information Paper-TIP-10-105-01, Cyber Threats to Mobile Devices [12], as sources for this section, which is not an exhaustive list of threats to mobile devices. Although this practice guide focuses only on the threats and vulnerabilities related to the mobile device, readers should also consider broader threats to services that provide mobile device management (MDM) capabilities while assessing risk. Additional consideration should be given to threats posed from cloud services and the mobile ecosystem supporting the device. Cloud MDM services that leverage the Federal Risk and Authorization Management Program (FedRAMP), for example, can increase confidence in the security of these solutions with consistent security authorizations using a baseline set of agreed-upon standards [13]. To further address comments received in the public comment period of 1800-4, Mobile Device Security: Cloud and Hybrid Builds draft publication, the NCCoE Mobile Device Security Project team has produced National Institute of Standards and Technology Interagency Report 8144, Assessing Threats to Mobile Devices & Infrastructure. This publication accompanies the Mobile Threat Catalogue, which describes, identifies, and structures the threats posed to mobile information systems. We received many comments with a common theme that the example architectures in 1800-4 did not address the entire mobile security ecosystem. We encourage readers to review National Institute of Standards and Technology Interagency Report 8144 and the Mobile Threat Catalogue to assist in developing risk assessments, building threat models, enumerating the attack surface of their mobile infrastructure, and identifying mitigations for their mobile deployments.

3.4.1 Threats Below are common threats to mobile devices:

NIST SP 1800-4B: Mobile Device Security

7

▪ mobile malware ▪ social engineers ▪ stolen data due to loss, theft, or disposal ▪ unauthorized access

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ electronic eavesdropping ▪ electronic tracking ▪ access to data by legitimate third-party applications

3.4.2 Vulnerabilities Vulnerabilities are commonly associated with applications that are installed on mobile devices. However, it is important to recognize that vulnerabilities can be exploited at all levels in the mobile device stack, which is outlined below in Figure 3-1. Figure 3-1 Mobile Technology Stack

Applications that can be exploited can come from various sources — they may be installed by the device owner, preinstalled by a mobile network operator (i.e., carrier), or natively bundled with the OS. Although carrier and bundled applications can add valuable functionality to the device, the attack surface is also broadened. Further, carrier-installed applications can be particularly troublesome because they can be difficult to remove. Applications may be intentionally malicious, particularly those installed by the device owner. Mobile applications specifically developed to do harm to a device are categorized as mobile malware and often exploit design flaws or vulnerabilities in the mobile OS to achieve malicious design goals. Note that on mobile devices, the firmware and hardware levels are not as clearly defined as Figure 3-1 depicts. Mobile devices with access to a cellular network contain a baseband processor comprising a distinct telephony subsystem used solely for telephony services (e.g., voice calls, texts, data transfer via the cellular network) [14]. This processor and the associated software/firmware on which it operates NIST SP 1800-4B: Mobile Device Security

8

are separated from the mobile OS running on the application processor. Furthermore, some mobile devices contain additional security-specific hardware and firmware used to assist with making security decisions and storing important information, such as encryption keys, certificates, and credentials [15], [16], [17].

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

For up-to-date information regarding vulnerabilities, we recommend that security professionals leverage the National Vulnerability Database (NVD). The NVD is the U.S. government repository of standardsbased vulnerability management data [18].

3.4.3 Risk Using the common threats identified previously as a guide, we identified risks that an organization might face when deploying mobile devices. In general, these risks focus on data leakage and compromise. Because modern mobile devices process many types of information (e.g., personal, enterprise, financial, medical), there are many types of data leakages, each with its own level of severity in a given context. The following are potential reasons for data leakage and/or compromise: ▪ lack of mobile access control (e.g., loss of the mobile device, lock screen protection, enabling smudge attacks) ▪ lack of confidentiality protection (e.g., encryption of data in transit) of information due to operating on unsafe or untrusted networks (e.g., Wi-Fi, cellular) ▪ unpatched firmware, OS, or application software bypassing the OS security architecture (e.g., rooted/jailbroken device) ▪ users running malicious mobile applications which may glean information via misuse of interprocess communication or other access control mechanisms ▪ device interaction with cloud services outside corporate control ▪ misuse or misconfiguration of location services, such as global positioning system ▪ acceptance of fake mobility management profiles, providing malicious actors with a high degree of device control ▪ social engineering via voice, short message service /multimedia messaging service, third-party text communication, or email communication

3.4.4 Security Control Map Using this risk information, NCCoE engineers identified the security characteristics of the solution. Table 3-1 through Table 3-6 map these characteristics to the Subcategories from the NIST Cybersecurity Framework [19], NIST SP 800-53 Revision 4 [20], International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) 27002 [21], and the Council on CyberSecurityʼs Critical Security Controls for Effective Cyber Defense [22]. Note: Before transfer to the Council on Cybersecurity, [22] was informally known as the Sysadmin, Audit, Networking, and Security Consensus Audit Guidelines (CAG) 20. The following tables identify security characteristic standards mappings for data protection, data isolation, device integrity, monitoring, identity and authorization, and privacy. For more information on each of these, reference Section 6. NIST SP 1800-4B: Mobile Device Security

9

Table 3-1 Security Characteristic Standards Mapping (Data Protection) Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

device encryption

PR.AC-3, PR.DS-1, PR.DS-5, PR.PT-2

application-level encryption

Security Characteristic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

IEC/ISO 27002

CAG 20

AC-19(5), MP-5(4), SC-13, SC-28(1)

6.2.1, 8.3.1, 10.1.1, 11.2.7, 18.1.5

CSC 17-1, CSC 17-2

PR.DS-1

SC-28(1)

6.2.1, 8.3.1, 10.1.1, 18.1.5

CSC 17-1, CSC 17-2, CSC 17-3

secure containers

ID.AM-3, PR.AC-4, PR.DS-1, PR.DS-3, PR.DS-5

AC-3, AC-3(8), AC4, MP-6(8), SC-13, SC-28(1)

6.2.1, 8.3.1, 9.4.1, 10.1.1, 18.1.5

CSC 15-4, CSC 15-5, CSC 17-1, CSC 17-2, CSC 17-3

trusted key storage

PR.DS-5, PR.PT-3

AC-3(5), SC-12, SC13, SC-3, SC-3(1)

10.1.1, 10.1.2, 14.1.3

CSC 12-13, CSC 1615, CSC 16-17

hardware security modules

PR.DS-1, PR.DS-5, PR.PT-3

IA-7, SC-3, SC-3(1), SC-34

10.1.1, 10.1.2, 18.1.5

CSC 17-15

remote wipe

PR.DS-1, PR.DS-3, PR.IP-6

MP-6(8), SC-28(1)

6.2.1, 8.1.2, 8.1.4, 8.3.2, 11.2.7

selective wipe

PR.DS-1, PR.DS-3, PR.IP-6

MP-6(8), SC-28(1)

6.2.1, 8.1.2, 8.1.4, 8.3.2, 11.2.7

automatic wipe

DE.AE-2, PR.DS-1, PR.DS-3, PR.IP-6

AC-7, AC-7(2), MP6(8), SC-28(1)

6.2.1, 8.1.2, 8.3.2, 11.2.7, 11.2.8

encrypted memory

PR.DS-1, PR.DS-5

SC-13, SC-28(1)

10.1.1

CSC 17-3

protected communications

PR.DS-2, PR.DS-5

SC-8, SC-8(1), SC13

9.1.2, 9.4.2, 10.1.1, 13.1.1, 13.2.1, 13.2.3, 14.1.3

CSC 3-7, CSC 7-6, CSC 15-4, CSC 1615, CSC 16-16, CSC 17-7

protected execution environments

PR.AC-4, PR.DS-5

AC-6(4), SC-11, SC3, SC-39, SC-39(1)

14.1.3

Table 3-2 Security Characteristic Standards Mapping (Data Isolation) Security Characteristic virtualization

Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

PR.AC-3, PR.AC-4, PR.AC-5

AC-20(3), AC-6(4), SC-7(21)

NIST SP 1800-4B: Mobile Device Security

IEC/ISO 27002

CAG 20

6.2.2

CSC 2-8

10

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

sandboxing

PR.AC-5, PR.DS-5

SC-39, SC-7(21)

memory isolation

PR.DS-5

SC-39

trusted execution

PR.DS-5

SA-13, SC-3, SC-11

14.1.3

device resource management

PR.AC-3, PR.AC-5, PR.DS-5, PR.IP-1

AC-4, AC-19, CM-2, SC-7(21)

6.1.2, 6.2.1, 9.1.2, 11.1.5, 13.2.1

CSC 3-1, CSC 7-5, CSC 7-8, CSC 7-9, CSC 11-1, CSC 17-8

data flow control

PR.DS-5

AC-4

6.2.1, 8.2.1, 8.2.3, 9.1.1, 9.4.1, 13.2.1

CSC 15-5

data tagging

ID.AM-3, PR.AC-4

AC-4(1), AC-16

8.2.1, 8.2.2

CSC 15-5

baseband isolation

PR.DS-5

SC-39, SC-39(1)

IEC/ISO 27002

CAG 20

Table 3-3 Security Characteristic Standards Mapping (Device Integrity) Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

IEC/ISO 27002

baseband integrity checks

PR.DS-6

SI-7, SI-7(1), SI-7(9)

12.2.1

application whitelisting/ blacklisting

DE.CM-3, PR.IP-1

CM-7(4), CM-7(5), CM-11

6.2.1, 12.2.1, 12.6.2

boot validation

PR.DS-6

SI-7, SI-7(6), SI-7(9), 12.2.1 SI-7(10), SI-7(12)

application verification

PR.DS-6

SI-7, SI-7(1), SI-7(6)

12.2.1

CSC 3-8

verified application and OS updates

PR.DS-6

SI-7, SI-7(1), SI-7(6)

12.2.1

CSC 3-8

mobile malware detection

DE.AE-2, DE.CM4, PR.PT-2

MP-7, SI-3, SI-3(2), SI-3(7), SI-4(7)

6.2.1, 12.2.1, 13.2.1

CSC 5-1, CSC 5-2, CSC 5-8

trusted integrity reports

PR.PT-1, PR.DS-6

AU-9, AU-9(3), IA3(4), SA-13, SI-7, SI7(1)

18.2.3

CSC 3-8, CSC 13-8

policy integrity verification

PR.DS-6

SI-7, SI-7(1), SI-7(6)

18.2.3

CSC 3-8

Security Characteristic

NIST SP 1800-4B: Mobile Device Security

CAG 20

CSC 2-1, CSC 2-2, CSC 6-1

11

Table 3-4 Security Characteristic Standards Mapping (Monitoring) Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

inventory of mobile device hardware, firmware, and software

ID.AM-1, ID.AM-2

asset management

Security Characteristic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

IEC/ISO 27002

CAG 20

CM-8, CM-8(2)

8.1.1, 8.3.1, 12.2.1, 12.6.1, 18.1.2

CSC 1-1, CSC 1-3, CSC 1-4, CSC 2-4, CSC 2-5

ID.RA-1, PR.AC-3, PR.IP-1

AC-19, CM-2, CM6, SC-43, SI-2

6.2.1, 8.1.1, 9.1.2, 11.2.8, 11.2.9, 12.1.1, 12.1.2, 12.5.1, 12.6.1, 12.6.2, 18.1.2

CSC 3-1, CSC 3-3, CSC 3-7, CSC 3-10, CSC 16-5, CSC 16-6, CSC 16-8, CSC 16-9

compliance checks

DE.CM-3, ID.AM3, ID.AM-4, PR.AC-3, PR.IP-1

AC-19, AC-20, AC20(1), CA-9, CA9(1), CM-6(1), CM6(2), CM-11(1)

12.1.2, 12.2.1, 18.2.3

CSC 2-3, CSC 3-1, CSC 7-1, CSC 13-8d

root and jailbreak detection

PR.DS-6

SI-7, SI-7(1), SI7(2), SI-7(6), SI7(9)

12.2.1

CSC 7-1, CSC 13-8

anomalous behavior detection

DE.AE-2, DE.CM-4

IA-10, SI-4, SI-4(5), SI-4(11), SI-4(24), SI-15

9.4.2, 12.2.1

CSC 5-8

auditing and logging

PR.PT-1, RS.AN-1

AU-2, AU-3, AU-8, AU-9, AU-12, IR-5

12.1.1, 12.4.1, 12.4.2, 12.4.3, 12.4.4, 12.7.1, 16.1.1

CSC 14-1, CSC 14-2

canned reports and ad hoc queries

PR.PT-1

AU-7, AU-7(1), AU7(2)

geofencing

DE.CM-7, ID.AM3, PR.AC-4, PR.AC5, PR.PT-1

AC-4AC-4(3), AC9.1.2 4(8), AC-6, CM-8(8)

NIST SP 1800-4B: Mobile Device Security

12

Table 3-5 Security Characteristic Standards Mapping (Identity and Authorization) Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

local authentication of user to device

PR.AC-4, PR.DS-5

local user authentication to applications

Security Characteristic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

IEC/ISO 27002

CAG 20

AC-3, IA-6

6.2.1, 9.3.1, 9.4.1, 9.4.2, 10.1.1

CSC 16-8

PR.AC-4, PR.DS-5

AC-3, IA-6

6.2.1, 9.1.1, 9.3.1, 9.4.1, 9.4.2, 10.1.1

CSC 16-8

remote user authentication

PR.AC-1, PR.AC-4, PR.DS-5

AC-3, AC-17, IA-2, IA-2(2), IA-2(11), IA-6

6.2.1, 9.1.1, 9.1.2, 9.3.1, 9.4.1, 9.4.2, 10.1.1, 13.1.1, 14.1.3

CSC 7-1, CSC 12-8, CSC 13-7, CSC 16-8, CSC 16-14

remote device authentication

PR.AC-1, PR.AC-3, PR.AC-4

AC-3, AC-17, AC19, IA-3, IA-3(1), IA-3(4)

6.2.1, 9.1.1, 9.4.1, 10.1.1, 13.1.1, 14.1.3

CSC 1-7, CSC 7-1, CSC 7-7, CSC 13-8

implementation of user and device roles for authorization

PR.AC-4

AC-3, AC-3(7), AC-6 6.2.1, 9.1.1

device provisioning and enrollment

ID.AM-1, PR.AC-3, PR.PT-1, PR.PT-2, PR.PT-3

AC-19, CM-7(3), CM-8(4), MP-5(3), MP-7(1)

6.2.1, 8.1.2, 8.1.4, 8.2.3, 8.3.1, 8.3.2, 9.2.2, 11.2.5

CSC 5-7, CSC 7-1, CSC 13-8

credential and token storage and use

PR.AC-1

IA-2, IA-2(10), IA2(11), IA-2(12), IA5, IA-5(1), IA-5(2), IA-5(4), IA-5(6), IA5(9), IA-5(10), IA5(11), IA-5(12), IA5(13)

9.2.3, 9.2.4, 9.3.1, 9.4.2, 10.1.1, 10.1.2, 14.1.3

CSC 1-7, CSC 12-13, CSC 12-12, CSC 168, CSC 16-14, CSC 16-15, CSC 16-16

Table 3-6 Security Characteristic Standards Mapping (Privacy)

Security Characteristic informed consent of user

Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

IEC/ISO 27002

ID.GV-3

AC-8, PS-6

8.1.3, 9.4.2

NIST SP 1800-4B: Mobile Device Security

13

Cybersecurity Framework Subcategory

NIST SP 800-53 rev4

data monitoring minimization

ID.GV-3

DM-1

custom privacy statement

ID.GV-3

TR-1

Security Characteristic

IEC/ISO 27002

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3.5 Technologies Following the draft publication of NIST SP 800-164 [2], NIST began looking for additional ways to foster mobile security in the enterprise. The three primary mobility security principles of NIST SP 800-164 (i.e., device integrity, isolation, and protected storage) were used as a baseline. Moving forward, NCCoE engineers used other standards and guidance relating to mobility to build upon these principles to create the full list of security characteristics and capabilities in Section 4.3. The initial document describing this projectʼs security challenge was released in 2014 [1]. After incorporating public comments and revising the document, the NCCoE MDS team consulted with the NCCoE’s NCEP partners to understand which technologies would be applicable to this project. The technologies used in this project are listed in Table 3-7. Note that this represents a best effort in reflecting how key security functions of each product can support an organization’s standards-based approach to cybersecurity risk management. These products may have additional security functions not represented here. Table 3-7 Technology Security Characteristic Mapping

Technology

Use

Product

EMM

Web service used to define and send policies to mobile devices

Microsoft Intune

NIST SP 1800-4B: Mobile Device Security

Cybersecurity Framework Subcategory DE.CM-3, ID.AM-1, ID.AM-2, ID.AM-3, ID.AM-4, ID-RA-1, PR.AC-3, PR.AC-4, PR.DS-3, PR.DS-6, PR.IP-1, PR.IP-6, PR.PT-1, PR.PT-2, PR.PT-3, RS.AN-1

NIST SP 800-53 Rev4 Controls AC-3, AC-6(1), AC-6(3), AC-17(2), AC-19, AU-2, AU-3, AU-7, AU-7(1), AU-7(2), AU-8, AU-9, AU-12, AC-20, AC-20(1), CA-9, CA-9(1), CM-2, CM-6, CM-6(1), CM6(2), CM-7, CM-7(3), CM-7(4), CM-7(5), CM8, CM-8(2), CM-8(4), CM-11, CM-11(1), IR-5, MP-5(3), MP-6(8), MP7(1), SC-8, SC-8(1), SI-2, SI-7(1), SI-7(2), SI-7(5)

14

Technology

Use

Product

Cybersecurity Framework Subcategory

NIST SP 800-53 Rev4 Controls

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Microsoft Office 365 MDM

ID.AM-1, ID.AM-2, ID.AM-3, ID.AM-4, ID.RA-1, PR.AC-3, PR.AC-4, PR.DS-3, PR.DS-6, PR.IP-1, PR.IP-6, PR.PT-1, PR.PT-2, PR.PT-3, RS.AN-1

AC-2, AC-3, AC-6(1), AC6(3), AC-17(2), AC-19, AC-20, AC-20(1), AU-2, AU-3, AU-7, AU-7(1), AU-8, AU-9, CA-9, CA9(1), CM-2, CM-6, CM6(1), CM-6(2), CM-7, CM-7(3), CM-8, CM8(2), CM-8(4), IR-5, MP5(3), MP-6(8), MP-7(1), SC-8, SC-8(1), SI-2, SI7(1), SI-7(2), SI-7(5)

Cloud Platform

Provides directory services and web-based productivity applications

Microsoft Office 365 Enterprise E3

PR.AC-1, PR.AC-4, PR.DS-2, PR.DS-5

AC-2, AC-3, AC-17, IA-2, IA-2(10), IA-5, IA-6, SC8, SC-8(1)

Federation Services

Allows service providers to authenticate users who are managed by a trusted identity provider

Microsoft Active Directory Federation Services

ID.GV-3, PR.AC-4, PR.DS-2

AC-17, AC-24(1), SC-8, SC-8(1), TR-1

Inventory and Configuration Management

Provides centralized IT asset inventory, configuration, and management

Microsoft System Center 2012 R2 Configuration Manager

DE.CM-3, ID.AM-1, ID.AM-2, ID.AM-4, ID.RA-1, PR.AC-3, PR.PT-1, PR.IP-1, RS.AN-1

AU-2, AU-3, AU-6, AU-7, AU-7(1), AU-7(2), AU-8, AU-9, AU-12, AC-19, AC20, AC-20(1), CM-2, CM5, CM-6, CM-6(1), CM6(2), CM-7(4), CM-7(5), CM-8, CM-8(2), CM8(4), CM-8(7), CM-11, CM-11(1), IR-5, SI-2

Mobile Device End Point Protection

Mobile malware detection and OS integrity verification

Lookout Mobile Threat Protection (MTP)

DE.CM-4, PR.AC-1, PR.DS-6, PR.IP-1, PR.PT-1, PR.PT-2, PR.PT-3

AU-2, AU-3, AU-6, AU7(2), AU-12, CM-6(2), CM-7(3), IA-2(13), MP7, SI-3(2), SI-3, SI-3(7), SI-7, SI-7(1), SI-7(2), SI7(5), SI-7(6)

NIST SP 1800-4B: Mobile Device Security

15

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Technology

Use

Product

Cybersecurity Framework Subcategory

Mobile Device

Provides remote access to organizational services and data

iPhone 6 (iOS 8.3), Motorola Nexus 6 (Android 5.1), Nokia Lumia 830 (Windows Phone 8.1)

DE.AE-1, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-5, PR.DS-1, PR.DS-2, PR.DS-3, PR.DS-5, PR.DS-6, PR.IP-1, PR.IP-6, PR.PT-2, PR.PT-3

AC-3, AC-3(5), AC-6(4), AC-7, AC-7(2), AC-19(5), CM-2, CM-5(3), IA-5, IA6, MP-5(4), MP-6, MP6(8), SA-13, SC-3, SC7(21), SC-3(1), SC-8, SC8(1), SC-11, SC-12, SC13, SC-17, SC-28, SC28(1), SC-3(1), SC-39, SC-39(1), SC-8(1), SI-7, SI-7(1), SI-7(6), SI-7(9), SI-7(10), SI-7(12)

Secure Protects the communications confidentiality protocol and integrity of data communicated between end points

Transport Layer Security (TLS)

PR.DS-2, PR.DS-5

SC-8, SC-8(1), SC-13

E-mail, contacts, and calendar application

Provides core business productivity

Microsoft Outlook Application

PR.AC-1, PR.DS-2, PR.DS-5

IA-6, SC-8, SC-8(1), SC13

MDM Agent

Client application with administrative control that enforces MDM policies on the device

Microsoft Company Portal Application

DE.CM-3, ID.GV-3, PR.AC-3, PR.AC-4, PR.AC-5, PR.DS-5, PR.IP-1, PR.IP-6

AC-3, AC-4, AC-19, CM2, CM-5, CM-6, CM-7(4), CM-7(5), CM-11, CM11(1), IA-6, SC-7(21), SC-8, SC-8(1), SI-7(1), SI7(2), SI-7(6)

Digital Certificate

Used for authentication of end points in federated services

Symantec Digital Certificate

PR.DS-5

SC-13

NIST SP 800-53 Rev4 Controls

The following mobile devices were used throughout this project:

NIST SP 1800-4B: Mobile Device Security

16

▪ Dell Venue 8 Pro (Intel) ▪ Lenovo Miix 2 (Intel) ▪ Nexus 6 ▪ Nokia Lumina 830

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ iPhone 6 ▪ Samsung Galaxy S5

4 Architecture This section documents the functional and network architectures of both the cloud and hybrid builds. Before continuing, it is useful to describe a notional EMM deployment. An EMM can consist of multiple services, including MDM, mobile application management (MAM), and other mobile computing services. Enterprises use EMMs to define a set of policies, push those policies to a mobile device, and then enforce these policies on a mobile device via an enforcement mechanism on the device (e.g., OS, mobile application). Before policies can be pushed to a given device, an enterprise must enroll that device into the management services. Once enrolled, policies, such as the requirement to use an eight-digit passcode, are defined and then pushed to the device via a secure communications channel. These processes and technologies enable users to work inside and outside the enterprise network with a securely configured mobile device with the following functional and security capabilities: ▪ Device encryption: cryptographic protection of all or portions of a device’s data storage locations to prevent unauthorized disclosure of enterprise data ▪ Application-level encryption: an alternative or additional layer of cryptographic protection applied only to application data to prevent unauthorized disclosure when device encryption is either undesirable or has been defeated ▪ Trusted key storage: protected locations in software, firmware, or hardware in which long-term cryptographic keys or secrets are safeguarded from unauthorized disclosure or modification ▪ Protected communications: strong cryptographic protection of data transmitted over untrusted networks to mitigate unauthorized disclosure or modification ▪ Remote wipe: action that prevents the unauthorized access of data stored on a lost or stolen device by rendering data recovery techniques infeasible ▪ Selective wipe: remote wipe that affects only enterprise data, leaving personal data intact; also occurs automatically as a consequence of a device user unenrolling their device from enterprise management ▪ Automatic wipe: action that reactively wipes all device data in response to multiple subsequent failed attempts to unlock a locked device, which may occur before the loss or theft of a mobile device is discovered ▪ Hardware security modules: embedded or removable tamper-resistant hardware used to perform cryptographic operations and provide secure storage to protect security operations or data from unauthorized access or modification

NIST SP 1800-4B: Mobile Device Security

17

▪ Sandboxing: OS or application-level virtualization, isolation, and integrity mechanisms utilizing multiple protection, isolation, and integrity capabilities to achieve higher levels of overall process isolation ▪ Memory isolation: OS-enforced separation of memory spaces allocated to running processes to protect their integrity, which secondarily protects the confidentiality, integrity, and availability of data in process

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ Trusted execution: protection of security processes within an isolated and trustworthy environment using distinct memory spaces and controlled interfaces to provide higher levels of isolation than memory isolation alone ▪ Device resource management: ability to selectively disable unused or unnecessary peripherals to prevent their abuse and preserve other resources (e.g., battery life, data limits) ▪ Application whitelisting/blacklisting: allowing or disallowing the use of applications based on a prespecified list to prevent the execution of malicious, vulnerable, or flawed applications ▪ Boot validation: integrity checks on the content of boot files and the execution of boot processes to verify the OS has been launched into a known-good and trustworthy state ▪ Application verification: integrity checks on application installation packages and validation of the digital signature to verify that applications come from a trusted source and have not been modified prior to installation ▪ Verified application and OS updates: application verification techniques, as above, are applied to application and OS update packages prior to execution ▪ Mobile malware detection: identification of malicious software on mobile platforms to facilitate remediation and limit their potential to cause harm ▪ Inventory of mobile device hardware and software: maintain version information for the hardware, firmware, OS, and installed applications on devices in order to respond effectively to discovered vulnerabilities ▪ Asset management: identify, configure, and maintain the security configuration of devices, components, software, and services residing on a network to reduce the potential for compromise ▪ Compliance checks: determine a device’s level of compliance with mandated security policies to prevent granting access to improperly configured and vulnerable devices ▪ Root and jailbreak detection: verification that the security architecture for a mobile device has not been compromised to prevent granting access to untrustworthy devices ▪ Auditing and logging: capture and store security events for devices, including enrollment, failed compliance checks, administrative actions, and unenrollment ▪ Canned reports and ad hoc queries: use preconfigured reports or active searches or filters on security logs to manage incidents and audit compliance ▪ Local authentication of user to device: require a user to provide a personal identification number (PIN), password, cryptographic token, or other authentication mechanism to prevent granting unauthorized access to sensitive device functionality or accessible data ▪ Local user authentication to applications: as above, but specific to an application

NIST SP 1800-4B: Mobile Device Security

18

▪ Remote user authentication: as above, but for networked applications that require successful authentication to a remote service before granting full access to its functionality and data ▪ Device provisioning and enrollment: identification and association of specific mobile devices with organizational user accounts to ensure that remote access is granted only to authorized users using approved devices

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ Custom privacy statement: inform users about the implications to privacy or changes to device functionality as a result of accepting organizational management of their personal device or remotely accessing enterprise resources This project installs, configures, and integrates two distinct MDMs from Microsoft: Office 365 (included in most Office 365 deployments) and Microsoft Intune. These MDMs offer varying levels of functionality — security and otherwise. The integration of the various technologies within these builds would be extremely difficult without the use of standards and best practices. The following standards are crucial to a successful implementation: ▪ NIST SP 800-124 Rev 1: Guidelines for Managing the Security of Mobile Devices in the Enterprise [2] ▪ NIST SP 800-164 (Draft): Guidelines on Hardware-Rooted Security in Mobile Devices [3] ▪ NIST SP 800-147: BIOS Protection Guidelines [23] ▪ NIST SP 800-155: BIOS Integrity Measurement Guidelines [24] ▪ NIST SP 800-88 Rev 1: Guidelines for Media Sanitization [25] ▪ NIST SP 800-163: Vetting the Security of Mobile Applications [11] ▪ NSA: Mobility Capability Package 2.3 [4] ▪ Department of Defense Commercial Mobile Device Implementation Plan [26] ▪ CIO Council: Government Mobile and Wireless Security Baseline [27] ▪ GSA Managed Mobility Program Request for Technical Capabilities [28] ▪ NIAP: Protection Profile for Mobile Device Management Version 1.1 [29] ▪ NIAP: Protection Profile for Mobile Device Fundamentals Version 2.0 [6] ▪ NIAP: Extended Package for Mobile Device Management Agents Version 2.0 [7] ▪ GlobalPlatform: specifications for Secure Element and Trusted Execution Environment [15], [16] ▪ Trusted Computing Group: specifications for Trusted Platform Module [17] Section 4.1, Cloud Build: Architecture Description and Section 4.2, Hybrid Build: Architecture Description describe the cloud and hybrid architectures, respectively, as well as their benefits and security features.

4.1 Cloud Build: Architecture Description The cloud build is intended to assist organizations wanting to leverage mobile devices and manage these devices via the cloud. These organizations may include entities needing to stand up mobile deployments with minimal effort and entities with established enterprise mobile deployments wanting to leverage NIST SP 1800-4B: Mobile Device Security

19

the benefits of cloud computing. This build can be quickly deployed within enterprises without an internal AD server. Although this build uses the MDM system included with Office 365, an organization could choose to leverage Intune instead in this instance. Office 365 was chosen to diversify the MDMs used within this project.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

This solution can be easily configured and operated as a cloud service to onboard personally or enterprise-owned mobile devices into the EMM, allowing users to access enterprise resources and enterprise managers to push policies to mobile devices. Office 365 allows for a variety of policies to be pushed to the device (detailed in Appendix C) but offers a significantly reduced feature set when compared with Microsoft Intune. Figure 4-1 provides the overall architecture of the cloud build. Figure 4-1 Cloud Build Architecture

Mobile devices communicate with Office 365 over a public communications network, which then accesses Microsoft’s mobile applications such as Word and Excel. System administrators manage devices via the Office 365 admin center. In order to make full use of cloud services, a globally recognized commercial domain is required. For test purposes, the NCCoE acquired cmdsbb.org (CMDSBB is an acronym for cloud mobile device security building block) from a commercial domain registrar and used it throughout this guide. The exact method for DNS acquisition and management is unique for each registrar and enterprise and is therefore unable to be addressed by this guide.

4.1.1 Cloud Architecture Benefits The security benefits of a cloud architecture will depend heavily on the service provider that is chosen. NIST SP 800-146 states that in a public cloud scenario, “the details of provider system operation are usually considered proprietary information and are not divulged to consumers. … Consequently, NIST SP 1800-4B: Mobile Device Security

20

consumers do not (at the time of this writing) have a guaranteed way to monitor or authorize access to their resources in the cloud” [30]. However, organizations that lack security subject matter experts can realize a benefit because “clouds may be able to improve on some security update and response issues.” We recommend that readers consider the recommendations in Section 9.3 of NIST SP 800-146 [30] before choosing a cloud service provider.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Functionally, the cloud architecture benefits from the rapid development of features — a trait found in modern web-based services. The MDM service used within the cloud build is able to keep pace with the quick-changing landscape of mobile devices. For example, mobile device vendors can add device management features as they iterate through OS versions. These features can be immediately available through the cloud service rather than delayed by a traditional on-premises software upgrade cycle. Another benefit of the cloud architecture is the ability to manage mobile devices from any physical location. Our cloud MDM portal is available to administrators through a web interface; the only requirements are a modern web browser and an internet connection. This allows administrators to take action while outside the boundaries of the enterprise network. Further, it reduces reliance on desktop applications that may not be available on all workstations.

4.1.2 Cloud Build Security Characteristics Much of the security of the cloud build relies on the protections provided by the mobile device, the policies implemented by the MDM, and the Microsoft Outlook mobile application installed on the device. The initial selection of the mobile device makes a large difference in the security features available due to low-level boot firmware and/or OS integrity checks. Some mobile devices provide some form of secure boot rooted in hardware or firmware by default, while other devices offer no boot integrity at all. Another feature available only on certain mobile devices is secure key storage, which may or may not be rooted in hardware. Organizations may wish to ensure that the devices they support include these desirable hardware/firmware capabilities. An individual who decides to participate in a managed scenario must download the Microsoft Community Portal application and input the required information. Then the device is provisioned into the EMM, and the default set of policies listed in Appendix C is applied to the device. This includes local authentication to the mobile OS via a lock screen and the encryption capabilities provided by the mobile OS to protect data on the device. The Outlook application provides an additional layer of applicationlevel encryption to email and Outlook application-related data via the Microsoft managed application policies [31]. The Outlook application uses a TLS 1.2 tunnel to communicate with the Office 365 email, calendaring, and contact services, and does the same for the cloud-based AD service offered by Office 365. The management interface to access the Office 365 EMM and other administrative functions is also protected via a TLS 1.2 tunnel over the internet. Further, if a user is not in compliance with the policies specified in Appendix C, the system administrator is notified. As an additional layer of protection, inclusion of the Lookout for Enterprise application also provides anti-malware protection alongside jailbreak/root detection.

NIST SP 1800-4B: Mobile Device Security

21

4.2 Hybrid Build: Architecture Description

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The hybrid build leverages the same cloud-based services from the cloud build but integrates them into the network in a different manner. It includes a combination of enterprise assets likely to be present within an organization’s existing network, including EMM capabilities, and adds cloud services for MDM. This build might be a starting point for an organization that has significant investment in or dependence on an internal AD server. The cornerstone of the hybrid build is the existing AD server housing user data and associated credentials. Figure 4-2 depicts the high-level hybrid build architecture. Figure 4-2 Hybrid Build Architecture

NIST SP 1800-4B: Mobile Device Security

22

Table 4-1 Legend for Hybrid Build Architecture Diagram

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Acronym

Term

AD DS

Active Directory Domain Services

AD FS

Active Directory Federation Services

DMZ

Demilitarized Zone

Microsoft Intune functions as the EMM for this solution, which can be easily configured and operated as a cloud service to onboard personally or enterprise-owned mobile devices into the EMM. This allows users to access enterprise resources and allows those involved with enterprise management to push policies to mobile devices. The hybrid build contains the following elements: ▪ In the cloud: •

Intune provides MDM, MAM, and end point management capabilities. Devices outside the enterprise firewall can connect to Intune for configuration management and monitoring

•

Office 365 synchronizes with AD Domain Services (DS) 2012R2 to provide email, contacts, and calendaring services. It also has its own user database, which can be selectively synced with AD DS via the Azure AD Sync Tool

•

The Lookout Security Platform provides the back end to the threat protection mobile application to identify risks on the device

▪ In the enterprise intranet: •

AD DS stores directory data and manages communication between users and domains, including user log-on processes, authentication, and directory searches. It is used to centrally manage servers and users, and information is synchronized with cloud services https://technet.microsoft.com/en-us/library/Cc770946(v=WS.10).aspx

•

AD Federation Services (FS) 2012R2 is a standards-based service that allows the secure sharing of AD DS identity information between trusted business partners across an extranet. https://msdn.microsoft.com/en-us/library/Bb897402.aspx

•

Azure AD Sync Services is used to mirror Azure AD and Office 365 with a single-forest or multiforest on-premises AD. It does not require access to the Azure AD tenant that is created with the associated Office 365 subscription. Systems Center Configuration Manager (SCCM) provides unified management across on-premises, service provider, and Azure environments for both Windows computers and mobile devices. http://www.microsoft.com/en-us/server-cloud/products/system-center-2012-r2/

▪ In the enterprise demilitarized zone: •

The Web Application Proxy (WAP) provides reverse proxy functionality for AD FS to allow access to users on any device from outside the enterprise network. It acts as a security

NIST SP 1800-4B: Mobile Device Security

23

barrier by not allowing direct access into the AD environment from the internet and is not joined to the domain itself ▪ From the internet: •

Mobile applications (Lookout MTP, Intune MDM client, Outlook) deployed to the device that support the functional and security characteristics of this build

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Additional components not pictured: Making full use of cloud services requires a globally recognized commercial domain. For our test purposes, we acquired hmdsbb.org from a commercial domain registrar and used it throughout this practice guide. The exact method for DNS management will be unique for each registrar and organization and is therefore unable to be addressed by this guide. The build team generated a certificate from the Symantec Secure Site Pro Secure Sockets Layer Certificates service to fulfill prerequisite requirements from AD FS to federate with Office 365. A router/firewall is used to simulate various network and security domains within an organization.

4.2.1 Hybrid Architecture Benefits The hybrid architecture leverages the flexibility of cloud services discussed in Section 4.1 while benefiting from security enhancements by using on-premises services. First, we made the architectural decision to use identity federation services that are realized through AD FS and Microsoftʼs AD Authentication Library (ADAL) service. This build leverages federation when the device owner is required to authenticate to Intune and Office 365 cloud services. This allows an organization to act as an identity provider — device owner passwords are shared only with on-premises systems and never with thirdparty cloud services. The NCCoE made the architectural decision in this build to use a WAP. The WAP serves as a front end for requests to the on-premises AD FS system. This setup has the security benefit of adding a layer of defense by isolating front-end requests from the corresponding back-end requests to the protected federation service. This is important because the AD FS holds sensitive cryptographic keys such as the token-signing and service identity key. In this way, the AD FS system is protected within the enterprise network boundaries and not exposed to internet-facing networks [32]. Functionally, the architecture provides the benefit of managing enterprise identities within the traditional workflow of an on-premises AD system. Many organizations utilize identity management systems that require on-premises AD services but would also like to leverage cloud services without having two disparate identity systems. To solve this issue, we made the architectural decision to add an on-premises system dedicated to syncing identities between the on-premises AD and the cloud-based Office 365 environment. SCCM is another instance of how our hybrid architecture benefits from on-premises and cloud services. This build could leverage traditional workstation configuration capabilities while enjoying the benefits of using a cloud MDM service. This is possible because the on-premises SCCM system is integrated with the Intune cloud service. Therefore, administrators can continue their normal workflow from the SCCM console and have a complete picture of enterprise assets from a single view.

NIST SP 1800-4B: Mobile Device Security

24

4.2.2 Hybrid Build Security Characteristics

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The security characteristics of the hybrid build closely resemble the characteristics in Section 4.1.2, Cloud Build Security Characteristics. The Outlook mobile application uses a TLS tunnel to communicate with the Office 365 email, calendaring, and contact services that live in the cloud. However, in the hybrid build, mobile traffic is directed through a proxy before communicating with internal enterprise services when interacting with the enterprise for authentication services. Additionally, on-premises systems communicate with Microsoft cloud services via a TLS tunnel. This includes the SCCM system and the AD Sync systems.

4.3 Security Characteristics and Capabilities The security characteristics and capabilities presented in Appendix C are based on the principles identified in NIST SP 800-164 and NIST SP 800-124. Security characteristics are the goals that this build is trying to achieve, while security capabilities are the individual mechanisms to accomplish these goals. A goal would be to implement the identified characteristics and capabilities with verifiable integrity via continued assertions that the device has not been compromised. This would ensure that key firmware or OS files have not been tampered with, that the device has not been rooted or jailbroken, and that the device’s security policies are verified as those being issued by the enterprise. Therefore, these characteristics and capabilities should be implemented at the lowest possible level; for instance, firmware is preferred to an application layer service. The original problem definition document [1] defines a superset of security characteristics and capabilities. This project does not implement every item within that document. What is specifically achieved in the context of this project is detailed in Appendix C, along with implementation notes for the build. Finally, note that many of the terms used below are not standardized throughout industry. Therefore, the descriptions provided alongside the capabilities reflect the term’s meaning in the context of this project.

4.3.1 Default Policies Multiple standards espouse management policies that should be applied to user devices. Specifically, NIST SP 800-124 Revision 1 and the NIAP protection profile for MDMs suggest desirable features and functionality for an enterprise MDM policy. Table 4-2 shows the default policy used in this project and pushed to devices within this building block, fulfilling our goals of a reasonable balance between security and user functionality. Suggested policies such as turning off Bluetooth and Wi-Fi, while reducing the threat surface to which a mobile device is exposed, remove important functionality desired by users. Some of these policies may be accomplished by the underlying mobile OS (e.g., Android, iOS, Windows Phone) while others require application-level features, and still others are accomplished via the MDM. Although the following policies were used for the building block, organizations need to perform their own assessments to understand the risks associated with their systems. Guidance for performing this assessment and selecting appropriate policies can be found within NIST 800-124 r1 [2].

NIST SP 1800-4B: Mobile Device Security

25

Table 4-2 SP 800-124 Mapping to Security Characteristic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

NIST SP 1800-4 Security Characteristic

Automatically monitor device configuration and detect policy violations

• Intune and Office 365 MDM Compliance checks periodically query the Company Portal MDM agent for a deviceʼs current level of compliance

Note Company Portal, Intune, and Office 365 MDM automatically monitor managed devices for policy compliance

• The Company Portal MDM agent monitors the device for policy compliance and enforces policy settings on local device functionality (e.g., access to location services or removable media) Automatically report when policy violations occur, such as changes from the approved security configuration baseline

SCCM can log the policy violations for subsequent reporting and review, which can be optionally sent to Event Viewer to enable additional monitoring and reporting functionality

Auditing and logging

When configuring an MDM policy in SCCM, setting noncompliance severity for reports to the least information will log violations of any included settings in Configuration Manager. [33]

Automatically take action in response to policy violations when possible and appropriate

Intune and SCCM offer policy settings that authorize the Company Portal MDM agent to attempt to restore noncompliance settings back to a compliant state

Asset management

Most MDM policy sections configurable by Intune/SCCM have a remediate noncompliant settings option. Note that automatic remediation for any given policy setting may not be supported on all OS versions

NIST SP 1800-4B: Mobile Device Security

26

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

Limit or prevent access to enterprise services based on whether the device has been rooted/jailbroken

• Intune and Office 365 MDM can block access to enterprise resources when the device is detected as being jailbroken or rooted

NIST SP 1800-4 Security Characteristic

Note

Root and jailbreak detection

Conditional access is set through SCCM Exchange connector. Mobile users are not allowed to access enterprise email services until the target device is compliant (i.e., phone is encrypted and not rooted/jailbroken)

When creating an MDM policy using SCCM, the Platform Applicability step of the Create Configuration Item Wizard will list policy settings that are not supported by selected OS versions

• Intune and SCCM via Intune have MAM policy settings that block user access to managed applications when the device is not compliant with MDM policy • The Conditional Access Extension for SCCM enables blocking access to an onpremises Exchange server, Exchange Online, and SharePoint online for noncompliant devices

Limit or prevent access to enterprise services based on the mobile deviceʼs OS version

Intune/SCCM must be explicitly configured to allow enrollment of iOS and Android devices. Each MDM policy created using Intune/SCCM can apply to a different set of specific OS versions

Device provisioning and enrollment

Limit or prevent access to enterprise services based on the mobile deviceʼs vendor/brand or model

Intune enables a device enrollment manager to enroll usersʼ devices on their behalf, allowing an organization to manually control which models of mobile devices will be enrolled

Device provisioning and enrollment

Limit or prevent access to enterprise services based on the MDM software client version (if applicable)

N/A

N/A

NIST SP 1800-4B: Mobile Device Security

27

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

NIST SP 1800-4 Security Characteristic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Strongly encrypt data communications between the mobile device and the organization

Each of the mobile devices and OSes used in the build are capable of secure communications that use TLS

Protected communications

Strongly encrypt stored data on builtin storage.

• Intune/SCCM and Office 365 Device encryption MDM offer a policy setting requiring that built-in device storage be encrypted • Intune/SCCM offer a MAM policy setting enforcing encryption of application data

Note The Company Portal and Microsoft Outlook applications initiate secure communications with Microsoft Intune and Office 365 using TLS by default Device encryption implementation varies among device manufacturers. Encrypting the application data setting may not provide additional cryptographic protection over full-device encryption. However, when device encryption is undesirable, this setting is an alternative

Strongly encrypt stored data on removable storage

Intune/SCCM offer a policy setting to force encryption of removable media, which is advertised to work with Windows Phone 8.1

N/A

If removable storage is not a necessary feature and encryption of removable storage is not supported, consider disabling the use of removable storage media

Wipe the device (to scrub its stored data) before reissuing it to another user, retiring the device, etc.

Intune/SCCM and Office 365 MDM can trigger a full or selective wipe of data remotely

Remote wipe

Administrators are able to fully wipe devices by selecting the device from the SCCM console

NIST SP 1800-4B: Mobile Device Security

28

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

NIST SP 1800-4 Security Characteristic

Note

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Remotely wipe the device (to scrub its stored data) if it is suspected that the device has been lost, stolen, or has otherwise fallen into untrusted hands and is at risk of having its data recovered by an untrusted party.

Intune/SCCM and Office 365 MDM can trigger a full or selective wipe of data remotely

Remote wipe

A device often can also be configured to wipe itself after a certain number of incorrect authentication attempts

Intune/SCCM and Office 365 offer a policy setting that activates this feature and sets the number of allowed unlock attempts

Device wipe after unsuccessful unlock attempts

Require a device unlock code be set before authorizing access to the organization’s resources

Intune/SCCM and Office 365 offer a policy setting that requires a managed device to have a device unlock code set

Local This setting is a authentication prerequisite for device of user to device encryption

Require basic parameters for password strength

• Intune/SCCM and Office 365 N/A have a policy setting that requires that a device unlock code possesses a minimum length • Intune/SCCM and Office 365 have a policy setting that requires that the device unlock code meets certain complexity requirements

NIST SP 1800-4B: Mobile Device Security

Administrators are able to selectively or fully wipe devices by choosing the device from the SCCM console

Longer or more complex device unlock codes increase the cryptographic strength of derived device encryption key and are more resistant to discovery (e.g., shoulder surfing attacks)

29

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

NIST SP 1800-4 Security Characteristic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Optionally require other authentication (e.g., token-based authentication, network-based device authentication, domain authentication) before accessing the organizationʼs resources

Intune/SCCM offer a MAM policy setting that forces a four-digit PIN or corporate credentials to be entered before Company Portal will allow managed applications to be accessed locally by the device user

Local authentication of user to applications

Require a limit on the number of retries permitted without negative consequences (e.g., locking out the account, wiping the device)

Intune/SCCM offer a MAM policy setting that sets a limit on the maximum number of managed application authentication attempts (via PIN or corporate credentials) before the PIN will be reset.

N/A

If device account lockout is enabled or the device password/passcode is forgotten, an administrator can reset this remotely to restore access to the device

Intune/SCCM have a policy setting that allows a password reset PIN to be synchronized with a Microsoft Exchange server; advertised for Windows devices only

N/A

Have the device automatically lock itself after it is idle for a period (e.g., five minutes)

Intune/SCCM and Office 365 have a policy setting that requires that the device automatically locks after a specified number of minutes of inactivity

N/A

NIST SP 1800-4B: Mobile Device Security

Note

If an attacker has access to an unlocked device, they likewise will have access to any data not protected by additional authentication

30

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

NIST SP 1800-4 Security Characteristic

Note

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Under the direction of an administrator, remotely lock the device if it is suspected that the device has been left in an unlocked state in an unsecured location

Intune/SCCM can issue a remote lock instruction to managed devices

N/A

Administrators are able to remotely lock devices from the SCCM console

Restrict the use of OS and application synchronization services (e.g., local device synchronization, remote synchronization services, and websites)

Intune/SCCM offer a series of policy settings applicable to iOS and Samsung Android with KNOX that block synchronization of various kinds of content (photos, files, application backups) with either locally connected computers or cloud services

Device resource management

As support for this feature varies across OS versions, and restriction of synchronization can significantly impact device functionality, we did not choose to block synchronization. Consider using MAM policies to restrict the data-sharing functions accessible to managed applications

Verify digital signatures on applications to ensure that only applications from trusted entities are installed on the device and that code has not been modified

Intune/SCCM offer MDM policy settings that block installation of unsigned applications or files

Application verification, verified application, and OS updates

Each of the mobile device OSes used supports verification of digital signatures for applications and application and OS updates

Query the current version of the hardware model of the device

Intune/SCCM and Office 365 MDM automatically query and record device hardware and OS versions for enrolled devices. Additionally, SCCM incorporates this information with its centralized asset inventory

Inventory of mobile device hardware, firmware, and software

NIST SP 1800-4B: Mobile Device Security

31

NIST SP 800-124 rev1 EMM/MDM Security Services

Related Technical Functions

NIST SP 1800-4 Security Characteristic

Note

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Alert the administrator to security events

Intune/SCCM offer alert-level settings for each category of policy settings (e.g., encryption or cloud); detected violations of any setting within that group. Additionally, by default, deployment of a configuration baseline is configured to automatically send alerts to when overall policy compliance falls below a specified compliance threshold (90% by default)

Auditing and logging, compliance checks

When configuring an MDM policy in SCCM, if the noncompliance severity for reports setting for a given policy section is set to critical with event, then in addition to logging by Configuration Manager, a Windows event will be generated, enabling additional notification features by using Event Viewer

Import keys/secrets into the secure key storage locations

• Intune/SCCM allow digital certificates to be automatically installed onto mobile devices upon enrollment

Trusted key storage

This is accomplished at the OS level of iOS, Android, and Windows Phone 8.1. Note: Use of OS-managed secure key storage by any given application is optional

Note that blocking the installation of third-party applications is currently incompatible with the use of an organizationmanaged application store

• iOS 8.3, Android 5.3, and Windows Phone 8.1 allow application to store cryptographic keys/secrets in OS-managed secure key storage locations (e.g., Android Keychain) Restrict which application stores may be used

Intune and SCCM offer a policy setting that restricts enrolled devices to installing applications from the official application store for its OS. Additionally, Intune/SCCM can block user access to the official application store

Whitelisting/ blacklisting

Restrict which applications may be installed through whitelisting (preferable) or blacklisting

Intune/SCCM offer policy settings to establish both whitelists and blacklists of applications; lists are specific to each mobile OS

Whitelisting/ blacklisting

NIST SP 1800-4B: Mobile Device Security

32

NIST SP 800-124 rev1 EMM/MDM Security Services

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Restrict the permissions (e.g., camera access, location access) assigned to each application

Related Technical Functions • Intune/SCCM offer policy settings that can block use of certain specific device peripherals or OS functionality for all applications (e.g., camera, location services)

NIST SP 1800-4 Security Characteristic

Note

Device resource management, data protection

• Intune/SCCM offer MAM policy settings that can block access to specific OSprovided functions (e.g., cut-and-paste, data transfer between applications, or screen capture) for managed iOS or Android applications Install, update, and remove applications

Intune has MAM functionality that allows it to automatically install, update (may require manual deployment), and remove applications from managed devices

N/A

Safeguard the mechanisms used to install, update, or remove applications

Access to the policies and software functions that will install, upgrade, or remove applications from managed devices is managed by a rolebased access management scheme using AD groups

N/A

Keep a current inventory of all applications installed on each device

Intune and SCCM receive application information from Company Portal; the installed applications with version information are inventoried for each device

Inventory of mobile device hardware, firmware, and software

NIST SP 1800-4B: Mobile Device Security

The SCCM built-in role of Application Deployment Manager can be used to manage which administrators can install and remove applications from managed devices

33

NIST SP 800-124 rev1 EMM/MDM Security Services

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Distribute the organization’s applications from a dedicated mobile application store

Related Technical Functions Intune and SCCM have MAM functionality that allows an organization to upload internally developed and publicly available applications to a private application store accessible only to managed devices

NIST SP 1800-4 Security Characteristic N/A

Note At the time of this document, no mobile OS differentiates between an organizationʼs private application store and any other third-party (unofficial) application store. If a private application store is used without an explicit whitelist of applications, those from unofficial application stores could also be downloaded

5 Outcome This section discusses the building block from the perspective of the user and the system administrator. We define system administrator as a person within the organization who has elevated privileges on the management systems in the build.

5.1 The User’s Experience When users access enterprise services on their device, their devices will be enrolled into an EMM. Access to email, contacts, and calendaring services occurs via the Microsoft Outlook mobile application. Device enrollment is accomplished by downloading and installing the Microsoft Company Portal application, available in the iOS and Android application store. Windows Phone devices have some management capability built into the OS, but they also require the Company Portal application to relay information to the enterprise. The Company Portal application can be downloaded directly onto the device from the Windows Application Store. In general, the specific hardware of a mobile device will make little difference in how information is presented to the user. Accordingly, boot integrity has little impact on the workflow unless a user needs the capability to modify the mobile OS (e.g., jailbreaking, rooting) or if boot integrity is compromised. Enrolling a mobile device into the EMM causes a number of policies to be applied to it. One of the items most affecting a user’s experience is the case in which a user does not have local authentication on the device because the default EMM policies espoused within Appendix C require authentication to the OS lock screen. The exact complexity of the authentication solution (e.g., PIN, passcode, gesture) is subject to the needs of the enterprise, although NIST SP 800-63-3 [34] provides enterprises with guidance on this topic. The user’s enrollment authentication experience remains largely the same between the cloud and hybrid builds, even though the hybrid build supports identity federation between the enterprise and NIST SP 1800-4B: Mobile Device Security

34

Microsoft cloud services. The hybrid build leverages ADAL-based sign-in — which uses a Security Assertion Markup Language-based AD FS identity provider. This allows the user to keep a familiar workflow with the added security benefit of keeping passwords within the enterprise boundary.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

To receive the Lookout security services, which provide mobile malware protection, users should download the Lookout application from their device’s application store in one of two ways. First, during the EMM enrollment process, users are presented with a direct link to the device’s application store in the Company Portal. Second, the user is sent an invitation to enroll with Lookout through email. There is no technical control in this build, however, to require the installation of the Lookout application. Implementers of this build may wish to implement a MAM policy as a means to enforce the installation of the Lookout application. To enroll in the Lookout service, a user will have to supply the application with his or her email address and a unique code received via email. The Lookout application generally interacts with users only if there is a security violation on the device. Figure 5-1, Figure 5-2, and Figure 5-3 present the high-level workflow of device owner enrollment on the Android, iOS, and Windows Phone platforms, respectively. Figure 5-1 Android Workflow

NIST SP 1800-4B: Mobile Device Security

35

Figure 5-2 iOS Workflow

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

36

NIST SP 1800-4B: Mobile Device Security

Figure 5-3 Windows Phone Workflow

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5.2 The System Administrator’s Experience The experience of the system administrator will be different based on whether they are using the hybrid or cloud builds, mostly due to the type and granularity of policies available via the EMM interfaces. Installation, configuration, and deployment of the management systems are relatively simple if an organization decides to adopt the cloud-based EMM services, where setup can be accomplished in less than a few hours. The installation of the EMM and associated services on premises is significantly more complex, with installation time estimated in hours at least. Defining EMM policies within the web interface of the EMMs is relatively simple, as is distribution to mobile devices. Provisioning and de-provisioning email, contacts, and calendaring services on mobile devices is an important capability of this build. The process by which provisioning occurs will differ for the system administrator in the cloud and hybrid scenarios. Because the MDM functions are embedded within Office 365, provisioning mobile devices is quite simple in the cloud scenario. While creating a new user within the Office 365 administrative console, the system administrator has the option to allow the user mobile access.

NIST SP 1800-4B: Mobile Device Security

37

The complex nature of the hybrid architecture, however, necessitates a slightly more intricate process. The high-level process is as follows: 1. A new enterprise user is created in the on-premises AD. The means by which this happens is outside the scope of this building block; however, many organizations choose to use a thirdparty identity management system

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. The user is placed within a specific group within AD that is configured to sync identities. The user is synchronized by the on-premises Azure AD Sync system to the cloud Azure AD service 3. The on-premises SCCM system detects the new user, who is automatically added to the Intune collection. A collection represents a group of users who have mobile devices to be managed 4. The Windows Intune Connector extension installed on the SCCM system syncs the new user to the Intune cloud service 5. The new user can now enroll in the Intune service by using the Company Portal application De-provisioning is a simple task for the system administrator in both the cloud and hybrid builds. In the cloud build, de-provisioning a user can be as simple as disabling or deleting the user from the Office 365 administrative console. In the hybrid build, the user is removed from the Intune collection on the SCCM system. Implementers should note that de-provisioning actions may not be immediate. They will depend on the syncing periodicity configured in the Intune extension. While Lookout services offer direct integration with selected EMM providers, this build did not use a compatible EMM. As a result, the system operator would not receive predefined alerts (e.g., malware on a device) through the SCCM workflow. The system operator must configure the Lookout administrative console to send email alerts to designated personnel when threats are present on user devices. In practice, the operator would receive an email with a warning of malware on a user’s device. The operator would then find the user within SCCM and take appropriate action on the device. Further, in this build there is no technical mechanism to enforce the installation and use of Lookout technologies. An administrator could, however, periodically compare the list of enrolled users in Lookout and the EMM. Users who were absent from the Lookout enrollment could be encouraged to download and install the application through an out-of-band means. A step-by-step description of setup, installation, and configuration is available in NIST SP 1800-4C.

6 Security Characteristic Analysis The purpose of the security characteristic analysis is to understand the extent to which the project meets its objective of demonstrating a method of protecting organizational data while permitting users the freedom to access and process data via mobile devices. In addition, it seeks to understand the security benefits and drawbacks of the example solution.

6.1 Assumptions and Limitations The security characteristic analysis has the following limitations:

NIST SP 1800-4B: Mobile Device Security

38

▪ It is neither a comprehensive test of all security components nor a red team exercise ▪ It cannot identify all weaknesses ▪ It does not include the lab infrastructure. It is assumed that devices are hardened. Testing these devices would reveal only weaknesses in implementation that would not be relevant to those adopting this reference architecture

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6.2 Build Testing The evaluation included an analysis of the project to identify weaknesses and discuss mitigations. The focus of this portion of the evaluation was hands-on testing of the laboratory build and examination of product manuals and documentation. Our objective was to evaluate the example solution and not specific products. However, the presence of three primary OSes for mobile devices (Android, iOS, and Windows) made complete product independent hands-on testing unrealistic. Table 6-1 describes the goals of each test case.

NIST SP 1800-4B: Mobile Device Security

39

Table 6-1 Cybersecurity Framework Subcategory Evaluation

Test ID

Cybersecurity Framework Subcategory

Related NIST SP 800-53 Controls

Evaluation Objective

Data Protection

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1

PR.DS-1: Data at rest is protected

SC-28 Protection of Information at Rest

Data is accessible only to authorized users and services. Data is protected during storage and processing

2

PR.DS-2: Data in transit is protected

SC-8 Transmission Confidentiality and Integrity SC-13 Cryptographic Protection

The confidentiality and integrity of information is protected while in transit (SC-8) by using a cryptographic mechanism. A Federal Information Processing Standard (FIPS) 140-2-compliant mechanism is used to secure data in transit

SC-7 Boundary Protection

Monitor and control communications at the external boundary of the system and at key internal boundaries within the system

Data Isolation 14

PR.DS-5: Protections against data leaks are implemented

Device Integrity 16

PR.DS-6: Integritychecking mechanisms are used to verify software, firmware, and information integrity

SI-7 Software, Firmware, and Information Integrity

Integrity mechanisms are running to check the integrity of software and information files

17

DE.CM-4: Malicious code is detected

SI-3 Malicious Code Protection

Malicious code protection is installed on mobile devices. Anti-malware software (e.g., anti-virus software) is installed

18

DE.CM-5: Unauthorized mobile code is detected

SC-18 Mobile Code

Only mission-appropriate content may be uploaded within the application. The application should employ functionality to restrict upload of file types to those expressly required for operations (e.g., TIFF, JPEG, and PDF)

Monitoring

NIST SP 1800-4B: Mobile Device Security

40

Test ID

Cybersecurity Framework Subcategory

Related NIST SP 800-53 Controls

Evaluation Objective

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

20

ID.AM-1: Physical devices and systems within the organization are inventoried

CM-8 Information System Component Inventory

Mobile devices are inventoried within the SCCM database

21

ID.AM-2: Software platforms and applications within the organization are inventoried

CM-8 Information System Component Inventory

Software and licensing are inventoried within the SCCM database

28

DE.AE-5: Incident-alert thresholds are established

IR-5 Incident Monitoring

When alerts exceed the established threshold, the administrator is notified

37

DE.CM-8: Vulnerability scans are performed

RA-5 Vulnerability Scanning

Scanning mechanisms are implemented and effective. Vulnerability scanners provide comprehensive coverage and employ best practices

Identity and Authorization 41

PR.AC-1: Identities and credentials are managed for authorized devices and users

IA Controls

The architecture accounts for multiple user roles with access privileges assigned to each role. Access controls are documented.

42

PR.AC-1

AC-2 Account Management; Identification and Authentication Controls

Only enrolled/managed devices can access email, contacts, and calendaring. Information is available only to authorized devices

6.3 Scenarios and Findings One aspect of our security evaluation involved assessing how well the reference design addresses the security characteristics it was intended to support. The NIST Cybersecurity Framework subcategories were used to provide structure to the security assessment by consulting the specific sections of each standard that are cited in reference to a subcategory. The cited sections provide validation points that the example solution would be expected to exhibit. Using the Cybersecurity Framework subcategories as a basis for organizing our analysis allowed us to systematically consider how well the reference design supports the intended security characteristics. NIST SP 1800-4B: Mobile Device Security

41

The remainder of this subsection discusses how the reference architecture solution addresses the six desired security characteristics that are listed in Table 3-1 through Table 3-6.

6.3.1 Data Protection This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

We chose to examine the capability of protecting data at rest. The primary means used by this building block to accomplish data protection is encryption. Android, iOS, and Windows Phone devices used as part of this build deployed device encryption. The Android devices used dm-crypt, a disk encryption subsystem that calls a number of cryptographic libraries. The Android implementation of this has not been FIPS 140-2 validated, although it uses the same crypto library as the Red Hat Enterprise Linux validation. For environments where FIPS 140-2 validation is necessary, organizations could consider using a third-party data and application isolation solution, such as a secure container providing application-level encryption. Our Apple devices use Apple OS X CoreCrypto Kernel Module v5.0. As of 2015, it has received FIPS 140-2 level 1 validation on iOS 8.x devices. The Windows phones used in this exercise are FIPS 140-2 compliant. The Microsoft Kernel Mode Cryptographic Primitives Library has met FIPS 140-2 compliance at level 1 by using a Qualcomm Snapdragon 800 system on a chip. Finally, the Outlook application provides an additional level of encryption. Microsoft protects the Outlook data via AES-128 encryption in cipher block chaining mode utilizing Android’s cryptography libraries. The iOS application-level encryption was not evaluated as Microsoft indicated that information is encrypted via the OS cryptographic engine.

6.3.2 Data Isolation When a device is utilized for organizational and personal activities, the ability to isolate data is essential. We inspected the sandboxing capability of devices and found that each of the OSes in use offers native isolation functions. Android, iOS, and Windows run applications in a sandbox that prevents a third-party application from accessing, gathering, or modifying information from other applications. While this is a valuable security feature, it does not replace the need to educate device users on the potential dangers of downloading unknown and untrusted applications.

6.3.3 Device Integrity Each of the mobile platforms has integrity-checking mechanisms. We examined the native file integrity mechanisms as well as malicious code protection. Each platform requires application authors to digitally sign applications before the applications are available for users. The integrity-checking mechanism does not ensure that the application itself is secure or free of malware. To protect devices from malware, the MDS building block specifies that anti-virus software be installed on mobile devices and that the configuration “allow unknown sources” is not enabled. The build restricts the ability to download file types via email by enabling the file attachment filter in Office 365. We verified this by disallowing PDF file types. A user then attempted to send an email with a PDF file attached. The intended recipient was notified that an email addressed to them was blocked according to policy.

NIST SP 1800-4B: Mobile Device Security

42

6.3.4 Monitoring

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Our examination of security monitoring provided evidence of basic monitoring and scanning being performed. Devices enrolled in the MDM tool were displayed within the configuration management system console. This can be used for hardware inventory reporting as the MDM tools have customizable reports. We were able to use software reporting to only a limited degree. Intune provided software reporting only for applications published under the organization’s application store. It did not monitor and conduct an inventory of applications downloaded from other sources such as Google Play. The MDM provides the capability to tailor compliance policy for devices. When a device exceeds the organization-defined threshold for compliance, the administrator receives an alert showing which device is out of compliance. As an additional precaution, an organization may desire to restrict devices from downloading outside its own organizational application store if the potential for unknown applications exceeds the organization’s risk appetite. Finally, the Lookout MTP service provides monitoring of enrolled devices for malware risks on Android devices. In this build, the administrator periodically reviewed the status of enrolled devices in the enterprise through the MTP web console. More sophisticated notification systems, however, could be developed for larger deployments.

6.3.5 Identity and Authorization Identity and authorization are integrated within the enterprise. The NCCoE needed to verify that only users with authorized access via mobile devices were able to exercise that access. Because the lab was built as a Microsoft environment, access control was implemented via AD. Test users were members of a domain users’ group synchronized through AD FS. We had users who were not members of the appropriate group attempt to access their email on an enrolled mobile device, and those attempts failed. We also sought to verify device authorization. We wanted to ensure that only currently enrolled devices could access organizational resources. Our verification included devices never enrolled and devices previously enrolled. Access attempts for devices not enrolled produced the following results:

NIST SP 1800-4B: Mobile Device Security

43

▪ iOS redirected the user to the organization portal, then directed the user to enroll his or her device. Email was not accessible until the device was enrolled and compliant with the organization’s mobile device policy. ▪ Android attempted to enroll the device with the active sync policy when not managed by Intune. Android would not retrieve email until the device was enrolled in SCCM and compliant with policy.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

▪ When attempting to access Office 365 services from out-of-compliance devices, users could activate the email client on the device but were unable to retrieve email.

7 Future Build Considerations As we expand this work to future builds, our objective is to solicit feedback from the user community toward prioritization of additional capabilities and to solicit suggestions from the EMM vendor community on commercial products that provide those capabilities. There is potential for the development and implementation of new MDS architectures under this build. To explore these various architectures, the NCCoE would like to engage with any individual or company with commercially or publicly available technology relevant to MDS. The NCCoE published a Federal Register notice (https://www.federalregister.gov/articles/2015/08/14/2015-20040/nationalcybersecurity-center-of-excellence-mobile-device-security-building-block) inviting parties to submit a Letter of Interest to express their desire and ability to contribute to this effort. Interested parties would be required to enter into a consortium CRADA partnership. Some topics of interest for future builds include… ▪ sector-specific MDM policy configurations ▪ mobile application vetting ▪ baseband integrity ▪ containerization technology ▪ rogue wireless access point detection ▪ enhanced identity services, such as two-factor authentication, derived personal identity verification (PIV) as demonstrated in NIST Interagency Report 8055, or use of the FIDO Alliance’s technology All interested parties are encouraged to engage the NCCoE with additional ideas and system requirements by reaching out to mobile-nccoe@nist.gov.

NIST SP 1800-4B: Mobile Device Security

44

Acronyms

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

AD

Active Directory

ADAL

Active Directory Authentication Library

AD DS

Active Directory Domain Services

AD FS

Active Directory Federation Services

BYOD

Bring Your Own Device

CAG

Consensus Audit Guidelines

CIO

Chief Information Officer

DNS

Domain Name System

DoD

Department of Defense

EMM

Enterprise Mobility Management

FIPS

Federal Information Processing Standard

HTTP

Hypertext Transfer Protocol

IEC

International Electrotechnical Commission

ISO

International Organization for Standardization

IT

Information Technology

MAM

Mobile Application Management

MDM

Mobile Device Management

MDS

Mobile Device Security

MTP

Mobile Threat Protection

NCCoE

National Cybersecurity Center of Excellence

NCEP

National Cybersecurity Excellence Partnership

NFC

Near Field Communication

NIAP

National Information Assurance Partnership

NIST

National Institute of Standards and Technology

NSA

National Security Agency

NVD

National Vulnerability Database

OS

Operating System

PHA

Potentially Harmful Application

PIV

Personal Identity Verification

SCCM

Systems Center Configuration Manager

NIST SP 1800-4B: Mobile Device Security

45

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

SP

Special Publication

TEE

Trusted Execution Environment

TLS

Transport Layer Security

TPM

Trusted Platform Module

US-CERT

United States Computer Emergency Readiness Team

WAP

Web Application Proxy

NIST SP 1800-4B: Mobile Device Security

46

References

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

[1]

National Cybersecurity Center of Excellence, Mobile Device Security for Enterprises, Sept. 2014. Available: https://www.nccoe.nist.gov/projects/building-blocks/mobile-devicesecurity/enterprise.

[2]

M. Souppaya and K. Scarfone, Guidelines for Managing the Security of Mobile Devices in the Enterprise, National Institute of Standards and Technology (NIST) Special Publication (SP) 800124 Revision 1, Gaithersburg, Md., June 2013. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r1.pdf.

[3]

L. Chen et al., Guidelines on Hardware-Rooted Security in Mobile Devices (Draft), NIST SP 800-164 (Draft), Gaithersburg, Md., Oct. 2012. Available: http://csrc.nist.gov/publications/drafts/800164/sp800_164_draft.pdf.

[4]

National Security Agency, Mobile Access Capability Package 2.0, Aug. 2017. Available: https://www.nsa.gov/Portals/70/documents/resources/everyone/csfc/capabilitypackages/mobile-access-cp.pdf.

[5]

National Information Assurance Partnership (NIAP), Protection Profile for Mobile Device Management Version 1.1, March 2014. Available: https://www.niapccevs.org/MMO/PP/pp_mdm_v1.1.pdf.

[6]

NIAP, Protection Profile for Mobile Device Fundamentals Version 2.0, September 2014. https://www.niap-ccevs.org/MMO/PP/pp_md_v2.0.pdf.

[7]

NIAP, Extended Package for Mobile Device Management Agents Version 2.0, Dec. 2014. Available: https://www.niap-ccevs.org/MMO/PP/pp_mdm_agent_v2.0.pdf.

[8]

S. Brooks et al., An Introduction to Privacy Engineering and Risk Management in Federal Systems, National Institute of Standards and Technology Internal Report 8062, NIST, Gaithersburg, Md., Jan. 2017. Available: https://doi.org/10.6028/NIST.IR.8062.

[9]

NIST, Managing Information Security Risk, NIST SP 800-39 Revision 1, Gaithersburg, Md., Mar. 2011. Available: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800 39.pdf.

[10] NIST, Guide for Applying the Risk Management Framework to Federal Information Systems, NIST SP 800-37 Revision 1, Gaithersburg, Md., Feb. 2010. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf. [11] S. Quirolgico et al., Vetting the Security of Mobile Applications, NIST SP 800-163, Gaithersburg, Md., Jan. 2015. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800163.pdf. [12] United States Computer Emergency Readiness Team (US-CERT), Cyber Threats to Mobile Devices, Technical Information Paper-TIP-10-105-01, US-CERT, Apr. 2010. Available: https://www.uscert.gov/sites/default/files/publications/TIP10-105-01.pdf.

NIST SP 1800-4B: Mobile Device Security

47

[13] Federal Risk and Authorization Management Program, Program Overview. Available: https://www.fedramp.gov/about/. [14] G. Delugré, Reverse engineering a Qualcomm baseband, Sogeti/ESEC R&D, 2011. Available: https://events.ccc.de/congress/2011/Fahrplan/attachments/2022_11-ccc-qcombbdbg.pdf.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

[15] Global Platform, Introduction to Secure Element. May 2018. Available: https://globalplatform.org/wp-content/uploads/2018/05/Introduction-to-Secure-Element15May2018.pdf. [16] Global Platform, Introduction to Trusted Execution Environment (TEE) Guide. May 2018. Available: https://globalplatform.org/wp-content/uploads/2018/05/Introduction-to-TrustedExecution-Environment-15May2018.pdf. [17] Trusted Computing Group, TPM Main Specification. Available: http://www.trustedcomputinggroup.org/resources/tpm_main_specification. [18] NIST, National Vulnerability Database, Gaithersburg, Md., 2015. Available: http://nvd.nist.gov. [19] NIST, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1, Gaithersburg, Md., Apr. 16, 2018. Available: https://www.nist.gov/cyberframework. [20] NIST, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53 Revision 4, Gaithersburg, Md., Apr. 2013. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf. [21] International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), Information technology — Security techniques — Code of practice for information security management, ISO/IEC 27002, 2013. [22] Council on CyberSecurity, The Critical Security Controls for Effective Cyber Defense, Version 6.0, May 2016. Available: https://www.sans.org/media/critical-security-controls/CSC-5.pdf. [23] D. Cooper et.al., BIOS Protection Guidelines, NIST SP 800-147, Gaithersburg, Md., Apr. 2011. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-147.pdf. [24] A. Regenscheid and K. Scarfone, BIOS Integrity Measurement Guidelines (Draft), NIST SP 800-155 (Draft), Gaithersburg, Md., Dec. 2011. Available: http://csrc.nist.gov/publications/drafts/800155/draft-SP800-155_Dec2011.pdf. [25] R. Kissel et al., Guidelines for Media Sanitization, NIST SP 800-88 Revision 1, Gaithersburg, Md., Dec. 2014. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80088r1.pdf. [26] Department of Defense (DoD), DoD Commercial Mobile Device Implementation Plan, Feb. 15, 2013. Available: http://archive.defense.gov/news/DoDCMDImplementationPlan.pdf. [27] U.S. Government Chief Information Officer Council, Government Mobile and Wireless Security Baseline, May 23, 2013. Available: https://s3.amazonaws.com/sitesusa/wpcontent/uploads/sites/1151/downloads/2013/05/Federal-Mobile-Security-Baseline.pdf.

NIST SP 1800-4B: Mobile Device Security

48

[28] General Services Administration (GSA), GSA Managed Mobility Program Request for Technical Capabilities, Available: https://www.gsa.gov/cdnstatic/Managed_Mobility_ML%26EM_RFTC__FINAL.pdf. [29] National Information Assurance Partnership (NIAP), Protection Profile for Mobile Device Management Version 2.0, Dec. 2014. Available: https://www.niapccevs.org/MMO/PP/pp_mdm_v2.0.pdf.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

[30] L. Badger et al., Cloud Computing Synopsis and Recommendations, NIST SP 800-146, Gaithersburg, Md., May 2012. Available: http://csrc.nist.gov/publications/nistpubs/800146/sp800-146.pdf. [31] Microsoft, How to create and assign app protection policies, Microsoft Technet, Nov. 30, 2018. Available: https://technet.microsoft.com/en-us/library/dn878026.aspx. [32] Microsoft, “Office 365 Single Sign-On with AD FS 2.0 whitepaper,” June 2012. Available: https://www.microsoft.com/en-us/download/details.aspx?id=28971. [33] Microsoft, Compliance Policies in Configuration Manager, Microsoft Technet, Apr. 7, 2016. Available: https://docs.microsoft.com/en-us/previous-versions/system-center/system-center2012-R2/mt131417(v=technet.10). [34] NIST, Digital Identity Guidelines, NIST SP 800-63-3, Gaithersburg, Md., June 2017. Available: https://pages.nist.gov/800-63-3. [35] Microsoft, Windows Phone 8.1 Security Overview, Apr. 2014. Available: http://download.microsoft.com/download/B/9/A/B9A00269-28D5-4ACA-9E8EE2E722B35A7D/Windows-Phone-8-1-Security-Overview.pdf. [36] Lookout, Change to sideloading apps in iOS 9 is a security win. Available: https://blog.lookout.com/blog/2015/09/10/ios-9-sideloading/. [37] The White House, Bring Your Own Device — A Toolkit to Support Federal Agencies Implementing Bring Your Own Device (BYOD) Programs, Aug. 23, 2012. Available: https://obamawhitehouse.archives.gov/digitalgov/bring-your-own-device. [38] Google, Help protect against harmful apps with Google Play Protect. Available: https://support.google.com/accounts/answer/2812853?hl=en. [39] Microsoft, Windows Phone Library, Apr. 2014. Available: https://technet.microsoft.com/enus/windows/dn771706.aspx . [40] NIST, Best Practices for Privileged User PIV Authentication, NIST Cybersecurity White Paper, Gaithersburg, Md., Apr. 2016. Available: http://csrc.nist.gov/publications/papers/2016/bestpractices-privileged-user-piv-authentication.pdf.

NIST SP 1800-4B: Mobile Device Security

49

Security Characteristics and Capabilities This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Data Protection

Device encryption: cryptographic protection of all or portions of a deviceʼs data storage locations — primarily flash memory locations

Operating system (OS)-level capability Unauthorized access to corporate data provided by each mobile OS, often a stored on a locked lost/stolen mobile combination of full disk encryption and file- device level encryption

Data Protection

Application-level encryption: potential additional layer of cryptographic protection on managed application data

Due to variations in implementation of encryption on mobile devices, perapplication encryption may only provide additional protection over device encryption for certain devices in certain states (e.g., encrypted application data not in use and device locked)

Unauthorized access to corporate data stored on a lost/stolen device, particularly when device-level encryption is not in use or has been bypassed

Data Protection

Trusted key storage: protected locations in software, firmware, or hardware in which longterm cryptographic keys can be held

• Android not in use: Android Keystore. The underlying implementation is devicespecific but is typically backed by firmware or hardware capabilities to securely store keys and perform cryptographic operations

Cryptographic key theft when keys are stored in unprotected memory locations

Implementation Note

Example Mitigated Threats

• iOS: provided by Secure Enclave • Windows Phone: has a Trusted Platform Module (TPM) capable of trusted key storage [27]

NIST SP 1800-4B: Mobile Device Security

50

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Data Protection

Data Protection

Implementation Note

Example Mitigated Threats

Protected communications: The confidentiality of data transmitted over untrusted networks is protected by strong encryption

Communication between mobile devices, cloud services, and on-premises components are protected by Transport Layer Security

Eavesdropping or manipulation of unencrypted data transmitted over untrusted networks

Remote wipe: renders access to both personal and enterprise data stored on lost/stolen devices infeasible, but may wipe only a portion of flash memory

• Android: Device Policy Manager application program interface which is used by enterprise mobility management / mobile device management (EMM/MDM) agents, Googleʼs Android Device Manager, and numerous thirdparty applications

Unauthorized access to personal and corporate data when an attacker is suspected of having physical access to a lost or stolen device

• iOS: provided by iCloud and can additionally be provided by an EMM/MDM system when the device is enrolled into enterprise management • Windows Phone: provided by windowsphone.com • Microsoft Intune and Office 365 MDM: can trigger a full wipe of enrolled devices remotely • Due to variations in implementation of wipe operations on mobile devices, the inability to recover data may be contingent on device- or application-level

NIST SP 1800-4B: Mobile Device Security

51

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats

encryption to achieve a cryptographic wipe by destroying the decryption key Data Protection

Selective wipe: Render access to enterprise data stored on a device infeasible without affecting personal data

• Microsoft Intune/ Systems Center Configuration Manager (SCCM) and Office 365 MDM: An administrator can wipe only organizational data from an enrolled device, leaving personal data intact • Android: Disabling the device administrator associated with Company Portal performs a selective wipe and unenrolls the device from Intune/Office 365 MDM

• Unauthorized access to enterprise data when a managed device is under the control of an untrusted user, but destruction of personal data is undesirable • Accidental disclosure of corporate data that may be accessible to personal applications once the user has opted to unenroll their personal device from enterprise management

• iOS: Removing the device management profile created during enrollment performs a selective wipe and unenrolls the device from Intune/Office 365 MDM • Windows Phone: Deleting the workplace created during the enrollment process performs a selective wipe and unenrolls the device from Intune/Office 365 MDM Data Protection

Automatic wipe: Multiple failed unlock attempts of lost/stolen devices can render access to both personal and enterprise data infeasible

NIST SP 1800-4B: Mobile Device Security

• OS-level capability provided by each mobile OS • Microsoft Intune/SCCM and Office 365 MDM: Offer a policy setting to enforce activation of automatic wipe functionality

Unauthorized access to personal and corporate data when an attacker attempts brute-force attacks against the unlock mechanism for a lost or stolen device

52

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Data Protection

Hardware security • Android: Device implementation specific, modules: tampermay be discrete hardware, or may be resistant hardware used implemented in firmware (e.g., by using to perform cryptographic ARM TrustZone) operations and secure • iOS: provided by Secure Enclave storage that may be removable or physically • Windows Phone: has a Trusted Platform part of the device Module capable of common cryptographic operations, which may be discrete hardware or may be implemented in firmware

Data Isolation

Sandboxing: OS or application-level mechanisms utilizing multiple protection, isolation, and integrity capabilities to achieve higher levels of overall isolation

Implementation Note

Example Mitigated Threats Cryptographic key theft when keys are stored in memory locations accessible to untrusted code

OS-level capability provided by each mobile • Exploitation of vulnerabilities in OS standard-process isolation mechanisms that would allow a process to access the instructions or data stored in the memory space or storage locations of another process • Exploitation of vulnerabilities in the OS by compromised or malicious mobile applications • Loss of availability of some OS functionality by flawed mobile applications that enter an unrecoverable execution state (e.g., application crashes)

Data Isolation

Memory isolation: Processes should be unable to access or

NIST SP 1800-4B: Mobile Device Security

OS-level capability provided by each mobile Unauthorized access by a running process OS to the data in use by another running process, or manipulation of the 53

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats

modify another processʼs memory

instructions loaded into another processʼs memory space

Data Isolation

Trusted execution: A process is created and runs in a trustworthy and isolated execution environment leveraging distinct memory spaces and controlled interfaces

OS-level capability provided by each mobile Exploitation of vulnerabilities in standardOS process isolation mechanisms in which the attacking and target processes run in the same security context

Data Isolation

Device resource management: ability to enable/disable device peripherals and certain OS-provided functionality

Microsoft Intune/SCCM and Office 365 MDM: Offer policy settings to restrict or disable peripherals and functions, which are applied and enforced on a mobile device by the Company Portal mobile application

• Compromise of the mobile OS via exploits delivered over unused wireless communications protocols (e.g., Bluetooth or near field communication (NFC) • Exfiltration of personal or enterprise data by malware or compromised mobile applications using unsecured and often unmonitored wireless communications protocols (e.g., Bluetooth or NFC) • Tracking the physical location of a mobile device using unused wireless communications protocols • Loss of availability of mobile device functionality resulting from an increase of power consumption by unused device peripherals (e.g., Bluetooth, NFC, Wi-Fi, location services)

NIST SP 1800-4B: Mobile Device Security

54

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats • Behavior tracking by malware or potentially harmful applications (PHAs) leveraging data obtained from device peripherals (e.g., Wi-Fi, location services, accelerometer) • Compromise of enterprise data, which can be recorded inconspicuously by Trojan or other malicious applications using accessible device peripherals (camera, microphone, location services)

Data Isolation

Data flow control: application-level access policies on OS-provided functionality that would transfer data into or out of its control

Microsoft Intune/SCCM: MDM and MAM policies can restrict how data is permitted to flow in or out of managed applications

Loss of confidentiality of and enterprise control over enterprise data that can be shared between mobile applications

Device Integrity Application whitelisting/ blacklisting: allowing or disallowing installation of applications based on a prespecified list

Microsoft Intune/SCCM and Office 365 MDM: can create device policies that deny installation of applications from unofficial application stores

• Installation of mobile malware or PHAs, particularly repackaged versions of legitimate applications

Device Integrity Application whitelisting/blacklisting

Microsoft Intune/SCCM: can additionally specify a whitelist or blacklist of specific applications and prohibit unsigned applications from being installed

• Installation of vulnerable applications, which increases the probability of application and device compromise

NIST SP 1800-4B: Mobile Device Security

• Exploitation of vulnerabilities in a thirdparty library (e.g., advertisement library) embedded in an application

55

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats • Installation of untrusted applications, which handle sensitive data in an insecure manner

Device Integrity Boot validation: validation that the device is in a known working state and unmodified at boot (e.g., basic input-output system integrity checks)

• Android: optional Verified Boot capability with device-specific availability. Additionally, other optional devicespecific boot-loader protections may be present

Compromise of the mobile OS via modification of code executed during the boot process

• iOS: provide by Secure Boot Chain • Windows Phone: provide by Secure Boot

Device Integrity Application verification: ensures that applications being installed come from a valid source

• OS-level capability provided by each mobile OS to verify the digital signature of applications • Android: ability in device settings to enable/disable installation of applications from untrusted sources (typically meaning the Google Play Store)

Installation of applications that contain malicious code introduced after submission from the developer or, for applications downloaded from an official application store, after review by the application store authority (e.g., Google, Apple, Microsoft)

• iOS: For applications side-loaded in iOS 9, the user must explicitly trust the application developer before the application can be used [36] unless the application is installed through an MDM system that the device is enrolled in Device Integrity Verified application and OS updates: Ensure that application and OS

NIST SP 1800-4B: Mobile Device Security

OS-level capability provided by each mobile • Introduction of malicious code into an OS to verify the digital signature of installed (and thus trusted) application applications and OS updates

56

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

updates being installed come from a valid source

Example Mitigated Threats via an update that was modified since submission or review • Exploitation of publicly known vulnerabilities on unpatched devices • Introduction of malicious code into the OS via an update that was modified since submission

Device Integrity Mobile malware detection: identification of malicious software on mobile platforms

Lookout Mobile Threat Protection (MTP) performs signature and non-signaturebased analysis of installed mobile applications

Installation of mobile malware, PHAs, particularly repackaged versions of legitimate applications

Monitoring

Inventory of mobile device hardware and software: Provide version information for the hardware, firmware, OS, and installed applications for enrolled mobile devices

Microsoft Intune/SCCM and Office 365 MDM inventory enrolled devices, including hardware, firmware, and OS versions

Compromise of mobile devices through known and unpatched vulnerabilities in device firmware or the mobile OS

Monitoring

Inventory of mobile device hardware and software

Intune/SCCM inventory installed applications on enrolled mobile devices

• Compromise of mobile devices or data through known and unpatched vulnerabilities in installed applications • Data compromise through flawed applications known to handle sensitive data insecurely (e.g., store it unencrypted in areas normally accessible to other applications)

NIST SP 1800-4B: Mobile Device Security

57

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats • Data compromise through applications that are known to harvest sensitive or user behavior data unnecessary for their advertised purposes

Monitoring

Asset management: identifies, configures, and tracks devices, components, software, and services residing on a network

Provided by SCCM for hybrid build and Office 365 Enterprise E3 for cloud build

Lower the likelihood of device or application compromise by configuring the device to restrict or disable the use of vulnerable components or applications

Monitoring

Compliance checks: Provide information about whether a device is compliant with a mandated set of policies

Microsoft Intune/SCCM and Office 365 MDM: Periodically audit and log device policy compliance via Company Portal

Mobile devices with unapproved configurations of hardware, firmware, OS, applications, and device settings are used to access, store, or process enterprise data

Monitoring

Root and jailbreak detection: ensures that the security architecture for a mobile device has not been compromised

• Microsoft Intune/SCCM and Office 365 MDM: can create device policies that enforce jailbreak detection on enrolled mobile devices

• Loss of confidentiality, integrity, or availability of personal or enterprise data accessed, stored, or processed on a mobile device running a compromised OS

• Company Portal: performs jailbreak and root detection on devices running iOS, Android, and Windows Phone 8.1 • Lookout MTP: performs jailbreak and root detection on device running iOS and Android

Monitoring

Auditing and logging: Capture and store security events for

NIST SP 1800-4B: Mobile Device Security

Microsoft Intune/SCCM and Office 365 MDM: Routinely audit enrolled devices for compliance

• For Lookout MTP, include losses on devices in which compromise of the OS may not be detected by the MDM agent

Repeated compromise via exploits that could be mitigated following review of audit logs 58

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats

• Provided by Intune/SCCM and Lookout MTP components

Repeated compromise via exploits that could be mitigated following review of audit logs

devices, including enrollment, failed compliance checks, administrative actions, and unenrollment Monitoring

Canned reports and ad hoc queries: produces preconfigured reports from audit logs and the ability to actively search or filter logs for specific data

• Microsoft Intune/SCCM: additionally, maintains a log of administrative actions and compliance check results to support reporting and alerting functions • Lookout MTP: routinely scans devices and logs any detected malware or indicators of OS compromise via rooting or jailbreaking

Identity and Authorization

Local authentication of user to device: requirement of a personal identification number (PIN), password, gesture, token, or other mechanism before the device can be fully used

OS-level capability provided by each mobile Unauthorized access to or modification of OS enterprise or personal data accessible to applications that do not require authentication when an attacker has physical access to a mobile device

Identity and Authorization

Local user authentication to applications: application requires a PIN, password, token, or other authentication

Application-specific functionality that prevents usage of the application until the user successfully authenticates. May be contingent on remote authentication, as with Company Portal

NIST SP 1800-4B: Mobile Device Security

Unauthorized access to or modification of enterprise data locally accessible to the application when an attacker has physical access to an unlocked mobile device

59

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Implementation Note

Example Mitigated Threats

mechanism to be fully used Identity and Authorization

Local user authentication to applications

Microsoft Intune/SCCM: Offer a MAM policy setting that requires entry of a PIN to use the application, which is enforced by Company Portal

Unauthorized access to or modification of enterprise data locally accessible to a managed application when an attacker has physical access to an unlocked mobile device

Identity and Authorization

Remote user authentication: Networked managed applications require authentication to a remote service to be fully used

Outlook and Company Portal: Require successful authentication to Office 365 Enterprise E3 for full functionality

Unauthorized remote access to enterprise resources when an attacker has access to a networked application for which application- or device-level authentication does not exist or has been bypassed

Identity and Authorization

Device provisioning and enrollment: restricts access to organization resources to provisioned mobile devices

Company Portal: provisions mobile devices into Microsoft Intune or Office 365 MDM

• Remote access to enterprise resources from untrusted mobile devices

Custom privacy statement: notification provided to users about the implications to privacy by the use of organizational resources and to privacy and device and application functionality for enrolled devices

Microsoft ADFS: allows the organization to customize the authentication portal, including a privacy statement

Privacy

NIST SP 1800-4B: Mobile Device Security

• Compromise of enterprise systems by malware executed on untrusted mobile devices Violation of an employeeʼs expectation of privacy as a result of monitoring an employeeʼs personal mobile device during remote access sessions of enterprise resources

60

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.1800-4.

Security Characteristic

Security Capability and Capability Description

Privacy

Custom privacy statement

NIST SP 1800-4B: Mobile Device Security

Implementation Note

Example Mitigated Threats

Company Portal: notifies the user of the implications of enrolling their device into an MDM

Violation of an employeeʼs expectation of privacy as a result of monitoring an employeeʼs personal mobile device following enrollment in an enterprise MDM

61

NIST SPECIAL PUBLICATION 1800-4C

Mobile Device Security Cloud and Hybrid Builds Volume C: How-to Guides

Joshua Franklin National Institute of Standards and Technology Information Technology Laboratory

Kevin Bowler Christopher Brown Spike E. Dog Sallie Edwards Neil McNab Matthew Steele The MITRE Corporation McLean, VA

February 2019 This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4 The original draft of this publication is available free of charge from: https://www.nccoe.nist.gov/projects/building-blocks/mobile-device-security/cloud-hybrid

DISCLAIMER

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Certain commercial entities, equipment, products, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST or NCCoE, nor is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 1800-4C, Natl. Inst. Stand. Technol. Spec. Publ. 1800-4C, 109 pages, February 2019, CODEN: NSPUE2

FEEDBACK As a private-public partnership, we are always seeking feedback on our Practice Guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at mobile-nccoe@nist.gov. All comments are subject to release under the Freedom of Information Act (FOIA).

National Cybersecurity Center of Excellence National Institute of Standards and Technology 100 Bureau Drive Mailstop 2002 Gaithersburg, MD 20899 Email: nccoe@nist.gov

NIST SP 1800-4C: Mobile Device Security

i

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners — from Fortune 50 market leaders to smaller companies specializing in IT security — the NCCoE applies standards and best practices to develop modular, easily adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cyber Security Framework and details the steps needed for another entity to recreate the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Md. To learn more about the NCCoE, visit https://nccoe.nist.gov. To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align more easily with relevant standards and best practices and provide users with the materials lists, configuration files, and other information they need to implement a similar approach. The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

ABSTRACT This document proposes a reference design on how to architect enterprise-class protection for mobile devices accessing corporate resources. The example solutions presented here can be used by any organization implementing an enterprise mobility management solution. This project contains two distinct builds: cloud and hybrid. The cloud build makes use of cloud-based services and solutions, while the hybrid build achieves the same functionality but hosts the data and services within an enterpriseʼs own infrastructure. The example solutions and architectures presented here are based upon standardsbased, commercially available products.

KEYWORDS mobile; mobile device; mobile device management; mobility management; mobile security

NIST SP 1800-4C: Mobile Device Security

ii

ACKNOWLEDGMENTS We are grateful to the following individuals for their generous contributions of expertise and time.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Name

Organization

Rick Engle

Microsoft

Kevin Fiftel

Intel

Paul Fox

Microsoft

Steve Kruse

Symantec

Tim LeMaster

Lookout

Nate Lesser

NIST National Cybersecurity Center of Excellence

Adam Madlin

Symantec

Kevin McPeak

Symantec

Rene Peralta

Microsoft

Atul Shah

Microsoft

Steve Taylor

Intel

The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build the example solutions. We worked with… Technology Partner/Collaborator

Build Involvement

Intel

Lenovo Miix 2.8 Mobile Device

Lookout

Enterprise Mobility Management Application

Microsoft

Microsoft Cloud Service, Company Portal, Intune, Office 365 Enterprise E3, Outlook & Community Portal Mobile

NIST SP 1800-4C: Mobile Device Security

iii

Technology Partner/Collaborator

Build Involvement Applications, System Center 2012 R2 Configuration Manager SP1, Windows Phone Operating System

Symantec

X.509 Certificate

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4. NIST SP 1800-4C: Mobile Device Security

iv

Contents

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2.1.1

Cloud Build Components ..............................................................................................4

2.1.2

Office 365 Setup............................................................................................................5

2.1.3

Office 365 MDM Setup ...............................................................................................14

3.2.1

Hybrid Build Components ...........................................................................................27

3.2.2

Enterprise Network and Firewall ................................................................................28

3.2.3

Enterprise Software Components for Hybrid .............................................................31

3.2.4

Cloud Services Instances .............................................................................................34

3.2.5

Hybrid Integration .......................................................................................................37

4.1.1

iOS ...............................................................................................................................84

4.1.2

Android .......................................................................................................................88

4.1.3

Windows Phone 8.1 ....................................................................................................90

4.1.4

Email Setup .................................................................................................................94

4.1.5

Lookout MTP Enrollment ..........................................................................................103

NIST SP 1800-4C: Mobile Device Security

v

List of Figures Figure 2-1 Cloud Build Process ............................................................................................................5 Figure 3-1 Hybrid Build Process ........................................................................................................ 25 Figure 3-2 Detailed Architecture ....................................................................................................... 26 Figure 3-3 Detailed Architecture with Network Addresses and Host Names ....................................... 27 Figure 3-4 List of Configured Interfaces ............................................................................................. 28

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Figure 3-5 WAN................................................................................................................................ 29 Figure 3-6 WAN Firewall Rules .......................................................................................................... 29 Figure 3-7 DMZ Firewall Rules .......................................................................................................... 30 Figure 3-8 LAN Firewall Rules ........................................................................................................... 30 Figure 3-9 Management Firewall Rules ............................................................................................. 31

List of Tables Table 1-1 Typographic Conventions ....................................................................................................2 Table 2-1 Cloud Build Components .....................................................................................................4 Table 3-1 Legend for Detailed Architecture Diagrams ........................................................................ 26 Table 3-2 Hybrid Build Components .................................................................................................. 27 Table 3-3 On-Premise Components of the Hybrid Build ..................................................................... 31

NIST SP 1800-4C: Mobile Device Security

vi

1 Introduction The following volumes of this guide show information technology (IT) professionals and security engineers how we implemented the example solutions to the challenge of securing email, contacts, and calendaring in mobile devices. We cover all the products that we employed in this reference design. We do not recreate the product manufacturer’s documentation, which is presumed to be widely available. Rather, these volumes show how we incorporated the products together in our environment.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

NOTE: These are not comprehensive tutorials. There are many possible service and security configurations for these products that are out of scope for this reference design.

1.1 Practice Guide Structure This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide demonstrates standards-based reference designs and provides users with the information they need to replicate this approach to mobile device security. This reference design is modular and can be deployed in whole or in part. This guide contains three volumes: ▪

NIST SP 1800-4A: Executive Summary

▪

NIST SP 1800-4B: Approach, Architecture, and Security Characteristics – what we built and why

▪

NIST SP 1800-4C: How-To guides – instructions for building the example solution (you are here)

Depending on your role in your organization, you might use this guide in different ways: Business decision makers, including chief security and technology officers, will be interested in the Executive Summary (NIST SP 1800-4A), which describes the following topics: ▪

challenges enterprises face in implementing and using mobile devices

▪

example solutions built at the NCCoE

▪

benefits of adopting the example solutions

Technology or security program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in NIST SP 1800-4B, which describes what we did and why. The following sections will be of particular interest: ▪ Section 3.4.3, Risk, which provides a description of the risk analysis we performed ▪ Section 3.4.4, Security Control Map, which maps the security characteristics of this example solution to cybersecurity standards and best practices You might share the Executive Summary, NIST SP 1800-4A, with your leadership team members to help them understand the importance of adopting standards-based enterprise mobility management (EMM) approaches to protect your organization’s digital assets.

NIST SP 1800-4C: Mobile Device Security

1

IT professionals who want to implement an approach like this will find the whole practice guide useful. You can use the How-To portion of the guide, NIST SP 1800-4C, to replicate all or parts of the build created in our lab. The How-To guide provides specific product installation, configuration, and integration instructions for implementing the example solutions. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solution.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

This guide assumes that IT professionals have experience implementing security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these particular products. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a solution that would support the deployment of mobile devices and the corresponding business processes. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope that you will seek products that are congruent with applicable standards and best practices.

1.2 Build Overview The NCCoE constructed the Mobile Device Security building block by using a virtualized environment and a physical wireless access point. The servers hosted by the virtualized environment were built to satisfy the hardware specifications of the specific software components in a small test environment (hard drive capacity, memory, etc.). The wireless access point was configured to use a closed lab network rather than directly internet connected. The mobile devices used in the build were configured to use this access point to simulate usage outside the traditional corporate network boundaries. Readers of this guide should assess the hardware needs of their environment carefully before implementation. Further, this build requires internet accessibility for some of the on-premise components that connect to commercial cloud services. We recommend configuring your firewall or other equipment to allow only internet access from on-premise systems to a specific internet protocol (IP) space provided by your cloud provider. Finally, this document makes heavy use of screenshots from cloud services set up through a web browser. The reader should be aware that the rapid development of cloud services may cause some differences in what is presented here with screenshots and what the implementer experiences. Refer to vendor documentation to address significant variations.

1.3 Typographic Conventions The following table presents typographic conventions used in this volume. Table 1-1 Typographic Conventions

NIST SP 1800-4C: Mobile Device Security

2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Typeface/ Symbol

Meaning

Example

Italics

File names and path names; references to documents that are not hyperlinks; new terms; and placeholders

For detailed definitions of terms, see the

Bold

names of menus, options, command buttons, and fields

Choose File > Edit.

Monospace

command-line input, on-screen computer output, sample code examples, status codes

mkdir

Monospace Bold

command-line user input contrasted with computer output

service sshd start

blue text

link to other parts of the document, a web URL, or an email address

All publications from NIST’s NCCoE are available at https://nccoe.nist.gov.

NIST SP 1800-4C: Mobile Device Security

NCCoE Glossary.

3

2 How-To: Build a Cloud-Based Solution to Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

This section of the practice guide contains detailed instructions for creating and configuring the cloud architecture depicted below. No software resources are necessary for this build because it is completely cloud based. The only hardware requirement is that the organization that implements this build uses mobile devices that are compatible with the cloud mobile device management (MDM). This building block chose to use mobile devices running iOS, Android, and Windows Phone — the top three operating systems in terms of market share [1]. This How-To guide details the creation, configuration, and enrollment aspects of each cloud service. Keep in mind, a prerequisite to the cloud is an internet domain name. If the implementer does not already have a domain name, one can be obtained from an accredited registrar [2]. You will need to be able to edit the resource records to prove ownership of the domain. The implementer will also need access to an Apple developer account to generate a push notification certificate for iOS devices. A push certificate allows the Office 365 instance to send push notifications to enrolled devices. Refer to the Apple website for pricing information and more details regarding certificates [3]. Further, during the configuration of the Office 365 MDM, you will be prompted to allow or block devices from Office 365 that cannot be managed. This can occur when a user has a device with an unsupported operating system. Select Block during this step to enhance the security of Office 365 services. Finally, we have chosen in this simple cloud build to leverage the MDM capabilities that are available within Office 365. This offers a more limited feature set than what is available through the Intune MDM service. Implementers looking for more capabilities should consider the Intune portion of the Hybrid How-To guide.

2.1 Cloud Build Setup and Configuration 2.1.1 Cloud Build Components The following components are used for this building block: Table 2-1 Cloud Build Components Make

Model

Version

Quantity

Microsoft

Office 365 Tenant

Business Premium

1

Google

Nexus (Android)

6 (5.1)

1

Apple

iPhone (iOS)

6 (8.3)

1

Nokia

Lumia (Windows Phone)

830 (8.10.14219.341)

1

N/A

Public Domain Name

N/A

1

NIST SP 1800-4C: Mobile Device Security

4

The cloud building block build process can be completed with the following high-level steps in Figure 21. The following sections in the How-To guide will focus on the final two steps. Figure 2-1 Cloud Build Process

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2.1.2 Office 365 Setup Office 365 is the central piece to the functionality of the cloud building block. The only prerequisite to this step is a public domain name. Keep in mind these steps may change as this is a web-based procedure. To start the process, use a web browser to access the following URL to start the process: https://products.office.com/en-us/business/office-365-enterprise-e3-business-software.

1. Choose a commitment level

NIST SP 1800-4C: Mobile Device Security

5

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Fill in the requested information in the next several screens

3. Choose Admin from the set of services

4. In the next steps, we will configure the domain name with Office 365. Choose the Domains option

NIST SP 1800-4C: Mobile Device Security

7

6. Choose Let's get started

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. Choose Add domain

8

NIST SP 1800-4C: Mobile Device Security

8. Choose Next

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. Enter your public domain name

9

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

9. At this point you need to add this information to the TXT record of your domain name. This functionality should be available from your registrar

10. Verify the Domain Name System (DNS) settings. The TXT record should match what was presented in the previous step. Note that it may take several minutes for the record to propagate to the Office 365 DNS servers

11. Choose Next NIST SP 1800-4C: Mobile Device Security

10

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

12. Choose Update selected users

13. Sign out to complete the change, and then sign in with your identification.

NIST SP 1800-4C: Mobile Device Security

11

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

14. Choose Next

15. Choose Next

12

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

16. Choose Next

13

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

17. Add the resource records presented in this step to your domain name. These are necessary for full functionality of the Office 365 tenant

2.1.3 Office 365 MDM Setup In the next section, you will be guided through the device management setup through Office 365. https://portal.office.com/Admin/Default.aspx#IntuneInventoryPage 1. Choose Get Started

NIST SP 1800-4C: Mobile Device Security

14

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Next, a security group needs to be created in order to apply the policy to a group of users. Navigate to Office 365 > Admin Center > Groups > +

3. Add a title and description for the group

NIST SP 1800-4C: Mobile Device Security

15

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Add members to the group to be managed

5. Go to Office 365 > Admin Center > Mobile Devices > Manage device security policies to configure a device policy to apply to enrolled devices

NIST SP 1800-4C: Mobile Device Security

16

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6. Choose to Block unsupported devices

7. Set the name for the actual device policy

NIST SP 1800-4C: Mobile Device Security

17

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

8. Set rules for the device policy

9. Set additional restrictions

NIST SP 1800-4C: Mobile Device Security

18

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

10. Select whether to deploy the policy and to what group

11. Select the group created earlier to apply the policy

2.1.3.1 Configure Push Certificate for iOS Devices As noted in the introduction to this section, an Apple push notification (APN) certificate is required for full functionality with Apple iOS devices. Only Apple can sign these certificates.

NIST SP 1800-4C: Mobile Device Security

19

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Set up APN in Office 365 > Admin Center > MobileDevices > Manage Settings

2. Configure an APNs Certificate for iOS devices > Set up

NIST SP 1800-4C: Mobile Device Security

20

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Download certificate signing request (CSR). Once the CSR is generated, it can be submitted to Apple for signing. Use a browser to visit: https://identity.apple.com/pushcert/.

4. You will be prompted for your Apple Developer account credentials. Sign in

NIST SP 1800-4C: Mobile Device Security

21

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. Once authenticated, choose Create a certificate. Review the terms and conditions screen

NIST SP 1800-4C: Mobile Device Security

22

6. When creating the certificate, you will be presented with a screen to submit your CSR. Use the Browse button to navigate to where you stored your CSR file and choose Upload

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. After the upload, refresh the page. You will be presented with a list of signed certificates. Choose the download option for your new certificate, which will allow you to save the signed certificate in privacy enhanced mail (PEM) format

NIST SP 1800-4C: Mobile Device Security

23

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

8. Return to Office 365, and upload the signed APN certificate from Apple’s developer portal

9. Verify that the APN is working correctly. It should have an expiration date listed

NIST SP 1800-4C: Mobile Device Security

24

3 How-To: Build an On-Premises Solution for Mobile Device Security 3.1 Hybrid Build Setup and Configuration

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Figure 3-1 depicts the high-level procedures to reproduce the hybrid build used in this building block. First, the implementer must own an internet domain name or have permission to edit resource records within a domain. This is a prerequisite to integration with the cloud services used within this build. The next set of steps configure the on-premise components. The procedures assume that no on-premise components have been installed, however implementers may wish to skip to the configuration sections if these components are already in place. In general, this guide defers to vendor documentation for installation procedures. The final set of steps instantiate the cloud services and integrate them into the on-premise components. Figure 3-1 Hybrid Build Process

An important prerequisite to using Active Directory Federation Services (ADFS) in this hybrid arrangement is a third-party public key certificate issued from a reputable certificate authority. In this build we used Symantec’s Secure Site Pro service. You may also want to purchase a third-party certificate to secure the Transport Layer Security channel on the system that hosts the application proxy to avoid web browser warnings/errors when users authenticate to the enterprise. Please refer to TechNet articles [4] and [5] for specific requirements. Finally, there are several cloud-based services that provide functionality similar to the one chosen in this build. We use Microsoft’s Office 365 for email/calendaring/contacts management and Intune to manage mobile devices. The implementer should note that email/calendaring/contact and MDM from different vendors may not offer the same out-of-the-box integration as what we have chosen here. For example, we have set a compliance rule that forces the mobile device to be enrolled with the MDM before it is given access to email/calendaring/contacts.

3.2 Hybrid Detailed Architecture The following architecture diagrams depict the final architecture of the hybrid build after implementing this guide. Figure 3-2 calls out the various protocols implemented among the on-premise, cloud, and mobile device components. Figure 3-3 is a similar view but details the network addressing and host names that were used during the build.

NIST SP 1800-4C: Mobile Device Security

25

Figure 3-2 Detailed Architecture

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Table 3-1 Legend for Detailed Architecture Diagrams Acronym

Term

AD

Active Directory

ADDS

Active Directory Domain Service

ADFS

Active Directory Federation Services

DMZ

Demilitarized Zone

HTTPS

Hyper Text Transfer Protocol Secure

ISP

Internet Service Provider

LDAP

Lightweight Directory Access Protocol

MGMT

Management Network

TLS

Transport Layer Security

WAP

Wireless Access Point

NIST SP 1800-4C: Mobile Device Security

26

Figure 3-3 Detailed Architecture with Network Addresses and Host Names

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3.2.1 Hybrid Build Components The following components are used for this building block: Table 3-2 Hybrid Build Components Make

Model

Version

Quantity

Lookout Mobile Security

Lookout Security for Work Application

2.0.150

1

Lookout Mobile Security

Mobile Threat Protection

Microsoft

Office 365 Tenant

Business Premium

1

Lenovo

Miix (Windows)

2.8 (8.1)

1

Google

Nexus (Android)

6 (5.1)

1

Apple

iPhone (iOS)

6 (8.3)

1

Nokia

Lumia (Windows Phone)

830 (8.10.14219.341)

1

Microsoft

Windows Server

2012 R2

5

Open Source

pfSense

Microsoft

Windows

NIST SP 1800-4C: Mobile Device Security

1

1 7

1

27

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Make

Model

Version

Quantity

Microsoft

System Center Configuration Manager (SCCM)

1

Microsoft

AD DS

1

Microsoft

AD FS

1

Microsoft

AAD Sync

1

Microsoft

Web Application Proxy

1

Microsoft

Intune

N/A

Symantec

Public Certificates

N/A

N/A

Public Domain Name

N/A

1 1

3.2.2 Enterprise Network and Firewall The build uses pfSense for the organization router/firewall (see figure above). It is a combination router and firewall configured as a virtual device. This subsection describes the configuration used in the build and how to create it. A single firewall configuration was chosen for simplicity and flexibility in a lab environment, but a dual firewall configuration could also be implemented. Only IPv4 is used and IPv6 is disabled for simplicity. To install and configure pfSense, implementers should refer to pfSense documentation for installation and configuration instructions. To re-create the build’s configuration, follow the instructions in the documentation and use the configuration files made available by pfSense (pfSense Configuration Files: Interfaces — interfaces-config-pfSense.localdomain-20150402160851.xml; NAT — nat-configpfSense.localdomain-20150402160838.xml; Firewall — filter-config-pfSense.localdomain20150402160823.xml) The following screenshots show the final configuration of the pfSense device. Access pfSense through its web interface. The default screen includes a list of interfaces described as part of the architecture in the Hybrid Build Architecture section. The individual interfaces are described below with the firewall rules. Figure 3-4 List of Configured Interfaces

The build network is configured to use network address translation (NAT). The following port forwarding is set up to allow communication from outside the lab into the build network. NIST SP 1800-4C: Mobile Device Security

28

Figure 3-5 WAN

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Several firewall rules are configured to control access through the subnetworks. The following screenshots show these rules for the wide-area network (WAN), demilitarized zone (DMZ), local area network (LAN), and management network (MGMT). Figure 3-6 WAN Firewall Rules

The WAN configuration information is specific to our Internet Service Provider (ISP). In this lab, we provided the 10.33.1.0/24 network from which to statically assign addresses. 10.33.1.105 is the pfSense device’s IP address, and 10.33.1.104 is also assigned as a virtual IP address for the WAP service. Firewall rules are configured to allow internet access to the WAP in the DMZ in order for Microsoft’s ADFS to function.

NIST SP 1800-4C: Mobile Device Security

29

Figure 3-7 DMZ Firewall Rules

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

In pfSense our DMZ is assigned as DMZ (OPT2) using the network 192.168.3.0/24. It is not allowed to access the intranet or management networks, except for specific rules for DNS and ADFS access. 192.168.1.10 is the IP address of the Active Directory server. 192.168.1.20 is the IP address of the ADFS server. Figure 3-8 LAN Firewall Rules

In pfSense our LAN is using the network 192.168.1.0/24. It is not allowed to access the MGMT network.

NIST SP 1800-4C: Mobile Device Security

30

Figure 3-9 Management Firewall Rules

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

In pfSense our management network is assigned as MGMT (OPT1) using the network 192.168.2.0/24. It has access to all networks.

3.2.3 Enterprise Software Components for Hybrid The following section describes installation of the on-premise components of the hybrid build. As noted previously, this guide provides references to the vendor’s documentation for installation to better customize the component to the target environment. Alternatively, implementers may replicate this build exactly by using the following table, which maps each component to the exact system used in architecture diagram Figure 3-2, Detailed Architecture. Table 3-3 On-Premise Components of the Hybrid Build Component

Host Name

IP Address

Active Directory Domain Services

mds00

192.168.1.10

Active Directory Federation Services

mds-adfs

192.168.1.20

Active Directory Federation Services Proxy

wap

192.168.3.104

Systems Center Configuration Manager

mdssccm

192.168.1.102

Azure Active Directory Sync Services

mds-adsync

192.168.1.21

In order to increase security from the default server configuration, the Security Configuration Wizard (SCW) included with Windows Server 2012 R2 was used on each server after installation. These policies were saved as XML files and are available for download. They can be viewed, edited, and applied with the SCW tool.

3.2.3.1 Active Directory Domain Services The Active Directory Domain Services (ADDS) instance used in the hybrid build was created by using basic configuration settings offered through the Add Roles and Features Wizard. The system was deployed as a new forest with a domain name of nccoe.local. Implementers of this guide who seek more

NIST SP 1800-4C: Mobile Device Security

31

details of an ADDS installation can consult an Install Active Directory Domain Services [6] TechNet article. Alternatively, implementers may wish to use a lab environment for their development [7]. After installation, the implementer should create an organizational unit (OU) to hold users who are to be synced with the Office 365 tenant. Create test accounts in this OU of users that will represent individual device owners. Or, as mentioned previously, create users from a production environment.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The domain controller will find the user’s account based upon the userPrincipalName in the certificate’s Subject Alternative Name field. The original domain controller was set up with a domain of nccoe.local. However, a more likely scenario would have an organization create an instance under a well-known toplevel domain. We have addressed this issue by adding a User Principal Name (UPN) for hmdsbb.org in the ADDS configuration. All users in this configuration are required to have a UPN of <user>@hmdsbb.org. Identity federation between Intune and on-premise ADFS will fail if the users do not have the appropriate UPN. The procedures to configure a UPN suffix are as follows: 1. 2. 3. 4.

Launch Active Directory Domain and Trusts snap-in Right-click on the top-level Active Directory Domains and Trusts Select Properties In UPN Suffixes tab add hmdsbb.org and ad.hmdsbb.org domain suffixes

3.2.3.2 Active Directory Federation Service Readers of this guide should refer to Microsoft documentation for specific installation instructions for their environment. Consult the referenced articles as a starting point for installation [8], [9]. Implementers should note the requirement of a certificate issued from a certificate authority that is recognized/trusted by Microsoft. In this demonstration, the build team procured certificates from Symantec’s Secure Site Pro Secure Sockets Layer (SSL) service. Ensure that the provider is able to populate the Subject Alternative Name extension of the certificates used in the implementation. Screenshots below are of the certificates from Symantec used in the build. NIST SP 1800-4C: Mobile Device Security

32

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3.2.3.3 Active Directory Federation Services Proxy Refer to the articles referenced in the Active Directory Federation Service section for specific installation instructions.

3.2.3.4 Systems Center Configuration Manager Readers of this guide should refer to Microsoft documentation for specific installation instructions for their environment. Consult the following Test Lab Guide as a starting point for installation [10].

NIST SP 1800-4C: Mobile Device Security

33

3.2.3.5 Azure Active Directory Sync Services Refer to the referenced article for Azure Active Directory Sync Tool installation procedures [11]. Default options were used for this build.

3.2.4 Cloud Services Instances After the on-premise components have been installed, the cloud services must be created. This section walks the implementer through the basic steps of creating Office 365, Intune, and Lookout accounts.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3.2.4.1 Office 365 Setup The setup of the Office 365 service is the same as what has been previously described for the cloud build in section 3.1. We replaced cmdsbb.org with hmdsbb.org for this build.

3.2.4.2 Intune Setup Use a browser to access the following URL to start the Intune creation process: http://www.microsoft.com/en-us/server-cloud/products/microsoft-intune/

1. Choose Try Now

NIST SP 1800-4C: Mobile Device Security

34

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Sign up for a trial license when prompted

3. Choose Try Now Sign-up is complete, and you should be redirected to the Intune management console at https://manage.microsoft.com. Note that the Silverlight 3.0 browser support is required to load the management console.

NIST SP 1800-4C: Mobile Device Security

35

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Important! Do not proceed any further with Intune if you want to manage devices via SCCM.

3.2.4.3 Lookout Setup Contact the enterprise sales team at support@lookout.com to create an account.

1. After your account has been created, the designated administrators will receive an email instructing them to reset their password. Click the link and reset the password

NIST SP 1800-4C: Mobile Device Security

36

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Open the Lookout administrative console to access the Lookout administrator functions by using a browser and navigating to https://mtp.lookout.com/les

3.2.5 Hybrid Integration This section documents the integration of cloud and on-premise services.

3.2.5.1 Office 365 with Active Directory Federation Setup In this step, an on-premise ADFS server is integrated with the Office 365 service. The purpose of this integration is to provide identity federation between Office 365 and enterprise authentication service. You should have previously added your public domain to Office 365 in the Office 365 Setup section. If not, follow the procedures from TechNet Magazine [12]. Detailed integration information can be found in the referenced TechNet article [9]. 1. Connect ADFS with your Office 365 instance by issuing the following two commands. This step will automatically exchange the required metadata to implement federation with Office 365 Set-MsolAdfscontext -Computer <AD FS server FQDN> Convert-MsolDomainToFederated -DomainName <domain name>

3.2.5.2 Azure Active Directory Sync Services For this step, we configure synchronization of the organization’s enterprise Active Directory with the Office 365 directory. This service will periodically sync identities — adding, deleting, or otherwise modifying from the on-premise Active Directory to the Azure Active Directory instance when this step is completed. This build accepted the default syncing schedule, but it may be tuned at a later time.

NIST SP 1800-4C: Mobile Device Security

37

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Launch the Sync Services Configuration Tool. Input the global administrator credentials for the Office 365 instance and click Next

2. Input the Forest name and credentials of the administrator. Click Add Forest

NIST SP 1800-4C: Mobile Device Security

38

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Click Next

4. Accept the defaults for uniquely identifying your users. Click Next

NIST SP 1800-4C: Mobile Device Security

39

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. Do not choose any of the optional features. Click Next

6. Click Configure

NIST SP 1800-4C: Mobile Device Security

40

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. Choose to Synchronize now and click Finish

8. If successful, the added connectors will be displayed in the Synchronization Service Manager

3.2.5.3 Sync Intune with Office 365 Exchange The following steps will establish a back-end connection between the Intune and Office 365 instances, which were created in the Cloud Services Instances section. When this step is completed, Intune will have the ability to enforce conditional access policies on all enrolled mobile devices.

NIST SP 1800-4C: Mobile Device Security

41

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Open the Intune administrative console with a browser. Click ADMIN

2. Click Set Up Exchange Connection within the Microsoft Exchange section 3. Click Set Up Service to Service Connector The configuration with Office 365 will occur in the background. No further actions are required.

3.2.5.4 Manage Intune with SCCM To allow the Intune tenant to be administered remotely, SCCM must be configured on the enterprise network. The following steps add test accounts to an SCCM user collection and syncs with the Intune tenant. While Intune will be available through the browser-based administrative console after this exercise, the account will be permanently configured to manage devices through SCCM. 3.2.5.4.1 Configure Active Directory User Discovery When these steps have been completed, the SCCM instance will be able to automatically discover Intune users by way of an Active Directory container. 1. Launch the Configuration Manager console. Navigate to System Center Configuration Manager /Site Database/Site Management/<site name>/Site Settings/Discovery Methods NIST SP 1800-4C: Mobile Device Security

42

2. Right-click Active Directory User Discovery, and then click Properties 3. On the General tab, click the New icon to specify a new Active Directory container 4. On the New Active Directory Container dialogue box, specify Local Domain

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. Select the AzureAD Synced Users container

6. The path will reflect the container chosen in the previous step. Click OK

NIST SP 1800-4C: Mobile Device Security

43

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. Ensure Enable Active Directory User Discovery is selected. Click OK

8. After configuration, the status of the Active Directory User Discovery will be Enabled

NIST SP 1800-4C: Mobile Device Security

44

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

9. Navigate to Users > All Users to view accounts synced from Active Directory 3.2.5.4.2 Register SCCM with Intune The following sequence of steps enrolls an SCCM instance with the Intune tenant. After this step you will no longer be able to create and deploy policies from the Intune web management portal. 1. Start the Intune Subscription wizard by opening the Configuration Manager. In the Administration section, expand Cloud Services, and click Microsoft Intune Subscriptions. Click on the Home tab and then Add Microsoft Intune Subscription

NIST SP 1800-4C: Mobile Device Security

45

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Click Next

3. Click the Sign In button

46

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Sign in using an administrative user from the Intune tenant

5. Authorize a collection of users to enroll with Intune. Click Next

NIST SP 1800-4C: Mobile Device Security

47

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6. You may choose to configure device types in this step. However, we chose to configure these in a later step. Click Next

7. Enter the contact information for your organization. This is optional. Click Next

NIST SP 1800-4C: Mobile Device Security

48

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

8. Submit an organizational logo, if desired. Click Next

9. Review the settings and click Next

NIST SP 1800-4C: Mobile Device Security

49

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

10. Close the wizard after the configuration completes. A green check mark indicates success for that task

11. The Intune administrative console reflects SCCM management after configuration has been completed 3.2.5.4.3 Configure Push Certificate for iOS Devices A push notification certificate is required for full functionality with Apple iOS devices. Only Apple can sign these certificates. Once the CSR is generated, it can be submitted to Apple for signing. The following procedure shows how to create the CSR within SCCM.

NIST SP 1800-4C: Mobile Device Security

50

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Click Create APNs certificate request in the SCCM console

2. Save the CSR to local storage. Youʼll need this file for the next step

NIST SP 1800-4C: Mobile Device Security

51

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Use a browser to visit https://identity.apple.com/pushcert/. You will be prompted for your Apple Developer account credentials.

4. Once authenticated, choose Create a certificate

NIST SP 1800-4C: Mobile Device Security

52

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. Review the terms and conditions screen. You will be presented with a screen to submit your CSR. Use the Browse… button to navigate to where you stored your CSR file, and choose Upload

NIST SP 1800-4C: Mobile Device Security

53

6. After the upload, refresh the page. You will be presented with a list of signed certificates. Choose the download option for your new certificate, which will allow you to save the signed certificate in PEM format

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. Load the signed certificate into SCCM. Navigate to Administration > Overview > Cloud Services > Windows Intune Subscriptions. Right-click on Windows Intune Subscription and choose Properties 8. Check the box to enable iOS enrollment and use the Browse… button to import the PEM certificate you downloaded from Apple. Click OK 3.2.5.4.4 Mobile Policy Creation The following section depicts creation and deployment of a security policy to mobile devices in the building block test environment. The reader should note that not all options are available to every mobile operating system. Generally, iOS offers more fine-grain device management capabilities than Android; however, a KNOX-enabled Samsung Android device augments the base Android capabilities with additional management functions. More information regarding specific capabilities of supported mobile platforms can be found on TechNet [13]. 1. Launch the Create Configuration Item Wizard from the SCCM Configuration Manager. In the Assets and Compliance section, click Configuration Items in the Compliance Settings folder. Click Create Configuration Item from the toolbar

NIST SP 1800-4C: Mobile Device Security

54

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Give the configuration a name and specify in the drop-down that this configuration item is for mobile devices. Click Categories…

3. Select the Client category. Click OK

NIST SP 1800-4C: Mobile Device Security

55

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Select Password, Device, Security, and Encryption setting groups. Click Next

5. Configure the password requirements based on your local requirements

NIST SP 1800-4C: Mobile Device Security

56

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6. Configure the device settings based on your local requirements

7. Configure the security settings based on your local requirements

NIST SP 1800-4C: Mobile Device Security

57

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

8. Configure the encryption settings based on your local requirements

9. Select the mobile platforms you wish to support. Click Next

NIST SP 1800-4C: Mobile Device Security

58

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

10. Click Next

11. Click Next

59

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

12. Click Close

13. Click Create Configuration Baseline by right-clicking Configuration Baseline from the Configuration Manager

NIST SP 1800-4C: Mobile Device Security

60

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

14. Name the baseline policy. Add the baseline configuration created in the previous steps and click OK

3.2.5.4.5 Create Mobile Application Policy This section describes how to roll out mobile application policy for the Outlook mobile application. The policy is automatically deployed when the device owner installs the application for the first time. First, the SCCM administrator will create a new application management policy, then associate an application NIST SP 1800-4C: Mobile Device Security

61

to the newly created policy. The following procedures feature the iOS platform, but the process is essentially the same for other platforms.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. To start the wizard, navigate to Under Software Library > Application Management > Application Management Policies: Create Policy in the SCCM console. Name the policy and click Next

NIST SP 1800-4C: Mobile Device Security

62

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Choose the platform type and policy type. In this example, a policy is being deployed to an iOS application. Click Next

NIST SP 1800-4C: Mobile Device Security

63

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Set the specifics of the policy as pictured. Click Next

NIST SP 1800-4C: Mobile Device Security

64

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

Upon successful creation, an overview is displayed. In order to use this policy, it needs to be matched with an application. In the next section, the Outlook application is linked to the iOS application store through Company Portal and associated with the previously created application policy.

NIST SP 1800-4C: Mobile Device Security

65

3.2.5.4.6 Link an Application to a Previously Created Mobile Application Policy

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Navigate to Software Library > Applications and Create Application. The admin will be prompted for a link to the application store application that they wish to link in the Location field. Search for the Outlook application using a search engine, and copy the link

NIST SP 1800-4C: Mobile Device Security

66

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Set the Name, Publisher, and Software version information for the application link as pictured

NIST SP 1800-4C: Mobile Device Security

67

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Click Next to confirm the settings

68

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Important: Deploy the application to a user collection instead of a device collection

NIST SP 1800-4C: Mobile Device Security

69

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. After setting the general settings for deploying the application, the admin will get a chance to link an application profile. Further configuration of the General Settings was not required for our purposes 3.2.5.4.7 Configure SCCM with Lookout Application This section describes integration of the Lookout mobile application with SCCM. When completed, the mobile device user will receive a link to download the Lookout application after enrollment with the MDM. The link URL will differ based on the mobile platform. Android users will be directed to the Google Play Store, iOS users to the App Store, and Windows Phone users to the Windows Phone store.

NIST SP 1800-4C: Mobile Device Security

70

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. To start the wizard, navigate to General. Select App Package for Android on Google Play in the Type drop-down. Type https://play.google.com/store/apps/details?id=com.lookout.enterprise&hl=en in the Location field.

NIST SP 1800-4C: Mobile Device Security

71

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Click Next

72

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Use the suggested text in the Name and Publisher fields. Click Next

NIST SP 1800-4C: Mobile Device Security

73

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Click Next

74

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. Click Close

75

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6. Open the application deployment wizard. In the Software field, browse for the Lookout application. In the Collection field, browse for All Users

NIST SP 1800-4C: Mobile Device Security

76

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. Click Next

77

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

8. In the Action drop-down, choose Install. In the Purpose drop-down, choose Available. Click Next

NIST SP 1800-4C: Mobile Device Security

78

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

9. Click Next

79

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

10. In the User notifications drop-down, choose Display in Software Center and show all notifications

NIST SP 1800-4C: Mobile Device Security

80

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

11. Click Next

81

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

12. Click Next

82

NIST SP 1800-4C: Mobile Device Security

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

13. Click Close

83

NIST SP 1800-4C: Mobile Device Security

4 How-To: Device Configuration The following section steps through the configuration of devices. This section is applicable to both the cloud and hybrid builds. Here, we feature enrollment and email configuration with iOS, Android, and Windows Phone operating systems.

4.1 Device Enrollment with Office 365 This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The following sections depict the enrollment process of an iOS and Android device to the Intune enterprise mobility management service. The reader should note that the Intune service will automatically redirect the user to the Intune tenant owner’s authentication service based on the domain part presented in the user’s email address. The authentication service must be accessible via the internet if users enroll remotely. Otherwise, an organization must make its authentication service available on a local network accessible by device users. Instruct device owners to download the Company Portal application through the application distribution point of their platform to start the enrollment process. The URLs for iOS and Android devices are https://itunes.apple.com/us/app/microsoft-intune-company-portal/id719171358?mt=8 and https://play.google.com/store/apps/details?id=com.microsoft.windowsintune.companyportal&hl=en respectively. This is not necessary for Windows Phone devices because MDM management through this service is native to the device.

4.1.1 iOS Device enrollment for iOS devices is described in the following material.

1. Download the Company Portal application from the application store and log in using Office 365 credentials NIST SP 1800-4C: Mobile Device Security

84

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. The user will then be asked to enroll their device and accept the organization’s policies

3. Before accepting the management profile, the user can see the specifics of the profile and certificates that are issued

NIST SP 1800-4C: Mobile Device Security

85

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Upon accepting the management profile, the device will be enrolled, and the user will receive this confirmation message

In order to gain full access to company resources, the user will need to check their device for compliance. This screen will pop up when the user taps on their device in Company Portal

NIST SP 1800-4C: Mobile Device Security

86

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. The compliance checking process will take a couple of minutes, and the user can minimize the application during this process

6. Upon minimizing the Company Portal application during the compliance checking process, the user is presented with the password remediation process, alerting the user to change their passcode within the hour

NIST SP 1800-4C: Mobile Device Security

87

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

7. After meeting compliance, the user’s device should be listed in the Company Portal like the example above

4.1.2 Android

1. After launching the Company Portal, click Next

NIST SP 1800-4C: Mobile Device Security

88

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. Enter your email address

3. If implementing a hybrid architecture, you will be redirected to your enterprise login site to enter your password. Otherwise, enter password and click Sign In. The user will be notified when they are signing into the Company Portal and when their device is being enrolled

NIST SP 1800-4C: Mobile Device Security

89

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Click Activate to allow remote management of the device

4.1.3 Windows Phone 8.1

1. First, the user must add a workplace to their device. To do so on Windows Phone 8 and 8.1 devices navigate to settings > system tab > workplace (WP8.1) or settings > system tab > company apps (WP8)

NIST SP 1800-4C: Mobile Device Security

90

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

2. The workplace application will attempt to connect to your company’s management portal. We used the manage.microsoft.com portal

3. After connecting to your company’s portal, the device should now be able to be managed by Office 365. To do this, download Company Portal from the App Store to finish enrolling the device and receive your organization’s policies

NIST SP 1800-4C: Mobile Device Security

91

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

4. Upon logging into Company Portal for the first time, the user will be notified that their device hasn’t met compliance and that some resources will be restricted

5. After the user checks the compliance manually (less than five minutes), the user’s device is fully enrolled and should have the appropriate policies deployed

NIST SP 1800-4C: Mobile Device Security

92

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

6. The screenshot above displays the details and policy compliance status of how a compliant and fully enrolled device should look

7. Once compliance has been met, the user should be able to tap the activation link to activate their email access

NIST SP 1800-4C: Mobile Device Security

93

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

8. The activation link will open a browser. Upon successful activation, the user should receive this page. At this point, the user should have full access to Exchange email/contacts/calendar

4.1.4 Email Setup The following section steps through the setup of email clients on iOS, Android, and Windows Phone. For iOS and Android, we use the Outlook client from Microsoft in the App Store and Play Store. The native email capabilities are used with Windows Phone. Other third-party applications are available, but this guide makes no assumptions regarding the security of these applications. Implementers may choose to have users configure an email client on their devices manually or create an SCCM profile, which automatically configures enrolled devices. At the time of writing this practice guide, only iOS and Microsoft mobile devices were supported. Consult SCCM documentation for the latest capabilities.

NIST SP 1800-4C: Mobile Device Security

94

4.1.4.1 iOS

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. When the user first opens the settings application — before, during, or after the compliance check — they are prompted for their Office 365 password for the Exchange profile that is provisioned during the onboarding process. (This is a onetime occurrence)

2. The user will receive this email the first time they open their email client

NIST SP 1800-4C: Mobile Device Security

95

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. To activate their email access, the user will have to tap the link to activate the email and check for compliance

4. After activating their email, the user will be presented with an enrollment activated confirmation page

NIST SP 1800-4C: Mobile Device Security

96

4.1.4.2 Android

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Open the Outlook application on your device

2. Choose Office 365

NIST SP 1800-4C: Mobile Device Security

97

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Log in with your enterprise credentials

4. Note that if you are using the hybrid build, a single sign-on workflow is initiated. The device owner will be redirected to their local sign-in service

NIST SP 1800-4C: Mobile Device Security

98

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. If the device has not been enrolled with the MDM, a prompt is presented to do so

6. A device that is out of compliance with the MDM policy will not have access to Office 365 services. The device owner is forced to remediate the device

NIST SP 1800-4C: Mobile Device Security

99

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

The device owner is granted access to Office 365 after the device complies with policy

4.1.4.3 Windows Phone 8.1

1. To get full access to Exchange resources as well as email, use the built-in email client to add an Exchange account. In the email client, tap the three horizontal dots on the bottom right and tap add account to bring up the account select page. Or under settings > email+ accounts add the Office 365 Exchange account credentials 2. Log in using Office 365 credentials; the server information should auto-populate

NIST SP 1800-4C: Mobile Device Security

100

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Upon successfully syncing the Exchange account, an email explaining the enrollment process should be received requesting that the user enroll/check for compliance

4.1.4.4 Windows 8.1 Email profiles for Windows Mobile 8.1 were configured using the following steps. 1. The user can add their account to the built-in email application by selecting Exchange account and adding their email@customdomain and password. The email application should be able to pull the settings

NIST SP 1800-4C: Mobile Device Security

101

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4. 2. Upon connecting to their Exchange account, the user should receive an email asking them to activate their email by clicking the link to check compliance

NIST SP 1800-4C: Mobile Device Security

102

4.1.5 Lookout MTP Enrollment

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Open the Lookout Mobile Threat Protection (MTP) administrative console with a browser. Navigate to https://mtp.lookout.com/les/devices/enroll and type the target user’s email address into the provided web field

2. The mobile device user will receive an email with an activation code that must be used to activate the application NIST SP 1800-4C: Mobile Device Security

103

4.1.5.1 Android

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

1. Find the MTP application from the Google Play Store by searching “lookout”

2. Select the Lookout Security for Work application

NIST SP 1800-4C: Mobile Device Security

104

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

3. Enter the activation code retrieved from the enrollment email

4. Select OK after the activation code is validated

NIST SP 1800-4C: Mobile Device Security

105

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

5. The application will proceed to scan the device.

6. The application notifies the user of any threats on the device

NIST SP 1800-4C: Mobile Device Security

106

Appendix A

List of Acronyms

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

AD

Active Directory

ADDS

Active Directory Domain Service

ADFS

Active Directory Federation Services

APN

Apple Push Notification

BYOD

Bring Your Own Device

COPE

Corporately Owned, Personally Enabled

DMZ

Demilitarized Zone

DNS

Domain Name System

EMM

Enterprise Mobility Management

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Secure

ISP

Internet Service Provider

LAN

Local Area Network

MDM

Mobile Device Management

MDS

Mobile Device Security

MGMT

Management Network

MTP

Mobile Threat Protection

NCCoE

National Cybersecurity Center of Excellence

NIST

National Institute of Standards and Technology

NSA

National Security Agency

OU

Organizational Unit

PEM

Privacy Enhanced Mail

SCW

Security Configuration Wizard

NIST SP 1800-4C: Mobile Device Security

107

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

SP

Special Publication

SSL

Secure Sockets Layer

TLS

Transport Layer Security

UPN

User Principal Name

WAN

Wide Area Network

WAP

Wireless Access Point

NIST SP 1800-4C: Mobile Device Security

108

Appendix B

References

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.1800-4.

[1]

International Data Corporation, Android and iOS Squeeze the Competition, Feb. 24, 2015. Available: https://www.businesswire.com/news/home/20150224006498/en/Android-iOS-SqueezeCompetition-Swelling-96.3-Smartphone.

[2]

Internet Corporation for Assigned Names and Numbers-Accredited Registrars, Dec. 11, 2018. Available: https://www.icann.org/registrar-reports/accredited-list.html.

[3]

Apple website for pricing information and more details regarding certificates. Available: https://developer.apple.com.

[4]

Microsoft, “Plan for third-party SSL certificates for Office 365,” Oct. 23, 2017. Available: https://docs.microsoft.com/en-us/office365/enterprise/plan-for-third-party-ssl-certificates.

[5]

Microsoft, “Understanding Certificate Requirements,” July 22, 2014. Available: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-141/gg476123(v=exchg.141).

[6]

Microsoft, “Install Active Directory Domain Services (Level 100),” May 30, 2017. Available: https://technet.microsoft.com/en-us/library/hh472162.aspx.

[7]

Microsoft, “Use a lab environment for your devops,” May 1, 2017. Available: https://docs.microsoft.com/en-us/visualstudio/test/lab-management/using-a-lab-environment-for-your-application-lifecycle?view=vs-2017.

[8]

Microsoft, “How To Install ADFS 2012 R2 For Office 365,” Apr. 28, 2014. Available: http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365.aspx.

[9]

Microsoft, Office 365 and ADFS…Active Directory Federation Service Installation, Feb. 10, 2018. Available: https://social.technet.microsoft.com/wiki/contents/articles/9082.office-365-and-adfsactive-directory-federation-service-installation.aspx?Redirected=true.

[10]

Microsoft, Test Lab Guide: System Center 2012 Configuration Manager. Available: https://www.microsoft.com/en-us/download/confirmation.aspx?id=30443.

[11]

Microsoft, Azure Active Directory Sync, Nov. 8, 2015. Available: https://docs.microsoft.com/enus/previous-versions/azure/azure-services/dn790204(v%3dazure.100) .

[12]

Microsoft, Geek of All Trades: Office 365 SSO: A Simplified Installation Guide, Aug. 30. 2016. Available: https://docs.microsoft.com/en-us/previous-versions/technet-magazine/jj631606(v=msdn.10).

[13]

Microsoft, Manage settings and features on your devices with Intune policies, June 13, 2018. Available: https://technet.microsoft.com/en-us/library/dn913730.aspx .

NIST SP 1800-4C: Mobile Device Security

109

Related documents

• NIST SP 1800-22: Mobile Device Security: Bring Your Own Device (BYOD)#2831
• NIST SP 800-163r1: Vetting the Security of Mobile Applications#2913
• NIST SP 1800-34: Validating the Integrity of Computing Devices#2843
• A Survey of Privacy Vulnerabilities of Mobile Device Sensors#400466
• NIST SP 800-101r1: Guidelines on Mobile Device Forensics#2856