SYS.3.2.2 Mobile Device Management (MDM)
Smartphones, tablets, and phablets are an indispensable part of many employees' work. IT Operations must provide more and more such devices in many different configurations while simultaneously...
Description
Introduction
Smartphones, tablets, and phablets are an indispensable part of many employees’ work. IT Operations must provide more and more such devices in many different configurations while simultaneously ensuring adequate security. In addition, mobile end devices are exposed to special risks and their administration differs in fundamental ways from other IT systems.
This is why a Mobile Device Management (MDM) is indispensable in institutions with a larger number of smartphones, tablets, and phablets for the regulated and secure operation of these devices. With appropriate MDM software, end devices can be managed centrally, security rules can be enforced, and emergency actions can be triggered. An MDM thus ensures an equal or at least comparable security standard on all devices.
Objective
The objective of this building block is to demonstrate how mobile end devices can be used securely by institutions using an MDM. It also provides guidance on operating an MDM.
Scope and Modeling
The building block SYS.3.2.2 Mobile Device Management (MDM) must be used for the information domain when mobile end devices are managed using a Mobile Device Management (MDM).
Mobile end devices in the sense of this building block are smartphones, tablets, and phablets on which mobile operating systems such as Android or iOS are installed. The security requirements of smartphones, tablets, notebooks, and tablets with desktop operating systems are described in other building blocks of the SYS IT Systems layer. The requirements from SYS.3.2.1 General Smartphones and Tablets must also be taken into account when an MDM is used. How smartphones, tablets, and phablets are specifically secured is additionally described in detail in the building blocks for the respective operating systems, e.g., in SYS.3.2.3 iOS (for Enterprise)) or SYS.3.2.4 Android.
An authorization concept must be created for the MDM. Requirements for this are provided by the building block ORP.4 Identity and Authorization Management. One of the core tasks of an MDM is the administration of mobile end devices. Security requirements for administration are contained in the building block OPS.1.1.2 Proper IT Administration.
Aspects of “Bring Your Own Device” (BYOD) are not addressed in this building block.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block SYS.3.2.2 Mobile Device Management (MDM):
Insufficient Synchronization with the MDM
For the MDM to be able to enforce the rules defined by those responsible on the mobile end devices, the devices must be regularly synchronized with the MDM. If a device is not connected to the MDM for an extended period, for example, new or updated rules cannot be applied. Also, if no connection exists to a lost device, the data can no longer be remotely deleted.
Erroneous Administration of the MDM
MDM solutions are complex applications typically with several hundred different rules. Not all rules are compatible with each other and conversely many rules depend on each other. Errors in administration can expose both the MDM and the end devices to various risks that directly or indirectly affect the confidentiality, availability, or integrity of the data and applications.
Inappropriate Rights Management in the MDM
The rights management of the MDM determines which users are permitted to make which settings on the mobile devices and who is permitted to access which data. If users are assigned an incorrect role, there is a risk that they are granted excessively high rights. They could, for example, view data without authorization or change device settings. It would also be possible for them to install and use apps that are not permitted in the institution, for example for using cloud storage services. As a result, sensitive data can flow out of the institution or statutory data protection provisions can be violated.
Unauthorized Creation of Movement Profiles via the MDM
Most MDM products allow determining where a device is currently located, and data or apps can be enabled or disabled depending on location (so-called “geofencing”). This creates detailed movement profiles of the devices and thus also of users. If this data is collected without informing users appropriately, those responsible may under certain circumstances violate data protection regulations. There is also the risk that in the event of an attack this data could reach unauthorized parties. Geofencing can also be misused to impermissibly monitor employees.
Requirements
The following are the specific requirements of the building block SYS.3.2.2 Mobile Device Management (MDM). The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.
Additional roles are defined in the IT-Grundschutz Compendium. These should be filled insofar as this is sensible and appropriate.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | IT Operations |
| Additional responsibilities | None |
Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many people should fill these roles.
Basic Requirements
The following requirements MUST be met with priority for this building block.
SYS.3.2.2.A1 Defining a Strategy for Mobile Device Management (B)
A strategy MUST be developed that determines how employees may use mobile end devices and how the devices are integrated into the institution’s IT structures. The protection needs of the information to be processed MUST form the basis. The strategy MUST cover at a minimum the following aspects:
- May the MDM be operated as a cloud service?
- Should the MDM be operated by the institution itself?
- Should the MDM provide all apps, or may users install apps themselves? What restrictions does the institution impose on provided or self-installed apps?
- Should the MDM be integrated into a broader infrastructure?
- What requirements regarding support services and response times are to be placed on the institution providing the MDM?
- What compliance requirements must be enforced?
- Which mobile devices and which operating systems must the MDM support?
- Must the MDM solution be multi-tenant capable? Does it guarantee the necessary tenant separation?
- Must cloud services be integrated?
- Must document management systems be integrated?
- Must the MDM also integrate and manage peripheral devices?
- Which operating model is to be used: private end devices (Bring Your Own Device, BYOD), personalized end devices (institution’s property), or non-personalized end devices (institution’s property, shared)?
The strategy MUST be set down in writing and approved by the ISO.
SYS.3.2.2.A2 Defining Permitted Mobile End Devices (B)
It MUST be determined which mobile end devices and operating systems are permitted in the institution. All permitted devices and operating systems MUST meet the requirements of the MDM strategy and fully satisfy the institution’s technical security requirements. The MDM MUST be configured so that only approved devices can access the institution’s information. Only mobile end devices approved by the institution MAY be procured.
SYS.3.2.2.A3 Selection of an MDM Product (B)
When appropriate MDM software is to be procured, it MUST be ensured that all requirements defined in the MDM strategy can be met with it. It MUST also be able to implement all technical and organizational security measures and support all permitted mobile end devices.
SYS.3.2.2.A4 Distribution of the Basic Configuration to Mobile End Devices (B)
All mobile end devices MUST be integrated into the MDM before they are used. When devices receive the basic configuration, they MUST be in factory state. The connection of mobile end devices to the MDM MUST be adequately secured. For already used devices, all institution-related data MUST first be deleted. An end device not configured via MDM MUST NOT be able to access the institution’s information.
SYS.3.2.2.A5 Installation of the MDM Client (B)
When mobile end devices are handed over to employees, the MDM client MUST be installed and configured on them, unless it is already provided by the operating system.
SYS.3.2.2.A20 Regular Review of the MDM (B)
Security settings MUST be regularly reviewed. For new operating system versions of mobile end devices, it MUST be checked in advance whether the MDM fully supports them and whether the configuration profiles and security settings remain effective and sufficient. Deviations MUST be corrected. The permissions assigned to users and administrators MUST be regularly reviewed to determine whether they remain appropriate (principle of minimum privilege).
Standard Requirements
Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.
SYS.3.2.2.A6 Logging of Device Status (S)
The lifecycle including the configuration history of a mobile end device SHOULD be sufficiently logged and centrally retrievable. When needed, the current status of the managed end devices SHOULD be able to be determined by IT Operations (device audit).
SYS.3.2.2.A7 Installation of Apps (S)
Apps SHOULD be installed, uninstalled, and updated via the MDM in accordance with the requirements of the planned deployment scenario. The MDM SHOULD enforce installation, uninstallation, and updates as soon as a connection to the mobile end device exists. Apps installed via the MDM SHOULD NOT be able to be uninstalled by users. The MDM SHOULD enable a block or allowlist for the installation of apps.
SYS.3.2.2.A8 DISCONTINUED (S)
This requirement has been discontinued.
SYS.3.2.2.A9 DISCONTINUED (S)
This requirement has been discontinued.
SYS.3.2.2.A10 DISCONTINUED (S)
This requirement has been discontinued.
SYS.3.2.2.A11 DISCONTINUED (S)
This requirement has been discontinued.
SYS.3.2.2.A12 Securing the MDM Operating Environment (S)
The MDM itself SHOULD be secured by technical measures to meet the protection needs of the information stored or processed therein. The underlying operating system SHOULD be hardened.
SYS.3.2.2.A21 Management of Certificates (S)
Certificates for the use of services on the mobile end device SHOULD be centrally installed, uninstalled, and updated via the MDM. The installation of untrustworthy and non-verifiable (root) certificates by users SHOULD be prevented by the MDM. The MDM SHOULD support mechanisms to check the validity of certificates.
SYS.3.2.2.A22 Remote Deletion and Decommissioning of End Devices (S)
The MDM SHOULD ensure that all official data on the mobile end device can be deleted remotely (remote wipe when a data connection exists). If external storage is used in the mobile end device, it SHOULD be examined whether these should also be deleted during a remote wipe. This function SHOULD be supported by the MDM.
The process for decommissioning the mobile end device (unenrollment) SHOULD ensure that no sensitive data remains on the mobile end device or connected storage media. This SHOULD apply in particular when the unenrollment is performed remotely.
Requirements for High Protection Needs
The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered when there is a higher need for protection. The concrete definition is made in the context of an individual risk analysis.
SYS.3.2.2.A13 DISCONTINUED (H)
This requirement has been discontinued.
SYS.3.2.2.A14 Use of External Reputation Services for Apps (H)
If the administrators of an institution cannot select the permitted apps themselves and users are permitted to install apps independently on their devices, a so-called reputation service SHOULD be used. The MDM SHOULD then restrict the installation of apps using information from this reputation service at a minimum.
SYS.3.2.2.A15 DISCONTINUED (H)
This requirement has been discontinued.
SYS.3.2.2.A16 DISCONTINUED (H)
This requirement has been discontinued.
SYS.3.2.2.A17 Monitoring the Use of Mobile End Devices (H)
Appropriate criteria SHOULD be defined on the basis of which devices are to be monitored, without violating statutory or internal regulations. In particular, so-called jailbreaks or rooting SHOULD be detected.
SYS.3.2.2.A18 DISCONTINUED (H)
This requirement has been discontinued.
SYS.3.2.2.A19 Use of Geofencing (H)
By storing a geofencing policy, it SHOULD be ensured that devices with sensitive information cannot be used outside a previously defined geographic area. If the geographic area is left, correspondingly classified information or the device SHOULD be completely deleted. Before the device is selectively or completely deleted, the responsible administrators and security management as well as the users SHOULD be informed. Only after an appropriate delay SHOULD the device be selectively or completely deleted. The areas where these additional security measures are necessary SHOULD be identified. Subsequently, the security measures SHOULD be implemented in compliance with statutory and internal regulations.
SYS.3.2.2.A23 Enforcement of Compliance Requirements (H)
Violations of the institution’s regulations or even manipulation of the operating system SHOULD be detected using an appropriate solution. The following actions SHOULD be carried out in the event of suspected violation of regulations or manipulation of the operating system. Corresponding functions SHOULD be provided for this purpose:
- Autonomous sending of warnings,
- autonomous locking of the device,
- deletion of the institution’s confidential information,
- deletion of the complete device,
- preventing access to company apps, and
- preventing access to the institution’s systems and information.
In the event of suspected violation or manipulation, an alarm SHOULD be sent to the responsible administrators and security management in the institution.
Additional Information
Good to Know
The BSI has published the document BSI-CS 052: “Mobile Device Management” in the “BSI Publications on Cyber Security”.
The BSI has published a minimum standard on the topic of MDM: “Minimum Standard of the BSI for Mobile Device Management in accordance with Section 8(1) Sentence 1 BSIG — Version 1.0 of 11.05.2017”. The minimum standards must be implemented by the offices of the federal administration mentioned in Section 8(1) Sentence 1 BSIG.
The National Institute of Standards and Technology (NIST) provides the document “Guidelines for Managing the Security of Mobile Devices in the Enterprise: NIST Special Publication 800-124”, Revision 1, June 2013.