SYS.3.2.1 General Smartphones and Tablets

Description

Introduction

Smartphones are IT systems designed for mobile use with an adapted interface that can be operated with a large, typically touch-sensitive screen (touch display). In addition to telephony, smartphones combine, for example, media players, personal information managers, and digital cameras in one device, and also offer users many other applications and functions such as web browsers, e-mail clients, or location tracking (e.g., via GPS). They are also equipped with cellular, WLAN, Bluetooth, and NFC interfaces. Tablets are, in simplified terms, smartphones with a large form factor that as a rule cannot make phone calls over a cellular network.

Objective

The objective of this building block is to provide those responsible for security management and IT Operations with information on typical threats to smartphones and tablets, as well as to convey requirements for how these can be avoided or eliminated. Additionally, approaches are to be shown to those responsible for creating protection-needs-appropriate configuration profiles. These configuration profiles can be distributed and managed via a central infrastructure using a Mobile Device Management (MDM). However, given the large number of different mobile operating systems, it cannot generally be assumed that devices can be integrated into such an MDM.

Scope and Modeling

The building block SYS.3.2.1 General Smartphones and Tablets must be applied to all smartphones and tablets used for official purposes.

This building block does not address how specific operating systems of smartphones and tablets are secured, as this is described in detail in the building blocks for the respective systems, e.g., in SYS.3.2.3 iOS (for Enterprise)) or SYS.3.2.4 Android. Security requirements for operating an MDM are described in SYS.3.2.2 Mobile Device Management (MDM)). These building blocks must be applied additionally when smartphones and tablets are used in institutions.

Smartphones, like ordinary clients, are threatened by malicious programs. They must be taken into account in the concept for protection against malware. Requirements for protection against malicious programs can be found in the building block OPS.1.1.4 Protection Against Malicious Programs.

Smartphones and tablets generally offer the ability to install mobile applications (apps). To avoid unnecessary security risks in this regard, the requirements of the building block APP.1.4 Mobile Applications (Apps)) must be taken into account. Additionally, other building blocks from the APP Applications layer, such as APP.1.2 Web Browser, may be relevant.

Since smartphones generally have cellular capabilities, the relevant requirements of the building block SYS.3.3 Mobile Phone must be taken into account.

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.1 General Smartphones and Tablets.

Missing Operating System Updates

New versions and updates of mobile operating systems appear regularly. For devices that have specific extensions to the operating system from the manufacturer, these must first be integrated into their version and then distributed. Updates are generally provided for the most recent device generation and for a number of older device generations. However, not all previous operating system versions receive (security) updates to the same extent. Operating systems are sometimes not further developed for economic reasons. Subsequently discovered vulnerabilities in the operating system of an already discontinued device generation can then no longer be closed through updates and can be exploited particularly easily in an attack.

Software Vulnerabilities in Pre-Installed Applications (Apps)

Pre-installed apps can also contain vulnerabilities that can be exploited for local attacks or attacks via network connections. Furthermore, many apps from third-party developers are no longer maintained after a period of time. As a result, recognized security deficiencies can no longer be remedied through corresponding updates.

Manipulation of Smartphones and Tablets

In an attack, access to smartphones or tablets can be gained in order to deliberately manipulate data. For example, the configuration could be changed, additional services started, or malware installed. This can result in, for example, communication connections being intercepted (unintended data exfiltration) or security settings being changed (e.g., allowing access from the Internet to the end device) on the manipulated system.

Malware for Smartphones and Tablets

Like every device connected to the Internet, mobile devices are also threatened by malware. The risk of infection is lower compared to client operating systems such as Microsoft Windows, but attackers are increasingly concentrating on mobile devices. In particular when apps are obtained from untrustworthy sources or when no updates are available for known vulnerabilities, there is a risk of infection. If a device is infected, data can be read, modified, or deleted, internal IT resources of the institution can be accessed, or actions can be taken in the institution’s name.

Web-Based Attacks on Mobile Browsers

Mobile browsers, but also many other apps, can display web pages and web content. This can expose devices to phishing attacks, drive-by exploits, and other web-based forms of attack.

Misuse of Health, Fitness, and Location Data

The operating system of many smartphones and tablets usually contains special functions for managing health, fitness, and location data. This personal data represents an attractive attack target and is particularly worthy of protection, especially when collected and stored over an extended period. The prerequisite is that these functions have been activated.

For example, the location of the device can become visible through an attack on the device itself or on connected cloud services. In addition to data protection implications, this can under certain circumstances lead to further attacks. For example, burglaries at employees’ homes are conceivable when they are on a trip according to their location data.

Misuse of Sensitive Data on the Lock Screen

Many mobile operating systems have a function that allows notifications from activated widgets and push notifications to be displayed on the lock screen. This can expose confidential information to unauthorized third parties who can exploit it. Via voice assistants, it is also often possible to access phone functions and contact data even when the device is locked. This too can result in unauthorized third parties gaining access to confidential information.

Furthermore, in the locked state it is often possible to configure interfaces such as WLAN or Bluetooth. This allows, for example, an additional attack vector to be activated if the Bluetooth interface is switched on by an attacker with physical access.

Risks From Private Use of Official Smartphones and Tablets

When employees use company-owned smartphones and tablets privately, multiple problems for the information security of the institution arise. For example, users might independently install apps that contain malicious functions, or they might visit a website that infects the device with malware. Likewise, many privately installed apps pose a risk to the institution’s information stored on the device, as they can, for example, read address books and transmit them to unknown servers, or potentially access e-mails or documents. As a result, data could flow out or conversely enter the institution in an uncontrolled manner. Typical examples of apps with such risks are social media and messenger apps.

Risks From Bring Your Own Device (BYOD)

If private end devices are used for official purposes, various threat potentials arise as a result. For example, legal problems may arise regarding software licenses. If in an emergency official data must be deleted from the device by the MDM, this can also affect the private data on the device.

Furthermore, those responsible for IT cannot check every individual private device to determine whether it meets official requirements. As a result, devices can be used that cause users to violate data protection and security requirements. Additionally, users are often responsible themselves for maintaining and having their devices repaired. During such a repair, company data could potentially be accessed without authorization. The same risk exists if it is not regulated what is to happen to the data on the device when employees leave the institution.

Privilege Escalation Through Vulnerabilities

Vulnerabilities are repeatedly discovered in the operating systems of smartphones and tablets that allow the security concepts established by manufacturers to be circumvented and thus access system processes and protected memory areas. As a result, programs can gain permissions not intended for them, enabling them to perform unauthorized actions. For example, programs could thus access data from the operating system and other apps.

So-called jailbreaks exploit these vulnerabilities in order, for example, to be able to use alternative app stores or other extensions. Jailbreak techniques can be used in an attack to install malware or perform other harmful manipulation on the device.

Malware can also exploit vulnerabilities to install itself on a device or to manipulate it. As a result, the operating system can be used in a manner other than intended and important security functions can be bypassed.

Particularly affected is data stored by the mobile operating system in protected areas, as an app with superuser rights may be able to read it.

Intentional privilege escalation (“rooting”) can give rise to similar threat scenarios if access to the privileged rights is not protected.

Requirements

The following are the specific requirements of the building block SYS.3.2.1 General Smartphones and Tablets. 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.

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.1.A1 Defining a Policy for the Use of Smartphones and Tablets (B)

Before an institution provides, operates, or deploys smartphones or tablets, a general policy for the use and control of the devices MUST be defined. Among other things, it MUST be determined who is permitted to access which information of the institution on smartphones.

SYS.3.2.1.A2 Defining a Strategy for Cloud Usage (B)

The institution MUST define a general strategy for cloud usage and for the protection and control of information in connection with smartphones and tablets. The permitted use of cloud services for the institution’s information MUST be clarified and defined. It MUST be determined whether and to what extent cloud services are permitted for private use of the devices. Users MUST be regularly sensitized regarding the use of such cloud services.

SYS.3.2.1.A3 Secure Basic Configuration for Mobile Devices (B)

All mobile end devices MUST be configured so that they adequately meet the required protection level. For this purpose, an appropriate basic configuration of security mechanisms and settings MUST be compiled and documented. Unused functions SHOULD be deactivated. The activation of communication interfaces MUST be regulated and reduced to the level necessary for official use. Unused interfaces SHOULD be deactivated.

SYS.3.2.1.A4 Use of Access Protection (B) [Users]

Smartphones and tablets MUST be protected with an adequately complex device lock code. The screen lock MUST be used. The display of confidential information on the lock screen MUST be deactivated. All mobile devices MUST automatically activate the screen lock after an appropriately short period of time. This period MUST be commensurate with the targeted protection level.

For each failed attempt to unlock the device, the wait time until a new attempt SHOULD increase. The number of device lock codes after which a code is permitted to repeat SHOULD be defined. After multiple failed attempts to unlock the screen, the mobile device SHOULD reset itself to factory state. In doing so, the data or encryption keys SHOULD be securely destroyed. It SHOULD be avoided that users use recently used passwords when changing their password.

SYS.3.2.1.A5 Updates of Operating System and Apps (B)

Even when selecting mobile devices to be procured, the institution MUST ensure that the manufacturing institution specifies over what planned usage period security updates will be provided for the devices. Older devices for which no more updates are provided MUST be decommissioned and replaced by devices supported by the manufacturer. Apps SHOULD also NOT continue to be used if they are no longer supported by the manufacturer.

SYS.3.2.1.A6 Privacy Settings and Permissions (B)

Access by apps and the operating system to data and interfaces MUST be appropriately restricted. Privacy settings MUST be configured as restrictively as possible. In particular, access to the camera, microphone, and location and health/fitness data MUST be checked for conformity with the organization’s internal data protection and security requirements. Access MUST be configured restrictively or deactivated.

Security-relevant permission settings MUST be defined in such a way that they cannot be changed by users or apps. Where this is technically not possible, the permission settings MUST be regularly reviewed and reset. This applies in particular after the installation of updates.

SYS.3.2.1.A7 Behavioral Rules for Security Incidents (B) [Users]

If devices are lost or unauthorized changes to the device and software are detected, users MUST immediately inform those responsible.

SYS.3.2.1.A8 Installation of Apps (B)

The institution MUST regulate whether, how, and which apps users may install on their devices themselves. Users SHOULD only be permitted to install approved apps. The institution MUST define from which sources apps may be installed. It MUST be prevented that apps from unauthorized sources can be installed.

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.1.A9 Restrictive Use of Functional Extensions (S)

Functional extensions SHOULD only be used restrictively. Where possible, functional extensions SHOULD be dispensed with. The functional extensions SHOULD NOT have automatic access to sensitive information. They SHOULD NOT be able to bypass or modify the defined basic configuration.

SYS.3.2.1.A10 Policy for Employees on the Use of Mobile Devices (S) [Users]

A binding policy for employees on the use of mobile devices SHOULD be created. This SHOULD define how mobile devices are to be used and maintained. The topics of storage and loss reporting SHOULD be addressed therein. Furthermore, it SHOULD be prohibited to uninstall management software, to root the device, or to change security-relevant configurations.

SYS.3.2.1.A11 Encryption of Storage (S)

The non-volatile storage of the mobile device SHOULD be encrypted. Sensitive data on additionally used storage media, such as SD cards, SHOULD be encrypted.

SYS.3.2.1.A12 Use of Non-Personalized Device Names (S)

The device name SHOULD contain no references to the institution or to users.

SYS.3.2.1.A13 Regulations on Screen Sharing and Casting (S)

A decision SHOULD be made on whether and how functions for the transmission of screen content, audio, or video (screen sharing or casting) are to be used. The functions SHOULD be regulated organizationally or technically. For this purpose, a corresponding agreement SHOULD be made with users.

SYS.3.2.1.A14 DISCONTINUED (S)

This requirement has been discontinued.

SYS.3.2.1.A15 DISCONTINUED (S)

This requirement has been discontinued.

SYS.3.2.1.A16 Deactivation of Unused Communication Interfaces (S) [Users]

Communication interfaces SHOULD only be activated when needed and only in suitable environments. If an MDM is used, the interfaces SHOULD be managed centrally via the MDM.

SYS.3.2.1.A17 DISCONTINUED (S)

This requirement has been discontinued.

SYS.3.2.1.A18 Use of Biometric Authentication (S)

If biometric methods are to be used for authentication (e.g., a fingerprint sensor), it SHOULD be checked whether this achieves a similarly high or higher level of protection compared to a device password. In case of doubt or poorer protection, biometric methods SHOULD NOT be used. Users SHOULD be made aware of the forgability of biometric characteristics.

SYS.3.2.1.A19 Use of Voice Assistants (S)

Voice assistants SHOULD only be used if absolutely necessary. Otherwise they SHOULD be deactivated. In general, a voice assistant SHOULD NOT be usable when the device is locked.

SYS.3.2.1.A20 DISCONTINUED (S)

This requirement has been discontinued.

SYS.3.2.1.A21 DISCONTINUED (S)

This requirement has been discontinued.

SYS.3.2.1.A22 Integration of Mobile Devices into the Internal Infrastructure via VPN (S)

Mobile end devices SHOULD only be integrated into the institution’s infrastructure using a VPN. For this purpose, a suitable method SHOULD be selected and deployed. Instead of passwords, the devices SHOULD authenticate themselves to the internal infrastructure via certificates.

SYS.3.2.1.A28 Use of Website Filtering Options (S)

If a reputation service or a corresponding proxy server is already in use at the institution, this SHOULD be stored as a global HTTP proxy for all installed browsers. If the proxy is only reachable in the internal network, the end devices SHOULD be integrated appropriately via a VPN connection, either permanently or based on the apps used.

If the mobile end devices are not integrated into an existing proxy or reputation infrastructure of the institution, filter options based on allowlists or blocklists or third-party content filters SHOULD be used for web browsers.

SYS.3.2.1.A31 Regulation on Mobile Payment (S)

It SHOULD be regulated whether mobile payment with official smartphones and tablets is permitted.

SYS.3.2.1.A32 MDM Usage (S)

Smartphones and tablets SHOULD be managed by an MDM system.

SYS.3.2.1.A33 Selection and Installation of Security Apps (S)

All mobile end devices SHOULD be protected against malicious programs. If possible, suitable security apps SHOULD be selected for the end device. The security apps SHOULD be installed automatically, for example via an MDM.

SYS.3.2.1.A34 Configuration of the DNS Server Used (S)

Standard gateway entries, such as DNS servers of the manufacturing or developing institutions, SHOULD be replaced by those of the provider or by the institution’s own.

If the provider offers so-called DNS-over-HTTPS (DoH), this SHOULD be used. If it does not yet offer this, it SHOULD be deactivated.

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.1.A23 DISCONTINUED (H)

This requirement has been discontinued.

SYS.3.2.1.A24 DISCONTINUED (H)

This requirement has been discontinued.

SYS.3.2.1.A25 Use of Separate Work Environments (H)

If employees are permitted to use official devices also privately, solutions for separate work environments SHOULD be deployed on the end device. Where possible, only certified products (e.g., under Common Criteria) SHOULD be procured for this purpose. Official data SHOULD remain exclusively in the official environment.

SYS.3.2.1.A26 Use of PIM Containers (H)

Information on mobile end devices SHOULD be encapsulated, for example in a PIM container. Additionally, the data SHOULD be secured through separate authentication and data and transport encryption independent of the operating system.

SYS.3.2.1.A27 Use of Specially Secured End Devices (H)

Depending on the protection needs, institutions SHOULD use specially secured mobile end devices that are certified for processing information according to statutory information protection classifications.

SYS.3.2.1.A29 Use of an Institution-Related APN (H)

It SHOULD be examined whether an institution-related access point to the cellular network (APN, Access Point Name) can be used to limit the pool of permitted devices. All devices using this APN SHOULD receive an IP address range coordinated with the institution from the cellular provider. For authentication, a complex password of up to 64 characters SHOULD be agreed with the cellular provider. If an institution-related APN is used, authentication SHOULD be implemented based on the CHAP protocol.

SYS.3.2.1.A30 Restriction of App Installation Using an Allowlist (H)

With a higher protection need, only approved and reviewed apps SHOULD be permitted to be installed on mobile end devices. If an MDM is used, it SHOULD prevent other apps from being installed, or alternatively remove unauthorized apps immediately.

SYS.3.2.1.A35 Use of a Firewall (H)

A firewall SHOULD be installed and activated on smartphones and tablets.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides requirements for the use of mobile end devices in the standard ISO/IEC 27001:2013, particularly in Annex A, A.6.2 “Mobile devices and teleworking”.

The Information Security Forum (ISF) provides requirements for the use of mobile end devices in its standard “The Standard of Good Practice for Information Security”, particularly in Area PA2 Mobile Computing.

The National Institute of Standards and Technology (NIST) provides the following documents in the area of mobile end devices:

• “Guidelines for Managing the Security of Mobile Devices in the Enterprise: NIST Special Publication 800-124”, Revision 1, June 2013
• “Security and Privacy Controls for Federal Information Systems and Organizations: NIST Special Publication 800-53”, Revision 4, April 2013
• “Securing Electronic Health Record on Mobile Devices: NIST Special Publication 1800-1d”, Draft, July 2015