Mobile App Testing. Mobile App Testing. Seite 1 von 10

10  Download (0)

Full text


1 Security and Insecurity of mobile Applications ... 3

1.1 App-Security in official App Stores ... 3

1.2 mediaTest digital App Security Audits ... 3

1.2.1 Testing Approach ... 4

1.2.2 Test Criteria ... 4

1.2.3 Evaluation of Test Results ... 5

2 Using Apps in a Corporate Environment ... 8



Security and Insecurity of mobile Applications

The market for mobile Applications is exploding. Today, 900.000 iOS and 800.000 Androids are available in the official App Stores and these numbers are growing rapidly. Having this large amount of software available it is beyond all questions that a mobile device which is used in a corporate context needs to be secured against potential loss or abuse of sensitive data which includes for instance:

Unauthorized access to sensitive corporate, payment, calendar or contact data Theft or abuse of sensitive correspondence

Generation of movement profiles Industrial spying

Malware Etc.

There are countless possible risk scenarios existing and any company has particular security demands and requirements. In terms of securing mobile devices and regulating the App usage companies should define specific risk potentials in an early stage in order to implement an App-Whitelist that fits the specific security requirements. Just to name a few examples:

How do I deal with geo-data? This can be used to generate movement profiles which makes employees and executives unconsciously transparent people being more easy to manipulate or abuse

Is it ok that Apps spread my device codes making it possible to identify users without logins or similar? This opens the door for targeted virus attacks for instance as it allows abusing or device specific distinction of content.

Access rights: How many rights do I tolerate? Access to Calendar? Contact Data? Mail? This data can possibly be transmitted to unauthorized third parties.

Do I allow cloud services? This goes along with losing data sovereignty and allowing third parties handling with corporate data.


App-Security in official App Stores

Apple: It takes up to three weeks before Apple makes an App available to its community. According to Apple, this time is being used for App testing to ensure that Apps available at iTunes are safe and noncritical in terms of data privacy and security. This is offset by the fact that about 40% of all Apps tested by mTd show critical behavior and/or security vulnerabilities (that are also not allowed by Apple itself).

Google: Google is following a different strategy. All Apps are instantly approved an available for download. It’s up to the community to separate the good from the bad, either by poor ratings or by not using an App.

In terms of security both strategies are critical – Apple gives the impression of security that in fact does not exist and Google has not yet implemented any security regulations.


mediaTest digital App Security Audits

In order to provide companies and end user with security information required for making valid decisions about the usage of Applications on mobile devices, Apps will run through an extensive


testing process considering legal and technical aspects. The audit combines static and dynamic testing which is the most powerful combination in terms of security (a static test itself can not cause any hidden behavior of the App. An App is only showing its true behavior when it is running on standard hardware.).

1.2.1 Testing Approach

To achieve a preferably maximum range of relevant security information the below process has been established:

Legal Assessment

Checking Terms and Conditions (T&C) Checking German Data Protection Act Checking Data Security Regulations Checking Data Processing Locations Technical Assessment

Check: Encrypted transmission of sensitive and user confirmed data Check: Authorized recipient of the transmitted data

Check: Logging of access authorization Check: contacted server

Breaking up SSL-Encryption by Man-in-the-Middle Attack

In parallel an App-Audit is being performed (partly virtual, partly physical): - Selecting all menu items

- Creating user accounts, purchasing products if applicable - Sending files out of the App

- Receiving and saving data

- Further options depending on the App functionality - Checking access authorization during the test Check: Type and target of transmitted data

1.2.2 Test Criteria

The scope of criteria has been defined to cover all relevant areas of data. This is an approach to provide maximum protection against 3rd parties trying to get access to sensitive data and harm business operations. In detail App-Security Audits are focused on the following sensitive information:

Device Codes (IMEI, UDID, Android-ID, etc.) Username Passwords Serial Number MAC-Addresses Content of Messages GEO-Data

Credit Card Data Contact Details Individual Data


1.2.3 Evaluation of Test Results

Each App is being reviewed individually corresponding to the following approach: Is the App only doing what it is supposed to do? In detail this means:

Matching real access rights with specified rights

Reviewing sent data (what sort of data? where? how? authorized?)

Is the distribution or investigation of the data required for the App functionality? Logging all occurring connections (IP, company, whois)

Combining data security and privacy knowledge and experience from several customer projects following security levels have been set:


Non-conspicuous App behavior, Terms and Conditions OK


App shows lack of security. Individual decision required if criteria can be excluded under certain circumstances. This level includes the following violations:

Geo-Data are being transmitted either unencrypted or to unauthorized parties Device Codes are being transmitted

Usernames are being transmitted unencrypted

“Unlovely” paragraphs in General Terms and Conditions Etc.


Significant security worries but under certain conditions the App might still be used. This level includes the following violations:

Device Codes are being transmitted unencrypted

Usernames are being transmitted to unauthorized parties

Message content is being transmitted either unencrypted or to unauthorized parties GEO-Data is being transmitted unencrypted and to unauthorized parties

Contact data is being transmitted unencrypted or to unauthorized parties Problematic paragraphs in General Terms and Conditions

Etc. Black:

The App should not be used! This level includes the following violations:

Passwords are being transmitted unencrypted or to unauthorized parties Credit Card Data is being transmitted unencrypted or to unauthorized parties Device Codes are being send unencrypted to unauthorized parties

Significantly problematic paragraphs in General Terms and Conditions Etc.


For an initial Whitelist supposed to be used in a corporate environment we would propose the below set of criteria that needs to be fulfilled by an App that is allowed to be installed on mobile devices.



Using Apps in a Corporate Environment

People are used to work with Apps in their in their daily routine and Apps are playing an important part in efficiency, usability and fun using a corporate mobile device. Thereby, the lines between private and business usage are frequently blurred. To strike the balance between data security and usability, dynamic App Management including App-Withelisting is an efficient approach.

Integrating a secure mobility concept focusing on a secure mobile app environment is a multilevel process with several things to consider. The following process is a best practices approach of mediaTest digital for making a Trusted App Directory available and using it effectively.

1. Preparation / General Framework

Defining involved partners/stakeholder (corporate safety representive, CIO Board, Work Coucil, Purchasing, etc.)

Desired scope of white- and blacklisting

Defining the process for approving further apps Selecting basic services and Add-Ons

2. Security Standards

Defining security criteria and traffic light system in corporation with the customer Prioritizing security violations and defining escalation rules

Handling of update szenarios

3. Setup

Filling the Trusted App Directory with App-IDs, criteria and background information from the security audits (sort of security violation, etc.)

Transmitting the existing App inventory of the customer and synchronization with mTd data base for defining the initial setup

Testing unavailable apps and updates

Integration into the Mobile Device Management System

4. Auditing

Rolling import of test results for all apps and updates into the MDM

Submitting requested apps for being available in the Trusted App Directory by web form and/or based on defined processes out of the MDM

One target of the PoC is to deliver an initial draft of a Trusted App Directory and an idea what to consider when rolling out a whitelist in terms of communication. The following points will cover the content of the initial whitelist and also highlight issues for raising awareness of stakeholders.


Black- and Whitelisting

Having a total of 1.7 million Apps available and considering the massive daily expansion rate at the iTunes and Play Store a straight blacklisting is not a realistic approach in terms of the cost-value ratio. Rather than permanently testing the entire app market a whitelist combined with a supporting blacklist offers a great balance between user friendliness, security and involved costs.

The following proposal for a reasonable use case is considering a whitelist, blacklist and a “grey zone”.


Whitelist: All Apps that have been tested and meet the defined security requirements. Blacklist: All Apps that have been tested and don’t meet the security requirements. Grey Zone: Will be filled by the customer and contains selected Apps that the customer would like to make available but are not yet part of the white- or blacklist. Additionally, the grey list will contain Apps which are already installed on corporate devices and/or will be installed aside the whitelist for specific reasons. The grey zone Apps can either be accepted by the customer or can be put through to mediaTest digital for testing and/or for requesting an alternative.

Remark: Compared to a classical white- or blacklist (e.g. blocking/allowing the access of certain websites in a corporate environment) it is today not possible to technically block the download of specific applications or to block all Apps apart from the ones listed in the whitelist. This would require a stand alone App Store which is at least for public apps not a practicable concept today


judicial and liability issues when hosting and distributing software, individual contracts with each developer, etc. In Addition, Apple does not allow this sort of App Stores in general.




Related subjects :