Behavior Analysis Of Mobile System In Cloud Computing

DOI : 10.17577/IJERTV2IS50541

Download Full-Text PDF Cite this Publication

Text Only Version

Behavior Analysis Of Mobile System In Cloud Computing

K. Saritha

[Ii M.Tech]-Cse, Drkvscew College Kurnool

R. Samaiah

Asst. Professor, Dept Of CSE, Dr. KVSCEW, Kurnool

ABSTRACT

Recently, several mobile services are changing to cloud-based mobile services with richer communications and higher flexibility. We present a new mobile cloud infrastructure that combines mobile devices and cloud services. This new infrastructure provides virtual mobile instances through cloud computing. To commercialize new services with this infrastructure, service providers should be aware of security issues. In this paper, we first define new mobile cloud services through mobile cloud infrastructure and discuss possible security threats through the use of several service scenarios. Then, we propose a methodology and architecture for detecting abnormal behavior through the monitoring of both host and network data. To validate our methodology, we injected malicious programs into our mobile cloud test bed and used a machine learning algorithm to detect the abnormal behavior that arose from these programs

Keywords

Mobile cloud computing, mobile cloud infrastructure, mobile cloud service scenarios, abnormal behavior monitoring, machine learning

  1. INTRODUCTION

    Applications for these devices. According to, there are more available as of March 2011 and these numbers are increasing benefit users by richer communications and higher flexibility. Cloud-based mobile services. Cloud-based mobile services computing infrastructure instead of low-speed mobile devices. In line with the numerous electronics manufacturers infrastructure. Virtual smart phone over IP is one example Massive computational processing is performed through cloud notification, and enriched call with multi-media content sharing. Producing new mobile devices such as smart phones and smart provided with the virtualization of mobile devices in cloud rapidly. One recent trend for mobile services is their change to richer communications and higher flexibility can be provided Richer communications mean advanced techniques supporting services, we expect that new mobile cloud services will be such as enhanced phonebooks, messaging with push tablets, various mobile services are being provided as than 200,000 Android and 300,000 iPhone applications The data stored in cloud infrastructure can be accessed at any Through the

    convergence of mobile devices and cloud time and from anywhere through mobile devices. As a result, to mobile device users through cloud computing of provisioning virtual mobile instances to users. Each virtual instance in cloud infrastructure represents a mobile device, and users can connect to and use this instance. In this paper, we present a mobile cloud infrastructure as an infrastructure that provides virtual mobile instances, and those instances are managed in cloud computing architecture with massive computational processing power and storage. However, service providers should be aware of security problems that may arise when they adopt and launch new cloud services. According to an IDC report, when questioned, 74.6% of service providers answered that the most important issue for cloud services is security. In addition, recent cloud computing attacks make it difficult to guarantee the trust and safety of cloud services. For mobile cloud services, malicious mobile applications can be run on virtual mobile instances and therefore any security problems may be much severe if those applications target on the virtualization of mobile cloud infrastructure.

  2. RELATED WORK

    1. Monitoring Abnormal Behavior in Mobile Devices:

      Some previous studies have focused on the detection of malware by monitoring behavior in mobile devices. Shabtaietal.Implemented a behavioral framework to detect malware for Android mobile devices. They extracted the features of CPU, memory, and network usages, monitored these using their mobile application, and then detected malware using several machine learning algorithms. Demopoulos et al. focused on malware that are related to spamming, but their method cannot detect more general malware. They defined the behavior of mobile devices as web browsing, SMS, phone calls, and were able to detect abnormal behavior using machine learning algorithms available in Weka with high accuracy. There are other studies that also focus on abnormal behavior in mobile devices, but those studies defined the behavior of mobile devices differently. Enck et al. related abnormal behavior of mobile devices to privacy information on mobile devices. Their framework monitors the privacy data by observing event lists in Android devices, and detected that several mobile applications can misuse

      users private information. Burguera et al. correlated behavior with the number of each system call counter, and focused on some important system calls that are related to normal applications and malware such as access(), chmod(), and chown(). However their framework requires root permission in Android devices in order to monitor the number of system calls in mobile devices.

    2. Abnormal Behavior in Cloud Computing Infrastructure:

      Several research groups have targeted intrusion detection for cloud computing infrastructure. Roschke et al. discussed the requirements and proposed architecture that can detect malicious behaviors in cloud infrastructure. They identified Intrusion Detection System (IDS) management issues in the cloud considering both Host IDS (HIDS) and Network IDS (NIDS). However, their study does not focus on how those malicious behaviors are defined and detected in cloud infrastructure. Vieira et al. proposed architecture for grid and cloud computing intrusion detection. In their architecture, they performed behavior analysis with the collaboration of each node, and also used knowledge-based analysis. However, their architecture does not reflect virtualization of each node when virtual instances are provided to users through cloud computing infrastructure. Moreover, their analysis is performed in service nodes, which can influence on the performance of cloud computing.

  3. MOBILE CLOUD SERVICE AND SCENARIOS:

    This section defines a new mobile cloud service through the virtualization of mobile devices in cloud infrastructure. We describe two main service scenarios to explain how this mobile cloud service can be used. Service scenarios are useful to discuss security threats on mobile cloud infrastructure, because they include users, places, mobile devices, and network types, and users interesting contents.

    1. Defining Mobile Cloud Computing and the Concept of Mobile Cloud Service:

      Defining mobile cloud computing is important for the characterization and explanation of mobile cloud services. There are several definitions of mobile cloud computing that assign larger role to mobile devices for cloud computing. For example, Warner et al. defined mobile cloud computing as accessing the cloud through mobile devices and also mobile devices becoming part of a larger cloud construct [11].

      Marinelli referred to mobile cloud computing as a term meaning that a number of mobile devices construct a cloud computing group, and jobs are allocated to various device nodes in order to execute computing jobs faster [10]. In this paper, we define mobile cloud computing as processing jobs for mobile devices in cloud computing infrastructure and

      delivering job results to mobile devices. This definition is also mentioned in other studies [17][21][22]. Based on this definition, we propose a new mobile coud service as providing virtual mobile instances through mobile cloud computing. The proposed mobile cloud service provides virtual mobile instances through the combination of a mobile environment and cloud computing. Virtual mobile instances are available on mobile devices by accessing the mobile cloud infrastructure. This means that users connect to virtual mobile instances with their mobile devices and then use computing resources such as CPU, memory, and network resources on mobile cloud infrastructure. In this case, such mobile devices will have smaller roles to play than current mobile devices. Mobile cloud service providers can then distribute mobile applications which can connect to mobile cloud infrastructure, view, and interact to virtual mobile instances. Fig. 1 illustrates the concept of our defined mobile cloud service. By mobile cloud services, any mobile devices can be a super computer and they can support several rich services. So always keeping on computing life will be realized.

      Figure 1. The Concept behind our Defined Mobile Cloud Service

      • Mobile Cloud Computing is the combination between Mobile Networks and Cloud Computing to bring benefits for mobile customers, cloud providers, and mobile network operators. For customer side: Mobile Cloud Computing provides mobile users with the data processing and storage services in clouds. Therefore mobile devices do not need a powerful configuration (e.g., CPU speed and memory capacity) since all the complicated computing modules can be processed in the clouds. In addition, mobile customers can gain very various convenient services from cloud providers.

      • For cloud provider side: MCC makes a big chance for cloud providers to provide services for mobile customers (e.g., security, storage, offloading).

      • For mobile network operators: it is a "bridge" between mobile users and cloud computing. It is clear to see that when users' demand increases, the "traffic crossing the bridge" is also increased. This makes a big revenues for mobile network operators.

      3.1.1 Service Scenarios for Mobile Cloud Services Security threats to our mobile cloud service depend on how the service is prepared and delivered from the service providers to the actual users. We grouped together possible service scenarios on our mobile cloud service into two main categories.

      The first is for individual personal users and the other for office workers. Individual users use the mobile cloud service for entertainment and other individual purposes, and office workers mainly use it for smart work.

      1. Individual users:

        Individual users are categorized as normal users, advanced users and developers according to usage types and their requirements. Following are descriptions of each individual user category and Table I provides a summary of possible service scenarios for each case in.

        • Normal Users: These users are more interested in the services available from the mobile cloud environment than environment itself. The cloud environment required by these users is somewhat fixed with little change necessary.

        • Advanced Users: These users are aware of overall mobile cloud services and more interested in cloud resources than normal users. They also require a cloud environment that varies more frequently.

        • Developers: These users are aware of overall mobile cloud services and require a cloud environment that is specific, varied and which changes frequently.

        Normal User

        Place

        Device

        Network

        Consuming Content

        Subway

        Tablet

        3G/4G

        Online game, Movie

        Home

        Laptap

        Home Wi-Fi

        Movie

        Advanced User

        Place

        Device

        Network

        Consuming Content

        Office

        Smart phone

        Office Wi-Fi

        Smart Work

        Bus

        Laptop

        3G/4G

        Simulation

        Normal User

        Place

        Device

        Network

        Consuming Content

        Subway

        Tablet

        3G/4G

        Online game, Movie

        Home

        Laptap

        Home Wi-Fi

        Movie

        Advanced User

        Place

        Device

        Network

        Consuming Content

        Office

        Smart phone

        Office Wi-Fi

        Smart Work

        Bus

        Laptop

        3G/4G

        Simulation

        Table 1. Scenario items for individual users

        Developer User

        Place

        Device

        Network

        Consuming Content

        Subway

        Tablet

        Public Wi-Fi

        Server management

        Home

        Tablet

        3G/4G

        Read dig-size data

        We show one example of service scenarios for individual users. This is a scenario for mobile application developers who develop mobile applications and run a server for the application in cloud.

        Actor: Mobile application developers

        Interests: To build and test her or his mobile application in various mobile environments.

        Preconditions: Mobile cloud service should support various mobile environments customizing function Main Scenario: Actor requires several mobile environments with different display size and hardware resources.

        Actor accesses each virtual mobile instance and tests her or his application whether or not it works well in different environments with tablets through public Wi- Fi. Actor requires additional virtual mobile instances with strong hardware resources and uses it as a server for her or his application.

      2. Office workers

      We categorized office workers as staff in a main office, staff in overseas offices and subcontractors according to their office location and relationship to the company. Assuming that a mobile office system is installed in the main office, Table II Provides a summary of possible service scenarios with different requirements for each case of office workers.

      Staff in a main office: These users work on mobile office systems installed in the main office.

      Staff in overseas offices: These users access mobile office systems from overseas offices to the main office. The network condition in foreign countries may be poorer than domestically accessed mobile offices.

      Subcontractors: These users contract as developers of the main office, co-work or run a project together with the company.

      If their contract is no longer valid, subcontractors should not use mobile office systems provided from the main office.

      Table 2. Scenario items for office workers

      Staff in a Main Office

      Place

      Device

      Network

      Consuming content

      Subway

      Smart phone

      3G/4G

      Messenger, schedule-mail

      Office

      Laptap

      Office Wi- Fi

      word, VoIP

      Home

      Tablet

      Home Wi- Fi

      Word, Approval

      Staff in Overseas Offices

      Place

      Device

      Network

      Consuming content

      Customer office

      Smart Phone

      Public Wi- Fi

      Document View

      Office

      Laptop

      Office Wi- Fi

      Payment, video conference

      Subcontractors

      Place

      Device

      Network

      Consuming content

      Office

      Laptop

      Office Wi- Fi

      Program development,testing

      Outdoor

      Smart phone

      Public Wi- Fi

      Project management

      The following is one example of service scenarios for office workers: staff in overseas offices.

      Actor: Staff in overseas offices

      Interests: To access mobile office environment in mobile cloud with high speed and stability from overseas.

      Preconditions: Special network channel such as VPN should be set to guarantee high speed connection between overseas office and mobile cloud infrastructure.

      Main Scenario: Actor accesses mobile office and shares multimedia files to co-workers in the main office with high speed connection. Actor accesses mobile office via public Wi-Fi and check the payment.

  4. METHODOLOGY AND ARCHITECTURE FOR ABNORMAL BEHAVIOR DETECTION

    1. Our Abnormal Behavior Detection Methodology

      Behaviour means the actions of not only each virtual mobile instance in mobile cloud infrastructure itself but also mobile applications running virtual

      mobile instances. For example, a mobile application should use some virtual resources such as CPU or memory when it executes an action in the mobile cloud infrastructure. The application generates some network traffic data if it needs network connectivity that is internal or external to the mobile cloud infrastructure. These kinds of actions change the value of some features of virtual resources in the mobile cloud infrastructure. Thus, we assume that each mobile application and each user has a unique behavioral pattern. In this paper, we propose a monitoring and detecting methodology for abnormal behavior of virtual mobile instances and applications. If abnormal behavior is detected in one virtual mobile instance, it means that something is wrong or changed in this virtual mobile instance. At such a point a detection alarm would be notify the mobile cloud infrastructure or the actual user of this virtual mobile instance.

      Virtual mobile instances in the infrastructure have the same role as normal mobile devices such as smart phones and tablet PCs. On such normal mobile devices, most current vaccine applications detect malware through a signature-based method. Signature- based methods can detect malware in a short space of time with high accuracy, but they cannot detect new malware whose signature is unknown or has been modified. If mobile cloud services are provided, much more malicious applications may appear including new and modified malware. Therefore vaccine applications cannot detect and prohibit them with only signature- based method in the future. Moreover, mobile cloud infrastructure supports a huge number of virtual mobile instances. When a malware is compromised on a virtual mobile instance, it can be delivered to other virtual mobile instances in the same mobile cloud infrastructure.

    2. Architecture for Monitoring Mobile Cloud Infrastructure

      Fig. 2 illustrates the architecture for mobile cloud infrastructure and the overall structure to detect abnormal behavior in the infrastructure. Mobile cloud nodes are divided into production service and non- production service nodes. Production service nodes are a group of service nodes providing services to customers directly, and non-production service nodes support mobile cloud services indirectly, such as through the processing of background jobs, managing production cluster nodes, and replacing nodes if production service nodes malfunction.

      In production service nodes, each node is virtualized to provide virtual mobile instances. Hypervisors, which are installed on the physical nodes, divide privileged and non-privileged domain, and manage virtual instances (creation, modification, and deletion). Mobile virtual instances run on non- privileged domains. To monitor each virtual mobile instance, our proposed architecture installs an agent mobile application into virtual mobile instances. This agent application monitors the host data on each virtual mobile instance. Network data is monitored through

      port-mirroring that is provided by virtual routers.We monitor host data using agent programs which are installed in each virtual mobile instance. It can monitor mobile host information in detail, including CPU and memory usage in a virtual mobile instance.

      Figure 2. Proposed Architecture for Abnormal Behaviour Monitoring and Detection in Mobile Cloud Infrastructure

      For network monitoring, we used port mirroring functionality via a virtual router. The virtual router installed on the hypervisor is designed to link and manage virtual network interfaces and to control the route of network traffic in those interfaces. To minimize the overhead of the hypervisor in each physical node, we installed one additional non-mobile virtual instance (VM for NetMon) on non-privileged domain, and configured the entire traffic in all virtual mobile instances so that it is mirrored to this instance. Fig. 3 illustrates a context diagram for network information monitoring. We can mirror network traffic from each virtual mobile instance to a VM for NetMon by applying the virtual routing configuration. Real network data is transmitted through eth0 and peth0, while control data including mirrored network data are transmitted through etp and petp.

      Synchronous

      communica

      In VM for NetMon, there are two modules: the flow generator and the feature extractor. The flow generator converts copied packets to flows. It possesses all of the information on the network traffic including IP header, TCP/UDP header, and payload, the size of which is too large for use as features. The feature extractor extracts useful features such as number of flows, flow size and others from said information using network analysis tool, Tshark. Then, it sends the feature information to the analyzer in the non-production service nodes. The detailed information from the flow generator can be used later for additional analysis of the detail network status in the mobile cloud infrastructure. Finally, the analyzeranalyzes the data of each virtual mobile instance and network data in each node in order to detect abnormal behavior. To detect abnormal behavior, the anomaly analyzer uses Random Forest (RF) machine learning Algorithm. If abnormal behavior is detected, an alarm is delivered to network administrators or customers.

        1. Target Host and Network Features

          The analyzer uses collected data from agents in virtual mobile instances, and virtual routers to detect abnormal behavior Host Features

          Host Features

          If we get the root permission in each virtual mobile instance, then we can monitor all events, including kernel-level data, and we can detect abnormal behavior more specifically and accurately. However, rooting means that it is more easily exposed to malware and becomes more dangerous than would normally be the case. Shabtai et al. analyzed the relationship between possible monitoring features and malware behavior. However, the number of monitoring features was more than 80, with many of them showing low dependency. Therefore, we chose about 20 features from among the 80 which show high dependency on normal and abnormal behavior, and which are summarized in Table 3.

          CPU (%)

          Memory (KB)

          Process

          CPU Usage (User)

          Free Memory

          CPU Usage

          CPU Usage (System)

          Active Memory

          # of Thread

          Inactive Memory

          Memory Usage

          Anonymous Memory

          Context Switches

          Mapped Pages

          Non-voluntarily Context Switches

          Network

          OS

          Total Tx Bytes

          CPU (%)

          Memory (KB)

          Process

          CPU Usage (User)

          Free Memory

          CPU Usage

          CPU Usage (System)

          Active Memory

          # of Thread

          Inactive Memory

          Memory Usage

          Anonymous Memory

          Context Switches

          Mapped Pages

          Non-voluntarily Context Switches

          Network

          OS

          Total Tx Bytes

          Table 3. Monitoring features using agents

          Contex t

          Context Provide

          Synchrono us and asynchrono

          Synchro nous

          Synchrono us and asynchrono

          Synchro nous

          Require ments for

          Context Broker

          Cont ext

          Cont ext Quali

          Con text

          Figure 3. Context Diagram for Network Information

          Monitoring

          3G Tx Packets

          Running Processes

          Total Rx Bytes

          3G Tx Bytes

          Context Switches

          3G Rx Packets

          Process Created

          3G Rx Bytes

          Process Blocked

          Wi-Fi Tx Packets

          Wi-Fi Tx Bytes

          Wi-Fi Rx Packets

          Wi-Fi Rx Bytes

          3G Tx Packets

          Running Processes

          Total Rx Bytes

          3G Tx Bytes

          Context Switches

          3G Rx Packets

          Process Created

          3G Rx Bytes

          Process Blocked

          Wi-Fi Tx Packets

          Wi-Fi Tx Bytes

          Wi-Fi Rx Packets

          Wi-Fi Rx Bytes

          Network Features

          Number of Hosts

          Number of Packets

          Number of Flows

          Size (Bytes)

          Number of DNS Packets

          Number of HTTP Packets

          Number of HTTPS Packets

          Number of Well-known port Packets

          Number of Other port Packets

          Network Features

          Number of Hosts

          Number of Packets

          Number of Flows

          Size (Bytes)

          Number of DNS Packets

          Number of HTTP Packets

          Number of HTTPS Packets

          Number of Well-known port Packets

          Number of Other port Packets

          Table 4. Monitoring features at the network level

          The data is collected using installed agent programs on virtual mobile instances. We can collect the data using mobile platform APIs (for running app processes and network information), basic user- mode commands (for CPU and OS information) and system files in the mobile platform (for memory and OS information).

          Network Features

          There are 3 types of malware that use network resources.

          • Type 1 steals data in virtual mobile instances from behind the user and sends them to an external server

          • Type 2 infects virtual mobile instances as zombie and uses them to build botnet and DDoS attack

          • Type 3 increases network usage so that communication fare is over-charged

      To detect these malware, not only simple network data from virtual mobile instances but also more specific and accurate data at the network level is needed. We monitored detail network data using port-mirroring functionality through a virtual router. Flow generator converts them to flows as 5- tuple format, and feature extractor extracts useful features in Table IV from the flows in every minute. If a mobile agent is infected by one of the malware, some features among these are suddenly increased suddenly or the pattern is changed, and we can detect those network-related malware.

      4.4 Abnormal Behaviour Detection

      The analyzer performs machine learning algorithms using a tool, Weka [15]. We used the Random Forest (RF) machine learning algorithm to train abnormal behavior with our collected data set. The RF algorithm is a combination of decision trees that each tree depends on the values of a random vector sampled independently and with the same distribution for all trees in the forest [16]. We represented the collected features as a vector with the data subsequently used to train our collected data set.

  5. EVALUATION Collecting Behaviour Data

    1. Test Environment

      We implemented our test bed for mobile cloud services to validate our methodology and architecture. Table V and Table VI illustrate the hardware and software specification of our test bed, respectively. We used two nodes and ran a total of 10 virtual mobile instances from them. To virtualize mobile instances, we installed a Xen hypervisor on each physical node. For virtual mobile instances, we created virtual images by compiling Android x86 [23] kernel sources. In our test bed, Gingerbread 2.3.6 is used with Linux kernel version 2.6.39. Open vSwitch [24] is installed to use the port-mirroring functionality in each physical node.

      ADVANTAGES OF DATA COLLECTION

      Nearly any survey instrument, including mail, self administered, and interviewer administered questionnaires, canbeposted on the world wide web for pilot testing and administration. The process for web

      based data collection is comparatively simple. A questionnaire is translated intoHTML (hypertext markup language), the de facto language of the internet. With a point and click interface, respondents can complete a web based survey that is visually and functionally similar to traditional, written surveys. Form elements of web based surveys are similar to many self administered surveys including check boxes and numeric entry boxes as well as radio buttons, selection lists, and pull down menus that facilitate data entry and minimise error.

      The electronic nature of the medium allows researchers to make adjustments to a survey as unforeseen problems tocomprehension are discovered. Just as questions can berevised or removed, new questions or follow up questions can be added as new issues arise based on new information or preliminary ndings. Online data collection can even document the length of time that a respondent took to complete a survey.

      Table 5. Hardware specification of our test bed

      Features

      Contents

      Node Model

      Dell PowerEdge R610

      CPU

      Model

      Intel Xeon X5650

      Clock

      2.67GHz

      Cache Size

      12MB

      # of Core

      6

      # of Thread

      12

      Memory

      Type

      DDR3 1333MHz

      Size

      24GB (8GB x 3)

      Storage

      Size

      2TB

      Network Controller

      Two dual port ebedded

      NetXtreme IITM 5709c Gigabit

      Ethernet NIC

      Table 6. Software specification of our test bed

      Features

      Contents

      OS(Privileged Domain)

      CentOS5.6(x86_64)

      Kernel

      2.6.18-194.el5

      Hypervisor

      Xen 4.0.0

      Libvert

      0.8.1

      Android x86 Version

      Gingerbread 2.3.6 (Kernel

      2.6.39)

      Virtual Router

      Open vSwitch 1.2.2

    2. Result of Host Monitoring

      We implemented an agent mobile application for virtual mobile instances. This agent program runs as a service mode in Android x86 to collect host data. Fig. 4 illustrates the result of host monitoring using agents installed in virtual mobile instances. The data are sent to the analyzer at a set interval of time (we set this interval to one minute).

      Figure 4.Host Monitoring Result from Agents in Virtual Mobile Instances.

    3. Network Information

      Network traffic data is mirrored to the VM for NetMon. Then, the flow generator in the VM for NetMon generates flows using the Tshark tool every minute. The feature extractor also extracts network behavior information every minute from the flows that are generated just one minute before. This network behavior information is then sent to the analyzer, also every minute. Fig. 5 shows an example of TCP and

      UDP flow traffic analysis using Tshark. Tshark is a terminal version of the Wireshark [18] tool. In Tshark, network traffic is displayed by host and counted for incoming, outgoing, and total frames and bytes.

      =======================================

      UDP Conversations Filter:<No Filter>

      | <- || -> || Total |

      | Frames Bytes || Frames Bytes || Frames Bytes | 192.168.122.142:59879 <-> 192.168.1.2:53 1 125 1 74

      2 199

      192.168.122.142:65480 <-> 192.168.1.2:53 1 123 1 77

      2 200

      192.168.122.142:58865 <-> 192.168.1.2:53 1 124 1 78

      2 202

      192.168.122.142:61089 <-> 192.168.1.2:53 1 160 1 77

      2 237

      192.168.122.142:50272 <-> 192.168.1.2:53 1 161 1 78

      2 239

      192.168.122.142:49986 <-> 192.168.1.2:53 1 130 1 74

      2 204

      ==========================TCP Conversations

      Filter:<No Filter>

      | <- || -> || Total |

      | Frames Bytes || Frames Bytes || Frames Bytes | 192.168.122.142:49277 <-> 192.168.181.54:590 25

      11204 13 822 38 12026

      192.168.122.142:56541 <-> 192.168.82.74:80 4 953 5

      1120 9 2073

      192.168.122.142:56540 <-> 192.168.71.99:80 3 571 4

      1183 7 175

      192.168.122.142:56542 <-> 192.168.82.74:80 1 66 2

      120 3 186

      192.168.252.99:49962 <-> 192.168.122.181:910 0 0 2

      132 2 132

      =======================================

      Figure 5. TCP/UDP Flow Traffic Analysis using Tshark

      Malware Data

      We chose GoldMiner [12] malware applications to obtain abnormal data in our mobile cloud infrastructure. We installed the malware onto two hosts and ran it. It gathers location coordinate and device identifiers (IMEI and IMSI), and sends the information to its server. This also prompts the user to download and install an application. The application prompts user to uninstall other applications and sends a list of installed applications to the server. The malware target affecting each mobile instance as zombie, and there are many other malware which have the same purpose although their functionality and behavior are

      little different from each other [13][14]. This kind of malware is more threatening to mobile cloud infrastructure because there are lots of similar virtual mobile instances and they are closely connected to each other.

      Result of Monitoring and Detecting Abnormal Behavior

      Fig. 6 shows graphs of the monitoring results of five virtual hosts in a node. A malware, GoldMiner2, was installed on the 192.168.122.41 virtual machine, with the data of the machine represented in pink in the graphs. We activated the five virtual hosts by running normal applications and ran GoldMiner2 from 20:30 to 21:00 on the 192.168.122.41 host, and gathered 257 sample data. The number of context switches and the CPU usage ratio of this host were higher than other normal hosts during this time, see Fig. 6-(b) and (c). Also, the number of connecting r mote hosts is sometimes higher than others during this time. According to these data, the analyzer detected abnormal behavior from the 192.168.122.41 virtual host andchanged its state to abnormal, as shown in Fig. 6- (d). The 1st layer (yellow) means an inactive state, the 2nd layer (green) means an active state, and the 3rd layer (red) means an abnormal state in the graph. After running the malware, there are some periods of abnormal states because the malware was sometimes still running sometimes in the background even after stopping it from running.

      The original sample is randomly partitioned into 10 subsamples. Of the 10 subsamples, a single subsample is retained as the validation data for testing the model, and the remaining 9 subsamples are used as training data. The cross validation process is then repeated 10 times. Table VII shows the detection results of inactive, active, or abnormal states. There are 3 false labels in our results; one is detected as abnormal instead of inactive, and two are detected as abnormal instead of active. Table VIII shows the accuracy of our abnormal behavior detection results. TP Rate means True Positive rate, and FP Rate means False Positive rate. Precision means the fraction of retrieved documents that are relevant to the search, and recall is the fraction of the documents that are relevant to the query that are successfully retrieved. Weighted average shows average values of each accuracy feature according to the number of instances with each class label. Precision is high for all three states, and FP rate is almost zero.

      Table 7. Abnormal behaviour detection result: inactive, active and abnormal states

      Detection Result

      Inactive

      Active

      Abnormal

      Label

      Inactive

      115

      0

      1

      Active

      0

      34

      2

      Abnormal

      0

      0

      105

      Table 8. The accuracy of abnormal behavior detection

      TP

      Rate

      Fp Rate

      Precision

      Recall

      Class

      Accuracy

      0.991

      0.000

      1.000

      0.991

      Inactive

      0.944

      0.000

      1.000

      0.944

      Active

      1.000

      0.020

      0.972

      1.000

      Abnormal

      Weighted Avg.

      0.988

      0.008

      0.989

      0.988

      0.988

  6. Conclusion And Future Work

    In this paper, we presented a new mobile cloud service with the virtualization of mobile devices and discussed some possible scenarios for individual users and office workers. To address security issues in mobile cloud infrastructure, we proposed abnormal behavior monitoring methodology and architecture to detect malware. These were then tested by deploying our mobile cloud test bed. Host and network data are used together to detect abnormal behavior. Our abnormal behavior detection using the RF machine learning algorithmshows that our proposed methodology and archtecture successfully detect abnormal behavior.

    Traffic Size

    Context Switch

    CPU Usage

    Mobile Host State

    Figure 6. Behaviour Monitoring Results in Our Experiment Environment

    For future work, we will investigate on the service feasibility of this new mobile cloud service. In addition to the monitoring of mobile cloud infrastructure focusing on security issues, other monitoring metrics should be considered for the provisioning and configuration, of services, and for the charging of users. We will also measure the performance of our proposed monitoring architecture. To deal with security aspects on this service, we will gather various additional types

    of sample malware for training in order to improve the accuracy of using various machine learning algorithms. Further, we will consider other monitoring features to improve the accuracy of detecting abnormal behavior.

    A new, growing risk that's just as devious as malware is now disguised as adware. While malware is often designed to hide on your device, minimizing impact while nabbing personal files and passwords, adware can operate in plain sight while it collects almost everything else on your smartphone. Much like a burglar, stealthy capabilities combined with security loopholes heighten the danger of malware. Bringing in adware, though, is like recklessly inviting a total stranger for dinner. The conversation may be pleasant, but he may be walking around the house and learning everything there is to know about you.There is money to be made in using adware to gather personal data from your phone. This attracts legitimate advertisers, and more dubious characters. Keeping a close eye on your device to make sure that it behaves properly is highly recommended. With both personal and work data on your device, imagine what would happen if someone were to gain complete access to it. For instance, if you notice a spike in data consumption without doing anything out of the ordinary, it might reveal that something is smuggling data out of or onto your device. The best way to stay ahead of the problem is to set up a data meter to plug the leak before it causes too much damage.

  7. REFERENCES

  1. Distimo, "The battle for the most content and the emerging tabletmarket", April,

    2011,http://www.distimo.com/blog/2011_04_the-battlefor- the-lost-content-and-the-emerging-tablet-market/.

  2. E. Y. Chen and M. Itoh, "Virtual Smartphone over IP", The next IEEEInternational Symposium on a World of Wireless, Mobile andMultimedia Networks (WoWMoM 2010), Montrreal, Canada, June 2010,pp.1-6.

  3. F. Gens, "IT Cloud Services User Survey, pt.2: Top Benefits &Challenges", IDC eXchange(http://blogs.idc.com/ie/), August 14, 2008.

  4. Y. Chen, V. Paxson, and R. H. Katz, "What's New About CloudComputing Security?," University of California Berkeley Report No.UCB/EECS-2010-5, January 2010.

  5. S. Subashini and V. Kavitha, "A survey on security issues in servicedelivery models of cloud computing", Journal of Network and ComputerApplications 2010, Vol.34, No.1, July 2010, pp.1-11.

  6. A.Shabtai, U. Kanonov, and Y.Elovici, "Andromaly: a behavioural malware detection framework for android devices", Journal ofIntelligent Information Systems, January 2011, pp 1-30.

  7. D.Damopoulos, S.A. Menesidou, G. Kambourakis, M. Papadaki, N.Clarke, and S. Grizali, "Evaluation of Anomaly- Based IDS for MobileDevices Using Machine Learning Classifier", Security andCommunication Networks, Vol.5, No.1, January 2011, pp.3-14.

  8. W. Enck, P. Gilbert, B. Chun, L. P. Cox, J. Jung, P. McDaniel, and A.N. Sheth, "TaintDroid: An Information- Flow Tracking System forRealtime Privacy Monitoring on Smartphones", In Proc. of the USENIXSymposium on

    Operating Systems Design and Implementation (OSDI),Vancouver, Canada, October. 4-6, 2010.

  9. I. Burguera, U. Zurutuza and S. Nadjm-Tehrani, "Crowdroid: behaviorbasedmalware detection system for android", Proceedings of the 1stworkshop on Security and privacy in smartphones and mobile devices(SPSM11), New York, NY, USA, October 17, 2011.

  10. E. E. Marinelli, "Hyrax: cloud computing on mobile devicesusingMapRecuce", a Mater Thesis, CMU-CS-09-164, Carnegie MellonUniversity, September, 2009, available on http://reportsarchive.adm.cs.cmu.edu/anon/2009/CMU-CS-

09-164.pdf.

About The Authors

K.SARITHA, received his M.Sc in Computer Science from SK University, Anantapur, India, in 2008. Currently pursuing M.Tech in Computer Science and Engineering at Dr.KVSRCEW, Kurnool, India.

R.SAMAIAH, received his M.Tech in Computer Science in VT University, Bangalore, India.in 2008. He is an Asst.Professor at Dr.K.V.S.R.C.E.W, Kurnool, India.

Leave a Reply