Security risk management on information systems provides security guarantees while controlling costs. But security risk assessments can be very complex, especially in a cloud context where data is distributed over multiple environments. To prevent costs from becoming the only cloud selection factor, while disregarding security, we propose a method for performing multiple cloud security risk assessments. In this paper we present a broker framework for balancing costs against security risks. Our framework selects cloud o ers and generates deployment-ready business processes in a multi-cloud environment.
The Cloud business model proposes a multitude of di erent services, at di erent prices, and with various quality levels. While the use of cloud computing can reduce costs, the selection of a solution is time consuming. For this purpose, cloud brokers have emerged; they can help cloud consumers to select adequate solutions, by comparing existing o ers, essentially against their prices.
But security is still an important factor for a cloud selection process. As cloud
computing presents new kinds of security risks ([
In turn, distributing software over multiple locations increases the complexity of gathering sensitive business information. In this paper, we propose a framework for cloud brokers which helps them analyze the security levels of di erent cloud o ers, following standard risk assessment methodologies, with respect to cloud o ers.
The paper is organized as follows. Section 2 presents a motivating example used to demonstrate the purpose and the scope of our framework. Section 3 describes our tool, its implementation on the motivating example and experimental results. Section 4 and Section 5 discuss respectively related and future work. 2
In this section, we introduce a motivating example to illustrate our framework. Then we give an overview of our approach for selecting clouds when deploying business processes.
e c n a r u s n I
Initiate Claim Account
Claim
HospOitbatlaRineport
Medical Report
Obtain Incident Details Hospital Details Hospital Report
Obtain
Expert Report Incident Details
Obtain Police Report
Police Report
Send Reimbursement
Decision Expert Report Amount
Validate Reimbursement
Consider an insurance claim recovery chain [
Now suppose that the insurance company wants to outsource the software supporting this process to the cloud to reduce costs. It has not necessarily the knowledge of moving it e ectively on its own. A cloud broker could support the company by evaluating the security risks of a cloud outsourcing, selecting the adequate o ers and decomposing the process to deploy it on multiple clouds. These three tasks are detailed below.
Our tool consists in a design-time framework for producing secure and coste ective business processes on multiple cloud. It is illustrated in Fig.2.
Security Needs
Business processes
Cloud Offers
Configuration
First, a cloud broker requests the security needs as non-functional requirements from the cloud consumer and analyzes the cloud o ers from the cloud provider to realize a risk assessment.
Second, the broker uses the business processes from the cloud consumer to select the adapted cloud o ers based on the functional requirements, the costs and the previously calculated risk.
Third, the broker decomposes the business process into smaller parts, as
each task can be enacted on a di erent cloud o er. The generated con guration
is the assignment of these process fragments to cloud o ers. The decomposition
itself has already been addressed in [
Implementation, experimentation and evaluation To demonstrate the feasibility of the approach, we illustrate on our motivating example the three previously de ned steps of the broker tool. 3.1
The risk assessment is threefold: security needs de nition, risk evaluation and cloud provider exclusion.
Security needs de nition Our framework uses the ve CIANA objectives (Con dentiality, Integrity, Availability, Non-Repudiation, Authenticity) to de ne the security need of each data object of the process (Fig. 1). If the data object needs the objective, the value is equal to 1, otherwise to 0 (see Table 1). Typically, these security needs are negotiated by a risk manager with the cloud consumer.
As business process deployment is task-centric, these values need to be translated into security needs on tasks. We use the maximum values of the input and output objects of a task. For example, Obtain Incident Details is associated to the data objects Claim, Incident Details and Hospital Details. So, by taking the maximum of each data object's need we get the need of Obtain Incident Details: f0, 1, 1, 1, 1g for respectively fConf identiality, Integrity, Availability, N on-Repudiation, Authenticityg.
Risk evaluation for each provider In this paper we take into account ve
cloud security threats given by the CSA [
Authenticityg { Insecure Interfaces = fCon dentiality, Integrity, Authenticityg { Denial of Service = fAvailabilityg Harm - We combine these relations with the security needs of each data object to obtain a so-called harm. The harm is de ned on each data object, for each threat through the sum of the a ected security needs. For example, the Insecure Interfaces threat (t) has the following harm on Obtain Incident Details (ta): Harm(t; ta) = (1 0) + (1 1) + (0 1) + (0 1) + (1 1) = 3 The rst value of each bracket is equal to 1 if the threat is related to the objective, 0 otherwise, and the second value is the need calculated previously. Notice that the harm value is in this case always between 0 and 5. The result for all tasks of the process can be seen in Table 2.
Coverage - Now that we have the harm of a threat on each task of the process, we
need to determine the response to these threats for each cloud provider. For this
information we use the STAR Registry and the matrix de ned by the CSA [
The CSA matrix de nes a list of security controls a cloud provider should implement to reduce security risks. Each of these controls can be related to one or multiple threats. For example, the control "IS-19.4 - Do you maintain key management procedures ?" mitigates the Data Breaches threat. This matrix de nes a total of 197 controls to implement in order to respond to all threats in the best possible way.
The STAR Registry publishes the list of implemented controls for providers willing to follow these recommendations. These lists are freely accessible and can help to check if a control has been put in place by a speci c provider or not.
In our case, we use these two information as binary values (a control mitigates a threat or not / a control is implemented by a provider or not) to calculate a so-called coverage score, which indicates the response of a provider to a given threat. This value is a percentage, if the provider implements all controls mitigating a threat, it gets a coverage for this threat of 100%. In our case, this percentage is brought to a score on a scale of 0 to 5 (with 5 equivalent to 100%). We took 5 providers from the registry and calculated their coverage score, it is available in Table 2.
Too risky provider exclusion Usually, the vulnerability is assessed and used to calculate a risk value of an information system. But in a cloud context, providers may be tempted to conceal their vulnerabilities for security reasons. This is why we use the coverage based on the security controls. By using the maximum possible coverage value Covgmax (in our case 5), it is possible to get an equivalent to the vulnerabilities. Therefore, by combining this value with the harm we can de ne the following risk formula for a threat t, a task ta and a provider p: Risk(t; ta; p) = Harm(t; ta) + (Covgmax Covg(p; t)) Table 3 shows the maximum risk value for the ve CSA threats, for the tasks of our motivating example, on ve di erent providers (Softlayer4, CloudSigma5, FireHost6, SHI Int.7 and Terremark8).
In accordance with the consumer, the broker de nes the level of acceptable risk (referred to as threshold). For a given task, this threshold de nes the providers with a too high risk value and excludes these deployment options. In our example, we set the threshold to 5, the cells of eliminated providers are grayed out in Table 3. Respectively a white cell means that the task can be deployed on the provider. 3.2
We select the target cloud environments in two stages: di erent con gurations evaluation and nal clouds selection.
Con gurations evaluation We need to evaluate the di erent possible deployment con gurations. To do this, we introduce a cost model which will allow us to balance the risks against the costs.
Cost model - Our cost model takes into account three types of costs: { Usage costs, the CPU power needed to execute the process ($/GHz/month).
The need is annotated on the tasks of the process. { Storage costs, the space needed by the data of the process ($/GB/month).
The size is annotated on the data objects of the process. { Transfer costs, the amount of incoming/outgoing messages ($/GB). This size is calculated with the data exchanged between the process fragments. 4 http://www.softlayer.com 5 http://www.cloudsigma.com 6 http://www.firehost.com 7 http://www.shi.com 8 http://www.terremark.com
Softlayer CloudSigma AG FireHost SHI International, Corp.
Terremark
We can notice that the transfer costs conduct to a regrouping of the tasks on one main o er to restrain the global costs. The process is deployed on the target environments in two steps: process decomposition and fragments deployment.
Secure and Cost-E ective BP Deployment on Multiple Clouds 55
Process decomposition According to the selected con guration, the process
is decomposed in multiple process fragments. A fragment is an autonomic
business process enacted on one cloud and includes additional synchronization tasks.
These additional tasks support the collaboration with the remote fragments to
guarantee the control ow of the initial process. More details can be accessed
in [
The decomposed motivating example according to the selected con guration is depicted in Fig.3 (grey activities are synchronization tasks).
a m g i S d u o l C It.I n H S
Deployment in clouds The last step of our approach consists in deploying this
con guration on the selected cloud o ers. In [
In [
In opposition to our proposal, [
The model presented in [
Watson [
In this paper we have presented a cloud broker framework for assessing security risks in a multiple-cloud context. We assess security risks of cloud providers using standard-based and industry accepted security controls and risk listings. We focus on one business process to illustrate how these risk values, in combination with costs, can help a cloud broker to take decisions for the cloud provider selection. The paper demonstrates the feasibility of our approach with a motivating example and real cloud providers.
Some limitations are not addressed in this paper. First, the shortage of empirical evaluation on real use cases, which will be realized in future works with domain experts and industrial partners. Another point is that our approach takes place at design-time, but as the Cloud is a very dynamic context, extending our framework to con guration at run-time would be an interesting improvement. Finally, the binary values for the security needs, mitigations and control implementation could be replaced with more complete scales, as some security controls \better" mitigate threats than others.