Application development

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.