MINDPRES: A Hybrid Prototype System for Comprehensive Data Protection in the User Layer of the Mobile Cloud

1. Introduction

Intrusion detection and prevention play a critical role in protecting user data from malware in end devices. Modern malware have evolved in sophistication such that traditional detection methods have difficulty to keep up, and detection techniques using machine language algorithms have been increasingly employed. Implementing machine learning (ML) on mobile devices is challenging due to the limited computing resources of the mobile devices. Data security issues have become an obstacle to the adoption of cloud computing (CC) and mobile clous computing (MCC) technologies as the enormous amount of data travelling through the mobile Internet has attracted attackers to this environment [1,2].

The security issues in the MCC cut across the three main layers that make up its architecture: the user layer (UL), the communication layer (CL), and the cloud service provider layer (CSPL) [3]. The mobile nature of the network nodes in the MCC has raised concerns about the potential of data privacy breaches, data loss or malicious replication of data [4,5,6].

While the cloud infrastructure of the MCC environment makes it possible to offer versatile and reliable services, ensuring the security and the privacy of user data is still a major challenge [7,8]. Firstly, the MCC environment inherits most of the security challenges typical for CC, such as multi-tenancy and virtualization security. This affects the security and privacy of user information stored in both the mobile and cloud infrastructure [9,10]. Secondly, to deploy the powerful cloud computation resources to execute resource-demanding applications [11], mobile device (MD) users need to offloading content to a cloud or an edge server for subsequent use. However, the MD user cannot validate the correctness of the offloaded data at the point of usage. If malicious apps are active on the MD, they may compromise target clouds based applications. If the attempt to integrate malware into legitimate cloud software remains undetected, this will poses a threat to the security of both mobile cloud data and mobile cloud applications [12,13].

In the last decade the number of cloud based mobile applications in areas such as education banking and healthcare has grown significantly [14,15,16]. As these applications are used frequently and widely, the security of the UL of the MCC environment has become a top priority [5]. However, malicious apps and may be hard to detect using existing defensive techniques, especially in the case of repackaging of popular applications with malicious payload [17,18,19,20,21,22]. In addition, security controls such firewalls, access control, anti-spyware, anti-virus and anti-malware may require significant computational power; in some cases, they may need to modify the kernel of the operating system (OS). Where feasible, moving some of the defensive mechanisms to the cloud end will make the implementation of a comprehensive defense system a feasible option [23,24,25,26].

According to [27], malicious apps are among the most significant threats to the security and privacy of MCC user data because the malicious activities affect both the UL and CSPL. The vulnerabilities of the MDs used at the UL of the MCC architecture have been identified in our earlier work [28,29]. Recent studies also highlight the threats to the CSPL posed by malicious apps on MCC user devices [20,21]. Ineffective security protection mechanisms at the UL may lead to a compromised app gaining access to MCC services [30]. This may breach the security defenses of the MCC infrastructure and open doors to possible attacks. Therefore, it is necessary to develop security approaches that mitigate these risks to strengthen the reliability of the MCC environment.

1.1. Related Work

A number of research studies on the topic of protecting user data on Android de-vices have proposed and evaluated a variety of classification approaches and feature selection (FS) methods for developing ML models for malware detection. Earlier work used predominantly a static approach , with app permissions often used as classification features [31]. As cybercriminal attacks became more sophisticated, the focus shifted towards dynamic analysis using features representing app behavior.

For example, the system proposed by Ribeiro et al. [18] monitors MD behavioral characteristics such as CPU usage, memory consumption, outgoing and incoming net-work traffic, battery usage to detects unusual patterns. Zhou et al. [19] also proposed a dynamic model for the detection of malicious attacks. They used a large set of 166 dynamically extracted features. Their detection engine acquires run-time system calls from unknown Android apps to create an input feature vector table. Based on the table, the ML model classifies an app as benign or malicious. Dynamic features were explored as well by Bhat et al. [32] and by Roy et al. [33]. Both studies tested extensively several ML models that used dynamic input features such as system calls, binder calls and network traffic data, using available datasets.

Work on improving the performance of static ML detection models also continued as static methods are simpler and generally, faster. For example, O. S et al. [27] proposed an ontology-based intelligent model using an ML classifier trained on app permissions as static features. Alazab et al. [34] developed a static malware detection model, which classified apps as benign or malicious based on the static analysis of app permissions and API (Application Programme Interface) calls. Their work focused particularly on identifying a set of best performing strategies for selecting relevant API calls. Kirubavathi et al. [35] applied a static approach to build a model specifically for the detection of ransomware. The model was effective while using a small set of 22 selected static features (permissions). Aljarrah et. [36] also used static analysis but added a set of contextual use features (services, receivers, activities and providers) to the set of 50 other static features (permissions and API calls) . Mahindru et al. [37] applied a static approach that used permissions and API calls as features, and app ratings and number of downloads as additional features; their detection engine included ML models and a neural network.

Hybrid approaches that combined methods for static and dynamic analysis also gained attention. For example, Maryam et al. [38] proposed to use app permissions and intents as static features and information leakage, cryptography’s exploitation, and network manipulations as dynamic features. Their experimental results indicated that best classification results were achieved when the static and dynamic features were analyzed simultaneously. Shatnawi et al. [39] similarly applied hybrid approach, with static features (permissions) extracted from the APK file and dynamic features extracted from running the apps in a controlled environment. Their model focused on action repetitions, i.e., the number of activities representing normal or suspicious data access activities. Aldhaferi et al. [40] also deployed a hybrid d approach to train a support vector regression (SVR) classifier. The static features were extracted from the APK (Android Package Kit) files and included permissions and other metadata; the dynamic features (system calls, API calls, network traffic) were obtained from executing the APK files in a controlled environment. The feature set was relative large, comprising 327 features. In the hybrid approach adopted by Asmitha et al. [41] the static features (permissions, activities, services, receivers) were also extracted from the APK file and the dynamic features (system calls) were extracted by running the APK files in an emulator. The authors created a multilayer architecture that comprised both conventional ML and deep learning (DL) algorithms. Finally, Sonya et al. [42] proposed a comprehensive hybrid system for ransomware detection. The static features (e.g., permissions) are selected and extracted from the APK file while the dynamic features (e.g., API calls) are extracted by running the apps in a sandbox or in an emulator.

1.2. Research Problem and Study Contributions

The vast majority of models and approaches proposed in past research report results that hade been obtained in laboratory conditions, using datasets available for various repositories. While dynamic and hybrid models in particular have achieved good classification accuracy and other performance metrics, the extraction of features for dynamic analysis involves running the apps/ This is particular drawback when it comes to implementing a model for the practical purpose of providing effective and efficient protection against malicious intrusions. With the exception of [41, little consideration has been given to the feasibility of developing actual software systems that can be deployed on MDs , and on the issue of time consuming model training. A parallel architecture for malware detection is proposed in [26]; however, their reported prototype works with static features only, extracted from the APK file.

This study proposes a flexible hybrid approach for comprehensive protection of the data and the MD device that is connected to the mobile cloud. It reports on the design and evaluation of a prototype system (MINDPRES) that demonstrates the feasibility of the approach and the methods used. The main contributions of this study are:

• A data-driven , cloud-based method for the static risk assessment of mobile apps resident on an MD.
• An effective innovative filter-based feature selection (FS) technique for static app classification.
• A proof-of -concept prototype of an innovative distributed hybrid intrusion detection and prevention system (IDPS) .
• A flexible framework for building distributed systems for the protection of MCC user data and devices.

The rest of the paper is organized as follows. An overview of the functionalities of the prototype system and descriptions of the methods used are provided in section 2. In section 3, we describe the system design and its implementation as a working prototype, and present the results of the performance evaluation of the prototype system. In section 4 we compare our work to other results reported in the extant literature, discuss the contributions and limitations of the study, and suggest directions for further research. The appendices contain detailed descriptions of the class, sequence and activity diagrams that are introduced in section 3.2.

2. Materials and Methods

In this study, the capacity and capability issues associated with running an advanced IDPS that uses ML algorithms at the device level are mitigated by training two ML models on a cloud-based server and distributing the computational load of the app risk evaluation process between the mobile device and the cloud-based server. The functional overview of the proposed hybrid (host-based and mobile cloud-based) protection system (MINDPRES) is shown in Figure 1.

A central building block of the system is the app evaluator which comprises a cloud-based component and a device-based component. It works with an ensemble ML model for static app classification (benign or malicious) that uses the declared apps permissions and intents as input features.

The ensemble ML model for dynamic app activity classification (benign or malicious) uses as inputs, the API call data and actual permissions or intents requested at the time of the API calls. The MD user data are thus protected by an IDPS that comprises two intrusion detection systems (IDS) (a host based IDS and a network based IDS), and an intrusion prevention system (IPS). The system operates as follows:

• When MINDPRES is installed on a device for the first time, it analyzes each user-installed app and determines its risk category (high, medium, low). Apps that fall into the high and medium risk categories are placed in a watchlist.
• When a new app is installed on a device the host IDS of MINDPRES is automatically invoked to perform a static analysis and assign the app a risk category.
• The network and host IDS of MINDPRES monitors the API calls made by apps and apps’ network activities both when the user is using the device and when the device is idle. The system prioritizes monitoring the behavior of the apps that are already on the watchlist.
• The IPS automatically blocks apps when suspicious activities or malicious network traffic are detected. Due to the possibility of false alarms, MINDPRES gives users the option to override the block and execute the app.

To develop the functional capabilities of the MIDNPRES prototype we drew on the approaches and experimental results reported in our previous work [28,29,43]. The descriptions of the methods used in this study are presented below.

2.1. Feature Selection Method

To select the features for the ensemble ML for app classification, this study uses IFD (intrinsic feature dispersion) as the FS method. IFD is a filter-based feature selection method that was proposed and evaluated in [43]. It takes into consideration the outcomes of the statistical analysis of the permissions and intents used by the apps represented in the training dataset. The method was developed and tested using a training dataset of 28, 306 APK samples ( 9,879 benign and 18,427 malicious samples) collected for the AndroZoo [44] and RmDroid [45] repositories. A total of 132 unique permissions and 131 unique intents were used by the samples in the training dataset. Thus, the number of potential features to be used in the app classification ML model was 263.

The set of potential features was reduced first by excluding permissions and intents that were commonly requested by both benign and malicious apps (e.g., the permission to use the Internet), and permissions and intents that were are rarely used by any type of app. In this study, the exclusion/inclusion thresholds were set to 3% and 90% (i.e., a permission or an intent was excluded if less than 3%, or included if more than 90% of the apps in the training dataset used it). The outcome was a set M of m permissions and a set N of n intent. The members of the sets M and N were all potential classification features.

A the next step, each permissions M_{i ,}i= 1. 2…m from the set M and each intent N_j, j=1,2…n form the set N was evaluated and either selected or rejected as an input feature, as described below.

For each permission M_i we define the measures to represent the relative use of this permission by all benign and by all malicious apps in the training dataset as

$${\xi }_i={\displaystyle \frac{Numberofbenignapps\in trainingdatasetusingpermission{M}_i}{Totalnumberofbenignapps\in trainingdataset}}\times 100\%$$

(1)

and

$${\eta }_i={\displaystyle \frac{Numberofmaliciousapps\in trainingdatasetusing{M}_i}{Totalnumberofmaliciousapps\in trainingdataset}}\times 100\%$$

(1)

The permission selection function E(M_i) is defined as

$$E\left(M_i\right)=\left\{\begin{array}{c}GOOD,if{\displaystyle \frac{{\delta }_i}{min\left({\xi }_i,{\eta }_i\right)}}>{\displaystyle \frac{{\epsilon }_i}{2}}\\ VOID,\wedge if{\displaystyle \frac{{\delta }_i}{min\left({\xi }_i,{\eta }_i\right)}}\le {\displaystyle \frac{{\epsilon }_i}{2}}\end{array}\right.$$

(1)

where

$${\epsilon }_i=min{\displaystyle \frac{\left({\xi }_i,{\eta }_i\right)}{max\left({\xi }_i,{\eta }_i\right)}}$$

(1)

and

$${\delta }_i\left({\xi }_i,{\eta }_i\right)=\left|{\xi }_i-{\eta }_i\right|=\left\{\begin{array}{c}{\xi }_i-{\eta }_i,{\xi }_i{\ge \eta }_i\\ {\eta }_i-{\xi }_i,\wedge {\xi }_i<{\eta }_i\end{array}\right.$$

(1)

A permission M_i is selected as a feature if E(M _i) returns a value GOOD. Intents are selected in a similar way. The IFD method led to the selection of 39 unique features (30 permissions and nine intents ) form the sets of potential features M and N. (Table 1).

2.2. Ensemble ML Model for Static App Classification

In this study, the 39 features selected by the IDF method (section 2.1) were used to train an ensemble ML model for static app classification (Figure 2). This model is part of the detection engine of MINDPRES. It resides on the cloud server and is invoked when an app needs to be classified as benign or as malicious.

2.2.1. ML Classification Algorithms

Ten ML classification algorithms were considered for the ensemble (Table 2). These algorithms are well suited for a classification problem such as predicting an app as malicious or benign and have been widely used in related empirical work [31,46,47].

2.2.2. Algorithm Performance Evaluation

We carried out an experiment to compare the performance of the ML algorithms and build an ensemble ML model that can effectively recognize malicious apps. We used the ML Scikit library with the Python programming language running on a remote virtual machine with the following hardware configuration: AMD 32- Core CPU @2.20GHz (2 processor), 64GB RAM, and a 500GB hard disk drive.

The experimental models worked with the features in Table 1 and were trained using the same training dataset that was used to identify these features. The performance evaluation metrics in Table 3 were used for the comparison.

We tested the models with a test dataset that contained 2,001 benign samples and 3,661 malicious samples. A complete set of results can be found in [43]. In this paper, we tested the ensemble model comprising the top performing classifier C1, C2, and C7. Table 4 presents the performance evaluation results of the ensemble ML model in comparison to the performance evaluation results of the models that used C1, C2 and C7, respectively.

The ensemble ML model includes an app permission filter that is used to extract the permissions and intents request by an app and generate the feature dataset. The classification outcome of the ensemble ML model is achieved through majority voting across the three classifiers of the ensemble (C1, C2 and C7).

The results indicate that the ensemble model outperformed the other models in some of the metrics. For example, it achieved the top classification accuracy of 98.13% and the lowest error rate of 1.87%. The false alarm rate of around 2% was also the lowest, and significantly lower than in the rest of the models.

2.3. Static App Risk Evaluation Method

The static method for determining an app’s risk riskiness used in this study aims to assign to it a risk category. It was proposed and tested on a small sample of apps in [29].

The app risk category (low risk, medium risk, high risk) considers two inputs: (i) the app’s classification as benign or malicious by the ensemble ML model for static app classification described in section 2.2 , and (ii) the calculated value of the app’s risk score.

The risk score of the app depends on how the app uses each of the permissions that belong to a predetermined reference set of dangerous permissions. To determine the risk score of an app, the static method for app risk evaluation uses the risk scores of the permissions in the reference set of dangerous permissions

2.3.1. Risk Scores of Dangerous Permissions

The dangerous permissions in the reference set represent the ‘top most dangerous permissions’ that are likely to be used by apps, and are commonly found on user devices. This study used the set of top dangerous permissions identified in [29], and shown in Table 5. The permissions were identified though the analysis of the training dataset described in section 2.1.

For each dangerous permission P_i, i=1, 2,…15, its risk score r(i) is calculated as below.

$$\mathrm{r}\left(i\right)=\sqrt{{\alpha }_i-{\alpha }_i{\beta }_i}$$

(1)

where

$${\alpha }_i={\displaystyle \frac{NumberofMaliciousApps\in XUsing{DangerouspermissionP}_i}{NumberofMaliciousApps\in X}}$$

(2)

and

$${\beta }_i={\displaystyle \frac{NumberofBenignAppsinXUsing{DangerouspermissionP}_i}{NumberofBenignApps\in X}}$$

(3)

2.3.2. App Risk Score

Each app a that is resident on a user MD may be using one or more of the dangerous permissions in the reference set of dangerous permissions. The risk score R(a) of an app a resident on an MD is a value in the interval [0,1] that is calculated as shown below.

$$R\left(a\right)={\displaystyle \frac{1}{k}}\sum _{i=1}^n\lambda \left(a,i\right)r\left(i\right)$$

(4)

where

$$k\left(a\right)=\sum _{i=1}^n\lambda \left(a,i\right)$$

(5)

and

$$\lambda \left(a,i\right)=\left\{\begin{array}{c}1iftheappausesdangerouspermissionPi\\ 0iftheappadoesnotusedangerouspermissionPi\end{array}\right.$$

(6)

As the app landscape changes and new security threats appear, the reference set of dangerous permissions may change. The risks sores of the permissions in the reference set will be updated using the same formulae. If the reference set of dangerous permissions is updated, the risk scores R(a) of the apps resident on the MD will need to be recalculated as well, using the same formulae.

2.3.3. App Risk Category

The risk category of an app a resident on the MD depends on the app’s classification (benign or malicious) and the app risk score R(a). It is determined using a set of threshold parameters t₁, t₂, t₃ and t₄ (Table 6). In this study, the threshold parameters t₁, t₂, t₃ and t₄ were set as 0.25, 0.60, 0.65 and 0.80, respectively. The values were determined experimentally and found to be performing better than the threshold values used in [29].

If the classification ML model is retrained and/or the reference set of dangerous permissions is updated, the apps resident on the device will need to be reevaluated. Their categories will be updated using the same approach. The threshold parameters may need to be updated as well, to determine the ones performing best with the new data.

2.4. Dynamic App Risk Evaluation Method

The dynamic method of determining an app’s riskiness involves the use of two ensemble ML models:

• An ensemble ML model for the analysis of API calls made by apps at run time. The model analyses an app’s dynamic activities based on network traffic data to detect malicious activities performed by apps resident on the MD.
• An ensemble ML model for app classification based on run-time permission and internet requests. In this study, the model described in section 2.2 was used for the purpose.

2.4.1. Data Acquisition

Network traffic data and data about permissions and intents requested at run time were collected from 4,000 (2,000 benign and 2,000 malicious) APK samples. The samples were chosen randomly from the training dataset described in section 2.1. The apps' APKs were installed on ten different Android X Emulators (Nexus 5X) with the following hardware configuration: 1GB RAM, 512MB SD Card, 2GB internal storage, 1080 X 1920HDPI, 4 Multi-Core CPU in a remote Virtual Machine (VM). The VM had the following hardware configuration: AMD dual Core (processor) i7-8700 CPU @2.00GHz, 64GB RAM, and a 1TB hard disk drive.

A data capture tool was developed to collect data about app activities at run time These include network traffic data and information about permission and intent requests made by the app at the time of the network activity. The tool uses the Android virtual private network (VPN) services and tracks each API request to an external service originating from the device emulator. The network traffic data that were collected included information about the amount of data sent or received, the duration of the connection, the network protocol requested, and the destination host (IP address and URL) In addition, the tool captured the permissions and intent requested at the point of making the API calls.

In each emulator used in this study, 200 different apps of each type were installed and executed for 5 hours daily. The data associated with each API request were captured by the emulator and stored in an SQLite database. The emulators were left running unattended for another 7 hours to record background network calls made by apps when the emulated devices were idle. This process was repeated for each emulator for two days. At the end of the data acquisition period, a total of 78,285 unique dynamic activity data samples were collected (Table 7).

2.4.2. Feature Selection

The features that represented actual app run-time behavior were extracted from each emulator’s database. They included the set of 39 features (F₁, F₂,…F₃₉₎ ) (permission and intent requests) selected by the filter-based IFD method (Table 1) and the set (C₁, C₂, …C₈) of eight specific network traffic characteristics of API calls to external services (Table 8).

Thus, the app activity data comprises information about the use of the features F₁, F₂,…F₃₉ and the actual values of C₁, C₂, …C₈). Only API calls that request an HTTP, HTTPS, TCP, TLS, or DNS connection were considered. These protocols were chosen because typical malware behavior usually involves stealing sensitive information from the device and transmitting it to a remote server.

2.4.3. Ensemble ML Model for Dynamic App Activity Classification

The ensemble model for dynamic app activity classification uses the ensemble Random Forest ML classifier (with bagging). This algorithm was found to be one of the best performing classifies in our experiments with a proposed cloud intrusion detection system that used the NSL KDD dataset for training the ML models [48].

As shown in Figure 3, the model was trained on the experimental dataset of dynamic activity samples using as input features C₁,C₂, C₄, C₅, C₇, C₈ . When the model receives a request for an app activity classification at run time, it analyses the network traffic data to detect malicious behavior. It feeds back the classification outcome to the MD.

3. Results

The methods described in section 2 were deployed in a prototype of MINDPRES. This section describes the design and implementation of the prototype including the functional and algorithmic descriptions of its three main components and the corresponding Unified Modelling Language (UML) diagrams. We also present the results of experiments conducted to evaluate the prototype performance in terms of the overall efficiency and the system’s deployment feasibility.

3.1. MINDPRES Prototype Design

The prototype system comprises three sub-system components: the Device Manager (DM), the App Evaluator (AE), and the Detection Engine (DE). A high-level visualization of the prototype components is shown in Figure 4. The functional design of the components is discussed below.

3.1.1. Device Manager

The DM is responsible for scanning the apps that reside on the device and for generating risk evaluation results (Figure 5). The device manager uses the VPN service libraries in the Android OS to prepare the prototype system for monitoring the traffic generated by the apps resident on the device without root-level access; however, the device user must grant MINDPRES access to the Android VPN service.

The DM allows MINDPRES to run in the background while the user is using other apps. MINDPRES gathers app network traffic data and run-time permission and intent requests and stores these in the device database. The DM forwards the data to the DE component of MINDPRES for further analysis. The high-level algorithmic design of the DM is shown in Table 9.

3.1.2. App Evaluator

The AE (Figure 6) determines the risk profile of user-installed apps by assigning each app a risk category (high risk, medium risk, or low risk). To evaluate an app, MINDPRES reads the content of its manifest file and extracts: (i) the permissions and intents required by the feature selection algorithm of the cloud-based ML model, and (ii) the dangerous permissions used by the app. The AE sends a request to the cloud server. The request contains the input features (app permissions and intents) required by the ML model for static app classification.

The ML model for static app classification that resides on the server handles the request. The model is described in section 2.2; it uses the feature selection algorithm described in 2.1. The cloud server responds by returning a classification output (benign or malicious).

Next the risk posed by a device-resident app is assessed by computing its risk score value based on the risk score values of the extracted dangerous permissions (using the methods described in 2.3.1 and 2.3.2). Considering the app’s risk sore value and the the classification output of the ML model for static app classification, the AE assigns the app a static risk category (using the method described in 2.3.3). The high-level algorithmic design of the app evaluator is shown in Table 10.

3.1.3. Detection Engine

The DE provides the IDPS functionality of MINDPRES. The DE monitors resident apps' behavior in real time and alerts the user to signs of abnormal behavior. As shown in Figure 4, the DE comprises two main sub-systems: the app intrusion manager and the app prevention manager.

The app intrusion manager (Figure 7) works in conjunction with the DM to leverage the Android VPN services It uses a dynamic approach: It extracts the actual permissions and intents requested by an app at run-time . These are scanned to select the ones that belong to the list of permissions and intents features required by the cloud-based ML model for static app classification (as described in section 2.2) and forwards the information to the feature set manager.

Second, the app traffic extractor captures network traffic data from the apps on the device (limited to HTTP, HTTPS, TCP , TLS, and DNS requests.) The network traffic data comprise the protocol (port/service), the duration of the connection, the number of bytes sent from the device, the number of bytes received from the destination host, the number packets sent, the number of packets received from the destination host, the packet size, the URL and the IP address of the destination request, and the source of the request (i.e., the app). The app traffic extractor forwards the network traffic data required by the ML model for dynamic app activity classification (section 2.4) to the feature set manager.

The feature set manager prepares the app activity data required by each of the two ML models and sends requests for classification. The responses are sent to the intrusion assessor .

In addition, the app traffic extractor checks the URL in the API call against a global database of known malicious URLs (categorized as malware, spamming, phishing, suspicious). The outcome of the check is forwarded to the intrusion assessor.

The intrusion assessor analyses the responses obtained from the global database of malicious URLs and from the ML classification models. It raises a flag if one of the two classification outputs is ‘malicious’ (i.e., either an app has been classified as malicious based on the permissions and intents requested at run-time, or malicious traffic has been identified associated with the app), or the checking with the malicious URL database returns true for any of the four categories of malicious URLs. An intrusion alert is raised.

The app prevention manager (Figure 4) is the risk mitigation component of MINDPRES. If an intrusion alert is raised, the app prevention manager identifies the app, communicates with the device manager and blocks any traffic from the app to the destination IP address. The app prevention manager alerts the MD user who can override the block and allow the connection. The algorithmic design of the detection engine is shown in Table 11.

3.1.4. MINDPRES Unified Modelling

The UML class diagram of MINDPRES shows the internal structures of the classes that make up the prototype system, and how each class interacts with the other classes (Figure 8). The main_activity class is the backbone of the prototype. It has three associated classes that correspond to the system components described in section 3.1 (the device manager class, the app evaluator class, and the detection engine class). Each class comprises a number of subclasses that support various MINDPRES functionalities. For a more detailed description of the class diagram of the MINDPRES prototype, see Appendix A, Section A1.

The interactional activities amongst the various objects that make up the MINDPRES prototype system are visualized in the UML sequence diagram of MINDPRES (Figure 9). For a more detailed description, see Appendix A, Section A2.

The UML activity diagram of MINDPRES visualizes the system’s dynamic aspects (Figure 10). It shows an abstraction of the events occurring as a result of the interactions between the MD user and the system , and depicts the flow of the various MINDPRES activities from one point to another. For a more detailed description of the activity diagram of the MINDPRES prototype, see Appendix A, Section A3.

3.2. MINDPRES Prototype Implementation and User Interface

The ensemble ML models used to implement the prototype system were developed using Python as the programming language and in particular, the Scikit-learn, Pandas, and NumPy libraries. The libraries have been used in prior research and have proved to be robust and reliable [49]. The ML models were deployed to the AWS cloud container.

The devicer end components of the MINDPRES prototype were implemented using the Android Studio Integrated Development Environment (IDE). As the proposed system requires native access to the device's low-level resources such as the VPN service and the package manager, Java was chosen as the app development language; the Java libraries provided support for communicating with the Android OS kernel and enabled the system to analyze efficiently the device resident apps and to intercept their API calls.

The user Interface (UI) was designed using the Extended Markup Language (XML) in the Android Studio. It was initially implemented on an Android emulator and then tested on several Android devices. The UI design of the three main functional components of MINDPES (device manager, app evaluation and detection engine) are described below.

The device manager screen is the first one the users sees when the MINDPRES app is launched. The user is asked to accept the use of the VPN service for MINDPRES to monitor the activities of the apps on the device, and is shown the total number of users who have installed apps on the device (Figure 11). The app evaluator screen shows the risk score and risk category for each app that has been evaluated. The system displays the permissions requested by each app are provides the user with an option to uninstall apps that may pose risk to the device (Figure 12). The detection engine UI contains three different tabs. The first tab displays the list of all apps and the total number of online requests made by each app. It also provides a list of API calls made to external URLs and the details of the API calls made. The second tab displays the list of apps with the total number of malicious API calls made, as detected by the intrusion assessor. This tab also shows URLs flagged as malicious. The third tab displays the list of all blacklisted API calls and allows the user to either enable or disable a blacklisted URL ( Figure 13 and Figure 14).

3.3. MINDPRES Prototype Evaluation

The evaluation aimed to assess the effectiveness of the proposed approach to the protection of Android mobile devices against malicious apps and the feasibility of deploying MINDPRES on mobile devices, including energy consumption. The evaluation followed a staged process, with several real-life experiments conducted. The first stage involved assessing the risk posed by the apps resident on the device. The risk assessment was performed by the app evaluator, which assigned a risk category to each app. The second stage involved monitoring the actual network behavior of the resident apps by the detection engine, with the purpose of detecting and preventing malicious activities.

3.3.1. Experiment Setup

The dataset used in the evaluation experiment was different from the training and testing datasets used to evaluate the performance of the ensemble ML model for static app classification (section 2.2). Here, a testbed of 1,000 apps are used (600 benign and 400 malicious). The 600 benign samples were downloaded between November 1st, 2021 and December 1st, 2021. The selection included the top thirty most popular apps from each of the twenty app categories in the Google Play Store. Only apps with at least one million user downloads were considered. The selection included most of the popular apps found in user devices and used for day-to-day activities, e.g, social networking, or travel.

The 400 malicious samples were obtained from the malware repository CICMalDroid2020 [50]. The malicious samples in the CICMalDroid2020 dataset are categorized in four categories:

• Adware

The adware category in this dataset includes advertisement materials (ads) that ‘hide’ behind legitimate apps. The malware runs continuously on the device, even if the user tries to close the ad. This type of malware can infect the device and get root-level access, thus gaining unauthorized access to sensitive personal and operational data.

2.

Banking Malware:

The banking malware uses a trojan: it mimics the original banking app interface to infiltrate the user device and gain unauthorized access to the user data such bank login credentials.

3.

SMS Malware

The SMS malware category includes apps that attempt to intercept payload operations to conduct attacks on the device. Such apps send malicious SMS to users and/or steal data once they establish a link with the user.

4.

Riskware

The riskware malware category includes legitimate apps that can be manipulated to act maliciously. Users may install such apps without realizing the danger.

The experiment included the use of five Android devices , as shown in the first column im Table 12. The APK files of the benign and malicious testbed apps were checked using the VirusTotal services (https://www.virustotal.com, visited on 1 November 2024) to ascertain whether the apps were malicious or not. Applying the criteria used in our prior experiments [29], an app was deemed to be malicious if at least 15 of the antivirus engines in VirusTotal services flagged it as malicious. The outcomes did not indicate any misclassification.

The total number of benign and malicious apps installed on each device is shown the second and the third columns in Table 12. The distribution of the benign and malicious app samples across the devices is shown in Table 13 and Table 14, respectively.

The devices were prepared for testing by installing the MINDPRES prototype app on each of them. Then the testbed samples were downloaded and installed. as explained above. The two trained ensemble ML models were deployed on AWS cloud server using a docket container. For a faster response, copies of the trained models were installed on each of the five MDs and used in the testing of the DE. This allowed the DE to monitor app activity with reduced connectivity requirements and a lower network traffic load.

3.3.2. Testing the App Evaluator

The first stage focused on the static analysis performed by the app evaluator, which assesses the risks of user-installed apps and assigns each app a risk category (low, medium, or high). The results are presented in Table 15.

The table shows, for each app category, the number of apps classified as benign or malicious by the ensemble ML model for app classification, and the number of aps that were assigned each of the risk categories (low, medium or high) by the MINDPRES app evaluator.

The ensemble ML model effectively distinguished between benign apps and malicious apps, with over 90% apps in each category classified correctly. On the average, 94.80% of the apps were classified correctly; in particular, all apps in categories B1, B2, B3, B7, and B8 were correctly classified.

From the 600 benign apps downloaded from the Google Play store, 568 apps (94.67%) were correctly classified as benign. Notably, the 32 benign apps that were wrongly classified as malicious requested permissions and intents commonly used by malicious apps. From the 400 malicious apps, 380 apps (95.00%) were classified correctly as malicious. Further investigation showed that the 20 malicious apps that were wrongly classified as benign used permissions and intents commonly used by benign apps .

The results from the final risk assessment of the testbed apps carried out by the app evaluator are shown in Table 16. In the case of benign apps, 563 apps (93.83%) were evaluated as low risk, 35 apps (5.83% ) were evaluated as medium risk and 2 apps (less than 1%) were evaluated as high risk. About 5% of the benign apps had a zero risk score. All apps in categories B2, B3, B7, and B8 were determined as low risk; their risk score values were in the range [0.00, 0.60]. The risk score values of the apps in the other app categories were in the range (0.60, 0.80]. However, two such apps (from app categories B6 and B9) were assigned a high-risk category. The risk score values of these particular apps were below the high risk threshold for benign apps (0.80) but above the high risk threshold for malicious apps (0.65); as the apps were wrongly classified as malicious by the ML model, the app evaluator applied the high risk threshold for malicious apps.

In the case of malicious apps, 3 apps (<1%) were evaluated as low risk, 294 apps (73.60% ) were evaluated as medium risk and 103 apps (25.75%) were evaluated as high risk. All apps in app categories M1, M2, M4 and M5 were evaluated as either medium or high risk, with risk scores between 0.25 and 1.00. However, three apps (from categories M3 and M6) were assigned a low risk category. These apps had risk score values above the medium risk threshold for malicious apps (0.25) but below the medium risk threshold for benign apps (0.60); as the apps were wrongly classified as benign by the ML model, the app evaluator used the medium risk threshold for benign apps.

The results demonstrate the robustness of the static evaluation. Malicious apps are designed to evade detection but the app evaluator ‘missed’ only three of them. However, a relatively high number of malicious apps were assigned only a medium risk category, possibly due to the relatively high values of the threshold parameters used. This may mislead the user to treat medium risk apps as not dangerous enough and to keep them in use.

Finally, a small number of benign apps were categorized as medium or high risk.

The user needs to be warned to be careful when granting permissions to medium risk apps and treat them with caution as the dangerous permissions and intents they request may have been manipulated by malicious developers.

3.3.3. Testing the Detection Engine

The second stage of the MINDPRES prototype evaluation focused on testing the performance of the detection engine (dynamic analysis). As the detection engine monitors the actual behavior of the apps both when the user is active and when the device is idle; the evaluation experiment was carried over a two week timeframe.

During the experiment, each device was used for two hours daily. Using a device meant running all testbed apps that resided on the device to give the system an opportunity to capture the actual network behavior characteristics of the apps.

The outcomes of the analysis of the network traffic data recorded in the experiment shown in Table 17. As expected, the total number of malicious activities performed by malicious apps (4,433) was significantly higher compared to the number of malicious activities performed by benign apps (31). A total number of 371 malicious apps were detected as performing malicious activities, compared to 14 benign apps performing malicious activities. In both app categories and across all devices, a significant number of activities were performed when the device was idle (20.07% of all activities).

3.3.4. Prototype Effectiveness

The metrics defined in Table 3 were used to evaluate the effectiveness of the performance of the MINDPRES prototype, based on the data presented in Table 15 and Table 17. A summary of the results is shown in Table 18. The results indicate that the prototype system is able to detect efficiently intrusion activities caused by malicious apps at the user layer of the MCC environment.

Overall, the prototype system achieved classification accuracy above of 90% an higher in all devices, for both the static and the dynamic approaches. The static approach achieved a better classification accuracy than the dynamic approach in devices A, C, and E. In devices B and D, the dynamic approach outperformed the static approach. The PR value of the detection performance shows that the dynamic approach performed better in detecting malicious activities compared to the static approach, with over 94% on all devices used for the experiment. Similarly, the dynamic approach had a better FPR rate in all devices, with as low as 1.11% in device C.

3.3.5. Energy Consumption

The evaluation of the energy consumption is necessary because of the resource constrains of the MDs. The energy consumption of each device was recorded both with the prototype system installed and uninstalled (Figure 15). The energy consumption of MINDPREAS was also estimated using the Android profiler that is integrated into the development environment. The result obtained to the actual energy consumption

The results in Figure 15 show that the device energy consumption was slightly higher when the prototype system was installed. The energy consumption of device E was very high which may be explained with the type of benign apps installed on the device (sports, dating and tools). In particular, dating and sports apps have high energy requirements due to the high number of network activities they engage in.

4. Discussion

This study explored the use of a combination of app permissions, intents, API and URL requests and network traffic data to analyze the apps' static and dynamic behavior through a hybrid MK-based approach towards malware detection Android MDs connected to the mobile cloud. The proposed solution (MINDPRES) is a distributed system.

At the device end, MINDPRES performs the following main functions: (i) evaluating the riskiness of resident apps (installed or downloaded; (ii) informing the user about apps that are classified as medium- or high risk; (iii) monitoring app activities when the user is active on the device; (iv) monitoring app activities when the device is not being used; (v) alerting the used about suspicious activities); (vi)blocking suspicious activities (the user has the option to resume a blocked activity).

4.1. Comparison with Prior Work

Work on proposing new solution to the security issues caused by malicious apps executed by MDs in the MCC environment is still limited. We compared the results of our study with results reported in the literature on ML-based malware detection systems for Android devices (Table 19). It is evident from the data in Table X that earlier work considered a static approach, in which the ML model classifies an app as benign or malicious. The permissions declared in the app APK file are the most commonly used input features. More recent research aims to improve the accuracy of the ML model by expanding the scope of static the features used, by adopting a dynamic approach. The dynamic approach identifies malicious activities at run time. Currently, researchers are experimenting with a hybrid approach: combining static and dynamic analysis. In the reviewed work, static features are extracted form the APK file while dynamic features are extracted from observed app behavior in a safe run-time environment,

Our proposed system also deploys also a hybrid approach. Differently from the models reviewed, MINDPRES extracts all features at run time, including permissions and intents that are normally used in static analysis . Further more, the feature extraction does not need a safe environment to extract the features used in dynamic analysis, or root-level access to monitor app behavior in real-time. Rather, apps are monitored using the device’s VPN service. This makes the proposed system high implementable. In addition, the proposed system prioritizes monitoring app activities based on a preliminary static analysis that determines the risk score and risk category of each app resident of the device as a function of the app’s s classification (benign and malicious) and the app’s risk score. The app’s risk score shows how this app’s use of permissions compares to the use pf the permissions s currently known as ‘most dangerous’.

Furthermore, the results presented in Table 19 show that the data used in our experiments are reliable. First, the number of malicious samples used to train the ML models compare to most of the studies, with only studies having used significantly larger sets of malicious samples. The source datasets used in our study have also been used by other researchers, which to the credibility of our work.

With regard to the ML models built, our ensemble classifiers include algorithms that have been widely tested and have yielded good performance results. Our model for app classification (using permissions and intents) deploys as well innovative FS algorithm that has reduced the dimensionality od the feature se to 32 features only.,

The detection performance results of the proposed system shown in Table X show a classification accuracy of over 97% and a false positive rate of less than 3% in both the laboratory and real-life experiments. Thus indicates that the models used in the prototype system itself compare favorably with other related research.

Finally, the reviewed studies have conducted their experimental work laboratory conditions. None has investigated in depth the feasibility of deploying the proposed ML models on real MD. In contrast, we have build and treated a prototype systema and have demonstrated the feasibility of the solution.

4.2. Study Contributions

This study makes several important contributions. First, it proposes a hybrid approach toward the detection of malicious app behavior that is accurate and inobtrusive and does not increase significantly the energy consumption of the device.

Second, the study develops a working prototype of a distributed IDPS for the protection of MDs operating in the UL of the MCC that t applies a hybrid approach The two ML models that are used in the system are trained and updated at the cloud end of the IDPS, and up to date copies are pushed to the device end. This reduces the computational load on the MD and at the same time, allows for faster detection process.

Third, the study implements and demonstrates the effectiveness of two innovative methods proposed in our earlier work: (i) The IFD method for selecting static features, and (ii) the stochastic method for calculating an app risk score. Both are used in the initial static app evaluation performed by the app evaluator.

Fourth, the models and methods developed and used in this study offer a data-driven framework for developing a flexible distributed security protection system for Android MDs. The ML models can be rebuilt and/or retained in the cloud, including selecting a new set of features by the IFD. This allows to keep the models current, and/or to rebuild them for better performance. The reference set of most dangerous permissions that are used in the stochastic method for calculating the app risk score can be updated as well, to adjust to changes in the threat environment. In addition, the threshold parameters used by the app evaluator can adjusted as well. All such updates can be seamlessly pushed back to the MD.

4.3. Study Limitations and Concluding Remarks

This study has two major limitations. First, the ML model for the analysis of app behavior at run tine was trained on a small set of samples collected experimentally. For achieving better performance, the model can be retrained on a larger dataset. Second, the model was built using one selected classifier. Deploying other classifiers or ensembles including DL algorithms may lead to better performance. Further more, as a distributed system MINDPRES depends on the security of the communication channel and also on the security of the cloud service. Further research can look into developing a comprehensive MCC protection system that addresses the security issues at the other layers of the MCC infrastructure: the mobile communication channel and MC service provider..

Based on the results obtained in the experiments and the discussion above it can be concluded that MINDPRES is a feasible solution to the research problem driving this study. The system can be deployed on any Android mobile device connected to an MCC environment. By listening to the permission, intent, API and URL requests that apps make in real time , the system monitors the actual execution of the apps installed on the device and provides an effective defense against threats caused by malicious apps.