Appendix A List of Acronyms

ABM	Apple Business Manager
AD	Active Directory
API	Application Programming Interface
APN	Apple Push Notification
BYOD	Bring Your Own Device
CA	Certificate Authority
CN	Common Name
CRADA	Cooperative Research and Development Agreement
DC	Domain Controller
DMZ	Demilitarized Zone
DN	Distinguished Name
DNS	Domain Name System
EMM	Enterprise Mobility Management
FQDN	Fully Qualified Domain Name
HKEY	Handle to Registry Key
HKLM	HKEY_LOCAL_MACHINE
HTTP	Hypertext Transfer Protocol
HTTPS	Hypertext Transfer Protocol Secure
IBM	International Business Machines
ID	Identification
IIS	Internet Information Services
IP	Internet Protocol
IPSec	Internet Protocol Security
IPv4	Internet Protocol version 4
IT	Information Technology
ITL	Information Technology Laboratory
LDAP	Lightweight Directory Access Protocol
MDM	Mobile Device Management
NCCoE	National Cybersecurity Center of Excellence
NDES	Network Device Enrollment Service
NIST	National Institute of Standards and Technology
OS	Operating System
PII	Personally Identifiable Information
PIN	Personal Identification Number
PKI	Public Key Infrastructure
SCEP	Simple Certificate Enrollment Protocol
SMTP	Simple Mail Transport Protocol
SP	Special Publication
SSID	Service Set Identifier
SSL	Secure Sockets Layer
TLS	Transport Layer Security
UE	User Enrollment
URL	Uniform Resource Locator
UUID	Universally Unique Identifier
VPN	Virtual Private Network
WAN	Wide Area Network
zIPS	Zimperium Mobile IPS

Appendix B Glossary

Bring Your Own Device (BYOD)

A non-organization-controlled telework client device. [C2]

Appendix C References

C1

International Business Machines. “Cloud Extender architecture.” [Online]. Available: https://www.ibm.com/support/knowledgecenter/en/SS8H2S/com.ibm.mc.doc/ce _source/references/ce_architecture.htm.

C2

M. Souppaya and K. Scarfone, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security, National Institute of Standards and Technology (NIST) Special Publication 800-46 Revision 2, NIST, Gaithersburg, Md., July 2016. Available: https://csrc.nist.gov/publications/detail/sp/800-46/rev-2/final.

Appendix D Example Solution Lab Build Testing Details

This section shows the test activities performed to demonstrate how this practice guide’s example solution that was built in the National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE) lab addresses the threat events and privacy risks defined from the risk assessment found in Volume B, Section 3.4.

D.1 Threat Event 1 – Unauthorized Access to Sensitive Information Via a Malicious or Intrusive Application Practices

Summary: Unauthorized access to work information via a malicious or privacy-intrusive application.

Test Activity: Place mock enterprise contacts on devices, then attempt to install and use unmanaged applications that access and back up those entries.

Desired Outcome: Built-in device mechanisms such as Apple User Enrollment functionality and Google’s Android Enterprise work profile functionality are used to separate the contact and calendar entries associated with enterprise email accounts so that they can only be accessed by enterprise applications (applications that the enterprise mobility management (EMM) authorizes and manages), not by applications manually installed by the user.

Observed Outcome: Since the test application was unmanaged, it was unable to access the enterprise contacts and calendar entries. This is due to Android Enterprise and Apple User Enrollment providing data separation and isolation capabilities between the personal and work profiles. The observed outcomes are shown in Figure D-1 and Figure D-2, which show how a contact created in a work profile cannot be seen by a personal profile. In addition, Figure D-3 and Figure D-4 show how a contact created in a managed application cannot be seen by an unmanaged application.

Figure D‑1 Contact Created in Work Profile

Figure D‑2 Personal Profile Can’t See Work Contacts

Figure D‑3 Contact Created in Managed App

Figure D‑4 Unmanaged App Can’t See Managed Contacts

D.2 Threat Event 2 – Theft of Credentials Through a Short Message Service or Email Phishing Campaign

Summary: A fictional phishing event was created to test protection against the theft of credentials through an email phishing campaign.

Test Activity:

• This threat event can be tested by establishing a web page with a form that impersonates an enterprise login prompt.

• The web page’s uniform resource locator (URL) is then sent via email and there is an 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 require 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 when accessing it from within the work profile. However, if the malicious URL were not present in PAN-DB, or the URL was accessed in the personal profile of the device, the user would be allowed to access the website. Figure D-5 shows the observed outcome of the phishing webpage being blocked from within the work profile.

Figure D‑5 Fictitious Phishing Webpage Blocked

D.3 Threat Event 3 – Confidentiality and Integrity Loss Due to Exploitation of Known Vulnerability in the OS or Firmware

Summary: Confidentiality and integrity loss due to the exploitation of a known vulnerability in the operating system or firmware.

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: Zimperium was able to identify devices that were running an outdated version of iOS or Android, and it informed MaaS360 when a device was out of compliance. Once MaaS360 alerted the user, they had a pre-configured amount of time to remediate the risk before work data was removed from the device, leaving the personal data unaffected. Figure D-6 and Figure D-7 show the security architecture identifying the presence of outdated operating systems.

Figure D‑6 iOS MaaS360 OS Compliance Alert

Figure D‑7 Zimperium Risk Detected

D.4 Threat Event 4 – Loss of Confidentiality of Sensitive Information Via Eavesdropping on Unencrypted Device Communications

Summary: Loss of confidentiality of sensitive information via eavesdropping on unencrypted device communications.

Test Activity: Test if applications will attempt to establish a hypertext transfer protocol or unencrypted connection.

Desired Outcome:

• Android: Because all work applications are inside a work profile, a profile-wide virtual private network (VPN) policy can be applied to mitigate this threat event; all communications, both encrypted and unencrypted, will be sent through the VPN tunnel. This will prevent eavesdropping on any communication originating from a work application.

• iOS: Apply a per-application VPN policy that will send all data transmitted by managed applications through the VPN tunnel. This will prevent eavesdropping on any unencrypted communication originating from work applications.

• Kryptowire can identify if an application attempts to establish an unencrypted connection.

Observed Outcome: The Kryptowire report indicated that the application did not use in-transit data encryption. When the managed version of that application was launched, an SSL VPN connection was automatically established. Figure D-8 shows the analysis summary finding of no in transit data encryption in use.

Figure D‑8 Kryptowire Application Report

D.5 Threat Event 5 – Compromise of Device Integrity Via Observed, Inferred, or Brute-Forced Device Unlock Code

Summary: Compromise of device integrity via observed, inferred, or brute-forced device unlock code.

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.

Desired Outcome: Policies set on the device by the EMM (MaaS360) should require a device unlock code to be set, prevent the device unlock code from being removed, and require a minimum complexity for the device unlock code. The VPN (GlobalProtect) should require periodic re-authentication with multi-factor authentication to prevent devices with a bypassed lock screen from accessing on-premises enterprise resources.

Additionally, the MTD (Zimperium) can identify and report iOS devices with a disabled lock screen.

Observed Outcome: MaaS360 applies a policy to the devices to enforce a mandatory PIN, Zimperium reports devices with a disabled lock screen, and GlobalProtect requires periodic re-authentication using MFA. Figure D-9 through Figure D-11 show the passcode and lock screen configuration settings.

Figure D‑9 Android Passcode Configuration

Figure D‑10 iOS Passcode Configuration

Figure D‑11 Zimperium Detecting Disabled Lock screen

D.6 Threat Event 6 – Unauthorized Access to Backend Services Via Authentication or Credential Storage Vulnerabilities in Internally Developed Applications

Summary: Unauthorized access to backend services via authentication or credential storage vulnerabilities in internally developed applications.

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

Desired Outcome: Discover and report credential weaknesses.

Observed Outcome: Kryptowire recognized that the application uses hardcoded credentials. The application’s use of hardcoded credentials could introduce vulnerabilities if unauthorized entities used the hardcoded credentials to access enterprise resources. Figure D-12 shows the discovery of hardcoded credentials.

Figure D‑12 Application Report with Hardcoded Credentials

D.7 Threat Event 7 – Unauthorized Access of Enterprise Resources From an Unmanaged and Potentially Compromised Device

Summary: Unauthorized access of enterprise resources from an unmanaged and potentially compromised device.

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

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

Observed Outcome: Devices that were not enrolled in MaaS360 were unable to access enterprise resources as the GlobalProtect VPN gateway prevented the devices from authenticating without proper client certificates—obtainable only through enrolling in the EMM. Figure D-13 through Figure D-15 show the desired outcome of the VPN gateway protecting the enterprise.

Figure D‑13 Attempting to Access the VPN on an Unmanaged iOS Device

Figure D‑14 Attempting to Access the VPN on an Unmanaged Android Device

Figure D‑15 Attempting to Access the VPN on a Managed Android Device

D.8 Threat Event 8 – Loss of Organizational Data Due to a Lost or Stolen Device

Summary: Loss of organizational data due to a lost or stolen device.

Test Activity: Attempt to download enterprise data onto a mobile device that is not enrolled in the EMM system (may be performed in conjunction with TE-7). Attempt to remove (in conjunction with TE-5) the screen lock passcode or demonstrate that the device does not have a screen lock passcode in place. Attempt to locate and selectively wipe the device through the EMM console (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-7, only EMM enrolled devices should be able to access enterprise resources. As demonstrated by TE-5, 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.

Observed Outcome (Enrolled Devices): Enrolled devices are protected. They have an enterprise policy requiring a PIN/lock screen, and therefore, the enterprise data on the device could not be accessed. Additionally, the device could be remotely wiped after it was reported as lost to enterprise mobile device service management, ensuring no corporate data is left in the hands of attackers.

Observed Outcome (Unenrolled Devices): As shown in Threat Event 7, only enrolled devices could access enterprise resources. When the device attempted to access enterprise data, no connection to the enterprise services was available. Because the device cannot access the enterprise, the device would not contain enterprise information.

In both outcomes, both enrolled and unenrolled, it would be at the user’s discretion if they wanted to wipe all personal data as well. Because this is a Bring Your Own Device (BYOD) scenario, only corporate data (managed applications on iOS, and the work container on Android) would be deleted from a device if the device were lost or stolen. Figure D-16 through Figure D-19 show the removal of only organization data using selective wipe features.

Figure D‑16 Selective Wiping a Device

Figure D‑17 Selective Wipe Complete

Figure D‑18 Corporate Data Removal Confirmation Notification on iOS

Figure D‑19 Work Profile Removal Notification on Android

D.9 Threat Event 9 – Loss of Confidentiality of Organizational Data Due to its Unauthorized Storage in Non-Organizationally Managed Services

Summary: Loss of confidentiality of organizational data due to its unauthorized storage in non-organizationally managed services.

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 email account.

Desired Outcome: The EMM will prohibit screenshots and other data-sharing actions while using managed applications.

Observed Outcome: As shown in Figure D-20 through Figure D-22, MaaS360 device policies prevented the following actions on BYOD managed phones:

• Android

  • clipboard sharing

  • screen capture

  • share list

  • backup to Google

  • Secure Digital card write

  • Universal Serial Bus storage

  • video recording

  • Bluetooth

  • background data sync

  • Android Beam

  • Sbeam

• iOS

  • opening, writing, and saving from managed to unmanaged applications

  • AirDrop for managed applications

  • screen capture

  • AirPlay

  • iCloud backup

  • document, photo stream, and application sync

  • print

  • importing files

Figure D‑20 iOS DLP Configuration Options

Figure D‑21 Android DLP Configuration

Figure D‑22 Attempting to Paste Text on iOS Between Unmanaged and Managed Apps

D.10 Privacy Risk 1 – Wiping Activities on the Employee’s Device May Inadvertently Delete the Employee’s Personal Data

Summary: Personal data on the phone could be lost during a device wipe.

Test Activity: Selectively wipe a device using MaaS360; restrict staff access to only allow wiping of work profile data.

Desired Outcome: The user will no longer be able to access work applications and data on the device and retains all access to their personal applications and data. The restricted administrator accounts will only be able to remove work profile data.

Observed Outcome: Corporate data and applications are removed while personal data is untouched. The EMM console removes staff access to performing full device wiping. Figure D-23 shows initiation of a selective wipe. The selective wipe will remove the Mail Server account and all corporate settings available to the device.

Figure D‑23 Selective Wipe

Additional Potential Mitigations:

• Notify users of use-policy regarding corporate applications.

• Disallow configuration of work applications by users where possible to prevent comingling of personal and work data.

• Restrict staff access to system capabilities that permit removing device access or performing wipes.

D.11 Privacy Risk 2 – Organizational Collection of Device Data May Subject Employees to Feeling or Being Surveilled

Summary: The user may experience surveillance from the organization collecting device application and location data.

Test Activity: Disable location tracking and verify that applications outside of the organizationally controlled portions of the phone are not inventoried by the EMM.

Desired Outcome: Collection of application and location data is restricted by the EMM. The EMM does not collect an inventory of personal applications on the device and does not collect location information, including physical address, geographic coordinates and history, internet protocol (IP) address, and service set identifier (SSID).

Observed Outcome: When inspecting a device, location and application inventory information are not collected by an EMM, and application inventory information is not transmitted to Kryptowire. Collection of the installed personal apps is restricted by OS-level controls.

Figure D‑24 shows inventory information for installed applications. When privacy restrictions are configured, only corporate application inventory information is collected. No personal applications are found in the EMM’s installed applications list.

Figure D‑24 Application Inventory Information

Figure D‑25 shows that privacy settings have been enabled to restrict collection of location information.

Figure D‑25 Location Information Restricted

Additional Potential Mitigations:

• Restrict staff access to system capabilities that permit reviewing data about employees and their devices.

• Limit or disable collection of specific data elements.

• Dispose of personally identifiable information (PII).

D.12 Privacy Risk 3 – Data Collection and Transmission Between Integrated Security Products May Expose Employee Data

Summary: Access to monitoring data from the device is not restricted to administrators. Application and location data are shared with third parties that support monitoring, data analytics, and other functions for operating the BYOD solution.

Test Activity: Attempt to log in to the MaaS360 admin portal without domain administrator permissions.

Desired Outcome: System provides access controls to monitoring functions and logs. Data flow between the organization and third parties does not contain location information, including physical address, geographic coordinates and history, IP address, and SSID.

Observed Outcome: Domain administrators were allowed to log in, but non-administrator users were not.

Figure D‑26 demonstrates how a non-administrator account will be prevented from logging into the MaaS360 portal.

Figure D‑26 Non-Administrator Failed Portal Login

Figure D‑27 Admin Login Settings

Figure D‑28 Administrator Levels

Potential Mitigations:

• De-identify personal and device data when such data is not necessary to meet processing objectives.

• Encrypt data transmitted between parties.

• Limit or disable access to data.

• Limit or disable collection of specific data elements.

• Use policy controls such as contracts to limit third-party data processing.

D.13 Privacy Risk 4 – Employees Might Feel Compelled to Participate in Data Processing Practices Inconsistent with Expectations

Summary: Users may not have knowledge of what information is collected and monitored by the organization.

Test Activity: Test to ensure that MDM provides custom notification to users detailing collected device information.

Desired Outcome: MDM provides details of what information is collected during device enrollment.

Observed Outcome: Device data collection information is displayed to users.

Figure D-29 demonstrates how users will be notified of what device information is collected by mobile security products during the device enrollment process.

Figure D‑29 Mobile Device Information Collection Notification

Additional Potential Mitigations:

• Provide notification to the user.

• Train users on mobile-device collection policy.

• Provide a point of contact for user questions regarding organizational data collection and use policies.

• Train system administrators regarding the privacy requirements for operating the BYOD systems.

D.14 Privacy Risk 5 – Unauthorized or Invasive Application Processing of Information Exposes Employee Data

Summary: The employee or organization installs third-party applications that access data on the device without fully understanding the nature of the applications data processing practices, creating opportunities for invasive or malicious activity or installation of malware. An application may over-collect information or conduct analysis that may result in embarrassment to the employee or create opportunities for surveillance that extend beyond the level of monitoring needed for an organization.

Test Activity: Log in to an Application Vetting solution to automatically analyze all new applications installed on enrolled devices, then run the reports to see threat details.

The administrator configures a threat score alert threshold and an email address to receive alerts when an application’s threat score is at or above the threshold.

Desired Outcome: After application analysis the risk posture of the devices, and therefore, the enterprise stays at an acceptable level. If the work application did not pass the App Vetting process it should not be used by the enterprise.

Observed Outcome: App vetting solution recognized that the application exceeded the configured security threshold and over-collected personal information. The application’s collection of contacts, calendars and device sensors could introduce vulnerabilities. Figure D‑30 through Figure D-32 demonstrate the app vetting findings.

Figure D‑30 Mobile Device Information Collection Notification

Figure D‑31 Privacy and Information Access of the Application

Figure D‑32 Application Analysis

Additional Potential Mitigations:

• EMM leverages OS related separation between enterprise and personal data.

• Train users on safe practices for downloading files and installing applications of their devices.

• Scan downloaded applications for malware.

• Institute procedures for conducting a privacy risk assessment for applications installed by the organization.