Application development

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.