Application development

Data storage APIs

• You should not store sensitive information on a device when it's not required. If it must be stored on a device, make use of any native data storage protection APIs available on the platform.
• Make a model of the data flow in and out of the device, taking into consideration realistic threats that the system (and its users) may encounter. Most platforms provide documented APIs that allow data to be stored with different levels of protection.
• Always encrypt sensitive information when stored, protected by an authentication mechanism such as a passcode or platform-specific equivalent. When the sensitive data is no longer required on the device, it should be securely removed.
• Ensure the applications allows administrators to delete sensitive data from devices if they are compromised or lost.

Cryptography

• Secure implementation of cryptographic functions requires significant effort to properly design and verify, so wherever possible use native capabilities available on the platform.
• If using non-native cryptographic schemes, ensure they are reviewed and tested by third party experts.
• Storing cryptographic keys on the device will reduce the effectiveness of an additional cryptographic layer (as keys stored locally could be recovered from the device). Storing the keys on a remote server would prevent an attacker with physical access to the device from retrieving them. Users should be required to authenticate to the server. Alternately, you can use TPMs (trusted platform modules) and secure enclaves to improve the security of stored keys.

Data access authorisation

• Store sensitive information securely, and hide it from the user until they have been authenticated (and authorised) to view it.
• Perform user authentication using the native platform mechanisms, with each account being linked to an individual.
• Where practical, manage user accounts centrally.
• When the application has lost focus (or been backgrounded for a short amount of time), the authentication process should be repeated to ensure the identity or permissions of the current user have not changed.

Secure data transmission

• Send any sensitive information transferred between device and server using an appropriate encryption mechanism. All modern platforms have built-in support for transport layer security (TLS), which is the NCSC's preferred option.
• Restrict supported ciphers on both ends of the communication, so that only strong ciphers may be used. Take additional steps to maximise the security of the data connection, such as using certificate pinning to ensure the application connects to a host with a known, trusted certificate.
• Never send sensitive data over an insecure or unencrypted connection, and where possible non-sensitive data should also be sent over a secure connection.
• Alert the user if any suspicious attributes are detected that indicate the secure communication channel is under attack. In this case, the connection should be denied until a verified secure channel is available.

Session handling

• Session handling requires appropriate controls to be placed on the backend server to which the application connects.
• Ensure the backend server treats the application (and its user) as untrusted, until they can provide appropriate authentication.
• Ensure that sessions timeout periodically and require the user or application to repeat the authentication process. 

Modern platforms typically avoid compiling applications to native code, instead preferring to use an intermediate language running in a container. However, it is possible, and sometimes necessary, to include native code components. As a developer you should be aware of the security differences between native and managed code. Principally, native code does not provide the same protections against memory mismanagement issues, such as buffer overflows and use-after-freevulnerabilities.

Stack protection

• Compile native code portions of the application to take advantage of any protection mechanisms that are available on the platform.
• Enable features such as Address Space Layout Randomisation (ASLR) and Stack Canaries during compilation in order to make the application more difficult to exploit. However, these should only be used to increase the effort needed to exploit vulnerabilities, and should not be solely relied upon to prevent exploitation.

Code obfuscation

You can take steps to make your applications more difficult to reverse engineer, but it's important that applications remain secure even when the entire system is understood by an attacker. As such, obfuscation techniques should only be considered to prevent the reverse engineering of technologies to safeguard (for example) intellectual property, and not to provide a robust security system. Even so, you can use obfuscation of both native and managed code to make reverse engineering attempts more difficult. This is also likely to increase the effort required for attackers to understand how to attack and break the application’s security model.

Jailbreak and root detection

Jailbroken or rooted devices are a threat to sensitive data they contain. As a method of hardening the application, consider implementing checks to detect if the device has been compromised. Detection will always be subject to circumvention by a determined attacker, however tests for common jailbreak and rooting methods allow for the application to take appropriate steps, such as alerting the user, or preventing the device from processing sensitive information.

You might be considering deploying third party applications on the same device as applications that handle sensitive data. The primary concerns here are:

• protecting the enterprise network infrastructure from attack via the third party applications
• preventing data from leaking from a sensitive datastore into a third party application

Modern platforms have built-in support for segregation of applications and users, which you should use wherever possible.

As the behaviour of third party applications cannot normally be modified, protection has to be provided elsewhere, via network protections and appropriate use of data-stores. Where possible, the developers of any third party applications should be approached in order to gain a deeper understanding of their product.

Applications that are likely to:

• be sources of data leaks
• track user movements
• interfere with other applications

 - should not be installed. If software must be used despite security concerns that cannot be mitigated with technical controls, users should be given training on how best to manage the risk.