Revision as of 07:56, 25 May 2011

Top 10 mobile controls and design principles

1. Identify and protect sensitive data on the mobile device

Risks: Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).

Store sensitive data on the server instead of client-end device, if possible.

Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.

Do not store/cache sensitive data on the removable media

Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)

Automatically delete data from device which is no longer required

Be aware of caches and temporary storage as a possible leakage channel

Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device

Schedule deletion according to time, rather than on a push-pop basis.

Use secure deletion procedures.

Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)

Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).

In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials

Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)

Password credentials should be marked to avoid being copied to backups

Ensure passwords and keys are not visible in cache or logs

We recommend that one-time codes (OTP) should not be forwarded via SMS. Consider using HTTPS and protect it on the device (Zitmo)... //or can we make a better rec on this?

Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )

Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)

For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...

Do not disable or ignore the SSL chain validation.

SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?

Consider use of GSM encryption-on flags to verify that GSM encryption is on.

Provide appropriate trust cues for linking to unknown third party applications.

4. Keep the back-end API and mobile platform secure
//Downgrade this control
Risks: Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

Web Services/ SOAP/ REST , security best practices (placeholder)

Input validation

Do not use a generic shared secret for integration to backend (like embedded password in code)

Use authentication that ties back to the end user identity (rather than the device identity)

Ensure authorization controls are done correctly in the backend APIs.

Ensure that the backend platform is running on a hardened configuration with latest security patches

Risks:
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

User authentication must be based on user's credentials.

Use unpredictable session identifier with high entropy

Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.

Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).

6. Ensure strong vulnerability and patch management in place
//Downgrade and mix with #4

All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.

Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.

Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.

Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

7. Employ the secure coding/development practices
// Let's try to get rid of it and move the recommendation
//Risk? Isn't this circular? I don't understand the principle here.

Input Validation and Output Encoding

Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)

Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.

Run with the minimum privilege required for the application on the operating system.

Don't authorize code/app to execute with root privilege

Always perform testing as a standard user (rather than a privileged user)

Least privilege. Be aware of privileges granted by default by API's and disable them.

10. Enforce higher security posture on the device for sensitive apps

If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.

Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

Candidates (to be merged if needed)

11. No secrets in code/binary

Risk: Mobile application binaries can be easily reverse engineered.

Do not store any passwords or secrets in the application binary

12. Protect your application from other malicious applications on the device

Risk: User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

(?? What guidelines could be provided to developers)

User education on using due diligence while installing third party applications on mobile devices