Marianthi Theoharidou

Alexios Mylonas
email: amylonas@aueb.gr

Dimitris Gritzalis

A Risk Assessment Method for Smartphones

Keywords: Smartphone, Risk Assessment, Android, Security, Threat

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Smartphones' popularity lies mainly with their pervasiveness, which stems from their small size, advanced processing and connectivity capabilities, reduced cost, and their ability to host multi-purpose third party applications. Smartphones host heterogeneous data such as multimedia, sensor data, communication logs, data created or consumed by applications, etc. A smartphone user carries the device on multiple locations throughout the day, and allows connections to various networks that are often not secure. As the same device may be used for both, work and leisure purposes, smartphones often contain a combination of valuable personal and business data.

The complexity of administrator attempts to secure organisation assets rises, as users continue to bring their own smartphones in corporate premises [START_REF] Nachenberg | A Window Into Mobile Device Security[END_REF]. Often, organizations are not prepared to manage smartphone heterogeneity, especially when the required resources or expertise is not present (consumerization). Smartp hones extend the business perimeter, while existing security and privacy perimeter-oriented mechanisms are inadequate [START_REF] Oppliger | Security and Privacy in an Online World[END_REF]. In this context, the importance of smartphone data, in conjunction with their ability to interact with corporate assets, make them economically attractive to attackers [START_REF] Caldwell | Smart security[END_REF]. Hence, traditional risks (e.g. theft, fraud, etc.) may reappear with increased impact. They can pose a security challenge [START_REF] Dlamini | Information security: The moving target[END_REF] or take place using new attack vectors, e.g., using smartphone location capabilities for surveillance [START_REF] Mylonas | Smartphone Security Evaluation: The Malware Attack Case[END_REF]. In addition, smartphones implement different security models, which make traditional countermeasures ineffective.

Traditional risk assessment methods treat smartphones as an asset of a business information system, similarly to a personal computer or a laptop. They treat the smartphone as a single entity, where threat and vulnerability assessment are performed on the asset as a whole. Although a smartphone can be viewed as a kind of small scale information system, making existing methods applicable, such an assessment is not ideal for risks that target device (sub)assets, e.g. GPS sensor (i.e. surveillance), logs (i.e. call logs disclosure), etc. This is due to the fact that they do not take account smartphone-specific threats, neither the unique vulnerabilities that a smartphone security model introduce. Furthermore, most risk assessment methods are not intended for users, but mainly for businesses. Thus, a targeted risk assessment method is useful, so as to assess user-specific parameters and smartphone-specific threats, in a considerably more fine-grained fashion. We contribute towards this direction by identifying smartphone assets and threats, as well as by proposing a risk assessment method specifically tailored for smartphones.

The paper is organized as follows. Section 2 provides the reader with a smartphone definition and smartphone data taxonomy. In Section 3 the proposed risk assessment method is introduced. The method is applied in Section 4, through the use of a case study. Method limitations and further research ideas are discussed in Section 5.

Smartphone: Definition and Assets

The term smartphone is frequently used by the industry and research community to refer to state-of-the-art cell phone devices. These devices are considered 'smart', and are distinguished from ordinary and technologically constrained cell phones. The latter, which are referred to as feature phones, are often restrained by small screen size, limited processing and network capabilities, and execute, in general, a proprietary and not adequately documented operating system. Thus, their security is mainly based on secrecy or as the IT security community refers to, as "security by obscurity".

In contrast with the term 'feature phone', a widely accepted definition for 'smartphone' can hardly be found in the literature. Becker et al. [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF] define smartphones as devices which: (a) "contain a mobile network operator smartcard with a connection to a mobile network", i.e. a SIM or USIM card in GSM and UMTS systems, respectively, and, b) "have an operating system that can be extended with third-party software". However, this definition appears to be rather broad. Also, its properties are valid for feature phones. For instance, the Motorola V3i1 feature phone would be incorrectly classified as a smartphone, as it contains a mobile carrier SIM card and has a proprietary OS that can be extended by third party applications (specifically with MIDP 2.0 Java applications).

The alternative definition of a smartphone, which is adopted here, is the following: smartphone is a cell phone 2 with advanced capabilities, which executes an identifi-able operating system allowing users to extend its functionality with third party applications that are available from an application repository. According to this definition, smartphones must include sophisticated hardware with: a) advanced processing capabilities (e.g. modern CPUs, sensors), b) multiple and fast connectivity capabilities (e.g. Wi-Fi, HSDPA), and (optionally) c) adequately limited screen sizes. Furthermore, their OS must be clearly identifiable, e.g. Android, Blackberry, Windows Phone, Apple's iOS, etc. Finally, the OS must allow third party application installation from application repositories ('app markets'), e.g. Android Market, BlackBerry App World, App Hub, App Store, etc.

Smartphone assets

A smartphone is viewed herein as a small-scale information system, which incorporates various assets. [START_REF] Ledermüller | Risk Assessment for Mobile Devices[END_REF]. An assessment of security in the case of the Android platform [START_REF] Shabtai | Google Android: A Comprehensive Security Assessment[END_REF] analyses: (a) private/confidential content stored on the device, (b) applications and services, (c) resources (battery, communication, RAM, CPU), and (d) hardware (device, memory cards, battery, camera). Our analysis makes use of four asset types: a) Device, b) Connectivity, c) Data, and d) Applications. The Device asset type includes the physical device and its resources (e.g. battery, RAM, CPU etc.), but not the Data. The latter appear to be more complex and are analysed in the next section. Applications are viewed only as user services.

Smartphones use four Connectivity channels, namely: a). GSM services, i.e. messaging (SMS, EMS, etc.) and voice calls, b). PAN interface (e.g. Bluetooth, IrDA, etc.), a free and ad-hoc short-range data channel, c) WLANs (e.g. Wi-Fi, WiMAX, etc.), a fast data channel, and d) Cellular network, which provides Internet connectivity at variable speeds, depending on the carrier technology (e.g. GPRS, HSDPA, etc.).

Data Taxonomy

Data are classified on the basis of two dimensions, i.e., information type and source. Table 1 associates the two dimensions. These associations will be used later as the basis for the data impact valuation. smartcard, which is controlled by the network carrier (i.e. SIM or USIM card) and incorporates a billing mechanism for the used network carrier services.

Input methods

    
Smartphone data hold various meanings. Their classification, according to the information type they may infer, led us to the following taxonomy:

Personal data are directly related to an identified individual. They are considered private and should not be made public. Examples include the content of a user's communication, images, videos, etc. Disclosure or unauthorized modification may result in embarrassment, reduction in self-esteem, or legal action. Business data (or corporate intellectual property) refer to data with commercial and economic corporate significance. These include marketing information, products under design, etc. Unintended disclosure of this data to the public or competitors may lead to strategic advantage loss, copyright breach, loss of goodwill, etc. Such data are usually likely to exist in a 'personal' smartphone, if it is (even occasionally) used for business purposes. Government data affect: (a) public order, (b) international relations, or (c) performance of public service organization(s). They differ from business data, because they hold national or international significance, as opposed to business value. Financial data refer to records of financial transactions, current financial holdings or position. Unauthorized modification, disclosure, or unavailability may lead to financial loss or contract breach (e.g., due to delays). Authentication data refer to user credentials, e.g. passwords, PINs, biometrics, etc. Their unauthorized access may lead to impact, such as financial loss, personal information disclosure, legal consequences, etc. Connection/ Service data refer to data, which are required for network connections. They include connection identifiers, such as Wi-Fi MACs, IMSI, or IMEI, as well as data regarding the connection itself, such as the Wi-Fi joined networks history.

During regular (e.g., daily) use, data are used or stored on various sources. The following taxonomy is based on another dimension, i.e., data source [START_REF] Mylonas | Smartphone spying tools[END_REF]: Messaging Data derive from: (a). mobile carrier messaging services i.e. Short Message Service (SMS), Enhanced Messaging Service (EMS), Multimedia Messaging Service (MMS), or (b). Instant and e-mail messages. They also include messaging logs, e.g. receiver, sender, delivery time and date, attachments, etc. Device Data are data that (a) are not related to any third party application, or (b) contain device and OS specific information. They may reside in internal (e.g. flash drive, flash memory) and removable (e.g. microSD cards) storage media. Some examples include images, contact list, Wi-Fi MAC address, device serial number, etc. (U)SIM Card Data reside either in a Universal Subscriber Identity Module (USIM) or Subscriber Identity Module (SIM) card. Typical examples are the International Mobile Subscriber Identity (IMSI) 3 and the Mobile Subscriber Identification Number (MSIN) 4 . This source often contains SMS and contact list entries. Application Data include permanent or temporal data that are necessary for application execution. They may be stored as individual files, or constitute a local database, e.g. SQLite. A typical example is a flat dictionary text file. Usage History Data are used for logging purposes, such as: (a) call history, which contains incoming or outgoing phone call logs, (b) browsing history, i.e. temporary data created while the user browses local or remote files, (c) network history logs for wireless connections, e.g. Wi-Fi SSIDS, Bluetooth pairing, and (d) event logs, which are created by the OS for system monitoring and debugging. Sensor Data are created by dedicated hardware. Camera(s) and microphone(s) are two popular sensors. Other sensor hardware include: a) GPS sensor, b) accelerometer, c) gyroscope, d) magnetometer (i.e. digital compass), and e) proximity sensor. These are used to infer the exact device location, its orientation, the way the device is being moved, its heading direction, and the device distance from a surface, respectively. Sensor hardware, such as the light sensor and the temperature or pressure sensor, are present in some smartphones, measuring the device environment surroundings (context). Sensor data are mostly consumed on the fly and are not typically stored for later retrieval. Finally, they may be used as metadata (e.g. in geotagging where GPS data are embedded in photographs and videos). User Input Data include user gestures, hardware button presses, and keystrokes from a virtual or smartphone keyboard. All involve user interaction with the device. User input data are often consumed on the fly, or stored in a keyboard cache for performance reasons (e.g. improvement of spelling software).

Smartphone Risk Assessment

To assess smartphone risk, one should first assess the impact of its assets. Then, assets should be related to smartphone threat scenarios. Impact assessment for each asset is described in the sequel.

Asset impact

A key concept is, first, to involve the user with the initial impact valuation process. Then, the risk analyst should perform transparent associations and aggregations to calculate the overall risk.

Device. In typical risk assessment methods, physical assets are valued in terms of replacement or reconstruction costs, in a quantitative way. For a smartphone this refers to replacement or repair device cost, in the case of loss, theft, or damage. However, a smartphone contains, also, various information types, which need to be coassessed in terms of impact.

Data. For information assets, a loss of confidentiality, integrity, or availability may be valued via several criteria [START_REF]Information technology -Security techniques -Information security risk management[END_REF], [START_REF] Ledermüller | Risk Assessment for Mobile Devices[END_REF], i.e. personal information disclosure, legislation violation, contractual breach, commercial and economic interests, financial loss, public order, international relations, business policy and operations, loss of goodwill/reputation, personal safety, annoyance, etc. Due to the smartphone's multipurpose nature, these impact types vary from purely personal ones, e.g. user annoyance, to typical information systems ones, e.g. commercial interests. This heterogeneity affects risk assessment. Adequate input from user is, thus, required, as clearly opposed to generic smartphone risk assessment [START_REF] Hogben | Smartphones: Information security risks, opportunities and recommendations for users[END_REF], [START_REF] Shabtai | Google Android: A Comprehensive Security Assessment[END_REF], which uses expert opinion.

In a 'personalized' (or 'itemized') risk assessment, the user is asked questions aiming to determine the existing data types (e.g., "Do you store personal data in your smartphone?", "Do you use your smartphone for business purposes? If so, do you work for a governmental institution? ", or "Do you use your smartphone for financial transactions?", etc.).

In turn, for each identified data type, the user is invited to assess the impact of the following scenarios: "Which are the worst consequences if your < data type> are unavailable?", "Which are the worst consequences if your < data type> are disclosed to the public?" and "Which are the worst consequences if your < data type> are modified or damaged (deliberately/accidentally)? ". The answers lead to impact calculation for each data type, namely the unavailability impact Impact UA (data_type), the disclosure impact Impact DS (data_type), and the modification impact Impact MD (data_type).

Our approach adopts the "worst-case scenario" principle, i.e. the max operator is used to calculate the total scenario impact. The answers must follow a qualitative assessment of the impact types mentioned above, evaluated by the user with a 5-item 5Likert scale (very low, low, medium, high, very high). For each impact criterion, a table needs to be produced, mapping each qualitative assessment to a comprehensive description. For example, for the 'personal information disclosure' criterion, the "very low" valuation may refer to "minor distress to an individual", as opposed to the "very high" one, which may refer to "significant distress to a group of individuals or legal and regulatory breach". Again, a map to quantitative values is required, because impact criteria cannot be considered equivalent. For instance, the "very high" valuation on 'personal information disclosure' must not be quantitatively valued equally to the "very high" valuation on 'personal safety'.

Connectivity. Likewise, the user assesses the network services impact: "Which are the consequences if you cannot use the SMS service? ", "Which are the consequences if you cannot connect to a Wi-Fi network?", "Which are the consequences if your Wi-Fi connection is been monitored?", etc. The assessment should follow the same valuation tables and scales, as the data valuation ones do. The resulting valuations, i.e. Impact UA (channel), Impact DS (channel), Impact MD (channel), are used for risk assessment of threat scenarios which affect connectivity.

Applications. The same procedure can be used for user applications. Although this approach allows for a fine-grained impact valuation, it adds considerable complexity, as the applications may be numerous. It, also, assumes that a user has a clear perception of an application's significance, e.g. by using the application for some time. A trade-off could be the valuation of applications that the user identifies as more important. The assessment per application should follow the same valuation tables.

Total impact valuation. Based on the above, the user has assessed the impact of various scenarios (loss of availability, confidentiality and integrity) for all four smartphone asset types. These values are combined and used to assess the risk of the threats scenarios. For instance, the data type impact values are inferred to their associated data sources (see Table 1). This means that if a user has identified 'personal' and 'financial' data types on her smartphone, then the disclosure impact for the data source 'Messaging' can be calculated, as follows:

Impact DS (Messaging) = max {Impact DS (personal data), Impact DS (financial data)} Likewise, the overall smartphone impact is the max impact from all four assets, i.e., the device, data, applications, and connectivity.

Threat

Threat likelihood is assessed on the basis of: (a) experience and applicable statistics, (b) vulnerabilities, and (c) existing controls and how effectively they may reduce vulnerabilities [START_REF]Information technology -Security techniques -Information security risk management[END_REF]. In this section a smartphone threat list is presented, together with a discussion on how threat likelihood may be assessed. Table 2 presents a threat list expanding similar lists that are available in the smartphone literature [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF], [START_REF] Enck | A study of android application security[END_REF][START_REF] Hogben | Smartphones: Information security risks, opportunities and recommendations for users[END_REF], [START_REF] Jansen | Recommendations of the National Institute of Standards and Technology[END_REF][START_REF] Jeon | A Practical Analysis of Smartphone Security[END_REF], [START_REF] Ledermüller | Risk Assessment for Mobile Devices[END_REF], [START_REF]OWASP: Top 10 Mobile Risks[END_REF], [START_REF] Shabtai | Google Android: A Comprehensive Security Assessment[END_REF]. Each threat is grouped in the appropriate attack vector dimension (i.e. an asset utilization may be misused to impair another one (e.g. application access rights may be misused to leak private data)). Each threat is associated with the security attribute that it impairs.

A particular application may be an asset that needs protection and, at the same time, an attack access vector to other assets. For instance, the availability of a social networking application may be considered as a significant asset by a user (high impact), while being the attack vector for privacy threats. Even if this application is benign (i.e. not leaking any private data for malicious purposes), its privilege to access private data may be misused by a malicious application performing a deputy attack [START_REF] Dietz | Quire: lightweight provenance for smart phone operating systems[END_REF], [START_REF] Felt | The effectiveness of application permissions[END_REF], [START_REF] Grace | Systematic Detection of Capability Leaks in Stock Android Smartphones[END_REF]. Though, it might be the case that a malicious application masquerades as a benign application (e.g. game) luring users into downloading it and, thus, being the attack vector themselves. Thus, such a smartphone privilege is herein considered vulnerability.

The permission acceptance likelihood differs in smartphone platforms. It depends on authorization decisions, as delegated by the platform security model. These decisions differ significantly [START_REF] Mylonas | Smartphone Security Evaluation: The Malware Attack Case[END_REF] from allowing users to make security-critical authorization decisions (e.g. Android's community driven security model), up to placing functionality control barriers in applications that enter application repository (e.g. the 'walled garden' approach of Apple's App Store).

Risk

The triplet used for the risk assessment of threats, which are associated with specific permission access rights (i.e. threats T14-T19, T21, T22) is: (asset, permission combination, threat).

Asset refers to the asset targeted by the threat. Permission combination refers to the permissions for the dangerous functionality required by the threat. The permission combination is the vulnerability the threat exploits. In turn, threat likelihood is valuated on the basis of: a) the likelihood of permission combination acceptance in the smartphone platform, b) the threat incident likelihood, i.e. statistics on threat incidents in the platform or previous incidents experienced by the user, and c) the relevant security control existence (e.g. Use of Mobile Device Management [START_REF] Redman | Magic quadrant for mobile device management software[END_REF]). Given that the user has assessed the asset impact, the impact may be combined with the likelihood of the threat and the permissions acceptance, so as to calculate risk by forming the triplet: (asset impact, permission likelihood, threat likelihood) = > Threat Risk Risk assessment is calculated on the basis of a risk matrix [START_REF]Information technology -Security techniques -Information security risk management[END_REF]. Risk can be mapped as Low (0-2), Medium [START_REF] Dietz | Quire: lightweight provenance for smart phone operating systems[END_REF][START_REF] Dlamini | Information security: The moving target[END_REF][START_REF] Enck | A study of android application security[END_REF], or High [START_REF] Hogben | Smartphones: Information security risks, opportunities and recommendations for users[END_REF][START_REF] Felt | The effectiveness of application permissions[END_REF][START_REF] Gartner | Market Share: Mobile Communication Devices by Region and Country[END_REF]. Since each threat is associated with specific security attributes, the relevant asset impacts are taken into account. For instance, when assessing the Risk of threat T17 'Sensitive Information Disclosure' on the data source 'Messaging', the disclosure impact value Impact DS (Messaging) is used as the asset impact, because the particular threat affects confidentiality. For threats that cannot be associated with specific permissions, i.e. T1-T13, T20, such a triplet cannot be produced. In this case, threats are combined with specific assets, and their risk is calculated on the basis of asset impact and threat likelihood, where the likelihood is calculated based on threat incident statistics or previous incidents experienced by the user. This is done through a simple table (see Table 4).

Table 3. Risk matrix

Table 4. Simplified risk matrix

Threat likelihood Low Medium High

Asset impact

0 L L M 1 L M M 2 L M H 3 M M H 4 M H H

Case Study: Risk assessment in Android

This section provides a demonstration of the proposed risk assessment method in the case of the Android platform. Android was selected because it is: a) popular smartphone platform holding the 52.5% of the smartphone market sales share in Q3 of 2011 [START_REF] Gartner | Market Share: Mobile Communication Devices by Region and Country[END_REF], b) open source and, hence, its security model details are publicly available, and c) well studied platform and statistics about its threats are available.

For the purpose of this case study a HTC Hero (Android version 2.1) owner is assumed, who holds a 'high' managerial position in the Pharmaceutical industry. The user identified two data types, i.e., personal data and business data. She provided data impact valuations as follows: Impact UA (personal)=1, Impact DS (personal)=2, Impact MD (personal)=2, Impact UA (business)=2, Impact DS (business)=4 and Impact MD (business)= 3. She chose not to assess network services and applications. She also assessed the replacement cost of the device as low, i.e. Impact(device)=1.

In addition, the user provided the following data: 1) the only smartphone security control enabled is the automatic password device lock, 2) she regularly discusses critical business issues over the carrier voice service, 3) she does not consider herself a technology or security savvy user, 4) no past security incident has ever come into her attention, 5) has noticed some delays in the device, 6) travels frequently in technology 'underdeveloped' country where fast 3G data connections are not available and, thus, her only way to connect to the internet is either through public free Wi-Fi hotspots, or expensive carrier network if one is not available, 7) has never updated the firmware, 8) she regularly installs applications while she is using public transport (trains, subway, etc). Finally, since Android's security is based on the user security consciousness (i.e. the user decides permission authorization during installation time in an all or nothing way [START_REF] Mylonas | Smartphone Security Evaluation: The Malware Attack Case[END_REF]), the likelihood of a permission combination acceptance is estimated using Android application research and studies [START_REF] Enck | A study of android application security[END_REF], [START_REF] Felt | The effectiveness of application permissions[END_REF].

For readability and space-limitations reasons, the case study focuses on risk that is due to threats T5, T10, T11, T13, T14, T17, T18, and T21. T5 Eavesdropping. The user-identified the use of GSM voice services, in a carrier where UMTS is not supported. As a result, the possibility of abusing the discussion confidentiality is High [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF] and the Impact DS (GSM Service)=max{Impact DS (personal), Impact DS (business)}=4. Risk is assessed as High (see Table 4). T10 Unauthorized device (physical) access. The user has the automatic password device lock enabled, therefore this threat likelihood is Low. As physical access to a device affects all security attributes and may cause significant damage to the hardware itself, the total impact of the asset 'device' is the max value of the replacement cost and the relevant impact valuations for the data it holds. Therefore, To-tal_Impact(device) = max{Impact(device), Impact DS (personal), Impact DS (business), Impact MD (personal), Impact MD (business), Impact UA (personal), Impact UA (business)} = 4. Therefore, the threat risk is Medium (see Table 4). T11 Unauthorized Access. The user is running an Android version that suffers by known security vulnerabilities. The vulnerabilities have been identified and patched by the device vendor without the user applying them. In addition, publicly available and stable (i.e. confirmed) source code exists, which can exploit the vulnerabilities 6 . The source code can be used by an attacker, so as to gain unauthorised access to the devise with administrator privileges. Thus, the threat likelihood is High. Since T11 may affect all security attributes but not the hardware itself, the Impact DS,MD,UA (Device) is the max impact valuation of the data it holds, i.e. it equals with 4. As a result, the threat risk is High. T13 Crashing. The user is running a buggy version of Android 2.1 that affects the device performance. An official fix (patch) for this vulnerability is available from the device vendor, thus, the threat probability is High. T13 affects the device's availability. The unavailability impact of the asset 'device' is the max value of the relevant impact valuations for the data it holds. Therefore, Impact UA (device) = max {Impact UA (personal), Impact UA (business)}=2 and the threat risk is High (Table 4). T14 Misuse of Phone Identifiers: This threat is associated with the triplet T1= <USIM Data, Open Network Sockets + Access Phone State, T9>. The likelihood of T14 is Low (~20%) [START_REF] Enck | A study of android application security[END_REF]. The combination likelihood is, also, Low (≤35%) [START_REF] Felt | The effectiveness of application permissions[END_REF]. As a result, the following risk triplet is formed: <Impact DS (USIM Data), Low, Low>. Since the Impact DS (USIM Data)=4 (i.e. max disclosure impact of associated data types -personal and business), the threat risk calculated from the triplet <4, Low, Low>,and, hence, it is 4 (Medium) (Table 3). http://www.exploit-db.com/exploits/15548/ T17 Sensitive Information Disclosure (SID), Spyware. Herein the call logs disclosure threat is examined. This is associated with the triplet: <UsageHistory, read the user's contacts data + Open Network Socket, T17_Call_Logs>. The permission combination, according to [START_REF] Felt | The effectiveness of application permissions[END_REF], is Low (≤16%), while statistics about the threat likelihood are not available. Thus, the risk triplet is: < Impact DS (UsageHistory), Low, N\A>, i.e. <4, Low, N/A>. As a result the risk varies from Medium to High. T18 Corrupting or modifying private content. The removable storage corruption by junk file addition is herein examined. The permission involved in this threat is the 'Write to External Storage'. The threat triplet is: <Device, Write to External Storage, T18 Storage>. Relevant studies [START_REF] Felt | The effectiveness of application permissions[END_REF] have revealed the combination likelihood to Medium (≤50%), but additional data about the threat likelihood where unavailable at the time of publication. The threat triplet is: <Impact UA (Device), Medium, N\A>. Thus, the threat risk is 3-5 (Medium). T20 Client Side Injection/ Malware. The likelihood of this user downloading malware in her device is considered High, since: a) the user frequently installs applications in the device, b) user is not considered a security savvy one, and c) most smartphone malware are targeting Android (40% of mobile malware that was detected in Q3 of 2011 [13]). As in T11, this threat may affect all security attributes but not the hardware itself, the Impact DS,MD,UA (Device) is the max impact valuation of the data it holds, i.e. it equals with 4. Thus, the threat risk is High. T21 Direct billing. Since the user frequently makes use of the carrier data connectivity, in order to connect to the Internet, malicious applications may abuse the Internet permission to incur direct costs to the user. The malicious application needsapart from the permission to open network socket -access to the networking state, i.e. if the carrier data are being used. Hence, the involved triplet is: <USIMCard, Use Network Socket + Access Information about Networks, T21CarrierData>. The permission combination likelihood is High (≤86%)7 [START_REF] Felt | The effectiveness of application permissions[END_REF], and the threat likelihood is also High. Thus, the threat triplet is: <Impact MD (USIMCard), High, High>. As the Impact MD (USIM Data)=3 (i.e. max modification impact of associated data typespersonal and business), threat risk is calculated from the triplet <3, High, High> and thus it is 7 (High).

Table 5 summarizes the risk assessment of the threats included in the case study.

Conclusions

We have presented a risk assessment method that is tailored for smartphones. The method is compatible with established guidelines on risk assessment [START_REF]Information technology -Security techniques -Information security risk management[END_REF]. Nonetheless, contrarily to traditional risk assessment methods, which treat smartphones as a single entity, this method provides a more fine-grained valuation by: (a) dividing the device into various (sub)assets, (b) assessing smartphone-specific threats, and (c) taking into account the characteristics of a smartphone security model. User input for (sub)asset impact is based on a two-dimensional data taxonomy. The data analysis takes place transparently to the user and it leads to a 'personalised' risk assessment, as opposed to other smartphone-oriented methods, which use mainly expert opinions [START_REF] Hogben | Smartphones: Information security risks, opportunities and recommendations for users[END_REF], [START_REF] Shabtai | Google Android: A Comprehensive Security Assessment[END_REF]. The level of input detail varies according to user skill [START_REF] Ledermüller | Risk Assessment for Mobile Devices[END_REF] this may indeed affect the quality of results -but our approach requires minimum input, i.e. the data impact valuation. The method could be potentially used in order to extend an information risk assessment method to include smartphone-specific threats, as its theoretical basis is compatible with best practices, i.e. ISO27005 [START_REF]Information technology -Security techniques -Information security risk management[END_REF]. This is used in combination with a threat list to conduct risk assessment. The list was compiled by extending existing threat lists of smartphone literature. For threat assessment, risk triplets are introduced, which makes the approach novel. They use application permissions as the attack vector, associating assets to threats and permission combinations. Risk is, then, assessed as a combination of asset impact and threat likelihood. Finally, a demonstration of the proposed assessment method is provided, via a case study based on the Android platform.

It should be noted that generic conclusions for specific threats cannot be drawn by 'high' risk valuations of a hypothetical, single case. Risk is highly affected by the valuation of impact, which is a parameter that varies among different users. However, our method can also be applied in other smartphone platforms with permission-based security models (e.g. Symbian, Windows Phone, etc.), as well as in other platforms (e.g. iOS, BlackBerry, etc.) with some minor adjustments. For instance, risk triplets can be created by examining API library combinations of applications that exist in application repositories.

Future research may aim for an extended review of threats and vulnerabilities, along with an analytical dictionary of permission combinations. This will allow a more detailed threat assessment, based on past incidents or statistics, the presence of vulnerabilities or controls, analyzed on a per threat basis. We may also provide explanatory impact valuation tables and relevant questionnaires, which are appropriate for smartphone users.

Table 1 .

 1 Smartphone data taxonomy

	Information Type Source	Personal Business Government	Financial	Authenti-cation	Connecti-on/Service
	Messaging					
	Device						
	USIM Card	some	some	some	some		
	Application						
	Use history & caching		some	some	some		
	Sensor			

Table 2 .

 2 Smartphone threats

	Dimension	Threat

Table 5 .

 5 Risk assessment results summary

	Threat	Asset Impact	Permission Likelihood	Threat Likelihood	Risk
	T5	ImpactDS(GSM Service) = 4	N\A	High	High
	T10	Total_Impact(Device) = 4	N\A	Low	Medium
	T11	Impact DS,MD, UA (Device) = 4	N\A	High	High
	T13	Impact UA (Device) = 2	N\A	High	High
	T14	Impact DS (USIM Data) = 4	Low	Low	Medium
	T17	Impact DS (UsageHistory) = 4	Low	N\A	Medium-High
	T18	Impact UA (Device) = 2	Medium	N\A	Medium
	T20	Impact DS,MD, UA (Device) = 4	N\A	High	High
	T21	Impact MD (USIM Data) = 3	High	High	High

http://www.motorola.com/mdirect/manuals/V3i_9504A48O.pdf

A cell phone is a device which: a) is used primarily by its holder to access mobile network carrier services, e.g. phone calls, Short Message Services (SMS), etc., and b) contains a

A unique number that identifies the subscriber to the network.

The 10-digit phone subscriber number.

Any number of levels between 3 and 10 can be used[START_REF]Information technology -Security techniques -Information security risk management[END_REF].

Access to network state is granted to all Android applications without user intervention.

Acknowledgements. This research has been co-funded by the European Union (ESF) and Greek national funds, through the Operational Program "Education and Lifelong Learning" of the National Strategic Reference Framework (Program HERACLEITUS II: Investing in knowledge society through the European Social Fund).


Bernhard J Berger

Karsten Sohr

An Approach to Detecting Inter-Session Data Flow Induced by Object Pooling ⋆

Security tools, using static code analysis, are employed to find common bug classes, such as SQL injections and cross-site scripting vulnerabilities. This paper focuses on another bug class that is related to the object-pool pattern, which allows objects to be reused over multiple sessions. We show that the pattern is applied in a wide range of Java Enterprise frameworks and describe the problem of inter-session data flows, which comes along with the pattern. To demonstrate that the problem is relevant, we analyzed different open-source and a proprietary commercial software, with the help of a detection approach we introduce. We were able to show that the problem class occurred in these applications and posed a threat to the confidentiality of the closed-source software.

Introduction

Security tools, using static code analysis, are employed by software producers more and more frequently to detect security bugs introduced during the implementation. These static analyses can find bug classes, such as SQL injections and crosssite scripting vulnerabilities. The commercial success of those tools shows that industry is realizing the importance of software security [START_REF] Feiman | Magic quadrant for static application security testing[END_REF].

One kind of applications that are prone to the vulnerabilities mentioned above are business applications, offering services or web interfaces to customers. These systems share the property that they process data from different users at the same time that must be handled confidentially. To separate data from different users, the applications provide a session, an object that represents the server-side state [START_REF] Schumacher | Security Patterns: Integrating Security and Systems Engineering[END_REF]. The common bug classes pose a threat to the confidentiality of the user's data and the availability of the system.

A frequently-used framework to implement business applications is the Java platform, Enterprise Edition that supports different APIs to ease the development of business applications [19]. The core framework is complemented by different libraries like Apache Struts [START_REF]The Apache Software Foundation: Apache Struts[END_REF] or Spring [26], which provide additional capabilities and should reduce development time.

Within this paper, we describe an additional threat to the confidentiality of a user's data that relates to the object-pool pattern described by Kircher and Jain [START_REF] Kircher | Pooling[END_REF]. This pattern is used within different enterprise frameworks to improve the performance by reusing class instances for different requests [START_REF] Souza | Performance Models for the Instance Pooling Mechanism of the JBoss Application Server[END_REF]. Nevertheless, these pooled instances may create the possibility of confidential data-flows between different users of a system if they contain fields that are not handled correctly. This behaviour is known as the "Object Cesspool anti pattern" in the development community. Furthermore, we will show a light-weight and bytecode-based approach to detecting such vulnerabilities. The described approach is evaluated with the help of a closed-source and two open-source systems. We detected possible security vulnerabilities in the analyzed software and the vendor of the commercial software approved that a part of the reported findings were exploitable .

The remainder of the paper is structured as follows. An overview of related work is given in Section 2, followed by a detailed description of the problem, as well as a possible way to address it in Section 3. To show the validity of our approach, we evaluate our proposed solution in Section 4 and conclude with a summary of our work and a look on the next steps we will pursue in the future.

Related Work

There is a plethora of works that aim to find security vulnerabilities with the help of static analysis [START_REF] Ashcraft | Using Programmer-Written Compiler Extensions to Catch Security Holes[END_REF][START_REF] Chess | Improving Computer Security using Extended Static Checking[END_REF][START_REF] Wassermann | Sound and Precise Analysis of Web Applications for Injection Vulnerabilities[END_REF][START_REF] Nagy | Static Security Analysis Based on Input-Related Software Faults[END_REF]. One approach that handles vulnerabilities for Java enterprise applications was developed by Livshits and Lam [START_REF] Livshits | Finding Security Vulnerabilities in Java Applications with Static Analysis[END_REF]. They present a framework to detect different input-related vulnerabilities, such as SQL injections, cross-site scripting, HTTP response splitting, path traversal, and command injections. To find possible vulnerabilities, they identify sources of user input and track it through the entire application to certain methods that are known to be prone to a specific kind of vulnerability. When a possible data flow is found, it is an evidence for a vulnerability and will be reported.

Hammer and Snelting describe how static analysis can be used to check whether the confidentiality or the integrity of the data processed by a program can be threatened by a user [START_REF] Hammer | Flow-Sensitive, Context-Sensitive, and Object-sensitive Information Flow Control Based on Program Dependence Graphs[END_REF]. For their information-flow control, they use a program dependence graph, a representation already known in the area of static program analysis [START_REF] Krinke | Identifying similar code with program dependence graphs[END_REF][START_REF] Anderson | The codesurfer software understanding platform[END_REF][START_REF] Graf | Speeding up context-, object-and field-sensitive sdg generation[END_REF]. In a succeeding work, Hammer evaluates his approach with some real-world examples and lists results of his performance measurements [START_REF] Hammer | Experiences with PDG-Based IFC[END_REF].

Another well-known vulnerability class that can be detected with static analysis is time-of-check-to-time-of-use (TOCTTOU) vulnerabilities [START_REF] Bishop | Checking for Race Conditions in File Accesses[END_REF]. Here, an attacker tries to manipulate a file an application tries to read between the time it checks some properties (e.g. access rights or existence) and the usage of a file. Since the two operations are not atomic, an attacker might manipulate the file between the two operations, such as creating a symbolic link to another file to trick the application into deleting or overwriting it. It is a special kind of race condition between the programmer and the attacker.

Inter-Session Data Flow

In the following section, we first summarize whether certain frameworks or their implementation may use the object-pool pattern and how to detect these pooled objects. Afterwards, we give a detailed description of the problem and complement it with an example. Finally, we introduce our attempt to detecting the described problem.

Analyzed Frameworks

We searched different specifications and documentations for an evidence if the object-pool pattern may be applied in an implementation. We started with some core specifications, typically used in Java enterprise applications, such as the Enterprise JavaBean specification, the JavaServer Pages specification and the Java Servlet specification. Beyond that, we took a look at the Struts 1 framework, since it is used by our partners in the research project ASKS to implement their user interfaces.

Enterprise JavaBean An Enterprise JavaBean (EJB) is a managed component, running in an application container and follows a well-defined lifecycle that is steered by the application container. There are different commercial and noncommercial containers that implement one of the EJB specifications.

A special kind EJB is the stateless session bean, a component that is accessible for local and remote clients and implements business logic. The term "stateless" means that it does not hold a state to process a request sent by a client. Therefore, it is a candidate to be used within the object-pool pattern. The EJB specification in the version 2.1, as well as 3.0, states: "Since stateless session bean instances are typically pooled, the time of the clients invocation of the create method need not have any direct relationship to the containers invocation of the PostConstruct/ejbCreate method on the stateless session bean instance." [8, p. 8] and [9, p. 72]. This formulation does not prescribe the behavior of an application container, but gives a hint that the object-pooling mechanism may be used by application container implementations.

Depending on the version of the EJB specification, a stateless session bean must implement the interface javax.ejb.SessionBean or be annotated with javax.ejb.Stateless. Java Servlet A Java Servlet is a managed entity that reacts on requests and produces some response that is returned to the origin of the request. An example is the HttpServlet-Interface that reacts on HTTP queries and an implementing class can generate any valid HTTP response. The Servlet API, as well as the lifecycle that a Servlet container has to provide, are defined in the Java Servlet specification. The specification mentions that the servlet container may choose to pool such objects [17, p. 7].

The base interface for all Java Servlets is javax.servlet.Servlet. To detect all Servlets, one has to find all classes that implement this interface.

JavaServer Pages JavaServer Pages (JSP) is a Java-based template language to easily generate dynamic web pages. A programmer can write a textual file which he enhances with some quoted Java code to insert dynamic data at runtime. A typical field of application of JSPs is the generation of HTML and XML documents, which are served to a web browser. According to the JavaServer Pages specification [START_REF] Roth | JavaServer Pages TM Specification[END_REF], the base interface for all JSPs is javax.servlet.jsp.HttpJspPage which is a Java Servlet. Therefore, JSPs are possibly pooled, too.

Struts 1 Apache Struts is a framework that implements the model-viewcontroller pattern [START_REF] Reenskaug | Models -Views -Controllers[END_REF] for JSPs. The framework uses traditional JSPs for the view part of the pattern and adds Actions to assume the controller role. An action is a Java class that inherits from org.apache.struts.action.Action.

The online documentation of Struts 11 says explicitly that one should not use instance variables within actions because of possible multi-threading issues that originate from the fact that each action is instantiated once and reused for all requests.

Remark The specifications mention that pooling of objects may be used which means that it is an implementation-defined behaviour of the frameworks or application containers. We inspected some open-source implementations of the specifications under investigation, such as the JBoss application container [START_REF] Hat | Inc: Session EJB and MDB Configuration[END_REF], the Glassfish application container, the Tomcat web server, and the Struts implementation and found out that all of them use object pooling.

A developer, who uses the aforementioned frameworks, does not explicitly use the pooling mechanism, instead he implements certain interfaces or uses some given annotations and the framework automatically pools instances of these objects. None of the specifications mentioned above provide some kind of reset method that is called when an object is returned to the pool and whose task is to clear the state of an instance.

Problem

As already mentioned, enterprise applications allow different users to connect simultaneously. Unique identifiers assigned to each user allow the container to distinguish the different users and provide an independent session for each of them. Ideally, each session would be handled in its own memory area to avoid private data to leak between sessions.

If the response time of a software system is an important non-functional requirement, software architects may decide to use the object-pool pattern since it can improve the speed of an application, by reusing class instances [START_REF] Souza | Performance Models for the Instance Pooling Mechanism of the JBoss Application Server[END_REF]. Normally, an object is temporarily bound to the client that is using the object, whereas we observed in the case of Struts that it is also used concurrently by different clients.

The concept of object pooling contradicts to a strict separation of sessions since it explicitly shares object instances-which may contain sensitive information. This may lead to the aforementioned information flow between different sessions and therefore between different users, as long as the sensitive data is not removed when the instance is returned to the pool. This is not done by the frameworks we analyzed. The problem is depicted in Figure 1. Two different users are calling entry methods of a system, which call some internal methods to process the user request. Let us assume that the field on the right-hand side belongs to a pooled object. User B's request is processed first, an instance is fetched from the pool and a method is called that writes data to the field. The pooled instance now holds data of B and is returned to the object pool. The next request is issued by User A, who receives the same instance from the pool and calls a method that reads the data from the field and processes them. This constellation is a situation where sensitive information can leave the session (the framed area within Figure 1) of User A and flow into the session of User B or vice versa.

Example

A concrete example of an inter-session data flow problem is given in Listing 1.1, which shows a Struts action written in Java (see Section 3.1 for more information).

The action class ExampleAction has a private field userEMail of type String that can be accessed by the two methods enterEMail and sendEMail. These methods can be called by an HTTP request, depending on an HTTP parameter. The former method stores an e-mail address provided by the query into the field userEMail and does some additional operations, such as checking the provided value for correctness. The latter method uses the stored value from userEMail to send some private information to it.

The obvious problem in Listing 1.1 is the case in which User A sets her e-mail address and User B triggers the send method, which leads to the situation where data of User B might be sent to User A.

Detection Approach

To investigate whether the problem is relevant in real life, we implemented a detection algorithm to identify possible inter-session data flows using the Bauhaus tool-suite [START_REF] Raza | Bauhaus -A Tool Suite for Program Analysis and Reverse Engineering[END_REF]. The basis for our analysis is a resource-flow graph (RFG), which contains typed nodes for every declared element and typed edges for relations between those elements. For the Java language, there are, for instance, nodes for classes, interfaces, methods, and fields, whereas edges represent call relations, inheritance, field access, or the used types. The call graph, for example, is a part of our resource-flow graph.

To construct an RFG, we use the application's bytecode, which gives us the possibility to analyze a software without having its source code. To analyze JSPs we use the JSP compiler Jasper from Apache Tomcat [START_REF]The Apache Software Foundation: Apache Tomcat[END_REF]. With the help of the JSP compiler a JSP file can be translated into normal Java source code, which can be processed by the default Java compiler. This way, we do not need extra support for JSP files. The RFG for an application is generated from the class files belonging to the system under investigation, as well as the depending libraries.

A simple approach for detecting such data flows would be to search for all pooled classes and report them if they contain a field. This way, one can identify all potential vulnerabilities, but it produces false positives since not every field leads to a flow of sensitive information. To reduce the rate of false positives, we implemented a detection algorithm that is a bit more sophisticated (see Figure 1).

The algorithm consists of three automatic successive steps. First, we identify all pooled instances within an application (lines 2 -7). For this step, the method isP ooled uses the knowledge how to detect these objects which we have already described in Section 3.1. This step is similar to the naive approach. In the second step, we identify all methods that may be called by a user (lines 8 -9)-in contrast to those methods that are called by the framework. These entries are the same ones that are used by injection-related analyses, for example, described by Livshits et al. [START_REF] Livshits | Finding Security Vulnerabilities in Java Applications with Static Analysis[END_REF]. Starting from these entry methods, we traverse the static call graph (call to function getT ransitivelyCalled in line 10) to determine the methods that are reachable from the entry points. In the last step, we collect all fields, belonging to the pooled class that are accessed within the reachable methods (lines 11 -20). Finally, a tuple is created, consisting of the accessing method and the access type (read, write), and is added to the list of results of the field that is accessed (lines [START_REF] Hammer | Flow-Sensitive, Context-Sensitive, and Object-sensitive Information Flow Control Based on Program Dependence Graphs[END_REF][START_REF] Nagy | Static Security Analysis Based on Input-Related Software Faults[END_REF].

Input: RF G Resource Flow Graph Output: Result A list

Fig. 2. Detection algorithm for inter-session data flows

The results of our approach can be divided into four different classes, according to the fact whether they are read, written, or read and written. read only The case that a field is just read from entries may be harmless, but not in all cases. If the field is a base data-type, such as int, float or boolean or it is an class instance that is not manipulated (for example, immutable instances), the field cannot lead to an inter-session data flow. In this case, the state of the program is not manipulated and therefore it is not possible for sensitive data to flow to another session. In the case that a class instance is read, it is possible that a method of the instance is called that manipulates its state, which may lead to an inter-session data flow. write only If a field is just written, there is no way for sensitive information to flow since no other session will read the data that may be stored in the object. Therefore, these findings are flagged as false positives. read and write This group of results definitely can lead to data flows between sessions. The examples in Section 3.2 and Section 3.3 belong to this class. no access If a field is not accessed at all, it poses no threat to the confidentiality of the data and therefore this is a false positive finding in the naive approach, too.

Our approach reports the groups "read only" and "read and write" as findings, in contrast to the naive approach described above. We are aware of the fact that the reported findings are not free of false positives and false negatives. This shortcoming will be discussed in Section 4.2.

Evaluation

For our evaluation, we considered three applications, two being open source and the other being proprietary software. The criterion for selecting these was whether they used one of the frameworks analyzed in Section 3.1.

Evaluated programs

The first open-source application we analyzed is the Java version of enNode2 [START_REF]Open Source Exchange Network Node, supporting the National Environmental Exchange Network[END_REF]. A running instance of enNode2 is part of the Exchange Network, which has the aim to exchange environmental information between different States, Territories, Tribes, and the U.S. Environmental Protection Agency. The second application, called GSS [START_REF]File storage service with REST-like API, rich web GUI, webDAV[END_REF], is a file storage service used for the Greek research and academic community.

The closed-source application is made available by one of our partners and is a successful commercial business application that helps companies to declare goods electronically for the import and export. The software is offered to customers on a software as a service basis, which makes the confidentiality of the user data an important and not easy to ensure requirement, due to the size of the existing source code (over 600k LoC and more than 1000 JSP files).

The different frameworks of interest that are used by the analyzed programs are listed in Table 1. Within the table, "EJBs" stands for stateless enterprise session beans, not for all type of existing Enterprise JavaBeans. One can see that enNode2 is a web application that does not use Enterprise JavaBeans, whereas GSS does not employ the Struts framework.

Furthermore, Table 1 shows the size of the different systems, which was measured with sloccount2 . One can see that the proprietary software is the largest application, by far. Additionally, the table shows the time that was necessary to construct the RFG for the program and the time our analysis took.

The construction and analysis time shows that our approach is applicable for real-world systems.

Analysis Results

In the previous section, we showed which frameworks were used by which programs and gave a rough size estimation. Next, we highlight in Table 2 to which degree the classes that are implemented are pooled by a framework. 24% of all implemented classes in enNode2 are pooled, and 68% of these have at least one field. In GSS just 8% of all classes are pooled, but each of these classes contains fields. Finally, Commercial has a pooled rate of 30% and a quite high rate of 84% of the pooled classes that contain fields. In addition, Table 2 shows that the classes that contain fields have a medium rate of fields. In total, we found 473 fields of pooled classes within the implementation of enNode2, 88 fields in GSS and 10894 in Commercial. To determine whether the results may lead to inter-session data flows, we grouped the fields according to their usage as described in Section 3.4 and show the results in Table 3.

All fields that belong to the groups "write only" and "no access" are false positives and would have been reported by the simple approach in contrast to our approach. Therefore, our approach removes at least between 30% and 69% of the reported findings.

Discussion

With our approach, we can detect fields of pooled classes that may lead to inter-session data flow. Our approach has a lower false positive rate than the naive one since it identifies fields that cannot transfer data between sessions (see Section 3.4). Nevertheless, the findings reported by our approach still contain false positives3 , since we just use control flow and field accesses for our detection. In order to improve the quality of our analysis, we are planning different enhancements that will be described in Section 5, such as a data-flow based approach. However, we were able to show with the help of our approach that the problem of inter-session data flow is relevant in the applications that we analyzed.

A possible reason for the quite high rate of unused fields may be the use of reflection, a typical source of false positives in static analysis. In some situations, it is not possible to determine which class is instantiated or which field is accessed. There is a work by Bodden et al. that uses run-time monitoring to track the aforementioned information and enhances the intermediate representation with the gathered details at analysis time to improve the results of static analysis [START_REF] Bodden | Clara: a framework for statically evaluating finite-state runtime monitors[END_REF].

To validate the results of our approach, we manually checked the assignment to the different groups of a part of our results and found that all checked findings were categorized correctly. During the checks, we noted that the classes generated by Jasper for the JSP files all contained generated fields that belonged to the read-only group. A manual inspection suggests that these fields do not transfer data between sessions and therefore are false positives that we cannot identify with our approach.

Beyond that, we inspected, in collaboration with the vendor, the reported problems of the commercial software. The vendor was able to identify several findings that have caused trouble in the past. In particular, customers complained that their data were messed up with data from other customers sporadically and the programmers were not able to identify the cause of the problem because they could not reproduce the symptoms, which the users reported. For some of our findings, we created automated reproducers that repeatedly called some functionality until the results indicated that the data do not belong to the current user. After removing the fields, we were unable to reproduce the erroneous behaviour which shows the effectiveness of our approach.

We described the problem of inter-session data flows that may arise from the wrong usage of the object-pool pattern in the context of different Java Enterprise frameworks. Furthermore, we developed a light-weight approach to detecting such flows that produces a lower rate of false positive than a naive approach and showed that this kind of problems appeared in open-source as well as in proprietary software. The size of our case study is relatively small and must be increased in our future work. Nevertheless, our approach helped us to identify and remove existing security holes in a commercial software.

In order to improve our approach, we are planning to implement several refinements. First, we plan to automatically detect the object-pool pattern, which makes the preliminary manual inspection of the framework documentation superfluous. Second, we are going to track the flow of user-related data through a system and find out whether the data are stored in memory locations that may be accessed from different sessions, in contrast to our current mere control-flow based approach. This task is similar to taint checking, employed to find injection vulnerabilities. Last but not least, we want to exclude the cases where checks are implemented which make sure the data cannot flow, such as locking and resetting areas that access the field.

Fig. 1 .

 1 Fig. 1. Communication between sessions

  of tuples, containing the method and the access type, for each field

	1	begin
	2	pooled ← ∅;
	3	foreach Class class ∈ RFG do
	4	if isPooled(class) then
	5	pooled ← pooled ∪ {class};
	6	end
	7	end
	8	foreach Method method ∈ RFG do
	9	if isEntry(method) then
	10	foreach Method callee ∈ getTransitivelyCalled(method) do
	11	foreach Field field ∈ getReadFields(callee) do
	12	if getContainingClass(field) ∈ pooled then
	13	Result[f ield].append((callee, Read));
	14	end
	15	end
	16	foreach Field field ∈ getWrittenFields(callee) do
	17	if getContainingClass(field) ∈ pooled then
	18	Result[f ield].append((callee, W rite));
	19	end
	20	end
	21	end
	22	end
	23	end
	24	end

Table 1 .

 1 General information of the analyzed systems

	Project	EJBs JSPs Servlets Struts	LoC [k] RFG	Analysis
		1		[min]	[min]
	enNode2		85	2:27	0:43
	GSS		36	0:24	0:07
	Commercial		614	4:42	1:51

Table 2 .

 2 Frequency of pooled classes

	Project	Num. of	Num. of	Pooled	Avg. Num.
		Classes	Pooled	with Fields	of Fields
			Classes
	enNode2	438	107 (24 %)	68 %	6.48
	GSS	164	14 (8 %)	100 %	6.29
	Commercial	4901	1485 (30 %)	84 %	8.72

Table 3 .

 3 Results grouped by access type

		enNode2	GSS	Commercial
	read only	54.12 %	30.68 %	57.35 %
	write only	0.42 %	0.00 %	4.56 %
	read and write	4.23 %	0.00 %	11.92 %
	no access	41.23 %	69.32 %	26.16 %

http://struts.apache.org/1.x/userGuide/building controller.html

http://www.dwheeler.com/sloccount/

Nota bene: The naive approach reports the same false positives.

⋆ This work was supported by the German Federal Ministry of Education and Research (BMBF) under the grant 01IS10015B (ASKS project).


Yulong Zhang
email: zhangy44@vcu.edu

Min Li

Kun Bai
email: kunbai@us.ibm.com

Meng Yu

Wanyu Zang
email: wzang@vcu.edu

Incentive Compatible Moving Target Defense against VM-Colocation Attacks in Clouds

Keywords: Cloud computing, Moving target defence, VM migration, VCG mechanism

 reveals that virtual machine (VM) colocation based side-channel attack can leak users' privacy. Techniques have been developed against side-channel attacks. Some of them like NoHype remove the hypervisor layer, which suggests radically changes of the current cloud architecture. While some other techniques may require new processor design that is not immediately available to the cloud providers. In this paper, we propose to construct an incentive-compatible moving-target-defense by periodically migrating VMs, making it much harder for adversaries to locate the target VMs. We developed theories about whether the migration of VMs is worthy and how the optimal migration interval can be determined. To the best of our knowledge, our work is the first effort to develop a formal and quantified model to guide the migration strategy of clouds to improve security. Our analysis shows that our placement based defense can significantly improve the security level of the cloud with acceptable costs.

Introduction

Cloud computing [START_REF] Armbrust | Above the clouds: A berkeley view of cloud computing[END_REF] is becoming a major trend in computing services with its inspiring features of elastic "data anywhere" and "computing anywhere". Generally, there are three types of cloud computing services: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). Among them the IaaS is the most fundamental one, where a cloud user owns a virtual machine (VM) and purchases virtual power to execute as needed, just like running a virtual server. A typical example of public IaaS is the Amazon Elastic Computing (EC2) Services [START_REF]Amazon web services[END_REF]. Although IaaS offers cost-efficiency and ease-of-use to cloud users, there are significant security concerns that need to be addressed when considering moving critical applications and sensitive data to the clouds. Recent work [START_REF] Ristenpart | Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds[END_REF] reveals the problem of side-channel based attacks through virtual machine colocation, showing that the adversaries can map the internal VM-placement of the cloud and mount cross-VM side-channel attacks by placing malicious VMs on the victim's physical server.

Many software level approaches [START_REF] Page | Defending against cache-based side-channel attacks[END_REF] and hardware modification methods [START_REF] Wang | New cache designs for thwarting software cache-based side channel attacks[END_REF][START_REF] Keller | Nohype: virtualized cloud infrastructure without the virtualization[END_REF] have been developed against the side-channel attacks. Unfortunately, the software approach cannot perfectly cover the new advances in attack models, and the hardware approach, modifying the cloud physical platform, is far from practical for commercial clouds. Using commercial off-the-shelf (COTS) components, the Shamir's secret sharing approach [START_REF] Shamir | How to share a secret[END_REF] can make the attack much harder. We can split our secret D into k pieces and store them into k VMs3 . Using Shamir's secret sharing, D can be easily constructed from all k pieces but knowledge less than k pieces reveals no information about D. Note that the secret sharing might be controlled by either a single party or multiple parties [START_REF]Workshop on Secret Sharing and Cloud Computing[END_REF]. Thus, the attacker will be forced to use brute-force-attacks to achieve colocation with multiple target VMs, according to [START_REF] Ristenpart | Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds[END_REF]. Now, the defense problems becomes how to protect the k pieces from being all captured by the attacker.

The methods to securely live-migrate VMs [START_REF] Danev | Enabling secure vm-vtpm migration in private clouds[END_REF][START_REF] Liu | Performance and energy modeling for live migration of virtual machines[END_REF] can make it much harder for adversaries to locate the target VMs [START_REF] Kant | Configuration management security in data center environments[END_REF]. As shown in Figure 1, the secret, "helloworld", is divided into two pieces and held by two VMs, initially as VM 0 and VM 2 . An attacker can launch VMs colocated with the benign VMs with some probabilities. For example, if VM 3 is controlled by an attacker, the attacker will be able to extract partial secret, "hello", out of VM 0 . Although the splitting of "helloworld" into "hello" and "world" can prevent the attack from reconstructing the secret from VM 3 , we should at the same time guarantee that VM 5 can never be taken over by the same attacker. The fact that the attack would simultaneously attempt to launch lots of VMs to enumerate the colocations with both VM 0 and VM 2 motivates the migration of the VMs, e.g. moving VM 0 to VM 1 . Unfortunately, there is currently no formal model to guide the dynamic migration strategy for clouds. Similarly, quantifying the benefits of dynamism still remains an open problem. Intuitively, the cloud provider can offload the choice to cloud users, letting them migrating at free will. Or the cloud provider can migrate VMs according to the security demandthose VMs with higher security demand of dynamism have higher chances to be migrated.

At first glance, this is reasonable. However, as long as some of the VMs sharing the secret are migrated, other VMs can take the free ride of the achieved dynamism. Since any rational cloud user will try to maximize their benefit 4 , he/she could report a lower preference of dynamism than the actual one, pining its hope on other VMs honest movements to reach the security goal. So in this case, the game equilibrium is that no one would truthfully report the security valuation and migrate.

Our goal and contributions: To solve the aforementioned problems, the goals of this paper are [START_REF]Amazon web services[END_REF] to model the migration benefit and cost, (2) to provide instructional criteria for the migration strategy of the cloud provider, and (3) to motivate the cloud users to migrate in a incentive-compatible way. In order to address these issues, we develop a migration strategy based on the Vickrey-Clarke-Groves(VCG) mechanism [START_REF] Nisan | Introduction to Mechanism Design (for Computer Scientists)[END_REF] in game theories, which can maximize the social welfare given the individuals are all "selfish".

The contributions of this paper are as follows. To the best of our knowledge, (1) this is the first work to address VM-colocation based attacks in clouds using moving target defense; (2) our work is the first effort to apply VCG game and realize incentive compatible migration in cloud; (3) we offer two criteria about how to make the strategy acceptable by rational cloud users, and how to determine the optimal time interval of migrations, (4) our analytical evaluation shows that our defense approach is practical for commercial clouds.

This paper is organized as follows. In Section 2, we review some of the fundamental concepts of game theory, especially the VCG mechanism. In Section 3, we present our proposed method. In Section 4, we evaluate the security and practicability of our scheme. We conclude the work in Section 5.

Preliminaries

Assumptions and Notations

We have the following assumptions: (1) the cloud controller and the migration process are all secure; (2) for simplicity, each migration of a VM will result in a constant cost in terms of service interruption and consume the same amount of resources; (3) the cloud provider has enough CPU, network bandwidth, and other resources to perform arbitrary migration; (4) the cloud provider has sufficient resources as the reward, e.g., extra memory or CPUs, to motivate the players to migrate, which will be further discussed later; and (5) a node's destination of migration is randomly chosen, as long as the cloud has free space. In reality, cloud provider would take performance and efficacy into consideration during the migration. For example, VMs with frequent connections should be placed close to each other. In this paper, for simplicity, we only measure security in the goal function, but a commercial cloud can freely modify the goal function as needed, where our game model remains the same.

The incentive problem of cloud migration can be modelled as a game. The specific game discussed here is a finite player, single round, simultaneous action, incomplete information game, with payoffs depending on the final result of players' actions. In the cloud migration problem, the game players, P 1 , P 2 , ..., P n , are n VMs sharing a secret. The cloud provider (game mediator) is denoted as P t , who doesn't participate in the game but operates the game. Players have actions which they can perform at designated times in the game, and as a result they receive payoffs. The actions of the players are denoted as X = (x 1 , x 2 , ..., x n ), and specially X -i = (x 1 , x 2 , ..., x i-1 , x i+1 , ..., x n ). The players have different pieces of information, on which the payoffs may depend; each player has his/her individual strategy to maximize his or her payoff. Each player P i ∈ {P 1 , P 2 , ..., P n } can decide whether to accept the migration request from P t or not, so x i = {accept, refuse}. For those who agree to migrate, the direct payment is pi , which measures the cost of downtime due to live mi- gration. Here we assume the cost of downtime is a constant value for each P i . As a result of migration, all the players get benefited. We measure the benefit as v i (X), where the valuation function v i quantifies P i 's real security demand of the overall dynamism. However, under the assumption of incomplete information, P i can decide to report a fake valuation function v ′ i at will. Finally, the utility function of each player is

u i = v i -p i .

Incentive Compatible Game

While our ultimate goal is to design a migration strategy to fulfil some security requirements, the problem is that in real-world cloud environment most of the cloud users are not willing to migrate their VMs unless it is necessary, because the migration will result in service interruption. So the main purpose of our work is to design an incentive compatible mechanism to mitigate this problem. Following Nisan's work [START_REF] Nisan | Introduction to Mechanism Design (for Computer Scientists)[END_REF], the terms "mechanism" and "incentive compatible" are defined as :

Definition 1 (Mechanism) [START_REF] Nisan | Introduction to Mechanism Design (for Computer Scientists)[END_REF] Given a set of n players, and a set of outcomes, A, let V i be the set of possible valuation functions of the form v i (a) which player i could have for an outcome a ∈ A. A mechanism is a function f

: V 1 ×V 2 ×...×V n → A.
Given the valuations claimed by the players, f selects an outcome, and n payment functions, p 1 , p 2 , ..., p n , where

p i : V 1 × V 2 × ... × V n → R.
Definition 2 (Incentive compatible) [START_REF] Nisan | Introduction to Mechanism Design (for Computer Scientists)[END_REF] If, for every player i, every v

1 ∈ V 1 , v 2 ∈ V 2 , ..., v n ∈ V n , and every v ′ i ∈ V i , where a = f(v i , v -i ) and a ′ = f(v ′ i , v -i ), then v i (a) -p i (v i , v -i ) ≥ v i (a ′ ) -p i (v ′ i , v -i )
, then the mechanism is incentive compatible. Specially, among those incentive compatible mechanisms, the Vickrey-Clarke-Groves (VCG) mechanism is the mostly used one. The VCG mechanism generally seeks to maximize the social welfare of all players in one game, where the social welfare is calculated as

∑ n i=1 v i . So the goal function of VCG is argmax a∈A ∑ n i=1 v i .
The VCG mechanism and the rule to design VCG mechanisms [START_REF] Nisan | Introduction to Mechanism Design (for Computer Scientists)[END_REF] are defined as: Definition 3 (Vickrey-Clarke-Groves mechanism) [START_REF] Nisan | Introduction to Mechanism Design (for Computer Scientists)[END_REF] A mechanism, consisting of payment functions p 1 , p 2 , ..

., p n and a function f, for a game with outcome set A, is a Vickrey

- Clarke-Groves mechanism if f(v 1 , v 2 , ..., v n ) = argmax a∈A
∑ v i (a) (f maximizes the social welfare) and for some functions h 1 , h 2 , ..., h n , where h i :

V -i → R (h i does not depend on v i ), ∀v i ∈ V, p i (v i ) = h(v -i ) - ∑ j̸ =i v j . Definition 4 (Clarke pivot rule) [9] The choice h i (v -i ) = max b∈A ∑ j̸ =i v i (b) is called the Clarke pivot payment. Under this rule the payment of player i is p i (v 1 , v 2 , ..., v n ) = max b ∑ j̸ =i v i (b) - ∑ j̸ =i v i (a), where a = f(v 1 , v 2 , ..., v n ).

VM-migration Based Moving Target Defence

The Optimal Number of Moving VMs

At first glance, it appears that maximum dynamism can be achieved if all VMs migrate, but in this section we will disprove it and find the optimal number of moving VMs. As denoted in Section 2, each player has the unique valuation function v i (X), where X = (x 1 , x 2 , ..., x n ) is the vector of actions of all players. Intuitively, v i has a positive correlation with the randomness or diversity of the VM placement. Suppose there are m physical nodes as the available candidates, and γof them are randomly chosen as the migration destination, of which the capacities (the maximum number of extra VMs one node can host using its current free space) are C = c 1 , c 2 , ..., c γ . If k out of n VMs are randomly selected to be migrated (k < ∑ γ i=1 c i ), the number of possible placements, N(m, γ, n, k, C) can be derived using the Balls In Bins analysis.

For selecting γ ones out of the m nodes, and selecting k ones out of the n VMs, the numbers of possible schemes are given respectively:

S(m, γ) = ( m γ ) , T(n, k) = ( n k ) (1)
The generating function for placing k distinguishable VMs (balls) in γ distinguishable nodes (bins) is

GF = γ ∏ i=1 ci ∑ j=0 x j j! (2)
where the coefficient of x k k! , denoted as θ(γ, k, C), is the number of the total number of possible placements.

Specially, if c 1 = c 2 = ... = c γ = c, Equation 2 reduces to be

GF = (1 + x + x 2 2! + x 3 3! + ... + x c c! ) γ (3)
Finally, the total number possible VM-placements is

N(m, γ, n, k, C) = S(m, γ)T(n, k)θ(γ, k, C) (4)
Given the m, γ, n and C, we can use Equation 4 to find k opt , which is the optimal number of moving VMs corresponding to the largest N. To make it tangible, an example curve illustrating the k -N relationship is shown in Figure 2. Since S(m, γ) does not contribute too much in the magnitude of N, we simply set γ = m (so S(m, γ) = 1); for demonstration, we set the total VMs as n = 25 and the capacity of each destination node as c = 4. From the curve we can learn that:

1. It is not true that a larger k is better, which means that the intuitive strategy of migrating VMs as many as possible is incorrect. 2. A larger γ, namely more destination nodes, significantly increases the number of possible placement schemes. 3. Compared to γ, N is even more sensitive to k. N can reach the order of 10 9 when k is still in the order of 10 1 , which implies the huge potential of VM migration as a moving target defense strategy.

On the one hand, the optimal k is given by

k opt = argmax k N(m, γ, n, k, C) (5)
and in reality, only cloud provider controls the complete information of m, γ, n, k, C, so it is the cloud provider's responsibility to calculate the k opt .

On the other hand, if we assign 1 to accept and 0 to refuse, we have the actual number of moving VMs, k real , as:

k real = n ∑ i=1 x i (6)
In economics, the valuation function should reflect the security preference of the cloud users. Since this is not the main focus of this paper, we simply model the preference as a linear function of the system diversity:

v i (X)| m,γ,n,C = λ i N(m, γ, n, n ∑ i=1 x i , C) + η i ( 7
)
where λ i and η i are determined by the ith cloud user's preference.

Once the cloud provider decides the security level, and thus the value of k, the rest is to motivate the randomly chosen k VMs, denoted as Ω, to get migrated. To satisfy the Clarke pivot rule defined in Definition 4, we design the payment function for each P i ∈ Ω as:

p i (X) = ∑ j̸ =i v j (X -i ) - ∑ j̸ =i v j (X) + pi ( 8
)
where pi is the constant cost due to service interruption as assumed. We will further intro- duce the determination of pi in Section 3.2.

The second part of Equation 8, -∑ j̸ =i v j (X), is actually a positive reward from cloud provider to the ith VM. It can be any form with monetary value equalling to it, like extra CPU scheduling credit, bonus VM life, extra network bandwidth and so on, depending on the need of P i . The first part, ∑ j̸ =i v j (X -i ), is the monetary charge of P i . If P i chooses accept, pi is the actual migration cost; if P i chooses refuse, pi is in the form of monetary charge. Given that everyone else accepts migration, if P i decides to migrate, we have k real = k opt ; if P i refuses to do so, k real = k opt -1.

Theorem 1 (The criterion for the migration decision) The mechanism with the valuation function shown in Equation 7 and the payment function shown in Equation 8 is individually rational if and only if

n ∑ i=1 λ i (N(m, γ, n, k opt , C) -N(m, γ, n, k opt -1, C)) > pi
Proof. To prove that the mechanism is individually rational, we should show that the mechanism has a utility of at least zero for each of the players. For those selected to be migrated:

u i (X) = v i (X) -p i (X) = n ∑ i=1 v i (X) - n ∑ j̸ =i v j (X -i ) -pi = n ∑ i=1 λ i (N(m, γ, n, k opt , C) -N(m, γ, n, k opt -1, C)) -pi (9)
Only when the value of the above equation is larger than 0, P i can achieve individual rationality. As a matter of fact, Theorem 1 provides a criterion for cloud provider to decide whether a migration is cost-efficient.

Theorem 2 (Incentive Compatibility) The mechanism with the above valuation and payment functions is incentive compatible and thus motivates the players to truthfully reveal their security preference.

Proof. To get to the proof of incentive compatibility, we must show that for any given i, X -i and the P i 's choice x i = accept or x i = refuse:

u i (X = accept ∪ X -i ) ≥ u i (X ′ = refuse ∪ X -i ) (10)
The utility of P i for X is given by

u i (X) = v i (X) -p i (X) = n ∑ i=1 v i (X) - n ∑ j̸ =i v j (X -i ) -pi (11)
Likewise,

u i (X ′ ) = n ∑ i=1 v i (X ′ ) - n ∑ j̸ =i v j (X -i ) -pi (12)

So we have

Incentive Compatible Moving Target Defense against VM-Colocation Attacks in Clouds

u i (X) -u i (X ′ ) = n ∑ i=1 v i (X) - n ∑ i=1 v i (X ′ ) = n ∑ i=1 λ i (N(m, γ, n, k opt , C) -N(m, γ, n, k opt -1, C)) ( 13
)
According to Equation 5, the value of Equation 13is always non-negative. Therefore, the mechanism is incentive compatible. In Equation 8 we introduced the pi , which is the constant cost of service interruption each time P i is migrated. According to [START_REF] Liu | Performance and energy modeling for live migration of virtual machines[END_REF], pi is determined by the initial memory size of a VM and the applications' memory access pattern. For demonstration, we illustrate the downtime due to migration in Figure 3. The platform specifications are listed in Table 1, and the VM that we migrate is of 1 vcpu, 1 GB memory and 4 GB disk. To test the influence to the cpu execution, we keep the VM executing "for(i=0;i<999999;i++); gettimeofday(&time,NULL);" and recording the execution period. As shown in 3a, the migration will bring in an execution delay of around 350ms. To test the influence to the network service, we keep measuring the VM's response delay of GET requests. As shown in 3b, there will be a 967ms downtime to the web server. P t and each P i can estimate the pi respectively, according to the service downtime.

The Constant Cost of Migration

Defense Timeline

Although the migration can confuse the attackers and force them to restart the attack procedures, with time going by the attackers can still figure out the new VM placement as well.

To solve the problem, we have to keep migrating the VMs, and how to determine the optimal time interval becomes a new problem. Following the model in [START_REF] Evans | Effectiveness of moving target defenses[END_REF], the State Transition Diagram (STG) of attacks is shown in Figure 4a. More specifically, the attackers have to firstly probe the placement of the VMs, for example, by continually creating and stopping their probing VMs and testing the colocation with target VMs; then, it takes some time to construct the attacks; and there is still a period before the attackers successfully gathering all the information. Any distortion of the VM placement, for example, by migrating any of the VMs to other places, will reset the attack to the initial state.

As shown in Figure 4b, suppose the total time needed for a successful attack is t 1 , the time interval between any two migrations t 2 should satisfy t 2 < t 1 , which offers the cloud provider the criterion to determine migration intervals. If t 2 ≥ t 1 , there is a highly chance for the attackers to fully extract the secret. In reality the constructing time and the launching time of the attacks could be treated as constants, while the probing time has a linear relationship with the N, which explodes with the increasing of γ as shown in Figure 5d.

Evaluation

Security

We can never guarantee that our defense strategy or algorithm is agnostic to the adversaries. So when we design a moving target defense scheme, we must ensure that the adversaries are impossible or difficult to recover our actual internal infrastructures even if the strategy is not secret. In the mechanism designed here, we assume that the forms of the valuation function and the deliberate payment function are known to the public. However, in reality the individual security preference is kept as a privacy of each cloud user, thus the adversaries have no way to get λ i and η i . Even if some of these parameter-pairs are exposed, as long as the adversaries cannot obtain the information of all the VMs in the cloud, our strategy based on the overall social welfare is always secure. Furthermore, during the generation of the migration scheme, γ are randomly chosen and the capacity C = {c 1 , c 2 , ..., c n } is a secret of cloud provider only, thus according to Equation 5 the final migration scheme is only known to cloud provider. Another indicator of one moving target defense scheme's capability is the number of the total target space. As demonstrated later in Figure 5d, N can increase rapidly with a small increase of γ. With the exploding number of possible VM placements, the adversaries are extremely difficult to enumerate all the possibilities.

We note that there might be information leakage during VM migration. But since the design of migration methods is not within the scope of this paper, we prospect more secured VM migration mechanisms.

Practicability

As shown in Figure 5, compared with c, γ contributes more on the value of both k opt and N max . Empirically, k opt ≈ γ; theoretically, for any c 1 , c 2 , x ∈ N and c 1 < c 2 we have

x c 1 c1! > x c 2 c2! and lim c→∞ x c
c! = 0, so according to Equation 3, γ has a significantly larger influence on the value of k opt . Consequently, for the real-world cloud providers, it is pretty easy to determine the optimal strategy by assigning k opt = γ without complex algorithms, which maks this approach scalable.

Another potential concern is that whether the cloud users are willing to split a secret into multiple VMs, which is the precondition of our VM migration based defense. As shown in Table 2, the small instance has a price of 1/4 of the price of the large one, and offers 1/4 of the compute units, 1/4.4 of the memory and 1/5.3 of the storage. Therefore splitting a secret from one large VM into four samll VMs won't largely increase the cost. Compare with the risk of being attacked through covert channels, the cloud users will be willing to endure the cost due to transferring computation from few large VMs to numerous small VMs.

Discussion and Conclusion

Our work can be extended in different avenues. First, only security goal is considered here for simplicity, but the valuation and payment functions can be easily adjusted to include the performance considerations. Second, so far we have only considered the non-cooperative game. Actually, there might be some connections between VMs on cloud, forming a cooperative game which is a competition between coalitions of players rather than between individual players. In the future, we will develop the mechanism in regard to the coordination game. Furthermore, in the next step, we will extend the mechanism to suite into the asymmetric information game, because in reality some VMs are offering services to other VMs (thus knowing some statistics of the latter), and some VMs may even be controlled by attackers with some knowledge of other VMs.

To summarize, we proposed an incentive compatible moving target defense of cloud VM-colocation attacks, based on the VCG mechanism. When the migration is acceptable by rational users and how to determine the time interval are discussed. Our analysis shows that this defense strategy is practical to be applied to commercial clouds.

Fig. 1 :

 1 Fig. 1: Shamir's secret sharing in cloud environment and the moving target defense through VM-migration.

Fig. 2 :

 2 Fig. 2: The k-N relationship when n=25, c = 4, and m=γ varies from 10 to 7.

  Impact on CPU execution time of a certain task due to migration. As illustrated in the graph, the execution downtime is around 360ms.

  Migration impact on response delay of web server. As illustrated in the graph, the web service downtime due to migration is 967ms.

Fig. 3 :

 3 Fig. 3: The influence of migration to VM computation and web service.

  Attack and defense lifetime.

Fig. 4 :

 4 Fig. 4: The timeline of attacks and moving target defense (VM migration).

  The ckopt relationship (m = γ = 10).

  The c -Nmax relationship (m = γ = 10).

  The γ -kopt relationship (c = 4).

γ

  The maximum N (d) The γ -Nmax relationship (c = 4).

Fig. 5 :

 5 Fig. 5: The influence to k opt and corresponding N max by adjusting c or γ in Equation 5.

Table 1 :

 1 Platform specifications of migration downtime experiment.

	Hardware (source and destination nodes): VMM:
	CPU: Intel Xeon x5650 2.66GHz × 2 RAM: 8GB DDR3 1333MHz × 3 Ethernet: Broadcom NetXtreme II BCM5709 Dom0 kernel: 2.6.34.7-0.7-xen Xen version: 4.0.1-21326-02-0.5 Dom0: openSUSE 11.3 x86_64

Table 2 :

 2 Amazon EC2 Linux/UNIX instances pricing and specifications (US East, up to January 2012)[START_REF]Amazon web services[END_REF] .

	Instance types Small Large	Price $0.085 per hour 1.7 GB Memory Compute Units Storage API name 1 160 GB m1.small $0.34 per hour 7.5 GB 4 850 GB m1.large

It is not necessary to have k identical VMs. We can have one service VM and k -1 secret holding VMs that can be very small and cost little.

Note that even if all the VMs sharing the secret are controlled by one user, because different VMs may have different purposes, each VM should be treated as an independent party with individual interest.

Acknowledgments. This work was supported in part by NSF Grants CNS-1100221 and CNS-0905153.