Sie sind auf Seite 1von 7

Effective Risk Communication for Android Apps

ABSTRACT:

The popularity and advanced functionality of mobile devices has made them
attractive targets for malicious and intrusive applications (apps). Although strong
security measures are in place for most mobile systems, the area where these systems
often fail is the reliance on the user to make decisions that impact the security of a
device. As our prime example, Android relies on users to understand the permissions
that an app is requesting and to base the installation decision on the list of
permissions. Previous research has shown that this reliance on users is ineffective,
as most users do not understand or consider the permission information. We propose
a solution that leverages a method to assign a risk score to each app and display a
summary of that information to users. Results from four experiments are reported in
which we examine the effects of introducing summary risk information and how best
to convey such information to a user. Our results show that the inclusion of risk-
score information has significant positive effects in the selection process and can
also lead to more curiosity about security-related information.

EXISTING SYSTEM:

With regard to smart phones, users are more concerned with privacy on their phones
than on computers, and they especially worry about the threat of malicious apps.
For mobile devices, a person often downloads and uses many apps from multiple
unknown vendors, with each app providing some limited functionality. Additionally,
all of these unknown vendors typically submit their apps to a single or several app
stores where many other apps from other vendors may provide similar functionality.
This different paradigm requires a different approach to deal with the risks of mobile
devices, and offers distinct opportunities.

DISADVANTAGES OF EXISTING SYSTEM:

 People will not use security features properly if they fail to understand the
purpose of the features or the information on which their decisions should be
based.
 Users make many decisions that affect the overall state of security of any
system with which they interact. For security and privacy, most of these
decisions relate to the risk to which the individual or system is exposed.

PROPOSED SYSTEM:

We propose the addition of a summary risk rating for each app. A summary risk
rating enables easy risk comparisons among apps that provide similar functionalities.
We believe that one reason why current permission information is often ignored by
users is that it is presented in a “standalone” fashion and in a way that requires a lot
of technical knowledge and time to distill useful information, making comparison
across apps difficult. An important feature of the mobile app ecosystem is that users
often have choices and alternatives when choosing a mobile app. If a user knows
that one app is significantly riskier than another but provides the same or similar
functionality, then this fact may cause the user to choose the less risky one. This will
in turn provide incentives for developers to better follow the least-privilege principle
and request only necessary permissions.
ADVANTAGES OF PROPOSED SYSTEM:

 A summary risk rating also enables proactive risk communication (e.g., when
the user searches for apps) so that users can take this information into the
decision process. This is in contrast to the current reactive approach, where
often times the user sees the permission/risk information of an app as a final
warning only after the user has made the decision to choose the app.
 Our hypothesis is that when a summary risk rating is presented in a user-
friendly fashion, it will encourage users to choose apps with lower risk.
 The user sees the permission/risk information of an app as a final warning
only after the user has made the decision to choose the app.
 An effective risk communication approach for Android could provide.

SYSTEM ARCHITECTURE:

MODULES:
1. Design Goals
2. Permission Based Risk Signals
3. Category and Permission Based Risk Signal
4. Results for Risk Signals

MODULES DESCRIPTION:
Design Goals:
When designing a risk signal two relevant measures are the warning rate which
defines how often a user receives warnings generated by the risk signal and the
detection rate which defines what percentage of malicious apps will trigger the
signal. To avoid over-exposing users to warnings generated by risk signals, it is
desirable that a risk signal has a low warning rate. To be effective at detecting
malicious applications a risk signal should have a high detection rate. More-over a
risk signal should be easily understandable by end users. Because there is no
guarantee that the market data contains no malware, a warning rate of close to 0is
not necessarily desirable. At the same time the boundary between benign and
malicious apps is blurred since many apps are unnecessarily over-privileged or may
contain invasive ad networks. In this sense, raising warnings for such over-
privileged apps is not a “false” positive; thus one should not equate the warning rate
with the false positive rate in intrusion detection. On the other hand, an overly high
warning rate is certainly undesirable because when users frequently see a warning,
it becomes less effective. In general, we desire risk signals to have a relatively low
(between 1and10percent) warning rate, and a relatively high detection rate. Another
property that we desire is that the risk signals should be easy for end users to
understand. After all, no risk signal can be used to stop the installation of an app by
itself. The ultimate decision lies with the end user. If the user can understand why a
warning is raised, then there is higher chance that they can process the information
accordingly. Having an easy-to-understand risk signal also has the potential to
benefit the overall eco-system of Android apps.
The risk signal can be displayed on Android websites. If a small percentage of apps
are identified as risky, and there is clear reason why, such as requesting a rare
permission, this gives developers incentives to not request permissions the app can
function without, since requiring too many permissions now reflects adly on an app.
This creates a positive feedback loops as apps requesting fewer permissions will
cause other apps that request many permissions to increasingly stand out.

Permission based Risk Signals:


Risk signals based only on apps from the Android market are more robust as they
are not tuned to detect malicious apps in our particular data set, and aim only at
detecting apps that request too much permission. Furthermore, it may be desirable
for the signals to use only critical permissions so that such signals are more difficult
to evade. These many permissions were chosen because we believe they are critical
for the security and privacy of end users. These permissions allow an app to either
infringe upon privacy, or cause monetary loss or other kinds of damage.

Category and Permission based Risk Signals:


Different apps have different functionalities, and thus may require different
permissions; it thus makes sense to take into account the intended functionality of
an app when deriving a risk signal based on permissions. We use the category of an
app to approximate the intended functionality of an app. This is partially supported
by the analysis, in which it was shown that in general, the category an app was in
affects the permissions it requests. The CRCP signal can be intuitively viewed as
comparing the intended functionality of an app (inferred from its category) with its
requested permissions and generates a report when over requesting is detected.

Results for Risk Signals:


We evaluate these risk signals using the market data set and malware data set and
report the results here. In this specific data set we have apps for 30 categories; some
categories at the time of data collection were not yet available. The Category Based
Risk Signals take into account the category of an app, which can indicate some of
the functionality that is expected from apps within that category. Since the malicious
apps did not come with a category we count the number of categories a malicious
app is marked as risky in.

SYSTEM REQUIREMENTS:
HARDWARE REQUIREMENTS:

 System : Intel® core ™ i3-6100 CPU @ 3.70 GHz


 Hard Disk : 540 GB.
 Monitor : 15 VGA Colour.
 Mouse : Logitech.
 Ram : 4GB.
 MOBILE : ANDROID

SOFTWARE REQUIREMENTS:

 Operating system : Windows 7/8/10.


 Coding Language : Java 1.8
 Tool Kit : Android studio

REFERENCE:
Christopher S. Gates, Jing Chen, Ninghui Li, Senior Member, IEEE, and Robert W.
Proctor “Effective Risk Communication for Android Apps” IEEE
TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL.
11, NO. 3, MAY-JUNE 2014

Das könnte Ihnen auch gefallen