8.3 Mobile App Security
A mobile device is any portable technology running an operating system optimized or designed for mobile computing, such as Android or Apple’s iOS. The definition excludes technology running traditional/classic or more general-purpose operating systems, such as any of the Microsoft Windows desktop or server operating systems, versions of macOS, or Linux.
Mobile devices have become an essential element for organizations as part of the overall network infrastructure. Mobile devices provide increased convenience for individuals as well as the potential for increased productivity in the workplace. Because of the widespread use and unique characteristics of mobile devices, security for the devices is a pressing and complex issue. In essence, an organization needs to implement a security policy through a combination of security features built into the mobile devices and additional security controls provided by network components that regulate the use of the mobile devices.
Just as users access remote services via web browsers on computers that link to web servers, users access remote services via apps on their mobile device that link to remote servers. The focus in this case is on the security of the apps.
The execution of mobile applications on a mobile device may involve communication across a number of networks and interaction with a number of systems owned and operated by a variety of parties. This ecosystem makes the achievement of effective security challenging.
Figure 8.3 illustrates the main elements in the ecosystem within which mobile device applications function.
FIGURE 8.3 Mobile Ecosystem
Figure 8.3 shows the following elements in the ecosystem within which mobile device applications function:
Cellular and Wi-Fi infrastructure: Modern mobile devices are typically equipped with the capability to use cellular and Wi-Fi networks to access the Internet and to place telephone calls. Cellular network cores also rely upon authentication servers to use and store customer authentication information.
Public application stores (public app stores): Public app stores include native app stores; these are digital distribution services operated and developed by mobile OS vendors. For Android, the official app store is Google Play, and for iOS, it is simply called the App Store. These stores invest considerable effort in detecting and thwarting malware and ensuring that the apps do not cause unwanted behavior on mobile devices. In addition, there are numerous third-party app stores. The danger with third-party stores is uncertainty about what level of trust the user or the enterprise should have that the apps are free of malware.
Private application stores (private app stores): Many enterprises maintain their own app stores that offer applications of specific utility to the enterprise, for Android, for iOS, or for both.
Device and OS vendor infrastructure: Mobile device and OS vendors host servers to provide updates and patches to the OS and apps. Other cloud-based services may be offered, such as storing user data and wiping a missing device.
Enterprise mobility management systems: Enterprise mobility management (EMM) is a general term that refers to everything involved in managing mobile devices and related components (e.g., wireless networks). EMM is much broader than just information security; it includes mobile application management, inventory management, and cost management. Although EMM is not directly classified as a security technology, it can help in deploying policies to an enterprise’s device pool and monitoring a device’s state.
Enterprise mobile services: These backend services—including email, file sharing, and other applications—are accessible from authorized users’ mobile devices.
Mobile Device Vulnerabilities
Mobile devices need additional, specialized protection measures beyond those implemented for other client devices, such as desktop and laptop devices that are used only within the organization’s facilities and on the organization’s networks. SP 800-124 (Guidelines for Managing and Securing Mobile Devices in the Enterprise) lists seven major security concerns for mobile devices, which the following paragraphs summarize.
Lack of Physical Security Controls
Mobile devices, which are typically under the complete control of the user, are used and kept in a variety of locations outside the organization’s control, including off premises. Even if a device is required to remain on premises, the user may move the device within the organization between secure and non-secured locations. Thus, theft and tampering are realistic threats.
A security policy for mobile devices must assume that any mobile device may be stolen or at least accessed by a malicious party. The threat is twofold: A malicious party may attempt to recover sensitive data from the device itself or may use the device to gain access to the organization’s resources.
Use of Untrusted Mobile Devices
In addition to company-issued and company-controlled mobile devices, virtually all employees have personal smartphones and/or tablets. An organization must assume that these devices are not trustworthy. That is, the devices may not employ encryption, and either the user or a third party may have installed a bypass to the built-in restrictions on security, operating system use, and so on. A policy that allows employees, business partners, and other users to utilize a personally selected and purchased client device to execute enterprise applications and access data and the corporate network is known as a bring-your-own-device (BYOD) policy. Typically, it spans smartphones and tablets, but the strategy may also be used for laptops.
Measures for dealing with BYOD are discussed later in this section.
Use of Untrusted Networks
If a mobile device is used on premises, it can connect to organization resources over the organization’s own in-house wireless networks. However, for off-premises use, the user will typically access organizational resources via Wi-Fi or cellular access to the Internet and from the Internet to the organization. Thus, traffic that includes an off-premises segment is potentially susceptible to eavesdropping or man-in-the-middle types of attacks. Thus, the security policy must assume that the networks between the mobile device and the organization are not trustworthy.
A good mechanism for dealing with untrusted networks is to use a virtual private network (VPN). A VPN is a restricted-use, logical (i.e., artificial or simulated) computer network that is constructed from the system resources of a relatively public physical (i.e., real) network (e.g., the Internet), often using encryption (located at hosts or gateways) and authentication. The endpoints of the virtual network are said to be tunneled through the larger network. An external user can in effect log on to the VPN and then communicate with enterprise servers.
Use of Applications Created by Unknown Parties
By design, it is easy to find and install third-party applications on mobile devices. This poses the obvious risk of installing malicious software. An organization has several options for dealing with this threat, as described subsequently.
Interaction with Other Systems
A common feature on smartphones and tablets is the ability to automatically synchronize data, apps, contacts, photos, and so on with other computing devices and with cloud-based storage. Unless an organization has control of all the devices involved in synchronization, there is considerable risk of the organization’s data being stored in an unsecured location—as well as a risk that malware will be introduced.
Use of Untrusted Content
Mobile devices may access and use content that other computing devices do not encounter. An example is the Quick Response (QR) code, which is a two-dimensional barcode. QR codes are designed to be captured by a mobile device camera and used by the mobile device. The QR code translates to a URL, so that a malicious QR code could direct the mobile device to malicious websites.
Use of Location Services
The GPS capability on mobile devices can be used to maintain a knowledge of the physical location of the device. While this feature might be useful to an organization as part of a presence service, it creates security risks. An attacker can use the location information to determine where the device and user are located, which may be of use to the attacker.
A number of organizations supply mobile devices for employee use and preconfigure those devices to conform to the enterprise security policy. However, many organizations find it convenient or even necessary to adopt a bring-your-own-device (BYOD) policy that allows the personal mobile devices of employees to have access to corporate resources. IT managers should be able to inspect each device before allowing network access. IT should establish configuration guidelines for operating systems and applications. For example, it may say that rooted or jailbroken devices are not permitted on the network, and mobile devices cannot store corporate contacts on local storage. The BYOD policy generally also prohibits sideloading. Whether a device is owned by the organization or an employee, the organization should configure the device with security controls, including the following:
Enable auto-lock, which causes the device to lock if it has not been used for a given amount of time, requiring the user to re-enter a PIN or a password to re-activate the device.
Enable password or PIN protection. The PIN or password is needed to unlock the device. In addition, it can be configured so that email and other data on the device are encrypted using the PIN or password and can only be retrieved with the PIN or password.
Avoid using auto-complete features that remember usernames or passwords.
Enable remote wipe.
Ensure that TLS protection is enabled, if available.
Make sure that software, including operating systems and applications, is up to date.
Install antivirus software as it becomes available.
Either prohibit sensitive data from being stored on the mobile device or require that it be encrypted.
Ensure that IT staff have the ability to remotely access devices, wipe the device of all data, and then disable the device in the event of loss or theft.
Prohibit all installation of third-party applications, implement whitelisting to prohibit installation of all unapproved applications, or implement a secure sandbox that isolates the organization’s data and applications from all other data and applications on the mobile device. Any application that is on an approved list should be accompanied by a digital signature and a public-key certificate from an approved authority.
Implement and enforce restrictions on what devices can synchronize and on the use of cloud-based storage.
To deal with the threat of untrusted content, train personnel on the risks inherent in untrusted content and disabling camera use on corporate mobile devices.
To counter the threat of malicious use of location services, require that these services be disabled on all mobile devices.
Organizations can also enforce the use of a device’s permission options, which are designed to protect privacy. In the case of Android OS, no app, by default, has permission to perform any operations that would adversely impact other apps, the OS, or the user. This includes reading or writing the user’s private data (such as contacts or emails), reading or writing another app’s files, performing network access, keeping the device awake, and so on. An app must publicize the permissions it requires by including a notice known as a manifest. If an app lists normal permissions in its manifest (i.e., permissions that don’t pose much risk to the user’s privacy or the device’s operation), the system automatically grants those permissions to the app. If an app lists dangerous permissions in its manifest (i.e., permissions that could potentially affect the user’s privacy or the device’s normal operation), the user must explicitly agree to grant those permissions.
An Android user can manage all app permissions by opening the list of apps and selecting App Permissions. Android displays a list of different categories of permissions, along with the number of apps installed that have access to that permission. Categories include Body Sensors, Calendar, Camera, Contacts, Location, Microphone, Phone, SMS, and Storage. The user can see a list of which apps have which permission or go to a specific app and see what permissions it has and change the allowable permissions.
Apple’s iOS, for iPhone and iPad, has a similar permissions capability.
Mobile Application Vetting
Millions of apps are available from the two major stores, Apple App Store and Google Play, and millions more from other public app stores. The reliability and security of apps may vary widely, and the vetting process may be opaque or insufficiently robust, particularly for apps from outside the two major stores.
Regardless of the source of an app, an enterprise should perform its own evaluation of the security of an app to determine if it conforms to an organization’s security requirements. The requirements should specify how data used by an app should be secured, the environment in which an app will be deployed, and the acceptable level of risk for an app.
The process of evaluation and approval or rejection of apps within an organization, referred to as app vetting in NIST SP 800-163 (Vetting the Security of Mobile Applications), is illustrated in Figure 8.4. The vetting process begins when an app is acquired from a public or enterprise store or submitted by an in-house or third-party developer. An administrator is a member of the organization who is responsible for deploying, maintaining, and securing the organization’s mobile devices as well as ensuring that deployed devices and their installed apps conform to the organization’s security requirements. The administrator submits the app to an app testing facility in the organization that employs automated and/or human analyzers to evaluate the security characteristics of an app, including searching for malware, identifying vulnerabilities, and assessing risks. The resulting security report and risk assessment are conveyed to an auditor or auditors.
FIGURE 8.4 App Vetting Process
The role of an auditor is to inspect reports and risk assessments from one or more analyzers to ensure that an app meets the security requirements of the organization. The auditor also evaluates additional criteria to determine if the app violates any organization-specific security requirements that could not be ascertained by the analyzers. The auditor then makes recommendation to someone in the organization who has the authority to approve or reject an app for deployment on mobile devices. If the approver approves an app, the administrator can then deploy the app on the organization’s mobile devices.
The U.S. Department of Homeland Security offers a tool, AppVet, that provides automated management support of the app testing and app approval/rejection activities.
Resources for Mobile Device Security
A number of documents from U.S. agencies are valuable resources for any organization planning for mobile device security. The following are particularly useful:
[DHS17]: Study on Mobile Device Security. Develops a threat model consisting of six areas that provides a detailed summary of the greatest threats in each area as well as current mitigations and defenses.
NISTIR 8144: Assessing Threats to Mobile Devices & Infrastructure. Provides a detailed description of the threats related to mobile devices and the enterprise.
SP 800-124: Guidelines for Managing and Securing Mobile Devices in the Enterprise. Provides recommendations for selecting, implementing, and using centralized management technologies and explains the security concerns inherent in mobile device use and provides recommendations for securing mobile devices throughout their life cycles.
SP 800-163: Vetting the Security of Mobile Applications. (Describes in detail app vetting and app approval/rejection activities.
SP 800-164: Guidelines on Hardware-Rooted Security in Mobile Devices. Focuses on defining the fundamental security primitives and capabilities needed to securely enable mobile devices.
SP 1800-4: Mobile Device Security: Cloud and Hybrid Builds. Contains reference architectures; demonstrates implementation of standards-based, commercially available cybersecurity technologies; and helps organizations use technologies to reduce the risk of intrusion via mobile devices.