Mobile app security certification in the works


15 May 2016

If a mobile phone user is accessing an app to find out bus arrival times, why would the phone need to get his account and password information? If an app needs to invoke an API or LIB/SDK for a specific function, does it check to see if the kit is malicious? If the phone is sending data to the cloud, is the channel encrypted?

Privilege misuse, API/LIB native risk and connection encryption are some facets of mobile security examined by the Cloud Security Alliance (CSA) in a white paper on its Mobile Application Security Testing Initiative, which seeks to create a more secure cloud ecosystem to protect mobile applications. 

“We have reason to believe that the mobile story is very important as we can see that most applications today that are connected to the cloud are driven through the mobile phone,” said Aloysius Cheang, executive vice president of CSA Asia Pacific, in his opening address at the CSA APAC Summit 2016. “This is especially true for countries with a higher penetration rate in mobile phones compared with desktops.”

The paper will be used as the basis for developing the new CSA STAR (Security, Trust and Assurance Registry) Mobile testing and certification scheme for mobile applications. For CSA, this signifies a departure from the process-focused approach of its current CSA STAR certification schemes to device/appliance-focused testing, said Cheang.

In its report, CSA identifies eight facets of mobile security risks which it says represents the majority of problems that are present during the development phase. These are grouped into four categories – privacy handling, native security, protection requirement and execution context.

Privilege misuse is an example of a risk associated with privacy handling . It occurs when an app is developed in such a way that it accesses privileged information excessively.

Another example is improper information disclosure, where an app developer may maliciously or carelessly expose user credentials or hardware and software information, or exchange the information with another app. This disclosure comes mainly from improper coding at the development phase rather than from improper usage of the app or mobile device.

The API/LIB native risk is an example of a native security issue that presents itself when an app that is being developed needs to invoke an API or LIB/SDK at the time of coding to achieve a specific functionality, and it does this without proper validation of the kit.

Another example if a native security issue is app collusion, where some apps are designed to pass information to other apps beyond their declared scope. They may also be programmed to remain in a static monitoring mode to receive unauthorised information.  Such collusion activities can lead to data exfiltration, said the CSA report.

Under the protection requirement, one of the areas covered is encryption strength. The vast majority of app functions involves sending data to a cloud server or receiving data from it, noted CSA in its report. “Whether or not complete encryption is done over the transmission protocol channel is a very fundamental mechanism to avoid any peeking or stealing,” it said. In the vetting process, therefore, one of the basic security requirements that the CSA STAR Mobile certification will look into is whether encryption is enabled when the app connects to the cloud or the backend.

Under execution context, the CSA white paper discusses the issue of power consumption, which Cheang described as being “very important in the security of any application". “Power analysis is a method that is proven to be effective in cracking passwords,” he said. It facilities credentials hacking and enables devices to be tracked by monitoring how much power has been used over a certain time.

However, CSA noted that mobile device power consumption is sometimes overlooked during the app development or execution phase. As a result, when the app is installed on the device, the battery drains quickly to an unusable state. The safer way would be to confirm the app’s power consumption in order to determine if the operation of the mobile device will be hindered when it is installed. 

CSA has also outlined the technical vetting process for each of the security items discussed in the paper. Vetting will involve the use of an automated testing tool or manual inspection to detect any problem associated with an app during its native development that could put the user’s mobile device and information at risk. The aim is to reduce the risk of app data exfiltration or theft, said CSA. It could also help to alleviate concerns over unknown app risks and enhance the security of mobile apps for enterprise use.

Under the vetting process, there are three levels of assurance. Level C indicates that there are some areas of concern and a warning is issued. Level B is an escalation of Level C violations and will require the apps to be modified and resubmitted for vetting. With Level A, the app is judged to be a malicious development and is placed on a black list.