This section recommends how to securely deploy the application, should it be from third party organisation or via an in-house application.
3.1 Third party app store applications
iOS 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 on the Apple App Store. Untrusted applications should be restricted from handling sensitive material. You should assume that a proportion of third party applications will 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.
Operating system features can be used to help restrict third party applications from corporate infrastructure. Although 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 decision must be taken on a per application basis. Where possible, consult the developers of the application to understand better its limitations and restrictions. To help your evaluation, you can use the questions given above in the Questions for application developers section (feel free to ask more, these represent the minimum you should find out).
Trusted third party applications
A trusted third party application is an application that has not been developed in-house, but where the risk of trusting the application has been accepted. This should not result in complete trust in the application. Steps should be taken to minimise the threat and impact an application may have if it turns out to be malicious, or compromised.
Unless specifically designed to handle sensitive material, a third party application should never have access to it. Native operating system features, such as Open In Management, should be used to restrict sensitive access only to applications that have been approved. A third party PDF reader installed from Apple’s App Store, for example, should never be allowed to access your corporate infrastructure.
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. Organisations should ideally establish a relationship with the developers of these products and work with them to understand how their product does (or does not) meet its expected security posture.
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 iOS. Many enterprise applications feature server side components and when present, these should be considered as part of the wider risk assessment.
Security considerations
Third party applications may pose a threat to your organisation. Though Apple screens applications submitted to the App Store, this does not ensure that they are free of malware. Malicious applications may seek to gain access to sensitive information, or attempt to access your organisation’s network. Precautions should be taken in order to mitigate these threats.
In order to prevent sensitive information being leaked to a third party application, it should be stored and transmitted securely. The data should be stored on the device using Class A data storage. When in transit, encrypted protocols should be used.
Third party applications should be excluded from accessing your organisation’s network. This can be achieved by only allowing trusted applications to access the VPN to your organisation’s network, using the Per App VPN feature.
Approaching the developers of an application will help gain an insight into its construction. An application should not be installed if it is likely to leak data, interfere with other applications or track the movements of a user.
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 making appropriate use of the keychain.
- Open-in Management should be used to ensure certain file types can only be accessed by approved applications. This will help prevent applications that were not designed for handling sensitive documents from doing so.
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 functionality and security requirements of the application, and can 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 if supplied via business-to-business or the App Store. Either way, applications should then be installed onto managed devices through an MDM server or enterprise app catalogue front-end, to gain the benefits of the app being enterprise-managed.
Security requirements
Both in-house and third party App Store applications should be deployed directly to devices through an enterprise app catalogue. This means they will be marked as managed applications which will not be subject to iCloud backup routines.
Third party applications listed on an enterprise app catalogue may link through to the public App Store. In order for a user to install these applications, the public App Store must be enabled, meaning that any application from the public App Store can be installed. To manage this risk, policies and procedures should be put in place to audit devices, ensuring any unpermitted applications are not installed.
Applications wrappers
This section covers the different types of application wrappers, giving descriptions and the security considerations of each.
4. Application wrappers
This section covers the different types of application wrappers, giving descriptions and the security considerations of each.
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, each providing different end-user benefits, on most platforms (including iOS) 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 a 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 SDK's 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, rather than 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 2 and 3 wrapping technologies are frequently used to provide enterprise management to applications via the MDM 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 the behaviour of the application. For example, the application could be modified to always encrypt data or not use certain API calls.
On iOS, 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 iOS device. As such, normally only custom-developed in-house applications, and sometimes B2B 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 application. Preferably, in-house applications should be developed specifically against the previously described security recommendations wherever possible. The use of app-wrapping technologies should be seen as a less favourable alternative method of meeting the above 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.