SYS.3.2.4 Android
A widely used operating system for smartphones and tablets is Android from Google. Since version 4, Android has been gradually expanded for enterprise use...
Description
Introduction
A widely used operating system for smartphones and tablets is Android from Google. Since version 4, Android has been gradually expanded for enterprise use. For example, functions were integrated that make it easier for institutions to manage Android devices. The number of management policies supported by Android also increases with each version. Additionally, specific extensions from device manufacturers enable additional policies.
Objective
The objective of this building block is to inform about typical threats associated with Android and to demonstrate how Android-based devices can be securely used in institutions. Based on the requirements listed in the building block, security policies can also be created.
Scope and Modeling
The building block SYS.3.2.4 Android must be applied to all officially used smartphones and tablets with the operating system Google Android.
The building block contains fundamental requirements that must be observed and met when operating Android-based devices. General and overarching requirements for the operation of smartphones and tablets are not addressed in this building block but in SYS.3.2.1 General Smartphones and Tablets and must also be implemented when Android-based devices are used. Also not part of this building block are requirements for the case of central administration of Android devices via an MDM. These are listed in the building block SYS.3.2.2 Mobile Device Management (MDM)).
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.4 Android.
Disabling Security Features
The boot process of Android-based devices is secured using a manufacturer certificate. Each subsequent execution step is verified before it is executed. This ensures that the Android operating system starts unmodified.
When the bootloader is unlocked, this chain of trust is broken, allowing a modified operating system to start. Such modifications to the boot process are in some cases supported by the manufacturing institution, and in other cases bootloaders are also unlocked via vulnerabilities.
The Android security concept is thereby bypassed or rendered inoperative, creating new threats that must be mitigated elsewhere.
Malware for the Android Operating System
Due to its widespread use and open architecture, devices running the Android operating system are a popular target for malware, which is often installed by users themselves. Under Android, it is relatively easy to install apps not only from Google’s Play Store but also from alternative sources or via direct download. In addition to the monitored app stores of Google, device manufacturers, and other providers, apps are also offered for installation from rather dubious sources. Since it is not strictly necessary under Android to install apps from the official Google Play Store, attackers could, for example, infect a popular app with malware and then make it available for download again.
Missing Updates for the Android Operating System
Some manufacturing institutions deliver smartphones and tablets with outdated versions of Android or do not provide regular or any updates at all. Since vulnerabilities in Android are regularly discovered, such devices are particularly at risk. As a consequence, known vulnerabilities in these devices cannot be eliminated and can consequently be easily exploited by attackers.
Risk Through Accounts (Google ID) for Google Services
With the Google ID, users can centrally access all Google services, e.g., device management, recorded geographic positions, chat software, cloud storage, the Play Store, music, book and film offerings, data backup, bookmarks, or password storage for websites and synchronization services. Many other service providers also use the Google ID to authenticate users.
If attackers can authenticate via the Google ID, all services associated with it can be used under the stolen identity. Also, all data stored there can be accessed and devices can be remotely located or reset, i.e., all data on the device deleted.
Pre-Installed Apps and Integrated Functions in Android-Based Devices
With the operating system, manufacturers of Android devices often deliver already firmly integrated and pre-installed apps as well as connections to third-party services (Twitter, Facebook, etc.). Users often cannot remove these apps themselves. This increases the attack surface of the Android operating system. The direct connection to third-party services is also often undesirable in institutions.
Overall, the deep integration of apps and interfaces from third-party providers increases the risk of the device being infected with malware or attackers gaining unauthorized access to confidential information.
Requirements
The following are the specific requirements of the building block SYS.3.2.4 Android. 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.4.A1 DISCONTINUED (B)
This requirement has been discontinued.
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.4.A2 Deactivation of Developer Mode (S)
The developer mode SHOULD be deactivated on all Android-based devices.
SYS.3.2.4.A3 Use of Multi-User and Guest Mode (S)
It SHOULD be regulated whether a device may be shared with other people. It SHOULD be defined whether the multi-user or guest mode must be used for this purpose. Users on an Android-based device SHOULD be natural persons.
SYS.3.2.4.A4 DISCONTINUED (S)
This requirement has been discontinued.
SYS.3.2.4.A5 Extended Security Settings (S)
Only approved security apps SHOULD be granted device administration rights or be allowed to register as “Trust Agents”. This SHOULD be regularly reviewed.
Furthermore, only permitted apps SHOULD be able to access usage data and notifications.
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.4.A6 DISCONTINUED (H)
This requirement has been discontinued.
SYS.3.2.4.A7 DISCONTINUED (H)
This requirement has been discontinued.
Additional Information
Good to Know
There is no additional information for the building block SYS.3.2.4 Android.