This guidance contains recommendations for the secure development, procurement and deployment of Windows applications. Please familiarise yourself with the Generic application development section before continuing.
- Note that this this guidance also refers to concepts described in the Windows Dev Center documentation and the NCSC End User Devices Security Guidance. We recommend you familiarise yourself with these documents before reading this guidance.
PAGE 14 OF 16
Secure Windows application development
1.1 Datastore hardening
Universal Windows Platform (UWP) applications run in a container, meaning data storage is achieved in a sandboxed environment with its own file system and registry. Additionally, contained applications have restricted access to files on the host system or to data stored by other applications. Application developers do not need to implement anything to take advantage of this secure storage capability.
In cases where it is necessary to share data, UWP provides secure functionality for the following:
- reading specific files on the host operating system as selected by the user
- data sharing between applications
- data storage for the same application across multiple Windows users
Developers should utilise the platform’s native features for those purposes.
Note that while UWP implements the principle of least privilege and ensures its applications cannot access external resources directly, applications with administrator privileges will still be able to read and write data to a UWP application.
1.2 Network protection
The diagram below, taken from the Windows 10 security guidance, illustrates the recommended network configuration for UWP devices handling sensitive data. In summary, a VPN is used to bring device traffic back to the enterprise. Access to internal services is brokered through a reverse proxy server which protects the internal network from attack.
1.3 Authentication
If sensitive data is handled by the application, two-factor authentication should be required when the user logs in. You should integrate Windows Hello into UWP applications to achieve this. Windows Hello provides a biometric system built in to the operating system, and utilises the device’s Trusted Platform Module (TPM) chip for private key generation and storage (if available). This is a recommended option for key management as the TPM protects against several known attacks. Windows Hello can also require a PIN, which is backed by a TPM, if the organisation does not choose to use biometrics.
The Windows Hello two-factor authentication mechanism provides an alternative to smartcards. However, if Windows Hello is unavailable, smartcards can still be used to provide an additional layer of security.
If an application requires user authentication on launch, you should also implement additional checks for when the application has been backgrounded, or its use has been suspended for a length of time. This is necessary to ensure that the current user is still the authenticated user that launched the application. Where two-factor authentication has in place for the session, it would not be user-friendly to require additional two-factor authentication each time the user returns.
For authentication provided by an online identity provider, Single Sign-On (SSO) authentication should be enabled with the use of the Web Authentication Broker APIs native to UWP.
1.4 Secure data storage
Data-at-rest should be protected with use of the encryption and hashing APIs provided by UWP:
- The
SymmetricKeyAlgorithmProviderandAsymmetricKeyAlgorithmProviderclasses should be used to implement encryption. - The
CryptographicEngineclass provides encryption, decryption, digital signing and signature verification capabilities. - The
Security.Cryptography.DataProtection.DataProtectioclass should be used to encrypt and decrypt stored local data.
nProvider
UWP provides a range of functionality with built-in support for use of a device’s Trusted Platform Module (TPM), which protects against a range of attacks. Data protected by a TPM is very difficult for an attacker to access. The following TPM based functionality can be used to store data securely:
- Platform Crypto Provider gives access to robust cryptography schemes, including those that are backed by the TPM. It can be used to securely store data on the device.
- Windows Hello has integrated TPM support and can be used to authenticate and validate users for access to sensitive datastores.
Cryptographic keys and sensitive data should not be stored on the device unless they are stored using a TPM via a UWP feature such as those listed above.
When storing credentials, the Credential Locker feature should be used as it prevents other UWP applications from accessing them. Note that non-UWP applications and elevated users are able to access credentials within the Credential Locker, so for increased protection they could be encrypted before being stored. Credential Locker documentation details the following best practices for its use:
- only use the credential locker for passwords and not for data blobs
- never store credentials in plain-text using app data or roaming settings
- only save passwords in the credential locker if the user has:
a) successfully signed in
b) opted to save passwords
1.5 Server-side controls
Applications storing credentials should have robust server-side control procedures in place to revoke credentials or data stored on the device if it's compromised. If credentials are stored using Credential Locker, they can be deleted from all connected devices by using the PasswordVault.Remove functionality.
1.6 Secure data transmission
In order to transmit sensitive data securely, Windows applications should conform to the following:
For TLS connections, certificate pinning to known organisation services should be enforced.
- Encrypt any Websocket connections using the wss: URI scheme.
- All HTTP or HTTPS connections should use the Web.Http API.
- Note that because UWP applications run in a contained environment, issuer certificates to be used for validation are stored in an isolated cache within the container; as a result, you do not need to do anything to store issuer certificates securely.
1.7 Application security
In order to prevent potential memory corruption vulnerabilities and protect against reverse engineering, Windows applications should conform to the following:
- The application should be compiled using the latest supported security flags.
- The application should be compiled in release mode with all debug information stripped from the binaries.
- When applications are updated, the new version should target the latest SDK version.
1.8 General security recommendations
The following additional behaviours can increase the overall security of an application:
- Applications should minimise the amount of sensitive data stored on the device, retrieving data from the server when needed over a secure connection, and erase it when it is no longer required.
- Applications that require authentication on application launch should also request this authentication credential when returning back into the foreground after previously being backgrounded by a user allowing for a small grace period.
PAGE 15 OF 16
Questions for application developers
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 gain confidence that a UWP application stores sensitive data in a secure manner:
2.2 Secure data transmission
The following question will help you gain confidence that a UWP application transmits sensitive data securely:
2.3 IPC mechanisms
The following question will help you gain confidence that a UWP application shares sensitive data securely:
2.4 Binary protection
The following questions will help you gain confidence that a UWP application protects its data within a binary:
2.5 Server side controls
The following questions will help you gain confidence that a UWP application protects its data on the server side:
PAGE 16 OF 16
Secure deployment of Windows application
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.
