For anyone procuring an application built by a third party, you can ask developers the example questions below. Their answers will help you gain more (or less) confidence about the security of their products.
The most thorough way to assess an application before deploying it would be to conduct a full source code review to ensure it meets the security recommendations and contains no malicious or unwanted functionality. Unfortunately, for the majority of third party applications, this will be infeasible or impossible. However, the responses from the third party should help provide confidence that the application is well written and likely to protect information properly.
2.1 Secure data storage
The following questions will help you establish how confident you can be that an Android application stores sensitive data securely.
2.2 Secure data transmission
The following questions will help you gain confidence in how Android applications transmit sensitive data securely:
2.3 IPC mechanisms
The following questions will help you gain confidence in how Android applications share sensitive data securely.
2.4 Binary protection
The following questions will help you gain confidence in how Android applications protect their data within a binary.
2.5 Server side controls
The following questions will help you gain confidence in how Android applications protect their data on the server side.
2.6 Client side controls
The following questions are will help you gain confidence in how Android applications protect their data on the client side.
2.7 Other
PAGE 6 OF 16
Secure deployment of Android applications
3.1 Third party app store applications
Android supports a number of methods to install new third party applications. The following section divides these into two categories, trusted and untrusted:
Untrusted third party applications
Untrusted applications are those that have been produced by developers that your organisation does not have a relationship with. This includes applications hosted by both Google Play and on third party application stores. In these instances you should assume that the third party application may have unwanted functionality. While this functionality may not necessarily be malicious, these applications should be viewed as potential sources of leakage for sensitive data. You should evaluate whether or not an application can run on the device.
Network architecture components such as the reverse proxy can be used to help restrict third party applications from accessing corporate infrastructure. However, these features should be regarded as techniques to help mitigate the potential threat posed by the installation of third-party applications, they cannot guarantee complete protection.
The ideal method of mitigation is to not allow any third party applications to be installed on the device, though in reality this must be taken on a 'per application' basis. Where possible, developers of the application should be consulted in order to understand better the limitations and restrictions of the application. To help your evaluation, you can use the questions given above (feel free to ask more, these represent the minimum you should find out).
Trusted third party applications
You should learn as much as possible about the security posture of an application, so that the risks of deploying it can be understood and managed wherever possible. Your organisation should, ideally, establish a relationship with developers and work with them to understand how their product does (or does not) meet the security posture expected of it.
You should assess third party applications to decide whether the risk of having their code executing on your devices is outweighed by the benefits that the application brings to your organisation. If third party applications are to be permitted on devices with sensitive data, then the following steps should be taken:
- Ensure that the applications holding sensitive data do not permit third party application access to the data, for instance making sure that the third party application is not included as one that the user can choose to open sensitive documents with.
- Ensure that sensitive data would remain secure if the third party application were compromised. For instance, the data should not be accessible due to it being stored in a world-readable location on the device.
Where a third party application is being considered to manage sensitive data, you may also wish to consider commissioning independent assurance. This is particularly true if the application implements its own protection technologies (such as a VPN or data-at-rest encryption), and does not use the native protections provided by Android. Many enterprise applications feature server side components and when present, these should be considered as part of the wider risk assessment..
Private enterprise application catalogues can be created and managed using MDM solutions, allowing organisations to build a set of accepted third party and in-house applications that can either be installed on to every organisational device, or made available for employees to browse and choose to install manually.
Security considerations
When deploying third party applications, the primary concern for an organisation is determining whether these applications could affect the security of the enterprise network, or access data held in a sensitive datastore.
Malware and application level vulnerabilities are of particular concern when developing secure applications for Android. Secure applications must therefore pay particular attention when protecting data both in storage on a device and in transit, if third party applications are permitted on the same device.
You should also consider the security features of the devices that will host your application. A number of manufacturers offer custom security features to protect corporate data from other applications. If the application will only be used on these devices, then permitting third party applications on the same device may be deemed acceptable.
SECURITY REQUIREMENTS
Best practice when using third party applications is as follows:
- Server side components such as a reverse proxy should be used to restrict network enterprise access to trusted applications.
- The developers should be contacted in order to better understand the security posture of the application. Use the Questions for Application Developers section as your starting point.
- Data should be protected from third party applications by restricting their access to sensitive data and functionality.
3.2 In-house applications
In-house applications are those designed and commissioned by an organisation to fulfil a particular business requirement. The organisation can stipulate the functional and security requirements of the application, and enforce these contractually if the development work is subcontracted.
The intention when securing these applications is to minimise the opportunity for data leakage from these applications and to harden them against physical and network-level attacks. For the purposes of this document, these applications are assumed to access, store, and process sensitive data.
SECURITY CONSIDERATIONS
Regardless of whether the application is developed by an internal development team, or under contract by an external developer, you should ensure that supplied binaries match the version which you were expecting to receive. Applications should then be installed onto managed devices through an MDM server or in-house enterprise application catalogue front-end, to gain the benefits of an application being enterprise managed.
SECURITY REQUIREMENTS
Both in-house and third party applications should be deployed directly to devices through an in-house enterprise application catalogue. This means they can be remotely managed, and kept separate from third party applications installed by the user.
PAGE 7 OF 16
Application wrappers
4.1 Security considerations
A variety of 'application wrapping' technologies exist on the market today. Whilst these technologies ostensibly come in a variety of forms which provide different end-user benefits, on most platforms (including Android) they essentially work in one of three ways.
Category 1: These provide a remote view of an enterprise service, for example a Remote Desktop view of a set of internal applications that are running at a remote location, or an HTML-based web application. Multiple applications may appear to be contained within a single application container, or may live separately in multiple containers to simulate the appearance of multiple native applications. Usually, only temporary cached data and/or a credential is persistent on the device itself.
Category 2: These are added to an application binary after compilation and dynamically modify the behaviour of the running application (for example to run the application within another sandbox and intercept and modify platform API calls) in an attempt to enforce data protection.
Category 3: The source code to the surrogate application is modified to incorporate a Software Development Kit (SDK) provided by the technology vendor. This SDK modifies the behaviour of standard API calls to instead call the SDKs API. The developer of the surrogate application will normally need to be involved in the wrapping process.
4.2 Security requirements
Category 1 technologies are essentially normal platform applications, but which store and process minimal information, deferring processing and storage to a central location. The development requirements for these applications are identical to other native platform applications. Developers should follow the guidelines given above.
Category 2and category 3 wrapping technologies are frequently used to provide enterprise management to applications via the MDM server that the device is managed by. SDKs are integrated into these MDM solutions and can be used to configure settings in the application or to modify its behaviour. For example, the application could be modified to always encrypt all data or not use certain API calls.
On Android, both category 2 and category 3 wrapping technologies require the surrogate developer’s co-operation to wrap the application into a signed package for deployment onto an Android device. As such, normally only custom developed in-house applications, and sometimes trusted third party applications (with co-operation) can use these technologies. As the robustness of these wrapping technologies cannot be asserted in the general case, they should not be used with an untrusted application; they should only be used to modify the behaviour of trusted applications, or for ease of management of the wrapped applications.
In-house applications should be developed specifically against the previously described security recommendations wherever possible. The use of app-wrapping technologies should only be used as a less favourable alternative method of meeting the given security recommendations where natively meeting them is not possible.
Ultimately, it is more challenging to gain confidence in an application whose behaviour has been modified by a category 2 technology. It is difficult to assert that dynamic application wrapping can cover all the possible ways an application may attempt to store, access and modify data. It is also difficult to make any general assertions about how any given wrapped application will behave. As such, the NCSC cannot give any assurances about category 2 technologies or wrapped applications in general, and hence cannot recommend their use as a security barrier at this time.
However, category 3 technologies are essentially an SDK or library which developers use as they would any other library or SDK. In the same way that the NCSC does not assure any standalone cryptographic libraries, we do not provide assurance in SDKs which wrap applications. The developer using the SDK should be confident of its functionality, as they would be with any other library.
PAGE 8 OF 16
Apple iOS application development
This guidance contains recommendations for the secure development,procurement and deployment of iOS applications. Please familiarise yourself with the generic application development guidance section before continuing.
- Note that this guidance also refers to concepts described in the NCSC End User Devices Security Guidance. We recommend you familiarise yourself with this before reading the guidance below.
- A general guide to secure Apple programming can be found in Apple’s security guide.
Regarding data at rest and keychain protection classes, the following terminology will be used:
https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development
Note that the other keychain classes have a ‘This device only’ counterpart. More information about these protection classes can be found within Apple’s security guide document and API documentation.
