Multi-Scenario Multi-Criteria Optimization in Engineering ...
A multi- Criteria - based Evaluation of Android Application
description
Transcript of A multi- Criteria - based Evaluation of Android Application
A multi-Criteria-based Evaluation of Android Application
Andrea Saracino,G. Dini, F. Martinelli, I. Matteucci,
M.Petrocchi, D. Sgandurra
InTrust 2012
Android
• Largest Market Share.
• Plethora of applications.
• Several marketplace.– Official.– Unofficial.
61%
Can we trust them??
• Android is the platform with the largest increase of malware attacks.
• More than 37 malware families specific for Android.
• Malware found even in official markets.
Android Security
• Sandboxing
• Permissions
Native security mechanisms?
The Permission System
• Access Control mechanism.
• Declared by app developer in Manifest file.
The Permission System (1)
• Who takes the decision on Application Security?
• THE USER!!
The Permission System (2)
• Several users do not understand or care about permissions.
• The user can only accept all the permissions or abort the installation.
• Too rough grained permissions.• Permission overdeclaration.
What we propose
• A threat based classification of Android Permissions.
• A threat index to assess the hazardousness of an application.
• A multi-criteria decision system to help the user in understanding whether an application is secure or not.
Type of threats
• Each permission receives a threat score on three parameters.
• ACCESS_COARSE_LOCATION– Privacy: 0.6– System: 0– Money: 0
• These parameters simply describe which security aspect is threatened by the application’s permissions.
Privacy Threat
• Permissions that allow an application to:– Read Contacts– Read text messages– Access user’s accounts and passwords– Read IMEI and location
Money Threat
• Permissions that allow an application to:– Perform phone calls.– Send SMS messages.– Use the internet connection.– Modify connection settings.
System Threat
• Permissions that allow an application to:– Install/Uninstall applications on the phone.– Enable/Disable connection interfaces (Wi-Fi,
Bluetooth, … ).– Switch on/off the smartphone screen.
Threat Levels
No Threat
Low Threat
Low – To –Moderate Threat
Moderate Threat
Moderate to High Threat
High Threat
Threat Score• Extraction of permissions from the manifest for each
application.
• Computation of a global threat score.– Ranges from 1 - no permissions required - to 15 - all permissions
required.– An application with a score higher than 7 is considered a very
dangerous application.
• Developer should declare only the necessaries permissions. (Contrast Overdeclaration).
Assessment of App Security
• Permissions may not be sufficient to decide whether an application is secure or not.– Applications that really needs several permissions.– Malware that does not require dangerous
permissions.• Add more criteria to assess the app quality.
• Use of a Multi-Criteria decision System.
Multi-Criteria Decision (1)
• Analytic Hierarchic Process (AHP)– Gives an objective decision using subjective
criteria.
– Highly flexible and customizable.
Analytic Hierarchic Process
Multi Criteria Decision (2)
• Criteria– Global threat score– Developer Reputation– Marketplace– Number of downloads– User Rating
Final Decision
• An application can be considered by AHP as:– Trusted: Secure and Reliable.– Deceptive: Bogus or generally low quality
application.– Untrusted: Shows several security issues.
Comparison Matrices
• Tell how much a decision (alternative) is relevant with respect to a criterion.
• Example: Top Developer
Trusted Untrusted Deceptive
Trusted 1 4 7
Untrusted 1/4 1 4Deceptive 1/7 1/4 1
Example: Baseball Superstar
• Two versions of the same game,Vers. A, Vers. B.
• Threat score:– Vers. A: 1– Vers. B: 7,3
• AHP decide that Vers. A is trusted, Vers. B is untrusted.
• Vers. B is trojanized by the Geinimi malware.
Example: Skype
• Skype requires several permissions to work properly. (Threat Score: 6,8).• Market: Official• Downloads: More than 10 millions.• Rating: 4 / 5• AHP decision: Trusted!
Results
• 180 Android applications coming from different marketplaces.
Conclusions
• We have defined a simple but effective permission classification system.
• We provide the user with an app analysis tool:– Static (computation can be performed offline).– Easily understandable.– Force developers to carefully choose the required
permissions.
Future Works
• Inclusion of a reputation parameters based on user feedbacks.
• Test the system on a larger application set, with different settings for AHP.
• Inclusion of sub-criteria in the AHP decision system.