A Methodology for Evaluating Cloud Computing Security Service ...

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements 1

Sang-Ho Na, 2Kyoung-Hun Kim, 3Eui-Nam Huh 1, First Author Kyung Hee Univ., Korea, [email protected] 2 Gangdong College, Korea, [email protected] *3 ,Corresponding Author Kyung Hee Univ., Korea, [email protected]

Abstract Explosive growth in cloud computing is driving a paradigm shift to cloud collaboration and the mobile cloud. Security tends to be more complex in cloud computing, and this tendency is becoming more pronounced as time passes. Accordingly, numerous studies have attempted to address security service-level agreements. This paper presents a methodology for quantizing and evaluating security threats, employing an analytic hierarchy model designed from the user's perspective. This model weighs each security threat to consider which security controls are required to meet the user’s needs in a security service-level agreement.

Keywords: Cloud, Threat Evaluation, SLA, Security, Control 1. Introduction Emerging cloud collaboration services based on mobile devices seem to be very efficient and effective solutions for managing and accessing data. However, we must bear in mind that along with these benefits, security vulnerability and risk have been increasing, especially regarding privacy and data loss. Increasing service complexity has created a need for service-level agreements (SLAs) that cover emerging security issues as well as traditional aspects of security such as integrity and confidentiality. These SLAs should give users convincing answers about how their data are managed to ensure security. In this paper, we will provide a security threat evaluation model for use in measuring threats and negotiating security SLAs. In Section 2, we will discuss related work. In Section 3, we will propose a hierarchy model by analytic hierarchy process (AHP) and describe our threat correlation model. In Section 4, threats are analyzed based on their relative priorities. Section 5 concludes the paper and includes our plans for future work.

2. Related Works The SLA is a contract negotiated between a service provider and a user, establishing service levels, billing, and compensation for violations [8]. In cloud computing environments, the model, pay-as-yougo, caused by outsourcing resource requires reasonable SLAs regarding availability, security, etc. Wu et al. have reviewed recent research about SLAs, identifying sensitive issues such as the different SLA parameters of users and service providers and the difficulty of quantifying these parameters [7]. Due to continued service suspend in cloud computing environments, [9] give convincing answers to refunding model in regard to SLAs violation. Nowadays, security aspects are emerging as an issue for SLAs in cloud computing. A security SLA for cloud computing has been given considerable attention, how to get a single agreement between users and providers, in recent years [1–4]. The studies in [3, 4] illuminated the question of how cloud providers could address the user's security needs, such as integrity and confidentiality, from the SLA perspective and provided a good outline of security controls. Cloud security SLAs are negotiated between user and cloud providers [4]. A part of this view is particularly important in regard to the current emergence of the market for worldwide cloud collaboration services [5, 11]. Most research has only introduced security SLAs and provided security parameters, and has rarely focused on how to

International Journal of Advancements in Computing Technology(IJACT) Volume5, Number13, September 2013

235

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

measure these security aspects. As mentioned above, the parameters of SLAs, especially those of security aspects, are very difficult to estimate and calculate. To negotiate a specific security SLA, the foremost consideration is how to establish contractible security parameters and an evaluation methodology for each security parameter. The Cloud Security Alliance (CSA) has published articles about top threats, security guidance in cloud computing [6]. Among the various articles, “The Notorious Nine” provides top threats ranking, implications and security controls based on a survey of industry experts. It shows that security threats and parameters can be quantified, suggesting which threats are more influential and thus should take priority in security efforts. However, this ranking considered only the implications of specific security breaches, and did not consider the correlations between threats. To satisfy users’ security-specific SLAs, security aspects should be addressed from the users’ point of view. Tian et al. [10] suggested a novel threat evaluation model using the analytic hierarchy process (AHP) to attempt to address privacy and potential threats in Radio Frequency Identification (RFID), employing the AHP model to analyze user preference on threats.

3. Threat Evaluation Methodology To negotiate the specific security SLA, the most important thing is to evaluate the relative importance of security aspects, in a manner similar to the CSA’s threat ranking. We will discuss here how to measure security threats from the user’s perspective. Before proceeding with the question of how to negotiate security SLAs, we first define specific elements such as threats and security aspects.

3.1 Define of Security Threats and Aspects We considered threat correlation from the user’s perspective, choosing the five of the CSA’s nine top threats that are most important to the user. The five threats are data breaches (DB), data loss (DL), account hijacking (AH), insecure APIs (API), and malicious insiders (MI). After that, we categorized security aspects (Figure 2) related to SLA within a framework for security mechanisms [3], and graphed the possible implications of combined threats (Figure 1); for example, insecure APIs could cause breaking into a user’s account, and then her data will disappear permanently from cloud (Data Breach or Data Loss).

3.2 Establish Priorities of Security Threats We define the priority of each threat to mean that threat’s relative importance among the others. We suggest a constructed hierarchy model (Figure 2) that employs an AHP, a mathematics- and psychology-based decision-making technique reported by Saaty in 1970s [13].

Figure 1. Correlation between each threat

236

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

Figure 2. Hierarchy Model The criteria are evaluation bases for evaluating the alternatives; each criterion has a weight that corresponds to its relative importance among the threats.

4. Threats Analysis and Evaluation In this section, we will analyze features of threats using the criteria given in a thinking matrix of threats (Figure 3) and establish their priorities accordingly. To consider features regarding the five threats, we employed a 2 × 2 thinking matrix, which is used to facilitate better thinking and decisions.

4.1 Threat Analysis

Figure 3. 2 × 2 Thinking Matrix of Threats Our main considerations about security threats are whether the vulnerabilities are predictable or not and whether the issue is technical or not. For example, insecure API is predictable and is handled technically, while the MI is unpredictable and some of the issues related to the MI can be controlled and managed through security schemes like audits and verification. This approach is useful to establish the bounds of service providers’ responsibilities in a security SLA and provide guidelines for SLA documentation and costing of each threat.

4.2 Establish Priorities of Security Threats According to the AHP methodology, there are several types of hierarchy models according to the relations between criteria. The one of them has independent condition between criteria, while another

237

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

one has subordinate to the one or more other criterion. The CSA ranking only considers threats in isolation as independent condition model between threats, whereas our approach employs subordinate AHP in which threat correlation is considered. The pair comparison matrix of T regarding the criteria is T = (t ij), t ij = 1 and t ji=1/t ij is a reciprocal matrix. The dominant eigenvector of T is Wc = (W DB W DL WAH WAPI WMI ), using the weight values from the CSA report as a baseline (Table 1). Table 1 also includes our proposed dominant eigenvector Wc ', calculated considering dependence between threats (recall Figure 1). The notation Wt ' refers to a pair comparison matrix of impact with respect to threat t. Wc ' = Wc × (W DB ' W DL ' W AH ' W API ' W MI '), using the proposed W t ' values shown in Table 1. Each consistence index (CI) value of W t ' is (0.0194 DB , 0.0279 DL, 0.0271 AH, N/AAPI , N/AMI); these values are lower than 0.1, indicating a trustworthy result. The CI of W API and W MI are not available according to Figure 1; any other criteria do not impact to the API and MI.

DB CSA (Wc) (CI = 0.0248)

Proposed (Wc')

Table 1. Dominant Eigenvector DL AH

API

MI

0.0470

0.1009

0.2676

0.4205

0.1640

0.0240

0.0516

0.2012

0.4603

0.2629

4.3 SLA Evaluation Model Among numerous available cloud services, it is not easy for users to understand the technical security elements and evaluate which services will meet their security needs in terms of integrity, confidentiality, etc.; thus, providing guidelines for security aspects might help the general user. In a broker-based and market-oriented cloud collaboration environments, especially, service providers should be providing security scores regarding security threats, established according to the user’s point of view. To negotiate a contract about security SLA, we suggest the following SLA evaluation process:

Figure 4. Threat evaluation Service providers might first define security aspects for SLAs and then prepare formalized expressions of those aspects. To prevent the potential confusion that would be caused by different definitions, a standardized contract template should be used under the auspices of a service broker or another appropriate institution. The user can get convincing answers from a threat-based security SLA template that includes which security aspects are ensured by each service provider. The security requirements are compared with established priority values using a logical combination function which security parameters are not eliminated by specific method of each service provider respectively. The priority value, dominant eigenvector Wc calculated with regard to each of the five threats, will be updated based on service types, emerging security threats, user needs, etc. After evaluation, the result of security SLA of each service will be presented to user by classified grade. Depending on this grade, users can decide which service is best for their particular needs. Defining specific

238

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

security elements and itemizing security controls or solutions to deal with those elements are beyond the scope of this paper; we hope to address these issues in future work.

4.4 SLA Evaluation Methodology Below we present a security SLA evaluation methodology based on the five threats and their dominant eigenvector to estimate security SLA. Using the definitions and equations provided above, we will provide a security evaluation methodology based on various scenarios, and using the following notations: Ÿ  =    = 1, … ,  } : A set of l threats Ÿ  =     = 1, … ,  } : A set of n security methods or solutions such as alterantive in figure 2. Ÿ S =    q = 1, … ,  } : A set of o candidate services Ÿ ( ) : Weight value of ti Ÿ , = {  | = 1, … , } : A set of k candidate security schemes of serivce q regarding threat i such as Encryption, HMAC, etc. Ÿ , = {  | = 1, … , } : A set of k candidate security schemes of user regarding threat i such as Encryption, HMAC, etc. Ÿ TE  : A result of SLA evaluation of the service q regarding threat T. Ÿ C( ) : A logical combination function including ( ) and ′( ). Ÿ ( ) : A logical XOR function of R with M regarding threat i. Ÿ ′( ) : A logical AND function of ( ) with R regarding threat i. 

TE  = 1 −   ( )ⅹ ( )   , where E( ) means that  of service q can be eliminated by the combination of  ∈  by XOR function and E′( ) is remained  cannot be eliminated by the combination of  ∈  by AND function. A result of E′( ) can be present (a number of remained  ) / (a number of total  ). Let the  can be present using matrix about threats i as below: Ÿ Ÿ

, = [ 1 2 3 4 5 ] = [ 0 1 1 0 1 ] , = [ 1 2 3 4 5 ] = [ 1 1 0 0 1 ]

, where each 1 of , and means requirements of the user and provided security scheme respectively and otherwise marks 0. Then, E( ) = [ 1 0 1 0 0 ] and E′( ) = [ 0 0 1 0 0 ] and a result of ( ) is 1/5 and TE  is sum of ( )ⅹ ( ), where the i is 1 to 5. Suppose that there are two service providers and that their security methods or solutions are equivalent except for m3. Table 2 shows this example scenario, comparing the user’s requirements to two service providers’ formalized SLAs.

Table 2. Example of Security Aspects and Method list Threats(T) Insecure API Account or Service Traffic Hijacking Ÿ Ÿ Ÿ

User Requirements (Ri,u) Ÿ Ÿ Ÿ ID and Password Encryption Federated access control in untrusted network (public) environment Using user credentials Ÿ Ÿ Ÿ

Security Method of SP Service 1 (Ri,q) Service 2 (Ri,q) m1 m1 m2

m2

m3

—

m4

m4

mn

mn

239

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

4.5 Analyze Priorities of Threats We have suggested dominant eigenvector Wc and Wc' to assess threats. Figure 6 presents the assigned values for comparisons between threats; we use the numerical value in Saaty’s discrete nine-value scale [12]. Figure 6a is a comparison matrix (the independent condition in 4.2) based on the CSA report ranking, including the judgment of perceived risk and actual risk. Figures 6b–d show the respective impacts to AH, DL, and DB from other elements based on the subordination between threats presented in Figure 1. The API and MI do not have matrices because they are both influenced by themselves. The results of Table 1, above, are calculated using these matrices. The dominant eigenvectors are plotted in Figure 7.

Figure 6. Pairwise Comparison Matrix The priorities of API and MI are increased and the others are decreased because each value is normalized. In the case of CSA (Independent Condition), the survey of industry experts in cloud computing focused on threats specifically related to the shared, on-demand nature of cloud computing. Our priority results differed somewhat because of the subordinate features between threats. AH is caused by a vulnerability of a technical method or an insecure API. In addition, although the fatal problems of DL and DB are relatively unlikely to occur as a direct result of an insecure API or account and service hijacking, etc., it is still possible. When we consider security issues, most vulnerabilities can be predicted and prevented using the security control method, but some are unpredictable and difficult to control or manage, such as the malicious insider. The latter in above, are potential threats. The value of API as a subordinate is also a little increased, reflecting its role as a kind of trigger only to the five threats. Using these easily understood decomposed and categorized threat cases, we are able to estimate security threats and match them with a corresponding security control scheme.

Figure 7. Priorities Transition by Dependency

240

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

Let [Wc]p be a dominant eigenvector in respect of mutual influence between threats, where p is frequency and above Wc' is a result of the p = 1. Suppose that those effects last; then, the priority results are as follows: lim→∞ [ ] = (0.5396API 0AH 0.4603MI 0DL 0DB) Figure 8 shows that the most security breaches begin from the essential elements of the insecure API and the malicious insider. The API is the essential element of technology that delivers service to users, and the MI is the fundamental human resource element dealing with technology. Most security incidents, consequently, are preventable through diverse threat analysis, prediction, and technologies that are faithful to the basics. Some unpredictable threats could be handled well by appropriate controls. This result reminds us that managing human resources is the starting point of security.

Figure 8. Threat evaluation

5. Conclusion A constructed hierarchy model was employed to evaluate security threats in an attempt to establish priorities based on the AHP approach. We also suggested a model and methodology for evaluating security SLAs. We have shown an analysis of threats and priorities considering their correlations and subordination between security threats. This study will lay the foundation for future work on SLA measurement and estimation. Before evaluating SLAs, however, defining security threats and security elements for SLAs on the user side is more important. In future work we will attempt to establish these definitions and improve our SLA evaluation methodology through a feedback process and group evaluation by service providers.

Acknowledgements This research was supported by the MSIP (Ministry of Science, ICT&Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (NIPA-2013-H0301-134006) supervised by the NIPA (National IT Industry Promotion Agency).

241

A Methodology for Evaluating Cloud Computing Security Service-Level Agreements Sang-Ho Na, Kyoung-Hun Kim, Eui-Nam Huh

6. References [1] Mark D. Ryan, “Cloud computing security: The scientific challenge, and a survey of solutions”, Journal of Systems and Software, Elsevier, online, 2013. [2] Dimitrios Zissis, Dimitrios Lekkas, “Addressing cloud computing security issues”, Future Generation Computer Systems, vol. 28, no. 3, pp.583-592, 2012 [3] Chunming Rong, Son T. Nguyen, Martin Gilje Jaatun, “Beyond lightning: A survey on security challenges in cloud computing”, Computers & Electrical Engineering, Elsevier, vol.39, no.1, pp.47-54, 2013 [4] Bernsmed Karin, Jaatun Martin Gilje, Meland Per Håkon, Undheim Astrid. “Security SLAs for federated cloud services”, In Proceeding(s) of the Availability, Reliability and Security (ARES), pp.202-209, 2011. [5] Collaboration Services: Deployment Options For The Enterprise, Forrester, 2013, http://campustech nology.com/whitepapers/2013/06/cisco_collaboration-services-deployment-options-enterprise.aspx

[6] The Cloud Security Alliance, https://cloudsecurityalliance.org/ [7] Chenkang Wu, Yonghua Zhu, Shunhong Pan, “The SLA Evaluation Model for Cloud Computing”, In Proceeding(s) of the International Conference on Computer, Networks and Communication Engineering, pp.331-334, 2013. [8] A. Sahai, S. Graupner, V. Machiraju, and A. Moorsel, “Specifying and Monitoring Guarantees in Commercial Grids through SLA,” In proceeding(s) of IEEE/ACM International Symposium Cluster Computing and the Grid (CCGrid ‘03), pp.292-300, 2003. [9] Al Amin Hossain, Cheol-Su Lim, Eui-Nam Huh, “Cloud Broker-based Refundable Service on Multitenant Environment”, In Proceeding of International Conference On ICT for Smart Society (ICISS), p.1-5, 2013. [10] Yuan Tian, Biao Song, Eui-Nam Huh, “A novel Threat Evaluation method for privacy-aware system in RFID”, International Journal of Ad Hoc and Ubiquitous Computing, Inderscience, vol.8, no.4, pp.230-240, 2011. [11] Hassan, Mohammad, Song, Biao, Huh, Eui-Nam, “A market-oriented dynamic collaborative cloud services platform”, annals of telecommunications, Springer, vol.65, no.11-12, pp.669-688, 2010 [12] Lin, C-Cm Wang, W-C and Yu, W-D, “Improving AHP for construction with an adaptive AHP approach (A3)”, Automation in Construction, Elsevier, vol.17, no.2, pp.180-187, 2008 [13] Thomas L. Saaty, “How to make a decision: The Analytic Hierarchy Process”, European Journal of Operational, Elsevier, vol. 48, pp.9-26, 1990.

242