Security Overhead on a Service with Automatic Resource Management: A Performance Analysis

Security Overhead on a Service with Automatic Resource Management: A Performance Analysis Abstract As information about clients and businesses is migrating to the cloud, there are growing concerns about how safe this environment is. Furthermore, it is known that as more stringent levels of security are required, the countermeasures, necessary to maintain the security of the system, are subjected to increasing interference on the performance. In the case of cloud computing, it is possible to compensate the overhead generated by the security mechanisms by changing the number of available resources on-the-fly. The aim of this paper is to perform a performance evaluation of a service involving the application of security mechanisms. We considered the change of computing resources during the execution time by means of a dynamic and self-managed module, which was responsible for load balancing, efficient utilization of resources and Quality of Service level assurance. According to the results of the experiments, we verified that the approach in the Vertical environment provided the fulfilment of the requirements defined in the Service Level Agreement, even with security overhead, with slight changes in the service costs. 1. INTRODUCTION The concept of Cloud Computing is currently the norm among many Information Technology (IT) companies [1]; indeed it is based on many years of research in several areas of computing, such as: distributed systems, virtualization, fault tolerance, load balancing, interoperability, Web 2.0 applications, utility computing and autonomic computing [2–4]. In this context, cloud providers must offer a suitable level of quality of service (QoS) to all users. Owing to the different kinds of consumers, each with specific needs and the unpredictable nature of the Web, and the wide influence of content management on the overall behaviour of the application, the Cloud must be continuously monitored, evaluated and adapted to ensure it achieves the appropriate level of QoS [5, 6]. As well as all these challenges, there are requirements with regard to security issues in all fields of data processing, data storage and network communication, which are also important. As a result, the process of managing resources efficiently to ensure data security without losing performance on QoS is not a trivial task in Cloud environment [6, 7]. There are a lot of studies that address the problem of how to deal with various security issues on cloud computing environment [8–23]. Defining how security should be applied in service layers of a cloud computing environment and the extent to which it interferes with both the quality and cost of the service offered, is a task that calls for further studies. The main providers available in the market do not show data regarding this interference. On the other hand, there are some studies that discuss the security overhead on the system performance [24–26, 10, 27–32]. However, they do not discuss a way to offset this overhead. Therefore, there is a need for security mechanisms together with the quality of service attributes related to performance, so that a link can be established between the provision of security, a guarantee of performance, and the cost of the service. In this paper, we present a solution to offset the overhead imposed by the security mechanisms on the service performance. Our approach, called Resource Management Module (ReMM), deals with resource provisioning mechanisms and renegotiating costs concomitantly. In view of this, the ReMM is capable of changing the number of virtual resources on-the-fly, which has an impact on costs, in an attempt to meet the clients requirements such as deadline and security level, as specified in the service level agreements (SLAs), and ensure an efficient use of the available resources. In this way, the main purpose of this paper is to perform evaluations that take account of the overhead imposed by the security mechanisms on the service performance, and analyse how to offset it. That is, the focus is not on setting out new security policies for cloud and helping to improve some aspects of the systems security, but rather on establishing a relationship between the ways security and a suitable performance can be achieved and investigate how this relationship affects the system response variables. For this, the follow steps were carried out: Study of the overhead imposed by security mechanisms on the performance of different systems. Several papers available in the literature were analysed, which carry out a performance evaluation considering the use of security countermeasures. The study carried out by Sanka et al. [24] was used in the composition of the analysed scenario, which implies an overhead of 28% on the environment performance. Performance evaluation, which through the design of experiments, allowed to evaluate the behaviour of the response variables, confronting the overhead imposed by the security mechanisms with the changes on-the-fly in the amount of resources carried out by the ReMM. This paper is structured as follows: Section 2 lists briefly the main security issues in cloud computing; Section 3 sets out the related work; Section 4 presents the ReMM, used to offset the security overhead; the methodology employed in conducting the experiments is presented in Section 5; the results are examined in Sections 6 and 7 ; finally in Section 8, the conclusions and findings of this paper are discussed, as well as some suggestions for future work. 2. CLOUD SECURITY Millions of users have been using networks for banking transactions, purchases, tax returns and other features, making network security one of the most important topics discussed in academic and industrial areas, and an essential issue in distributed systems [33]. Security issues are intentionally caused by malicious agents trying to gain some benefit from a system and/or harming someone. According to Tanenbaum and Wetherall [34], problems can be divided into the following interrelated areas: confidentiality, authentication, non-repudiation and integrity control, and can be avoided through the application of security services. In cloud computing, when a particular company migrates its entire logical infrastructure to a service provider, it does not worry about costly issues such as physical and logical infrastructure, purchase of hardware and software, refrigeration, physical space, training of professionals and idleness of resources. Its main concerns are related to the security of its data and operations, the time spent in the execution of the operations and the amount charged by the provider in the provision of a service, i.e. the quality of the service [35]. In addition, users must be able to trust cloud systems and their providers and be willing to submit to some level of control. This trust relationship is gained by controlling access to resources, securing data, meeting deadlines and managing events/operations [36]. An important factor that should be considered by both clients and providers is the trust of both parties. In a cloud, the trust can be defined as the certainty of the customer that the provider is able to provide the required services accurately and without failures. In this way, trust can be expressed as the client’s belief in the integrity, operation, experience and compliance with all regulations and laws by a service provider [37]. Outsourced or external environments such as those present in cloud computing require rigorous security practices and mechanisms to ensure data security in transit, data protection used in processes, key life cycle management, establishment of contractual rules with providers (requiring the correct destruction of data that is stored on media before it is released for use) and strategies for backing up [38]. In recent years, some troubling incidents have given rise to concerns about the secure handling of access, storage and data in cloud computing. For example, in 2008 a bug in the data centres of Amazon S3 resulted in many data users experiencing corruption, which culminated in failures in the file integrity verification.1 Another problem was noticed in June 2011, when a Dropbox update affected the authentication mechanism, resulting in inappropriate access being granted to user files with incorrect passwords.2 In 2014, a security break in the OpenSSL library allowed the exposure of encrypted connections. This setback affected most of the Linux and BSD operational systems and, hence, services such as Facebook, Twitter, Amazon, Oracle applications, IBM, VMware, and others. It is suspected that the National Security Agency (NSA) already knew about this vulnerability and exploited it to spy on encrypted connections, previously regarded as secure.3 Starting from around 2012, the use of ransomware scams has grown internationally. In 2017, a lot of companies, airports, hospitals, government agencies, in more than 150 countries, were impaired since this type of malicious software threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid, usually in bitcoin. Trying to face the threats, several studies that aim to address some of the security problems in cloud computing are available in the literature, as shown in [9] for control logs; [10] that uses the virtualization to increase cloud security by protecting the integrity of virtual machines and resources of the infrastructure; [22] that uses a scheme to detect anomalies; [8] for identity management; and [39, 21] for access control. A study on security in different service models is presented by Subashini and Kavitha [11]. Vaquero et al. [12] provide a comprehensive view of security in IaaS. Khorshed et al. [15] and Ardagna et al. [19] conducted a research into the threats and existing countermeasures to the cloud environment, as well as the challenges for the implementation of these countermeasures. Yang et al. [14] address the audit problem in data storage in a cloud presenting and analysing the possible solutions available in the literature. Zissis and Lekkas [16] present some threats and countermeasures available to a cloud environment. In the work presented by Modi et al. [17], the authors discuss various types of intrusions that may threaten the integrity, confidentiality and availability of cloud services. Amoud and Roudiès [23] present a literature review of privacy and security approaches for cloud computing. Therefore, there are a lot of studies in the literature showing that security in cloud environments is an important and essential topic both in academic and industry world. Every computational system needs to be protected against a wide range of threats so that it can guarantee confidentiality and integrity, as well as the availability of data and resources. However, a number of factors need to be addressed, such as the sensitivity of the data and the resources that an application will handle, to assure the correct scaling of the security mechanism without compromising the entire environment. In addition, when analysing performance and security, the effects produced by different security mechanisms should be evaluated by different QoS metrics [40]. As the Internet is the basic technology of cloud computing, all the concerns it raises are inherited. The cloud infrastructure is about more than the hardware, where the data are processed and stored, and includes the way that the data are transmitted and accessed. In a cloud, the data are transmitted from the source to the destination, by means of several devices and forms of infrastructure owned by third-party organizations, which allow the data to be intercepted and modified [41]. Thus, even if a number of security mechanisms are implemented by the client and provider, the data still remain vulnerable. Service providers offer computational resources to the clients, and allow them to host their data or execute some application. Their clients can also use the hired infrastructure to offer services to other clients, this second class of clients is called users. This means that the providers have to provide security mechanisms to ensure that no virtual machine will interfere in the others VMs of the different clients, ensuring the isolation among them. Moreover, when a client hires an IaaS service, for example, and provides services to other users, the IaaS provider is unconcerned about the nature of the operations or the management of the requests by the companies who hire its services. Currently, none of the most popular service providers, such as Amazon S3, Google Drive and Microsoft Azure, provide security guarantees in their SLAs. Amazon S3 and Microsoft Azure, for example, only guarantee the availability of the service in their SLAs. If the service metric of availability falls below 99.9%, the clients should be compensated in accordance with clauses in their contracts. Amazon states that the security virtual machine is the clients’ responsibility, since they are free to run any kind of operating system or even application. Thus, clients are responsible for ensuring the security of virtual machines hosted on cloud providers. In view of this, given the importance of the facts outlined above, the next section shows a review of mechanisms available in the literature that aim guaranteeing security in a cloud environment. Security mechanisms are very important to ensure the integrity, availability and confidentiality of the data and resources. However, their overhead on the system performance must be considered. 3. RELATED WORK There are several studies in the literature addressing cloud computing security issues related to access, storage and handling of data and resources in the provision of a service by VMs. This section presents an analysis of some papers considering the overhead imposed by security mechanisms on environmental performance. Sanka et al. [24] discuss the challenges related to secure access to data in cloud computing. The authors proposed a security approach in which access and encryption control mechanisms were used for data protection. They modified the Diffie–Hellman key exchange mechanism [42] so that it can be used by both the service provider and the client for the symmetric key sharing and manipulation of data. In addition, the authors proposed an access control based on capability, with cryptographic techniques for a cloud platform, and a list of capacity that is used to specify the access rights of users. A simulated environment was used for the implementation and analysis of experiments, in which the proposed solution generated an overhead of ~28% in the system. In the study presented in [25], the authors proposed a solution based on fine-grained access control mechanisms, through authorization and authentication mechanisms and federated identity. The overhead introduced by multitier architecture and the security mechanisms are measured through experiments on a prototype called PerfCloud, allowing comparative analysis between security and performance. According to the results, the use of authorization mechanisms such as XACML hardly generated overhead on the system, <0.01%. Regarding the transport channel and the authentication mechanism, both influenced the performance of virtual and physical resources. According to the authors, both factors had a big impact on response time, 30%, and 60%, respectively. Finally, the use of a trusted third party (TTP) as a second option to make the authentication process had a major impact on the performance of the environment, because of the used mechanisms: authentication protocol (Secure Message), the transport channel (HTTP) and authorization mechanisms (MapFile and XACML). The overhead generated was ~184% on the response times. The aim of the study presented by [26] was to investigate how to provide privacy and integrity for applications that run on untrusted nodes, in which the hardware and the operating system are vulnerable to attacks. For this, the authors proposed the SecureMe, a mechanism for hardware and software that provides a safe computing environment. The SecureMe aims to protect an application from hardware attacks, using a secure processor, and also against operating system attacks, through memory camouflage, paging permission and protection of system calls. Experiments were carried out in a simulated environment using Simics simulator [43], which allowed a performance evaluation using micro benchmarks and different loads. The authors found that the SecureMe adds an overhead on the execution time of ~13.5% compared to a completely unprotected system. Lombardi and Di Pietro [10] discuss how virtualization can increase the security of cloud computing, protecting both the integrity of virtual machines and the cloud infrastructure components. They proposed an architecture called Advanced Cloud Protection System (ACPS), which aims to ensure the security of resources. The ACPS can be implemented in various cloud solutions and can effectively monitor the integrity of the VMs and the components of the infrastructure in a transparent way. For this, regular checks of checksum files and libraries are made and, according to the results, the ACPS can react locally to security breaches, and notify the environmental manager. A prototype was implemented using Eucalyptus and OpenECP. The prototype was tested against attacks and an analysis of the proposed architecture was performed with different types of load. The results show that ACPS is resilient against attacks and that the overhead introduced was ~6%. Popa et al. [27] conducted a performance evaluation of the security mechanisms available in CloudProof. CloudProof was designed to ensure the confidentiality and integrity of data, write-serializability among multiple users and freshness version of the file. In addition, the CloudProof guarantees access control and is able to detect breaches in data integrity, compensating the client in case of a mishap. According to the authors, the use of CloudProof introduced an overhead of ~17% compared with experiments in which this mechanism was not used. There was also a reduction of ~10% in the throughput for data storage in the cloud. The used cryptographic algorithms were: SHA-1 for hashing, AES for symmetric encryption and RSA signature with a key of 1024 bits. Zhang et al. [28] proposed a transparent approach that protects the privacy and integrity of virtual machines in virtualized infrastructures. According to the authors, a prototype called CloudVisor was designed, which is able to provide privacy and ensure the integrity even if the hypervisor and the virtual machines manager are under the attacker’s control. Some experiments were carried out for a performance evaluation with different numbers of clients, numbers of virtual cores in a VM and numbers of VMs. I/O operations correspond to the neck of CloudVisor, because of cryptographic operations with the AES algorithm and hash operations. In the results, the overhead generated by the use of CloudVisor and I/O applications ranges between 4.5% and 54.5%, compared with experiments in which Xen hypervisor was used. This variation is related to the number of clients. Bates et al. [29] proposed an access control model for data storage in the cloud. The authors considered the management and validation of metadata from a reliable source system and introduced protocols that allow the secure transfer of metadata between end-hosts and cloud entities. Using these protocols, they have developed a prototype for provenance-based access control in cloud storage, called Cumulus, able to process thousands of read and write operations per second. Through replicated components, the system generated an overhead of ~14%, which according to the authors, showed that the provenance-based access control is a practical and scalable solution for the cloud. In the study carried out in [30], the authors proposed a fine-grained access control mechanism for a peer to peer (P2P) storage cloud, called Access Control mechanism for P2P storage Cloud (ACPC). Through this mechanism, it is possible to exploit the storage space in a cloud of participants using a P2P system. However, since the providers and users are in different domains, often unreliable, some challenges arise related to data security and access control. To resolve these problems, the authors developed encryption techniques such as Ciphertext-Policy Attribute-Based Encryption (CP-ABE) [44] and Proxy Re-Encryption (PRE) [45]. Thus, according to the authors, the ACPC can resist collision attacks and protect users’ information effectively. A performance analysis is presented, in which the ACPC was compared with other state-of-the-art revocable ABE schemes such as BSW [44], W [46] and HN [47]. In the results, the operations performed by the ACPC showed the less harmful overhead on the system, ~13.2%. In the study highlighted in [31], the authors presented an architecture in which the provider can offer security as a service to its clients. The proposed security model offers both basic security for the provider to protect its infrastructure, and a flexible security that provides additional security mechanisms. For basic security, the authors proposed a component called service provider attack detection (SPAD). For flexible security, the authors proposed a component called tenant specific attack detection (TSAD). In addition, they provided mechanisms against attacks on the hypervisor. For this, they used the Security Gateway that specifies policies and mechanisms to detect attacks on the hypervisor. A performance analysis of the proposed architecture is presented. In the results, the operations performed by SPAD and TSAD introduced an overhead of ~6% with different types of attacks. He et al. [32] proposed a security architecture called network security for cloud computing (NSCC), which aims to solve the security issue on the network in a cloud. According to the authors, NSCC deals with issues related to scalability, fault tolerance and use of resources in a safe way, preventing the system against internal and external attacks. In NSCC, the security management domains (SMD), the security meta group (SMG) and the virtual switch (vSwitch) work together to ensure the security of the cloud. The SMD defines the routing rules of vSwitch, and this in turn, forwards the internal and external traffic through the SMG. Finally, the SMG performs the inspection and filtering of incoming and outgoing traffic of the cloud service users. Some experiments were performed on a prototype. In the experiments, the overhead was measured by comparing an environment with NSCC and an unsafe environment. According to the results, the NSCC imposed an overhead of ~9.3% on the throughput and network latency. In this section, some papers were analysed, which aim to set out specific security mechanisms as countermeasures against certain threats. As a result of this, the main objective of this analysis is not to compare them, insofar as each has its own modelling features and view of the security problem, experimental planning and the execution environment. The aim of this analysis is rather to survey the available works in the literature which examine the critical security factors discussed in this paper. It also investigates the best way to carry out an evaluation of the overhead generated by security mechanisms and how this affects performance in a cloud environment. Furthermore, although all the analysed papers present an impact assessment of the security mechanisms on the system performance, they did not aim to handle this overhead. The study presented in this paper explores the hypothesis that it is possible to face the overload generated by the security mechanisms through an alteration of computational resources in the environment carried out by the ReMM. 4. RESOURCE MANAGEMENT MODULE The ReMM concerns the way the available resources are handled during the execution time with regard to the QoS metrics defined in the SLA. We outline a resource management module for cloud applications in which both horizontal and vertical scalability can be applied dynamically, thus leading to a change in price. The most common type of scaling is horizontal scaling which involves the allocation and release of virtual machines. The other type is vertical scaling which either increases or reduces the computing resources (vCPU, memory, disk, etc.) of one or more instances [48]. In this way, the ReMM aims to satisfy both the clients (thus ensuring the SLA at a fair price) and provider by using the resources available in the system efficiently. A client’s request will be answered by a provider, which uses three layers and can provide different services: application layer (Software as a Service—SaaS), platform layer (Platform as a Service—PaaS) and infrastructure layer (Infrastructure as a Service—IaaS). The application layer handles all the application services that are offered to the clients. The platform layer includes mapping and scheduling policies which are designed to translate the clients’ QoS requirements to infrastructure level parameters and allocating virtual machines to meet their requests. The infrastructure layer carries out the initiation and removal of VMs with specific resource configurations for the client in a transparent way. Figure 1 shows the proposed module. Figure 1. View largeDownload slide ReMM operation. Figure 1. View largeDownload slide ReMM operation. First of all, the client and provider must negotiate a SLA, by defining the QoS metrics and the contract details (1). After this procedure, different clients request different types of services from a provider. The Admission Control is responsible for analysing the request and decides whether or not it can be met (2). During the system overload, for example, the service provider can decide either to reject the new requests or violate the SLA. The SLA violation should result in penalties for the provider. If the request is accepted, it will be stored in the Requests Queue (3), where it will receive a priority that will define the execution sequence (a service differentiation can be applied, for example, with different kinds of clients). The ReMM will provide the virtual resources based on the information defined in the SLA (4), and place them in the physical resources (5). After the resources allocation, the Scheduler forwards the requests (6) so that they can be run on resources using scheduling policies (7.a) (7.b)—initially the Round Robin policy was developed. At intervals of time, the Performance Monitor collects information about the system performance and about the request execution (8) and sends them to ReMM (9.a). This information is compared with the QoS information available in the contract (9.b) and if the results are not in accordance with the SLA, the ReMM dynamically adjusts a number of resources (horizontally or vertically) in an attempt to ensure the SLA (10). Any changes in the system influence the Business Model (11). In view of this, the ReMM is capable of changing the number of virtual resources on-the-fly, which has an impact on costs, in an attempt to meet the clients requirements, as specified in the SLAs, and ensure an efficient use of the available resources. Further information about the experiments and analysis of ReMM can be found in [49, 7]. In the next section, there is an analysis of a cloud service, which makes it possible to confront the overhead generated by the security mechanisms required by the clients with the ReMM and evaluate the impact on the defined response variables. QoS-driven approaches for different environments were defined on the basis of the results and these took account of the overhead imposed by the security mechanisms, the performance, and the service costs. 5. DESIGN OF THE EXPERIMENTS In the analysis, the CloudSim 3.0.3 simulator was used to design the cloud environment with ReMM. A scenario was created consisting of three entities: users, the client, and provider (Fig. 2). The client hires the infrastructure from a provider to allocate a service. This service provides the storage and data sharing (for example, music and movies) for multiple users. Figure 2. View largeDownload slide Relation between providers, clients and users. Figure 2. View largeDownload slide Relation between providers, clients and users. In the proposed analysis, a client can have access to a service with security, which must be run on a particular VM in the provider, in a transparent way and respect the deadline specified in the SLA. However, the use of security mechanisms leads to an overhead on the service, which will be confronted by the ReMM, unlike the other papers presented in Section 3. For this reason, the ReMM must analyse the request execution time and compare it with the deadline defined in the SLA, which in the experiments is 100 seconds with an SLA variation margin of 20%, i.e. the service execution time can range between 80 and 120 seconds [7]. If the result is not in accordance with the contracted performance, the amount of resources allocated must be changed in accordance with the scalability algorithm provided by ReMM, and this has an effect on the response variables. Changes made by the ReMM through its scalability algorithms follow the analysis conducted by [49], in which the Vertical algorithm only changes the number of vCPUs (virtual cores) of the VMs, where the changes have a percentage of 100%. This determines that eight vCPUs is the maximum number allowed per VM and one vCPU is the minimum value. In the Horizontal algorithm, ReMM changes the number of instances, where one instance is the minimum amount allowed. Both algorithms involve changes in the costs which are in proportion to the amount of changed resources. Three types of environments were designed to perform the experiments (Common, Vertical and Horizontal), and they employ different approaches. The Common is a non-scalable environment used by some providers, where the service requests must be executed by the previously allocated VMs, with no changes in the amount of resources during the execution time. In this way, the resource provisioning is static and the costs remain unchanged. The Horizontal environment applies a dynamic approach used by some providers like Amazon (Auto Scaling4). This model allows changes in the amount of resources allocated during the execution time. In this case, the horizontal scalability is applied, and the adjustments to the cost are in proportion to the number of allocated instances. Finally, the Vertical environment employs an approach that takes into account changes in the specific features of a VM, for example, the amount of memory, disk or processor cores (vCPUs). Based on the study carried out by Batista et al. [49], the experiments include changes in the number of vCPUs of a VM, which reduce fluctuations in the costs, since they are proportional to the number of allocated vCPUs. That is, an instance has an initial price, which can change if the number of virtual cores is changed, while the other resources that compose a VM remain unchanged. A client requests an image rendering execution and storage through the Monte Carlo algorithm. This type of service request was modelled on the Smallpt benchmark.5 With regard to the amount of overhead imposed by the security mechanisms, the study presented by Sanka et al. [24] and discussed in Section 3 was used, in which the overhead is 28%. A provider consisting of data centres has been set up to carry out the experiments and hosts the virtual machines that run the service requests. In the experimental environment, the hardware heterogeneity and the performance interference across the same type of cloud VM instances were not considered. The physical resources were regarded as unlimited, and thus, all the requests could be accepted and executed by the available VMs. Furthermore, the users are not differentiated in terms of priorities. The virtual machines used for the execution of the service requests were modelled based on the types of M3 instances of Amazon.6 Table 1 shows the settings of each VM, as well as the initial cost of each instance. It is worth remembering that the final cost may vary according to the environment, since the ReMM can change the settings of a particular VM or the number of instances during the execution time. Table 1. Specification of instances. Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  View Large Table 1. Specification of instances. Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  View Large Furthermore, the following response variables were considered and analysed: Execution mean time (EMT): average time spent on the execution of a request. In the experiments, it was decided that each request must be performed at ~100 seconds with a range of up to 20%. Final average cost per VM (FACVM): is the average of the final cost ($/hour) of using a VM, while allowing for possible changes in the allocated resources. The FACVM considers the initial average cost per VM (IACVM). Final average cost of the environment (FACE): is the average cost ($/hour) for the allocation of all the VMs used to meet the demand of requests during the environmental observation time. The FACE considers the initial average cost of the environment (IACE). Number of answered requests (AR): average rate of requests met by a cloud environment during the observation time. Used amount of resources: refers to the average number of vCPUs and instances (VMs) used in each experiment for the execution of a client request. A full factorial experimental planning was used for the experiments. This model is outlined by Jain [50] and is suitable for the analysis of the response variables. In this methodology, the planning and analysis of experiments include both factors and levels, where the factors correspond to environmental characteristics and the levels are the possible environmental variations. In this way, two factors and their levels were included. The factor Environment defines whether the experiments will be performed: in a Common environment (without the ReMM), a Vertical environment (in which ReMM applies the vertical scalability to change the resources) or a Horizontal environment (in which the ReMM applies the horizontal algorithm). Furthermore, the factor Instance corresponds to the type of allocated virtual machine required to execute the requests. Other important factors are the number of clients requesting services and the number of VMs initially available to meet this demand. Fixed values were adopted for these factors, in which 100 clients request services constantly during the experimental observation time. These requests were initially run by 50 VMs with settings that varied in accordance with the experiment planning. Each experiment was run 10 times, with an observation time of ~1.5 hours. Through 10 replications, it was noted that the results for each response variable did not show significant variations. Thus, the average, standard deviation (SD) and the confidence interval (CI) of 95% were calculated for each setting of the experiments [50]. 6. ANALYSIS OF THE RESULTS Figure 3 and Table 2 show the results of experiments in which we considered the use of security mechanisms. As highlighted by Sanka et al. [24] in Section 3, the use of security mechanisms provided an overhead of 28% on the system. Figure 3. View largeDownload slide Requests execution mean times. Figure 3. View largeDownload slide Requests execution mean times. Table 2. Results in environments with security overhead. EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  View Large Table 2. Results in environments with security overhead. EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  View Large In the results, the use of security mechanisms negatively influenced the service performance in which ReMM was not used (Common environment). As an example, we can mention the experiments with m3.medium instances, in which the EMT was 429.98 seconds. Compared to experiments in which the m3.xlarge instance was used, the unique type of instance where the SLAs have been met in a Common environment, there was a reduction in the response variable of ~75%. On the other hand, in the Vertical and Horizontal environments, the overhead imposed by security mechanisms was offset by changes in the amount of resources performed by the ReMM. In this way, the SLAs were ensured, generating reductions in the execution mean times of ~74% and 48% in environments with m3.medium and m3.large, respectively, and an increase of ~100% with m3.2xlarge instances. However, in the experiments with m3.xlarge instances, the results in the three environments were similar, since there were no statistical differences between the values obtained with the confidence interval of 95%. As shown in Table 3 and Fig. 4, whereas the overhead imposed by the security mechanisms was 28%, the ReMM changed the amount of resources as an attempt to offset this overload and to ensure the SLA. The changes impacted on the average number of answered requests. Figure 4. View largeDownload slide Average number of answered requests. Figure 4. View largeDownload slide Average number of answered requests. Table 3. Number of used resources and their impact on the number of answered requests.   Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893    Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893  View Large Table 3. Number of used resources and their impact on the number of answered requests.   Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893    Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893  View Large In the environments with the vertical algorithm, the changes in the number of vCPUs increased the final average costs, ~25% in the m3.medium instances and 8% in the m3.large. On the other hand, the ReMM reduced the number of vCPUs in the m3.2xlarge instances, reducing the final average costs, ~4%. The amount of resources available in the m3.xlarge instances was considered sufficient for the execution of service requests with security mechanisms. Hence, no change was necessary. Table 4 and Fig. 5 show the results. Figure 5. View largeDownload slide Final average costs per hour. (a) Virtual machine and (b) Environment. Figure 5. View largeDownload slide Final average costs per hour. (a) Virtual machine and (b) Environment. Table 4. Response variables with vertical scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  View Large Table 4. Response variables with vertical scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  View Large As presented in Table 5 and Fig. 5, in the experiments with horizontal scalability, there were significant increases in the amounts of m3.medium and m3.large instances, 300%, and 100%, respectively. Considering the m3.2xlarge instances, there was a reduction of 50%, while there were no changes in the environments with m3.xlarge instances. These increases in the amount of instances impacted in the same proportion on the final average costs of the environment. Table 5. Response variables with horizontal scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  View Large Table 5. Response variables with horizontal scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  View Large Although there is no statistical difference in the EMTs in the Vertical and Horizontal environments, the methodology applied by each environment given the need to change the amount of resources on-the-fly to offset the security overhead and ensure the SLA, impacted the final average costs. While the horizontal algorithm applies the change in the number of instances, the vertical deals with the change in the number of vCPUs. Thus, it is possible to establish a relationship between the amount of used resources, the requests execution times and the cost paid for the service, considering a single VM and the environment as a whole (i.e., all instances available in the environment). In Table 6, the analysis of the percentages considers the changes made by the Vertical and Horizontal environments in relation to the Common environment. These values can be used to define the best approach for the analysed scenario. Table 6. Percentage of increase (+) and decrease (−) exercised by ReMM on response variables as an attempt to counter the security overhead and ensure the SLAs. Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  View Large Table 6. Percentage of increase (+) and decrease (−) exercised by ReMM on response variables as an attempt to counter the security overhead and ensure the SLAs. Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  View Large In the results is possible to verify that only in the experiments with m3.xlarge instances in a Common environment the SLAs have been met. This happened because the quantity of resources available in this type of instance was considered enough to attend the services demand respecting the defined SLA. Therefore, there is no statistical difference between the results with this instance in the Common environment and the results in the Vertical and Horizontal environments. In the Vertical environment, the requests execution mean times were reduced, in comparison with the Common environment, with the changes in the number of vCPUs in the m3.medium and m3.large instances. On the other hand, there was an increase in the EMT with m3.xlarge instances, generating proportional increases in the final average costs. This occurred because the ReMM reduced the number of vCPUs in this type of instance, i.e. the initially number of allocated vCPUs (8 per m3.2xlarge instance) was considered excessive for the execution of the service demand. Finally, for running safely the requests in m3.xlarge instances, there were no changes in the number of resources, and, consequently, the final average costs remain unchanged. Therefore, the used instance was considered ideal for the execution of this type of service request. In the Horizontal environment, the percentage of increases and reductions in the EMTs was similar to that obtained in a Vertical environment, since there is no statistical difference between the values. However, the impact on the final average costs was massive, especially in experiments with m3.medium and m3.large instances, in which there were increases of 300% and 100% in the final average costs of the environment, respectively. Next section shows an analysis of the influence of each factor on the response variables EMT, FACVM and FACE. 7. FACTORS INFLUENCE This section discusses about the percentage of influence of the factors Environment and Instance. We considered combinations comparing the environments with changes made by the ReMM (Vertical and Horizontal environments) with the environment in which no change in the resources was performed (Common environment). Furthermore, owing to the factor Instance has four levels, the levels m3.medium and m3.large were considered, in which, although they have lower computational differences in relation to other possible combinations of instances, they are enough to scale out the impact on the response variables. Table 7 shows the percentage of influence of the mentioned factors on the response variables, considering the Common and Vertical environments. Owing to the changes made by the vertical algorithm, necessary for compliance with SLAs, the factor with the greatest impact on the execution mean times was the Environment with 75.74% of influence. The second one was the Instance factor with 12.29% and, in third, the combination of both factors with 11.97%. Table 7. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  View Large Table 7. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  View Large Furthermore, considering the computational differences in the types of analysed instances, in which m3.medium has one vCPU and m3.large has two vCPUs, the factor Instance was the most impactful on the final average costs, 82.55%, followed by the factor Environment, 17.34% of influence. Regarding to the Common and Horizontal environments, the percentage of influence of factors on the EMT is similar to that discussed in the previous combination. The order of influence remained the same with the factor Environment in first with 75.81%, followed by the factor Instance with 12.15%. The combination of both factors resulted in 12.04% of influence. Table 8 shows these values. Table 8. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  View Large Table 8. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  View Large In the final average costs, the factor Instance generated an impact of 100% on the FACVM, since there are no changes in the resources that compose a virtual machine in both Common and Horizontal environments. On the other hand, considering the small difference of computational resources between the types of the analysed instances, the horizontal algorithm changed the number of instances and, hence, had the greatest influence on the FACE, with 98%. 8. CONCLUSION In cloud computing, the infrastructure is the backbone of the pricing and the quality of the services that will be provided. In this way, the resources management becomes increasingly important. The user has the vision of a single resource and exclusive use, and therefore, is expected the best performance of the selected attributes to execute the service. In contrast, the provider has multiple physical machines, which need to host the client’s virtual machines in order to maximize profit and save resources, especially energy. These considerations influence the quality of service, and consequently, the SLA defined and the price charged to the customer. Considering the results in both the Vertical and Horizontal environments, the ReMM offset the overhead imposed on the system by the security mechanisms with changes in resources, ensuring the SLAs, and consequently, impacting the costs and the average amounts of answered requests. Therefore, based on the results, the methodology applied by a Common environment was not effective considering the requirements related to the execution time and the use of security mechanisms defined in the SLA. Although the final costs remained unchanged, since there is no change in a number of resources in this environment, most of the SLAs were not ensured. Thus, the approach used in this environment is not recommended for a cloud in which the services demand is constantly changing. In the methodology adopted in the Horizontal environment, the contracts were fulfilled as a result of the changes in the amount of resources applied by the horizontal algorithm. However, these changes consist of adding or removing instances and, hence, all the resources that compose a VM (such as vCPU, memory and disk). Thus, the final costs were more expressive. Many providers offer the resources scalability option, which is applied horizontally, in which the number of instances is changed respecting the terms defined in the SLA. However, the performance improvement of a service is not directly related to the increase of all the resources that compose a VM. Perhaps only the increase in the number of vCPUs is the most appropriate procedure, saving costs and using resources more efficiently. This approach is adopted by the vertical algorithm. The methodology applied by the Vertical environment provided compliance with the requirements defined in the SLAs with small changes in the service costs. For this reason, this model proved to be the best option for cloud environments that consider the relationship between the security overhead, system performance and cost of service. Further studies should be conducted including the development of a prototype using real machines, which will allow a comparison to be made of statistical data from simulated and prototyped environments and an analysis of different network topologies. Furthermore, the hardware heterogeneity and the multi-tenancy interference in the system performance will be considered. Others resource provisioning algorithms should be developed, including the use of optimization techniques, as well as new security policies will be applied. Funding The authors would like to acknowledge the financial support provided by FAPESP (process number 2011/17201-3), CNPq, CAPES and FAPEMIG. Acknowledgements Furthermore, they would like to acknowledge the infrastructure provided by UNIFEI, UFMS, UFBA, and especially the USP and the LASDPC group, where this study was performed for the most part. Footnotes 1 https://gigaom.com/2008/02/15/amazon-s3-service-goes-down/ 2 http://www.itnews.com.au/news/dropbox-update-nullifies-passwords-261240 3 http://www.wired.com/2014/04/nsa-heartbleed/ 4 https://aws.amazon.com/autoscaling/ 5 https://openbenchmarking.org/test/pts/smallpt 6 https://aws.amazon.com/ec2/instance-types/ References 1 Prnjat, O., Rodriguez Pascual, M., Becker, B. and Barbera, R. ( 2015) Surveying clouds in a global environment. IST-Africa Conf., 2015, Lilongwe, Malawi, 6–8 May, pp. 1–11. IEEE. 2 Rimal, B.P., Choi, E. and Lumb, I. ( 2009) A taxonomy and survey of cloud computing systems. NCM ‘09: Proc. 2009 Fifth Int. Joint Conf. INC, IMS and IDC, Seoul, South Korea, 25–27 Aug, pp. 44–51. IEEE Computer Society. 3 Shekanayaki, K., Chakure, A. and Jain, A. ( 2015) A survey of journey of cloud and its future. Int. Conf. Computing Communication Control and Automation (ICCUBEA), Pune, India, 26–27 Feb, pp. 60–64. IEEE. 4 Zhan, Z.-H., Liu, X.-F., Gong, Y.-J., Zhang, J., Chung, H.S.-H. and Li, Y. ( 2015) Cloud computing resource scheduling and a survey of its evolutionary approaches. ACM Comput. Surv. (CSUR) , 47, 63:1– 63:33. Google Scholar CrossRef Search ADS   5 Luo, M., Zhang, L.-J. and Lei, F. ( 2010) An insuanrance model for guranteeing service assurance, integrity and qos in cloud computing. Proc. 2010 IEEE Int. Conf. Web Services, Miami, FL, USA, 5–10 July ICWS ‘10, pp. 584–591. IEEE Computer Society. 6 Gui, Z., Yang, C., Xia, J., Huang, Q., Liu, K., Li, Z., Yu, M., Sun, M., Zhou, N. and Jin, B. ( 2014) A service brokering and recommendation mechanism for better selecting cloud services. PLoS One , 9, e105297. Google Scholar CrossRef Search ADS PubMed  7 Batista, B.G., Estrella, J.C., Ferreira, C.H.G., Leite Filho, D.M., Nakamura, L.H.V., Reiff-Marganiec, S., Santana, M.J. and Santana, R.H.C. ( 2015) Performance evaluation of resource management in cloud computing environments. PLoS One , 10, 1– 21. 8 Yan, L., Rong, C. and Zhao, G. ( 2009) Strengthen cloud computing security with federal identity management using hierarchical identity-based cryptography. CloudCom: IEEE Int. Conf. Cloud Computing, Beijing, China, 1–4 December, pp. 167–177. Springer. 9 Marty, R. ( 2011) Cloud application logging for forensics. Proc. 2011 ACM Symposium on Applied Computing, TaiChung, Taiwan, 21–24 March, pp. 178–184. ACM. 10 Lombardi, F. and Di Pietro, R. ( 2011) Secure virtualization for cloud computing. J. Netw. Comput. Appl. , 34, 1113– 1122. Google Scholar CrossRef Search ADS   11 Subashini, S. and Kavitha, V. ( 2011) A survey on security issues in service delivery models of cloud computing. J. Netw. Comput. Appl. , 34, 1– 11. Google Scholar CrossRef Search ADS   12 Vaquero, L., Rodero-Merino, L. and Morán, D. ( 2011) Locking the sky: a survey on iaas cloud security. Computing , 91, 93– 118. Google Scholar CrossRef Search ADS   13 Velev, D. and Zlateva, P. ( 2010) Cloud infrastructure security. Open Research Problems in Network Security: IFIP WG 11.4 International Workshop, iNetSec, Sofia, Bulgaria, 5–6 March, pp. 140–148. Springer. 14 Yang, X., Nasser, B., Surridge, M. and Middleton, S. ( 2012) A business-oriented cloud federation model for real-time applications. Future Gener. Comput. Syst. , 28, 1158– 1167. Google Scholar CrossRef Search ADS   15 Khorshed, M.T., Ali, A.S. and Wasimi, S.A. ( 2012) A survey on gaps, threat remediation challenges and some thoughts for proactive attack detection in cloud computing. Future Gener. Comput. Syst. , 28, 833– 851. Google Scholar CrossRef Search ADS   16 Zissis, D. and Lekkas, D. ( 2012) Addressing cloud computing security issues. Future Gener. Comput. Syst. , 28, 583– 592. Google Scholar CrossRef Search ADS   17 Modi, C., Patel, D., Borisaniya, B., Patel, H., Patel, A. and Rajarajan, M. ( 2013) A survey of intrusion detection techniques in cloud. J. Netw. Comput. Appl. , 36, 42– 57. Google Scholar CrossRef Search ADS   18 Wei, L., Zhu, H., Cao, Z., Dong, X., Jia, W., Chen, Y. and Vasilakos, A.V. ( 2014) Security and privacy for storage and computation in cloud computing. Inf. Sci. , 258, 371– 386. Google Scholar CrossRef Search ADS   19 Ardagna, C.A., Asal, R., Damiani, E. and Vu, Q.H. ( 2015) From security to assurance in the cloud: a survey. ACM Comput. Surv. (CSUR) , 48, 2:1– 2:50. Google Scholar CrossRef Search ADS   20 Shamsolmoali, P. and Alam, A. ( 2015) Ensuring data security and performance evaluation in cloud computing. Intelligent Computing, Communication and Devices. Advances in Intelligent Systems and Computing. Springer, 308, 415–423. 21 Yang, K., Liu, Z., Jia, X. and Shen, X.S. ( 2016) Time-domain attribute-based access control for cloud-based video content sharing: a cryptographic approach. IEEE Trans. Multimed. , 18, 940– 950. Google Scholar CrossRef Search ADS   22 Huang, T., Zhu, Y., Wu, Y., Bressan, S. and Dobbie, G. ( 2016) Anomaly detection and identification scheme for vm live migration in cloud infrastructure. Future Gener. Comput. Syst. , 56, 736– 745. Google Scholar CrossRef Search ADS   23 Amoud, M. and Roudiès, O. ( 2016) A systematic review of security in cloud computing. Proc. Second Int. Afro-European Conf. Industrial Advancement AECIA 2015, Villejuif, France, 9–11 September, pp. 69–81. Springer. 24 Sanka, S., Hota, C. and Rajarajan, M. ( 2010) Secure data access in cloud computing. 4th Int. Conf. Internet Multimedia Services Architecture and Application (IMSAA), Bangalore, India, 15–17 Dec, pp. 1–6. IEEE. 25 Casola, V., Cuomo, A., Rak, M. and Villano, U. ( 2013) The cloudgrid approach: Security analysis and performance evaluation. . Future Gener. Comput. Syst. , 29, 387– 401. Google Scholar CrossRef Search ADS   26 Chhabra, S., Rogers, B., Solihin, Y. and Prvulovic, M. ( 2011) Secureme: a hardware-software approach to full system security. Proc. Int. Conf. Supercomputing, Tucson, Arizona, USA, May 31–June 04, pp. 108–119. ACM. 27 Popa, R.A., Lorch, J.R., Molnar, D., Wang, H.J. and Zhuang, L. ( 2011) Enabling security in cloud storage slas with cloudproof. USENIX Annual Technical Conf., Portland, OR, USA, 15–17 June 14. USENIX Association. 28 Zhang, F., Chen, J., Chen, H. and Zang, B. ( 2011) Cloudvisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization. Proc. Twenty-Third ACM Symposium on Operating Systems Principles, Cascais, Portugal, 23–26 October, pp. 203–216. ACM. 29 Bates, A., Mood, B., Valafar, M. and Butler, K. ( 2013) Towards secure provenance-based access control in cloud environments. Proc. 3rd ACM Conf. Data and application security and privacy, San Antonio, Texas, USA, 18–20 February, pp. 277–284. ACM. 30 He, H., Li, R., Dong, X. and Zhang, Z. ( 2014) Secure, efficient and fine-grained data access control mechanism for p2p storage cloud. IEEE Trans. Cloud Comput. , 2, 471– 484. Google Scholar CrossRef Search ADS   31 Varadharajan, V. and Tupakula, U. ( 2014) Security as a service model for cloud environment. IEEE Trans. Netw. Serv. Manage. , 11, 60– 75. Google Scholar CrossRef Search ADS   32 He, J., Dong, M., Ota, K., Fan, M. and Wang, G. ( 2014) Nscc: Self-service network security architecture for cloud computing. Computational Science and Engineering (CSE), 2014 IEEE 17th Int. Conf., Chengdu, China, December 19–21, pp. 444–449. IEEE. 33 Kurose, J.F. and Ross, K.W. ( 2012) Computer Networking: A Top-Down Approach  ( 6th edn). Pearson, New Jersey, USA. 34 Tanenbaum, A.S. and Wetherall, D.J. ( 2010) Computer Networks  ( 5th edn). Prentice Hall Press, Upper Saddle River, NJ, USA. 35 Hemanth Chakravarthy, M. and Kannan, E. ( 2014) A review on secured cloud computing environment. Am. J. Appl. Sci. , 11, 1224– 1228. Google Scholar CrossRef Search ADS   36 Orehovački, T., Babić, S. and Etinger, D. ( 2018) Identifying relevance of security, privacy, trust, and adoption dimensions concerning cloud computing applications employed in educational settings. Proc. AHFE 2017 Int. Conf. Human Factors in Cybersecurity, Los Angeles, California, USA, July 17–21, pp. 308–320. Springer. 37 Rojas, M.A.T., Redígolo, F.F., Gonzalez, N.M., Sbampato, F.V., de Brito Carvalho, T.C.M., Ullah, K.W., Näslund, M. and Ahmed, A.S. ( 2018) Developments and Advances in Intelligent Systems and Applications: Managing the Lifecycle of Security SLA Requirements in Cloud Computing . Springer, Cham, Switzerland. 38 Yadav, R., Kilaru, A. and Kumari, S. ( 2018) The recent trends, techniques and methods of cloud security. Int. Conf. Information and Communication Technology for Intelligent Systems, Ahmedabad, India, March 25–26, pp. 594–601. Springer. 39 Hu, H., Ahn, G. and Kulkarni, K. ( 2011) Anomaly discovery and resolution in web access control policies. Proc. 16th ACM Symp. on Access Control Models and Technologies, Innsbruck, Austria, June 15–17, pp. 165–174. ACM. 40 Landwehr, C.E. ( 2001) Computer security. Int. J. Inf. Secur. , 1, 3– 13. Google Scholar CrossRef Search ADS   41 Ristenpart, T., Tromer, E., Shacham, H. and Savage, S. ( 2009) Hey, you, get off of my cloud: Exploring information leakage in third-party compute clouds. Proc. 16th ACM Conf. Computer and Communications Security, Chicago, Illinois, USA, November 09–13, pp. 199–212. ACM. 42 Steiner, M., Tsudik, G. and Waidner, M. ( 1996) Diffie-hellman key distribution extended to group communication. Proc. 3rd ACM Conf. Computer and Communications Security, New Delhi, India, March 14–15, pp. 31–37. ACM. 43 Magnusson, P.S., Christensson, M., Eskilson, J., Forsgren, D., Hallberg, G., Hogberg, J., Larsson, F., Moestedt, A. and Werner, B. ( 2002) Simics: a full system simulation platform. Computer , 35, 50– 58. Google Scholar CrossRef Search ADS   44 Bethencourt, J., Sahai, A. and Waters, B. ( 2007) Ciphertext-policy attribute-based encryption. IEEE Symp. Security and Privacy, Berkeley, CA, USA, May 20–23, pp. 321–334. IEEE. 45 Blaze, M., Bleumer, G. and Strauss, M. ( 1998) Divertible protocols and atomic proxy cryptography. EUROCRYPT: Inter. Conf. Theory and Applications of Cryptographic Techniques, Espoo, Finland, May 31–June 4, pp. 127–144. Springer. 46 Waters, B. ( 2011) Ciphertext-policy attribute-based encryption: an expressive, efficient, and provably secure realization. 14th Int. Conf. Practice and Theory in Public Key Cryptography, Taormina, Italy, March 6–9, pp. 53–70. Springer. 47 Hur, J. and Noh, D.K. ( 2011) Attribute-based access control with efficient revocation in data outsourcing systems. IEEE Trans. Parallel Distrib. Syst. , 22, 1214– 1221. Google Scholar CrossRef Search ADS   48 Caron, E., Rodero-Merino, L., Desprez, F. and Muresan, A. ( 2012) Auto-Scaling, Load Balancing and Monitoring in Commercial and Open-Source Clouds. Technical Research Report RR-7857. INRIA, France. 49 Batista, B.G., Estrella, J.C., Santana, M.J., Santana, R.H. and Reiff-Marganiec, S. ( 2014) Performance evaluation in a cloud with the provisioning of different resources configurations. IEEE World Congress on Services (SERVICES), Anchorage, AK, USA, 27 June–2 July, pp. 309–316. IEEE. 50 Jain, R. ( 1991) The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling . Wiley Computer Publishing, John Wiley & Sons, Inc, San Francisco, CA, USA. Author notes Handling editor: Gerard Parr © The British Computer Society 2018. All rights reserved. For permissions, please e-mail: journals.permissions@oup.com This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/about_us/legal/notices) http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png The Computer Journal Oxford University Press

Security Overhead on a Service with Automatic Resource Management: A Performance Analysis

Loading next page...
 
/lp/ou_press/security-overhead-on-a-service-with-automatic-resource-management-a-03aQaBtJdc
Publisher
Oxford University Press
Copyright
© The British Computer Society 2018. All rights reserved. For permissions, please e-mail: journals.permissions@oup.com
ISSN
0010-4620
eISSN
1460-2067
D.O.I.
10.1093/comjnl/bxy033
Publisher site
See Article on Publisher Site

Abstract

Abstract As information about clients and businesses is migrating to the cloud, there are growing concerns about how safe this environment is. Furthermore, it is known that as more stringent levels of security are required, the countermeasures, necessary to maintain the security of the system, are subjected to increasing interference on the performance. In the case of cloud computing, it is possible to compensate the overhead generated by the security mechanisms by changing the number of available resources on-the-fly. The aim of this paper is to perform a performance evaluation of a service involving the application of security mechanisms. We considered the change of computing resources during the execution time by means of a dynamic and self-managed module, which was responsible for load balancing, efficient utilization of resources and Quality of Service level assurance. According to the results of the experiments, we verified that the approach in the Vertical environment provided the fulfilment of the requirements defined in the Service Level Agreement, even with security overhead, with slight changes in the service costs. 1. INTRODUCTION The concept of Cloud Computing is currently the norm among many Information Technology (IT) companies [1]; indeed it is based on many years of research in several areas of computing, such as: distributed systems, virtualization, fault tolerance, load balancing, interoperability, Web 2.0 applications, utility computing and autonomic computing [2–4]. In this context, cloud providers must offer a suitable level of quality of service (QoS) to all users. Owing to the different kinds of consumers, each with specific needs and the unpredictable nature of the Web, and the wide influence of content management on the overall behaviour of the application, the Cloud must be continuously monitored, evaluated and adapted to ensure it achieves the appropriate level of QoS [5, 6]. As well as all these challenges, there are requirements with regard to security issues in all fields of data processing, data storage and network communication, which are also important. As a result, the process of managing resources efficiently to ensure data security without losing performance on QoS is not a trivial task in Cloud environment [6, 7]. There are a lot of studies that address the problem of how to deal with various security issues on cloud computing environment [8–23]. Defining how security should be applied in service layers of a cloud computing environment and the extent to which it interferes with both the quality and cost of the service offered, is a task that calls for further studies. The main providers available in the market do not show data regarding this interference. On the other hand, there are some studies that discuss the security overhead on the system performance [24–26, 10, 27–32]. However, they do not discuss a way to offset this overhead. Therefore, there is a need for security mechanisms together with the quality of service attributes related to performance, so that a link can be established between the provision of security, a guarantee of performance, and the cost of the service. In this paper, we present a solution to offset the overhead imposed by the security mechanisms on the service performance. Our approach, called Resource Management Module (ReMM), deals with resource provisioning mechanisms and renegotiating costs concomitantly. In view of this, the ReMM is capable of changing the number of virtual resources on-the-fly, which has an impact on costs, in an attempt to meet the clients requirements such as deadline and security level, as specified in the service level agreements (SLAs), and ensure an efficient use of the available resources. In this way, the main purpose of this paper is to perform evaluations that take account of the overhead imposed by the security mechanisms on the service performance, and analyse how to offset it. That is, the focus is not on setting out new security policies for cloud and helping to improve some aspects of the systems security, but rather on establishing a relationship between the ways security and a suitable performance can be achieved and investigate how this relationship affects the system response variables. For this, the follow steps were carried out: Study of the overhead imposed by security mechanisms on the performance of different systems. Several papers available in the literature were analysed, which carry out a performance evaluation considering the use of security countermeasures. The study carried out by Sanka et al. [24] was used in the composition of the analysed scenario, which implies an overhead of 28% on the environment performance. Performance evaluation, which through the design of experiments, allowed to evaluate the behaviour of the response variables, confronting the overhead imposed by the security mechanisms with the changes on-the-fly in the amount of resources carried out by the ReMM. This paper is structured as follows: Section 2 lists briefly the main security issues in cloud computing; Section 3 sets out the related work; Section 4 presents the ReMM, used to offset the security overhead; the methodology employed in conducting the experiments is presented in Section 5; the results are examined in Sections 6 and 7 ; finally in Section 8, the conclusions and findings of this paper are discussed, as well as some suggestions for future work. 2. CLOUD SECURITY Millions of users have been using networks for banking transactions, purchases, tax returns and other features, making network security one of the most important topics discussed in academic and industrial areas, and an essential issue in distributed systems [33]. Security issues are intentionally caused by malicious agents trying to gain some benefit from a system and/or harming someone. According to Tanenbaum and Wetherall [34], problems can be divided into the following interrelated areas: confidentiality, authentication, non-repudiation and integrity control, and can be avoided through the application of security services. In cloud computing, when a particular company migrates its entire logical infrastructure to a service provider, it does not worry about costly issues such as physical and logical infrastructure, purchase of hardware and software, refrigeration, physical space, training of professionals and idleness of resources. Its main concerns are related to the security of its data and operations, the time spent in the execution of the operations and the amount charged by the provider in the provision of a service, i.e. the quality of the service [35]. In addition, users must be able to trust cloud systems and their providers and be willing to submit to some level of control. This trust relationship is gained by controlling access to resources, securing data, meeting deadlines and managing events/operations [36]. An important factor that should be considered by both clients and providers is the trust of both parties. In a cloud, the trust can be defined as the certainty of the customer that the provider is able to provide the required services accurately and without failures. In this way, trust can be expressed as the client’s belief in the integrity, operation, experience and compliance with all regulations and laws by a service provider [37]. Outsourced or external environments such as those present in cloud computing require rigorous security practices and mechanisms to ensure data security in transit, data protection used in processes, key life cycle management, establishment of contractual rules with providers (requiring the correct destruction of data that is stored on media before it is released for use) and strategies for backing up [38]. In recent years, some troubling incidents have given rise to concerns about the secure handling of access, storage and data in cloud computing. For example, in 2008 a bug in the data centres of Amazon S3 resulted in many data users experiencing corruption, which culminated in failures in the file integrity verification.1 Another problem was noticed in June 2011, when a Dropbox update affected the authentication mechanism, resulting in inappropriate access being granted to user files with incorrect passwords.2 In 2014, a security break in the OpenSSL library allowed the exposure of encrypted connections. This setback affected most of the Linux and BSD operational systems and, hence, services such as Facebook, Twitter, Amazon, Oracle applications, IBM, VMware, and others. It is suspected that the National Security Agency (NSA) already knew about this vulnerability and exploited it to spy on encrypted connections, previously regarded as secure.3 Starting from around 2012, the use of ransomware scams has grown internationally. In 2017, a lot of companies, airports, hospitals, government agencies, in more than 150 countries, were impaired since this type of malicious software threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid, usually in bitcoin. Trying to face the threats, several studies that aim to address some of the security problems in cloud computing are available in the literature, as shown in [9] for control logs; [10] that uses the virtualization to increase cloud security by protecting the integrity of virtual machines and resources of the infrastructure; [22] that uses a scheme to detect anomalies; [8] for identity management; and [39, 21] for access control. A study on security in different service models is presented by Subashini and Kavitha [11]. Vaquero et al. [12] provide a comprehensive view of security in IaaS. Khorshed et al. [15] and Ardagna et al. [19] conducted a research into the threats and existing countermeasures to the cloud environment, as well as the challenges for the implementation of these countermeasures. Yang et al. [14] address the audit problem in data storage in a cloud presenting and analysing the possible solutions available in the literature. Zissis and Lekkas [16] present some threats and countermeasures available to a cloud environment. In the work presented by Modi et al. [17], the authors discuss various types of intrusions that may threaten the integrity, confidentiality and availability of cloud services. Amoud and Roudiès [23] present a literature review of privacy and security approaches for cloud computing. Therefore, there are a lot of studies in the literature showing that security in cloud environments is an important and essential topic both in academic and industry world. Every computational system needs to be protected against a wide range of threats so that it can guarantee confidentiality and integrity, as well as the availability of data and resources. However, a number of factors need to be addressed, such as the sensitivity of the data and the resources that an application will handle, to assure the correct scaling of the security mechanism without compromising the entire environment. In addition, when analysing performance and security, the effects produced by different security mechanisms should be evaluated by different QoS metrics [40]. As the Internet is the basic technology of cloud computing, all the concerns it raises are inherited. The cloud infrastructure is about more than the hardware, where the data are processed and stored, and includes the way that the data are transmitted and accessed. In a cloud, the data are transmitted from the source to the destination, by means of several devices and forms of infrastructure owned by third-party organizations, which allow the data to be intercepted and modified [41]. Thus, even if a number of security mechanisms are implemented by the client and provider, the data still remain vulnerable. Service providers offer computational resources to the clients, and allow them to host their data or execute some application. Their clients can also use the hired infrastructure to offer services to other clients, this second class of clients is called users. This means that the providers have to provide security mechanisms to ensure that no virtual machine will interfere in the others VMs of the different clients, ensuring the isolation among them. Moreover, when a client hires an IaaS service, for example, and provides services to other users, the IaaS provider is unconcerned about the nature of the operations or the management of the requests by the companies who hire its services. Currently, none of the most popular service providers, such as Amazon S3, Google Drive and Microsoft Azure, provide security guarantees in their SLAs. Amazon S3 and Microsoft Azure, for example, only guarantee the availability of the service in their SLAs. If the service metric of availability falls below 99.9%, the clients should be compensated in accordance with clauses in their contracts. Amazon states that the security virtual machine is the clients’ responsibility, since they are free to run any kind of operating system or even application. Thus, clients are responsible for ensuring the security of virtual machines hosted on cloud providers. In view of this, given the importance of the facts outlined above, the next section shows a review of mechanisms available in the literature that aim guaranteeing security in a cloud environment. Security mechanisms are very important to ensure the integrity, availability and confidentiality of the data and resources. However, their overhead on the system performance must be considered. 3. RELATED WORK There are several studies in the literature addressing cloud computing security issues related to access, storage and handling of data and resources in the provision of a service by VMs. This section presents an analysis of some papers considering the overhead imposed by security mechanisms on environmental performance. Sanka et al. [24] discuss the challenges related to secure access to data in cloud computing. The authors proposed a security approach in which access and encryption control mechanisms were used for data protection. They modified the Diffie–Hellman key exchange mechanism [42] so that it can be used by both the service provider and the client for the symmetric key sharing and manipulation of data. In addition, the authors proposed an access control based on capability, with cryptographic techniques for a cloud platform, and a list of capacity that is used to specify the access rights of users. A simulated environment was used for the implementation and analysis of experiments, in which the proposed solution generated an overhead of ~28% in the system. In the study presented in [25], the authors proposed a solution based on fine-grained access control mechanisms, through authorization and authentication mechanisms and federated identity. The overhead introduced by multitier architecture and the security mechanisms are measured through experiments on a prototype called PerfCloud, allowing comparative analysis between security and performance. According to the results, the use of authorization mechanisms such as XACML hardly generated overhead on the system, <0.01%. Regarding the transport channel and the authentication mechanism, both influenced the performance of virtual and physical resources. According to the authors, both factors had a big impact on response time, 30%, and 60%, respectively. Finally, the use of a trusted third party (TTP) as a second option to make the authentication process had a major impact on the performance of the environment, because of the used mechanisms: authentication protocol (Secure Message), the transport channel (HTTP) and authorization mechanisms (MapFile and XACML). The overhead generated was ~184% on the response times. The aim of the study presented by [26] was to investigate how to provide privacy and integrity for applications that run on untrusted nodes, in which the hardware and the operating system are vulnerable to attacks. For this, the authors proposed the SecureMe, a mechanism for hardware and software that provides a safe computing environment. The SecureMe aims to protect an application from hardware attacks, using a secure processor, and also against operating system attacks, through memory camouflage, paging permission and protection of system calls. Experiments were carried out in a simulated environment using Simics simulator [43], which allowed a performance evaluation using micro benchmarks and different loads. The authors found that the SecureMe adds an overhead on the execution time of ~13.5% compared to a completely unprotected system. Lombardi and Di Pietro [10] discuss how virtualization can increase the security of cloud computing, protecting both the integrity of virtual machines and the cloud infrastructure components. They proposed an architecture called Advanced Cloud Protection System (ACPS), which aims to ensure the security of resources. The ACPS can be implemented in various cloud solutions and can effectively monitor the integrity of the VMs and the components of the infrastructure in a transparent way. For this, regular checks of checksum files and libraries are made and, according to the results, the ACPS can react locally to security breaches, and notify the environmental manager. A prototype was implemented using Eucalyptus and OpenECP. The prototype was tested against attacks and an analysis of the proposed architecture was performed with different types of load. The results show that ACPS is resilient against attacks and that the overhead introduced was ~6%. Popa et al. [27] conducted a performance evaluation of the security mechanisms available in CloudProof. CloudProof was designed to ensure the confidentiality and integrity of data, write-serializability among multiple users and freshness version of the file. In addition, the CloudProof guarantees access control and is able to detect breaches in data integrity, compensating the client in case of a mishap. According to the authors, the use of CloudProof introduced an overhead of ~17% compared with experiments in which this mechanism was not used. There was also a reduction of ~10% in the throughput for data storage in the cloud. The used cryptographic algorithms were: SHA-1 for hashing, AES for symmetric encryption and RSA signature with a key of 1024 bits. Zhang et al. [28] proposed a transparent approach that protects the privacy and integrity of virtual machines in virtualized infrastructures. According to the authors, a prototype called CloudVisor was designed, which is able to provide privacy and ensure the integrity even if the hypervisor and the virtual machines manager are under the attacker’s control. Some experiments were carried out for a performance evaluation with different numbers of clients, numbers of virtual cores in a VM and numbers of VMs. I/O operations correspond to the neck of CloudVisor, because of cryptographic operations with the AES algorithm and hash operations. In the results, the overhead generated by the use of CloudVisor and I/O applications ranges between 4.5% and 54.5%, compared with experiments in which Xen hypervisor was used. This variation is related to the number of clients. Bates et al. [29] proposed an access control model for data storage in the cloud. The authors considered the management and validation of metadata from a reliable source system and introduced protocols that allow the secure transfer of metadata between end-hosts and cloud entities. Using these protocols, they have developed a prototype for provenance-based access control in cloud storage, called Cumulus, able to process thousands of read and write operations per second. Through replicated components, the system generated an overhead of ~14%, which according to the authors, showed that the provenance-based access control is a practical and scalable solution for the cloud. In the study carried out in [30], the authors proposed a fine-grained access control mechanism for a peer to peer (P2P) storage cloud, called Access Control mechanism for P2P storage Cloud (ACPC). Through this mechanism, it is possible to exploit the storage space in a cloud of participants using a P2P system. However, since the providers and users are in different domains, often unreliable, some challenges arise related to data security and access control. To resolve these problems, the authors developed encryption techniques such as Ciphertext-Policy Attribute-Based Encryption (CP-ABE) [44] and Proxy Re-Encryption (PRE) [45]. Thus, according to the authors, the ACPC can resist collision attacks and protect users’ information effectively. A performance analysis is presented, in which the ACPC was compared with other state-of-the-art revocable ABE schemes such as BSW [44], W [46] and HN [47]. In the results, the operations performed by the ACPC showed the less harmful overhead on the system, ~13.2%. In the study highlighted in [31], the authors presented an architecture in which the provider can offer security as a service to its clients. The proposed security model offers both basic security for the provider to protect its infrastructure, and a flexible security that provides additional security mechanisms. For basic security, the authors proposed a component called service provider attack detection (SPAD). For flexible security, the authors proposed a component called tenant specific attack detection (TSAD). In addition, they provided mechanisms against attacks on the hypervisor. For this, they used the Security Gateway that specifies policies and mechanisms to detect attacks on the hypervisor. A performance analysis of the proposed architecture is presented. In the results, the operations performed by SPAD and TSAD introduced an overhead of ~6% with different types of attacks. He et al. [32] proposed a security architecture called network security for cloud computing (NSCC), which aims to solve the security issue on the network in a cloud. According to the authors, NSCC deals with issues related to scalability, fault tolerance and use of resources in a safe way, preventing the system against internal and external attacks. In NSCC, the security management domains (SMD), the security meta group (SMG) and the virtual switch (vSwitch) work together to ensure the security of the cloud. The SMD defines the routing rules of vSwitch, and this in turn, forwards the internal and external traffic through the SMG. Finally, the SMG performs the inspection and filtering of incoming and outgoing traffic of the cloud service users. Some experiments were performed on a prototype. In the experiments, the overhead was measured by comparing an environment with NSCC and an unsafe environment. According to the results, the NSCC imposed an overhead of ~9.3% on the throughput and network latency. In this section, some papers were analysed, which aim to set out specific security mechanisms as countermeasures against certain threats. As a result of this, the main objective of this analysis is not to compare them, insofar as each has its own modelling features and view of the security problem, experimental planning and the execution environment. The aim of this analysis is rather to survey the available works in the literature which examine the critical security factors discussed in this paper. It also investigates the best way to carry out an evaluation of the overhead generated by security mechanisms and how this affects performance in a cloud environment. Furthermore, although all the analysed papers present an impact assessment of the security mechanisms on the system performance, they did not aim to handle this overhead. The study presented in this paper explores the hypothesis that it is possible to face the overload generated by the security mechanisms through an alteration of computational resources in the environment carried out by the ReMM. 4. RESOURCE MANAGEMENT MODULE The ReMM concerns the way the available resources are handled during the execution time with regard to the QoS metrics defined in the SLA. We outline a resource management module for cloud applications in which both horizontal and vertical scalability can be applied dynamically, thus leading to a change in price. The most common type of scaling is horizontal scaling which involves the allocation and release of virtual machines. The other type is vertical scaling which either increases or reduces the computing resources (vCPU, memory, disk, etc.) of one or more instances [48]. In this way, the ReMM aims to satisfy both the clients (thus ensuring the SLA at a fair price) and provider by using the resources available in the system efficiently. A client’s request will be answered by a provider, which uses three layers and can provide different services: application layer (Software as a Service—SaaS), platform layer (Platform as a Service—PaaS) and infrastructure layer (Infrastructure as a Service—IaaS). The application layer handles all the application services that are offered to the clients. The platform layer includes mapping and scheduling policies which are designed to translate the clients’ QoS requirements to infrastructure level parameters and allocating virtual machines to meet their requests. The infrastructure layer carries out the initiation and removal of VMs with specific resource configurations for the client in a transparent way. Figure 1 shows the proposed module. Figure 1. View largeDownload slide ReMM operation. Figure 1. View largeDownload slide ReMM operation. First of all, the client and provider must negotiate a SLA, by defining the QoS metrics and the contract details (1). After this procedure, different clients request different types of services from a provider. The Admission Control is responsible for analysing the request and decides whether or not it can be met (2). During the system overload, for example, the service provider can decide either to reject the new requests or violate the SLA. The SLA violation should result in penalties for the provider. If the request is accepted, it will be stored in the Requests Queue (3), where it will receive a priority that will define the execution sequence (a service differentiation can be applied, for example, with different kinds of clients). The ReMM will provide the virtual resources based on the information defined in the SLA (4), and place them in the physical resources (5). After the resources allocation, the Scheduler forwards the requests (6) so that they can be run on resources using scheduling policies (7.a) (7.b)—initially the Round Robin policy was developed. At intervals of time, the Performance Monitor collects information about the system performance and about the request execution (8) and sends them to ReMM (9.a). This information is compared with the QoS information available in the contract (9.b) and if the results are not in accordance with the SLA, the ReMM dynamically adjusts a number of resources (horizontally or vertically) in an attempt to ensure the SLA (10). Any changes in the system influence the Business Model (11). In view of this, the ReMM is capable of changing the number of virtual resources on-the-fly, which has an impact on costs, in an attempt to meet the clients requirements, as specified in the SLAs, and ensure an efficient use of the available resources. Further information about the experiments and analysis of ReMM can be found in [49, 7]. In the next section, there is an analysis of a cloud service, which makes it possible to confront the overhead generated by the security mechanisms required by the clients with the ReMM and evaluate the impact on the defined response variables. QoS-driven approaches for different environments were defined on the basis of the results and these took account of the overhead imposed by the security mechanisms, the performance, and the service costs. 5. DESIGN OF THE EXPERIMENTS In the analysis, the CloudSim 3.0.3 simulator was used to design the cloud environment with ReMM. A scenario was created consisting of three entities: users, the client, and provider (Fig. 2). The client hires the infrastructure from a provider to allocate a service. This service provides the storage and data sharing (for example, music and movies) for multiple users. Figure 2. View largeDownload slide Relation between providers, clients and users. Figure 2. View largeDownload slide Relation between providers, clients and users. In the proposed analysis, a client can have access to a service with security, which must be run on a particular VM in the provider, in a transparent way and respect the deadline specified in the SLA. However, the use of security mechanisms leads to an overhead on the service, which will be confronted by the ReMM, unlike the other papers presented in Section 3. For this reason, the ReMM must analyse the request execution time and compare it with the deadline defined in the SLA, which in the experiments is 100 seconds with an SLA variation margin of 20%, i.e. the service execution time can range between 80 and 120 seconds [7]. If the result is not in accordance with the contracted performance, the amount of resources allocated must be changed in accordance with the scalability algorithm provided by ReMM, and this has an effect on the response variables. Changes made by the ReMM through its scalability algorithms follow the analysis conducted by [49], in which the Vertical algorithm only changes the number of vCPUs (virtual cores) of the VMs, where the changes have a percentage of 100%. This determines that eight vCPUs is the maximum number allowed per VM and one vCPU is the minimum value. In the Horizontal algorithm, ReMM changes the number of instances, where one instance is the minimum amount allowed. Both algorithms involve changes in the costs which are in proportion to the amount of changed resources. Three types of environments were designed to perform the experiments (Common, Vertical and Horizontal), and they employ different approaches. The Common is a non-scalable environment used by some providers, where the service requests must be executed by the previously allocated VMs, with no changes in the amount of resources during the execution time. In this way, the resource provisioning is static and the costs remain unchanged. The Horizontal environment applies a dynamic approach used by some providers like Amazon (Auto Scaling4). This model allows changes in the amount of resources allocated during the execution time. In this case, the horizontal scalability is applied, and the adjustments to the cost are in proportion to the number of allocated instances. Finally, the Vertical environment employs an approach that takes into account changes in the specific features of a VM, for example, the amount of memory, disk or processor cores (vCPUs). Based on the study carried out by Batista et al. [49], the experiments include changes in the number of vCPUs of a VM, which reduce fluctuations in the costs, since they are proportional to the number of allocated vCPUs. That is, an instance has an initial price, which can change if the number of virtual cores is changed, while the other resources that compose a VM remain unchanged. A client requests an image rendering execution and storage through the Monte Carlo algorithm. This type of service request was modelled on the Smallpt benchmark.5 With regard to the amount of overhead imposed by the security mechanisms, the study presented by Sanka et al. [24] and discussed in Section 3 was used, in which the overhead is 28%. A provider consisting of data centres has been set up to carry out the experiments and hosts the virtual machines that run the service requests. In the experimental environment, the hardware heterogeneity and the performance interference across the same type of cloud VM instances were not considered. The physical resources were regarded as unlimited, and thus, all the requests could be accepted and executed by the available VMs. Furthermore, the users are not differentiated in terms of priorities. The virtual machines used for the execution of the service requests were modelled based on the types of M3 instances of Amazon.6 Table 1 shows the settings of each VM, as well as the initial cost of each instance. It is worth remembering that the final cost may vary according to the environment, since the ReMM can change the settings of a particular VM or the number of instances during the execution time. Table 1. Specification of instances. Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  View Large Table 1. Specification of instances. Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  Instances  Virtual core  Main memory (GB)  Disk SSD  Initial cost/hour ($)  m3.medium  1  3.75  1×4  $ 0.1082  m3.large  2  7.5  1×32  $ 0.2166  m3.xlarge  4  15  2×40  $ 0.4387  m3.2xlarge  8  30  2×80  $ 0.8775  View Large Furthermore, the following response variables were considered and analysed: Execution mean time (EMT): average time spent on the execution of a request. In the experiments, it was decided that each request must be performed at ~100 seconds with a range of up to 20%. Final average cost per VM (FACVM): is the average of the final cost ($/hour) of using a VM, while allowing for possible changes in the allocated resources. The FACVM considers the initial average cost per VM (IACVM). Final average cost of the environment (FACE): is the average cost ($/hour) for the allocation of all the VMs used to meet the demand of requests during the environmental observation time. The FACE considers the initial average cost of the environment (IACE). Number of answered requests (AR): average rate of requests met by a cloud environment during the observation time. Used amount of resources: refers to the average number of vCPUs and instances (VMs) used in each experiment for the execution of a client request. A full factorial experimental planning was used for the experiments. This model is outlined by Jain [50] and is suitable for the analysis of the response variables. In this methodology, the planning and analysis of experiments include both factors and levels, where the factors correspond to environmental characteristics and the levels are the possible environmental variations. In this way, two factors and their levels were included. The factor Environment defines whether the experiments will be performed: in a Common environment (without the ReMM), a Vertical environment (in which ReMM applies the vertical scalability to change the resources) or a Horizontal environment (in which the ReMM applies the horizontal algorithm). Furthermore, the factor Instance corresponds to the type of allocated virtual machine required to execute the requests. Other important factors are the number of clients requesting services and the number of VMs initially available to meet this demand. Fixed values were adopted for these factors, in which 100 clients request services constantly during the experimental observation time. These requests were initially run by 50 VMs with settings that varied in accordance with the experiment planning. Each experiment was run 10 times, with an observation time of ~1.5 hours. Through 10 replications, it was noted that the results for each response variable did not show significant variations. Thus, the average, standard deviation (SD) and the confidence interval (CI) of 95% were calculated for each setting of the experiments [50]. 6. ANALYSIS OF THE RESULTS Figure 3 and Table 2 show the results of experiments in which we considered the use of security mechanisms. As highlighted by Sanka et al. [24] in Section 3, the use of security mechanisms provided an overhead of 28% on the system. Figure 3. View largeDownload slide Requests execution mean times. Figure 3. View largeDownload slide Requests execution mean times. Table 2. Results in environments with security overhead. EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  View Large Table 2. Results in environments with security overhead. EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  EMT (s)  SD  CI  Lower limit  Upper limit  Instances  Common environment  429.98  11.87  7.98  422.00  437.96  m3.medium  215.49  11.22  7.45  208.04  222.94  m3.large  108.85  11.58  7.77  101.08  116.62  m3.xlarge  56.02  11.20  7.38  48.64  63.40  m3.2xlarge  Vertical environment  111.43  14.54  9.94  101.49  121.37  m3.medium  113.41  12.69  9.04  104.37  122.45  m3.large  112.52  11.78  8.73  103.79  121.25  m3.xlarge  110.78  13.98  9.41  101.37  120.19  m3.2xlarge  Horizontal environment  109.23  17.46  11.74  97.49  120.97  m3.medium  112.67  14.77  12.34  100.33  125.01  m3.large  111.19  15.31  9.67  101.52  120.86  m3.xlarge  112.84  11.36  9.59  103.25  122.43  m3.2xlarge  View Large In the results, the use of security mechanisms negatively influenced the service performance in which ReMM was not used (Common environment). As an example, we can mention the experiments with m3.medium instances, in which the EMT was 429.98 seconds. Compared to experiments in which the m3.xlarge instance was used, the unique type of instance where the SLAs have been met in a Common environment, there was a reduction in the response variable of ~75%. On the other hand, in the Vertical and Horizontal environments, the overhead imposed by security mechanisms was offset by changes in the amount of resources performed by the ReMM. In this way, the SLAs were ensured, generating reductions in the execution mean times of ~74% and 48% in environments with m3.medium and m3.large, respectively, and an increase of ~100% with m3.2xlarge instances. However, in the experiments with m3.xlarge instances, the results in the three environments were similar, since there were no statistical differences between the values obtained with the confidence interval of 95%. As shown in Table 3 and Fig. 4, whereas the overhead imposed by the security mechanisms was 28%, the ReMM changed the amount of resources as an attempt to offset this overload and to ensure the SLA. The changes impacted on the average number of answered requests. Figure 4. View largeDownload slide Average number of answered requests. Figure 4. View largeDownload slide Average number of answered requests. Table 3. Number of used resources and their impact on the number of answered requests.   Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893    Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893  View Large Table 3. Number of used resources and their impact on the number of answered requests.   Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893    Common  Vertical  Horizontal  Instance  vCPUs  VMs  AR  vCPUs  VMs  AR  vCPUs  VMs  AR  m3.medium  1  50  2205  4  50  4891  1  200  4896  m3.large  2  50  2748  4  50  4879  2  100  4870  m3.xlarge  4  50  4677  4  50  4875  4  50  4877  m3.2xlarge  8  50  5776  4  50  4881  8  25  4893  View Large In the environments with the vertical algorithm, the changes in the number of vCPUs increased the final average costs, ~25% in the m3.medium instances and 8% in the m3.large. On the other hand, the ReMM reduced the number of vCPUs in the m3.2xlarge instances, reducing the final average costs, ~4%. The amount of resources available in the m3.xlarge instances was considered sufficient for the execution of service requests with security mechanisms. Hence, no change was necessary. Table 4 and Fig. 5 show the results. Figure 5. View largeDownload slide Final average costs per hour. (a) Virtual machine and (b) Environment. Figure 5. View largeDownload slide Final average costs per hour. (a) Virtual machine and (b) Environment. Table 4. Response variables with vertical scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  View Large Table 4. Response variables with vertical scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  111.43  0.1082  0.1348  5.41  6.74  m3.large  113.41  0.2166  0.2345  10.83  11.73  m3.xlarge  112.52  0.4387  0.4387  21.94  21.94  m3.2xlarge  110.78  0.8774  0.8415  43.87  42.08  View Large As presented in Table 5 and Fig. 5, in the experiments with horizontal scalability, there were significant increases in the amounts of m3.medium and m3.large instances, 300%, and 100%, respectively. Considering the m3.2xlarge instances, there was a reduction of 50%, while there were no changes in the environments with m3.xlarge instances. These increases in the amount of instances impacted in the same proportion on the final average costs of the environment. Table 5. Response variables with horizontal scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  View Large Table 5. Response variables with horizontal scalability. Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  Instances  EMT (s)  IACVM ($/H)  FACVM ($/H)  IACE ($/H)  FACE ($/H)  m3.medium  109.23  0.1082  0.1082  5.41  21.64  m3.large  112.67  0.2166  0.2166  10.83  21.66  m3.xlarge  111.19  0.4387  0.4387  21.94  21.94  m3.2xlarge  112.84  0.8774  0.8774  43.87  21.94  View Large Although there is no statistical difference in the EMTs in the Vertical and Horizontal environments, the methodology applied by each environment given the need to change the amount of resources on-the-fly to offset the security overhead and ensure the SLA, impacted the final average costs. While the horizontal algorithm applies the change in the number of instances, the vertical deals with the change in the number of vCPUs. Thus, it is possible to establish a relationship between the amount of used resources, the requests execution times and the cost paid for the service, considering a single VM and the environment as a whole (i.e., all instances available in the environment). In Table 6, the analysis of the percentages considers the changes made by the Vertical and Horizontal environments in relation to the Common environment. These values can be used to define the best approach for the analysed scenario. Table 6. Percentage of increase (+) and decrease (−) exercised by ReMM on response variables as an attempt to counter the security overhead and ensure the SLAs. Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  View Large Table 6. Percentage of increase (+) and decrease (−) exercised by ReMM on response variables as an attempt to counter the security overhead and ensure the SLAs. Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  Instance  EMT  FACVM  FACE  Vertical vs. Common environment  m3.medium  −74%  +25%  +25%  m3.large  −48%  +8%  +8%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  −4%  −4%  Horizontal vs. Common environment  m3.medium  −74%  0%  +300%  m3.large  −48%  0%  +100%  m3.xlarge  0%  0%  0%  m3.2xlarge  +100%  0%  −50%  View Large In the results is possible to verify that only in the experiments with m3.xlarge instances in a Common environment the SLAs have been met. This happened because the quantity of resources available in this type of instance was considered enough to attend the services demand respecting the defined SLA. Therefore, there is no statistical difference between the results with this instance in the Common environment and the results in the Vertical and Horizontal environments. In the Vertical environment, the requests execution mean times were reduced, in comparison with the Common environment, with the changes in the number of vCPUs in the m3.medium and m3.large instances. On the other hand, there was an increase in the EMT with m3.xlarge instances, generating proportional increases in the final average costs. This occurred because the ReMM reduced the number of vCPUs in this type of instance, i.e. the initially number of allocated vCPUs (8 per m3.2xlarge instance) was considered excessive for the execution of the service demand. Finally, for running safely the requests in m3.xlarge instances, there were no changes in the number of resources, and, consequently, the final average costs remain unchanged. Therefore, the used instance was considered ideal for the execution of this type of service request. In the Horizontal environment, the percentage of increases and reductions in the EMTs was similar to that obtained in a Vertical environment, since there is no statistical difference between the values. However, the impact on the final average costs was massive, especially in experiments with m3.medium and m3.large instances, in which there were increases of 300% and 100% in the final average costs of the environment, respectively. Next section shows an analysis of the influence of each factor on the response variables EMT, FACVM and FACE. 7. FACTORS INFLUENCE This section discusses about the percentage of influence of the factors Environment and Instance. We considered combinations comparing the environments with changes made by the ReMM (Vertical and Horizontal environments) with the environment in which no change in the resources was performed (Common environment). Furthermore, owing to the factor Instance has four levels, the levels m3.medium and m3.large were considered, in which, although they have lower computational differences in relation to other possible combinations of instances, they are enough to scale out the impact on the response variables. Table 7 shows the percentage of influence of the mentioned factors on the response variables, considering the Common and Vertical environments. Owing to the changes made by the vertical algorithm, necessary for compliance with SLAs, the factor with the greatest impact on the execution mean times was the Environment with 75.74% of influence. The second one was the Instance factor with 12.29% and, in third, the combination of both factors with 11.97%. Table 7. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  View Large Table 7. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.74  17.34  17.34  Instance  12.29  82.55  82.55  Both  11.97  0.11  0.11  View Large Furthermore, considering the computational differences in the types of analysed instances, in which m3.medium has one vCPU and m3.large has two vCPUs, the factor Instance was the most impactful on the final average costs, 82.55%, followed by the factor Environment, 17.34% of influence. Regarding to the Common and Horizontal environments, the percentage of influence of factors on the EMT is similar to that discussed in the previous combination. The order of influence remained the same with the factor Environment in first with 75.81%, followed by the factor Instance with 12.15%. The combination of both factors resulted in 12.04% of influence. Table 8 shows these values. Table 8. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  View Large Table 8. Percentage of influence of the factors in Common and Vertical environments. Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  Factor  EMT (%)  (FACVM (%)  FACE (%)  Environment  75.81  0  98  Instance  12.15  100  1.81  Both  12.04  0  0.19  View Large In the final average costs, the factor Instance generated an impact of 100% on the FACVM, since there are no changes in the resources that compose a virtual machine in both Common and Horizontal environments. On the other hand, considering the small difference of computational resources between the types of the analysed instances, the horizontal algorithm changed the number of instances and, hence, had the greatest influence on the FACE, with 98%. 8. CONCLUSION In cloud computing, the infrastructure is the backbone of the pricing and the quality of the services that will be provided. In this way, the resources management becomes increasingly important. The user has the vision of a single resource and exclusive use, and therefore, is expected the best performance of the selected attributes to execute the service. In contrast, the provider has multiple physical machines, which need to host the client’s virtual machines in order to maximize profit and save resources, especially energy. These considerations influence the quality of service, and consequently, the SLA defined and the price charged to the customer. Considering the results in both the Vertical and Horizontal environments, the ReMM offset the overhead imposed on the system by the security mechanisms with changes in resources, ensuring the SLAs, and consequently, impacting the costs and the average amounts of answered requests. Therefore, based on the results, the methodology applied by a Common environment was not effective considering the requirements related to the execution time and the use of security mechanisms defined in the SLA. Although the final costs remained unchanged, since there is no change in a number of resources in this environment, most of the SLAs were not ensured. Thus, the approach used in this environment is not recommended for a cloud in which the services demand is constantly changing. In the methodology adopted in the Horizontal environment, the contracts were fulfilled as a result of the changes in the amount of resources applied by the horizontal algorithm. However, these changes consist of adding or removing instances and, hence, all the resources that compose a VM (such as vCPU, memory and disk). Thus, the final costs were more expressive. Many providers offer the resources scalability option, which is applied horizontally, in which the number of instances is changed respecting the terms defined in the SLA. However, the performance improvement of a service is not directly related to the increase of all the resources that compose a VM. Perhaps only the increase in the number of vCPUs is the most appropriate procedure, saving costs and using resources more efficiently. This approach is adopted by the vertical algorithm. The methodology applied by the Vertical environment provided compliance with the requirements defined in the SLAs with small changes in the service costs. For this reason, this model proved to be the best option for cloud environments that consider the relationship between the security overhead, system performance and cost of service. Further studies should be conducted including the development of a prototype using real machines, which will allow a comparison to be made of statistical data from simulated and prototyped environments and an analysis of different network topologies. Furthermore, the hardware heterogeneity and the multi-tenancy interference in the system performance will be considered. Others resource provisioning algorithms should be developed, including the use of optimization techniques, as well as new security policies will be applied. Funding The authors would like to acknowledge the financial support provided by FAPESP (process number 2011/17201-3), CNPq, CAPES and FAPEMIG. Acknowledgements Furthermore, they would like to acknowledge the infrastructure provided by UNIFEI, UFMS, UFBA, and especially the USP and the LASDPC group, where this study was performed for the most part. Footnotes 1 https://gigaom.com/2008/02/15/amazon-s3-service-goes-down/ 2 http://www.itnews.com.au/news/dropbox-update-nullifies-passwords-261240 3 http://www.wired.com/2014/04/nsa-heartbleed/ 4 https://aws.amazon.com/autoscaling/ 5 https://openbenchmarking.org/test/pts/smallpt 6 https://aws.amazon.com/ec2/instance-types/ References 1 Prnjat, O., Rodriguez Pascual, M., Becker, B. and Barbera, R. ( 2015) Surveying clouds in a global environment. IST-Africa Conf., 2015, Lilongwe, Malawi, 6–8 May, pp. 1–11. IEEE. 2 Rimal, B.P., Choi, E. and Lumb, I. ( 2009) A taxonomy and survey of cloud computing systems. NCM ‘09: Proc. 2009 Fifth Int. Joint Conf. INC, IMS and IDC, Seoul, South Korea, 25–27 Aug, pp. 44–51. IEEE Computer Society. 3 Shekanayaki, K., Chakure, A. and Jain, A. ( 2015) A survey of journey of cloud and its future. Int. Conf. Computing Communication Control and Automation (ICCUBEA), Pune, India, 26–27 Feb, pp. 60–64. IEEE. 4 Zhan, Z.-H., Liu, X.-F., Gong, Y.-J., Zhang, J., Chung, H.S.-H. and Li, Y. ( 2015) Cloud computing resource scheduling and a survey of its evolutionary approaches. ACM Comput. Surv. (CSUR) , 47, 63:1– 63:33. Google Scholar CrossRef Search ADS   5 Luo, M., Zhang, L.-J. and Lei, F. ( 2010) An insuanrance model for guranteeing service assurance, integrity and qos in cloud computing. Proc. 2010 IEEE Int. Conf. Web Services, Miami, FL, USA, 5–10 July ICWS ‘10, pp. 584–591. IEEE Computer Society. 6 Gui, Z., Yang, C., Xia, J., Huang, Q., Liu, K., Li, Z., Yu, M., Sun, M., Zhou, N. and Jin, B. ( 2014) A service brokering and recommendation mechanism for better selecting cloud services. PLoS One , 9, e105297. Google Scholar CrossRef Search ADS PubMed  7 Batista, B.G., Estrella, J.C., Ferreira, C.H.G., Leite Filho, D.M., Nakamura, L.H.V., Reiff-Marganiec, S., Santana, M.J. and Santana, R.H.C. ( 2015) Performance evaluation of resource management in cloud computing environments. PLoS One , 10, 1– 21. 8 Yan, L., Rong, C. and Zhao, G. ( 2009) Strengthen cloud computing security with federal identity management using hierarchical identity-based cryptography. CloudCom: IEEE Int. Conf. Cloud Computing, Beijing, China, 1–4 December, pp. 167–177. Springer. 9 Marty, R. ( 2011) Cloud application logging for forensics. Proc. 2011 ACM Symposium on Applied Computing, TaiChung, Taiwan, 21–24 March, pp. 178–184. ACM. 10 Lombardi, F. and Di Pietro, R. ( 2011) Secure virtualization for cloud computing. J. Netw. Comput. Appl. , 34, 1113– 1122. Google Scholar CrossRef Search ADS   11 Subashini, S. and Kavitha, V. ( 2011) A survey on security issues in service delivery models of cloud computing. J. Netw. Comput. Appl. , 34, 1– 11. Google Scholar CrossRef Search ADS   12 Vaquero, L., Rodero-Merino, L. and Morán, D. ( 2011) Locking the sky: a survey on iaas cloud security. Computing , 91, 93– 118. Google Scholar CrossRef Search ADS   13 Velev, D. and Zlateva, P. ( 2010) Cloud infrastructure security. Open Research Problems in Network Security: IFIP WG 11.4 International Workshop, iNetSec, Sofia, Bulgaria, 5–6 March, pp. 140–148. Springer. 14 Yang, X., Nasser, B., Surridge, M. and Middleton, S. ( 2012) A business-oriented cloud federation model for real-time applications. Future Gener. Comput. Syst. , 28, 1158– 1167. Google Scholar CrossRef Search ADS   15 Khorshed, M.T., Ali, A.S. and Wasimi, S.A. ( 2012) A survey on gaps, threat remediation challenges and some thoughts for proactive attack detection in cloud computing. Future Gener. Comput. Syst. , 28, 833– 851. Google Scholar CrossRef Search ADS   16 Zissis, D. and Lekkas, D. ( 2012) Addressing cloud computing security issues. Future Gener. Comput. Syst. , 28, 583– 592. Google Scholar CrossRef Search ADS   17 Modi, C., Patel, D., Borisaniya, B., Patel, H., Patel, A. and Rajarajan, M. ( 2013) A survey of intrusion detection techniques in cloud. J. Netw. Comput. Appl. , 36, 42– 57. Google Scholar CrossRef Search ADS   18 Wei, L., Zhu, H., Cao, Z., Dong, X., Jia, W., Chen, Y. and Vasilakos, A.V. ( 2014) Security and privacy for storage and computation in cloud computing. Inf. Sci. , 258, 371– 386. Google Scholar CrossRef Search ADS   19 Ardagna, C.A., Asal, R., Damiani, E. and Vu, Q.H. ( 2015) From security to assurance in the cloud: a survey. ACM Comput. Surv. (CSUR) , 48, 2:1– 2:50. Google Scholar CrossRef Search ADS   20 Shamsolmoali, P. and Alam, A. ( 2015) Ensuring data security and performance evaluation in cloud computing. Intelligent Computing, Communication and Devices. Advances in Intelligent Systems and Computing. Springer, 308, 415–423. 21 Yang, K., Liu, Z., Jia, X. and Shen, X.S. ( 2016) Time-domain attribute-based access control for cloud-based video content sharing: a cryptographic approach. IEEE Trans. Multimed. , 18, 940– 950. Google Scholar CrossRef Search ADS   22 Huang, T., Zhu, Y., Wu, Y., Bressan, S. and Dobbie, G. ( 2016) Anomaly detection and identification scheme for vm live migration in cloud infrastructure. Future Gener. Comput. Syst. , 56, 736– 745. Google Scholar CrossRef Search ADS   23 Amoud, M. and Roudiès, O. ( 2016) A systematic review of security in cloud computing. Proc. Second Int. Afro-European Conf. Industrial Advancement AECIA 2015, Villejuif, France, 9–11 September, pp. 69–81. Springer. 24 Sanka, S., Hota, C. and Rajarajan, M. ( 2010) Secure data access in cloud computing. 4th Int. Conf. Internet Multimedia Services Architecture and Application (IMSAA), Bangalore, India, 15–17 Dec, pp. 1–6. IEEE. 25 Casola, V., Cuomo, A., Rak, M. and Villano, U. ( 2013) The cloudgrid approach: Security analysis and performance evaluation. . Future Gener. Comput. Syst. , 29, 387– 401. Google Scholar CrossRef Search ADS   26 Chhabra, S., Rogers, B., Solihin, Y. and Prvulovic, M. ( 2011) Secureme: a hardware-software approach to full system security. Proc. Int. Conf. Supercomputing, Tucson, Arizona, USA, May 31–June 04, pp. 108–119. ACM. 27 Popa, R.A., Lorch, J.R., Molnar, D., Wang, H.J. and Zhuang, L. ( 2011) Enabling security in cloud storage slas with cloudproof. USENIX Annual Technical Conf., Portland, OR, USA, 15–17 June 14. USENIX Association. 28 Zhang, F., Chen, J., Chen, H. and Zang, B. ( 2011) Cloudvisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization. Proc. Twenty-Third ACM Symposium on Operating Systems Principles, Cascais, Portugal, 23–26 October, pp. 203–216. ACM. 29 Bates, A., Mood, B., Valafar, M. and Butler, K. ( 2013) Towards secure provenance-based access control in cloud environments. Proc. 3rd ACM Conf. Data and application security and privacy, San Antonio, Texas, USA, 18–20 February, pp. 277–284. ACM. 30 He, H., Li, R., Dong, X. and Zhang, Z. ( 2014) Secure, efficient and fine-grained data access control mechanism for p2p storage cloud. IEEE Trans. Cloud Comput. , 2, 471– 484. Google Scholar CrossRef Search ADS   31 Varadharajan, V. and Tupakula, U. ( 2014) Security as a service model for cloud environment. IEEE Trans. Netw. Serv. Manage. , 11, 60– 75. Google Scholar CrossRef Search ADS   32 He, J., Dong, M., Ota, K., Fan, M. and Wang, G. ( 2014) Nscc: Self-service network security architecture for cloud computing. Computational Science and Engineering (CSE), 2014 IEEE 17th Int. Conf., Chengdu, China, December 19–21, pp. 444–449. IEEE. 33 Kurose, J.F. and Ross, K.W. ( 2012) Computer Networking: A Top-Down Approach  ( 6th edn). Pearson, New Jersey, USA. 34 Tanenbaum, A.S. and Wetherall, D.J. ( 2010) Computer Networks  ( 5th edn). Prentice Hall Press, Upper Saddle River, NJ, USA. 35 Hemanth Chakravarthy, M. and Kannan, E. ( 2014) A review on secured cloud computing environment. Am. J. Appl. Sci. , 11, 1224– 1228. Google Scholar CrossRef Search ADS   36 Orehovački, T., Babić, S. and Etinger, D. ( 2018) Identifying relevance of security, privacy, trust, and adoption dimensions concerning cloud computing applications employed in educational settings. Proc. AHFE 2017 Int. Conf. Human Factors in Cybersecurity, Los Angeles, California, USA, July 17–21, pp. 308–320. Springer. 37 Rojas, M.A.T., Redígolo, F.F., Gonzalez, N.M., Sbampato, F.V., de Brito Carvalho, T.C.M., Ullah, K.W., Näslund, M. and Ahmed, A.S. ( 2018) Developments and Advances in Intelligent Systems and Applications: Managing the Lifecycle of Security SLA Requirements in Cloud Computing . Springer, Cham, Switzerland. 38 Yadav, R., Kilaru, A. and Kumari, S. ( 2018) The recent trends, techniques and methods of cloud security. Int. Conf. Information and Communication Technology for Intelligent Systems, Ahmedabad, India, March 25–26, pp. 594–601. Springer. 39 Hu, H., Ahn, G. and Kulkarni, K. ( 2011) Anomaly discovery and resolution in web access control policies. Proc. 16th ACM Symp. on Access Control Models and Technologies, Innsbruck, Austria, June 15–17, pp. 165–174. ACM. 40 Landwehr, C.E. ( 2001) Computer security. Int. J. Inf. Secur. , 1, 3– 13. Google Scholar CrossRef Search ADS   41 Ristenpart, T., Tromer, E., Shacham, H. and Savage, S. ( 2009) Hey, you, get off of my cloud: Exploring information leakage in third-party compute clouds. Proc. 16th ACM Conf. Computer and Communications Security, Chicago, Illinois, USA, November 09–13, pp. 199–212. ACM. 42 Steiner, M., Tsudik, G. and Waidner, M. ( 1996) Diffie-hellman key distribution extended to group communication. Proc. 3rd ACM Conf. Computer and Communications Security, New Delhi, India, March 14–15, pp. 31–37. ACM. 43 Magnusson, P.S., Christensson, M., Eskilson, J., Forsgren, D., Hallberg, G., Hogberg, J., Larsson, F., Moestedt, A. and Werner, B. ( 2002) Simics: a full system simulation platform. Computer , 35, 50– 58. Google Scholar CrossRef Search ADS   44 Bethencourt, J., Sahai, A. and Waters, B. ( 2007) Ciphertext-policy attribute-based encryption. IEEE Symp. Security and Privacy, Berkeley, CA, USA, May 20–23, pp. 321–334. IEEE. 45 Blaze, M., Bleumer, G. and Strauss, M. ( 1998) Divertible protocols and atomic proxy cryptography. EUROCRYPT: Inter. Conf. Theory and Applications of Cryptographic Techniques, Espoo, Finland, May 31–June 4, pp. 127–144. Springer. 46 Waters, B. ( 2011) Ciphertext-policy attribute-based encryption: an expressive, efficient, and provably secure realization. 14th Int. Conf. Practice and Theory in Public Key Cryptography, Taormina, Italy, March 6–9, pp. 53–70. Springer. 47 Hur, J. and Noh, D.K. ( 2011) Attribute-based access control with efficient revocation in data outsourcing systems. IEEE Trans. Parallel Distrib. Syst. , 22, 1214– 1221. Google Scholar CrossRef Search ADS   48 Caron, E., Rodero-Merino, L., Desprez, F. and Muresan, A. ( 2012) Auto-Scaling, Load Balancing and Monitoring in Commercial and Open-Source Clouds. Technical Research Report RR-7857. INRIA, France. 49 Batista, B.G., Estrella, J.C., Santana, M.J., Santana, R.H. and Reiff-Marganiec, S. ( 2014) Performance evaluation in a cloud with the provisioning of different resources configurations. IEEE World Congress on Services (SERVICES), Anchorage, AK, USA, 27 June–2 July, pp. 309–316. IEEE. 50 Jain, R. ( 1991) The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling . Wiley Computer Publishing, John Wiley & Sons, Inc, San Francisco, CA, USA. Author notes Handling editor: Gerard Parr © The British Computer Society 2018. All rights reserved. For permissions, please e-mail: journals.permissions@oup.com This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/about_us/legal/notices)

Journal

The Computer JournalOxford University Press

Published: Apr 9, 2018

There are no references for this article.

You’re reading a free preview. Subscribe to read the entire article.


DeepDyve is your
personal research library

It’s your single place to instantly
discover and read the research
that matters to you.

Enjoy affordable access to
over 18 million articles from more than
15,000 peer-reviewed journals.

All for just $49/month

Explore the DeepDyve Library

Search

Query the DeepDyve database, plus search all of PubMed and Google Scholar seamlessly

Organize

Save any article or search result from DeepDyve, PubMed, and Google Scholar... all in one place.

Access

Get unlimited, online access to over 18 million full-text articles from more than 15,000 scientific journals.

Your journals are on DeepDyve

Read from thousands of the leading scholarly journals from SpringerNature, Elsevier, Wiley-Blackwell, Oxford University Press and more.

All the latest content is available, no embargo periods.

See the journals in your area

DeepDyve

Freelancer

DeepDyve

Pro

Price

FREE

$49/month
$360/year

Save searches from
Google Scholar,
PubMed

Create lists to
organize your research

Export lists, citations

Read DeepDyve articles

Abstract access only

Unlimited access to over
18 million full-text articles

Print

20 pages / month

PDF Discount

20% off