CSA Mobile Application Security Testing Project 「CSA Mobile APP Security Testing and Mobile APP...

CSA Mobile Application Security Testing Project

© Copyright 2015 Cloud Security Alliance. All rights reserved. 1

ACKNOWLEDGMENTS (In alphabetical order) Special Thanks (TBD) Managing Editor / Researcher (TBD) Design/Editing (TBD)


Summary Mobile applications have not only become indispensable to modern life, but have also been part of all organizations. With the emergence of cloud computing technology, organizational reinforcement is needed to adapt to the massive change. Cloud computing enables realtime use of applications, by which it offers enterprise the enormous flexibility. Accompanied by the convenience; with the inclusion of applications, security problems result from the lack of transparency and present challenges to risk management. The goal of the project strives to create a more secured cloud ecosystem to protect mobile applications. Engineering methods are established by system protection and applied to structure, design testing, and review of applications. These assist in integrations and introduce security, quality control, and compliable evidence in mobile application development and management. The project wishes to conduct more research in mobile application security vetting; the efforts help organizations and individuals reduce the possible risk exposures and security threat in using mobile applications.


Project responsibility Initial physical action scope may include: create an assessment and certification scheme white paper based on NIST special publication 800163:Vetting mobile applications set up a vetting plan for maturity model and mobile apps security set up a vetting plan for mobile apps allocate resources to resolve potential security problems or certification period incidents

Scope The app security testing and vetting process uses both static and dynamic analysis to analyze the application. The testing and vetting process covers permissions, exposed communications, potentially dangerous functionality, application collusion, obfuscation, excessive power consumption and traditional software vulnerabilities. The testing covers the internal communications such as debug flag and activities and external communication such as GPS, NFC access as well as checking the links that is written in the source code. In addition to security testing and vetting, the project will also develop processes and procedures for security incidence response.


Table of Contents 1. Introduction 1.1 Purpose and Scope 1.2 Initial Normative References 1.3 Preliminary Study 1.4 Content Structure 2. Mobile Apps Vetting Issues from Life Cycle Perspective 2.1 Mobile Computing and Apps Security Challenge 2.2 3rd Party App Derived Security Issues 3. Mobile Apps Development Management 4. Mobile Apps Coding and Audit Management Security Issues 4.1 Intentional Misconduct 4.2 Negligence 4.3 Native Problem 5. Mobile App Vetting Process 5.1 Mobile App Vetting Scheme 5.2 Mobile App Security Items 5.2.1 Privacy Handling Privilege Misuse 5.2.2 Privacy Handling Improper Information Disclosure 5.2.3 Native Security API/Library Native Risk 5.2.4 Native Security App Collusion Activity 5.2.5 Native Security Development Obfuscation Concern 5.2.6 Protection Requirement Connection Encryption Strength 5.2.7 Protection Requirement Data Storage Status 5.2.8 Execution Environment Power Consumption Problem 5.2.9 APP Development Security Item Classification 5.3 Mobile App Management Life Cycle


5.4 Technological Vetting Process and Procedure Basic Definition Requirements and Objectives

5.5 Technological Vetting Process and Procedure Vetting Content Classifying and Rating

5.6 Technological Vetting Process and Procedure Vetting Process and Flow 5.7 Management Cycle of Vetting Process and Procedure


Infrastructure and Resource Requirement The project is made up of CSA volunteers; there will be one steering committee and a joint chair. The project will require typical project management, online workspace and technical writing assistance. Task Group Phone Conference and Facetoface Talk The project will hold the phone conference at least once per month, with the presence of chair or his agent. If the chair does not attend the conference, the agent should be fully authorized on behalf of the principal. Facetoface meeting will be held annually at agreed location. Contact/Communication The project communications will be done by phone and online every two weeks. SubWorking Group Specialized formed subworking groups are carried out or planned any associated campaign by corresponding domain experts in order to increase the opportunity for further understanding or researches. Such subworking groups should report directly to FWG. The project can grant cloud community and other CSA working groups the sharing of resources, assist the timely completion of the project and any other project tasks that need support or kickoff. Peer Review/Advisory We will seek CSA’s help in reaching out to peers for reviewing our charter and other documented activities of the initiative. Deliverables/Activities Q3 2015 Deliverables: Charter Deliverables: Project Plan Activities: Project Execution Q4 2015 Activities: Project Execution Deliverables: Mobile Application Vetting Whitepaper Q2 2016 Deliverable: Proposed Application Vetting Scheme Project Term


The project team will operate until the third quarter of 2016 with the valid certificate; decision of certificate renewal will be made at the time.


1 Introduction

1.1 Purpose and Scope of White Paper CSA MAST creates a conformable 「Mobile APP Security Testing and Vetting」in order to assist Mobile App developers in their secure development or use to ensure the secure development quality of Mobile Apps. CSA MAST Working Group, a CSA subordinate group, establishes 「CSA Mobile APP Security Testing and Mobile APP Security Vetting Certification () The current version uses Special Publication 800163 as the basis of consideration in determining the classification level for basic security vetting specifications. Security classification can be divided into three categories. Level C has 40 items, any single violation results in one point deduction. Consecutive violations of certain Level C items will be escalated to become Level B violation. Same rule applies to Level A similarly. The vetting benchmark provides the third party institution related App security vetting, vetting result analysis, and security risk assessment for mobile Apps and their corresponding security level rating, by which mobile app security level are perfected. The vetting standard complies with 「CSA MAST Mobile APP Security Testing and Vetting」to provide the necessary security vetting items and benchmarks for mobile apps. This vetting standard items can be applied to the common functionalities of mobile app of nonspecific domain and mobile app to ensure the tested mobile app’s conformance to the「Mobile APP Basic Information Security Specifications」security classification and corresponding security requirement. Differentiations between the information security specification required by the domain functionalities of specific domain mobile apps and the vetting standard are suggested to be researched and written in the later revised versions.

1.2 Initial Normative References

NISTSP800163/142/115…series

App Security Issues, Basic Level – Related Issues

App Vetting Related Basic Modes

OWASP Mobile Security Project

Top Ten Mobile Risks

Information Security Development Considerations


Mobile Storage and Connection Security Issues

MAST Working Group Professional Practice Member Meeting

Regional Mobile Information Security Discussion Issues

Mobile Development Technology Discussions

CSAChina Testing Security Requirements

Technical requirements for security capability of smart mobile terminal

Mobile Security Level Determination

Mobile Security Item Basics

IDB/ROC APP Vetting Specifications (Interface)

Fundamental Industrial Security Development Directions

Regional Developer Security Considerations

ISO27034 Creating Standards for Secure Software Programming Process and Framework

1.3 Preliminary Study According to the Data Flow observation of mobile system in the course of its use, we found the mobile system, during execution, generally deals with the privacy for the vulnerability or risk resulting from APP execution process. Avoiding the improper disclosure of privacy information should be the basic requirement. Tracing back to the time of development, determine whether it is out of malice or negligence, for the use of the wrong library or activities concealed from the user. The majority of Apps, during execution, are required to connect to certain website or cloud backend; one very critical aspect of Data Flow is whether data communication encryption or their associated protection have been taken into account during development phase so as not to cause any faults. Owing to the fact that Apps are installed and used in mobile hardware terminal device following the design, power consumption related usage factors need to be taken into account for their frequent portable uses. As a result, whether excessive power consumption could lead to trouble


and fault in the use of an App after its mobile terminal device installation is one of the critical consideration factors during development phase. The general directions of vulnerabilities and risks, after compared again with the initial normative references against the various mobile security perspectives, are used to establish the technical requirements. We come up with the summarization in accordance with the drills as in practice based on Initial Normative References and include higher risk development items into four categories. Each level has its own focused risks that require attentions; a total of eight items are included in the four categories as follows: — Privacy handling • Privilege misuse • Information improper disclosure — Native Problem • API/LIB Native Risk • APP collusion • Development Obfuscation Concern — Protection Requirement • Connection Encryption Strength • Data Storage Status — Execution Environment • Power Consumption Problem

These faceted classifications primarily focus on defining the vulnerabilities generated by data protection, program coding, library calls, environmental setup, etc. processes and their subsequent execution results, intentionally or unintentionally, during App development. Regardless these vulnerabilities are created out of intention or negligence, significant infringement or loss result from the actual use of the mobile apps. Therefore, the standard vetting study of this white paper will conduct the subsequent related App development security guidance based on the eight faceted categories. In addition, the security concerns of the vast majority of the Apps, with very few exceptions are about the hardware compatibilities, are generated during the development. These problems, whether they are committed intentionally or negligently, are essentially created during the app programming. Therefore the app security vetting revealed in this white paper determines its direction against those negligence or intentional conduct made during native development. The


definitions help at least clarify the following related vetting descriptions and understand the problems happened by vetting against the native development phase.

1.4 Content Structure Vetting will be conducted over the Target Items based on the nineteen security problem items under eight problem categories resolving from four privacy handling, native security, protection requirement, and execution environment facets. These Vetting Target Items do not represent all the app security development problems; however, the white paper plans to conduct the Baseline Vetting against the app security development problem items with more threat, publicity, or obviousness. In determining the subsequent vetting method, audit requirement required by app development phase is also taken care of. We call such basic auditing requirement The Requirement of Management in App Develop Auditing. After the basic auditing requirement decision, vetting result will be conducted for Level determination, level rating, scoring and certification based on Vetting Baseline.

2. Mobile Apps Vetting Issues from Life Cycle Perspective

2.1 Mobile Computing and Apps Security Challenge Conveniently portable and flexible, the smartphone and tablet mobile devices provide functional characteristics such as sending/receiving emails, document storage, presentation browsing, remote access of information, and even remotely access other network equipment. They increase productivity and efficiency of mobile office environment at the expense of bringing the new security threats. The ever increasing functions of smart phones have gradually replaced desktop computers in the operations for corporate business use, coupled with the fact that individual users have stored their files and photos in cell phones, information security problems extending from smartphones have become an important issue. Additional to the business use, individual user’s privacy risks are often exposed under the threat of various malicious malware attacks. Today’s cell phone is not only a phone; it can also turn into an individual’s electronic payment wallet, electronic identity, phonebook, and business data storage location. With all the above features of our mobile devices, sensitive information leakage risk result if either because the devices are lost or stolen or because the information are stolen or leaked by APPs maliciously. Moreover, many users depend a lot on App features and authorize App developers to look up the user


profile information, personal photos, and contact information without even checking on the App terms of service, according to statistics. Many mobile phone users fail to read the app’s terms and conditions in detail and agree to the clauses when downloading the paid or free apps. Such user action could grant the app developer the permissions to search for information of the cell phone or reveal the whereabouts of the user. The mobile device ecology consist of three major elements: operating system, hardware, and App. Current operating system ecology is mainly composed of iOS, Android, and Windows with a small fraction. Operating systems are bundled with hardware for manufacturing or are preloaded before pushed to the market. Such manufacturing and preloading have very low probability in hardware problem and enhance the security with the revision of the operating system. On the contrary, App has a simple and fastpaced development environment resulting from the openly and powerful promotion by the system vendors. Millions, if not more, of people got involved in the development, from which ecology the App development security consideration has not been emphasized by every developer or user. The above mentioned risk and leakage incidents occur frequently, whether made negligently or maliciously, to the extent that endangers the normal business activities.

2.2 3rd Party App Derived Security Issues Up until now, app development and use have not been only the routine entertainment use purpose for general users but also have become the public or internal service tools and interfaces for many business or big organizations. Therefore, the more complex need transforms the extended security problem from a simple computer virus problem into an information security stealing or leakage problem. App execution stage has been the resulting stage for the birth of the problems while the true risks are really found during the development stage, from which determines the level of risk for the mobile data security of the mobile device where app is installed. During the development stage, third party library or API are referenced additional to the original NDK/SDK to attain the mobile computing features. In general, the security problem of these libraries or APIs can only be known by inquiry or the variation functionalities generated during execution rather than being confirmed prior to the use. Therefore, the existence of security guidance or related security details in development stage is the keys to overcome these security challenge issues.


3 Mobile APPs Development Management Generally speaking, mobile app development are conducted through several procedures: requirement confirmation, internal technical discussions and work division, code writing, quality assurance, online testing, release (launching), and version revision for a total of seven major steps. These steps appear in a variety of different mobile app development methodologies and make up the basic development pieces. Among these steps, in addition to the general software engineering management cycle, special attentions need to be paid on the following development management principles: Environment management: Mobile app development process must cope with the fact that the finished product will have to be installed to different versions of operating systems and different configurations of mobile terminal devices (usually cell phones or tablets). If the complex situations are ignored, developing and testing using currently owned simple environment could result in incompatible development result or security information leakage concern. Version management: Same as the traditional software development, app development is usually the finally summarized and compiled result of teamwork development. Additionally, mobile environment app development have more issues concerning, i.e. connection scheme, offline processing, data overwriting, surrounding detection, etc., therefore if any divided segment shares functionally coherent coding or finished version control with other segments has an influence on whether such app could have security concern due to incomplete transition. Native kit management: Many app development teams in practice need to invoke the already developed kit components or part of the modules in developing certain functions. Most of the time the app engineers directly download other people’s finished kits from Internet and put into use without conducting any kit management; meanwhile, a good number of the teams have no way of verifying such kits or components about whether they are secure or without being embedded anything improper maliciously or negligently. At the same time, native kits should be assisted in their creation and management by corresponding groups or units to put an end to any security concern for auditing and vetting management. Mobile App development, beside its staff development skills, has to allocate quality control and auditing manpower in development stage and corresponding vetting management. More complicated than traditional software development is the uncertainty present regarding the stability in developing iOS or Android programs because of the openness of mobile operating systems and languages. On the other hand, security breach concern caused by system must


take corresponding Internet security factor into consideration rather than only the problem of how to write the code entering development stage.

4. Mobile Apps Coding and Audit Management Security Issues We mentioned in the previous chapter the essential principle of mobile apps development management is nothing more than the extension of security and audit consideration procedure. The development management starts from the process that include: requirement confirmation, internal technical discussions and task division, program writing, quality assurance, online testing, release, and version change and sum up into security issue management that are composed of programming process and audit act. Compared to general project management and implementation of software engineering paradigm, mobile app development and auditing require more complex management security issue. When this issue is being addressed; most of the time, we will arrange the native status of development (i.e. security and audit critical acts of development). Prior to this, we first discuss about why the security problems occur during the development? Security problems resulting from development stage can be attributed mainly to mobile app development’s few restrictions and sloppy existing kit invocation from programs. Plus the fact that the inconsistency in quality of developers; consequently, security problem result from the above two factors. In summary, causes of the problem are explained as below:

4.1 Intentional Misconduct Intentional SQL Injection/APT/BOT Intentionally place computer virus, attack type code, theft type code, etc. in coding purely on specific purpose to attain specific unidentified goal. Besides the fact that this type of intention could be associated to a team’s intentional act, another possibility is because of the developer’s own interest or showing off act. Malicious channel leakage or weakness function injections Similar to the previous factor, intentionally inject weakened functions or data leakage channel users unable to detect in code purely on specific purpose to cause security problem to such program.


If API/LIB kit sources required by development are not either managed and provided or version controlled, misuse could result of those infected API/LIBs or faked/disguised during development ones. Although not intentionally, misuse directly or indirectly result in illicit purpose consequence over app development product.

4.2 Negligence Misuse of the obsolete function App developers wrongly use most of the time by referencing the obsolete API/LIB during programming; for example, an engineer uses the Android 2.2 version of library in developing Apps under the Android 5.5 environment. With the fact that such library has been abandoned in new version of operating system, misuse of the obsolete library often causes waste or possible security breach even there may not be any imminent security risk. Misuse of community malware program During the development cycle, an App developer tends to rely on other’s app or web services to produce not entirely selfcontained code. These third party app or web services, over which a developer has no control, can contain malware and can have vulnerabilities at the time of use, the negligence can lead to an app with functional deficiency with operational risk. API/LIB Misuse of API/LIB In practice; for instance, developing an Android App requires the invocation of the Apache.jar library. The problem is that there are many changed versions of Apache.jar on Internet; unawareness of the problem or inability in identifying the right version result in misuse and have the 0day security problem consequence.

4.3 Native Problem APP NDK/SDK NativeProblem This case is less common but could occur occasionally. It refers to the native environment security risk caused by native defect or backdoor found in the use of NDK/SDK that are provided by operating system vendors.


5 Mobile App Vetting Process

5.1 Mobile Apps Vetting Scheme Regarding the App vetting scheme, they are conducted based on the defined security items (described in the following chapters) based on the white paper. The purpose is to inspect if the app has any security problem and concern as listed by the security items. As to the vetting approval, details will be given in different sessions. The paper proposed two mobile app vetting schemes: source code detect and nonsource code detect. It is commonly recognized that provision of app source code is adequate for vetting purpose. Considering the vetting in practice, the app source codes are not available because the involved party may not be app developer. Hence the nonsource code detect is employed to better the vetting coverage. Source code vetting scheme: Vetting is conducted by either the use of tools for code review or manual walking through of the source code. The process need to be in conformance with ISO 17025 regulations (not addressed in this session). Vetting items should be checked one by one according to the security items defined in the white paper. Since the proposed white paper only provides itemized descriptions of the related security item’s definition and its result, the vetting process is conducted without specification using static, dynamic, or the combination of both while fulfilling the vetting requirements. Consistency: The vetting result should clearly identify the conforming security items listed by this white paper. Ambiguous answers that map to two or above security items are not permitted by the vetting process; in such case, the ambiguous vetting result is considered invalid. Comparability: The vetting result must agree with other existing known vetting schemes without any difference. Vetting has to be done against any listed security items. Repeatability: Vetting over the same app using the same tool or manual if the same testing tool or manual process should agree for three consecutive times. Additionally, same problem configuration on two different cell phone app should be found without any difference. Nonsource code vetting scheme: It refers to the adoption of tool to conduct static and dynamic vetting on nonsource executable code iPA or APK. The method should comply with the consistency, comparability, and repeatability requirements. The process also needs to be in conformance with ISO 17025 regulations (not addressed in this session). Vetting items should


be inspected statically and dynamically individually according to the security items defined in the white paper.

5.2 Mobile App Security Items The preceding paragraph has conducted preliminary study and obtained the information regarding the riskprone fourcategory, eightfacet problems during app development. At this point in time, our study aims to collect critical security focuses of the eight facets in more detail; these security focuses will become our consideration and vetting requirement emphases presented by the initial white paper. Our current collected eight facets obtain the relevant notable emphasis mainly from OWASP\NIST 163 and other documents. These focused items are reviewed repeatedly to confirm they are indeed the majority of the insecure App problems that are present during development and occur when used by mobile device users. The reason why these focused items are chosen is because the concern regarding protection, no leakage, normalization, etc. basic development requirements that dataflow process demands. Security standard compliant development framework thus can be established based on these type of requirements. We studied these focused items and list them as below:

5.2.1 Privacy handling Privilege Misuse Privilege misuse: The use of app often have to obtain the account and password or privileges of getting the software and hardware information from user; confirmation whether the access privilege is insufficient or excessive is necessary at such time of use. For examples, there is no need to get “all” the account and password information of the cellphone if the user is simply using the app for bus arrival time. If such an app is developed in a way that uses the privilege excessively, it is referred as a Privilege misuse. Generally speaking, there are three different situations and determination methods on Privilege misuse during development phase: — Improper Raising Up Behavior and Purpose • determine if there is any improper purpose or raising up behavior. — Intentionally concealed privilege use • Determine if there is any concealed privilege use of app development, i.e. to get excessive privilege without declaration message or informing dialog box and prompt message — Selfdefined Privilege by App Developer

• Determine if developers use privileges not permitted by NDK/SDK by creating selfdefined privileges; such acts are conducted by means of sabotage or malicious third party.


5.2.2 Privacy Handling Improper Information Disclosure Message improper disclosure: APP often, without strict development control or audit control management under development, results in the leak or exposure of private or sensitive information associated with the future APP use. App developer sometimes may maliciously or carelessly leak or expose app context address or transmission information to improper destination or exchange information with other app and put the app execution without proper protection, this is called message improper disclosure. The cause of message improper disclosure comes mainly from improper coding at development phase rather than from user improper operation. We conclude that message improper disclosure at code development phase comprises the following situation and determination methods: — Surrounding information improper disclosure

Assess if there is any NFC Physical address, MAC address、bluetooth message、 mobile device GPS location etc. and not limited to the above mentioned and related information is exfiltration or transmit to unknown address or destination during app development.

• Assess if there is any forge on NFC Physical address, MAC address、bluetooth message、mobile device GPS location etc. and not limited to the above mentioned and related information for not authorized usage during app development. — App development issue • Assess if there are proper protection measure to avoid data leakage for sensitive data when perform mobile coding, especially check on Android Activity, Service, Broadcast receiver, Content Provider, or iOS Container view components. • Assess if there is any attribute (feature) information (sensitive or not) created by Activities, Service, Content Provider is exfiltration or transmit to unknown address or destination during app execution. • Assess if there is any intentional collection, leakage or transmission of specific sensitive data on code design with RE or malicious code dependencies.

5.2.3 Native Security – API/LIB Native Risk API/LIB native risk: Apps, during development, often need to invoke API or LIB/SDK at time of coding to achieve a specific functionality purpose because of the need from specific function.


Yet this “malicious kit” can be kit used with risk by lacking proper validation, or kit on black list, or kit contains unexpected and/or malicious functionality; due to oversight or intention, this could cause the API/LIB native problem. Our observation points out, there are 2 major issues with this type of risk, more information and assessment as follows, — API potential risk • determine if there is a call or use of API that is known to be risky to development vendor • determine if the call to API with flaw and may lead to data leakage or without proper data protection • determine if it is a native problem with malicious descriptive instruction — Library potential risk • determine if a call or use of the risky library that has been known to the industry • determine if the library calling scheme is flawed, resulting in unprotected status that is prone to information leakage • determine if there is a library native problem with existence of malicious function(s) — Injection Risk • SQL Injection determine if there is SQL Injection • Command Injection determine if there is Command Injection

5.2.4 Native Security – App Collusion Activity APP Collusion: Some APP when in execution, design to pass information to other App beyond declared scope, or remaining a static monitoring mode to receive unauthorized information, such “Collusion” activities, can lead to data exfiltration and cannot be properly traced. This kind of collusion can be classified as intentionally design to dodge the malicious or systematic behavior to be discovered. In general, there are a few collusion approaches, they are described and explained as follows, —data source/destination collusion •App when in execution, allows other unauthorized app to obtain information regarding the data origin and storage destination •APP when in execution, accesses information from DATA regions generated by other APP — Broadcast receiver component •Broadcast receiver components in pair with collusion for important information — Data Creation/Update/Deletion • App sending instruction or request for execution to create/update/delete database or documentation resources


• Issue instruction or request from app to another app perform create/update/delete of data base or documentation

5.2.5 Native Security Development Obfuscation Concern Development Obfuscation Concern: Employment of the testing or incidentcreating process while in use has taken its toll on significant security risks created by either irrelevant functionality or unpredicted mechanism that is generated by maintenance and testing programs or calls. Viewing from fundamental structure, several obvious problems will become the highlights: — Native code execution obfuscation

•Embedded specific functionalities into the program code and caused the unexpected functionalities during native code execution. — Mapping Call Problem mapping calls are often embedded with control flows that are capable of confusing App and mechanisms that can sabotage privileges. Therefore mapping call determination problems are used to confirm whether the existence of obfuscation in order to decide there is any security problem. — Assembled Code

• Some app code hides its intention by disassemble purposely and assemble afterwards, by which the risks and problems can’t even be detected with sandbox protection. Therefore, understanding the intention of code assembly during development or determining the risk type of the assembly must be done for making the security assessment.

5.2.6 Protection Requirement Connection Encryption Strength Connection encryption strength: The vast majority of apps are capable of connecting to the cloud to perform data access and use its services. These functions involve either sending data to some cloud server or receiving data from it. Whether or not complete encryption is done over transmission protocol or channel during the data transmission process is a very critical fundamental mechanism to avoid any peeking or stealing for app development. Therefore, app vetting regarding if encryption or encrypted channels are enabled when connecting to cloud or backend is the basic security requirement and also one of the important factors in verifying the app security. Connection encryption related strength requirement is the focus of the current security issue, and hence we include the security factors with high priority as follows: —Connection Protection • determine if the app code has taken into account and comes with a connection encryption channel protection mechanism?


• determine if connection protection mechanism is wellknown for it’s weakness point? (e.g. , SSL) —Certificate strength, Multifactor problem

• Whether connection data transmission certificate has better strength? The so called “better strength” should have one of the following: — Advanced Encryption Standard (AES) encryption algorithm, and the key length is at least 128 bits. — Threekey TripleDES encryption algorithm, and the key length is at least 112 bits. — Skipjack encryption algorithm，and the key length is at least 80 bits. — or any encryption algorithm that has the equivalent level of strength is considered to be

having better encryption strength. •if there is a multifactor or at least two factors or more certification mechanism?

5.2.7 Protection Requirement Data Storage Status Data Storage Status: During the app execution, additional to the internet connection, execution result information is usually created. The information can be stored temporarily or longterm on the mobile terminal device. For the security and privacy consideration, protection will be implemented against the stored data. Therefore whether the data storage protection takes into account both security and privacy becomes one of the key indicators for app development security. After comprehensive researches and discussions, data storage configuration security factors include: — Storage scheme and location • Whether storage scheme takes into account the encryption mechanism? • Any concern regarding the improper disclosure for database or file location?

• Any special provision is done for concealing storage location? Is the data stored in an easytosteal or attackprone location? — Sensitive Information Protection

• Whether special security measure is done if the stored information has been classified as Sensitive information? For example, any encryption or data segmentation measure taken to make it hard to identify.

5.2.8 Execution Context Power Consumption • Power Consumption: Some apps, during their development or execution, do not take mobile device power consumption into consideration. The consequence is that the mobile device can’t last long enough and drain its battery to unusable state. The safer way would be to confirm during the development phase the app’s power consumption status after being installed to the


mobile device in order to determine if the normal mobile device operation could be hindered. The summarized security items include : — CPU Utilization Ratio

• An app consumes more power from its CPU use more than average standby or regular mobile device use

• Based on the experiment of 100 normal randomly picked apps of their power consumption characteristics, a standardized method is concludes as: Either Android based Nexus 6 or iOS based iPhone 6, after their full charge, is considered within the normal operating range if the usage of the CPU is not higher than 40% when app is in standby or in use or and the power consumption is not higher than 10% for 5 minute of continuous usage. — I/O issue

• If an app I/O consumes more power consumption than the average mobile device standby or in use • Based on the experiment of 100 normal randomly picked apps of their power consumption

characteristics; a standardized method is concludes as: Either Android based Nexus 6 or iOS based iPhone 6, after their full charge, is considered within the normal operating range if the usage of the CPU is not higher than 10% when app is in standby or is in normal storage, GPS, or communication use.


5.2.9 APP Development Security Item Category Summary

5.3 Mobile Apps Lifecycle Management We have mentioned APP development management in the previous chapter, for this chapter we would like to describe the life cycle management for an app from its development phase to completion, usage and off the shelf (store) phase, especially the topic of security management; and at the same time to provide proper definition for the abovementioned. After integrated study, we concludes the app lifecycle management includes development, audit, launch/release (Store/Market), update, app removal and app deletion phases. The main issues of each phase of the app life cycle compiled as follows — Development : Perform coding and validation/verification functions; besides general project management for program coding, the management focus is to develop the security


management mechanism for secure programs. Security management can be performed by means of kit version control, assurance of program code origin, and security vetting, and so on. — Audit: Perform the quality auditing task before the app is submitted to app store or go online. In addition to performing security vetting once again based on the technical security items; simulation of execution needs to be executed as well as the confirmation of environment installation settings. The management focus of the phase falls is regarding for security vetting and online risk forensics. — Launch/Release: Perform app launch management for submission to public app store (Google Play, Apple APP Store) or Inhouse launching. Managing of the phase is about app store launch application and maintenance, checking on the number of download and usage status feedbacks, and so on. The management focus is about the assurance issues of secure uses. — Update : Conduct app version update operations; the phase mainly handles newlyadded or modified app functionalities. Better service quality for customer is provided by app revision and launch. The management focus is how long security item vetting is required following the app based on this white paper. — App Removal: If apps have to be removed from the app store for some reason(s), Google Play or APP Store rules shall be followed. The removed apps should close or cancel related services; such as advertisement ID, online payment type of service, etc. to avoid unnecessary trouble. — App Data Deletion: To avoid unnecessary trouble for the user, the uninstall function or the complete removal of both app and the data following its execution should be included in the time of the app design. Although most of the apps offer such functionality; oftentimes, data still remain without being completed removed in practice.

5.4 Technical vetting steps and process definition, requirement and purpose Vetting Definition Use of automated testing tool or manual inspection to detect if there is any possibility and problem associated with app during its native development that could“endanger”the user information or mobile terminal device. Identify malicious code or development negligence risk hidden in Android APK & iOS iPA program and follow the security items as defined in the white paper in conducting vetting.


Vetting Requirement As stated in the previous sessions, app vetting consists of source code and nonsource code types in terms of its source origin; refer to the definitions and descriptions as in Section 5.1 “Mobile Apps vetting Scheme” for vetting requirements. Vetting Purpose Apply vetting to reduce risk of app data exfiltration or theft on mobile device use. It can also be used to alleviate the unknown app risk concern and enhance the security level for business use.

5.5 Technical Vetting Steps and Procedure – Vetting Content Categories and Rating Methods

We define the mobile vetting as 3 level of assurance, which is category, facets of each category, and issues/items for each facet.


— Level C: Concern and warning are issued. Any single vetting security item violation is considered as a Level C problem, with approval still being given under some degree of problem level. Consecutive violations of certain Level C items are escalated to become a Level B violation, e.g., violations of C1, C2, and C3 will become a B1 violation, and so on. — Level B: Modify and submit again for vetting. Any single violation of vetting security items is a Level B violation, with possible approval after its submission for vetting. Consecutive violations of certain Level B items are escalated to become a Level A violation, e.g., violations of B1, B2 will become a A1 violation, and so on. — Level A: Abandon. App has to be abandoned and placed on a blacklist. Any single violation of vetting security items is a Level A violation. Basically the Level A violation from vetting result will be judged as a malicious development with such app invalidated and placed on a blacklist.


5.6 Technical Vetting Steps and Procedure – Vetting Steps and Process


5.7 Management Cycle of Vetting Steps and Procedures

Development: Perform coding and validation/verification functions; besides general project management for program coding, the management focus is to develop the security management mechanism for secure programs. Security management can be performed by means of kit version control, assurance of program code origin, and security vetting, and so on.

Whether kit version management is conducted Program code origin assurance done by designated person Whether continuous security vetting management is conducted during app development

Audit: Perform the quality auditing task before the app is submitted to app store or go online. In addition to performing security vetting once again based on the technical security items; simulation of execution needs to be executed as well as the confirmation of environment installation settings. The management focus of the phase falls is regarding for security vetting and online risk forensics.

Whether a standardized security vetting is applied, e.g., CSA MAST. Whether the vetting result is fed back to the system for future development revision or

other audit assurance Launch/Release: Perform app launch management for submission to public app store (Google Play, Apple APP Store) or Inhouse launching. Managing of the phase is about app store launch application and maintenance, checking on the number of download and usage status feedbacks, and so on. The management focus is about the assurance issues of secure uses.


version control during the app store launch; Google Play & App Store both have strict rules to follow. Check if there is assurance management of version control and content procedure for inhouse apps? Update : Conduct app version update operations; the phase mainly handles newlyadded or modified app functionalities. Better service quality for customer is provided by app revision and launch. The management focus is how long security item vetting is required following the app based on this white paper.

Whether the internal revision process is established; and if version change and modified functionalities are complete based on meeting minutes .

Whether all the revisions follow the launch rules App Removal : If apps have to be removed from the app store for some reason(s), Google Play or APP Store rules shall be followed. The removed apps should close or cancel related services; such as advertisement ID, online payment type of service, etc. to avoid unnecessary trouble.

Verify if additional services (ad. ID, online payment, etc.) of the app have been cancelled or closed; records must be kept for later assurance.

App Data Deletion: To avoid unnecessary trouble for the user, the uninstall function or the complete removal of both app and the data following its execution should be included in the time of the app design. Although most of the apps offer such functionality; oftentimes, data still remain without being completed removed in practice.

Audit personnel should inspect nonperiodically all the launched app in use to see, after app installation, if its data still remains in the mobile device that installed such app.

Whether there is a mechanism that informs the cloud administrator about the app data left in the cloud if such data is only for personal use rather than public service purpose.


CSA Mobile Application Security Testing Project 「CSA Mobile APP Security Testing and Mobile APP...

Documents

Transcript of CSA Mobile Application Security Testing Project 「CSA Mobile APP Security Testing and Mobile APP...