B
SI
p
ub
lic
at
io
ns
o
n
cy
be
r
se
cu
ri
ty
Mobile Device Management
As a consequence of the change of the working environment from stationary to mobile workplaces, the devices used must be mobile as well. It is necessary, and now also pos sible, to access corporate data from practically anywhere. "Mobile data" is not a new phenomenon, but has been used on a day-to-day basis for a long time. The laptop was the first device to make corporate data mobile over a wide area. At first, the devices were used offline, meaning that the data was installed in the company and it could be used in transit. Only with the connection to the corporate intranet did this mobile data become synchronised mobile data. Significant changes have occurred in this regard: Up-to-date documents and figures are now available at any time and place, emails are checked promptly by the user, and appointments are organised online with colleagues and business partners. It is impossible to imagine today's working environment without mobile terminal devices.
With state-of-the-art, simple operating concepts, smartphones and tablet computers with the operating systems iOS from Apple, Android from Google, or Windows Phone
from Microsoft are intended more for the consumer market and less for business ap plications. Therefore, they differ radically from other concepts of mobile terminal devices such as Blackberry, which was designed specifically for use in companies. Never theless, devices with iOS and Android have entered the business environment and are increasingly replacing established solutions. They must be integrated into the business processes and/or the business processes must be adapted to them. IT departments face the challenge of allowing access to the IT infrastructure using the devices, managing these devices in a centralised manner, and simultaneously maintaining the level of se curity in the company. As an means of solving this task, Mobile Device Management solutions (hereinafter referred to as MDM solutions) are offered.
This document contains advice and recommendations for the selection and use of MDM solutions. In many areas, this document was written in a cross-platform manner, but the examples mentioned are geared specifically towards the commonly used mobile operating systems Android and iOS.
However, the recommendations are not intended to repeat the configuration recom mendations for MDM solutions, which are already sufficiently known, especially since the menus of the management consoles normally exhaust the possibilities of the plat form configurations and are self-explanatory. The focus is rather on the central aspects that should be taken into account when selecting and operating an MDM solution. Nev ertheless, some exemplary recommendations for the configuration of iOS- and An droid-based smartphones and tablets will be provided for illustrative purposes at the end of this document.
The recommendations are deliberately kept short and make no claims to completeness. They will be updated and expanded at regular intervals. Therefore, we appreciate any ideas.
1 Change to insecurity
The hardware and system software of the classic mobile devices laptop and notebook is very similar or identical to the software of stationary computers. They also predominantly work with Windows, Mac OS X, or Linux as the operating system. Thus, there practically are no sig nificant differences in the use of these mobile devices. Once connected to the intranet of the company using a secure channel, they can be used to work as usual. Email, contacts, calendar, and access to network services are available, centralised administration, patch and backup management are performed transparently. The fact that the devices are protected by security software just like a desktop computer and that security guidelines can be enforced as usual is also important.
The situation is different for the category of hand-held computers – smartphones and tablets. With regard to equipment and performance capability, these are absolutely capable of pro cessing business processes; however, hardware, system software, and operating concept usu ally differ fundamentally from the "classic" mobile terminal devices laptop and notebook. Here, the diversity of smartphone and tablet computer platforms, with system-related proper ties that must be taken into consideration individually in each case constitutes a problem. Ad ditionally, there are differences within the operating systems. The Android operating system – which has become the leading mobile operating system (as at 2012) – is adapted specifically to the devices developed by the smartphone manufacturers. In so doing, basic functionalities such as the user interface are also subject to changes. Patch management is entirely incumbent upon these OEMs. Delays regarding the delivery of new operating system versions are inevit able, considering that a new version of Android is initially released by Google, then must be adapted to the individual devices by the hardware manufacturer, and is ultimately modified again by the provider (for example, in order to adapt it to the access point that is used to in voice data volumes). In addition, time is required for certification and approval. Delays of as long as six months are not uncommon. New devices are often released more quickly than ex isting devices are updated.
"Bring Your Own Device" (BYOD), meaning the (additional) official use of private smart phones, constantly presents IT departments with new challenges. The devices are not selected by the IT department, but by the user. This is even getting to the point where users accept plat form-related limitations only to be able to work with certain devices.
The location also entails an increased risk. Laptops are also used in insecure environments, but this is significantly easier when using smartphones. They do not require booting, but are ready-to-operate immediately after being switched on. The geometric dimensions allow these devices to be used almost anywhere. In many cases, free access to uncontrollable WLANs is available to the user. If the devices are stolen or lost, all the administrator can do is to lock and/or erase the device remotely (if the device is still available). Therefore, thieves interested in the data stored will prevent this final remote access.
The mostly encapsulated infrastructure of the company must be weakened further for remote administration. This means that it is sometimes necessary to place administration and com munication servers within the DMZ so that it is possible to establish a connection between the intranet and the mobile terminal devices.
2 Mobile Device Management in companies
Protecting the communication, processing data on the device, securely storing the data to the device, separating official and private forms of usage, as well as protecting the devices against malware constitute requirements reliably mastered by IT departments in the field of desktop computers/laptops. However, for mobile terminal devices, potential solutions are often not
implemented and/or potential solutions must first be developed by the operating system manufacturers and third-party providers. This requirement can be met by using Mobile Device Management – primarily with regard to central remote maintenance. Some solutions offer additional functionalities for protecting business-related data on the mobile terminal device which go beyond management functions.
MDM solutions predominantly build upon the four pillars hardware support, software support,
communication and its protection, and security on mobile terminal devices.
Along with the general support of different platforms, hardware support also includes the in tegration of an MDM solution into the respective platform so that the operation of the mobile terminal device is not affected adversely by the solution, for example regarding the battery op erating time. Amongst other things, software support includes the integration of new mobile terminal devices into the administration, the distribution of communication profiles, as well as the support of the IT infrastructure of a company. Protecting the data along the communic ation paths by using encryption at defined access points plays a central role. The same applies to the mobile terminal devices regarding secure configuration, encryption, user restrictions, etc., but also regarding secure removal from the administration.
3 Preparations for the selection of an MDM solution
Before making the decision in favour of a certain MDM solution, it must basically be defined what this solution must provide. Which platforms should be supported? Which corporate data is to be processed on the mobile terminal device? Is it necessary to process corporate docu ments along with the usual PIM data (calendar, contacts, tasks, and notes) and emails? How is this data protected and/or separated from other (private) data processed on the mobile ter minal device? Does the company dispose of proprietary apps that must be managed and does this require a separate app store? Is the use of private smartphones for official purposes al lowed?
Once these questions have been answered and a corresponding test schedule has been drawn up, a pre-selection of MDM solutions should be considered Do not trust the marketing depart ments of the providers. It is not enough to study the product documentation either. Tests and intense engagement with the topic are necessary in order to be able to actually assess the ap propriateness of the advertised functions in practice. Have the provider show reference pro jects and benefit from the experience of these companies.
4 Designs
MDM servers are offered as a pure software licence or as an appliance for use in a company. They either consist of an individual server or of several components and are located in the DMZ – embedded in firewalls. In the DMZ, they form the link between the IT infrastructure of the company and the mobile terminal devices. Moreover, they contain the administration console for configuring, monitoring, logging, and backing up the mobile terminal devices, etc. and may also contain a separate app store.
Additionally, some providers offer fully-fledged MDM solutions as a cloud service on separate servers. This solution is particularly advantageous for small-scale installations with a low number of mobile terminal devices. Such a cloud service may also be used to easily test an MDM solution, provided that it meets all requirements necessary for your own installation. People apprehensive of installing a separate MDM solution and deliberately deciding in favour of a cloud service must understand that all mobile data – business-related data, as well as per sonal data – is hosted on a third-party server. Please find further information on this in the "Data protection" chapter.
5 "Security"
One of the most important issues in the field of Mobile Device Management is the protection of the business-related data on the mobile terminal device. Both iOS- and Android-based devices were originally designed for the consumer market, but now must be integrated into business/official processes. iOS and Android absolutely provide facilities for processing official issues (PIM data, email, etc.), but are furthermore equipped with functionalities intended more for private use, for example the integration of Twitter or Facebook and/or YouTube or
Google+ into the operating system. There are hundreds of thousands of apps in the app stores that can be used to expand the functionalities of any device in any conceivable direction. Unfortunately, security terms are often generalised in the product descriptions of MDM solu tions, meaning that advertised security properties are often only applicable to a subset of the devices supported by a platform. For example, there are solutions which use special program ming interfaces (APIs) of certain manufacturers/OEMs in order to manage and protect An droid-based smartphones. The product presentation does not mention that this mechanism is not applicable to devices of other manufacturers and is only applicable to certain devices of one manufacturer. Likewise, you must understand that the support of different platforms, as well as their administration in a common console does not mean that configurations and dir ectives are implemented identically on all platforms. For example, there are system-related differences between iOS and Android regarding the provision of apps in a separate app store (for this, see chapter "App management").
As a rule, the protection of the data flows on the one side and the protection of the data on the smartphone itself must be differentiated ("data in motion" vs. "data at rest").
Normally, MDM solutions securely control the protection of the communication paths, even if they have to use third-party services for this (see chapter "Third-party services"). Examples in clude the use of secure protocols and certificates, VPN configurations, VPN configurations, WLAN settings, as well as the integration of the MDM servers into the IT infrastructure of the company.
In order to protect the data on the smartphone, normally only the configuration options provided by the smartphone platform may be used, such as encryption, password settings, user restrictions, etc. The threat regarding to corporate data from third-party apps accessing contact data, for example, is only taken into consideration by MDM solutions if the platform provides the corresponding protection mechanisms. Thus, it is not easy to clearly separate the official use of the smartphone from the private use.
The sandbox principle, both for Android and for iOS, protects apps and their data from being accessed by other apps. Building upon this basic protection, some providers added an "app container" to their MDM solution, within which the business-related issues are processed (see chapter "Content management on the smartphone").
6 Data protection
In addition to protecting the data communications between mobile terminal device and MDM server, a company should also understand the repercussions of using such a solution in the field of data protection. The majority of MDM solution providers are not headquartered in Germany or the European Union and operate their servers outside of this zone (in the U.S., for example). As a consequence, these companies are not subject to German or European data pri vacy laws, but are either subject to no data protection laws or data protection laws not recog nised in Europe. Therefore, the European Union concluded the so-called "Safe Harbour" agree ment with the U.S., which regulates the transfer of personal data to servers in the U.S., at least from a legal point of view (Safe Harbour).
Furthermore, we would like to refer specifically to §11 of the Federal Data Protection Act (BDSG) "Collecting, processing, and using personal data on behalf of others". This paragraph says that the contracting authority is still responsible for compliance with the BDSG when personal data is processed by other bodies (for example, when using a cloud solution for MDM) (Federal Data Protection Act).
7 Content management on the smartphone
Another challenge for an MDM solution is the separation of the business-related processes on the device in such a way that they are not influenced or endangered by the other (especially private) use.
For this, the majority of the MDM solutions do not offer any proprietary mechanisms. The native apps are used for processing the official issues. This means the smartphone is used as designed by the operating system platform. Therefore, there is no complete separation between official and private use.
Additionally, there is the so-called container solution. This is a normal smartphone app that is used to process official issues. It contains all PIM data, emails, and documents, as well as the program functions required for processing this data, i.e. email client, calendar, contact man agement, etc. Furthermore, there must also be a browser, since corporate servers may only be accessed using this browser. Outside of this app, the device can be used as usual. This kind of official use often results in user acceptance issues since the smartphone cannot be used with all the options available in the private area when using the official area of the phone. However, this solution provides a basic separation of official and private use.
Another approach to a solution for the processing of official issues on the mobile terminal device is a terminal server session, during which the data is stored and processed on the ter minal server. The mobile device is only used for representation and input, i.e. only text input, screen content, and input gestures are transmitted to/from the mobile device. Corresponding solutions are available both for the iPad and for Android smartphones/tablets. Bottlenecks re garding data transmission may have a negative impact, particularly if the data connection of the smartphone is established using a mobile phone network. Furthermore, the
smartphone's/tablet's display often shows a Windows desktop that is not optimised for display and operation on a touch screen smartphone/tablet. The following is applicable here: Have the provider show reference projects and test the solution comprehensively before introducing such a solution.
Moreover, Android provides different new approaches regarding the use of virtualisation in order to simultaneously operate two operating systems on one smartphone. One approach to a solution is two entire Android versions that are started simultaneously and which you can switch between during operation. Another approach to a solution operates a second operating system as an app within the native operating system. However, there are no empirical values obtained from comprehensive practical usage yet.
Nevertheless, the development of the mobile platforms is progressing. For example, version 4.2 of Android provides multi-user administration for tablets allowing for improved separa tion of different users or usage scenarios. Version 6 of iOS includes the innovative option to configure a global HTTP proxy, for instance, so that the IT department may route internet traffic via a controlled channel.
8 Third-party services
The data connection between the mobile terminal device and the MDM server is either estab lished via a mobile phone provider (via GPRS, EDGE, UMTS, HSDPA, LTE) or via a WLAN con nection. The assigned IP address cannot be foreseen and/or is not available, and so the MDM server cannot contact the device. Accordingly, the connection to the server must be estab lished by the smartphone.
With the so-called Apple Push Notification Service (APNS) and/or Google Cloud Messaging
(GCM), the manufacturers offer services that can nevertheless be used to contact the iOS and/or Android devices. These services are integrated into the operating system and cannot be switched off. If an MDM server wants to establish communication with a client, it sends a mes sage containing the communication request via APNS and/or GCM to the smartphone so that it establishes a connection to its MDM server. Without these services, the smartphone would have to provide the server with periodic requests in order to retrieve its status.
There are a wealth of apps which can receive Push Notifications, such as reminders, calendar, Passbook, "Find friends", etc. for iOS. It should be checked which apps Push Notifications are actually necessary for and which applications this service may be disabled for.
9 Anti-theft protection
In the context of Mobile Device Management, the term "anti-theft protection" does not in clude protection against losing the device. This includes the safeguards the IT department or the owner may initiate upon loss or theft in order to protect the data contained on the device against misuse. Once the administrator receives information of the loss, he/she can send cor responding commands from the MDM console, such as "Remote Lock". Some MDM solutions also have a web portal the user may use in order to issue such commands himself/herself. "Remote Lock" locks the device in such a way that any further use is only possible after enter ing the passcode. "Remote Wipe" deletes the data from the smartphone either completely or selectively. Along with the corporate data, the configuration profiles such as access data and certificates must also be deleted. When using an SD card to store corporate data, it must fur thermore be ensured that this SD card is also subjected to deletion. This should be tested in any case.
Additional options regarding "anti-theft protection" include:
• deletion after a certain number of incorrectly entered passcodes • locating the device using the transmitted GPS coordinates
• acoustic signal for retrieval
Please find additional information in the chapter "Business continuity safeguards/emergency drills".
If the smartphone is also used for private purposes along with the official usage, this is a spe cial situation. If an MDM solution is not able to differentiate between official and private data during deletion. For example, if a device is reset to its condition at the time of delivery, all private data will also be lost. This should be governed by a service agreement, since the con sent of the employee may otherwise be required before the private data may be deleted in cases of emergency.
10 Bring your own device (BYOD)
The official use of private devices entails legal conflicts regarding the software licensing law (official use of private licences and vice versa), as well as regarding business continuity safe guards (deletion of all data), data protection and security, etc.
Furthermore, the owner is no longer in control of his/her device, since it is administrated re motely by the IT department. This may result in acceptance issues, particularly since the IT de partment must enforce the configurations selected on the smartphones, inevitably resulting in user restrictions.
In the Android environment, this is aggravated by the now vast range of devices from diverse manufacturers. The performance of these smartphones varies greatly from the simple entry-level device to the "all-rounder" in the high-end segment. New models are launched almost every day. An IT department is not able to check every single device regarding its qualification for use in the company. For smartphones based on Android, this is aggravated by the known update issues. Devices which are not promptly provided with system updates or not provided with any updates at all (regardless of whether private or official device) should not be used for official issues.
As a consequence, the corporate use of the "Bring your own device" concept must be rejected as a rule. If simultaneous private and official usage of these devices is nevertheless permitted, a service agreement must be concluded involving the personnel representatives at an early stage.
Comment: The "Bring your own device" concept is accompanied by another "Private use of corporate equipment“ (PUOCE) concept. The company could procure smartphones which meet all platform-related requirements, are entirely supported by the MDM solution, and are permitted to be used privately to a certain extent. However, the legal concerns mentioned above remain in this case as well.
11 Jailbreak / Root detection
The sandbox principle of iOS, as well as of Android is based on a rights structure of the operat ing system limiting access of apps to other apps and system resources and ensuring that they can only manipulate data in their local area. This rights concept is suspended by the so-called "Jailbreak" for iOS-based devices and/or "Rooting" for Android-based devices so that apps are granted root rights. A Trojan horse on a manipulated device may gain full control of the smartphone and intercept all data – official, as well as private data – this way. Apple installed Jailbreak detection into its operating system as of iOS version 4.0. The MDM solutions were able to use the corresponding program interface (API) in order to detect manipulated devices. However, Apple decided against this concept in version 4.2 and removed the interface. Since then, MDM providers must use their own Jailbreak mechanisms and the same applies to Android.
In any case, an MDM solution requires efficient Jailbreak/Root detection that must be tested by the IT department. This is the only way to identify manipulated devices entailing high levels of risk for the company. Thus, the IT department must have the corresponding devices available for testing.
Unfortunately, the possibilities provided by technologies for Jailbreak/Root detection are lim ited, however, since they are based on software queries and such functions can be deceived with the help of skilful countermeasures.
12 App management
Everybody knows the app stores for smartphones which hundreds of thousands of apps can be downloaded and installed from – free apps, as well as apps subject to charges. For iOS-based devices, this is the Apple "App Store"; apps for Android-based devices are offered in the official Google store "Google Play", but also in many other stores (e.g. Amazon app store). Installation packages for Android (apk files) are not restricted to one store, however. As a matter of prin ciple, they can be loaded and installed from any location.
Many MDM solutions offer a "separate" app store for corporate apps and/or selected public apps as a web portal. Along with the "basic inventory" of apps installed when delivered, a com pany may use this to provide its employees with a selection of admissible (and preferably checked) apps.
The manifestations of the app stores vary, from the simple provision of public apps, via special corporate apps, up to comprehensive app management (distribution, control, monitoring). In the latter case, apps offered for Android (and sometimes for iOS) may be "wrapped" with addi tional control functions using so-called "wrapping" mechanisms. This way, the MDM solution may subsequently control functionalities or authorisations.
Regular control of the apps installed on the employee's smartphone is necessary in order to counteract any misuse of the mobile terminal device. Some MDM solutions offer inventory functionalities for this.
13 Group/user administration, multi-client capability
Frequently, the term "multi-client capability" with regard to administration software is used to refer to the option of administrating different companies, e.g. different customers of an IT ser vice provider. This is not incorrect, but is only one aspect of this topic. The administration of mobile terminal devices presents the IT department with the same problem as the administra tion of desktop computers. For larger companies, it must be possible to provide different branch offices, departments, and groups (such as development, sales, administration) with dif ferent configurations using one console. There may possibly be different subnetworks within the IT infrastructure that must be taken into consideration separately. Thus, it must also be possible to map the IT infrastructure in the administration console of the MDM solution. MDM solutions must comprise group and user administration for different terminal device roles in any case. Furthermore, they may also have a multi-client capability (with the meaning mentioned above). If an MDM solution is used to administrate different "clients" in a larger en vironment, it must be clarified who is responsible for administration. It makes sense to ap point a main administrator who performs the basic settings, as well as several administration administrators responsible for sub-areas. Role-based and/or location-based administrators are conceivable.
14 Business continuity safeguards / emergency drills
If a smartphone or tablet is lost or stolen, this is equivalent to the loss or theft of business-re lated data. The device must be locked and/or erased remotely as quickly as possible. Therefore, it is paramount that the user reports the loss as early as possible. The awareness of the employ ees in this regard should be raised at regular intervals. If the MDM solution contains a self-ser vice portal for this purpose, the employees must be made familiar with the handling of the portal. Furthermore, a business continuity plan must be drawn up containing clear instruc tions that may also be performed by a substitute of the responsible administrator.
In addition to remotely locking/deleting the lost device, the smartphone's access to the com pany must be blocked completely in the administration console so that any unauthorised ac cess is prevented.
15 Protection programs
Apps designed for providing protection against malware on Android-based smartphones work with the same limitations as any other apps. They are locked into a sandbox and must register their authorisations during installation. It is not possible to perform any actions in the depths of the operating system using system authorisations (root/administrator rights).
Malware is detected based on the installation file (apk file). Using the Android authorisation "Retrieve active apps", the protection app is able to compare the installed software packages to a blacklist. This blacklist contains known malware software packages and is either included in the protection program or is retrieved online. This way, infected apps can be identified "on de mand" or during installation.
Additionally, there are further protection functions depending on the configuration level, such as protection against unauthorised access to contact data or SMS and call filters. Addi tional protection functions include "Detect SIM change and lock device" and "Remote wipe" functionalities.
It is fundamentally impossible to install such additional safeguards in iOS for technical reas ons. Apple does not provide any suitable interfaces for this, but checks attacks using mechan isms integrated into the operating system.
Please find additional information on the Android authorisation system on the website "BSI für Bürger" at Exkurs: App-Berechtigungen bei Android.
16 Configuration recommendations (exemplary)
A few selected configuration recommendations for iOS and Android are presented below. They shall be enhanced in later versions of this document. We appreciate proposals for config uration recommendations that are not trivial or that are particularly important for data secur ity (proposals for other mobile operating systems are very much appreciated as well).
The configurations described must be performed by a system administrator responsible for the company in each case and must be protected against changes by the user using a password. If possible, adaptations should be performed in a centralised manner using the MDM solution. Android: External memory
If possible, storing official data to standard SD cards should be avoided, since data thieves could protect the memory card from access by the MDM solution quickly and easily. As a min imum requirement, it must checked whether the stored data is encrypted on the external memory. It must also be checked whether a "Remote wipe" command actually deletes the data on the SD card.
iOS: Configuration profiles
Settings of iOS-based devices are performed using configuration profiles. From a technical point of view, these are files in the XML format sent to and processed on the device. If an ad ministrator changes a setting, the corresponding configuration file (.mobileconfig file) must be re-sent to the device(s). Different MDM solutions configure iOS devices using a single config uration profile. As a consequence, the entire configuration is processed again and the data is
synchronised completely when a single setting is changed. This results in the data being re-transmitted (unnecessarily). Therefore, it makes sense to distribute the configurations to sever al configuration files, which some MDM solutions do.
iOS: "Open in ..."
Different apps offer the "Open in ..." option for processing files. This option displays apps that are capable of processing the file content. Example: Amongst other things, pdf files provide the option of reading the content using the "iBooks", "Chrome", or "Kindle" app. However, it is also possible to move files to a storage service in the cloud (such as "Dropbox") using the "Open in ..." option.
If possible, the MDM solution must disable this option.
By means of the BSI publications, the Federal Office for Information Security (BSI) publishes documents about current topics in the field of cyber security. Comments and advice from readers can be sent to info @cyber-allianz.de.
