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
1
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.
1.1
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.
1.2
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:
Green:
Non-conspicuous App behavior, Terms and Conditions OK
Yellow:
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.
Red:
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.
2
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.
2.1
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.
