ACM Mobile Networks and Applications manuscript No.(will be inserted by the editor)

Monitoring Smartphones for Anomaly Detection

Aubrey-Derrick Schmidt · Frank Peters · Florian Lamour ·

Christian Scheel · Seyit Ahmet Camtepe · Sahin Albayrak

Received: date / Accepted: date

Abstract In this paper we demonstrate how to mon-itor a smartphone running Symbian operating system

and Windows Mobile in order to extract features for

anomaly detection. These features are sent to a remote

server because running a complex intrusion detectionsystem (IDS) on this kind of mobile device still is not

feasible due to capability and hardware limitations. We

give examples on how to compute relevant features and

introduce the top ten applications used by mobile phone

users based on a study in 2005. The usage of these ap-plications is recorded by a monitoring client and visu-

alized. Additionally, monitoring results of public and

self-written malwares are shown. For improving moni-

toring client performance, Principal Component Analy-sis (PCA) was applied which lead to a decrease of about

80% of the amount of monitored features.

This work was funded by Deutsche Telekom Laboratories. Notethat this is a user-built version. The original published version canby found at http://www.springerlink.com DOI:10.1007/s11036-008-0113-x.

Aubrey-Derrick SchmidtTechnische Universitat Berlin / DAI-LaborTel.: +49 (0)30 - 314 74039Fax: +49 (0)30 - 314 74003E-mail: aubrey.schmidt@dai-labor.de

Frank PetersE-mail: frank.peters.@dai-labor.de

Florian LamourE-mail: florian.lamour@dai-labor.de

Christian ScheelE-mail: christian.scheel@dai-labor.de

Seyit Ahmet Camptepe

E-mail: ahmet.camtepe@dai-labor.de

Sahin AlbayrakE-mail: sahin.albayrak@dai-labor.de

Keywords smartphones · monitoring · anomalydetection

1 Introduction

Mobile phones get more and more popular. Since Au-

gust 2006, more mobile phones than inhabitants areregistered in Germany [6]. As the capabilities of these

devices increase, they are not simple voice centric hand-

sets anymore; rather they provide mobile computing

power that can be used for several purposes. Especiallysmartphones represent a possibility of moving appro-

priate applications from the PC to mobile devices, as

they mostly provide large bandwidth wireless network

access, office tools, and the possibility of installing third

party programs. But with the increase of capabilitiesmore and more malicious software (malware) targeting

these devices emerge. We believe that the evolution of

malware for mobile devices will take a similar direction

as the evolution of PC malware. Thus, similar prob-lems will have to be encountered, e.g. missing signatures

for unknown threats and new malwares appearing at

high frequency. Additionally, Builygin [7] showed that

in worst case a MMS worm targeting random phone

book numbers can infect more than 700000 devices inabout three hours. Moreover, Oberheide et al. [24] state

that the average time required for a signature-based

anti-virus engine to become capable of detecting new

threats is 48 days. These numbers request extendedsecurity measures for smartphones beyond signature-

based mechanisms as a malware can seriously damage

an infected device within seconds.

Applying machine learning algorithm to the task of

detecting anomalies and malware might increase secu-

rity of mobile devices, like smartphones. Therefore, this

2

paper introduces an approach on how to monitor smart-

phones in order to extract data (features) that can be

used for machine learning-based remote anomaly detec-

tion. Anomaly detection does not require signatures in

order to work which enables the detection of new andunknown malware. It can also be used in conjunction to

signature-based schemes to decrease the response time

whenever new malware emerges. For this purpose, the

anomaly detection algorithms have to learn the nor-mal behavior of a user and device in order to be able

to distinguish between normal and abnormal, possibly

malicious actions. The extracted features are sent as

vector to a remote system taking the responsibility for

extended security measures away from the probably un-aware user. These vectors are processed by methods and

algorithms from the field of machine learning, like Ar-

tificial Immune Systems (AIS) [12] or Self-Organizing

Maps (SOM) [2], in order to detect abnormal behav-ior. For identifying the relevant features, first of all, as

much as possible features were extracted. The resulting

list of features was analyzed with PCA for reducing the

amount of needed information. Basing on known smart-

phone malware behavior, the reduced list was extendedby further features that obviously can indicate malware

activity.

This work is structured as follows. In Section 2, weexplain what a smartphone actually is and where it can

be used. In Section 3, we give a brief overview on the

framework we use for processing the monitoring data.

Section 4 shows how to build a monitoring client for

smartphones and give explicit examples on values thatcan be extracted from Symbian OS and Windows Mo-

bile devices. In order to be able to learn normality on

smartphones, we map actions excerpted from a study

on mobile phone usage to different use cases and spec-ify testing scenarios on these. The corresponding mon-

itoring results are given in Section 5. In Section 6, we

present the results of principal component analysis for

reducing the amount of features. In Section 7, we con-

clude.

2 Related Work

In this section smartphone basics are introduced and re-

lated smartphone monitoring approaches are presented.

2.1 Smartphones

In this paper we use the expression smartphone1 in or-

der to describe a mobile device that mostly unifies func-

tionalities of a cellular phone, a PDA, an audio player,

a digital camera and camcorder, a GPS2 receiver, and

a PC. Smartphones often use PC-like QWERTY key-boards in order to increase typing speed and sometimes

PDA-like pen displays for improved data and command

handling. Mechanisms were developed that addition-

ally improve text input, like T9, which means “Texton 9 keys” and represents predictive text technology.

Smartphones use different techniques for creating wire-

less connections for communication purpose:

• GSM3 represents the second generation (2G) of mo-

bile end-to-end communication, mainly used for voicecalls and services like SMS4

• GPRS5 in combination with 2G is often described

as 2.5G, as it provides voice and packet data

• W-CDMA6 was designed as replacement of GSMand is used in the FOMA7 system (JP) and UMTS8,

being able to transport data at higher speed than

GSM.

Additionally, the devices provide Bluetooth, Wireless

LAN (WLAN), or IrDA9 support for shorter range wire-less connectivity. Using one of these connections, a user

is able to make phone calls, use an internet browser,

play multi-player games, or read emails.

Furthermore, the smartphone can be seen as thefirst platform for pervasive computing [1] where inter-

esting areas of application were pointed out by Roussos

et al. [26]:

• Mobile Phones as information service endpoint, e.g.applied as navigational assistance or location based

services.

• Mobile Phones as remote controllers for different de-

vices, like television or HiFi station.

• Mobile Phones as pervasive network hubs to pro-vide wide area connectivity, e.g. for wearable sys-

tems that need to communicate in order to transmit

health-related data.

• Mobile Phones as ID tokens in order to store infor-mation used to verify the user and information.

1 In the sense of this work, we will use the expressions smart-

phone, mobile phone and mobile device equivalently.2 Global Positioning System3 Global System for Mobile Communications4 Short Message Service5 General Packet Radio Service6 Wideband Code Division Multiple Access7 Freedom of Mobile Multimedia Access8 Universal Mobile Telecommunications System9 Infrared Data Association

3

Smartphones can be applied to these fields because they

have standardized operating systems installed. Follow-

ing Canalys [8], there are three main competitors in this

field: Symbian OS from Symbian Ltd. [28], Windows

Mobile from Microsoft [21], and Research In Motion(RIM) with the Blackberry devices, with 78.7%, 16.9%,

and 3.5% market share on the smart mobile device mar-

ket, respectively. These operating systems enable the in-

stallation of third party applications which allows cus-tomization of the device according to the user’s soft-

ware needs. But this customization brings the danger

of being infected by malware along. According to Pe-

ter Gostev from Kaspersky Lab. [14], from June 2004

to August 2006, 31 new families of malware for mo-bile devices with 170 variants were recognized where

Caribe was the first worm to hit the mobile community

(Symbian OS). Jamaluddin et al. [17] described how

easy it is to write a Trojan horse capable of sendingSMS messages to premium services. The behavior of

this malware is visualized in Subsection 5.4.1.

2.2 Related Research

Several promising smartphone monitoring-based approa-

ches have been presented:

Miettinen et al. [22] suggests an IDS that uses host-

based monitoring in order to detect anomalies on a mo-

bile device. Additionally, a remote correlation engine isused to add network-specific data for better detection

on a separate computer.

Davis et al. [10] propose a host based intrusion de-

tection engine (HIDE) which has the goal to alert a userwhen a suspected attack is underway before irrepara-

ble damage is caused. Therefore, HIDE first monitors

anomalous behavior of the battery when it fails to go

into suspend or sleep mode. Then HIDE sends an alarm

message to the user and the nearest proxy server andstarts to write logs that contain the causes of the higher

power consumption. In the next step, HIDE suggests

mitigation measures.

Cheng et al. [9] developed a system that uses sys-tem and log file monitoring in order to detect malware

infections. Therefore, a monitoring client is installed on

a Windows Mobile 5 device that is able to determine its

own phone number, the date, the cell id, the SMS and

calling logs. Statistical and abnormality-based analysisfor processing the monitored data is used. For privacy

and authentication, ticketing and encryption is intro-

duced. Whenever an infection is detected, the system

alerts the corresponding device as well as all deviceswith contact to the infected one. They evaluate their

approach with a simulation basing on SMS traces com-

ing from a cellular-network provider from India.

Buennenmeyer et al. [5] present an approach of mon-

itoring current changes on a smartphone in order to de-

tect anomalies. The changes can be caused by malwares

and external attackers, e.g. flooding or network prob-

ing. The monitored data is sent to a remote server thatcreates profiles of each monitored device and, hence, is

able to detect anomalies. They evaluate the power con-

sumption of the monitoring and state that the client

uses less than 2% of battery resources compared to thecorresponding baseline battery lifetime.

As mentioned before, these approaches are very promis-

ing but they are somehow limited to Windows Mobile or

follow a different approach. Especially the battery and

current-based approach depends on the quality and ageof the battery since the internal resistances of these in-

fluence the results. Our presented approach bases on

analyzing system-specific values where it is not limited

to one single (client) system. But since Symbian OS ismarket leader for the field of smart mobile devices and

hundreds of malwares already appeared for this plat-

form, our system can also provide extended security for

a wide range of Symbian users.

3 The Monitoring Framework

Fig. 1 The remote monitoring framework.

For understanding the purpose of our work we pre-

sent the corresponding framework on Figure 1 in which

our monitoring clients are included. We have to notethat the focus of this work is describing the develop-

ment of a monitoring client for smartphones so we will

not discuss design or implementation issues concerning

the global framework.The framework consists of three components: smart-

phone monitoring client, remote anomaly detection sys-

tem (RADS), and visualization. The client will be de-

4

scribed in Section 4. The RADS provides a web server

for communicating with the client. The received mon-

itored features are stored into a database which is ac-

cessible by detection units. These detection units ana-

lyze the data for finding anomalies which might indicatemalware activity. The detection units are implementa-

tions of machine learning algorithms, e.g. AIS [12] or

SOM [2], that are able to handle multi-dimensional data

in order to produce detection results. The meta detec-tion units work similar to the ordinary units except

that they analyze results for weighing results from dif-

ferent detection algorithms. Since different algorithms

perform different on certain device usage data, using

meta detection units might improve overall detectionresults. But this is still in research so no specific results

can be presented at this point. The visualization indi-

cates the device status, incidents, and detection results.

4 The Monitoring Client

Intrusion detection can be separated into two fields:signature-based misuse detection and anomaly detec-

tion. As the devices are monitored for anomaly detec-

tion, it is important to monitor device data that en-

ables differentiation between normality and anomalies.Eugene Spafford et al. [27] point out that host-based ap-

proaches, direct data collection techniques, and internal

sensors are preferable to network-based approaches, in-

direct data collection techniques, and external sensors.

This was taken into account when designing our moni-toring client.

4.1 Generic Client Design

Fig. 2 Generic client structure

We propose a generic architecture in Figure 2 in-

cluding three main components for the monitoring client:User Interface, Communication Module, and Feature

Extractor.

The User Interface enables client configuration, like

changing server IP address or port. It can be used to

visualize the state of the monitoring client, e.g. send-

ing or buffering, and can indicate anomaly detection

results.

The Communication Module is responsible for man-

aging connection states and sending or buffering the

monitored features which is shown on Figure 3. If the

client cannot connect due to signal loss, it starts buffer-ing until a connection can be established. If a connec-

tion is not possible before the buffer is filled, it adds the

last extracted vector and removes the first. This is only

a temporary solution since losing a single value already

may result in missing malicious activity.

Device_Connection

Idle

timer tick

Acquire data

data ready [buffer<threshold ]

Connect

stored

data ready [buffer>=threshold]

connected [buffer>0]

Store to buffer

connection failed

data sent

connected [buffer=0]

data sent

Send buffer

Send current data

Fig. 3 The possible connection states of the monitoring client

The Feature Extractor has several different compo-

nents gathering and computing features. Features de-

scribe the state of the monitored device. They rep-resent various measurements and observations of re-

sources and other hard- and software components. If no

direct interfaces are provided by the operating system,

features are extracted by using algorithms or methodswhich provide approximated results. This is done with

care, as additional encumbering of the already limited

device possibly distorts the monitoring results.

4.1.1 Securing the Monitoring Client

As the communication or even the monitoring client

itself can be targeted and attacked by malware, it isimportant to secure the system. Using encryption for

the communication channel should be a proper way to

secure data transmissions. Securing the application is

more complicated. The Symbian OS API provides amethod for setting processes to different critical lev-

els. On highest level, if the monitoring client process

is killed, the device reboots and restarts the process.

5

This functionality was not added yet, as it obviously

could lead to denial of service attacks on the device, but

at least it would guarantee either that the monitoring

agent is running or that the user brings the device to a

specialist for fixing the problem. Another possibility ischecking the running applications that are clearly iden-

tifiable through a unique Symbian application ID. As

soon as an unknown application is started, this could be

compared with an application white list that includesall allowed programs. If an unknown process is started

the system can kill it or alert the user and system. Dif-

ferent operating systems might support similar func-

tionalities where it is probable that not all clients will

be able to run the same security measures.

4.2 The Symbian Client

Fig. 4 The Nokia E61 and HTC TyTN B smartphones runningthe monitoring client.

The monitoring client was developed in Symbian C++version S60 3rd with “Nokia Carbide.vs” and consists

of the three proposed components. The User Interface

can be used to change server port and address, to start,

stop, or move the client into the background. Furtheruser information can be inserted in order to control ac-

cess to the remote server. For reasons of program stabil-

ity and to prevent interferences, the GUI is running in

a thread separate from the other components. Further

work may even remove the user interface to a separateapplication, since there is no need to tie up GUI re-

sources for an application running in the background.

The Communication Module uses SOAP10 Webservices

on top of TCP/IP in order to communicate with theserver. As we found out, sending data — or even just

remaining in ready-to-send mode — is rather expensive

in terms of battery power. To prevent the rapid deple-

tion of the power source all data is stored locally and

10 formerly: Simple Object Access Protocol

sent in bulk after reaching a certain threshold level. The

Feature Extractor is triggered to fetch new monitored

data every 20 seconds which then is sent to the server

using the appropriate service.

4.2.1 The Symbian Features

Table 1 An Excerpt of the Extracted Features

Name Compl. Description

RAM FREE simple Indicates the amount offree RAM in Kbyte

USER INACTIV-ITY

simple Indicates, if the user wasactive in the last ten sec-onds

PROCESSCOUNT

medium Indicates the amount ofrunning processes

CPU USAGE complex Represents the CPU Us-age in percent

SMS SENTCOUNT

complex Represents the amountof SMS messages in thesent directory

Symbian OS11 provides some programming interfacesfor extracting features, e.g. fetching the amount of free

RAM or the user inactivity time are simple API calls.

But not all areas are covered by API calls, especially

reading network traffic packets cannot be done by av-

erage developers as the application programming inter-faces are restricted. Some other features need complex

method constructs in order to be extracted. We distin-

guish between three different method complexities: sim-

ple, medium and complex. Features that can be calledthrough Symbian C++ interfaces taking only one or few

lines of code are categorized as simple. Features that

need several classes or algorithms to be computed are

marked as complex. Everything in between is marked

as medium. Some of the features can be used to iden-tify and manage observed users or devices, e.g. IMEI12

and IMSI13. The IMEI and IMSI are unique numbers

that clearly identify mobile devices or mobile network

users. In the following, we describe how to computerelevant features shown on Table 1 with pseudo code.

Some of these will be used to visualize user activity in

Section 5.4.

RAM FREE is a feature that can be easily extracted.All applications need more or less RAM in order towork, so every running program/malware should haveimpact on this value. In order to present how SymbianC++ programming looks like, we will show the real callfor getting the available RAM.

11 tested on Version 9.1 S60 3rd12 International Mobile Equipment Identity13 International Mobile Subscriber Identity

6

User::LeaveIfError(HAL::Get(

HALData::EMemoryRAMFree, iFreeRamSize));

USER INACTIVITY indicates if a button was pressed

within the last 10 seconds. If so, a “0” is returned else a

“1”. This feature uses a function that returns the abso-lute user inactivity time in seconds. This value is very

interesting for giving hints on activities that are not

directly caused by the user and happen automatically

and/or periodically in the background.

Table 2 Pseudo Code for Indicating User Activity

GET UserInactivityTime

IF UserInactivityTime ≥ 10 seconds

RETURN User is inactive

ELSE

RETURN User is active

The PROCESS COUNT can be easily computed

through a while loop that is checking the existence of

processes. Each started application should increase the

process count at least by one, and so should malware.

Table 3 Pseudo Code for Getting the Process Count

WHILE there are more processes

INCREASE counter

FETCH information from process objectSTORE process information

RETURN the counter

The CPU USAGE cannot be read through a given

Symbian OS interface. While searching for an approxi-

mation we found a method described by Marcus Grober

[15] that manually checks whether the CPU is busy or

not. This is done by requesting a timer event with lowpriority 100 times a second. Another request with high

priority checks every second how often the low prior-

ity request was actually called. The answer can be used

to approximate the usage of the CPU since the morethe CPU is busy the less the low priority request will

be called. The following code fragment shows the main

calls and functions of this method.

SMS SENT COUNT needs like every feature relat-

ing to messaging (SMS, MMS, and email) some morecomplex functions to be computed. But once imple-

mented, most of the messaging-related features can be

extracted using the same classes. Together with USER

Table 4 Pseudo Code for Approximating the CPU Usage

CREATE new request Active Object low priority

CREATE new check Active Object high priority

SEND low priority time request

to CPU 100 times/second

CHECK number of accepted requests/secondReturn approximated CPU usage/second

INACTIVITY this feature can help to indicate malware

sending messages to cost-intensive premium services.

Table 5 Pseudo Code for Getting the Amount of Sent SMS Mes-sages

CREATE messaging sessionCONNECT messaging session to sent folder

SELECT SMS sent folder

RETURN amount of SMS messages

4.3 The Windows Mobile Client

The Windows Mobile monitoring client was developed

in C# for Version 6.0 using Microsoft Visual Studio 2008

in the final stage. Similar to the Symbian OS client theWindows Mobile client bases on our generic client de-

sign. The extracted features are mostly of the same type

as on Symbian OS. They only differ in the way they

are called through the given Windows Mobile APIs. Ingeneral, developing the monitoring client on Windows

Mobile was easier than on Symbian OS since provided

APIs are documented well and running the needed de-

velopment and build environment does not need that

much effort as with Symbian OS. Various code exam-ples can be found online which are easy to integrate.

Figure 4 shows the HTC TyTN B running the moni-

toring client.

4.4 A First Android Architecture Draft

The Open Handset Alliance Project “Android”14 aims

for developing the first complete, free, and open mo-

bile plattform. Open means that all sources will be

published with the release of the first Android hand-set in the second half of 2008. There is an ongoing de-

bate whether open source software is more secure than

14 http://code.google.com/android/

7

closed source software where the most important pros

and cons can be found in Lawton [19]. Since the dis-

cussion reflects various different opinions which are all

argued well, we will omit to continue the debate in this

paper. We only state that open source software has thepotential to be more secure where it depends on the

quality of the code reviewers whether it is or not.

Android bases on Linux kernel 2.6 and uses Javaon top of Linux for providing a development and run-

time environment for 3rd party applications. The An-

droid Java environment is not compatible to Java Se

or ME and uses a proprietary virtual machine calledDalvik VM. This is optimized for mobile usage and

provides one virtual machine instance for each running

Java application. This enables Linux to handle the in-

stances separately where every application is restricted

by Linux file system rights. Since the openness of An-

GUI Comm. Java

Feature

ExtractorLinux

Fig. 5 Simple monitoring architecture

droid allows modification of almost every software com-

ponent and Linux was used as core OS, this platformprovides a good foundation for building a monitoring

agent benefiting from several years of Linux security re-

search. A first simple architecture basing on our generic

approach can be seen on Figure 5. Since accessing se-curity relevant system characteristics might be prob-

lematic using native calls from Java applications (JNI),

the extractor was placed on the Linux OS layer. Ap-

plication control (GUI) and communication are placed

on the Java layer since the Android Java environmentprovides various libraries for implementing these. With

the release of the first handsets it has to be checked if

this decision results in performance issues which in turn

may be solved by moving the communication compo-nent to the Linux layer.

GUI Comm.Java

Feature

ExtractorLinux

Detect.

Database

Fig. 6 Improved architecture for future smartphones

This simple architecture can be extended following

the assumption that the capabilities of smartphones in-

crease steadily. This means that early client-server de-

sign decisions that moved most of the data analysis pro-

cessing to the server may be changed. Relocating some

of the server functionality to the client side will result in

the reduction of communication latencies. Additionally,having a light-weight detection on the client might lead

to a dramatic decrease of communication data as the

client could only send data referring to already detected

anomalies. Furthermore, Android provides access to lo-cal database which can be used to store the monitored

data. On request of the server, database excerpts can

be sent to the remote detection side for further analysis.

The improved architecture can be found on Figure 6.

The monitored feature set of android devices willbe slightly different from the one of Symbian OS and

Windwos Mobile. Since Linux intrusion detection re-

search is mature, results from various systems can be

taken into consideration, e.g. [3] and [4]. A key issue

will be to identify and merge the most promising fea-tures known from file system, logfile, network, and ker-

nel monitoring systems.

5 Experiments

As our goal is to provide data that enables differenti-

ation between normal and malicious device usage, weneed to define normal usage first. TNS Technology re-

leased a booklet [29] sourced from the TNS Technol-

ogy’s Global Technology Insight (GTI) 2005 where typ-

ical user actions on mobile phones are described. We

excerpted actions that we performed on Nokia E61 and7610 smartphones in order to monitor normality. The

corresponding software behaviors are visualized as data

results and can be found in Section 5.4.

Table 6 The Top Ten Applications

No. Application Usage

1. SMS 83%

2. Games 61%

3. Camera 49%

4. MMS Pictures 46%

5. PDA Functions 36%

6. Internet 31%

7. WAP 30%15

8. Bluetooth 28%

9. Email 27%

10. Video Camera 27%

16 will be substituted with MP3 (19%) due to UMTS usage andincreasing interest for MP3 capabilities on devices

8

5.1 TNS GTI 2005 Study

The GTI 2005 bases on data coming from 6807 people

aged 16 to 49, in 15 different countries. These respon-dents used a mobile phone (6517 persons), PDA, or lap-

top and accessed the internet at least once a week. The

study partly focused on the adaption of applications

on mobile devices which we used to excerpt the topten actions that were introduced in that work. These

top ten actions base on the percentage of mobile phone

users who used the corresponding application and can

be seen on Table 6.

5.2 Testing Specification

In order to perform the actions, we had to specify test-ing scenarios where we had to distinguish between dif-

ferent use cases, for example a smartphone user can

send and receive a SMS message of various size with

various recipients. We identified about 40 use cases andspecified a testing protocol for each. An example pro-

tocol is given on Table 7.

Table 7 The Testing Specification for Multi-player Game -Miniblaster

Preconditions:• Miniblaster is installed on two devices• Bluetooth is disabled• settings in Miniblaster:

• music/sound enabled• Two minutes of non-device-usage

Testing:1. Launch Miniblaster on both devices2. Start hosting on one device3. Join game on second device4. Play two rounds5. Host exits game with left selection key6. Second device confirms note and exits7. Two minutes of non-device-usage

Expected Results:• Fall of FREE RAM

• Raise of CPU USAGE

• Bluetooth gets enabled• Data transfer

5.3 Technical Set Up

One of the used devices is a Nokia E61 smartphone

which is running Symbian OS 9.1 and has a QWERTY

keyboard. It supports most of the conventional tech-niques and protocols used in current smartphones, for

example WCDMA and WLAN. A 64Mbyte storage card

is plugged in which allows storage of various files like

videos which then can be viewed on the 320 × 240

pixel display [23]. The installed Symbian-C++ monitor-

ing client was triggered for sending a vector of features

every 20 seconds to our remote server with public IP-

address and attached database. This is done using awebservice via UMTS-connection. The feature vector

that was sent has a size of less than 8 Kbyte and con-

tains about 50 features.

Since malware is only available for older Symbianversions, we additionally used a Nokia 7610 running

Symbian S60 version 7.x in order to monitor Symbian

malware available from P2P networks. The display has

a resolution of 176x208 pixels where the device has a

weight of 118g. It uses an ordinary cell phone keyboardand includes MP3 player.

On Windows Mobile side, we used a HTX TyTN B

smartphone with similar capabilities and configurations

as the Nokia E61.

5.4 Results

On Figure 7, the usage of most of the top ten appli-

cations can be seen: on the upper left the figure showsthe usage of the Short Message Service. It is separated

into four parts: sending empty message, writing and

sending a 150-character message, writing and sending

a 300-character message, and writing and sending a

150-character message with multiple recipients. The up-per center shows the usage of three different kinds of

games: a simple game called Miniblaster, a more com-

plex game named Sky Force Reloaded, and Miniblaster

in multi player Bluetooth mode. The upper right vi-sualizes sending an empty MMS message, writing and

sending a 150-character MMS message, and writing and

sending a MMS message with attached picture. The

center left represents the usage of PDA functionalities;

in detail it describes reading a PDF file. Browsing theinternet can be seen on center graph where different

links were clicked and a picture was downloaded. The

center right refers to sending an image to a paired Blue-

tooth device. The bottom left displays sending of var-ious emails. On the bottom center graph, we used the

browser to download an 8 Mbyte MP3 file which was

played afterwards. Finally, the bottom right graph rep-

resents the creation of a new entry into the calendar.

What we can see although the number of vectorsvaries on the different figures is that each application

affects the corresponding features in a different way:

for example gaming produces much more CPU utiliza-

tion than creating and sending MMS messages. Thisencourages the attempt to apply anomaly detection to

the field of malware detection. A key issue that have

to be solved will be the differentiation between benign

9

0 20 40 60 80 1000

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

SMS_SENT_COUNT

PROCESS_COUNT

CPU_USAGE

0 5 10 15 20 250

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

BLUETOOTH_STATUS

PROCESS_COUNT

CPU_USAGE

0 5 10 15 20 25 30 35 40 450

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

MMS_SENT_COUNT

PROCESS_COUNT

CPU_USAGE

0 1 2 3 4 5 6 7 8 90

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

INACTIVE

PROCESS_COUNT

CPU_USAGE

0 10 20 30 40 500

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

CONNECTION_COUNT

HD_FREE

PROCESS_COUNT

CPU_USAGE

0 2 4 6 8 100

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

INACTIVE

BLUETOOTH_STATUS

PROCESS_COUNT

CPU_USAGE

0 10 20 30 40 50 600

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

MAIL_SMTP_SENT_COUNT

PROCESS_COUNT

CPU_USAGE

0 10 20 30 40 50 60 700

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

CONNECTION_COUNT

HD_FREE

PROCESS_COUNT

CPU_USAGE

0 2 4 6 8 10 120

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

INACTIVE

PROCESS_COUNT

CPU_USAGE

Fig. 7 Actions monitored on a Nokia E61: u.l. sending SMS messages, u.c. simple/3D/multiplayer gaming, u.r. sending MMS messages,c.l. PDA function reading .PDF file, c.c. internet browsing, c.r. Bluetooth data transfer, b.l. sending email, b.c. mp3 download, b.r.PDA function creating new calendar entry

and malicious software with similar functionalities. The

approach of this paper follows the assumption that hav-

ing only few features that are affected in a differentways might already enable detection algorithms to dis-

tinguish between soft- and malware.

Fig. 9 Pictures of smartphone users taken and sent by malware.

5.4.1 Malware Monitoring Results

We monitored several malwares on our Symbian de-

vices. On the older Nokia 7610, we recorded malicious

behavior of Blankfont.A, Hobbes.A, Cardblock.A, Mab-

tal.A, Fontal.A, and Dampig.A. Additionally, we cre-ated testing malware for newer Symbian version. The

monitoring results can be seen on Figure 8.

For understanding the malware effects and moni-

toring results, we give a brief introduction to the corre-

sponding malware behavior: Blankfont.A replaces icon

files with corrupted ones. Hobbes.A drops corrupted

binaries. Cardblock.A block memory cards and deletescritical system folders. Mabtal.A drops other malwares.

Fontal.A installs corrupted fonts. Dampig.A disables

applications and drops malware. As we mentioned be-

fore, we also used the malware proposed by Jamaluddinet al. [17]. If activated, this malware sends a SMS mes-

sage every time the key “2” is pressed. In Figure 8 bot-

tom left, every time the SMS SENT COUNT increases,

an increase of processes and CPU busyness and a de-

crease of available RAM can be observed. At vectorcount 96 we determined that a Nokia E61 device can

only hold 100 SMS messages which lead to the deletion

of these. Additionally, we implemented two more test-

ing malwares. The first malware takes a picture throughthe front camera, triggered by key strokes, and sends

this via MMS to a predefined mobile phone number.

Example pictures can be seen on Figure 9. The second

malware is remotely controlled by SMS messages. On

receive of predefined content and strings, the malwaredeletes the complete phonebook.

16 This class was removed since all values are already repre-sented

10

0 20 40 60 80 1000

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

HD_FREE

INACTIVE

PROCESS_COUNT

INSTALLED_APPS

TASK_COUNT

CPU_USAGE

Malware

0 5 10 15 200

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

HD_FREE

INACTIVE

PROCESS_COUNT

INSTALLED_APPS

TASK_COUNT

CPU_USAGE

Malware

0 5 10 15 20 25 30 35 40 450

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

HD_FREE

INACTIVE

PROCESS_COUNT

INSTALLED_APPS

TASK_COUNT

CPU_USAGE

Malware

0 10 20 30 40 50 600

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

HD_FREE

INACTIVE

PROCESS_COUNT

INSTALLED_APPS

TASK_COUNT

CPU_USAGE

Malware

0 5 10 15 20 25 30 35 400

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

HD_FREE

INACTIVE

PROCESS_COUNT

INSTALLED_APPS

TASK_COUNT

CPU_USAGE

Malware

0 5 10 15 20 25 30 35 40 450

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

HD_FREE

INACTIVE

PROCESS_COUNT

INSTALLED_APPS

TASK_COUNT

CPU_USAGE

Malware

0 20 40 60 80 100 120 140 1600

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_RAM

SMS_SENT_COUNT

PROCESS_COUNT

CPU_USAGE

Malware

0 200 400 600 800 10000

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_ RAM

INACTIVE

SMS_IN

MMS_IN

SMS_SENT

MMS_SENT

HD_FREE

REMOVABLE_FREE

PROCESSES

CPU_USAGE

SIGNAL_STRENGTH

Malware

0 50 100 150 200 250 300 3500

0.2

0.4

0.6

0.8

1

Vector Count

No

rma

lize

d L

en

gth

FREE_ RAM

INACTIVE

SMS_IN

MMS_IN

SMS_SENT

MMS_SENT

PROCESSES

CPU_USAGE

SIGNAL_STRENGTH

Malware

Fig. 8 Monitored malware behavior on a Nokia 7610: t.l. Blankfont.A, t.c. Hobbes.A, t.r. Cardblock.A, c.l. Mabtal.A, c.c. Fontal.A,c.r. Dampig.A, b.l. Jamaluddin malware, and on a Nokia E61: b.c. picture malware, and b.r. phonebook malware

6 Client-side Improvements

Our approach was to find as many system character-

istics as possible and necessary that can be usable for

any remote anomaly detection system. After being ableto retrieve 70 different features describing the current

state of a smartphone, the system characteristics were

collected continuously over a long period of time. The

resulting data was taken to evaluate common detec-tion approaches. Furthermore, this data was analyzed

in detail to detect conspicuous details helping us to re-

duce the number of observed features. These evalua-

tions showed that 38 features can be ignored since they

had no impact on application/malware detection.

The remaining 32 features were analyzed for find-

ing redundancies that allow additional removal. This is

necessary since processing large amounts of data causes

high CPU usage and memory consumption which is akey issue for limited devices. Several methods for de-

tecting redundant data are known from the field of

machine learning. Because the Principal Component

Analysis (PCA) has proven its utility [11], it was ap-

plied for this task. PCA is a method that is applied tomulti-dimensional data in order to reduce the number

of dimensions. This algorithm includes various mathe-

matical steps starting with subtracting the respective

mean from each existing dimension. Then, the covari-ances are calculated and the corresponding eigenvec-

tors and eigenvalues are determined. The features can

be ranked by the calculated eigenvalue where the lower

the eigenvalue is the less important it gets for the re-

mote analysis.

For automating these steps several tools provide

methods performing such an analysis. For this work

the Weka17 tool was used to analyze a set of 3000 fea-

ture vectors which were recorded on a Nokia E61. Thisanalysis identified nine relevant classes of features. A

class represents correlating features that have measur-

able impact on each other. Strong correlation means

it is less important to look at all of them. Hence, wecould reduce the number of features to one representa-

tive from each class which can be seen on Table 9. The

detailed results can be found on Table 8.

Beside the identified features from the PCA, we rec-

ommend to monitor additional features that are strongly

related to smartphone malware. Having an eye on the

number of installed applications can help to track downsources for anomalies. Whenever an anomaly appears as

soon as an application is installed, it is probable that

this anomaly was caused by the newly installed appli-

cation. Since several malwares use Bluetooth and MMS

in order to propagate, it makes sense watching the con-nections and incoming MMS messages. Additionally,

the anomaly detection system probably misses an in-

fection. Therefore, monitoring outgoing messages can

help to track malicious programs sending local data toa Trojan horse master or to premium services in order

to cause high costs. The additional features are marked

17 http://www.cs.waikato.ac.nz/ml/weka/

11

Table 8 Principal component analysis results

Eigenvalue Rank Feature 1 F 2 F 3 F 4 F 5

0.6001 1 0.38FREE RAM

-0.377DEBUG2

-0.377TASK CNT

-0.375THREAD CNT

-0.375PROC CNT

0.4414 2 0.544BATTERY

+0.525CONNS

+0.521CONNS DEL

-0.223HD FREE

+0.134TASK CNT

0.3519 3 -0.693CELL ID

-0.683LOCATION

-0.17 USR IDL -0.095HD FREE

+0.084DEBUG1

0.2749 4 -0.557USR IDLE

+0.499CPU USG

-0.381HD FREE

-0.374USR IDL B

+0.165BATTERY

0.2029 5 -0.600DEBUG1

+0.579CPU USG

+0.436USR IDL

-0.167BATTERY

+0.154HD FREE

0.1413 6 0.678 DEBUG1 -0.526USR IDL B

+0.373USR IDL

+0.29CPU USG

-0.119BATTERY

0.0934 7 0.851HD FREE

-0.366USR IDL

+0.274BATTERY

+0.191CPU USG

+0.08DEBUG 1

0.052 8 -0.733USR IDL B

-0.517CPU USG

-0.383DEBUG1

+0.164HD FREE

-0.064THREAD CNT

0.0159 9 -0.706CELL ID

+0.7LOCATION

+0.062USR IDL

-0.045USR IDL B

-0.043DEBUG1

Table 9 Ranked and recommended features

Rank Feature Description

1 FREE RAM Amount of availableRAM

2 CONN Created TCP/IP con-nections

3 USR IDL User idle time in sec-onds

4 CPU USG CPU usage in percent

5 BATTERY Battery charge level

618 USR IDL B Boolean user idle indi-cator

7 HD FREE Amount of availablehard disk space

8 THREAD CNT Amount of runningthreads

9 CELL ID mobile phone networkcell ID

10a INST APPS Number of installedapplications

11a BT CONN Amount of openedBluetooth connection

12a SMS SENT Amount of sent SMSmessages

13a MMS SENT Amount of sent MMSmessages

14a MMS RECV Number of receivedMMS messages

with an “a” on Table 9 where a count of fourteen fea-

tures was achieved in total.

The selected features were evaluated with a labeledmonitoring data set in which the browser of the moni-

tored device was started on few occasions. When hav-

ing the objective to detect malware, detecting arbitrary

running programs is the first cornerstone. If it is notpossible to detect anomalies caused by such a program,

then detecting anomalies caused by malware is certainly

not possible. Problems in detecting random programs

will result in a high false positive rate when detecting

malware. The task of detecting random programs is ob-

viously not trivial, because other programs are runningat the same time. For anomaly detection, the normal

state was defined as the recorded state before the pro-

gram to be detected was started first. This normal data

was used for training.

On the detection side we used algorithms basing onself-organizing maps (SOM) [2,18,25], artificial immune

system (AIS) [20,16,13]), and an algorithm we called

linear prediction in order to detect the browser activ-

ity. The linear prediction algorithm detects changes by

checking four predecessors of a chosen feature. Thesefour predecessors are are used for estimating a probable

successor. From the difference of this successor to the

actual measured state, the anomaly value is concluded.

For evaluation, the accuracy, true positive rate, false

positive rate, quality, and false alarms were measuredwhere the definitions of these can be found in the Ap-

pendix. Especially the true positive and false alarm rate

are of interest; the true positive rate describes the rate

of correctly identified incidents. The false alarm rate

indicates the rate of falsely identified normal events.Figure 10 visualizes the results of four different fea-

ture sets. The first set was created by feature selection,

based on PCA (labeled as selected). The second set ad-

ditionally includes our recommended features (labeledas selected 2). For better assessing the impact of the

feature selection, two more sets were included: one set

including all features (labeled as all) and one set of ran-

dom features. The random set was sized identically to

the selected set.

It is obvious that different detection algorithms per-

form differently. But surprisingly, the selected set caused

a three times better detection of true positives than

12

Accuracy TP Rate FP Rate Quality FA Rate 0

0.2

0.4

0.6

0.8

1

Norm

aliz

ed L

ength

selected

selected_2

random

all

Accuracy TP Rate FP Rate Quality FA Rate 0

0.2

0.4

0.6

0.8

1

Norm

aliz

ed L

ength

selected

selected_2

random

all

Accuracy TP Rate FP Rate Quality FA Rate 0

0.2

0.4

0.6

0.8

1

Norm

aliz

ed L

ength

selected

selected_2

random

all

TP Rate FA Rate 0

0.05

0.1

0.15

0.2

Norm

aliz

ed L

ength

selected

selected_2

random

all

TP Rate FA Rate 0

0.02

0.04

0.06

0.08

0.1

Norm

aliz

ed L

ength

selected

selected_2

random

all

TP Rate FA Rate 0

0.05

0.1

0.15

0.2

0.25

Norm

aliz

ed L

ength

selected

selected_2

random

all

Fig. 10 Detection results top: AIS all, SOM all, linear prediction all; bottom: AIS detail, SOM detail, linear prediction detail.

the complete set with the AIS algorithm. The recom-

mended feature set resulted in a two times better true

positive detection. Further investigations showed thatthe reason for this is that the more features are used in

AIS the less precise its detection gets. Therefore, it can

be stated that similar algorithms benefit from smaller

feature sets where the results of the PCA work best.The SOM algorithm worked best with the complete fea-

ture set while while the SOM with our recommended

set applied detected about one percent less true posi-

tives. Reducing the amount of features from 70 to 14

results in a save of 80% in terms of disk space. Addition-ally, computation and communication costs are reduced

significantly which has a positive impact on the battery

lifetime. Comparing these benenfits with the loss of one

percent in true positive detection, this is a deteriorationthat seems tolerable, especially in the field of mobile

devices. The linear prediction algorithm works slightly

better with the PCA and our recommended feature set

than with the complete one. Therfore, similar simple

appraoches will benefit from a reduced set too.

7 Conclusion and Future Work

In this paper, we demonstrated how a smartphone can

be monitored in order to transmit feature vectors to a

remote server. The gathered data is intended to be used

for anomaly detection methods that analyze the data

for distinguishing between normal and abnormal behav-ior. In general, applying machine learning algorithms

to anomaly detection on smartphone data can indicate

malicious software activity, where AIS [20,16,13] per-

formed slightly better than SOM [2,18,25]. In our case,only 14 features were needed to achieve first acceptable

results. Our recent findings can be applied to every plat-

form allowing the extraction of system-related data and

are not limited to mobile operating systems. Further-

more, testing of further algorithms might lead to bet-

ter results as well as creating bigger data sets includingmore vectors to be trained and analyzed. Limitations

can be found in the lack of available smartphone mal-

ware for newer platforms. In the case of Symbian OS,

the only way to perform realistic tests is to create mal-ware on your own.

Gathering more data from different kinds of smart-

phones that are running different operating systems,

like Google Android or iPhone, will be one of the tasksthat we will focus in future. Furthermore, additional

malware is needed for increasing the quality of our data

sets. If these sets are big enough, we will start to test

methods from various fields from machine learning in

order to improve the detection of malicious activities.

References

1. Abowd, G.D., Iftode, L., Mitchel, H.: The Smart Phone: AFirst Platform for Pervasive Computing. IEEE PervasiveComputing pp. 18–19 (2005). April-June

2. Albayrak, S., Scheel, C., Milosevic, D., Muller, A.: Combin-ing Self-Organizing Map Algorithms for Robust and ScalableIntrusion Detection. In: M. Mohammadian (ed.) Proceedingsof International Conference on Computational Intelligencefor Modelling Control and Automation (CIMCA 2005), pp.123–130. IEEE Computer Society (2005)

3. Allen, J., Christie, A., Fithen, W., McHugh, J., Pickel, J.,Stoner, E.: State of the Practice of Intrusion Detection Tech-nologies. Tech. Rep. CMU/SEI-99-TR-028, Carnegie MellonSoftware Engeneering Institue, Pittsburgh, PA 15213-3890(2000)

4. Axelsson, S.: Intrusion detection systems: A survey and tax-onomy. Tech. Rep. 99-15, Department of Computer Engi-neering Chalmers University of Technology Goteborg, Swe-den (2000)

5. Buennemeyer, T.K., Nelson, T.M., Clagett, L.M., Dunning,J.P., Marchany, R.C., Tront, J.G.: Mobile device profilingand intrusion detection using smart batteries. In: HICSS ’08:Proceedings of the Proceedings of the 41st Annual Hawaii

13

International Conference on System Sciences, p. 296. IEEEComputer Society, Washington, DC, USA (2008). DOI http://dx.doi.org/10.1109/HICSS.2008.319

6. Bundesverband Informationswirtschaft Telekommunikationund neue Medien e.V.- BITKOM: Mehr Handys als Ein-wohner in Deutschland (2006). URL http://www.bitkom.

de/41015_40990.aspx

7. Bulygin, Y.: Epidemics of mobile worms. In: Proceedings

of the 26th IEEE International Performance Computingand Communications Conference, IPCCC 2007, April 11-13, 2007, New Orleans, Louisiana, USA, pp. 475–478. IEEEComputer Society (2007)

8. Canalys: EMEA Q3 2006 - Highlight From the CanalysResearch (2006). URL http://www.canalys.com/pr/2006/

r2006102.htm. http://www.canalys.com/ (online visited2007.10.04)

9. Cheng, J., Wong, S.H.Y., Yang, H., Lu, S.: Smartsiren: virusdetection and alert for smartphones. In: International Con-ference on Mobile Systems, Applications, and Services (Mo-bisys 2007), pp. 258–271 (2007)

10. Davis, G., Davis, N.: Battery-based intrusion detection. In:Global Telecommunications Conference, 2004. GLOBECOM’04. IEEE, vol. 4, pp. 2250–2255 (2004). DOI 10.1109/GLOCOM.2004.1378409

11. Deegalla, S., Bostrom, H.: Reducing high-dimensional databy principal component analysis vs. random projection fornearest neighbor classification. In: ICMLA ’06: Proceedingsof the 5th International Conference on Machine Learning andApplications, pp. 245–250. IEEE Computer Society, Wash-ington, DC, USA (2006). DOI http://dx.doi.org/10.1109/ICMLA.2006.43

12. Forrest, S., Perelson, A.S., Allen, L., Cherukuri, R.: Self-nonself Discrimination in a Computer. In: Proceedings ofthe IEEE Symposium on Research in Security and Privacy,pp. 202–212. IEEE Computer Society Press (1994)

13. Glickman, M., Balthrop, J., Forrest, S.: A machine learn-ing evaluation of an artificial immune system. Evolution-ary Computation 13(2), 179–212 (2005). DOI 10.1162/1063656054088503

14. Gostev, A.: Mobile Malware Evolution: An Overview, Part1 (2006). URL http://www.viruslist.com/en/analysis?

pubid=200119916

15. Grober, M.: Applications for Symbian. http://www.

mgroeber.de/epoc.htm (15. Aug. 2007)16. Hofmeyr, S., Forrest, S.: Architecture for an Artificial Im-

mune System. Evolutionary Computation Journal 8(4), 443–473 (2000). DOI 10.1162/106365600568257

17. Jamaluddin, J., Zotou, N., Edwards, R., Coulton, P.: MobilePhone Vulnerabilities: A New Generation of Malware. In:Proceedings of the 2004 IEEE International Symposium onConsumer Electronics, pp. 199–202 (2004)

18. Kohonen, T.: Self-Organizing Maps, Springer Series in In-

formation Sciences, vol. 30, Third edn. Springer-Verlag(2001). ISBN 3–540–67921–9, ISSN 0720–678X

19. Lawton, G.: Open source security: Opportunity or oxy-moron? Computer 35(3), 18–21 (2002). DOI http://dx.doi.org/10.1109/2.989921

20. Luther, K., Bye, R., Alpcan, T., Albayrak, S., Muller, A.:A Cooperative AIS Framework for Intrusion Detection. In:Proceedings of the IEEE International Conference on Com-munications (ICC 2007) (2007)

21. Microsoft Corporation: Windows Mobile (2007). URLhttp://www.microsoft.com/germany/windowsmobile/

default.mspx. http://www.microsoft.com/ (online visited2007.10.04)

22. Miettinen, M., Halonen, P., Hatonen, K.: Host-Based In-trusion Detection for Advanced Mobile Devices. In: AINA

’06: Proceedings of the 20th International Conference on Ad-vanced Information Networking and Applications - Volume2 (AINA’06), pp. 72–76. IEEE Computer Society, Wash-

ington, DC, USA (2006). DOI http://dx.doi.org/10.1109/AINA.2006.192

23. Nokia: Nokia E61. http://www.nokia.co.uk/A4221036

(15. Aug. 2007) (2007)24. Oberheide, J., Cooke, E., Jahanian, F.: Cloudav: N-version

antivirus in the network cloud. In: Proceedings of the 17thUSENIX Security Symposium (Security’08). San Jose, CA(2008)

25. Rhodes, B.C., Mahaffey, J.A., Cannady, J.D.: Multiple self-organizing maps for intrusion detection. In: 23rd Na-tional Information Systems Security Conference - PRO-CEEDINGS, PAPERS, and SLIDE PRESENTATIONS(2000). http://csrc.nist.gov/nissc/2000/proceedings/

2000proceedings.html (2007-04-19)26. Roussos, G., March, A.J., Maglavera, S.: Enabling Pervasive

Computing with Smart Phones. IEEE Pervasive Computingpp. 20–27 (2005). April-June

27. Spafford, E., Zamboni, D.: Data Collection Mechanisms forIntrusion Detection Systems. CERIAS Technical Report2000-08, CERIAS, Purdue University, 1315 Recitation Build-ing, West Lafayette, IN (2000)

28. Symbian Software Limited: Symbian OS - the mobile operat-ing system (2007). http://www.symbian.com (online visited2007.10.04)

29. TNS Technology: Consumer Trends in Mobile Applications -A TNS Technology Briefing for Technology Decision Mak-ers (2005). http://www.tns-global.com/ (online visited2007.10.04)

A Definitions

The detection result charts base on the following definitions whereTable 10 shows a description on the detection classification:

– TP = True Positives

– FN = False Negatives

– FP = False Positives

– TN = True Negatives

– FA = False Alarm

Table 10 Detection event description

Detected TN FP FN TP

Reality real negatives real positives

Accuracy =TP + TN

TP + TN + FP + FN(1)

TP Rate =TP

TP + FN(2)

FP Rate =FP

TP + FP(3)

Quality =TP

TP + FN(4)

False Alarm =FP

FP + TN(5)

14

Aubrey-Derrick Schmidt

received his Diplom-

Informatiker with main

focus on artificial in-

telligence and commu-nication systems from

Technische Universitat

Berlin in 2006. He is a

Ph.D. candidate in thedepartment of electrical

engineering and com-

puter science at Tech-

nische Universitat Berlin. His research interests include

smartphone security, monitoring, and intrusion detec-tion.

Christian Scheel received

his Diplom-Informatikerwith main focus on ar-

tificial intelligence and

communication systems

from Technische Uni-

versitat Berlin in 2005.He is a Ph.D. candi-

date in the department

of electrical engineering

and computer science atTechnische Universitat

Berlin. His research in-

terests include machine learning, anomaly detection,

and agent communities.

Frank Peters has worked

as a software developer

for many years in var-

ious companies. He de-

cided to finish his edu-cation, is currently en-

rolled as diplom stu-

dent at Technische Uni-

versitat Berlin, and isabout to earn his de-

gree in Computer Sci-

ence. His main focuses

are artificial intelligence

and security.

Dr. Seyit Ahmet Cam-

tepe received the B.S.

and M.S. degrees in

Computer Engineering

at Bog(azii University,in 1996 and 2001 re-

spectively, under super-

vision of Prof. M. Ufuk

Caglayan. He receivedthe Ph.D. degree in

Computer Science at

Rensselaer Polytechnic Institute, in 2007, under super-

vision of Assoc. Prof. Blent Yener. Currently, He is

working as a senior researcher at DAI-Labor - Tech-nische Universitaet Berlin under supervision of Prof.

Dr.-Ing. habil Sahin Albayrak. His research interests

include autonomous security, economy of information

security, malicious cryptography, key management, dis-tributed systems security, attack modelling , detection,

and prevention, social network analysis and VoIP secu-

rity.

Prof. Dr. Sahin Al-bayrak is founder and

scientific director of the

Distributed Artifcial In-

telligence Laboratory. Hereceived his Ph.D. from

Technische Universitat

Berlin in 1992. Since

July 2003 Prof. Al-

bayrak holds the chairof Agent-Oriented Tech-

nologies (AOT) in Busi-

ness Applications and Telecommunication at Technis-

che Universitat Berlin. He is member of IEEE, ACM,GI, and AAAI.

Florian Lamour is a

technical computer sci-

ence diplom student withmain focus on hardware

and software techniques

at Technische Univer-

sitat Berlin.