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.

3.1 Third party Windows Store applications

Windows supports a number of methods to install new third party applications. The following section divides such applications into two types: untrusted and trusted.

Untrusted third party applications

Untrusted applications are those that have been produced by developers with whom the organisation does not have an existing relationship. This includes applications hosted by both Windows Store and on third party application stores. In these instances you should assume that the third party application may have unwanted functionality, either due to weaknesses in its design, or deliberately malicious code. The Windows Store does check apps for known malware during the certification process but this should not be relied upon by itself. Untrusted third party applications should therefore never be granted access to sensitive data, and should be assessed before inclusion in your organisation’s private enterprise application catalogue.

The Windows Store indicates which app permissions are required by the application. These should be reviewed carefully to ensure they are appropriate and do not provide the application with unnecessary or unmanaged access to sensitive data.

Network architecture components such as the reverse proxy can be used to help restrict third party applications from accessing corporate infrastructure. Although such 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 for application developers section (feel free to ask more, these represent the minimum you should find out).

Trusted third party applications

You are encouraged to learn as much as possible about the security posture of an application, so the risks of deploying it can be understood and managed wherever possible. Your organisation 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 the security posture expected.

Trusted applications have been assessed as posing an acceptable amount of risk to the organisation. This should, however, not result in complete trust of the application and steps should be taken to mitigate relevant risks and impacts. A third party application should never have access to sensitive data unless designed and accredited to do so. For those applications deemed to be trusted, their access to data should be restricted and the principle of least privilege should be applied. If devices are managed, restrictions should be applied with use of native operating system features such as Windows Information Protection (WIP), which defines the third party applications that can access enterprise protected files, Virtual Private Networks (VPN) and enterprise data on the clipboard or through a share contract.

Where a third party application is being considered to handle sensitive data, organisations may also wish to consider commissioning independent assurance. This is particularly recommended 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 UWP.

Many enterprise applications feature server side components, which should be considered as part of the wider risk assessment.

Security considerations

When deploying third party applications, the primary concern for an organisation is whether applications could affect the security of the enterprise network, or access data held in a sensitive datastore.

UWP applications must pass a certification process before being published to the Windows Store, which includes checks for known viruses and malware. However, this should not be taken as an indication that the application poses no threat to the organisation and additional threat mitigation activities should be undertaken. Specifically, this involves taking the recommended steps to protect both data-at-rest and data-in-transit while third party applications are permitted on the device.

You should also consider security features of the devices that will host their applications. 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, permitting third party applications on the same devices 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 enterprise network 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 the application’s access to sensitive data and functionality.

3.2 In-house Windows store applications

In-house applications are those applications which are 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. For the purposes of this document, these applications are assumed to access, store, and process sensitive data. The intention when securing these applications is to minimise the opportunity for data leakage, and to harden them against physical and network-level attacks.

The following best practice guidelines should be followed when developing applications for use internally:

• Consider security concerns throughout the product lifecycle, including the design, development, and ongoing support stages.
• Ensure that developers and product owners follow the NCSC secure development and deployment guidance.
• Ask the questions listed in the Questions for application developers section.
• Ensure that contracted developers deliver source code for the final product

3.3 General security advice

Microsoft provide a selection of technologies that can be used to assist the secure deployment of applications for Windows. UWP applications can be deployed to any Windows device through the Windows Store. Non-UWP applications can be packaged with Desktop Bridge for Windows Store deployment on systems running Windows 10 Anniversary edition or later. Desktop Bridge brings the advantages of publishing applications using a store, such as automatically deploying updates, but does not bring the security or containerisation advantages offered by UWP. 

When deploying UWP applications from third parties, review whether it is a native UWP application or one provided by Desktop Bridge. In most cases, applications with the 'Uses all system resources' permission are Desktop Bridge applications.

Managed deployment

Where possible, applications should be provided to users as part of a managed Windows domain or MDM service, in an environment protected by other security controls such as restricted user accounts and AppLocker.

As an alternative to the Windows Store, application deployment can be controlled on managed devices through enterprise software management solutions such as SCCM. These solutions can be used together to control access to the software and ensure that users are always running the latest version of the UWP application.

Unmanaged deployment

Deployment to unmanaged devices introduces some risk, as it reduces the complexity of attack needed to compromise the software. In this scenario, the following guidelines should be considered:

• Minimise storage of sensitive data on the device.
• In a client-server model, input from the software should not be trusted by the server unless further authentication (such as described in the Secure Windows Application Development – Authentication section) is supplied to verify and authenticate an actual user.
• Obfuscation and similar technologies could be used to increase the effort required to reverse-engineer the software. However, obfuscation should be considered only for this purpose, and should not be relied upon to provide complete protection.