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 SymmetricKeyAlgorithmProvider and AsymmetricKeyAlgorithmProvider classes should be used to implement encryption.
• The CryptographicEngine class provides encryption, decryption, digital signing and signature verification capabilities.
• The Security.Cryptography.DataProtection.DataProtectionProvider class should be used to encrypt and decrypt stored local data.

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 into the foreground after previously being backgrounded by a user allowing for a small grace period.