Mobile First Government

Transcription

1 Mobile First Government An analysis of NIST and DISA requirements for the adoption of commercially available mobility platforms by government agencies August East Middlefield Road Mountain View, CA USA Tel Fax

2 Table of Contents Overview... 3 Risk Assessment... 4 Lack of physical security controls... 4 Use of untrusted mobile devices... 4 Use of untrusted networks... 4 Use of applications... 5 Interaction with other systems... 5 Use of untrusted content... 5 Use of location services... 5 Mobile Device Management Capabilities NIST Guidelines... 6 Category I: General policy... 6 Category II: Data communication and storage... 6 Category III: User and device authentication... 6 Category IV: Applications... 6 Detailed Mobile Device Management Requirements DISA SRG... 7 Category I: General policy... 7 Category II: Data communication and storage... 9 Category III: User and device authentication...11 Category IV: Applications...12 Additional Capabilities of the MobileIron Platform...13 Access control...13 Data loss prevention (DLP) and application containerization...14 Identity...14 Secure tunneling...14 Geographic security and expense...14 Secure content...14 MobileIron Layered Security Model...15 Summary

3 Mobile First Government The new generation of commercially available mobility platforms can provide extensive application development capabilities and strong user experiences at reasonable cost. This white paper outlines the security requirements that must be met for these platforms to be adopted by government agencies. It also details how the MobileIron solution can help meet these requirements. We recommend reading the following resources for more details on requirements: DISA SRGs and STIGs for ios, Android, and device management: NIST Guidelines for mobile device security: This white paper outlines the security requirements for commercially available mobility platforms to be adopted by government agencies. Overview The National Institute for Standards and Technology (NIST), the Defense Information Systems Agency (DISA), and the General Services Administration (GSA) have been leading efforts to define requirements for enterprise mobility systems such as Mobile Device Management (MDM) and Mobile Application Management (MAM) for use in government agencies. Mobile devices, especially smartphones, are vulnerable to security breaches. They: Are easily lost Can be filled with unknown applications Frequently communicate over untrusted networks Are often purchased by users without consideration of IT standards and security requirements Mobile Device Management (MDM) systems can help mitigate these vulnerabilities. But managing mobile devices and data is a complex topic that requires an understanding of compliance policy, application vulnerabilities, trusted communications, secure storage, device authentication, remediation, and auditing. Managing mobile devices and data is a complex topic that requires an understanding of compliance policy, application vulnerabilities, trusted communication, secure storage, device authentication, remediation, and auditing. This white paper describes the NIST and DISA requirements for Mobile Device Management (MDM). It: Reviews the special risks of managing mobile devices from the NIST report Guidelines for Managing the Security of Mobile Devices in the Enterprise (NIST Special Publication Revision 1) available at Outlines the high-level capabilities that should be provided by MDM systems, as listed in the same document Reviews a selection of the detailed MDM requirements from the DISA report Mobile Device Management (MDM) Server Security Requirements Guide (SRG), Version 1, Release 1 (18 January 2013) available at Describes how MobileIron s leading enterprise mobility management platform can help government organizations address these requirements 3

4 Risk Assessment NIST provides a comprehensive overview of the risks associated with mobile devices in section 2.2 on pages 3-6 of NIST Special Publication Revision 1, Guidelines for Managing the Security of Mobile Devices in the Enterprise. This section, titled High-Level Threats and Vulnerabilities, also highlights mitigation strategies. The table below summarizes the contents of that section. Table 1: Vulnerabilities and Mitigation Strategies from NIST SP Revision 1 Vulnerability The devices mobile nature makes them much more likely to be lost or stolen than other devices [O]rganizations should assume that mobile devices will be acquired by malicious parties who will attempt to recover sensitive data either directly from the devices themselves or indirectly by using the devices to access the organization s remote resources. Lack of physical security controls Mitigation Strategy Encrypt data stored on the device. Authenticate users attempting to access the device or resources accessible through the device. The National Institute for Standards and Technology (NIST) has published a comprehensive overview of the vulnerabilities and mitigation strategies associated with mobile devices: NIST Special Publication Revision 1 Guidelines for Managing and Securing Mobile Devices in the Enterprise. Use of untrusted mobile devices Many mobile devices, particularly those that are personally owned (bring your own device, BYOD), are not necessarily trustworthy. Current mobile devices lack the root of trust features (e.g., TPMs)...There is also frequent jailbreaking and rooting of mobile devices, which means that the built-in restrictions on security, operating system use, etc. have been bypassed Restrict or prohibit BYOD devices. Fully secure each organizationissued phone before allowing it to be used. Employ technical solutions for achieving degrees of trust, such as running the organization s software in a secure, isolated sandbox on the phone, or using device integrity scanning applications. Use of untrusted networks Communications systems such as Wi-Fi and cellular networks are susceptible to eavesdropping, which places sensitive information transmitted at risk of compromise. Man-in-the-middle attacks may also be performed to intercept and modify communications... Encrypt communications. Establish mutual authentication to verify the identities of endpoints. 4

5 Use of applications Mobile devices are designed to make it easy to find, acquire, install, and use third-party applications Organizations should plan their mobile device security on the assumption that unknown thirdparty mobile device applications downloadable by users should not be trusted. Mobile devices may interact with other systems in terms of data synchronization and storage [such as] connecting a mobile device to a desktop or laptop [or] automatic backups of data to a cloud-based storage solution [T]he organization s data is at risk of being stored in an unsecured location outside the organization s control; transmission of malware from device to device is also a possibility. Interaction with other systems Prohibit installation of 3 rd -party apps. Implement whitelisting to prohibit installation of unapproved apps. Implement a secure sandbox to isolate government data and apps from all other data and apps. Prohibit or restrict browser access, or use a secure sandboxed browser. Apply policy controls for app-tocontent interaction, e.g., an openin or copy-paste policy. Mitigation Strategy (above) for Use of Applications also applies to this Vulnerability category. NIST outlines seven risks: Lack of physical security controls Use of untrusted mobile devices Use of untrusted networks Use of applications Interaction with other systems Use of untrusted content Use of location services Use of untrusted content Mobile devices may use untrusted content that other types of devices generally do not encounter. An example is Quick Response (QR) codes [M]alicious QR codes could direct mobile devices to malicious websites Educate users on the risks inherent in untrusted content. Restrict use of peripherals, such as disabling camera use in order to prevent QR code processing. Apply policy controls for app-tocontent interaction, e.g., an openin or copy-paste policy. Use of location services [M]obile devices with location services enabled are at increased risk of targeted attacks because it is easier for potential attackers to determine where the user and the mobile device are, and to correlate that information with other sources about who the user associates with and the kinds of activities they perform in particular locations. Disable location services. Prohibit use of location services for particular applications such as social networking or photo applications. 5

6 Mobile Device Management Capabilities NIST Guidelines The NIST Guidelines document also summarizes some of the capabilities that should be provided by an MDM system. Many of these are similar to the capabilities expected in systems management products for laptops and desktops, but there are a few areas where the requirements for managing mobile devices are significantly different, notably those related to controlling the download and use of apps. Below is a summary of key capabilities. Please consult pages 8-9 of the Guidelines document for more details. Category I: General policy An MDM system needs to manage security policies centrally. This includes: Restricting the use of hardware features like camera, GPS, Bluetooth and media interfaces Restricting the use of software features such as web browsers, clients, and app installation services Managing Wi-Fi and Bluetooth wireless interfaces Mobile management capability requirements can differ significantly from those for traditional laptop and desktop management, especially those related to controlling the download and use of apps. Policy management also includes monitoring and reporting on policy violations. Category II: Data communication and storage An MDM system should enforce the strong encryption of communications between the mobile devices and the organization, as well as the strong encryption of data stored on both built-in and removable storage on the mobile device. Category III: User and device authentication An MDM system should control authentication, including: Requiring passwords and other forms of authentication Setting parameters for password strength and incorrect password retries Allowing administrators to reset access remotely NIST outlines four sets of MDM capability requirements: General policy Data communication and storage User and device authentication Applications An MDM system should be able to lock devices, including: Automatically after a specified idle period Manually if devices are left in unsecure locations An MDM system should be able to wipe devices, including: When device is lost or stolen After a number of incorrect authentication attempts Category IV: Applications An MDM system should be able to control applications on devices through whitelisting and blacklisting, as well as remote installation, update, and removal. 6

7 An MDM system should be able to distribute applications securely from a dedicated app store. An MDM system should be able to prevent devices from Synchronizing with local or cloud-based systems. Accessing the enterprise network if the device has been rooted or jailbroken Accessing the enterprise network if the device has the wrong version of the MDM client Detailed Mobile Device Management Requirements DISA SRG The NIST Guidelines for Managing the Security of Mobile Devices in the Enterprise document provides very useful high-level descriptions of capabilities that should be provided by an MDM system. More detailed requirements exist in a document created by the Defense Information Systems Agency (DISA) for the U.S. Department of Defense. That document is called Mobile Device Management (MDM) Server Security Requirements Guide (SRG), Version 1, Release 1 and contains almost 300 potential rules that could be applied to MDM systems used in defense organizations. The Defense Information Systems Agency (DISA) has published a detailed requirements document called Mobile Device Management (MDM) Server Security Requirements Guide (SRG), Version 1, Release 1. It is important to note that this SRG represents a list of possible requirements submitted by agencies, vendors, contributors to standards organizations, and other entities. No single MDM product could implement all of the features suggested in the foreseeable future. However, over time, this list will be consolidated and refined, and even in its current state it provides a valuable trove of ideas for what MDM systems could provide. Below we have grouped a subset of the MDM SRG requirements into the same four categories of requirements outlined in the NIST Guidelines document discussed earlier. This is not the sequence in which they appear in the SRG, but it makes them easier to absorb and compare. Each section also describes how the MobileIron solution helps address the requirements. Category I: General policy Requirements from the MDM SRG The MDM server must have the administrative functionality to centrally manage configuration settings, including security policies, on managed mobile devices. Rule ID: SRG-APP MDM MDM_rule The MDM server must have the administrative functionality to centrally manage the following security policy rules on managed mobile devices: Enable or disable Bluetooth SRG-APP MDM MDM_rule Enable or disable Wi-Fi SRG-APP MDM MDM_rule 7

8 Enable or disable the GPS receiver SRG-APP MDM MDM_rule Enable or disable all cameras SRG-APP MDM MDM_rule Enable or disable the USB port mass storage mode SRG-APP MDM MDM_rule Enable or disable Wi-Fi tethering. SRG-APP MDM MDM_rule The MDM server must notify when it detects unauthorized changes to the security configuration of managed mobile devices. SRG-APP MDM MDM_rule The MDM server must detect if the security policy has been modified, disabled, or bypassed on managed mobile devices. SRG-APP MDM MDM_rule The MDM server must support the capability to deploy operating system and application updates via over-the-air (OTA) provisioning for managed mobile devices. SRG-APP MDM MAM_rule Central management of a broad set of mobile configuration settings and security policies with full auditability is a core element of the DISA SRG. The MDM server must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format. SRG-APP MDM SRV_rule The MDM server must record an event in audit log each time the server makes a security relevant configuration change on a managed mobile device. SRG-APP MDM SRV_rule How MobileIron can help address these requirements Management of configuration settings and security policies The MobileIron MDM platform makes it easy for administrators to enable or disable hardware and software features, including: Cameras USB connections Bluetooth Wi-Fi tethering Data networks (such as Wi-Fi) GPS for location detection Native web browsers clients MobileIron supports a broad set of configuration settings and security policies to give administrators the flexibility and granularity to design and deploy policies that match the security requirements of a particular population of users or devices. The administrator can choose between enabling, disabling, and letting users decide whether to enable many of these features. Many OS-specific features can also be controlled, e.g., blocking Siri and icloud backup on Apple ios devices and blocking devices that are out of compliance. MobileIron features a rule-based compliance engine that lets IT administrators easily define and implement compliance rules for smartphones and tablets to deal with specific events and contextual changes. Managed devices are continuously 8

9 monitored for violations of defined rules or events. Policies and events that can be monitored include minimum operating system version, encryption enforcement, application whitelists and blacklists, SIM change, roaming state change, and jailbreak / rooting of the device. If a policy violation occurs, MobileIron can take action by: Alerting the user and administrator Blocking access to corporate , apps, and intranet Blocking connections using Wi-Fi and VPN Wiping the device s memory to factory default settings Actions can also be automated to enforce closed-loop compliance. OTA provisioning and updating MobileIron provides the ability to provision and update mobile devices and software over-the-air (OTA): Monitor operating system versions to ensure the most recent has been installed and quarantine device if it has not. Push Wi-Fi, VPN, and configurations for secure connectivity. Distribute required apps, e.g., anti-malware software, and their updates through a secure internal app store. Provide secure access to content like documents and spreadsheets. MobileIron also provides flexible provisioning procedures so that mobile devices can be provisioned: Directly by the administrator By an authorized user after the administrator sends an enrollment request through or SMS Directly by an authorized user through a self-service portal MobileIron s rule-based compliance engine automates notification and data protection responses to specific events and contextual changes in the mobile environment. MobileIron s provisioning process can be driven endto-end by the administrator or provided through a selfservice portal to the end user. Audit Trails MobileIron creates a centralized audit trail of all operational and security events on each mobile device. Administrators can analyze the log data to track configuration changes, as well as events that may indicate an attack or security violation. Category II: Data communication and storage Requirements from the MDM SRG The MDM server must use cryptography to protect the integrity of remote access sessions with managed mobile devices. SRG-APP MDM MDM_rule The cryptographic module supporting encryption of data in transit (including and attachments) must be FIPS validated. SRG-APP MDM MDM_rule 9

10 The MDM server must encrypt all data in transit (e.g., mobile device encryption keys, server PKI certificates, mobile device data bases) using AES encryption. AES 128-bit encryption key length is the minimum requirement with AES 256 desired. SRG-APP MDM SRV_rule The MDM server must employ automated mechanisms to facilitate the monitoring and control of remote access methods. SRG-APP MDM SRV_rule The MDM server must provide the administrative functionality to transmit a remote Data Wipe command to a managed mobile device. SRG-APP MDM MDM_rule The MDM server must have the administrative functionality to perform a Data Wipe function whereby all data stored in user addressable memory on the mobile device and the removable memory card is erased when the maximum number of incorrect passwords for device unlock has been reached. SRG-APP MDM MDM_rule Appropriate cryptography and mechanisms to control remote access and data wipe are core elements of the DISA SRG. How MobileIron can help address these requirements Encryption MobileIron allows administrators to require that data stored on devices be encrypted. In addition, all information communicated between mobile devices and MobileIron is transmitted over the TLS 1.2 protocol, using FIPS compliant encryption modules. Monitoring remote access methods MobileIron can also monitor and control remote access methods through: Providing app-specific secure tunneling Distributing VPN (Virtual Private Network) profiles Enforcing the use of VPNs for remote communications Tracking the use of roaming data networks Allowing or disallowing the use of Wi-Fi connections Securing VPN and Wi-Fi connections with certificates MobileIron protects data-atrest and data-in-motion, including selective wipe of work data and applications. Wiping devices MobileIron allows administrators to perform both full and selective data wipes. The former removes all data from the device, and the latter removes just work data and applications, leaving behind the user s personal data and applications. MobileIron can protect users from unnecessary wipes by sending messages warning that a wipe will be performed after a grace period if the user does not take action to bring the device back into compliance. MobileIron sets password policies to ensure that the device is wiped after a predefined number of incorrect password attempts by the user. 10

11 Category III: User and device authentication Requirements from the MDM SRG The MDM server must uniquely identify mobile devices managed by the server prior to connecting to the device. SRG-APP MDM MDM_rule The MDM server must disable network access by unauthorized server components or notify designated organizational officials. SRG-APP MDM SRV_rule The MDM server must provide mutual authentication between the MDM server and the provisioned device during a trusted over-the-air (OTA) provisioning session. SRG-APP MDM MDM_rule The MDM server must have the capability to enable and disable a managed mobile device. SRG-APP MDM MDM_rule The MDM server must have the administrative functionality to centrally manage the following security policy rules on managed mobile devices: Enable or disable device unlock password. SRG-APP MDM MDM_rule Set maximum password age (e.g., 30 days, 90 days, 180 days). SRG-APP MDM MDM_rule Set the number of incorrect password attempts before a data wipe procedure is initiated (minimum requirement is 3-10). SRG-APP MDM MDM_rule How MobileIron can help address these requirements Access control MobileIron can block unauthorized devices from accessing the enterprise network. It also has the ability to quarantine unknown devices; that is, to block the devices from the enterprise network until an administrator can review them and make a decision about whether to provide access. Identity management plus remediation or protective actions when authentication fails are core elements of the DISA SRG. Access control through MobileIron blocks network access for unauthorized devices and provides full visibility into which devices are attempting to connect to the network. Network access for managed devices can be either disabled automatically when a compliance rule is broken or disabled manually by the administrator when the device has been lost or stolen. Access to enterprise data on the device can also be similarity restricted in situations of non-compliance or loss. Authenticating devices to the server MobileIron uses digital certificates to authenticate mobile devices to the MobileIron server. For example, Apple ios devices use the Simple Certificate Enrollment Protocol (SCEP) to generate a certificate enrollment request for the MobileIron Certificate Authority (CA), which sends the device an identity certificate. MobileIron also integrates with existing enterprise certificate authorities so agencies can leverage current infrastructure investments. For Android devices, the MobileIron 11

12 platform sends encrypted configuration information over the air. MobileIron holds the patent for Management of Certificates for Mobile Devices (granted July 23, 2013 U.S. Patent Number 8,494,485). Managing passwords MobileIron allows administrators to control password policies on mobile devices. This includes many password rules, such as: Complexity of password Minimum password length Maximum allowable age for password Idle time allowed before the device is locked and needs to be opened again with a password Number of failed login attempts that are allowed before data on the device is wiped Note that device-level password capabilities can vary across mobile operating systems because of the differing capabilities of those underlying systems, so the administrator must be aware of these variances when defining the password policy appropriate to his or her organization. MobileIron uses digital certificates to authenticate devices and holds the U.S. patent for Management of Certificates for Mobile Devices. Category IV: Applications Requirements from the MDM SRG The MDM server must detect and report the version of the operating system, device drivers, and application software for managed mobile devices. SRG-APP MDM MDM_rule The MDM server must support organizational requirements to install software updates automatically on managed mobile devices. SRG-APP MDM MAM_rule The MDM server device integrity validation component must use automated mechanisms to alert security personnel when the device has been jailbroken or rooted. SRG-APP MDM MDIS_rule As applications have become more and more important for realizing the full value of mobile government, the ability to both deliver and secure mobile applications on authorized devices has become a core element of the DISA SRG. The MDM server must have the administrative functionality to centrally manage the following security policy rules on managed mobile devices: Enable or disable the mobile device user s access to an application store or repository. SRG-APP MDM MDM_rule Prohibit the mobile device user from installing unapproved applications. SRG-APP MDM MDM_rule Prohibit the download of software from a DoD non-approved source. SRG- APP MDM MDM_rule Specify a list of approved applications that must be installed on the mobile device and cannot be removed by the user. SRG-APP MDM MDM_rule 12

13 How MobileIron can help address these requirements Hardware and software inventory MobileIron provides a complete hardware and software inventory of devices, including reports for each device about the processor, RAM, storage, battery level, operating system version, firmware, and apps installed. Device compliance Security-related information in the same reports includes which devices have been jailbroken or rooted, which devices are in or out of compliance, and the most recent wipe dates for devices. Security personnel are automatically notified and remediation steps are automatically triggered if any device falls out of compliance. Application distribution and control MobileIron provides security across the lifecycle of mobile applications and holds the U.S. patent for Management of Mobile Applications. MobileIron provides a secure app store that allows users to download authorized apps from an app catalog customized for each user based on group, operational unit, or individual authorization. MobileIron holds the patent for Management of Mobile Applications (granted January 22, 2013 U.S. Patent Number 8,359,016) Authorized applications can include in-house applications specific to the organization or third-party applications available in Apple s App Store, Google Play, or Windows Marketplace. MobileIron can also restrict access to these public app stores. MobileIron notifies the user when application updates are available for download. MobileIron lets administrators set up application control policies: Whitelists representing what applications are authorized for installation Blacklists representing what applications are not authorized for installation Required lists representing what applications must be installed at all times If a user installs or removes an application that breaks these any of these policies, MobileIron s automated compliance and remediation actions are triggered. Government employees are increasingly utilizing thirdparty applications available in public app stores, and so the ability to set appropriate app control rules in MobileIron is broadly utilized. Additional Capabilities of the MobileIron Platform Access control When a device or user falls out of compliance, access to enterprise resources is throttled until the issue is remediated. Policy-based access control over the flow of enterprise , application, document, and web traffic puts the burden of compliance on the shoulders of the user. If the user takes an action that is noncompliant, enterprise access is limited or revoked. As a result, enterprise data is protected no matter what action the user takes. 13

14 Data loss prevention (DLP) and application containerization Containerization is the mechanism to ensure that data associated with an application is protected against unauthorized access and distribution. This includes locally cached data from , web sites, file sharing systems, and mobile apps. IT must have the ability to enforce authentication, encryption, and selective wiping of this data and control the potential vectors of data loss. MobileIron provides containerization with these capabilities across these data types and the corresponding mobile data loss prevention (DLP) controls. Identity The identities of the user and device determine the enterprise services available to that user on that device. The majority of MobileIron customers use digital certificates for identity because they improve the end-user experience while providing IT with both high security and an easy way to revoke access. Back-end integration with directory services like AD/LDAP provides the authentication credentials. Containerization is the mechanism to ensure that data associated with an application is protected against unauthorized access and distribution. Secure tunneling Almost every mobile device will connect through untrusted networks at some point when accessing enterprise data. Secure tunneling, with the right level of authentication to prevent man-in-the-middle attacks, must be part of every mobile deployment. The two options are device-wide VPN or app-specific tunneling. The former leverages existing infrastructure but costs money and can be turned off by the user. The latter secures data-in-motion without any action required from the user and provides more granular controls. MobileIron supports both models. Geographic security and expense Many agencies have employees with sensitive information that travel internationally. MobileIron monitors country and network for each managed device and notifies the administrator when a device enters a new country. This allows the administrator to wipe the device if the country is unauthorized so that sensitive data isn t at risk of being accessed by foreign governments. This geographic knowledge also allows the administrator to ensure the device is on the appropriate international roaming plan so that there aren t unexpected charges incurred as a result of the trip. International roaming charges can be a major cost to organizations whose employees travel. MobileIron notifies the administrator when a device leaves the country and can also notify the user of roaming policies and expected behaviors. Secure content The identities of user and device determine the services available to that user on that device. Application-specific tunneling as an alternative to device-wide VPN has attracted the interest of many agencies, especially for BYOD programs. After , secure access to documents is the first mobile requirement of many agencies. Many agency employees require mobile access to government documents. These documents might exist in repositories such as SharePoint or as attachments. In either case, mobile access drives productivity but the document has to be made available without putting it at risk of loss or compromise. 14

15 MobileIron provides three levels of content security Secure access from the mobile device to back-end content repositories like SharePoint Encryption of attachments so that unauthorized mobile apps cannot read them Secure content hub on the mobile device to store and protect sensitive documents MobileIron Layered Security Model MobileIron has a broad security model that addresses the requirements listed in this document. This model provides layered controls for data loss prevention (DLP) that reinforce each other to protect data without damaging the user experience. The MobileIron Layered Security Model provides layered controls for data loss prevention (DLP) that reinforce each other to protect data without damaging the user experience. 15

16 Summary Mobile Device Management (MDM) is a complex subject. But the NIST Guidelines document and the DISA SRG, although still evolving, are already valuable resources for coming up to speed on potential requirements for MDM systems. The requirements can be grouped into four categories: 1. General policy 2. Data communication and storage 3. User and device authentication 4. Applications An advanced MDM platform can address many of these requirements. General policy Set security policies and push them to devices. Enable or disable hardware and software features like camera, connectivity, and cloud storage. Detect modifications to security parameters on devices and block devices that are out of compliance from accessing the enterprise network. Provision and update devices over-the-air (OTA). Collect and compile audit trails from thousands of mobile devices. Identify jailbroken, rooted, and out-of-compliance devices and prevent them from accessing the enterprise network. Take automated notification, block, and wipe actions to enforce closed-loop compliance. While Mobile Device Management is a complex subject, the NIST Guidelines and DISA SRG provide a valuable resource for evolving requirements. Data communication and storage Enforce the encryption of data at rest and data in motion. Monitor and secure remote access methods. Wipe devices that are lost and stolen to remove all enterprise data. Support both full wipe and selective wipe methods. User and device authentication Block unauthorized devices from accessing government networks. Quarantine unknown and non-compliant devices. Authenticate devices to the server using digital certificates. Manage passwords and password policies. Applications Collect and compile hardware and software inventory information. Provide secure internal app store for users to download authorized applications. Provide integration with public and private app stores. Manage and enforce application whitelists and blacklists. Trigger auto-compliance actions if unauthorized applications installed. Enforce installation of required applications. Enforce operating system versioning. Update apps over the air. 16

17 Additional requirements Establish policy-based access control. Containerize all locally cached data. Tightly integrate with identity services. Proved app-level secure tunneling. Monitor usage to control cost. Enforce geographic security. Distribute and secure documents and files. Provide detailed metrics and reporting. The central NIST and DISA MDM documents can be found at: NIST Special Publication Revision 1, Guidelines for Managing the Security of Mobile Devices in the Enterprise (see Section 2.2) is available at DISA Mobile Device Management (MDM) Server Security Requirements Guide (SRG) Version 1, Release 1, 18 January 2013, with an overview memo, is available at The full SRG is available within this zip file as an XML document. 17