APP.1.4 Mobile Applications (Apps)

Description

Introduction

Smartphones, tablets, and similar mobile devices are now widespread even in government agencies and companies. Employees can access the institution’s data, information, and applications regardless of location and time.

Mobile applications (apps) are applications that are installed and run on mobile operating systems such as iOS or Android on the corresponding end devices. Apps are typically obtained from so-called app stores. These are often operated and maintained by the manufacturing institutions of the mobile operating systems and end devices. In professional environments, however, it is also common to develop apps in-house and install and manage them on end devices via Mobile Device Management (MDM) solutions. Compared to applications on desktop operating systems, apps on iOS or Android are subject to special conditions, such as a permission management system enforced by the operating system.

For the various mobile operating systems, there is now a large selection of available apps. There are also standardized libraries and development environments that allow apps to be developed quickly compared to traditional applications.

Objective

The objective of this building block is to protect information processed by apps on mobile end devices. The integration of apps into an existing IT infrastructure is also considered. The building block also defines requirements for selecting apps correctly and operating them securely. The apps are considered regardless of their source (app store or in-house installation).

Scope and Modeling

The building block APP.1.4 Mobile Applications (Apps) is to be applied to all applications used on mobile end devices.

The building block covers apps on mobile operating systems such as iOS and Android. Requirements relating to the underlying operating systems are not considered here. These requirements are found, for example, in the building blocks SYS.3.2.3 iOS (for Enterprise)) and SYS.3.2.4 Android. Apps are often managed centrally via a Mobile Device Management. Requirements for this can be found in the building block SYS.3.2.2 Mobile Device Management (MDM)).

Likewise, application-specific aspects of apps are not the subject of the building block on mobile applications. These are addressed in the corresponding building blocks of the APP layer Applications, such as APP.1.2 Web Browsers.

Apps frequently use backend systems or servers or application services. If the backend systems or servers are operated in-house, security recommendations for these are not provided here but in the corresponding building blocks of the IT-Grundschutz Compendium. These include, for example, APP.3.1 Web Applications and Web Services or APP.4.3 Relational Databases. In addition, the building blocks dealing with general aspects of applications should be taken into account, such as OPS.1.1.6 Software Tests and Approvals or APP.6 General Software, since these aspects are not covered in the present building block. When developing in-house apps, the requirements of the building block CON.8 Software Development should be taken into account.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used as the basis for describing the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block APP.1.4 Mobile Applications (Apps).

Inappropriate Selection of Apps

The selected apps have a strong impact on the information processed with them, on the mobile end device, and frequently on the IT infrastructure of the institution. If this is not taken into account when selecting apps, far-reaching problems can arise. The risk is particularly high when apps are used that were not specifically developed for the business processes to be represented. For example, the prerequisites required for operating an app may not be adequately considered. It is then possible, for example, that the mobile network connection is not powerful enough or the hardware is not compatible. Apps can also be unsuitable if they do not offer sufficient long-term deployment stability and planning or are not adequately maintained by the manufacturing institutions.

Excessive Permissions

Apps require certain permissions to access specific functions and services. For example, an app can generally always access the mobile end device’s internet connection. The location or address book, on the other hand, usually have to be explicitly granted. If apps are used that require excessively broad permissions, or if the permissions are not sufficiently restricted, this can affect in particular the confidentiality and integrity of the information on the end device. Apps can also pass on information to unauthorized third parties, such as the location, photos, or contact and calendar data. Furthermore, apps are capable of modifying or deleting locally stored data. Finally, apps can also incur costs, for example through phone calls, sent SMS messages, or in-app purchases.

Unintended Functions in Apps

Although some app store operators check the apps on offer, these can still contain security vulnerabilities or deliberately implemented malicious functions. The risk is particularly high when apps are obtained from unchecked or unreliable sources. This can jeopardize the confidentiality, integrity, and availability of information.

Software Vulnerabilities and Errors in Apps

Apps may contain vulnerabilities through which they can be attacked directly on the device or via network connections. In addition, many apps are no longer maintained by their developers after some time. As a result, identified security deficiencies are no longer remedied by corresponding updates.

Insecure Local Storage of Application Data

Some apps store data on the end device, such as Users’ profiles or documents. If this data is insufficiently protected, other apps may be able to access it. This affects not only deliberately stored data but also temporary data, such as information cached in the cache. They are also easily readable by unauthorized persons, e.g., if employees have lost their devices. Furthermore, locally stored information is often not included in the data backup concept. If the end device fails or is lost, the locally stored information is also no longer available.

Inference of Confidential Information from Metadata

Apps accumulate a lot of metadata. Using this metadata, third parties can infer confidential information, e.g., about telephone and network connections, movement data, or visited websites. From this, further information can then be derived, such as the organizational structure of the institution, the precise locations of sites, and their staffing.

Leakage of Confidential Data

Data is transmitted via various routes to and from an app. Mobile operating systems provide various interfaces for this. Users also have various options for exchanging data with an app, such as locally via a memory card, the clipboard, the device camera, or other applications. In addition, data can be transmitted via cloud services or servers of the app or device provider. Through this, third parties can gain access to confidential data. Finally, the operating system itself can cache data for faster access (caching). In doing so, data can accidentally leak or attackers can access confidential information.

Insecure Communication with Backend Systems

Many apps communicate with backend systems through which data is exchanged with the institution’s data network. For mobile devices, data is mostly transmitted via insecure networks such as mobile phone networks or Wi-Fi hotspots. However, if insecure protocols are used for communication with backend systems, information can be intercepted or manipulated.

Communication Channels Outside the Institution’s Infrastructure

If apps can communicate with third parties in an uncontrolled manner, this can create communication channels that cannot be recognized and controlled by the institution. For example, Users may use a cloud storage service’s app to transmit information from the end device to the outside. The close intertwining of social media services with many apps also makes it difficult to control whether and how information leaves the end device. This type of communication channel is difficult to trace. This can cause further problems, for example when information or processes need to be archived.

Requirements

The following are the specific requirements of the building block APP.1.4 Mobile Applications (Apps). 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 meaningful and appropriate.

Exactly one role SHOULD be Primarily responsible. There may also 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 requirement heading. The use of singular or plural says nothing about how many people SHOULD fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

APP.1.4.A1 Requirements Analysis for the Use of Apps (B) [Fachverantwortliche]

In the requirements analysis, risks arising from mobile use MUST in particular be considered. The institution MUST check whether its control and influence options on the operating system environment of mobile end devices are sufficient to use them securely.

APP.1.4.A2 DISCONTINUED (B)

This requirement has been discontinued.

APP.1.4.A4 DISCONTINUED (B)

This requirement has been discontinued.

APP.1.4.A5 Minimization and Control of App Permissions (B) [Fachverantwortliche]

Security-relevant permission settings MUST be fixed so that they cannot be changed by persons or apps. Where this is technically not possible, the permission settings MUST be regularly reviewed and reset.

Before an app is introduced in an institution, it MUST be ensured that it only receives the minimum required app permissions for its function. Permissions that are not strictly necessary MUST be questioned and, if necessary, blocked.

APP.1.4.A6 DISCONTINUED (B)

This requirement has been discontinued.

APP.1.4.A7 Secure Storage of Local App Data (B)

If apps can access internal documents of the institution, it MUST be ensured that the app’s local data storage is adequately secured. In particular, access keys MUST be stored in encrypted form. Furthermore, confidential data MUST NOT be cached by the operating system in other storage locations.

APP.1.4.A8 Prevention of Data Leakage (B)

To prevent apps from unintentionally transmitting confidential data or creating profiles of Users from transmitted data, app communication MUST be appropriately restricted. For this purpose, communication SHOULD be analyzed as part of the testing and approval process. Furthermore, it SHOULD be checked whether an app writes unintended log or auxiliary files that may contain confidential information.

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.

APP.1.4.A3 Distribution of Protection-Worthy Apps (S)

Internal apps of the institution and apps that process protection-worthy information SHOULD be distributed via an institution-owned app store or via MDM.

APP.1.4.A9 DISCONTINUED (S)

This requirement has been discontinued.

APP.1.4.A10 DISCONTINUED (S)

This requirement has been discontinued.

APP.1.4.A11 DISCONTINUED (S)

This requirement has been discontinued.

APP.1.4.A12 Secure Uninstallation of Apps (S)

When apps are uninstalled, data that was stored on external systems, for example with the app providers, SHOULD also be deleted.

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. These proposals SHOULD be considered when there is a high protection need. The specific determination takes place in the context of an individual risk analysis.

APP.1.4.A13 DISCONTINUED (H)

This requirement has been discontinued.

APP.1.4.A14 Support for Additional Authentication Features in Apps (H)

Where possible, a second factor SHOULD be used for authentication in apps. Care SHOULD be taken to ensure that any sensors or interfaces that may be required are present in all devices used. In addition, for biometric methods, consideration SHOULD be given to how resistant the authentication is against possible forgery attempts.

APP.1.4.A15 Conducting Penetration Tests for Apps (H)

Before an app is approved for use, a penetration test SHOULD be conducted. All communication interfaces with backend systems as well as local data storage SHOULD be examined for possible security vulnerabilities. The penetration tests SHOULD be repeated regularly and additionally when major changes are made to the app.

APP.1.4.A16 Mobile Application Management (H)

Where possible, a Mobile Application Management SHOULD be used for the central configuration of business apps.

Additional Information

Good to Know

The German Association for Information Technology, Telecommunications and New Media (Bitkom) provides decision-making assistance on the topic of apps and mobile services in companies with the guide “Apps & Mobile Services - Tips for Companies” (2nd edition, 2014).

The Information Security Forum (ISF) offers a brochure entitled “Securing Mobile Apps - Embracing mobile, balancing control” (2018).

The “NIST Special Publication 800-163: Vetting the Security of Mobile Applications” (2015) also provides further information on the topic of apps.