NIST SPECIAL PUBLICATION 1800-21B

Mobile Device Security:

Corporate-Owned Personally-Enabled (COPE)

Volume B:

Approach, Architecture, and Security Characteristics

Joshua M. Franklin*

Gema Howell

Kaitlin Boeckl

Naomi Lefkovitz

Ellen Nadeau*

Applied Cybersecurity Division Information Technology Laboratory

Dr. Behnam Shariati

University of Maryland, Baltimore County Department of Computer Science and Electrical Engineering Baltimore, Maryland

Jason G. Ajmo

Christopher J. Brown

Spike E. Dog

Frank Javar

Michael Peck

Kenneth F. Sandlin

The MITRE Corporation McLean, Virginia

*Former employee; all work for this publication done while at employer.

September 2020

Final

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

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

DISCLAIMER

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.

National Institute of Standards and Technology Special Publication 1800-21B Natl. Inst. Stand. Technol. Spec. Publ. 1800-21B, 147 pages, (September 2020), 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.

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

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

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 information technology security—the NCCoE applies standards and best practices to develop modular, 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 re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland.

To learn more about the NCCoE, visit https://www.nccoe.nist.gov.
To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES

NIST Cybersecurity Practice Guides (Special Publication 1800 series) 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 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

Mobile devices provide access to vital workplace resources while giving employees the flexibility to perform their daily activities. Securing these devices is essential to the continuity of business operations.

While mobile devices can increase efficiency and productivity, they can also leave sensitive data vulnerable. Mobile device management tools can address such vulnerabilities by helping secure access to networks and resources. These tools are different from those required to secure the typical computer workstation.

This practice guide focuses on security enhancements that can be made to corporate-owned personally-enabled (COPE) mobile devices. COPE devices are owned by an enterprise and issued to an employee. Both the enterprise and the employee can install applications onto the device.

To address the challenge of securing COPE mobile devices while managing risks, the NCCoE at NIST built a reference architecture to show how various mobile security technologies can be integrated within an enterprise’s network.

This NIST Cybersecurity Practice Guide demonstrates how organizations can use standards-based, commercially available products to help meet their mobile device security and privacy needs.

KEYWORDS

Corporate-owned personally-enabled; COPE; mobile device management; mobile device security, on-premise; bring your own device; BYOD

ACKNOWLEDGEMENTS

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

Name	Organization
Donna Dodson	NIST
Vincent Sritapan	Department of Homeland Security, Science and Technology Directorate
Jason Frazell	Appthority (acquired by Symantec—A division of Broadcom)
Joe Midtlyng	Appthority (acquired by Symantec—A division of Broadcom)
Chris Gogoel	Kryptowire
Tom Karygiannis	Kryptowire
Tim LeMaster	Lookout
Victoria Mosby	Lookout
Michael Carr	MobileIron
Walter Holda	MobileIron
Farhan Saifudin	MobileIron
Jeff Lamoureaux	Palo Alto Networks
Sean Morgan	Palo Alto Networks
Kabir Kasargod	Qualcomm
Viji Raveendran	Qualcomm
Lura Danley	The MITRE Corporation
Eileen Durkin	The MITRE Corporation
Sallie Edwards	The MITRE Corporation
Marisa Harriston	The MITRE Corporation
Milissa McGinnis	The MITRE Corporation
Nick Merlino	The MITRE Corporation
Doug Northrip	The MITRE Corporation
Titilayo Ogunyale	The MITRE Corporation
Oksana Slivina	The MITRE Corporation
Tracy Teter	The MITRE Corporation
Paul Ward	The MITRE Corporation

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 this example solution. We worked with:

Technology Partner/Collaborator	Build Involvement
Appthority *	Appthority Cloud Service, Mobile Threat Intelligence*
Kryptowire	Kryptowire Cloud Service, Application Vetting
Lookout	Lookout Cloud Service/Lookout Agent Version 5.10.0.142 (iOS), 5.9.0.420 (Android), Mobile Threat Defense
MobileIron	MobileIron Core Version 9.7.0.1, MobileIron Agent Version 11.0.1A (iOS), 10.2.1.1.3R (Android), Enterprise Mobility Management
Palo Alto Networks	Palo Alto Networks PA-220
Qualcomm	Qualcomm Trusted Execution Environment (version is device dependent)

* Appthority (acquired by Symantec—A division of Broadcom).

List of Figures

Figure 3‑1 Risk Management Approach

Figure 3‑2 Risk Assessment Process

Figure 3‑3 NIST 800-30 Generic Risk Model

Figure 3‑4 Orvilia’s Mobile Deployment Before Security Enhancements

Figure 3‑5 Orvilia’s Security Goals

Figure 4‑1 Example Solution Architecture

Figure 4‑2 Example Solution Gateway Architecture

Figure 4‑3 Example Solution VPN Architecture

Figure 4‑4 NIST Privacy Risk Assessment Methodology Data Map for Orvilia’s Enterprise Security Architecture

Figure F‑1 Risk Assessment Process

Figure F‑2 NIST 800-30 Generic Risk Model

Figure G‑1 PRAM Data Map for Orvilia’s Enterprise Security Architecture

Figure H‑1 Setting a Custom Risk Level in Appthority

Figure H‑2 PAN-DB Blocked Website

Figure H‑3 Lock Screen and Security

Figure H‑4 Phishing Email on Android

Figure H‑5 Phishing Email on iOS

Figure H‑6 Untrusted Developer Warning

Figure H‑7 Application Signing Certificates

Figure H‑8 Restriction Setting Modification Screen

Figure H‑9 Unable to Trust Developer

Figure H‑10 Unknown Sources Detection

Figure H‑11 Vulnerability Identification

Figure H‑12 Patch Level Display

Figure H‑13 Kryptowire Analysis Report

Figure H‑14 Configuration Profile Example

Figure H‑15 Configuration Profile Phishing Email

Figure H‑16 Root Certificate Authority Enablement Warning

Figure H‑17 Reversed Web Page

Figure H‑18 Certificate Phishing Email

Figure H‑19 Reversed Web Page

Figure H‑20 Network Attack Detected

Figure H‑21 Unencrypted Data Transfer

Figure H‑22 Lock Screen Disabled Detection Notice

Figure H‑23 Hard-Coded Credentials

Figure H‑24 No Certificates Found on Android

Figure H‑25 No Certificates Found on iOS

Figure H‑26 Android Device Wipe Warning

Figure H‑27 Disallowing Screenshots and Screen Recording

List of Tables

Table 3‑1 Threat Event Mapping to the Mobile Threat Catalogue

Table 3‑2 Identify Vulnerabilities and Predisposing Conditions

Table 3‑3 Summary of Risk Assessment Findings

Table 4‑1 Commercially Available Products Used

Table 5‑1 Threat Event Scenarios and Findings Summary

Table 5‑2 Data Action Scenarios and Findings Summary

Table F‑1 Threat Sources of Concern

Table F‑2 Threat Sources Qualitative Scale

Table F‑3 Identify Vulnerabilities and Predisposing Conditions

Table F‑4 Likelihood of Threat Events of Concern

Table F‑5 Potential Adverse Impacts

Table F‑6 Summary of Risk Assessment Findings

Table I‑1 Example Solution’s Cybersecurity Standards and Best Practices Mapping

1 Summary¶

This section helps familiarize the reader with:

Corporate-Owned Personally-Enabled (COPE) concepts
COPE challenges, solutions, and benefits as related to this practice guide

______________________________________________________________________________

COPE mobile devices are owned by an enterprise and issued to an employee. Both the enterprise and the employee can install applications onto the device.

This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide seeks to help address COPE mobile device security implementation challenges in several ways: by analyzing a set of mobile security and privacy threats; exploring mitigating technologies; and describing a reference design based upon those technologies to help mitigate the identified threats.

Mobile devices provide greater flexibility in how employees access resources. For some organizations, this flexibility supports a hybrid approach enhancing their in-office processes with mobile device communication and workflows.

For others, this flexibility, combined with growing mobile functionality, fosters a mobile-first approach in which their employees primarily communicate and collaborate using mobile devices. However, some of the features that make mobile devices increasingly flexible and functional also make them challenging to deploy and manage with security in mind.

Further, organizations are becoming progressively cognizant of the privacy implications that arise from using mobile security technologies. Therefore, developing a successful mobile deployment strategy requires organizations to evaluate their security and privacy requirements.

To help organizations address mobile device security and privacy risks, this document’s reference design provides:

a description of a mobile device deployment example solution featuring an on-premises enterprise mobility management (EMM) solution integrated with cloud- and agent-based mobile security technologies to help deploy a set of security and privacy capabilities in support of a COPE mobile device usage scenario
a series of how-to guides—step-by-step instructions covering the initial setup (installation or provisioning) and configuration for each component of the architecture to help security engineers rapidly deploy and evaluate our example solution in their test environment

The example solution of our reference design uses standards-based, commercially available products. It can be used directly by any organization with a COPE usage scenario by implementing a security infrastructure that supports integration of on-premises with cloud-hosted mobile security technologies. Alternatively, an organization may use our reference design and example solution in whole or part as the basis for a custom solution that realizes the security and privacy characteristics that best support its unique mobile device usage scenario.

1.1 Challenge¶

Mobile devices are a staple within modern workplaces, and as employees use these devices to perform tasks, organizations are challenged with ensuring that devices process, modify, and store sensitive data securely. They bring unique threats to the enterprise and need to be managed differently from desktop platforms.

Due to their unique capabilities, mobile devices’ specific security challenges can include:

securing their always-on connections to the internet from network-based attacks
securing the data on devices to prevent compromise via malicious applications
protecting them from phishing attempts that try to collect user credentials or entice a user to install software
selecting from the many mobile device management tools available and implementing their protection capabilities consistently
identifying threats to mobile devices and how to mitigate them

Given these challenges, managing the security of workplace mobile devices and minimizing the risk posed can be complex. By providing an example solution that organizations can make immediate use of, this guide provides an example solution to help simplify deployment of mobile device security capabilities.

1.2 Solution¶

In our lab at the National Cybersecurity Center of Excellence (NCCoE), NIST engineers built an environment that contains an example solution for managing the security of mobile devices. In this guide, we show how an enterprise can leverage this infrastructure to implement on-premises EMM, mobile threat defense (MTD), mobile threat intelligence (MTI), application vetting, secure boot/image authentication, and virtual private network (VPN) services.

Further, these technologies were configured to protect organizational assets and end-user privacy, providing methodologies to enhance the security posture of the adopting organization. The foundation of this architecture is based on federal United States guidance, including that from the NIST 800 series publications [B1], the National Information Assurance Partnership (NIAP) [B2], the Department of Homeland Security [B3], and the Federal Chief Information Officers (CIO) Council [B4]. These standards, best practices, and certification programs help ensure the confidentiality, integrity, and availability of enterprise data on mobile systems.

This guide provides:

a detailed example solution with capabilities that mitigate common mobile threats
a demonstration of an approach that uses commercially available products
step-by-step installation how-to guidance for implementers, which is designed to integrate with existing systems to improve the organization’s mobile security posture with minimal disruption to operations

The NCCoE sought existing technologies that provided the following capabilities:

ability to help protect data on the mobile device
utilization of centralized management systems to deploy policies and configurations to devices
vetting the security of mobile applications
ability to help protect data from eavesdropping
privacy settings to enable the predictability, manageability, and disassociability of end-usersʼ personally identifiable information (PII)

Commercial, standards-based products such as the ones we used are readily available and interoperable with existing information technology (IT) infrastructure and investments.

1.2.1 Standards and Guidance¶

This guide leverages many standards and guidance, including the NIST Cybersecurity Framework Version 1.1 [B5], the NIST Privacy Risk Assessment Methodology (PRAM) [B6], the National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework [B7], the NIST Risk Management Framework [B8], and the NIST Mobile Threat Catalogue [B9]. For additional information, see Appendix D, Standards and Guidance.

1.3 Benefits¶

The potential benefits of the example solution explored by this project are to:

provide users with enhanced protection against both malicious applications and loss of personal and business data when a device is stolen or misplaced
reduce adverse effects on an organization if a device is compromised
reduce capital investment by embracing modern enterprise mobility models
provide visibility for system administrators into mobile security events, enabling automated identification and notification of a compromised device
provide modular architecture based on technology roles while remaining vendor-agnostic
facilitate multiple mobile device usage scenarios using COPE devices
apply robust, standards-based technologies using industry best practices
demonstrate secure mobile access to organizational resources
illustrate the application of the NIST Risk Management Framework to mobility scenarios

2 How to Use This Guide¶

This section helps familiarize the reader with:

this practice guide’s content
the suggested audience for each volume
typographic conventions used in this volume

______________________________________________________________________________

This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design and provides users with the information they need to replicate how to improve the security and privacy of organization-owned mobile devices. This reference design is modular and can be deployed in whole or in part.

This guide contains three volumes:

NIST SP 1800-21A: Executive Summary
NIST SP 1800-21B: Approach, Architecture, and Security Characteristics – what we built and why (you are here)
NIST SP 1800-21C: How-To Guides – instructions for building the example solution

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-21A, which describes the following topics:

challenges that enterprises face in securing organization-owned mobile devices from threats that are distinct from desktop platforms
example solution built at the NCCoE
benefits of adopting the example solution

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-21B, which describes what we did and why. The following sections will be of particular interest:

Section 3.4, Risk Assessment, provides a description of the risk analysis we performed
Section 4.3, Security Control Map, maps the security characteristics of this example solution to cybersecurity standards and best practices

You might share the Executive Summary, NIST SP 1800-21A, with your leadership team members to help them understand the importance of adopting standards-based solutions to improve mobile device security with on-premises mobile device management solutions.

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-21C, to replicate all or parts of the build created in our lab. The how-to portion of the guide provides specific product installation, configuration, and integration instructions for implementing the example solution. 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 guide assumes that information technology (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 this guide’s example solution for on-premises mobile device security management. 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.6, Technologies, lists the products we used, and Appendix I maps them to the cybersecurity controls provided by this reference solution.

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.

2.1 Typographic Conventions¶

The following table presents typographic conventions used in this volume.

Typeface/ Symbol	Meaning	Example
Italics	file names and path names; references to documents that are not hyperlinks; new terms; and placeholders	For language use and style guidance, see the NCCoE Style Guide.
Bold	names of menus, options, command buttons, and fields	Choose File > Edit.
`Monospace`	command-line input, onscreen 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://www.nccoe.nist.gov.

3 Approach¶

This section helps familiarize the reader with:

this guide’s intended audience, scope, and assumptions
the fictional organization used in the example scenario
the risk assessment, including the privacy risk assessment
the example solution’s goals and the technologies it uses

______________________________________________________________________________

The NIST build team surveyed reports of mobile device security trends and openly invited the mobile device security community—including vendors, researchers, administrators, and users—to engage in a discussion about pressing cybersecurity challenges. The community expressed two significant messages.

First, administrators experienced confusion about which policies and standards—out of myriad sources—should be implemented. Second, mobile device users were frustrated by the degrees to which enterprises have control over their mobile devices and maintain visibility into their personal activity.

Therefore, the NIST build team reviewed the primary standards, best practices, and guidelines from government sources and implemented a COPE usage scenario within this build. This effort highlights several security characteristics and capabilities that are documented within the Mobile Device Security for Enterprises building block [B10].

3.1 Audience¶

This practice guide is for organizations that want to enhance the security and privacy of corporate-owned mobile devices. It is intended for executives, security managers, engineers, administrators, and others who are responsible for acquiring, implementing, and maintaining mobile enterprise technology, including centralized device management, application vetting, and endpoint protection systems.

This document will be of particular interest to system architects already managing mobile deployment solutions and those looking to deploy mobile devices in the near term. It assumes readers have a basic understanding of mobile device technologies and enterprise security principles. Please refer to Section 2 for how different audiences can effectively use this guide.

3.2 Scope¶

The scope of this build includes managing mobile phones and tablets with on-premises EMM. Mobile devices in general are commonly defined as:

A portable computing device that: (i) has a small form factor such that it can easily be carried by a single individual; (ii) is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); (iii) possesses local, non-removable or removable data storage; and (iv) includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the devices to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, tablets, and E-readers [B11].

Laptops are excluded from the scope of this publication, as the security controls available today for laptops differ significantly from those available for mobile phones and tablets, although this is changing with the emergence of unified endpoint management capabilities.

Devices with minimal computing capability are also excluded, including feature phones, wearables, and devices classified as part of the Internet of Things. Classified systems, devices, data, and applications are not addressed within this publication.

The build team devised a fictional scenario centered around a mock organization (Orvilia Development) to provide context to our risk assessment and to enable us to build a reference design to solve common enterprise mobile security challenges. Using a fictional scenario exemplifies the issues that an organization may face when addressing common enterprise mobile security challenges. We intend for the example solution proposed in this practice guide to be broadly applicable to enterprises, including both the public and private sectors.

The example solution does not incorporate insider threats and their corresponding mitigations. It focuses on external threats and how the example solution can address them.

Additional options for deployment of Android, Apple, and Samsung Knox managed devices are discussed in Appendix E.

3.2.1 Orvilia Development¶

The fictional organization, Orvilia Development, is a start-up company providing IT services to many private sector organizations. Its service offerings include developing scalable web applications, improving existing IT systems, project management, and procurement. Orvilia recently won its first government contract. Given the organization’s current security posture, particularly in its use of mobile devices, complying with government regulations and heightened cybersecurity standards presents it with new challenges.

Orvilia has a deployment of on-premises IT resources. It hosts its own Microsoft Active Directory (AD) domain, Microsoft Exchange email server, and web-based resources for employees, such as timekeeping and travel support. All enterprise resources can be directly accessed by employees locally or remotely from any internet-connected device by using password-based authentication. Orvilia also provides its employees with corporate-owned mobile devices. These may be used for personal activity, including phone calls, instant messaging, and installation and use of social applications. Employees also regularly work outside the office and frequently use public Wi-Fi networks at hotels, airports, and coffee shops.

Orvilia’s mobile device deployment practice is still developing; it has minimal mobile device policies and has not implemented any additional security mechanisms such as enterprise mobility management. All policy and security enforcement actions are performed manually on an ad-hoc basis. Employees are expected to secure their own COPE devices, for instance via the timely installation of operating system (OS) updates, and to exercise good judgment regarding any personal use.

However, no mechanisms have been put into place to prevent or detect misuse or device compromise. Further, corporate policy prohibits access to the corporate network from personally owned mobile devices, but no technical safeguards have been implemented to prevent employees from doing so. This posture had been promoted based on the organization’s small size, high level of employee technical acumen, and lack of awareness that it has been significantly impacted by any cybersecurity incidents.

However, Orvilia’s new status as a contractor to a civilian government agency calls for it to achieve and maintain compliance with government policies, which require compliance with cybersecurity best practices and applicable standards. For example, Orvilia is required to secure its access to and storage of sensitive government information, which its employees will need to access from their mobile devices, both locally at agency sites and remotely from Orvilia or during travel.

In addition to meeting compliance requirements rising from its contractual obligations to a government agency, Orvilia leadership is concerned about the potential for future incidents where nation-state malicious actors might obtain sensitive government data from unsecured devices and infrastructure. Therefore, a risk assessment as described in NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments [B12], was performed using the risk management concepts shown in Figure 3‑1.

Figure 3‑1 Risk Management Approach

The risk assessment revealed that Orvilia’s current mobile infrastructure places the organization at risk of intrusion and compromise of sensitive data. The results of the risk assessment process are presented in Appendix F.

Based on the risk assessment findings, Orvilia chose to invest in security improvements to its mobile infrastructure. Details of Orviliaʼs new mobile device security infrastructure are provided in Section 4. As described in Section 4’s architecture design, Orviliaʼs new infrastructure addressed the concerns identified in its risk assessment. Orviliaʼs risk assessment team reviewed guidance by standards organizations and government agencies as part of its process and identified the standards and guidance identified in Appendix D as applicable to its organizational mobile use case.

3.3 Assumptions¶

This project is guided by the following assumptions:

The solution was developed in a lab environment based on a typical organization’s IT enterprise. It does not reflect the complexity of a production environment.
An organization has access to the skills and resources required to implement a mobile device security solution.
The benefits of adopting this particular mobile device security solution outweigh any additional performance, reliability, or security risks that may be introduced. However, we draw the reader’s attention to the fact that implementation of any security controls has the potential to increase or decrease the attack surface within an enterprise, the actual impact of which will vary from organization to organization. Because the organizational environment in which this build could be implemented represents a greater level of complexity than is captured in the current guide, we assume that organizations will first examine the implications for their current environment before implementing any part of the proposed solution.
Organizations have either already invested or are willing to invest in the security of mobile devices used within their organization and of their IT systems more broadly. As such, we assume they either have the technology in place to support this implementation or have access to the off-the shelf information security technology used in this build, which we assume will perform as described by the respective product vendor.
Organizations have familiarized themselves with existing standards and any associated guidelines (e.g., NIST Cybersecurity Framework [B5], NIST SP 800-124 Revision 2 Draft [B13], NIST SP 1800-4 [B14]) relevant to implementation of the solution proposed in this practice guide. We also assume that any existing technology to be used in the proposed solution has been implemented in a manner consistent with these standards.
Organizations have instituted relevant mobile device security policies and that these will be updated based on implementation of this solution.

3.3.1 Systems Engineering¶

Some organizations use a systems engineering-based approach in planning and implementing their IT projects. Organizations wishing to implement IT systems are encouraged to conduct robust requirements development, taking into consideration the operational needs of each system stakeholder.

The information contained within Section 4 of this volume provides architecture details to help understand the operational capabilities of the example solution. Guidance is also provided in standards such as the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers (IEEE) 15288:2015, Systems and software engineering–System life cycle processes [B15]; and NIST SP 800-160, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems [B16], which provide guidance in this endeavor. With these standards, organizations may choose to adopt only those sections that are relevant to their environment and business context.

3.4 Risk Assessment¶

NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments [B12], 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 (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.”

The NCCoE recommends that any discussion of risk management, particularly at the enterprise level, begins with a comprehensive review of NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations [B17] −material that is available to the public. The Risk Management Framework (RMF) guidance [B8], as a whole, proved to be invaluable in giving us a baseline to assess risks, from which we developed the project, the security characteristics of the build, and this guide.

This section provides information on the risk assessment process employed to improve the mobile security posture of Orvilia Development. Typically, a NIST SP 800-30 Revision 1-based risk assessment follows a four-step process as shown in Figure 3‑2: Prepare for assessment, conduct assessment, communicate results, and maintain assessment. Full details of the risk assessment can be found in Appendix F.

Figure 3‑2 Risk Assessment Process

The purpose of Orvilia Development’s risk assessment is to identify and document risk-impacting changes to its mission resulting from Orvilia’s new status as a contractor to government agencies and COPE mobile deployment.

3.4.1 Risk Assessment of the Fictional Organization Orvilia Development¶

This risk assessment is scoped to Orviliaʼs mobile deployment, which consists of mobile devices used to access Orvilia enterprise resources along with any backend IT components used to manage or provide services to those mobile devices.

Risk assessment assumptions and constraints were developed using a NIST SP 800-30 Revision 1 Generic Risk Model as shown in Figure 3‑3 to identify the following necessary components of the risk assessment:

threat sources
threat events
vulnerabilities
predisposing conditions
security controls
adverse impacts
organizational risks

Figure 3‑3 NIST 800-30 Generic Risk Model

3.4.2 Development of Threat Event Descriptions¶

Orvilia examined the sample tables in NIST SP 800-30 Revision 1— Table F‑1, Table F‑2, Table F‑3, Table F‑4, and Table F‑5 —and analyzed the sources of mobile threats. Using this process, Orvilia leadership identified the potential mobile device threat events that are described in the following subsections. A mapping of the threat events considered in this guide’s example solution to the Mobile Threat Catalogue can be found in Table 3‑1.

A note about selection of the threat events: These threat events were developed by identifying threats from the NIST Mobile Threat Catalogue [B9] that would have the ability to significantly disrupt Orvilia’s processes. In the interest of brevity, we limited our identified threat events of concern to those that were presumed to average a foreseeably high likelihood of occurrence and high potential for adverse impact in Orvilia’s specific scenario. The threats from the NIST Mobile Threat Catalogue that could have less impact to Orvilia were not prioritized as high and did not become part of the following 12 threat events that Orvilia prioritized for inclusion in its mobile device security architecture.

Table 3‑1 Threat Event Mapping to the Mobile Threat Catalogue

Threat Event (TE)	NIST Mobile Threat Catalogue Threat ID
TE-1	APP-2, APP-12
TE-2	AUT-9
TE-3	APP-5, AUT-10, APP-31, APP-40, APP-32, APP-2
TE-4	STA-9, APP-4, STA-16, STA-0, APP-26
TE-5	APP-32, APP-36
TE-6	STA-7, EMM-3
TE-7	CEL-18, APP-0, LPN-2
TE-8	AUT-2, AUT-4
TE-9	APP-9, AUT-0
TE-10	EMM-5
TE-11	PHY-0
TE-12	EMM-9

3.4.2.1 Threat Event 1—Unauthorized Access to Sensitive Information via a Malicious or Privacy-Intrusive Application¶

Summary: A mobile application can attempt to collect and exfiltrate any information to which it has been granted access. This includes any information generated during use of the application (e.g., user input), user-granted permissions (e.g., contacts, calendar, call logs, camera roll), and general device data available to any application (e.g., International Mobile Equipment Identity , device make and model, serial number). Further, if a malicious application exploits a vulnerability in other applications, the operating system (OS), or device firmware to achieve privilege escalation, it may gain unauthorized access to any data stored on or otherwise accessible through the device.

Risk Assessment Analysis:

Overall Likelihood: Very High

Justification: Employees have access to download any applications at any time. If an employee requires an application that provides a desired function, the employee can download that application from any available source (trusted or untrusted). If an application performs an employee’s desired function, they may download an application from an untrusted source whose app then requires privacy-intrusive permissions.

Level of Impact: High

Justification: Orvilia’s mobile devices currently have the ability to download an application from an untrusted source whose apps require privacy-intrusive permissions. This poses a threat for sensitive corporate data, as some applications may include features that access corporate data, unbeknownst to the user.

3.4.2.2 Threat Event 2—Theft of Credentials Through a Short Message Service (SMS) or Email Phishing Campaign¶

Summary: Malicious actors may create fraudulent websites that mimic the appearance and behavior of legitimate ones and entice users to authenticate to them by distributing phishing messages over SMS or email. Effective use of social engineering techniques such as impersonating an authority figure or creating a sense of urgency may compel users to forgo scrutiny of the message and proceed to authenticate to the fraudulent website; it then captures and stores the userʼs credentials before (usually) forwarding them to the legitimate website to allay suspicion.

Risk Assessment Analysis:

Overall Likelihood: Very High

Justification: Phishing campaigns are a common threat that occurs almost daily.

Level of Impact: High

Justification: A successful phishing campaign could provide the malicious actor with corporate credentials, allowing access to sensitive corporate data, or personal credentials that could lead to compromise of corporate data or infrastructure via other means.

3.4.2.3 Threat Event 3—Malicious Applications Installed via Uniform Resource Locators (URLs) in SMS or Email Messages¶

Summary: Malicious actors may send users SMS or email messages that contain a URL where a malicious application is hosted. Generally, such messages are crafted using social engineering techniques designed to dissuade recipients from scrutinizing the nature of the message, thereby increasing the likelihood they access the URL using their mobile device. If they do, it will attempt to download and install the application. Effective use of social engineering by the attacker will further compel an otherwise suspicious user to grant any trust required by the developer and all permissions requested by the application. Granting the former facilitates the installation of other malicious applications by the same developer, and granting the latter increases the potential for the application to do direct harm.

Risk Assessment Analysis:

Overall Likelihood: High

Justification: Installation of malicious applications via URLs is less common than other phishing attempts. The process for sideloading applications requires much more user input and consideration (e.g., trusting the developer certificate) than standard phishing, which solely requests a username and password. A user may proceed through the process of sideloading an application to acquire a desired capability from an application.

Level of Impact: High

Justification: Once a user installs a malicious sideloaded application, this could provide a malicious actor with full access to a mobile device, and therefore, access to corporate data and credentials, without the user’s knowledge.

3.4.2.4 Threat Event 4—Confidentiality and Integrity Loss Due to Exploitation of Known Vulnerability in the OS or Firmware¶

Summary: When malware successfully exploits a code execution vulnerability in the mobile OS or device drivers, the delivered code generally executes with elevated privileges and then issues commands in the context of the root user or the OS kernel. These commands may be enough for some to accomplish their goal, but advanced malicious actors will usually attempt to install additional malicious tools and to establish a persistent presence. If successful, the malicious actor will be able to launch further attacks against the user, the device, or any other systems connected to the device. As a result, any data stored on, generated by, or accessible to the device at that time−or in the future−may be compromised.

Risk Assessment Analysis:

Overall Likelihood: High

Justification: Many public vulnerabilities specific to mobile devices have been seen over the years, such as Stagefright. Users jailbreak iOS devices and root Android devices to download third-party applications and apply unique settings/configurations that the device would not typically be able to apply/access.

Level of Impact: High

Justification: Exploiting a vulnerability allows circumventing security controls and modifying protected device data that should not be modified. Jailbroken and rooted devices may exploit kernel vulnerabilities and allow third-party applications/services root access that can also be used to bypass security controls built-in or applied to a mobile device.

3.4.2.5 Threat Event 5—Violation of Privacy via Misuse of Device Sensors¶

Summary: Malicious actors with access (authorized or unauthorized) to device sensors (microphone, camera, gyroscope, Global Positioning System [GPS] receiver, and radios) can use them to conduct surveillance. It may be directed at the user, as when tracking the device location, or it may be applied more generally, as when recording any nearby sounds. Captured sensor data may be immediately useful to a malicious actor, such as a recording of an executive meeting. Alternatively, the data may be analyzed in isolation or in combination with other data to yield sensitive information. For example, audio recordings of on-device or proximate activity can be used to probabilistically determine user inputs to touchscreens and keyboards−essentially turning the device into a remote key logger.

Risk Assessment Analysis:

Overall Likelihood: Very High

Justification: This has been seen on public application stores in the past, with applications allegedly being used for data collection [B18]. As mentioned in Threat Event 1, unbeknownst to the user, a downloaded application may be granted privacy-intrusive permissions that allow access to device sensors.

Level of Impact: High

Justification: When the sensors are being misused, the user may not be aware. This allows collection of sensitive enterprise data, such as location, without knowledge of the user.

3.4.2.6 Threat Event 6—Compromise of the Integrity of the Device or Its Network Communications via Installation of Malicious EMM/MDM, Network, VPN Profiles, or Certificates¶

Summary: Malicious actors who successfully install an Enterprise Mobility Management/Mobile Device Management (EMM/MDM), network, or VPN profile or certificate onto a device will gain a measure of additional control over the device or its communications. Presence of a malicious EMM/MDM profile will allow an attacker to misuse existing OS application programming interfaces (APIs) to send the device a wide variety of commands. This may allow a malicious actor to obtain device information; install or restrict applications; or remotely locate, lock, or wipe the device. Malicious network profiles may allow a malicious actor to automatically compel the device to connect to access points under their control to achieve a person-in-the-middle attack on all outbound connections. Alternatively, malicious VPN profiles assist in the undetected exfiltration of sensitive data by encrypting it, thus hiding it from network scanning tools. Additionally, malicious certificates may allow the malicious actor to compel the device to automatically trust connections to malicious web servers, wireless access points, or installation of applications under the attacker’s control.

Risk Assessment Analysis:

Overall Likelihood: Moderate

Justification: Unlike installation of an application, installation of EMM/MDM, network, VPN profiles, and certificates requires additional effort and understanding from the user to properly implement.

Level of Impact: Very High

Justification: If a malicious actor were able to install malicious configuration profiles or certificates, they would be able to perform actions such as decrypt network traffic and possibly even control the device.

3.4.2.7 Threat Event 7—Loss of Confidentiality of Sensitive Information via Eavesdropping on Unencrypted Device Communications¶

Summary: Malicious actors can readily eavesdrop on communication over unencrypted, wireless networks such as public Wi-Fi access points, which are commonly provided by coffee shops and hotels. While a device is connected to such a network, a malicious actor would gain unauthorized access to any data sent or received by the device for any session not already protected by encryption at either the transport or application layers. Even if the transmitted data were encrypted, an attacker may be privy to the domains, internet protocol (IP) addresses, and services (as indicated by port numbers) to which the device connects; such information could be used in future watering hole attacks or person-in-the-middle attacks against the device user.

Additionally, visibility into network layer traffic enables a malicious actor to conduct side-channel attacks against its encrypted messages, which can still result in a loss of confidentiality. Further, eavesdropping on unencrypted messages during a handshake to establish an encrypted session with another host or endpoint may facilitate attacks that ultimately compromise security of the session.

Risk Assessment Analysis:

Overall Likelihood: High

Justification: Users require network access to retrieve email and access cloud services and other necessary data on the internet. Users can connect to readily available free internet access in public venues such as coffee shops, hotels, and airports.

Level of Impact: High

Justification: Users may connect to unencrypted wireless networks, and many applications do not properly encrypt network communications. Improper use of encryption, or lack thereof, allows a malicious actor to eavesdrop on network traffic.

3.4.2.8 Threat Event 8—Compromise of Device Integrity via Observed, Inferred, or Brute-Forced Device Unlock Code¶

Summary: A malicious actor may be able to obtain a user’s device unlock code by direct observation, side-channel attacks, or brute-force attacks. Both the first and second can be attempted with at least proximity to the device; only the third technique requires physical access. However, side-channel attacks that infer the unlock code by detecting taps and swipes to the screen can be attempted by applications with access to any peripherals that detect sound or motion (microphone, gyroscope, or accelerometer). Once the device unlock code has been obtained, a malicious actor with physical access to the device will gain immediate access to any data or functionality not already protected by additional access control mechanisms. Additionally, if the user employs the device unlock code as a credential to any other systems, the attacker may further gain unauthorized access to those systems.

Risk Assessment Analysis:

Overall Likelihood: High

Justification: Unlike shoulder-surfing to observe a user’s passcode, brute-force attacks are not as common or successful due to the built-in deterrent mechanisms. These mechanisms include exponential back-off/lockout period and device wipes after a certain number of failed unlock attempts.

Level of Impact: High

Justification: If a malicious actor can successfully unlock a device without the user’s permission, they could have full control over the user’s corporate account and thus gain unauthorized access to corporate data.

3.4.2.9 Threat Event 9—Unauthorized Access to Backend Services via Authentication or Credential Storage Vulnerabilities in Internally Developed Applications¶

Summary: If a malicious actor gains unauthorized access to a mobile device, the attacker also has access to the data and applications on that mobile device. The mobile device may contain an organization’s in-house applications and can subsequently gain access to sensitive data or backend services. This could result from weaknesses or vulnerabilities present in the authentication or credential storage mechanisms implemented within an in-house application.

Risk Assessment Analysis:

Overall Likelihood: Very High

Justification: Often applications include hard-coded credentials for the default password of the administrator account. Default passwords are readily available online. These passwords may not be changed to allow for ease of access and to eliminate the pressure of remembering a password.

Level of Impact: High

Justification: Successful extraction of the credentials allows an attacker to gain unauthorized access to enterprise data.

3.4.2.10 Threat Event 10—Unauthorized Access of Enterprise Resources from an Unmanaged and Potentially Compromised Device¶

Summary: An employee who accesses enterprise resources from an unmanaged mobile device may expose the enterprise to vulnerabilities that may compromise enterprise data. Unmanaged devices do not benefit from security mechanisms deployed by the organization such as mobile threat defense, mobile threat intelligence, application vetting services, and mobile security policies. These unmanaged devices limit an organization’s visibility into the state of a mobile device, including if the device is compromised by a malicious actor. Therefore, users who violate security policies to gain unauthorized access to enterprise resources from such devices risk providing attackers with access to sensitive organizational data, services, and systems.

Risk Assessment Analysis:

Overall Likelihood: Very High

Justification: This may occur accidentally when an employee attempts to access their email.

Level of Impact: High

Justification: Unmanaged devices pose a sizable security risk because the enterprise has no visibility into their security or risk posture. Due to this lack of visibility, a compromised device may allow an attacker to attempt to exfiltrate sensitive enterprise data.

3.4.2.11 Threat Event 11—Loss of Organizational Data Due to a Lost or Stolen Device¶

Summary: Due to the nature of the small form factor of mobile devices, they can be misplaced or stolen. A malicious actor who gains physical custody of a device with inadequate security controls may be able to gain unauthorized access to sensitive data or resources accessible to the device.

Risk Assessment Analysis:

Overall Likelihood: Very High

Justification: Mobile devices are small and can be misplaced. Enterprise devices may be lost or stolen at the same frequency as personally owned devices.

Level of Impact: High

Justification: Similar to Threat Event 9, if a malicious actor can gain access to the device, they could potentially have access to sensitive corporate data.

3.4.2.12 Threat Event 12—Loss of Confidentiality of Organizational Data Due to Its Unauthorized Storage in Non-Organizationally Managed Services¶

Summary: If employees violate data management policies by using unmanaged services to store sensitive organizational data, this data will be placed outside organizational control, where the organization can no longer protect its confidentiality, integrity, or availability. Malicious actors who compromise the unauthorized service account or any system hosting that account may gain unauthorized access to the data.

Further, storage of sensitive data in an unmanaged service may subject the user or the organization to prosecution for violation of any applicable laws (e.g., exportation of encryption) and may complicate efforts by the organization to achieve remediation or recovery from any future losses, such as those resulting from the public disclosure of trade secrets.

Risk Assessment Analysis:

Overall Likelihood: High

Justification: This could occur either intentionally or accidentally (e.g., taking a screenshot and backup pictures to an unmanaged cloud service).

Level of Impact: High

Justification: Storage in unmanaged services presents a risk to the confidentiality and availability of corporate data because the corporation would no longer control it.

3.4.3 Identification of Vulnerabilities and Predisposing Conditions¶

In Section 3.4, we identified vulnerabilities and predisposing conditions that increase the likelihood that identified threat events will result in adverse impacts for Orvilia Development. Each vulnerability or predisposing condition is listed in Table 3‑2 along with the corresponding threat events and ratings of threat pervasiveness. More details on the use of threat event ratings can be found in Appendix F.

Table 3‑2 Identify Vulnerabilities and Predisposing Conditions

Vulnerability ID	Vulnerability or Predisposing Condition	Resulting Threat Events	Pervasiveness
VULN-1	Email and other enterprise resources can be accessed from anywhere, and only username/password authentication is required.	TE-2, TE-10, TE-11	Very High
VULN-2	Public Wi-Fi networks are regularly used by employees for remote connectivity from their corporate mobile devices.	TE-7	Very High
VULN-3	No EMM/MDM deployment exists to enforce and monitor compliance with security-relevant policies on corporate mobile devices.	TE-1, TE-3, TE-4, TE-5, TE-6, TE-7, TE-8, TE-9, TE-11, TE-12	Very High

3.4.4 Summary of Risk Assessment Findings¶

Table 3‑3 summarizes the risk assessment findings. More detail about the methodology used to rate overall likelihood, level of impact, and risk can be found in Appendix F.

Table 3‑3 Summary of Risk Assessment Findings

Threat Event	Vulnerabilities, Predisposing Conditions	Overall Likelihood	Level of Impact	Risk
TE-1: Unauthorized access to sensitive information via a malicious or privacy-intrusive application	VULN-3	Very High	High	High
TE-2: Theft of credentials through an SMS or email phishing campaign	VULN-1	Very High	High	High
TE-3: Malicious applications installed via URLs in SMS or email messages	VULN-3	High	High	High
TE-4: Confidentiality and integrity loss due to exploitation of known vulnerability in the OS or firmware	VULN-3	High	High	High
TE-5: Violation of privacy via misuse of device sensors	VULN-3	Very High	High	High
TE-6: Compromise of the integrity of the device or its network communications via installation of malicious EMM/MDM, network, VPN profiles, or certificates	VULN-3	Moderate	Very High	High
TE-7: Loss of confidentiality of sensitive information via eavesdropping on unencrypted device communications	VULN-2, VULN-3	High	High	High
TE-8: Compromise of device integrity via observed, inferred, or brute-forced device unlock code	VULN-3	High	High	High
TE-9: Unauthorized access to backend services via authentication or credential storage vulnerabilities in internally developed applications	VULN-3	Very High	High	High
TE-10: Unauthorized access of enterprise resources from an unmanaged and potentially compromised device	VULN-1	Very High	High	High
TE-11: Loss of organizational data due to a lost or stolen device	VULN-1, VULN-3	Very High	High	High
TE-12: Loss of confidentiality of organizational data due to its unauthorized storage in non-organizationally managed services	VULN-3	High	High	High

Note 1: Risk is stated in qualitative terms based on the scale in Table I-2 of Appendix I in NIST Special Publication 800-30 Revision 1 [B12].

Note 2: The risk rating itself is derived from both the overall likelihood and level of impact using Table I-2 of Appendix I in NIST Special Publication 800-30 Revision 1 [B12]. Because these scales are not true interval scales, the combined overall risk ratings from Table I-2 do not always reflect a strict mathematical average of these two variables. This is demonstrated in the table above where levels of moderate weigh more heavily than other ratings.

Note 3: Ratings of risk relate to the probability and level of adverse effect on organizational operations, organizational assets, individuals, other organizations, or the nation. Per NIST SP 800-30 Revision 1, adverse effects (and the associated risks) range from negligible (i.e., very low risk), limited (i.e., low), serious (i.e., moderate), severe or catastrophic (i.e., high), to multiple severe or catastrophic effects (i.e., very high).

3.4.5 Privacy Risk Assessment¶

This section describes the privacy risk assessment conducted on Orvilia’s enterprise security architecture. To perform the privacy risk assessment, the NIST Privacy Risk Assessment Methodology (PRAM) was used. The PRAM is a tool for analyzing, assessing, and prioritizing privacy risks to help organizations determine how to respond and select appropriate solutions. The PRAM can also serve as a useful communication tool to convey privacy risks within an organization. A blank version of the PRAM is available for download on NIST’s website [B19].

The PRAM uses the privacy risk model and privacy engineering objectives described in NIST Internal Report (NISTIR) 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems [B20], to analyze for problematic data actions. Data actions are any system operations that process PII. Processing can include collection, retention, logging, analysis, generation, transformation or merging, disclosure, transfer, and disposal of PII. A problematic data action is one that could cause an adverse effect for individuals. The PRAM activities identified the following potential problems for individuals.

3.4.5.1 Potential Problems for Individuals¶

Three data actions were identified in the PRAM that have the potential to create problems for individuals. Those three data actions, along with their risk assessment analysis, follow:

blocking access and wiping devices
employee monitoring
data sharing across parties

3.4.5.1.1 Data Action 1: Blocking Access and Wiping Devices¶

Employees are likely to use their devices for both personal and work-related purposes. Therefore, in a system that features the capability to wipe a device entirely, there could be an issue of employees losing personal data. This is a potential problem for individuals because employee use of work devices for both personal and work-related purposes is common.

Devices that might pose a risk to the organization’s security posture can be blocked from accessing enterprise resources or wiped and reset to factory setting defaults, which could result in loss of information contained on the device. Potential options for minimizing the impact to the employee include:

blocking the device’s access to enterprise resources until it is granted access permission again
selectively wiping elements of the device without removing all data on the device. Within the example solution, this option is available for iOS devices.
advising employees to back up the personal data maintained on devices
limiting staff with the ability to perform wipes or block access

3.4.5.1.2 Data Action 2: Employee Monitoring¶

Employees may not be aware of the monitoring of their interactions with the system and may not want this monitoring to occur. Employer-owned or -controlled networks like Orvilia’s often can monitor activities, and many do on a regular basis.

The assessed infrastructure offers Orvilia a number of security capabilities, including reliance on comprehensive monitoring capabilities. A significant amount of data relating to employees, their devices, and their activities is collected and analyzed by multiple parties. Potential options for minimizing the impact to the employee include:

limit staff with ability to review data about employees and their devices
develop organization policies and techniques to limit collection of specific data elements
develop organization policies and techniques regarding disposal of PII

3.5 Solution Goals¶

This section describes the solution goals for revising Orvilia’s mobile security architecture. Here is an overview of the security issues identified within Orvilia’s original (also known as current) mobile device infrastructure architecture. To address these issues, a list of security goals was developed to provide a high-level overview of factors that could be applied to improve the security of Orvilia’s mobile architecture.

3.5.1 Current Architecture¶

Prior to investing in security improvements to their mobile infrastructure—as identified based on the aforementioned risk assessment—Orvilia Development had not implemented a mobile security strategy. Several weaknesses were identified based on their use of mobile devices. A subset of these weaknesses is presented in Figure 3‑4.

Figure 3‑4 Orvilia’s Mobile Deployment Before Security Enhancements

The following issues are highlighted in Figure 3‑4 with a red exclamation mark:

Organizational and personal data can become commingled if either the same application is used in both contexts or if multiple applications access shared device resources (e.g., contacts or calendar).
Mobile devices are connecting to Orvilia from unencrypted public Wi-Fi hotspots; data transmitted prior to a secure connection is subject to eavesdropping, including passwords.
Applications for work or personal use may contain unidentified vulnerabilities or weaknesses that increase the risk of device compromise.
Applications may be obtained outside official application stores, increasing the risk that they are malware in disguise.
Because mobile devices can connect from unknown locations, firewall rules must allow inbound connections from unrecognized, potentially malicious IP addresses.

3.5.2 Security Goals¶

In considering improvement to the security of their current deployment, Orvilia was able to identify high-level security goals to correct these shortcomings, as illustrated in Figure 3‑5.

Figure 3‑5 Orvilia’s Security Goals

The following strategies are highlighted in Figure 3‑5 with a green exclamation mark:

Organizational and personal information can be separated by restricting data flow between organizationally managed and unmanaged applications. Sensitive data is protected from crossing between work and personal contexts.
Mobile devices can connect to Orvilia over a VPN or similar solution to encrypt all data before it is transmitted from the device, protecting otherwise unencrypted data from interception.
Identifying applications with significant vulnerabilities or weaknesses facilitates blocking or uninstalling those applications from managed devices, reducing their risk to the organization.
Malware detection could be deployed to devices to identify malicious applications and facilitate remediation.
Mobile devices can be provisioned with a security certificate that allows them to be identified and authenticated at the connection point, which combines with user credentials to create two-factor authentication from mobile devices.

These high-level goals, obtained from a review of their current mobile security posture, provide examples of why a thorough risk assessment process is beneficial to organizations implementing mobile device security capabilities.

3.6 Technologies¶

This section describes the mobile-specific technology components used within this example solution. These technologies were selected to address the security goals and threat events identified in the risk assessment. This section provides a brief description of each technology and discusses the security capabilities that each component provides to address Orvilia’s security issues. For additional information, Appendix I provides the technologies used in this project and provides a mapping between the specific product used and the cybersecurity standards and best practices that the product provides in the example solution discussed in this guide.

3.6.1 Architecture Components¶

The security components in this section are combined into a cohesive enterprise security architecture to enable enterprises to address mobile security threats and provide secure access to enterprise resources from mobile devices. The security components described in this section provide protection for the following enterprise architecture components that are accessed by Orvilia’s users with their mobile devices.

email/Outlook Web Access–contacts
private chat server
travel support
organization intranet (e.g., internal announcements, organizational charts, policies)
time reporting

3.6.1.1 Trusted Execution Environment¶

A trusted execution environment (TEE) is “a tamper-resistant processing environment that runs on a separation kernel. It guarantees the authenticity of the executed code, the integrity of the runtime states (e.g., central processing unit registers, memory and sensitive I/O), and the confidentiality of its code, data and runtime states stored on a persistent memory. In addition, it shall be able to provide remote attestation that proves its trustworthiness for third-parties [B21].”

3.6.1.2 Enterprise Mobility Management¶

Organizations use Enterprise Mobility Management solutions to secure the mobile devices of users who are authorized to access organizational resources. Such solutions generally have two main components. The first is a backend service that mobile administrators use to manage the policies, configurations, and security actions applied to registered mobile devices. The second is an on-device agent, usually in the form of a mobile application, that integrates between the mobile OS and solution’s backend service. Alternatively, iOS supports a web-based EMM enrollment use case.

At a minimum, an EMM solution can perform MDM functions, which include the ability to provision configuration profiles to devices, enforce security policies on devices, and monitor compliance with those policies by devices. The on-device MDM agent can typically notify the device user of any noncompliant settings and may be able to remediate some noncompliant settings automatically. The organization can use policy compliance data to inform its access control decisions so that it grants access only to a device that demonstrates the mandated level of compliance with the security policy that applies to it.

EMM solutions commonly include any of the following: mobile application management, mobile content management, and implementations of or integrations with device- or mobile OS-specific containerization solutions, such as Samsung Knox (please refer to Appendix E for more information). These capabilities can be used to manage installation and usage of applications based on the applications’ trustworthiness and work relevance. Additionally, they can control how managed applications access and use organizational data and possibly strengthen the separation between a user’s personal and professional usage of the device.

Further, EMM solutions often have integrations with a diverse set of additional tools and security technologies that enhance their capabilities. An example is an EMM embedded with a mobile threat defense tool that serves to perform on-device, behavioral-based threat detection and to trigger policy remediation without the need to communicate to any server or service outside the device. This type of integration allows one application, the EMM agent, to manage, detect, and remediate device, network, application, malware, and spear phishing attacks. Additionally, because the remediation is autonomous at the device (does not require reaching a policy server), it has the advantage in addressing network-based threat vectors such as Pineapple or Stingray impersonation of valid Wi-Fi or cellular networks [B22].

For further reading, NIST SP 800-124 Revision 2 Draft, Guidelines for Managing the Security of Mobile Devices in the Enterprise [B13], provides additional information on mobile device management with EMM solutions. Additionally, NIAP’s Protection Profile for Mobile Device Management Version 4.0 [B23] describe important capabilities and security requirements to look for in EMM systems.

3.6.1.3 Virtual Private Network¶

A VPN gateway increases the security of remote connections from authorized mobile devices to an organization’s internal network. A VPN is a virtual network, built on top of existing physical networks, which can provide a secure communications mechanism for data and control information transmitted between networks. VPNs are used most often to protect communications carried over public networks such as the internet. A VPN can provide several types of data protection, including confidentiality, integrity, data origin authentication, replay protection, and access control that help reduce the risks of transmitting data between network components.

VPN connections apply an additional layer of encryption to the communication between remote devices and the internal network, and VPN gateways can enforce access control decisions by limiting which devices or applications can connect to it. Integration with other security mechanisms allows a VPN gateway to base access control decisions on more risk factors than it may be able to collect on its own; examples include a device’s level of compliance with mobile security policies or the list of installed applications that are not allowed by the organization as reported by an integrated EMM.

NIAP’s Extended Package for VPN Gateways [B24], in combination with the internationally and collaboratively developed Protection Profile for Network Devices [B25], describes important capabilities and security requirements to expect from VPN gateways.

3.6.1.4 Mobile Application Vetting Service¶

Mobile application vetting services use a variety of static, dynamic, and behavioral techniques to determine if an application demonstrates any behaviors that pose a security or privacy risk. The risk may be to a device owner or user, to parties that own data on the device, or to external systems to which the application connects. The set of detected behaviors is often aggregated to generate a singular score that estimates the level of risk (or conversely, trustworthiness) attributed to an application. Clients can often adjust the values associated with given behaviors (e.g., hard-coded cryptographic keys) to tailor the score for their unique risk posture. Those scores may be further aggregated to present a score that represents the overall risk or trustworthiness posed by the set of applications currently installed on a given device.

Mobile applications, malicious or benign, have high potential to negatively impact both security and user privacy. A malicious application can contain code intended to exploit vulnerabilities present in potentially any targeted hardware, firmware, or software on the device. Alternatively, or in conjunction with exploit code, a malicious application may misuse any device, personal, or behavioral data to which it has been explicitly or implicitly granted access, such as contacts, clipboard data, or location services. Benign applications may still present vulnerabilities or weaknesses that malicious applications can exploit to gain unauthorized access to its data or functionality. Further, benign applications may place user privacy at risk by collecting more information than is necessary for the application to deliver functionality desired by the user.

While not specific to applications, some services may include device-based risks (e.g., lack of disk encryption or vulnerable OS version) in their analysis to provide a more comprehensive assessment of the risk or trustworthiness presented by a device when running an application or service.

NIAP does not provide a Protection Profile for application vetting services themselves. However, NIAP’s Protection Profile for Application Software [B26] describes security requirements to be expected from mobile applications. Many mobile application vetting vendors provide capabilities to automate evaluation of applications against NIAP’s requirements.

3.6.1.5 Mobile Threat Defense¶

MTD generally takes the form of an application that is installed on the device, which provides the widest and most timely access to information about what activity is taking place. Ideally, the MTD solution will be able to detect unwanted activity and properly inform the user so they can act to prevent or limit the harm an attacker could cause. Additionally, MTD solutions may integrate with EMM solutions to leverage the EMM agent’s on-device capabilities, such as blocking a malicious application from being launched until the user can remove it.

MTD products typically analyze device-based, application-based, and network-based attacks. Device-based threats include outdated operating system versions and insecure configuration settings. Application-based threats include the issues discussed above regarding the mobile application vetting service, though sometimes without the same breadth or depth found in services dedicated to application vetting. Network-based attacks include use of unencrypted or public Wi-Fi networks and attacks such as active attempts to intercept and decrypt network traffic.

3.6.1.6 Mobile Threat Intelligence¶

In this guide, we describe mobile threat intelligence as actionable information that mobile administrators can use to make changes to their security configuration to improve their posture relative to recent discoveries. Intelligence data include malicious URLs, IP addresses, domain names, and application names or package/bundle IDs, as well as malware signatures or vulnerabilities in applications, mobile devices, device platform services, or mobile security products. This list is not all-encompassing, as any recent information that could inform rapid changes to enable an enterprise to better secure a mobile deployment against novel or newly enhanced threats is equally applicable to the term. This capability may be found in various other types of technology, such as MTD and other network analysis tools.

3.6.1.7 Mobile Operating System Capabilities¶

Mobile OS capabilities are available without the use of additional security features. They are included as part of the mobile device’s core capabilities. The following mobile OS capabilities can be found in mobile devices, particularly mobile phones.

3.6.1.7.1 Secure Boot¶

Secure boot is a general term that refers to a system architecture designed to prevent and detect any unauthorized modification to the boot process. A system that successfully completes a secure boot has loaded its start-up sequence information into a trusted operating system. A common mechanism is for the first program executed (a boot loader) to be immutable (stored on read-only memory or implemented strictly in hardware). Further, the integrity of mutable code is cryptographically verified prior to execution by either immutable or verified code. This process establishes a chain of trust that can be traced back to immutable, implicitly trustworthy code. Use of an integrated TEE as part of a secure boot process is preferable to an implementation that uses software alone [B27].

3.6.1.7.2 Device Attestation¶

This is an extension of the secure boot process that involves the operating system (or more commonly, an integrated TEE) providing cryptographically verifiable proof that it has a known and trusted identity and is in a trustworthy state, which means all software running on the device is free from unauthorized modification.

Device attestation requires cryptographic operations using an immutable private key that can be verified by a trusted third party, which is typically the original equipment manufacturer of the TEE (e.g., Qualcomm or Samsung) or device platform vendor (e.g., Google, Apple, or Microsoft). Proof of possession of a valid key establishes the integrity of the first link in a chain of trust that preserves the integrity of all other pieces of data used in the attestation. It will include unique device identifiers, metadata, and the results of integrity checks on mutable software, and possibly metrics from the boot or attestation process itself [B27].

3.6.1.7.3 Device Management and MDM API¶

Mobile operating systems and platform-integrated firmware (e.g., Samsung Knox) provide a number of built-in security features that are generally active by default. Examples include disk and file-level encryption, verification of digital signatures for installed software and updates, a device unlock code, remote device lock, and automatic device wipe following a series of failed device unlock attempts. Some of these features are directly configurable by the user via a built-in application or through a service provided by the device platform vendor (e.g., Google, Apple, or Microsoft).

Additionally, mobile operating systems expose an API to MDM products that allow an organization that manages a device to have greater control over these and many more settings that might not be directly accessible to the device user. Management APIs allow enterprises using integrated EMM or MDM products to manage devices more effectively and efficiently than they could by using the built-in application alone.

4 Architecture¶

This section helps familiarize the reader with the example solution’s:

architecture description
enterprise security architecture privacy data map
security control map

______________________________________________________________________________

This example solution consists of the six mobile security technologies described in Section 3.6: trusted execution environment, enterprise mobility management, virtual private network, mobile application vetting service, mobile threat defense, and mobile threat intelligence. Table 4‑1, identifies the commercially available products used in this example solution and how they aligned with the six mobile security technologies.

Table 4‑1 Commercially Available Products Used

Commercially Available Product	Mobile Security Technology
Appthority Cloud Service	Mobile threat intelligence
Kryptowire Cloud Service	Mobile application vetting service
Lookout Cloud Service/Lookout Agent Version 5.10.0.142 (iOS), 5.9.0.420 (Android)	Mobile threat defense
MobileIron Core Version 9.7.0.1 MobileIron Agent Version 11.0.1A (iOS), 10.2.1.1.3R (Android)	Enterprise mobility management
Palo Alto Networks, PA-220 Version 8.1.1	Virtual private network
Qualcomm, (version is mobile device dependent)	Trusted execution environment

These components are further integrated with broader on-premises security mechanisms and a VPN gateway as shown in Figure 4‑1. This integrated solution provides a broad range of capabilities to help securely provision and manage devices, protect against and detect device compromise, and help provide security-enhanced access to enterprise resources by only authorized mobile users and devices.

Organizations exploring the use of on-premises EMM technology should be aware they will be responsible for installing and configuring the on-premises instances of the EMM technology. This will include the software licenses that must be paid for directly by the organization for any underlying platforms or components. Pre-built software images and containers may be available that can help ease installation and configuration work. As a recommended best practice, if prebuilt containers and images are used, it is recommended that they be checked for common software vulnerabilities.

On-premises mobile device management solutions offer the benefit that enterprise data resides within the organization. Allowed devices may still send and receive information from the mobile device solution that they are authorized to obtain. Organizations that are interested can explore monitoring data flows from the EMM to other devices. Additionally, on-premises mobile device management solutions provide the organization with the capability to maintain physical security of the EMM.

Figure 4‑1 Example Solution Architecture

4.1 Architecture Description¶

The NCCoE worked with industry subject matter experts to develop an open, standards-based, commercially available architecture that addresses the risks identified during the risk assessment process in Section 3.4.

Where possible, the architecture uses components that are present on NIAP’s Product Compliant List [B28], meaning the product has been successfully evaluated against a NIAP-approved Protection Profile [B26]. NIAP collaborates with a broad community, including industry, government, and international partners, to publish technology-specific security requirements and tests in the form of Protection Profiles. The requirements and tests in these Protection Profiles are intended to ensure that evaluated products address identified security threats.

The example solution architecture supports its desired security characteristics as a result of the following integrations.

4.1.1 Enterprise Integration¶

This example solution extends central identity and access management to mobile devices via an integration between both MobileIron Core and Palo Alto Networks GlobalProtect with Microsoft Active Directory Domain Services (ADDS). The integrity of identification and authentication by mobile devices to the enterprise is further enhanced by using device certificates issued by local Microsoft Active Directory Certificate Services (ADCS).

By integrating with AD, MobileIron Core allows administrators to authorize select groups of users to register a mobile device, limiting mobile access to only those users who require it. Additionally, different security policies, device configurations, and authorized applications can be deployed to different AD groups, allowing administrators to centrally manage distinct mobile use cases. MobileIron Core queries AD using the lightweight directory access protocol.

Through its integration with ADCS, MobileIron Core automatically configures devices to obtain locally managed device certificates by using the Simple Certificate Enrollment Protocol (SCEP). Our example solution mitigates the potential of remote exploitation of SCEP by restricting certificate enrollment to mobile devices that are connected to a dedicated enterprise-managed Wi-Fi network that allows devices to access only MobileIron Core and the Network Device Enrollment Service server. Further, this example solution uses a dynamic SCEP scheme, in which MobileIron Core supplies a registered mobile device with a onetime password to include in its SCEP request, thus helping prevent unknown and untrusted devices that gain unauthorized access to the dedicated Wi-Fi network from obtaining a trusted device certificate.

The example solution’s chosen certificate enrollment configuration includes the mobile user’s User Principal Name (UPN) in the device certificate’s Subject Alternative Name field, which the Palo Alto Networks GlobalProtect VPN gateway uses to perform chain validation and enforce access control for the unique combination of mobile user and device.

MobileIron Core-registered devices also utilize the device certificate indirectly to enhance the security of remote connections to the enterprise in two ways. First, communication with MobileIron Core (which must be accessible from the internet in the demilitarized zone) is secured using two-way Transport Layer Security (TLS). This protects MobileIron Core from establishing secure connections with untrusted mobile devices. Second, the device certificate is used in the GlobalProtect VPN configuration, which restricts access to the VPN to only trusted devices. Further, GlobalProtect uses the device user’s UPN to grant appropriate access to enterprise resources based on the device user’s UPN through its integration with ADDS.

As shown in Figure 4‑2 [B29], devices present the certificates to the VPN and EMM authentication services after the certificates have been successfully issued. The GlobalProtect VPN authenticates the device user. On successful authentication, the GlobalProtect application prompts the user to authenticate using a second factor–their Active Directory domain password. Once this is verified, GlobalProtect establishes a tunnel with the gateway and is assigned an IP address from the IP pool in the gateway’s tunnel configuration.

Figure 4‑2 Example Solution Gateway Architecture

4.1.2 Mobile Component Integration¶

This section describes how the various mobile technology components integrate with one another. The majority of these components integrate with the EMM, MobileIron. MobileIron supports the integration of third-party cloud services through a defined API. MobileIron Core authenticates external systems by using basic authentication, so TLS protects the confidentiality of API account credentials and MobileIron’s responses to clients’ Representational State Transfer calls. MobileIron API client accounts for Kryptowire, Lookout Mobile Endpoint Security, and Appthority Mobile Threat Protection (MTP) are each assigned administrative roles that grant the minimum set of permissions necessary to achieve integration [B30], [B31].

4.1.2.1 Appthority–MobileIron¶

The Appthority application reputation service provides an integration with MobileIron Core systems through implementation of connector software provided by Appthority. The connector provides the code that exercises the APIs provided by MobileIron Core and the Appthority cloud service. In this integration, an API user was created within the MobileIron Core system and assigned specific roles required for successful operation of the application vetting service.

Automatic syncing between the Appthority service and MobileIron Core system can occur on a configurable basis. Specifically, the application and device inventory data are synced between the two systems. In this integration, syncing occurs every hour, but this value should be adjusted to fit the needs of the organization.

In this example solution, the integration provides the primary security benefit of compliance enforcement and remediation escalation. In the initial step of the process, the application inventory is gathered from the MobileIron Core system, and each application is assigned a threat measurement score. If an application is installed on a device that is not compliant with the configured policy, Appthority MTP communicates with the MobileIron Core system to identify those devices, which triggers MobileIron compliance enforcement actions.

4.1.2.2 Lookout–MobileIron¶

The Lookout mobile threat defense service provides integration with MobileIron Core systems through implementation of connector software provided by Lookout. The connector provides the code that exercises the APIs provided by MobileIron Core and the Lookout cloud service. This integration allows Lookout to retrieve device details as well as application inventory information and to apply labels to devices as necessary.

Following analysis, Lookout uses the API to apply specific labels to devices to categorize them based on risk posture, which is calculated based on the severity of issues detected on the device. MobileIron can then automatically respond to application of specific labels based on built-in compliance actions. This allows administrators to configure exactly how MobileIron will respond to devices in the following categories:

Pending–Lookout not yet activated
Secured–Lookout active
Threats Present–Lookout has detected threats
Deactivated–Lookout has been deactivated
Low Risk–devices with a low risk score in Lookout
Moderate Risk–devices with a moderate risk score in Lookout
High Risk–devices with a high-risk score in Lookout

4.1.2.3 Kryptowire–MobileIron¶

Kryptowire obtains device details, such as device platform, OS version, and the universally unique identifiers assigned to each registered device by MobileIron Core to enable clear identification of a particular device across systems. Kryptowire obtains the inventory of applications from all of the devices enrolled in MobileIron.

Kryptowire performs static, dynamic, and behavioral binary code analysis on mobile applications against government (NIAP) and industry (The Open Web Application Security Project, or OWASP) [B32] standards. Kryptowire provides both a detailed security analysis, provides pass/fail evidence down to the line of code, and provides a summary weighted risk score for each application.

Mobile application administrators can use these detailed reports to inform decisions on which applications are trusted and compliant with enterprise security and privacy policies and which are restricted for enterprise or personal use.

4.1.2.4 Palo Alto Networks–MobileIron¶

Palo Alto Networks’ GlobalProtect VPN is used to secure remote connections from mobile devices. MobileIron Core offers specific configuration options for the GlobalProtect client available on Android and iOS that facilitates secure deployment of VPN clients and enablement of VPN access using certificate-based authentication to the GlobalProtect gateway. Details of the certificate enrollment process are provided in Section 4.1.1

The VPN architecture used in this example solution is composed of two components of the Palo Alto Networks next-generation firewall–a GlobalProtect portal and a GlobalProtect gateway. The portal provides the management functions for VPN infrastructure. Every endpoint that participates in the GlobalProtect network receives configuration information from the portal, including information about available gateways as well as any client certificates that may be required to connect to the GlobalProtect gateway(s).

The gateway provides security enforcement for traffic from GlobalProtect applications. It is configured to provide access to specific enterprise resources only to mobile device users after a successful authentication and authorization decision.

The VPN tunnel negotiation between the VPN endpoint/mobile device and the VPN gateway is presented in Figure 4‑3 [B33]. It demonstrates a user logging into the system (1), the portal returning the client configuration (2), the agent automatically connecting to the gateway and establishing a VPN tunnel (3), and the gateway’s security policy enabling access to internal and external applications (4).

Figure 4‑3 Example Solution VPN Architecture

For our example solution, we chose to enforce an always-on VPN configuration. This configuration causes registered devices to establish a VPN connection to the GlobalProtect gateway whenever they have network connectivity–this occurs over cellular or Wi-Fi and is persistent across device reboot. This configuration affords devices with the greatest degree of protection, as additional Palo Alto Networks services can be extended to GlobalProtect. This example solution uses URL filtering, which blocks mobile devices from accessing prohibited internet domains or any domain that Palo Alto Networks associates with active exploits (e.g., phishing campaigns, watering hole attacks, botnet command and control). NIST SP 800-46 Revision 2, Guide to Enterprise Telework, Remote Access, and BYOD Security [B34], describes the most common VPN options used for remote workers.

4.1.2.4.1 FIPS Compliance¶

Any sensitive information passing over the internet, wireless networks, and other untrusted networks should have its confidentiality and integrity preserved through cryptography [B34]. While federal agencies are required to use cryptographic algorithms that are NIST-approved and contained in Federal Information Processing Standards (FIPS)-validated modules, adoption of these standards is available to private and commercial organizations [B35]. This example solution uses these best practices in the following ways:

FIPS-CC mode in the GlobalProtect VPN appliance is enabled, which requires TLS 1.1 (or above) and limits the public key use to FIPS-approved algorithms. This example solution’s implementation uses the highest version of TLS available, with TLS 1.2 being the minimum acceptable version. A full list of security functions can be found on the Palo Alto Networks FIPS-CC Security Functions documentation site [B36].
As described in Section 4.1.1, dynamic SCEP challenges are enabled.

To align our example solution with guidance in NIST SP 800-52 Revision 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations [B37], this example solution implements the following configuration:

The GlobalProtect portal and gateway restrict the list of cipher suites available to the client application by using a TLS service profile. The minimum version of TLS is set to 1.2 as recommended by NIST SP 800-52.
The GlobalProtect portal and gateway server certificates use 2048-bit RSA key modulus signed with sha256WithRSAEncryption algorithm.

4.1.2.5 iOS and Android EMM Integration¶

iOS and Android-based devices both integrate directly with EMM solutions, providing enterprise-level management of security controls based on policy.

iOS Integration

iOS devices are managed by configuration profiles. Configuration profiles can force security policies such as VPN usage, enterprise Kerberos support, and access to cloud services. iOS further incorporates a set of additional security controls in what is termed supervised mode, which denotes a corporately owned device. Typically, organizations choose to use the Apple Business Manager (formerly Device Enrollment Program) [B38] for large-scale deployments of iOS devices in supervised mode due to the reduction of labor involved in manually configuring each device. However, due to the small number of devices in our reference design, we have configured supervised mode using the Apple Configurator 2 tool [B39]. A description of iOS security capabilities can be found in Apple Platform Security [B40].

Android Integration

Similarly, Android-based devices offer security controls that an EMM can leverage for enterprise deployments. The Android Enterprise program by Google is available on devices with Android 5.0 (Lollipop) and higher. An EMM deploys a device policy controller [B41] as part of its on-device agent that controls local device policies and system applications on devices. A newer mode introduced in Android 8.0 supports fully-managed devices with a work profile, intended for COPE deployments [B42], [B43], [B44]. In this scenario, the device is corporately owned. Device level controls such as device wipe and reset to factory default settings are available. A work profile is also created to keep enterprise applications and data separate from any personal data. This scenario allows for some flexibility of the device owner to permit personal use of the device while retaining device controls and is the chosen deployment of this reference implementation.

4.2 Enterprise Security Architecture Privacy Data Map¶

Orvilia performed a privacy analysis using both the information gathered in the initial PRAM effort and the identified mobile security technologies included in the revised architecture. The output from the PRAM activities, including data flows between the components, along with their on-premises or cloud-based location, resulted in the information contained in Figure 4‑4. Note: The Key within this figure includes all data action types, but this particular example solution does not cover the Disposal of data in the Privacy Data Mapping exercise. For additional information on the PRAM activities, see Appendix G.

Figure 4‑4 NIST Privacy Risk Assessment Methodology Data Map for Orvilia’s Enterprise Security Architecture

4.3 Security Control Map¶

Using the developed risk information as input, the security characteristics of the solution were identified. A security control map was developed documenting the example solution’s capabilities with applicable Subcategories from the NIST Cybersecurity Framework Version 1.1 [B5]; NIST SP 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations [B11]; International Organization for Standardization (ISO), International Electrotechnical Commission (IEC) 27001:2013, Information technology–Security techniques–Information security management systems –Requirements [B45]; the Center for Internet Security’s Control set [B46] Version 6; and NIST SP 800-181, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework [B7].

The security control map identifies the security characteristic standards mapping for the products as they were used in the example solution. The products may be capable of additional capabilities not used in this example solution. For that reason, it is recommended the mapping not be used as a reference for all of the security capabilities these products may be able to address. The security control map can be found in Table I‑1.

5 Security Characteristic Analysis¶

This section helps familiarize the reader with:

assumptions and limitations
build testing
scenarios and findings

______________________________________________________________________________

The purpose of the security characteristic analysis is to understand the extent to which the project meets its objective of demonstrating how to increase the security of mobile devices within an enterprise by deploying EMM, MTD, MTI, application vetting, secure boot/image authentication, and VPN services.

5.1 Analysis Assumptions and Limitations¶

The security characteristic analysis has the following limitations:

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 those systems are hardened. Testing these devices would reveal only weaknesses in implementation that would not be relevant to those adopting this reference architecture.

5.2 Build Testing¶

Functional testing was used to confirm the example solution’s capabilities. We use the test activities to demonstrate Orvilia’s susceptibility to the threat before implementing the architecture detailed in this practice guide. We use the test activities again after implementing the architecture to demonstrate that the threats have been appropriately addressed.

5.2.1 Threat Event 1 —Unauthorized Access to Sensitive Information via a Malicious or Privacy-Intrusive Application¶

Summary: Unauthorized access to sensitive information via a malicious or privacy-intrusive application is tested. We tested this threat by placing a mock sensitive enterprise contact list and calendar entries on devices, then attempted to install and use applications on the Apple App Store and Google Play Store [B47] that access and back up those entries. Ideally, the enterprise’s security architecture would either detect or prevent use of these applications, or it would block the applications from accessing enterprise-controlled contact list and calendar entries.

Test Activity: Install an iOS or Android application that accesses the contact and calendar entries and backs them up to a cloud service. We have no reason to believe these applications are malicious. However, the behavior of accessing and backing up enterprise-controlled data (contacts and calendar entries) without authorization presents an activity that should be mitigated by this example solution’s security architecture.

Desired Outcome: The enterprise’s security architecture should identify the presence of the applications and the fact that they access contact and calendar entries. The security architecture should block these applications from installing, block them from running, or detect their presence and cause another appropriate response to occur, such as blocking the mobile device from accessing enterprise resources until the applications are removed.

Alternatively, built-in device mechanisms such as Apple’s managed applications functionality and Google’s Android enterprise work profile functionality could be used to separate the contact and calendar entries associated with enterprise email accounts, so they can be accessed only by enterprise applications (applications authorized and managed by the EMM), not applications manually installed by the user. The user should not have the ability to manually provision their enterprise email account. The account should be able to be provisioned only by the EMM, enabling enterprise controls on the enterprise contact list and calendar data. However, in this practice guide build, we chose to make the devices fully managed, not divided into separate enterprise and personal areas.

Observed Outcome: Appthority identified the presence of applications that have access to sensitive data and updated the device labels in MobileIron Core.

5.2.2 Threat Event 2 —Theft of Credentials Through an SMS or Email Phishing Campaign¶

Summary: A fictitious phishing event was created where protection against theft of credentials through an SMS or email phishing campaign was tested.

Test Activity:

Establish a web page with a form that impersonates an enterprise login prompt.
Send the web page’s URL via SMS or email and attempt to collect and use enterprise login credentials.

Desired Outcome: The enterprise’s security architecture should block the user from browsing to known malicious websites. Additionally, the enterprise should use multifactor authentication or phishing-resistant authentication methods, such as those based on public key cryptography, so that either there is no password for a malicious actor to capture, or capturing the password is insufficient to obtain access to enterprise resources.

Observed Outcome: The example solution used Palo Alto Networks’ next-generation firewall. The firewall includes PAN-DB, a URL filtering service that automatically blocks known malicious URLs. The URL filtering database is updated regularly to help protect users from malicious URLs. The next-generation firewall blocked the attempt to visit the phishing site because the malicious URL was present in PAN-DB. This kept the user from accessing the phishing site.

5.2.3 Threat Event 3—Malicious Applications Installed via URLs in SMS or Email Messages¶

Summary: Unauthorized applications, not present on the official Apple App Store or Google Play Store, are installed via URL links in SMS, email messages, or third-party websites.

Test Activity (Android):

Send an email to the user containing a link to a file with a message urging the user to click on the link to install the application.
On the device, if not already enabled, attempt to enable the Unknown Sources toggle setting in the device security settings to allow installing applications from sources other than the Google Play Store.
On the device, read the received email, click on the link, and attempt to install the F-Droid application.
Observe whether the F-Droid application could be successfully installed. If so, observe whether the enterprise detected and responded to installation of the unauthorized application.

Test Activity (iOS):

Send an email to the user containing a link to an iOS application available for installation from a website, along with a message urging the user to click on the link to install the application.
On the device, read the received email, click on the link, and attempt to install the application.
On the device, attempt to explicitly trust the developer’s signing certificate. Then attempt to run the application.
Observe whether the application could run. If so, observe whether the enterprise detected and responded to installation of the unauthorized application.

Desired Outcome: The device does not allow the user to install the unauthorized application. If the application is somehow installed, its presence should be detected, and an appropriate response should occur, such as blocking the device from accessing enterprise resources until the application is removed.

Observed Outcome: On iOS devices, Lookout detected that an application had been sideloaded, and it applied a label to the device. MobileIron then quarantined the device (removed the device’s access to enterprise resources) until the threat was resolved.

On iOS devices, MobileIron has a configuration option that prohibited the user from trusting the developer certificate.

On Android devices, MobileIron has a configuration option that prohibited the user from enabling Unknown Sources on the device.

5.2.4 Threat Event 4 —Confidentiality and Integrity Loss due to Exploitation of Known Vulnerability in the OS or Firmware¶

Summary: When malware successfully exploits a code execution vulnerability in the mobile OS or device drivers, the delivered code generally executes with elevated privileges and issues commands in the context of the root user or the OS kernel.

Test Activity: Attempt to access enterprise resources from a mobile device with known vulnerabilities (e.g., running an older, unpatched version of iOS or Android).

Desired Outcome: The enterprise’s security architecture should identify the presence of devices that are running an outdated version of iOS or Android susceptible to known vulnerabilities. It should be possible, when warranted by the risks, to block devices from accessing enterprise resources until system updates are installed.

Observed Outcome: Lookout identified that devices were running outdated operating systems. This information was communicated to MobileIron, which subsequently automatically quarantined the devices until the operating system was updated.

5.2.5 Threat Event 5 —Violation of Privacy via Misuse of Device Sensors¶

Summary: There is collection of location, camera, or microphone data by an application that has no need to access this data.

Note: Not all applications that have access to location, camera, or microphone data are malicious. However, when an application is found to be collecting this information, additional vetting or testing may be required to determine the intent of its use and to then determine if the application is malicious.

Test Activity: Upload the application to Kryptowire; observe the output report.

Desired Outcome: Output report identifies the use of location, camera, or microphone use by the application.

Observed Outcome: The Kryptowire report identified the use of location sensor, camera, or microphone by the application. An administrator could then perform further testing on the application, and if necessary, identify the application as prohibited within the EMM.

5.2.6 Threat Event 6—Compromise of the Integrity of the Device or Its Network Communications via Installation of Malicious EMM/MDM, Network, VPN Profiles, or Certificates¶

Summary: There is compromise of the integrity of the device or its network communications via installation of malicious EMM/MDM, network, VPN profiles, or certificates using a person-in-the-middle approach.

Test Activity:

Install mitmproxy (https://mitmproxy.org/) on a computer (we used a Mac) connected to the same Wi-Fi network as the mobile devices.
Install mitmproxy’s CA certificate (stored at ~/.mitmproxy/mitmproxy-ca-cert.cer on our Mac) onto the mobile devices being tested. iOS- and Android-specific instructions are found below.
Configure the computer as necessary to run mitmproxy in transparent mode, as described in https://docs.mitmproxy.org/stable/howto-transparent/.
To illustrate a malicious actor’s ability to manipulate network traffic, we downloaded the mitmproxy internet_in_mirror script from https://docs.mitmproxy.org/stable/addons-examples/#internet-in-mirror. It performs a mirror reflection of the content of all websites.
Run mitmproxy in transparent mode and using the internet_in_mirror script: mitmproxy –mode transparent –ssl-insecure –showhost -s internet_in_mirror.py
Rather than perform an intrusive attack such as address resolution protocol spoofing, we manually configured each mobile device’s Wi-Fi network settings to change the default gateway’s (sometimes referred to as router in the network settings) IP address to the computer’s IP address rather than the router’s IP address. This configuration change forced all the network traffic from each device through the computer.

Test Activity (Android):

Place mitmproxy’s CA certificate as an attachment within an email message.
Open the email message on the Android device and click on the attachment to attempt to install the CA certificate.
Modify the device’s Wi-Fi network settings to manually change the default gateway’s IP address to the address of the computer running mitmproxy.
Browse to a hypertext transfer protocol secure (https) website (e.g., https://www.nccoe.nist.gov), and observe whether the content has been reversed, illustrating that the person-in-the-middle attack on a TLS-protected connection was successful.

Test Activity (iOS):

Use Apple Configurator 2 on a Mac, or another tool, to create an iOS configuration profile containing mitmproxy’s CA certificate. The configuration profile used in testing was named Enterprise Access. The configuration profile was signed using a key associated with an Apple free developer account certificate. The signature was optional (Configuration profiles do not have to be signed).
Send the configuration profile as an attachment within an email message.
Open the email message and attempt to click on the attachment to install the configuration profile. Attempt to follow the prompts to complete the profile installation.
Attempt to enable the CA certificate in the iOS device’s Certificate Trust Settings.

Desired Outcome: The enterprise’s security architecture should block installation of unauthorized configuration profiles (iOS) or CA certificates (Android). Alternatively, the security architecture may detect the presence of unauthorized configuration profiles or CA certificates and perform another appropriate action, such as blocking the device from accessing enterprise resources until the configuration profile or CA certificate is removed. The architecture should also detect attempted person-in-the-middle attacks.

Observed Outcome: Lookout detected a person-in-the-middle attack on both iOS and Android devices. Lookout also detected the unknown configuration profile on iOS.

5.2.7 Threat Event 7—Loss of Confidentiality of Sensitive Information via Eavesdropping on Unencrypted Device Communications¶

Summary: Malicious actors can readily eavesdrop on communication over unencrypted, wireless networks such as public Wi-Fi access points, which are commonly provided by coffee shops and hotels. While a device is connected to such a network, a malicious actor would gain unauthorized access to any data sent or received by the device for any session not already protected by encryption at either the transport or application layers.

Test Activity: Test if applications will attempt to establish an http or unencrypted connection.

Desired Outcome: Be alerted when applications attempt to make an unencrypted connection or prevent the application from being able to do so.

Appthority can determine if applications will attempt to establish an http or unencrypted connection.

iOS and Android also can require a secure connection for an application. (When it tries to connect to the server if it is unencrypted, it will just drop the connection).

Observed Outcome: On both iOS and Android, Appthority detected a “sends data unencrypted” threat for an application. Transferring data over unencrypted connections could result in the loss of confidentiality of information being transmitted by that application.

5.2.8 Threat Event 8—Compromise of Device Integrity via Observed, Inferred, or Brute-Forced device Unlock Code¶

Summary: A malicious actor may be able to obtain a user’s device unlock code by direct observation, side-channel attacks, or brute-force attacks.

Test Activity:

Attempt to completely remove the device unlock code. Observe whether the attempt succeeds.
Attempt to set the device unlock code to “1234,” a weak four-digit personal identification number (PIN). Observe whether the attempt succeeds.
Attempt to continuously unlock the device, confirming the device is factory reset after 10 failed attempts.

Desired Outcome: Policies set on the device by the EMM (MobileIron) should require a device unlock code to be set, prevent the device unlock code from being removed, require a minimum complexity for the device unlock code, and factory reset the device after 10 failed unlock attempts.

Additionally, Lookout can identify and report devices that have the lock screen disabled.

Observed Outcome: MobileIron applied a policy to the devices that enforced a mandatory PIN and device wipe capability after 10 failed unlock attempts. Further, Lookout reports when the device has the lock screen disabled. For both devices, all data was erased after 10 failed unlock attempts.

The option to remove the unlock PIN/passcode had been disabled. Upon attempting to set the PIN to one with repetitious or consecutive characters, an error was displayed, informing the user they cannot use the PIN they entered.

5.2.9 Threat Event 9—Unauthorized Access to Backend Services via Authentication or Credential Storage Vulnerabilities in Internally Developed Applications¶

Summary: If a malicious actor gains unauthorized access to a mobile device, the attacker also has access to the data and applications on that mobile device. The mobile device may contain an organization’s in-house applications and can subsequently gain access to sensitive data or backend services.

Test Activity: Application was submitted to Appthority for analysis of credential weaknesses.

Desired Outcome: Discover and report credential weaknesses.

Observed Outcome: Appthority recognized within an application that it uses hard-coded credentials. The application’s use of hard-coded credentials could introduce vulnerabilities if the hard-coded credentials were used for access to enterprise resources by unauthorized entities. If the hard-coded credentials result was applied to an application policy, that policy would be applied as a label in MobileIron to all devices with that application installed.

5.2.10 Threat Event 10 —Unauthorized Access of Enterprise Resources from an Unmanaged and Potentially Compromised Device¶

Summary: An employee that accesses enterprise resources from an unmanaged mobile device may expose the enterprise to vulnerabilities that may compromise enterprise data. Unmanaged devices do not benefit from security mechanisms deployed by the organization such as mobile threat defense, mobile threat intelligence, application vetting services, and mobile security policies. These unmanaged devices limit an organization’s visibility into the state of a mobile device, including if the device is compromised by an attacker.

Test Activity: Attempt to directly access enterprise services, e.g., Exchange email server or corporate VPN, on a mobile device that is not enrolled into the EMM system.

Desired Outcome: Enterprise services should not be accessible from devices that are not enrolled into the EMM system. Otherwise, the enterprise is not able to effectively manage devices to prevent threats.

Observed Outcome: Devices that were not enrolled in MobileIron were unable to access enterprise resources as the GlobalProtect VPN gateway prevented the devices from authenticating without proper client certificates. The client certificates are obtainable only by enrolling in the EMM.

5.2.11 Threat Event 11—Loss of Organizational Data Due to a Lost or Stolen Device¶

Summary: Due to the nature of the small form factor of mobile devices, they can be misplaced or stolen. A malicious actor who gains physical custody of a device with inadequate security controls may be able to gain unauthorized access to sensitive data or resources accessible to the device.

Test Activity: Attempt to download enterprise data onto a mobile device that is not enrolled into the EMM system (may be performed in conjunction with TE-10). Attempt to remove (in conjunction with TE-8) the device unlock code or demonstrate that the device does not have a device unlock code in place. Attempt to locate and wipe the device through the EMM console (it will fail if the device is not enrolled in the EMM).

Desired Outcome: It should be possible to locate or wipe EMM-enrolled devices in response to a report that they have been lost or stolen. As demonstrated by TE-10, only EMM-enrolled devices should be able to access enterprise resources. As demonstrated by TE-8, EMM-enrolled devices can be forced to have a screen lock with a passcode of appropriate strength, which helps resist exploitation (including loss of organizational data) if the device has been lost or stolen.

Should the device be unreachable by the EMM (e.g., disconnected from all networking), EMM control and corporate data will be removed after 10 failed unlock attempts.

Observed Outcome (Enrolled Devices): Enrolled devices are protected. An enterprise policy requiring a personal identification number/lock screen is present, and therefore, the enterprise data on the device could not be accessed. After 10 attempts to access the device, the device was wiped. Additionally, the device was remotely wiped after it was reported as lost to enterprise mobile device service management.

Observed Outcome (Unenrolled Devices): As shown in Threat Event 10, only enrolled devices can access enterprise services. When the device attempted to access enterprise data, no connection to the enterprise services was available. Because the device cannot access the enterprise, enterprise information would not be located on the device.

5.2.12 Threat Event 12—Loss of Confidentiality of Organizational Data Due to Its Unauthorized Storage in Non-Organizationally Managed Services¶

Summary: If employees violate data management policies by using unmanaged services to store sensitive organizational data, this data will be placed outside organizational control, where the organization can no longer protect its confidentiality, integrity, or availability. Malicious actors who compromise the unauthorized service account or any system hosting that account may gain unauthorized access to the data.

Test Activity: Connect to the enterprise VPN. Open an enterprise website or application. Attempt to extract enterprise data by taking a screenshot, or copy/paste and send it via an unmanaged e-mail account.

Desired Outcome: Screenshots and other data-sharing actions will be prohibited by the EMM while using managed applications.

Observed Outcome: Through MobileIron restriction and lockdown policies, an administrator prevented the following actions on devices:

Android

copy/paste
screen capture
data transfer over near-field communication
data transfer over Universal Serial Bus
Bluetooth

iOS

screen capture and recording (iOS 9+)
AirDrop
iCloud Backup
iCloud Documents and data access
managed applications storing data in iCloud
data flow between managed and unmanaged applications
hand-off

These restrictions prohibited the user from executing common data leakage methods.

5.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 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.

This section provides the scenarios and findings for the security and privacy characteristics the example solution was intended to support. They include:

development of the Cybersecurity Framework and NICE Framework mappings
threat event scenarios and example solution architecture mitigations
data action scenarios and potential mitigations that organizations could employ

5.3.1 Cybersecurity Framework and NICE Framework Work Roles Mappings¶

While the example solution was being developed, the Cybersecurity Framework Subcategory mappings were developed into a table mapping for organizations implementing the example solution’s capabilities.

As the example solution’s products were installed, configured, and used in the example solution architecture, the example solution’s functions and their corresponding Cybersecurity Framework Subcategories, along with other guidance alignment, were determined and documented.

This mapping became an important resource to the example solution contained in this practice guide because it provides the ability to communicate with the organization’s stakeholders about the security controls that the example solution can help mitigate, and the workforce requirements that the example solution will require.

The example solution’s products, security control, and workforce mapping can be found in Table I‑1.

5.3.2 Threat Event Scenarios and Findings¶

As part of the findings, the threat events were mitigated in the example solution architecture using the concepts and technology shown in Table 5‑1. Each threat event was matched with functions that helped mitigate the risks posed by the threat event.

Note: While not demonstrated in the table, TEE provided tamper-resistant processing environment capabilities that helped mitigate mobile device runtime and memory threats in the example solution.

Table 5‑1 Threat Event Scenarios and Findings Summary

Threat Event	How the Example Solution Architecture Helps Mitigate the Threat Event	The Technology Function That Helps Mitigate the Threat Event
Threat Event 1: Unauthorized access to sensitive information via a malicious or privacy-intrusive application	Ensured administrators have insight into what corporate data applications can access.	MTI
Threat Event 2: Theft of credentials through an SMS or email phishing campaign	Utilized PAN-DB to block known malicious websites.	Firewall
Threat Event 3: Malicious applications installed via URLs in SMS or email messages	Disabled installing applications from unknown sources.	EMM
Threat Event 4: Confidentiality and integrity loss due to exploitation of known vulnerability in the OS or firmware	Quarantined noncompliant device until its operating system was updated.	EMM
Threat Event 5: Violation of privacy via misuse of device sensors	Application vetting reports indicated the sensors to which an application requested access.	MTI
Threat Event 6: Compromise of the integrity of the device or its network communications via installation of malicious EMM/MDM, network, VPN profiles, or certificates	Detected a person-in-the-middle attack and an unauthorized configuration profile on iOS.	MTD
Threat Event 7: Loss of confidentiality of sensitive information via eavesdropping on unencrypted device communications	Application vetting reports indicated if an application sent data without proper encryption.	Application Vetting
Threat Event 8: Compromise of device integrity via observed, inferred, or brute-forced device unlock code	Enforced mandatory device wipe capabilities after 10 failed unlock attempts.	EMM
Threat Event 9: Unauthorized access to backend services via authentication or credential storage vulnerabilities in internally developed applications	Application vetting reports indicated if an application used credentials improperly.	MTI
Threat Event 10: Unauthorized access of enterprise resources from an unmanaged and potentially compromised device	Devices not enrolled in the EMM system were not able to connect to the corporate VPN.	VPN
Threat Event 11: Loss of organizational data due to a lost or stolen device	Enterprise data was protected by enforced passcode policies and device wipe capabilities.	EMM
Threat Event 12: Loss of confidentiality of organizational data due to its unauthorized storage in non-organizationally managed services	Policies that enforce data loss prevention were pushed to devices.	EMM

5.3.3 Data Action Scenarios and Findings¶

The results of the PRAM found that three data actions were especially relevant to the build. Potential mitigations that could be used by an organization to lessen their impact were identified by the PRAM as shown below. Further details on the PRAM’s findings can be found in Appendix G.

Table 5‑2 Data Action Scenarios and Findings Summary

Data Action

Data Action Description

How the Data Action Could Be Mitigated

Data Action 1: Blocking access and wiping devices

Employees are likely to use their devices for both personal and work-related purposes. Therefore, in a system that features the capability to wipe a device entirely, there could be an issue of employees losing personal data.

Block the device’s access to enterprise resources until it is granted access permission again.

Selectively wipe elements of the device without removing all data on the device.

Advise employees to back up the personal data maintained on devices.

Limit staff with the ability to perform wipes or block access.

Data Action 2: Employee monitoring

Employer-owned or controlled networks monitor activities on a regular basis. Employees may not be aware of the monitoring of their interactions with the system and may not want this monitoring to occur.

Limit staff with ability to review data about employees and their devices.

Develop organizational policies and techniques to limit collection of specific data elements.

Develop organizational policies and techniques regarding disposal of PII.

Data Action 3: Data sharing across parties

Data transmission about individuals and their devices among a variety of different parties could be confusing for employees who might not know who has access to different information about them.

Develop organizational policies and techniques for de-identification of data.

Use encryption.

Limit or disable access to data.

Develop organizational policies and techniques to limit collection of specific data elements.

Use contracts to limit third-party data processing.

6 Conclusion¶

This document provides an overview of the Risk Management Framework and the Privacy Risk Assessment Methodology, an explanation of mobile device security concepts, and an example solution for organizations implementing a COPE deployment.

Our fictitious Orvilia Development organization started with a mobile device infrastructure that was lacking mobile device security architecture concepts. It employed security risk management and privacy risk assessment methodologies to understand the current gaps in its architecture and methods to enhance the security and privacy of its systems.

After identifying the core threat events from the risk assessment, the appropriate mobile device security technologies were applied. These included an on-premises EMM solution integrated with cloud- and agent-based mobile security technologies to help deploy a set of security and privacy capabilities in support of a usage scenario.

The practice guide also includes in Volume C a series of How-To Guides—step-by-step instructions covering the initial setup (installation or provisioning) and configuration for each component of the architecture—to help security engineers rapidly deploy and evaluate our example solution in their test environment.

The example solution of our reference design uses standards-based, commercially available products. It can be used directly by any organization with a COPE usage scenario by implementing a security infrastructure that supports an integration of on-premises with cloud-hosted mobile security technologies. The practice guide provides a reference design and example solution that an organization may use in whole or in parts as the basis for a custom solution that realizes the security and privacy characteristics that best support its unique mobile device usage scenario.

7 Future Build Considerations¶

A topic of interest for a future build is a bring your own device (BYOD) scenario. This entails protecting corporate data on personally owned devices that employees will use for work as well as personal activity. Another area of interest is a thin client deployed to mobile devices allowing the employee to access a virtual device contained within the corporate infrastructure.

Further, examination of emerging 5G technologies as they relate to mobile device security is a new field that presents a wide breadth of research opportunities.

Mobile Device Security:

1 Summary¶

1.1 Challenge¶

1.2 Solution¶

1.2.1 Standards and Guidance¶

1.3 Benefits¶

2 How to Use This Guide¶

2.1 Typographic Conventions¶

3 Approach¶

3.1 Audience¶

3.2 Scope¶

3.2.1 Orvilia Development¶

3.3 Assumptions¶

3.3.1 Systems Engineering¶

3.4 Risk Assessment¶

3.4.1 Risk Assessment of the Fictional Organization Orvilia Development¶

3.4.2 Development of Threat Event Descriptions¶

3.4.2.1 Threat Event 1—Unauthorized Access to Sensitive Information via a Malicious or Privacy-Intrusive Application¶

3.4.2.2 Threat Event 2—Theft of Credentials Through a Short Message Service (SMS) or Email Phishing Campaign¶

3.4.2.3 Threat Event 3—Malicious Applications Installed via Uniform Resource Locators (URLs) in SMS or Email Messages¶

3.4.2.4 Threat Event 4—Confidentiality and Integrity Loss Due to Exploitation of Known Vulnerability in the OS or Firmware¶

3.4.2.5 Threat Event 5—Violation of Privacy via Misuse of Device Sensors¶

3.4.2.6 Threat Event 6—Compromise of the Integrity of the Device or Its Network Communications via Installation of Malicious EMM/MDM, Network, VPN Profiles, or Certificates¶

3.4.2.7 Threat Event 7—Loss of Confidentiality of Sensitive Information via Eavesdropping on Unencrypted Device Communications¶

3.4.2.8 Threat Event 8—Compromise of Device Integrity via Observed, Inferred, or Brute-Forced Device Unlock Code¶

3.4.2.9 Threat Event 9—Unauthorized Access to Backend Services via Authentication or Credential Storage Vulnerabilities in Internally Developed Applications¶

3.4.2.10 Threat Event 10—Unauthorized Access of Enterprise Resources from an Unmanaged and Potentially Compromised Device¶

3.4.2.11 Threat Event 11—Loss of Organizational Data Due to a Lost or Stolen Device¶

3.4.2.12 Threat Event 12—Loss of Confidentiality of Organizational Data Due to Its Unauthorized Storage in Non-Organizationally Managed Services¶

3.4.3 Identification of Vulnerabilities and Predisposing Conditions¶

3.4.4 Summary of Risk Assessment Findings¶

3.4.5 Privacy Risk Assessment¶

3.4.5.1 Potential Problems for Individuals¶

3.4.5.1.1 Data Action 1: Blocking Access and Wiping Devices¶

3.4.5.1.2 Data Action 2: Employee Monitoring¶

3.4.5.1.3 Data Action 3: Data Sharing Across Parties¶

3.5 Solution Goals¶

3.5.1 Current Architecture¶

3.5.2 Security Goals¶

3.6 Technologies¶

3.6.1 Architecture Components¶

3.6.1.1 Trusted Execution Environment¶

3.6.1.2 Enterprise Mobility Management¶

3.6.1.3 Virtual Private Network¶

3.6.1.4 Mobile Application Vetting Service¶

3.6.1.5 Mobile Threat Defense¶

3.6.1.6 Mobile Threat Intelligence¶

3.6.1.7 Mobile Operating System Capabilities¶

3.6.1.7.1 Secure Boot¶

3.6.1.7.2 Device Attestation¶

3.6.1.7.3 Device Management and MDM API¶

4 Architecture¶

4.1 Architecture Description¶

4.1.1 Enterprise Integration¶

4.1.2 Mobile Component Integration¶

4.1.2.1 Appthority–MobileIron¶

4.1.2.2 Lookout–MobileIron¶

4.1.2.3 Kryptowire–MobileIron¶

4.1.2.4 Palo Alto Networks–MobileIron¶

4.1.2.4.1 FIPS Compliance¶

4.1.2.5 iOS and Android EMM Integration¶

4.2 Enterprise Security Architecture Privacy Data Map¶

4.3 Security Control Map¶

5 Security Characteristic Analysis¶

5.1 Analysis Assumptions and Limitations¶

5.2 Build Testing¶

5.2.1 Threat Event 1 —Unauthorized Access to Sensitive Information via a Malicious or Privacy-Intrusive Application¶

5.2.2 Threat Event 2 —Theft of Credentials Through an SMS or Email Phishing Campaign¶

5.2.3 Threat Event 3—Malicious Applications Installed via URLs in SMS or Email Messages¶

5.2.4 Threat Event 4 —Confidentiality and Integrity Loss due to Exploitation of Known Vulnerability in the OS or Firmware¶

5.2.5 Threat Event 5 —Violation of Privacy via Misuse of Device Sensors¶

5.2.6 Threat Event 6—Compromise of the Integrity of the Device or Its Network Communications via Installation of Malicious EMM/MDM, Network, VPN Profiles, or Certificates¶

5.2.7 Threat Event 7—Loss of Confidentiality of Sensitive Information via Eavesdropping on Unencrypted Device Communications¶

5.2.8 Threat Event 8—Compromise of Device Integrity via Observed, Inferred, or Brute-Forced device Unlock Code¶

5.2.9 Threat Event 9—Unauthorized Access to Backend Services via Authentication or Credential Storage Vulnerabilities in Internally Developed Applications¶

5.2.10 Threat Event 10 —Unauthorized Access of Enterprise Resources from an Unmanaged and Potentially Compromised Device¶

5.2.11 Threat Event 11—Loss of Organizational Data Due to a Lost or Stolen Device¶

5.2.12 Threat Event 12—Loss of Confidentiality of Organizational Data Due to Its Unauthorized Storage in Non-Organizationally Managed Services¶

5.3 Scenarios and Findings¶

5.3.1 Cybersecurity Framework and NICE Framework Work Roles Mappings¶