Modeling Security Requirements for Cloud-based ...

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE Concurrency Computat.: Pract. Exper. 2013; 00:1–17 Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/cpe

Modeling Security Requirements for Cloud-based System Development Massimo Ficco∗1 , Francesco Palmieri1 , and Aniello Castiglione2 1 Department of Industrial and Information Engineering, Second University of Naples, Via Roma 29, Aversa (CE), 2 Department of Computer Science, University of Salerno, Via Ponte Don Melillo, Fisciano (SA), Italy

Italy

SUMMARY The Cloud Computing paradigm provides a new model for the more flexible utilization of computing and storage services. However, such enhanced flexibility, that implies outsourcing the data and business applications to a third party, may introduce critical security issues. Therefore, there is a clear necessity of new security paradigms able to face with all the problems introduced by the cloud approach. Although, in the last years, several solutions have been proposed, the implementation of secure cloud applications and services is still a complex and far from consolidated task. Starting from these considerations, this work fosters the development of a methodology that considers security concerns as an integral part of cloudbased applications design and implementation. Accordingly, we present a set of stereotypes that defines a vocabulary for annotating UML-based models with information relevant for integrating the specification of security requirements into cloud architectures. This approach can be used to significantly improve productivity and overall success in the development of secure distributed cloud applications and systems. The final publication is available at: http://onlinelibrary.wiley.com/doi/10.1002/cpe.3402/abstract c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Received . . .

KEY WORDS: Cloud Computing; security; modeling; cloud applications; UML-based metamodel.

1. INTRODUCTION Cloud Computing is rapidly emerging as a hotspot in both industry and academia. It represents a new business model and computing paradigm, which enables on-demand provisioning of computational and storage resources. The Cloud Security Alliance has summarized five essential characteristics, that illustrate the tight relationships and the main differences characterizing cloud from more traditional computing paradigms, including on-demand self-service provisioning, broad network access, resource pooling, rapid elasticity, and measured service features [1]. However, economic benefits are the main driver for cloud development due to the severe reduction of both the capital and operational expenditure consequent to the introduction of these technologies in the information life-cycle management [2]. On the other hand, in addition to the benefits immediately available, the previous features result in serious cloud-specific security issues, preventing many organizations to transfer their missioncritical business into the cloud. These security issues are now the real barrier to the diffusion of Cloud Computing technologies in most of the IT-related sectors of modern society [3]. In particular, the Cloud Computing model involves the introduction of service oriented paradigms, multi-domain interoperability issues, multi-tenancies, on-demand elasticity and massive data and ∗ Correspondence

to: Massimo Ficco, e-mail: [email protected]

c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls [Version: 2010/05/13 v3.00]

2

M. FICCO ET AL.

applications outsourcing, as well as intense communication overhead, which are prone to several cyber attacks and hence potentially introduce vulnerabilities in IT management systems. In fact, most of the above paradigms imply a very limited control on all the involved entities/components and their interactions, that is widely considered as the root cause of many cloud security weaknesses. Moreover, the presence of very heterogeneous kinds of users lead to much different security requirements, which have to be granted by cloud customers and cloud service providers [4]. In this scenario is clear that Service Level Agreement (SLA) availability and performance parameters alone are not enough to ensure the satisfaction of secure service delivery. Incorporating security parameters in the SLAs can improve the quality of the services being offered [5]. This new requirement may have deep implications in the security solutions to be implemented and delivered in order to protect the services provided in the cloud [6]. Moreover, in order to cope with the resource capacity limits of a single cloud provider, as well as to address the vendor lock-in problems associated to the choice of a single proprietary cloud solution, the concept of federating multiple heterogeneous organizations is receiving an increasing attention by the key players in the cloud services market, by introducing further security issues and weaknesses [7]. In fact, the effects of attacks in a federated context may span from the loss of some data to the potential isolation of parts of the federation [8]. Thus, protecting the federated clouds against cyber attacks becomes a key concern, since there are potentially significant economic consequences for any vulnerability exploited by cyber attacks. Although security is an important aspect in information systems engineering, the literature reports that security concerns are often raised only when the system is about to be deployed or is already in use [16, 9, 11, 12]. In the best cases, security is considered only during the late system development stages. This is a serious issue in secure system design and implementation, since the early stages of the development process are the place where system security concerns should be discovered and security trade-offs should be analyzed. An approach to guide such an analysis is suggested by model-driven security [10]. In particular, due to the complexity of the modern cloud-based systems and applications and to the ease with which they can be compromised, it becomes fundamental to incorporate security concepts from the very beginning phase of their development life cycle (e.g., requirement specification and design). That is, in addition to designing and implementing secure software applications alone, developers also need to ensure these applications to run on secure cloud infrastructures, by protecting data they handle and adopting all kind of available security mechanisms to provide confidentiality, integrity and robustness in their communication from the cloud sites to the users and vice versa. All these issues become fundamental non-functional requirements that must be considered in every phase of the software development life cycle, starting from the requirement analysis and design stages. Although many different languages have been proposed to represent security specifications [16, 15, 20, 18, 17, 32], no one of them was conceived with the complexity of a cloud-based application and/or system in mind. Therefore, in order to propose an appropriate security specification language for cloud system design, at first we present a perspective of the most popular security specification languages found in the literature, with the purpose of individuating the best starting point choices from the options already available. Then, we propose an approach which shows how developers can identify and enforce, from the very early stages of development, the security requirements to be offered by the application and services to cloud users. Stereotypes are provided to extend UML diagrams and easily describe a cloud system with all its peculiarities. The presented UML-based meta-model can be used by cloud customers, as well as cloud service providers to develop services and applications offered to their end-users at different cloud stack levels, including IaaS, PaaS and SaaS. The remainder of the paper is organized as follows. The related experiences available in literature is presented in Sec. 2. Some of the most significant security challenges that need to be addressed in Cloud Computing are presented in Sec. 3. The modeling approach is presented in Sec. 4. The proposed stereotypes for annotating UML based models with information relevant for integrating the specification of security requirements into cloud-based systems are presented in Sec. 5. Finally, conclusions and lessons learned are presented in Sec. 6. c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

3

2. RELATED WORK AND TECHNOLOGIES In this section, we present an overview of the most popular security specification languages found in the literature. Every tool is explained in its essential features, followed by a comparison that underlines advantages and disadvantages of each approach.

Misuse Cases and Abuse Cases Use cases are abstract episodes of interaction between a system and one or more actors that represent entities outside a system interacting with it in some way. Misuse cases specify behaviors not wanted in the proposed system for the purpose of eliciting security requirements [13]. A Misuser is an actor that initiates misuse cases, either intentionally or inadvertently. In a Use Case diagram, in addition to Actors and Use cases, the security model introduces Misusers and Misuse Cases, so that misuse cases may threaten regular use cases. The model also identifies “Security Use Cases”, which may mitigate Misuse Cases. Therefore, Use Cases and Misuse Cases, with their interactions, may be represented in the same diagram. The visualization of links between Use Cases and Misuse Cases are helpful in organizing the requirements specification. The essence of a Misuse Case is usually captured in the associated textual description. A lightweight Misuse Case description extends the regular Use-Case template with a field called Threats. In this field, it is possible to specify one or more security issues and the possible outcomes. A full list of text fields describing Misuse Cases extensively can also be used. It includes a field that describes the actions that the Misuser could perform to harm the system; another field describes its alternative paths. Abuse Cases describe interactions involving the minimal abuse of privilege necessary to accomplish the harm intended by the abusing actor [14]. Unlike Misuse Cases, the Abuse Case diagram is kept separated from the Use Case one, so that we can distinguish the two by labeling the diagrams. In an Abuse Case, a more detailed description of the involved actors is given. Three characteristics of each actor are critical for understanding an abuse case: the actor’s resources, skills, and objectives. An Abuse Case diagram is associated with a tree diagram depicting the various ways that the Abuse Case may be accomplished. The diagram must be read like a decision tree, with each path from root to a leaf defining an abstract Abuse Case transaction that could potentially occur. Misuse Cases and Abuse Cases allow early focus on security by describing security threats and then requirements, without going into design. They can be made simple and abstract enough to be understood by users from a wide range of application domains. They can be used to show customers what will be prevented and what will not, in terms of their application domain. However, the harm is not always an identifiable sequence of actions and there is not always an identifiable malicious actor. These diagrams inform developers only about which security-related information they should specify and not about how and when to do so. They say nothing about how the security requirements process is related to other software development activities. These models are not a substitute for mathematical security models. Finally, Misuse Cases and Abuse Cases are ambiguous and incomplete so they can’t replace any other part of a security engineering process.

AsmL and UML State Charts Abstract State Machine Language (AsmL) is a software specification language developed by Microsoft, defining abstract state machines through a fairly high-level language that can be compiled into executable code. The syntax of AsmL is similar to a procedural programming language. The language has variables, methods, classes and supports object-oriented features, such as instances and inheritance. On the other hand, State Charts, one of the diagram types available in UML, are based on extended finite state machines and some of their important constituents are states, transitions, conditions, actions, and events. Zulkernine et al. [15] presented a method for integrating AsmL and Unified Modeling Language (UML) state charts, that are extended finite state c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

4

M. FICCO ET AL.

machine-based software specification languages, with the Snort open source Intrusion Detection System (IDS). Snort is a network IDS that sniffs network traffic packets and uses rules from a database of attack signatures to detect any attack packet. The attack scenarios are specified in AsmL or UML state charts, and then, automatically translated into Snort rules, which retain the context information present in AsmL and UML state chart scenarios. The Snort’s detection engine is than modified so that it can understand the rules translated from AsmL or UML state chart scenarios. Snort’s rules are not related to each other and this makes it difficult to detect coordinated attacks that have multiple steps. In fact, by using basic attacks multiple times within a specific period of time it is possible to specify most of the coordinated attacks. A similar situation can be observed in presence of different types of basic attacks. For this reason it is possible to use context information in AsmL or UML state charts to allow representation of more complex and coordinated attack scenarios, which could not be specified by using simple Snort rules. Even if the Snort IDS is non used, this work is helpful because it shows how to adopt a software specification language like AsmL to specify attack scenarios and how to avoid harms. However, AsmL and UML State Charts are not natively conceived for describing attack scenarios and hence do not provide functions for that purpose.

AsmLSec In order to have a specification languages that can be used for both functional and security specification, Raihan et al. [16] proposed a formal extension of a popular specification language, namely AsmL, for properly describing attacks with a view towards building secure software. The power of executable and testable AsmL specifications makes it a perfect choice for attack specification. However, AsmL was intended to be used for modeling, analyzing, and prototyping of components and protocols. It is appropriate for capturing the abstract structure and discrete behavior of the software with several degrees of detail. Therefore, AsmL lacks a number of features required to represent attack scenarios available in attack languages. AsmLSec is meant to incorporate those features in AsmL allowing to model an attack as a set of states and transitions. States represent a snapshot of different system attributes during the course of attacks. Transitions are labeled with system events that cause changes from one state to another. A state transition can take place only if certain conditions associated with the transition are satisfied. The system events need to take place in a certain order so as to make an attack successful. These temporal relationships among system events are modeled in AsmLSec attack specifications. An alert is generated when the system reaches a state under attack. Even if AsmLSec provides a quite rich syntax that facilitates writing attack signatures, the language suffers from some limitations, the most significant of which is not supporting regular expressions. In fact, attack patterns, when expressed by using regular expressions are more generic and able to capture variations in attack dynamics, due to evolution of attack strategies.

UMLSec UMLSec is an extension of UML aiming at aiding the development of security-critical systems [17]. It enables developers with security background to make use of security engineering knowledge encapsulated in a widely used design notation. To understand the offered potentialities let us consider a number of subsystem diagrams S describing different parts of a system. In order to define the security requirements for each diagram, we need to model potential adversary behavior. The adversaries can attack different parts of the system in a specified way. We can assume a function Threats A(s) which takes an adversary type A and a stereotype s and returns a subset of “delete, read, insert”. UMLSec provides many stereotypes that extend the semantics of existing types in the UML meta-model. Each new stereotype may have a tagged value and specific constraints. Such stereotypes label subsystems containing object diagrams or static structure diagrams to define c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

5

the security constraint we need. In particular, the constraints give criteria to evaluate the security aspects of a system design, by referring to a formal semantics of a simplified UML fragment. When considering the preferred utilization scenario, UMLsec mainly focuses on specifying and validating security properties and mechanisms like encryption.

SecureUML SecureUML is a modeling language that defines a vocabulary for annotating UML-based models with information relevant to access control [18]. The language builds the access control model for role-based access control (RBAC) with additional support for specifying authorization constraints. Simple policies can be expressed by using role-based permissions, and more complicated requirements can be specified by adding authorization constraints. SecureUML can be used in the context of a model-driven software development process to generate access control infrastructures. In this way, productivity during the development and the quality of the resulting systems can be improved. However, this model focuses only on access control problems, and it is not suitable to be used for a security specification language that can cover all different kind of security issues.

Secure Tropos Tropos is a development methodology specifically tailored to describe both the organizational environment of a system and the system itself. It deals with all the phases of system requirements analysis and system design and implementation, by adopting uniform and homogeneous choices. Tropos pays great deal of attention to the early requirements analysis that precedes the specification of the perspective requirements, emphasizing the need of understanding how and why the intended system would meet the organizational goals. In Tropos, the system is seen as a set of actors, who depend each other to reach their goals. The type of the dependency describes the nature of an agreement between dependee and depender. Goal dependencies represent delegation of responsibility for fulfilling a goal; softgoal dependencies are similar to goal dependencies, but their fulfillment cannot be defined precisely; task dependencies are used in situations where the dependee is required to perform a given activity; and resource dependencies require the dependee to provide a resource to the depender. Tropos was not conceived with security on mind, thus Mouratidis et al. [19] proposed a set of security concepts, such as security constraint, secure entities and secure dependencies enabling it to consider security aspects throughout the whole development process. A security constraint is defined as a restriction related to security issues, such as privacy, integrity and availability, of an information system. It can influence the analysis and design of the system under development by restricting some alternative design solutions, by conflicting with some of the requirements of the system, or by refining some of the system’s objectives. A secure entity represents a secure goal, a secure task or a secure resource. During the early requirements analysis stage, the goals, dependencies and the security constraints between the stakeholders (actors) are modeled with the aid of an actors diagram. In such a diagram, actors (graphically represented as circles) are modeled together with their goals (represented as ovals), soft-goals (represented as bubbles), their dependencies (represented as links between the actors indicating the dependum), and their security constraints (modeled as clouds). During the late requirements analysis stage, security constraints are imposed to the system-to-be. These constraints are further analyzed and security goals and entities necessary for the system to guarantee the security constraints are identified. The architectural design phase defines the system’s global architecture. During the detailed design each component of the system, identified in the previous stages, is further specified by using AUML diagrams, such as Capability Diagrams or Agent Interaction Diagrams.

c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

6

M. FICCO ET AL.

UMLintr UMLintr is a UML profile, that is, a collection of UML notations extended to specialize UML for a particular domain, which facilitates the specifications of intrusion scenarios [20]. UML diagrams used in UMLintr are called misuse-case, misuse-package, misuse-class, and misuse-state-machine diagrams. Use-case diagrams provide an abstract view of the services provided by the software. In UMLintr, each misuse-case diagram consists of an > actor and a > actor connected to a use-case representing the exploitation method. > represents instances where the attacker convinces the user to give out critical security information; > represents instances where an implementation bug in the software is exploited by the attacker; > is used for attacks where the attacker exploit a misconfiguration in the system policy; > is used for attacks where the attacker abuses a feature provided by the system. Misuse-package diagrams group into similar packages intrusion scenarios which share common properties. A package labeled with > contains scenarios for denial of service intrusions. > packages contains intrusion scenarios where remote attackers gain access with local user privileges. > denotes packages where users with local privileges gain root privileges. > denotes packages where attackers try to gather information about machines on the network to find their vulnerabilities. A Misuse-class diagram is represented by a box containing class stereotype and name, tagged values, data and functions. Three stereotyped classes are introduced: >, >, and >. Each stereotype has its own tagged values that present security related information. Misuse-state-machine diagrams are used to specify the detection of intrusion scenarios. Each misuse-state-machine represents the states which its corresponding attack may go through. Developers create new states representing different stages of an attack. The transition from one state to another is based on a trigger (event) specified by developers, such as arrival of a network packet or a system call. The transition can have instructions to be executed after triggering the transition. Developers may choose to add a guard condition to the transition which must be true before its corresponding transition can take place. The final state of each diagram marks a successful penetration. Component diagrams show the system as being composed of different components. UMLintr extends this view with an > stereotype presenting a component that offers intrusion detection services for other components. This UMLintr-based tool can be used for modeling components, specifying intrusion scenarios, and producing intrusion signatures, which can be employed by special UMLintr-based IDS to automatically detect intrusions. However, exploring how to specify and handle other security requirements like authentication, authorization, and integrity must extend UMLintr.

STATL STATL is an extensible state/transition-based attack description language designed to support intrusion detection [21]. The language allows the description of security violations as sequences of actions that an attacker performs to compromise a computer system. The STATL language has been successfully used in describing both network-based and host-based attacks, and it has been tailored to very different environments. Moreover, this methodology supports a modeling approach that represents only those steps in intrusion that are necessary for ensuring the effectiveness of the attack. By abstracting away from the details of a particular attack, it is possible to detect previously unknown variations of an attack or attacks that exploit similar mechanisms. The STATL language provides constructs to represent an attack as a composition of states and transitions. States are used to characterize different snapshots of a system during the evolution of an attack. The state assertion is tested before entering into a state and then the specific state’s code block is executed. A transition connects two states each other and has an associated action that is a specification of the event that may cause the move to a new state. The language is rigorous, that is, it has a precise syntax and a c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

7

parser. Moreover, it allows the representation of different types of attack: probes, denial-of-service, remote and local user-to-root attacks, threshold-based attacks, and even policy-based attacks.

Interaction Model All the presented languages have been proposed to represent security specifications, but no one of them was conceived with the complexity of a Cloud Computing system on mind. Therefore, in a previous work, we proposed an Interaction Model for modeling security requirements in Cloud Computing [22]. An Interaction is defined as every kind of data exchange among actors in a cloud system. Each Interaction is specified by the triple < Consumer, P rovider, T arget >, where: • Consumer: initiates the interaction and sends all the necessary information to process the request; • Provider: receives requests from Consumers and manages the requested object; • Target: the object involved in the request, such as a cloud service or a cloud resource. The actors involved in Interactions include the Cloud Customer and the Cloud Provider, as well as: • Attackers, that try to harm the cloud application or system, • Services, which refer to all kind of services provided by the cloud applications, and accessing to cloud resources, • Resources, that indicate any kind of resources located in the cloud (Virtual Machine, Storage, Table, Message Queue, etc.).

Each interaction involves different actors, which can assume any of the above roles. Every Interaction can be implemented in different modalities. Developers will select the right modality to implement according to its security level and available mechanisms/features. Each Interaction modality is characterized by: the triple: < T hreat, Security Requirement, Security M echanism >, where: • Threat: specific attacks or systems vulnerabilities that we want to mitigate or eliminate; • Security Requirements: requisites denied by the threat (usually, it is requested in the Service Level Agreement with the Cloud provider); • Security Mechanisms: methods and techniques to enforce the system with both additional components or with a specific implementation of an already existing component.

Depending on the Interaction, the requirements denied by the threat and the security mechanism that should be adopted may vary. A conceptual view of a Use Case representation is reported in Fig. 1. In particular, to each Use Case can be associated a set of critical interactions, which can be implemented in different modalities according to the user requirements.

Figure 1. Use Case representation

Finally, some concepts of such Interaction Model have been inherited and extended in the current proposal. c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

8

M. FICCO ET AL.

Summary of contributions Each analyzed language has its own advantages and disadvantages. Tab. I attempts to summarize the presented languages. Table I. Secure specification languages comparison Language

Class

Main Advantages

Main Disadvantages

Misuse Cases and Abuse Cases

Security requirement; Specification language.

Not a substitute for formal security models.

AsmL and UML State Chart

Specification language used to specify attack scenarios.

AsmLSec

Security requirement; Attack description language.

UMLSec

Security requirement; Specification language.

Simple to be understood; Abstract enough to define various security requirements; Similar to UML Use Case diagram. Same language for functional and security requirements; Possibility to convert attach scenarios into Snort rules. Extend AsmL with a rich set of syntax for attack signatures; Same language for functional and security requirements. UML extension; Easy to implement.

SecureUML

Security requirement; Specification language. Security requirement; Specification language.

Secure Tropos

UMLintr

Attack description language.

STATL

Attack description language.

Interation Model

Security requirement; Specification language.

UML extension; Easy to implement. Simple to be understood; Security is defined in different levels of complexity. UML extension; Security is defined in different levels of complexity. Used in describing both network- and host-based attacks; Attack described only in its necessary steps. Used in describing security mechanisms offered by CSP to cloud customers.

Insufficient function for describing attack scenarios.

Documents can be understood only to security experts; Does not support regular expressions. Focused only on validating security properties and mechanisms. Focused only on access control policies. Visual complexity of the diagrams; Low spread of Tropos comparing to UML. Not suitable for authentication, authorization, and integrity requirements. Documents can be understood only to security experts; Focused on IDS. Focused only on service interations.

3. CLOUD SYSTEMS CHARACTERISTICS AND SECURITY CHALLENGES Although all the options presented in the previous section have been proposed to specify security requirements, apart [22], no one of them was conceived to cope with the elasticity of cloud federation model [23]. In general, achieving a satisfactory degree of security for applications and services provided within a cloud is an hard and challenging task due to the complexity, heterogeneity, and dynamic nature of such systems. According to a cloud federation model, an application is composed of several software components, which run on distributed virtual nodes c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

9

hosted by different cloud service providers (CPSs) participating to the federation. Therefore, some challenges that need to be addressed during development and deployment of security solution for cloud federation scenarios, include: • In traditional distributed systems, due to the static nature of the monitored infrastructure, the security policies tend to be static, or at least rarely change over time. In a cloud federation infrastructure, the monitored virtual networks and nodes, that host the customer applications and services, are dynamically changed, added, and removed, and their security requirements tend to be different [24]. • Recent researches have provided evidence that most of the intruders come from the inside. Therefore, CPSs need to know if their infrastructure components are abused by malicious customers or applications running on a federated cloud [25]. • With the emerging federated cloud paradigm, where services are composed of several other services from different providers, we have a situation that implies a chain of transitive trust. Therefore, even though a customer trust his nearest provider, he may not implicitly trust the other ones involved in the service composition. Assuring the customer that adequate security mechanisms exist and are correctly implemented throughout the whole chain of providers will therefore be a hard challenge. • The federated cloud concept will require services to be composed dynamically in a more autonomous and ad-hoc manner over a shared infrastructure. This opens the door to a wide range of new threats, such as hijacking service components, forming compositions based on both legitimate and illegitimate service components, and injecting malicious services into otherwise legitimate service compositions [27, 26]. • In the cloud, the service provider’s system administrators often have unlimited access to the customer data and applications, which implies that illegitimate tampering or usage of customer property may easily go undetected. From the customers’ perspective, the use of federated cloud services implies an increased risk; achieving control over who can access and alter the customer data will be extremely difficult. Also, in contrast to the traditional IT system context, mutual auditability is a security issue new to Cloud Computing, since both the customer and the provider may be the source or the target of an attack. In federated clouds, the CPSs face an increased risk, since they may not know or do not have any possibility to control who the data and applications residing in their data centers belong to. In addition, the limited collaboration or mutual visibility between the involved providers or organizations may make things worse by introducing new “grey zones” characterized by lack of control and auditability.

Both CPSs and customers will benefit significantly if there is a comprehensive protection solution that evolves on the base of their requirements. Carefully, modeling these security requirements within the cloud system design process may be also helpful in filling the gap between the concrete user requirements and the more abstract and formal problem of representing them within the context of software engineering practices. Nevertheless, by considering these requirements by starting from strong and clear formalisms when designing cloud-based software architectures can significantly influence the final system behavior, and hence is overall success and quality, especially concerning non-functional and difficult to hand aspects like security. Therefore, proposing a new defense strategy that considers the different cloud security requirements from scratch, by starting from the earlier design stages, is the main motivation of this work.

4. SPECIFICATION OF CLOUD SECURITY REQUIREMENTS In this paper, we present a modeling language that defines a vocabulary for annotating UML-based models with information relevant to prevent cyber attacks against applications and services deployed in federated clouds. Some stereotypes have been inherited from models presented in the literature and adapted to the design strategy proposed in this work. Such strategy is based on the following logical steps: c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

10

M. FICCO ET AL.

1. Required behaviors of the application are identified and modeled with Use Cases. They are described by using interaction scenarios, which represent the interactions in terms of ordered set of legitimate actions that the involved actors may take within the system. 2. Unwanted behaviors are described as Misuse Cases. also in this case, developers have to elicit malicious behaviors (threats) by interaction scenarios. By using Misuse Cases, potential attacks that can affect application Use Cases should be considered. In particular, in this stage, developers have to elicit specific security requirements in order to mitigate the threats that may potentially occur. 3. The whole system is described with a Cloud Component Diagram and Deployment Diagram. They allow to specify the architecture and the security requirements related to the deployment of the involved application components in the federated environment. It is also possible to enrich the diagram by adding new formalisms necessary to describe the countermeasures for the described threats. 4.1. Use Cases and Misuse Cases Specification During the requirements analysis, it is important to describe the cloud application at a very high level, in which also security requirements should be preserved. Therefore, during the representation of the application requirements specification, whereas Use Cases specify general requirements, Misuse Cases can be added in order to specify behaviors not wanted in the analyzed system, performed for the purpose of eliciting user requirements. As represented in Fig. 2, Use Cases are abstract episodes of interaction between the system and one or more cloud users or customers, Misuse Cases represent security threats for Use Cases. A Misuser can be either an actor that operates outside the cloud federation (malicious cloud user), or an insider (e.g., a malicious customer of a federated cloud or a deployed application). Moreover, specific countermeasures can be defined to mitigate the threats. In particular, Mitigation Cases represent the security requirements to be implemented in order to mitigate Misuse Cases. An extensive Misuse Case description is presented in [13].

Figure 2. Use and Misuse Cases metamodel

c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

11

4.2. Actors and Roles The proposed model aims at describing both wanted and unwanted behaviors. The difference between a Use Case and a Misuse Case is mainly related to the interaction purposes. Use Cases can model any kind of legitimate interaction that describes the whole application behavior. Instead, Misuse Cases model malicious behaviors, which can cause harm to some stakeholder of the federation if the sequence is successful. According to the proposed approach, Use Cases and Misuse Cases can be described as interaction scenarios. The advantage of using the interaction scenarios is that they are completely independent from the technologies offered by different cloud providers (e.g. Windows Azure, Amazon EC2, Google Compute Engine, etc) [22]. The actors involved in the scenarios include the End-User, the Cloud Customer and the Cloud Service Provider, as well as a Misuser that tries to harm the cloud application or system. In particular, the Cloud Customer is the principal stakeholder for the cloud federation services needing the establishment of proper SLAs to specify the technical performance requirements regarding the quality, security, and remedies for performance degradation and failures, associated to the services to be implemented and offered to their end-users. Depending on the services requested, activities and usage scenarios, there will be different Cloud Customers: • SaaS Customers (CS) can be organizations that provide their members with access to software applications, as well as customers of a federated cloud who use a service offered by other federated cloud, or software application administrators who configure applications for end users. • PaaS Customers (CP) can be developers who design and implement software applications, testers who run and test applications in the federated environment, deployers who publish applications into the federation, and administrators who configure and monitor application performance on a specific platform. • IaaS Customers (CI) have access to virtual computers, network-accessible storage, network infrastructure components. They can be system developers, system administrators and IT managers who are interested in creating, installing, managing and monitoring services specifically deployed for IT infrastructure operations. The CSP is the entity responsible for making a service available to the interested parties. It acquires and manages the computing infrastructure of the federation required for providing the services, runs the cloud software that provides the services, and makes arrangement to deliver the cloud services to the Cloud Customers through network access. There are three different kind of CSPs: • SaaS Providers (PS) deploy, configure, maintain and update the software applications on the cloud infrastructure, so that the services are provisioned according to the expected service levels to Cloud Customers. • PaaS Providers (PP) manage the computing infrastructure at the platform-layer and run the cloud software that provides the components of this platform, such as runtime software execution stacks, databases, and other middleware components. They provide tools such as integrated development environments (IDEs), development version of cloud software, software development kits (SDKs), as well as various deployment and management tools. • IaaS Providers (PI) acquire the physical computing resources/equipment underlying the service, including the servers, networks, storage, hosting infrastructure and provide a set of service interfaces and computing resource abstractions, such as virtual machines and virtual network interfaces. To be more comprehensive, the National Institute of Standards and Technology (NIST) defines other three actors [28]: • Cloud Auditors (CA), third party organizations or individuals that can conduct independent assessment of cloud services, information system operations, performance and security of the cloud implementation. • Cloud Brokers (CB), entities that manage the use, performance and delivery of cloud services, and negotiate the relationships between Cloud Providers and Cloud Customers. c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

12

M. FICCO ET AL.

• Cloud Carriers (CC), intermediaries that provides connectivity and transport of cloud services from Cloud Providers to Cloud Customers.

The other entities involved in the scenarios are Misusers (M), Services (S) which refer to all kind of services witch provide access to cloud applications and cloud resources, and Resources (R) that indicate any kind of resource located in the federated cloud (Virtual Machine, Storage, Table, Message Queue, etc.). According to the Interaction model presented in [22], each iteration involves three entities: consumer, provider and target. Therefore, in general, the Cloud Customers, Cloud Users (CU), and Misusers act as consumers. CSPs can assume the roles both of consumer and provider. Service can assume all the three roles. The Resources can only act as Target. The Resources made available through the cloud federation, include hardware and system software on remote data centers, as well as services based upon these components that are accessible through the Internet. For instance, a Cloud Customer can access a Resource by using an ad-hoc Service or through a Cloud Provider interface, but he cannot gain direct access to the Resource. A CSP can offer access to Services or Resources to the Customer. An abstract representation of a scenario is reported in Fig. 3.

Figure 3. Interaction schema

4.3. Modeling Use Cases and Misuse Cases As previous described, the difference between an Use Case and a Misuse Case is mainly related to the interaction purpose between the consumer and the provider. Use Cases can model any kind of legitimate interaction scenarios that describe the application behavior. Malicious behaviors described by Misuse Cases can affect such legitimate interactions. Thus, it is important to specify security requirements to mitigate intrusions (i.e., malicious behavior performed when successful). Misuse Cases include a whole range of attacks that an hacker can independently perform to harm the cloud environment. Tables II and III report some examples of Use Cases and Misuse Cases respectively, in witch a Customer assumes the Consumer role. It is also shown how the same Use Case or Misuse Case can be associated to different scenarios. Moreover, each scenario can be implemented in different ways. An Use Case can be implemented in different ways, each one with its own weaknesses. Developers will select the specific implementation based on its weakness level. The examples in Tab. II are also helpful in clarifying what it is meant with an interaction scenario. The first Use Case example focuses on the actions performed by a Customer when he registers himself to a SaaS Provider. In this case, the CS acts as a Consumer, while the PS acts as Provider. Note that, the Target is the PS itself: the scenario has the effect of changing the set of users of the PS, enabling CS to accept future requests for different services. This Use Case can be implemented with a Web console interface, and can require a user and password authentication mechanism or, a more secure One Time Password mechanism; these two are equivalent from the functional point of view, but exhibit a different weakness level being the second more secure. Weakness levels must be preevaluated with an appropriate methodology (see [36]). The second Use Case example investigates c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

13

Table II. Use Case scenarios ID

Use Case Description

Scenario

Implementation

Weakness Level

UC1.1

First CS’s registration to PS



1

UC1.2 UC2.1 UC2.2 UC2.3

” CS creates a new Service instance ” ”

Web console with username and password Web console with OTP Web console Platform APIs REST APIs

”

”

2 1 2 3

how a CS can create a new instance of his original service. This time the Target is a Service provided by the PS. He can use a Web console or different kind of APIs provided by the PP. Table III. Misuse Case scenarioss ID

Misuse Case Description

Scenario

Implementation

Threat Level

MC1.1 MC1.2



” network architecture ” ”

File Upload Misconfiguration in the virtual

2 4

MC1.3 MC1.4 MC2.1

A injects a malicious VM ” ” ” ” A steals cryptographic key

3 3 3

MC2.2

”

”

MC2.3

”

”

PHP Injection TCP Injection Cross VM time-driven side-channel attack Cross VM trace-driven side-channel attack Cross VM access-driven side-channel attack

2 4

Several scenarios can also be associated to each Misuse Case. As represented in Fig. 4, each scenario can involve a Consumer, a Provider, and one or more Targets.

Figure 4. Misuse Case scenarios

Tab. III describes some Misuse Cases. The first example focuses on the actions performed by a Misuser (attacker), when he tries to inject a malicious Virtual Machine (VM) inside the cloud environment. In this case, the Resource is the Target and the CI acts as a Provider. The Attacker takes his first step by implementing his malicious VM in such a way that it will run on the IaaS infrastructure. The Attacker could inject also malicious services or malware. The VM can be c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

14

M. FICCO ET AL.

injected directly from an untrusted input source, or the infrastructure can be tampered by forcing the VM to be loaded from the local file system or from an external source, such an URL. Thus, the Attacker may be able to exploit flaws in the file upload mechanisms, or take advantage of some misconfiguration in the virtual network architecture offered by the CI. The attacker may reach the same goal by also performing a PHP Injection and executing malicious code on the server, or injecting malicious packets over a TCP connection. Different levels of threat can be associated to each Misuse Case pre-evaluated by using an appropriate methodology [30]. In the second example, the attacker’s goal is to steal confidential information. A research paper [29] discusses how to place a hostile VM adjacent to a target VM in an IaaS environments, and use such placement to attempt cross-VM side channel attacks to extract information from a target VM on the same hosting machine. A time-driven side-channel attack is possible when the total execution times of cryptographic operations with a fixed key are influenced by the value of the key itself. Tracedriven attacks continuously monitor some aspect of a device during cryptographic operations, such as the device’s power draw or electromagnetic emanations. In the third implementation of a sidechannel attack, the hostile program monitors the usage of a shared architectural component to learn information about the key, such as the data cache, instruction cache, floating-point multiplier, or branch-prediction cache. For each Misuse Case, a Mitigation Case can be defined, which can be implemented by one o more countermeasures (depending the Misuse Case scenario) used to mitigate the threat and enforce the security requirement. Each countermeasure is characterized by: the triple: < T hreat, Security Requirement, M itigation M echanism >, where: • Threat: specific attack or system vulnerability that we want to mitigate or prevent; • Security Requirement: specifies the security requirement to be enforced (usually derived by the SLA and the affected threat); • Mitigation Mechanism: implements the Mitigation Case (the methods, techniques and security rules to enforce the security requirement by additional features and components). Tab. IV reports some examples that clarify how countermeasures can be expressed. Depending on the Misuse Case scenario and the SLA, the security requirement to be satisfied and the mitigation mechanism that should be implemented may vary. Table IV. Mitigation Case description Misuse Scenario ID Misuse Scenario ID

Threat

Security Requirement

Mitigation Mechanism

M Cx1 .y1 M Cx3 .y3

Packet Sniffing Denial Of Service Wrapping Attack

M Cx4 .y4

footnotesizeSQL Injection

M Cx5 .y5

Man In The Middle

Confidentiality Availability Authenticity Integrity, Confidentiality Non repudiation

Routing Control Access Monitoring Digital Signature Parametrized Queries Digital Signature

M Cx2 .y2

During an UML-based design process, the developer can elicit security weakness that may compromise the specified Use Case’s Interaction. Thus, with Misuse Case scenarios he can specify malicious behaviors the cloud system should not allow. Specifically, as represented in Fig. 5, for each Misuse Case the developer can express different mitigation mechanisms to guarantee different security levels. In order to specify the Threats and the related Mitigation Mechanisms to be implemented, several formalisms can be adopted. A Threat is an attacker’s goal or what for which an attacker may act [33]. In this work, the Threat model presents the attacker’s view of the target system. It is used by the system developers to design defense mechanisms (Mitigation Mechanisms) against that view. In general, identifying system specific threats requires a more in-depth analysis of the modeled system [35]. For this purpose, Mead et al. [34] present specific threat models used for identification and prioritization of threats to be protected against. Moreover, as described in Sec. 2, several UML extensions for attack description are available in AsmLSec [16]. Similarly, several vocabularies for annotating UML-based models with information relevant to access control have been proposed by c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

15

Figure 5. Misuse Case model

[20, 18, 17, 32], whereas [15] presents UML state charts that can be automatically translated into detection rules.

5. CLOUD COMPONENT AND DEPLOYMENT DIAGRAM Use Case and Misuse Case scenarios allows designers to focus respectively on application weaknesses and attack scenarios. The final goal is to develop secure software and apply security mechanisms to mitigate or avoid unwanted behaviors. With this aim it is useful to identify the critical components and nodes in a Unified Modeling Language (UML) diagram. In order to protect the application and the system, it is important to enrich the available UML diagrams with the concepts and components that implement the Security Mechanisms identified for each Mitigation Case. The integration of UML Components and Deployment Diagrams can accurately describe the cloud environment. In order to implement the identified security solutions, the developer must be able to add components that provide countermeasures for the described threats. For example, he can add a component that provides a selective restriction of access to a service or other resource. He could also specify to pay attention for a critical link, component or node. The UML extension proposed in this section is fully aiming at supporting this work. Using such UML extension, it can be possible to integrate security related information in UML specifications. Security information is added by using stereotypes and covering many security properties, including secure information flow, confidentiality and access control. Stereotypes give a specific meaning to the elements of an UML diagram they are attached to, and they are represented by labels surrounded by double angle brackets. The goal of the extension is not to include all kinds of security properties as primitives. Instead, it focuses on those that have a comparatively intuitive and universally applicable formalization. Other properties have meanings that depend more on the context of their specific use. The idea is that these could be added by more sophisticated users on the fly. This work further extends UMLSec [17, 31] stereotypes with typical Cloud Computing security concepts. With stereotypes presented in Tab. V, developers can fill the gap between security requirements elicitation (provided with Use Case and Misuse Case scenarios), and the implementation of security mechanisms in the system. In particular, with the provided stereotypes, developers are able to: • define how to securely deploy the cloud application in the cloud environment; • specify critical links between services, software components, and different nodes within the federation; • specify security components and services to monitor their behaviors and mitigate malicious activities, by also carefully placing them within the cloud federation. Fig. 6 shows an example of what a Cloud Component and Deployment Diagram. In this scenario, a cloud application is deployed by using a Virtual Machine. In order to handle a c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

16

M. FICCO ET AL.

large number of requests the administrator provides two different instance of that VM. A Load Balancer receives requests from end-users and sorts them to the instances in order to mitigate flooding. Each service instance is provided with a Host Probe and a Network Probe component. They report information respectively from Internet traffic and log files and send them to the Intrusion Detection component. Thus, the latter receives different data from the probes and can decide if the system is under attack or not. Note that, the developer must pay attention to the link between Load Balancer and VM. He could also think about a secure protocol between the end-users and the cloud System.

Figure 6. Deployment diagram example

6. CONCLUSIONS Software security engineering entails developing software to function correctly, even in presence of malicious attacks or other hostile activities directly or indirectly affecting them. On the other hand, although the semi-formal description model have attracted a lot of attention in security engineering research, there is still a long way to their final acceptance into the requirements engineering process, especially in the context of Cloud Computing. The solution described in this paper is the first step in integrating security requirement specification into the development process of applications in federated cloud environments. In future works, our goal is to design a full methodology to develop secure cloud applications in an easy way, such that the provided security is measurable and can be monitored by cloud service providers.

REFERENCES 1. Cloud Security Alliance (CSA). Security Guidance for Critical Areas of Focus in Cloud Computing V2.1, (Released December 17, 2009). Available on-line at http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf 2. Z. Xiao and Y. Xiao, Security and Privacy in Cloud Computing. In IEEE Communications Surveys & Tutorials, vol. 15, no. 2, Second Quarter 2013, pp. 843-859. c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

MODELING SECURITY REQUIREMENTS FOR CLOUD-BASED SYSTEM DEVELOPMENT

17

3. H. Tianfield, Security issues in cloud computing. In Proc. of the IEEE Int. Conf. on Systems, Man, and Cybernetics (SMC), 2012, pp. 1082-1089. 4. M. Jensen, J. Schwenk, N. Gruschka, and L.L. Iacono, On Technical Security Issues in Cloud Computing. In Proc. of the IEEE Int. Conf. on Cloud Computing (CLOUD’09), 2009, pp. 109-116. 5. C. B. Westphall and F. R. Lamin. SLA Perspective in Security Management for Cloud Computing. In Proc. of the Int. Conf. on Networking and Services, 2010, pp. 212-217. 6. I. Gul and M. Hussain. Distributed Cloud Intrusion Detection Model. In Int. Journal of Advanced Science and Technology, vol. 34, 2011, pp. 71-82. 7. E. Ghazizadeh, J.-L.A. Manan, M. Zamani, and A. Pashang, A survey on security issues of federated identity in the cloud computing. In Proc. of theIEEE 4th Int. Conf. on Cloud Computing Technology and Science (CloudCom), 2012, pp. 532-565. 8. C. Esposito, M. Ficco, F. Palmieri, and A. Castiglione, Interconnecting Federated Clouds by Using PublishSubscribe Service, In Cluster Computing, 2013, pp. 1-17. 9. R. Matulevicius and M. Dumas, Towards Model Transformation between SecureUML and UMLsec for Role-based Access Control. In Proc. of the Int. Conf. on Databases and Information System, 2011, p. 339-352. 10. D. Basin, J. Doser, and T. Lodderstedt, Model Driven Security: from UML Models to Access Control Infrastructure. In ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 15, no. 1, 2006, pp. 39-91. 11. M. A. Hadavi, V. S. Hamishagi, H. M. Sangchi Security Requirements Engineering; State of the Art and Research Challenges In Proc. of the Int. MultiConference of Engineers and Computer Scientists, 2008, pp. 19-21. 12. Noro Atsushi and Matsuura Saeko, UML based Security Function Policy Verification Method for Requirements Specification. In Proc. of the IEEE 37th Annual Computer Software and Applications Conference (COMPSAC), 2013, pp. 832-833. 13. G. Sindre and A.L. Opdahl, Eliciting Security Requirements by Misuse Cases. In Proc. of the 37th Int. Conf. on Technology of Object-Oriented Languages and Systems (TOOLS00), IEEE CS Press, 2000, pp. 120-131. 14. J. McDermott, Abuse-case-based assurance arguments. In Proc. of the 17th Int. Conf. on Annual Computer Security Applications Conference (ACSAC), 2001, pp. 366-374. 15. M. Zulkernine, M. Graves, and M.U.A. Khan, Integrating Software Specification into Intrusion Detection. In Journal on Information Security, Springer, 2007, vol. 6, pp. 345-357. 16. M. Raihan and M. Zulkernine, AsmLSec: An Extension of Abstract State Machine Language for Attack Scenario Specification. In Proc. of the 2nd International Conference on Availability, Reliability and Security (ARES’07), IEEE CS Press, 2007, pp. 775- 782. 17. J. Jurjens, UMLsec: Exending UML for Secure Systems Development. In Proc. of the 5th International Conference on The Unified Modeling Language, LNCS, vol. 2460, 2002, pp. 412–425. Springer-Verlag. 18. T. Lodderstedt, D.A. Basin, and J. Doser, SecureUML: A UML-Based Modeling Language for Model Driven Security. In Proc. of the 5th International Conference on the Unified Modeling Language (UML’02), Springer, 2002, LNCS 2460, pp. 426-441. 19. H. Mouratidis, P. Giorgini, and G. Manson, When Security Meets Software Engineering: A Case of Modeling Secure Information Systems. In Journal of Information Systems, vol. 30, no. 8, 2005, Elsevier, pp. 609-629. 20. M. Hussein and M. Zulkernine, Intrusion Detection Aware Component-Based System: A Specification-Based Framework. In Journal of System and Software, vol. 80, no 5, 2007, Elsevier, pp. 700-710. 21. S.T. Eckmann, G. Vigna, and R.A. Kemmerer, STATL: An Attack Language for State-Based Intrusion Detection. In Journal of Computer Security, vol. 10, no. 1/2, 2002, IOS Press, pp. 71-104. 22. M. Rak, M. Ficco, E- Battista, V. Casola, and N. Mazzocca. Developing Secure Cloud Applications. In Scalable Computing: Practice and Experience, vol. 15, no. 1, March 2014, pp. 4962. 23. S. Roschke, F. Cheng, and C. Meinel, Intrusion detection in the Cloud. In Proc. of the 8th IEEE Int. Conf. on Dependable, Autonomic and Secure Computing, 2009, pp. 729-734. 24. J. Arshad, P. Townend, and J. Xu. A novel intrusion severity analysis approach for Clouds. In Future Generation Computer Systems, vol. 29, no. 1, Jan. 2013, pp. 416-428. 25. JM. Kizza. System intrusion detection and prevention. In Computer Communications and Networks, 2013, pp 271295. 26. B. Grobauer, T. Walloschek, E. Stocker. Understanding cloud computing vulnerabilities. In Security&Privacy, vol. 9, 2011, pp. 50-70. IEEE CS Press. 27. P. H. Meland, Service injection: A threat to self-managed complex systems. In Proc. of the Symposium on Dependable, Autonomic and Secure Computing, 2011, IEEE CSP, pp. 1-6. 28. F. Liu, J. Tong, J. Mao, R. Bohn, J. Messina, L. Badger and D. Leaf, NIST Cloud Computing Reference Architecture. Natl. Inst. Stand. Technol. Specification, Sep. 2011. 29. T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. In Proc. of the 16th ACM Conf. on Computer and communications security CCS’09, 2009, pp. 199-212. 30. F. Braber, I. Hogganvik, M. S. Lund, K. Stlen and F. Vraalsen, Model-based security analysis in seven steps - a guided tour to the CORAS method. BT Technology Journal, 2007. 31. J. Juerjens, Secure Systems Development with UML, Springer, 2005. 32. R. Bouaziz and B. Coulette, Secure Component Based Applications Through Security Patterns. In Proc. of the IEEE Int. Conf. on Green Computing and Communications (GreenCom), 2012, pp. 749-754. 33. F. Swiderski, W. Snyder, Threat Modeling. Microsoft Press, 2004. 34. N. R. Mead and G. McGraw, From the Ground Up: The DIMACS Software Security Workshop. In IEEE Security & Privacy, vol. 1, no. 2, 2003, pp. 59-66. 35. P. Josh and X. Dianxiang, Integrating Functional and Security Requirements with Use Case Decomposition. In Proc. of the 11th IEEE Int. Conf. on Engineering of Complex Computer Systems (ICECCS), 2006, pp. 57-66. 36. Scarfone, K., Souppaya, M., Cody, A., Orebaugh, A., Technical guide to information security testing and assessment. NIST Special Publication, vol. 800, 2008. c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe

18

M. FICCO ET AL.

Table V. Stereotype base class description Stereotype

Base class

Description

Cloud Service

Subsystem,

Critical

Encrypted

Component, Subsystem, Link Subsystem, Component Link

Service made available to users or developers on demand via the Internet from a Cloud Provider. Label a system, object or link as critical.

Fair exchange

Subsystem

Host Probe

Component

Internet

Link

Intrusion Detection System

Component

LAN

Link, Node

Load Balancer

Node Component

Network Probe

Component

No down-flow, No up-flow Provable Rbac Secure Links

Subsystem

Data security

Security Mechanism Virtual Machine Wire

Subsystem Subsystem Subsystem Component Component Node Link

Firewall

Component

Disaster Recovery

Component

Data Loss Prevention (DLP) Replica

Component

Rule

Component, Node, Subsystem

Object

c 2013 John Wiley & Sons, Ltd. Copyright ⃝ Prepared using cpeauth.cls

Enforce basic security requirements under the defined adversary model. Model an encrypted connection. It is assumed to be susceptible to message deletion by the default attackers. Enforce the fair exchange principle on communication. That is, ensure no cheating of cooperating parties. Host-based Intrusion Detection System that collects information from the host where it is installed. Internet connection. It is assumed to be susceptible to message deletion, addition and content exposure by the default attacker. IDS used to monitors network or system activities in order to detect malicious behaviors or policy violations and produces reports. “Mode” attribute specify if it is used “Standalon” as a “Probe” that collects information, or as a “Manager” that receives information and correlates them to take decisions. “Type” attribute can specify the resource to monitor: “Network”, “Host” or “Hybrid”. LAN connection or a LAN network (node). It is assumed to be unaffected by the default external attacker. Software that distributes processing and communications activity evenly across a virtual computer network so that no single virtual machine is overwhelmed. Network-based Intrusion Detection System that provides realtime network monitoring. Ensure secure information flow. Provide evidence of activities to obtain non-repudiation. Enforce Role-based access control Enforce secure communication links under the defined adversary model. Every software package added to secure other components. Resource that can be used to run applications and workloads. Wire connection. It is assumed to be unaffected by the default external attacker. System designed to prevent unauthorized access to or from a private network. Actions to minimize the negative effects of a disaster and maintain or quickly resume critical functions. System designed to detect potential data breach and prevent them by monitoring, detecting and blocking sensitive data. Data or computation replication can be adopted in order to provide fault tolerance solutions. “Mode” attribute specify the replication mechanism: “Active”, “Passive”. “Type” attribute specify different passive replicas: “Primary” and “Backup”. It defines “Attributes”, “Condition” and “Reaction” of an IDS rule. Concurrency Computat.: Pract. Exper. (2013) DOI: 10.1002/cpe