modeling security requirements for cloud‐based system development

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

Modeling Security Requirements for Cloud-based SystemDevelopment

Massimo Ficco∗1, Francesco Palmieri1, and Aniello Castiglione2

1Department of Industrial and Information Engineering, Second University of Naples, Via Roma 29, Aversa (CE), Italy2Department of Computer Science, University of Salerno, Via Ponte Don Melillo, Fisciano (SA), Italy

SUMMARY

The Cloud Computing paradigm provides a new model for the more flexible utilization of computingand storage services. However, such enhanced flexibility, that implies outsourcing the data and businessapplications to a third party, may introduce critical security issues. Therefore, there is a clear necessity ofnew security paradigms able to face with all the problems introduced by the cloud approach. Although, inthe last years, several solutions have been proposed, the implementation of secure cloud applications andservices is still a complex and far from consolidated task. Starting from these considerations, this workfosters the development of a methodology that considers security concerns as an integral part of cloud-based applications design and implementation. Accordingly, we present a set of stereotypes that defines avocabulary for annotating UML-based models with information relevant for integrating the specificationof security requirements into cloud architectures. This approach can be used to significantly improveproductivity 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/abstractCopyright c⃝ 2013 John Wiley & Sons, Ltd.

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 newbusiness model and computing paradigm, which enables on-demand provisioning of computationaland storage resources.

The Cloud Security Alliance has summarized five essential characteristics, that illustrate thetight relationships and the main differences characterizing cloud from more traditional computingparadigms, including on-demand self-service provisioning, broad network access, resource pooling,rapid elasticity, and measured service features [1]. However, economic benefits are the main driverfor cloud development due to the severe reduction of both the capital and operational expenditureconsequent 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 resultin serious cloud-specific security issues, preventing many organizations to transfer their mission-critical business into the cloud. These security issues are now the real barrier to the diffusionof Cloud Computing technologies in most of the IT-related sectors of modern society [3]. Inparticular, 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]

Copyright c⃝ 2013 John Wiley & Sons, Ltd.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 severalcyber 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/componentsand 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 securityrequirements, which have to be granted by cloud customers and cloud service providers [4]. Inthis scenario is clear that Service Level Agreement (SLA) availability and performance parametersalone are not enough to ensure the satisfaction of secure service delivery. Incorporating securityparameters in the SLAs can improve the quality of the services being offered [5]. This newrequirement may have deep implications in the security solutions to be implemented and deliveredin order to protect the services provided in the cloud [6]. Moreover, in order to cope with theresource capacity limits of a single cloud provider, as well as to address the vendor lock-in problemsassociated to the choice of a single proprietary cloud solution, the concept of federating multipleheterogeneous organizations is receiving an increasing attention by the key players in the cloudservices market, by introducing further security issues and weaknesses [7]. In fact, the effects ofattacks in a federated context may span from the loss of some data to the potential isolation ofparts of the federation [8]. Thus, protecting the federated clouds against cyber attacks becomes akey concern, since there are potentially significant economic consequences for any vulnerabilityexploited by cyber attacks.

Although security is an important aspect in information systems engineering, the literature reportsthat security concerns are often raised only when the system is about to be deployed or is already inuse [16, 9, 11, 12]. In the best cases, security is considered only during the late system developmentstages. This is a serious issue in secure system design and implementation, since the early stagesof the development process are the place where system security concerns should be discoveredand security trade-offs should be analyzed. An approach to guide such an analysis is suggested bymodel-driven security [10]. In particular, due to the complexity of the modern cloud-based systemsand applications and to the ease with which they can be compromised, it becomes fundamentalto 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 implementingsecure software applications alone, developers also need to ensure these applications to run onsecure cloud infrastructures, by protecting data they handle and adopting all kind of availablesecurity mechanisms to provide confidentiality, integrity and robustness in their communicationfrom the cloud sites to the users and vice versa. All these issues become fundamental non-functionalrequirements that must be considered in every phase of the software development life cycle, startingfrom 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 applicationand/or system in mind. Therefore, in order to propose an appropriate security specification languagefor cloud system design, at first we present a perspective of the most popular security specificationlanguages found in the literature, with the purpose of individuating the best starting point choicesfrom the options already available. Then, we propose an approach which shows how developers canidentify and enforce, from the very early stages of development, the security requirements to beoffered by the application and services to cloud users.

Stereotypes are provided to extend UML diagrams and easily describe a cloud system with allits peculiarities. The presented UML-based meta-model can be used by cloud customers, as well ascloud service providers to develop services and applications offered to their end-users at differentcloud stack levels, including IaaS, PaaS and SaaS.

The remainder of the paper is organized as follows. The related experiences available in literatureis presented in Sec. 2. Some of the most significant security challenges that need to be addressedin Cloud Computing are presented in Sec. 3. The modeling approach is presented in Sec. 4. Theproposed stereotypes for annotating UML based models with information relevant for integratingthe specification of security requirements into cloud-based systems are presented in Sec. 5. Finally,conclusions and lessons learned are presented in Sec. 6.

Copyright c⃝ 2013 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. (2013)Prepared using cpeauth.cls 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 foundin the literature. Every tool is explained in its essential features, followed by a comparison thatunderlines 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 thatrepresent entities outside a system interacting with it in some way.

Misuse cases specify behaviors not wanted in the proposed system for the purpose of elicitingsecurity requirements [13]. A Misuser is an actor that initiates misuse cases, either intentionallyor inadvertently. In a Use Case diagram, in addition to Actors and Use cases, the security modelintroduces 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 therequirements specification. The essence of a Misuse Case is usually captured in the associatedtextual description. A lightweight Misuse Case description extends the regular Use-Case templatewith a field called Threats. In this field, it is possible to specify one or more security issues and thepossible 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 toaccomplish the harm intended by the abusing actor [14]. Unlike Misuse Cases, the Abuse Casediagram is kept separated from the Use Case one, so that we can distinguish the two by labelingthe diagrams. In an Abuse Case, a more detailed description of the involved actors is given. Threecharacteristics 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 waysthat the Abuse Case may be accomplished. The diagram must be read like a decision tree, with eachpath 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 threatsand then requirements, without going into design. They can be made simple and abstract enoughto be understood by users from a wide range of application domains. They can be used to showcustomers 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 identifiablemalicious actor. These diagrams inform developers only about which security-related informationthey should specify and not about how and when to do so. They say nothing about how the securityrequirements process is related to other software development activities. These models are not asubstitute for mathematical security models. Finally, Misuse Cases and Abuse Cases are ambiguousand 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 byMicrosoft, defining abstract state machines through a fairly high-level language that can becompiled into executable code. The syntax of AsmL is similar to a procedural programminglanguage. The language has variables, methods, classes and supports object-oriented features, suchas instances and inheritance. On the other hand, State Charts, one of the diagram types availablein UML, are based on extended finite state machines and some of their important constituents arestates, transitions, conditions, actions, and events. Zulkernine et al. [15] presented a method forintegrating AsmL and Unified Modeling Language (UML) state charts, that are extended finite state


4 M. FICCO ET AL.

machine-based software specification languages, with the Snort open source Intrusion DetectionSystem (IDS). Snort is a network IDS that sniffs network traffic packets and uses rules from adatabase of attack signatures to detect any attack packet. The attack scenarios are specified in AsmLor UML state charts, and then, automatically translated into Snort rules, which retain the contextinformation present in AsmL and UML state chart scenarios. The Snort’s detection engine is thanmodified 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 attacksthat have multiple steps. In fact, by using basic attacks multiple times within a specific period oftime it is possible to specify most of the coordinated attacks. A similar situation can be observed inpresence of different types of basic attacks. For this reason it is possible to use context informationin AsmL or UML state charts to allow representation of more complex and coordinated attackscenarios, which could not be specified by using simple Snort rules. Even if the Snort IDS is nonused, this work is helpful because it shows how to adopt a software specification language likeAsmL to specify attack scenarios and how to avoid harms.

However, AsmL and UML State Charts are not natively conceived for describing attack scenariosand hence do not provide functions for that purpose.

AsmLSec

In order to have a specification languages that can be used for both functional and securityspecification, 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 attackspecification. However, AsmL was intended to be used for modeling, analyzing, and prototypingof components and protocols. It is appropriate for capturing the abstract structure and discretebehavior of the software with several degrees of detail. Therefore, AsmL lacks a number offeatures required to represent attack scenarios available in attack languages. AsmLSec is meant toincorporate 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. Transitionsare labeled with system events that cause changes from one state to another. A state transition cantake place only if certain conditions associated with the transition are satisfied. The system eventsneed to take place in a certain order so as to make an attack successful. These temporal relationshipsamong system events are modeled in AsmLSec attack specifications. An alert is generated whenthe system reaches a state under attack.

Even if AsmLSec provides a quite rich syntax that facilitates writing attack signatures, thelanguage suffers from some limitations, the most significant of which is not supporting regularexpressions. In fact, attack patterns, when expressed by using regular expressions are more genericand 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 knowledgeencapsulated in a widely used design notation. To understand the offered potentialities let usconsider a number of subsystem diagrams S describing different parts of a system. In order to definethe security requirements for each diagram, we need to model potential adversary behavior. Theadversaries can attack different parts of the system in a specified way. We can assume a functionThreats 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 inthe 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



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

SecureUML

SecureUML is a modeling language that defines a vocabulary for annotating UML-basedmodels with information relevant to access control [18]. The language builds the access controlmodel for role-based access control (RBAC) with additional support for specifying authorizationconstraints. Simple policies can be expressed by using role-based permissions, and morecomplicated requirements can be specified by adding authorization constraints. SecureUML canbe used in the context of a model-driven software development process to generate access controlinfrastructures. In this way, productivity during the development and the quality of the resultingsystems can be improved.

However, this model focuses only on access control problems, and it is not suitable to be usedfor a security specification language that can cover all different kind of security issues.

Secure TroposTropos is a development methodology specifically tailored to describe both the organizationalenvironment of a system and the system itself. It deals with all the phases of system requirementsanalysis 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 specificationof the perspective requirements, emphasizing the need of understanding how and why the intendedsystem 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 natureof an agreement between dependee and depender. Goal dependencies represent delegation ofresponsibility for fulfilling a goal; softgoal dependencies are similar to goal dependencies, buttheir fulfillment cannot be defined precisely; task dependencies are used in situations where thedependee is required to perform a given activity; and resource dependencies require the dependeeto provide a resource to the depender.

Tropos was not conceived with security on mind, thus Mouratidis et al. [19] proposed a set ofsecurity concepts, such as security constraint, secure entities and secure dependencies enabling it toconsider security aspects throughout the whole development process. A security constraint is definedas a restriction related to security issues, such as privacy, integrity and availability, of an informationsystem. It can influence the analysis and design of the system under development by restrictingsome alternative design solutions, by conflicting with some of the requirements of the system, orby refining some of the system’s objectives. A secure entity represents a secure goal, a secure taskor a secure resource. During the early requirements analysis stage, the goals, dependencies and thesecurity 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 linksbetween 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 toguarantee the security constraints are identified. The architectural design phase defines the system’sglobal architecture. During the detailed design each component of the system, identified in theprevious stages, is further specified by using AUML diagrams, such as Capability Diagrams orAgent Interaction Diagrams.


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 diagramsused in UMLintr are called misuse-case, misuse-package, misuse-class, and misuse-state-machinediagrams. Use-case diagrams provide an abstract view of the services provided by the software. InUMLintr, each misuse-case diagram consists of an << attacker >> actor and a << victim >>actor connected to a use-case representing the exploitation method. << socialengineering >>represents instances where the attacker convinces the user to give out critical security information;<< implementationbug >> represents instances where an implementation bug in the softwareis exploited by the attacker; << misconfiguration >> is used for attacks where the attackerexploit a misconfiguration in the system policy; << abusefeature >> is used for attackswhere the attacker abuses a feature provided by the system. Misuse-package diagrams groupinto similar packages intrusion scenarios which share common properties. A package labeledwith << DOS >> contains scenarios for denial of service intrusions. << RemoteToUser >>packages contains intrusion scenarios where remote attackers gain access with local user privileges.<< UserToRoot >> denotes packages where users with local privileges gain root privileges.<< Probe >> denotes packages where attackers try to gather information about machines on thenetwork to find their vulnerabilities. A Misuse-class diagram is represented by a box containingclass stereotype and name, tagged values, data and functions. Three stereotyped classes areintroduced: << attacker >>, << victim >>, and << intrusion >>. Each stereotype has itsown tagged values that present security related information. Misuse-state-machine diagrams areused to specify the detection of intrusion scenarios. Each misuse-state-machine represents thestates which its corresponding attack may go through. Developers create new states representingdifferent 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 canhave instructions to be executed after triggering the transition. Developers may choose to adda guard condition to the transition which must be true before its corresponding transition cantake place. The final state of each diagram marks a successful penetration. Component diagramsshow the system as being composed of different components. UMLintr extends this view with an<< IntrusionDetection >> stereotype presenting a component that offers intrusion detectionservices for other components. This UMLintr-based tool can be used for modeling components,specifying intrusion scenarios, and producing intrusion signatures, which can be employed byspecial UMLintr-based IDS to automatically detect intrusions. However, exploring how to specifyand handle other security requirements like authentication, authorization, and integrity must extendUMLintr.

STATL

STATL is an extensible state/transition-based attack description language designed to supportintrusion detection [21]. The language allows the description of security violations as sequencesof actions that an attacker performs to compromise a computer system. The STATL language hasbeen successfully used in describing both network-based and host-based attacks, and it has beentailored to very different environments. Moreover, this methodology supports a modeling approachthat represents only those steps in intrusion that are necessary for ensuring the effectiveness of theattack. By abstracting away from the details of a particular attack, it is possible to detect previouslyunknown variations of an attack or attacks that exploit similar mechanisms. The STATL languageprovides constructs to represent an attack as a composition of states and transitions. States are usedto characterize different snapshots of a system during the evolution of an attack. The state assertionis tested before entering into a state and then the specific state’s code block is executed. A transitionconnects two states each other and has an associated action that is a specification of the event thatmay cause the move to a new state. The language is rigorous, that is, it has a precise syntax and a



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 noone 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 CloudComputing [22]. An Interaction is defined as every kind of data exchange among actors in a cloudsystem. Each Interaction is specified by the triple < Consumer, Provider, Target >, where:

• Consumer: initiates the interaction and sends all the necessary information to process therequest;

• 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 Interac-tion can be implemented in different modalities. Developers will select the right modality to imple-ment according to its security level and available mechanisms/features. Each Interaction modality ischaracterized by: the triple: < Threat, Security Requirement, Security Mechanism >, 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 mechanismthat should be adopted may vary. A conceptual view of a Use Case representation is reported inFig. 1. In particular, to each Use Case can be associated a set of critical interactions, which can beimplemented 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 currentproposal.


8 M. FICCO ET AL.

Summary of contributions

Each analyzed language has its own advantages and disadvantages. Tab. I attempts to summarizethe presented languages.

Table I. Secure specification languages comparison

Language Class Main Advantages Main Disadvantages

Misuse Cases Security requirement; Simple to be understood; Not a substitute forand Specification language. Abstract enough to define formal security models.

Abuse Cases various security requirements;Similar to UML Use

Case diagram.AsmL and UML Specification language Same language for functional Insufficient function for

State Chart used to specify and security requirements; describing attack scenarios.attack scenarios. Possibility to convert attach

scenarios into Snort rules.AsmLSec Security requirement; Extend AsmL with a rich set Documents can be understood

Attack description language. of syntax for attack signatures; only to security experts;Same language for functional Does not support

and security requirements. regular expressions.UMLSec Security requirement; UML extension; Focused only on validating

Specification language. Easy to implement. security propertiesand mechanisms.

SecureUML Security requirement; UML extension; Focused only on accessSpecification language. Easy to implement. control policies.

Secure Tropos Security requirement; Simple to be understood; Visual complexity of the diagrams;Specification language. Security is defined in Low spread of

different levels of complexity. Tropos comparing to UML.UMLintr Attack description UML extension; Not suitable for authentication,

language. Security is defined in authorization, anddifferent levels of complexity. integrity requirements.

STATL Attack description Used in describing both Documents can belanguage. network- and host-based attacks; understood only to

Attack described only in security experts;its necessary steps. Focused on IDS.

Interation Model Security requirement; Used in describing Focused only onSpecification language. security mechanisms service interations.

offered by CSPto cloud customers.

3. CLOUD SYSTEMS CHARACTERISTICS AND SECURITY CHALLENGES

Although all the options presented in the previous section have been proposed to specify securityrequirements, apart [22], no one of them was conceived to cope with the elasticity of cloudfederation model [23]. In general, achieving a satisfactory degree of security for applicationsand 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, anapplication is composed of several software components, which run on distributed virtual nodes



hosted by different cloud service providers (CPSs) participating to the federation. Therefore, somechallenges that need to be addressed during development and deployment of security solution forcloud federation scenarios, include:

• In traditional distributed systems, due to the static nature of the monitored infrastructure, thesecurity policies tend to be static, or at least rarely change over time. In a cloud federationinfrastructure, the monitored virtual networks and nodes, that host the customer applicationsand services, are dynamically changed, added, and removed, and their security requirementstend 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 maliciouscustomers or applications running on a federated cloud [25].

• With the emerging federated cloud paradigm, where services are composed of several otherservices 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 theother ones involved in the service composition. Assuring the customer that adequate securitymechanisms exist and are correctly implemented throughout the whole chain of providers willtherefore be a hard challenge.

• The federated cloud concept will require services to be composed dynamically in a moreautonomous and ad-hoc manner over a shared infrastructure. This opens the door to a widerange of new threats, such as hijacking service components, forming compositions based onboth legitimate and illegitimate service components, and injecting malicious services intootherwise legitimate service compositions [27, 26].

• In the cloud, the service provider’s system administrators often have unlimited access tothe customer data and applications, which implies that illegitimate tampering or usage ofcustomer property may easily go undetected. From the customers’ perspective, the use offederated cloud services implies an increased risk; achieving control over who can accessand alter the customer data will be extremely difficult. Also, in contrast to the traditional ITsystem context, mutual auditability is a security issue new to Cloud Computing, since boththe 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 tocontrol 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 organizationsmay make things worse by introducing new “grey zones” characterized by lack of control andauditability.

Both CPSs and customers will benefit significantly if there is a comprehensive protection solutionthat evolves on the base of their requirements. Carefully, modeling these security requirementswithin the cloud system design process may be also helpful in filling the gap between the concreteuser requirements and the more abstract and formal problem of representing them within the contextof software engineering practices. Nevertheless, by considering these requirements by starting fromstrong and clear formalisms when designing cloud-based software architectures can significantlyinfluence the final system behavior, and hence is overall success and quality, especially concerningnon-functional and difficult to hand aspects like security. Therefore, proposing a new defensestrategy that considers the different cloud security requirements from scratch, by starting from theearlier 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-basedmodels with information relevant to prevent cyber attacks against applications and services deployedin federated clouds. Some stereotypes have been inherited from models presented in the literatureand adapted to the design strategy proposed in this work. Such strategy is based on the followinglogical steps:


10 M. FICCO ET AL.

1. Required behaviors of the application are identified and modeled with Use Cases. They aredescribed by using interaction scenarios, which represent the interactions in terms of orderedset 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 toelicit malicious behaviors (threats) by interaction scenarios. By using Misuse Cases, potentialattacks 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 thatmay 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 deploymentof the involved application components in the federated environment. It is also possible toenrich the diagram by adding new formalisms necessary to describe the countermeasures forthe 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 highlevel, in which also security requirements should be preserved.

Therefore, during the representation of the application requirements specification, whereas UseCases specify general requirements, Misuse Cases can be added in order to specify behaviorsnot wanted in the analyzed system, performed for the purpose of eliciting user requirements. Asrepresented in Fig. 2, Use Cases are abstract episodes of interaction between the system and one ormore cloud users or customers, Misuse Cases represent security threats for Use Cases. A Misusercan 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, specificcountermeasures can be defined to mitigate the threats. In particular, Mitigation Cases represent thesecurity requirements to be implemented in order to mitigate Misuse Cases. An extensive MisuseCase description is presented in [13].

Figure 2. Use and Misuse Cases metamodel



4.2. Actors and Roles

The proposed model aims at describing both wanted and unwanted behaviors. The differencebetween a Use Case and a Misuse Case is mainly related to the interaction purposes. Use Casescan 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 thefederation if the sequence is successful. According to the proposed approach, Use Cases and MisuseCases can be described as interaction scenarios. The advantage of using the interaction scenarios isthat 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 CloudService Provider, as well as a Misuser that tries to harm the cloud application or system. Inparticular, the Cloud Customer is the principal stakeholder for the cloud federation services needingthe establishment of proper SLAs to specify the technical performance requirements regarding thequality, security, and remedies for performance degradation and failures, associated to the servicesto be implemented and offered to their end-users. Depending on the services requested, activitiesand usage scenarios, there will be different Cloud Customers:

• SaaS Customers (CS) can be organizations that provide their members with access to softwareapplications, as well as customers of a federated cloud who use a service offered by otherfederated cloud, or software application administrators who configure applications for endusers.

• PaaS Customers (CP) can be developers who design and implement software applications,testers who run and test applications in the federated environment, deployers who publishapplications into the federation, and administrators who configure and monitor applicationperformance on a specific platform.

• IaaS Customers (CI) have access to virtual computers, network-accessible storage, networkinfrastructure components. They can be system developers, system administrators and ITmanagers who are interested in creating, installing, managing and monitoring servicesspecifically deployed for IT infrastructure operations.

The CSP is the entity responsible for making a service available to the interested parties. It acquiresand manages the computing infrastructure of the federation required for providing the services, runsthe cloud software that provides the services, and makes arrangement to deliver the cloud servicesto 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 thecloud infrastructure, so that the services are provisioned according to the expected servicelevels to Cloud Customers.

• PaaS Providers (PP) manage the computing infrastructure at the platform-layer and run thecloud software that provides the components of this platform, such as runtime softwareexecution stacks, databases, and other middleware components. They provide tools suchas 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 theservice, including the servers, networks, storage, hosting infrastructure and provide a set ofservice interfaces and computing resource abstractions, such as virtual machines and virtualnetwork interfaces.

To be more comprehensive, the National Institute of Standards and Technology (NIST) defines otherthree actors [28]:

• Cloud Auditors (CA), third party organizations or individuals that can conduct independentassessment of cloud services, information system operations, performance and security of thecloud 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.


12 M. FICCO ET AL.

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

The other entities involved in the scenarios are Misusers (M), Services (S) which refer to allkind 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), andMisusers act as consumers. CSPs can assume the roles both of consumer and provider. Service canassume all the three roles. The Resources can only act as Target. The Resources made availablethrough the cloud federation, include hardware and system software on remote data centers, as wellas services based upon these components that are accessible through the Internet. For instance, aCloud Customer can access a Resource by using an ad-hoc Service or through a Cloud Providerinterface, but he cannot gain direct access to the Resource. A CSP can offer access to Services orResources 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 relatedto the interaction purpose between the consumer and the provider. Use Cases can model anykind of legitimate interaction scenarios that describe the application behavior. Malicious behaviorsdescribed by Misuse Cases can affect such legitimate interactions. Thus, it is important to specifysecurity 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 harmthe cloud environment.

Tables II and III report some examples of Use Cases and Misuse Cases respectively, in witch aCustomer assumes the Consumer role. It is also shown how the same Use Case or Misuse Case canbe 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. Developerswill 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 registershimself 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 witha Web console interface, and can require a user and password authentication mechanism or, a moresecure 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 pre-evaluated with an appropriate methodology (see [36]). The second Use Case example investigates



Table II. Use Case scenarios

ID Use Case Description Scenario Implementation Weakness Level

UC1.1 First CS’s registration to PS <CS,PS,PS> Web console with username 1and password

UC1.2 ” ” Web console with OTP 2UC2.1 CS creates a new Service instance <CS,PS,S> Web console 1UC2.2 ” <CS,PP,S> Platform APIs 2UC2.3 ” ” REST APIs 3

how a CS can create a new instance of his original service. This time the Target is a Service providedby 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 A injects a malicious VM <M,PI,R> File Upload 2MC1.2 ” ” Misconfiguration in the virtual 4

” network architectureMC1.3 ” ” PHP Injection 3MC1.4 ” ” TCP Injection 3MC2.1 A steals cryptographic key <M,CI,R> Cross VM time-driven 3

side-channel attackMC2.2 ” ” Cross VM trace-driven 2

side-channel attackMC2.3 ” ” Cross VM access-driven 4

side-channel attack

Several scenarios can also be associated to each Misuse Case. As represented in Fig. 4, eachscenario 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 bya Misuser (attacker), when he tries to inject a malicious Virtual Machine (VM) inside the cloudenvironment. In this case, the Resource is the Target and the CI acts as a Provider. The Attackertakes his first step by implementing his malicious VM in such a way that it will run on the IaaSinfrastructure. The Attacker could inject also malicious services or malware. The VM can be


14 M. FICCO ET AL.

injected directly from an untrusted input source, or the infrastructure can be tampered by forcingthe VM to be loaded from the local file system or from an external source, such an URL. Thus, theAttacker may be able to exploit flaws in the file upload mechanisms, or take advantage of somemisconfiguration in the virtual network architecture offered by the CI. The attacker may reachthe 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 toeach 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 toplace a hostile VM adjacent to a target VM in an IaaS environments, and use such placementto attempt cross-VM side channel attacks to extract information from a target VM on the samehosting machine. A time-driven side-channel attack is possible when the total execution timesof cryptographic operations with a fixed key are influenced by the value of the key itself. Trace-driven attacks continuously monitor some aspect of a device during cryptographic operations, suchas the device’s power draw or electromagnetic emanations. In the third implementation of a side-channel attack, the hostile program monitors the usage of a shared architectural component to learninformation about the key, such as the data cache, instruction cache, floating-point multiplier, orbranch-prediction cache.

For each Misuse Case, a Mitigation Case can be defined, which can be implemented byone o more countermeasures (depending the Misuse Case scenario) used to mitigate the threatand enforce the security requirement. Each countermeasure is characterized by: the triple: <Threat, Security Requirement,Mitigation Mechanism >, 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 onthe Misuse Case scenario and the SLA, the security requirement to be satisfied and the mitigationmechanism that should be implemented may vary.

Table IV. Mitigation Case description

Misuse Scenario ID Threat Security Requirement Mitigation MechanismMisuse Scenario ID

MCx1.y1 Packet Sniffing Confidentiality Routing ControlMCx2.y2 Denial Of Service Availability Access MonitoringMCx3.y3 Wrapping Attack Authenticity Digital SignatureMCx4.y4 footnotesizeSQL Injection Integrity, Confidentiality Parametrized QueriesMCx5.y5 Man In The Middle Non repudiation Digital Signature

During an UML-based design process, the developer can elicit security weakness that maycompromise the specified Use Case’s Interaction. Thus, with Misuse Case scenarios he can specifymalicious behaviors the cloud system should not allow. Specifically, as represented in Fig. 5, foreach Misuse Case the developer can express different mitigation mechanisms to guarantee differentsecurity levels.

In order to specify the Threats and the related Mitigation Mechanisms to be implemented, severalformalisms can be adopted. A Threat is an attacker’s goal or what for which an attacker mayact [33]. In this work, the Threat model presents the attacker’s view of the target system. It isused by the system developers to design defense mechanisms (Mitigation Mechanisms) against thatview. In general, identifying system specific threats requires a more in-depth analysis of the modeledsystem [35]. For this purpose, Mead et al. [34] present specific threat models used for identificationand prioritization of threats to be protected against. Moreover, as described in Sec. 2, several UMLextensions for attack description are available in AsmLSec [16]. Similarly, several vocabularies forannotating UML-based models with information relevant to access control have been proposed by



Figure 5. Misuse Case model

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

5. CLOUD COMPONENT AND DEPLOYMENT DIAGRAM

Use Case and Misuse Case scenarios allows designers to focus respectively on applicationweaknesses and attack scenarios. The final goal is to develop secure software and apply securitymechanisms to mitigate or avoid unwanted behaviors. With this aim it is useful to identify the criticalcomponents and nodes in a Unified Modeling Language (UML) diagram. In order to protect theapplication and the system, it is important to enrich the available UML diagrams with the conceptsand components that implement the Security Mechanisms identified for each Mitigation Case.

The integration of UML Components and Deployment Diagrams can accurately describe thecloud environment. In order to implement the identified security solutions, the developer must beable to add components that provide countermeasures for the described threats. For example, hecan 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 extensionproposed in this section is fully aiming at supporting this work. Using such UML extension, it canbe possible to integrate security related information in UML specifications. Security informationis added by using stereotypes and covering many security properties, including secure informationflow, confidentiality and access control. Stereotypes give a specific meaning to the elements ofan UML diagram they are attached to, and they are represented by labels surrounded by doubleangle brackets. The goal of the extension is not to include all kinds of security properties asprimitives. Instead, it focuses on those that have a comparatively intuitive and universally applicableformalization. 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 Computingsecurity concepts. With stereotypes presented in Tab. V, developers can fill the gap betweensecurity requirements elicitation (provided with Use Case and Misuse Case scenarios), and theimplementation 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 thisscenario, a cloud application is deployed by using a Virtual Machine. In order to handle a


16 M. FICCO ET AL.

large number of requests the administrator provides two different instance of that VM. ALoad Balancer receives requests from end-users and sorts them to the instances in order tomitigate flooding. Each service instance is provided with a Host Probe and a Network Probecomponent. They report information respectively from Internet traffic and log files and sendthem to the Intrusion Detection component. Thus, the latter receives different data from theprobes and can decide if the system is under attack or not. Note that, the developer must payattention to the link between Load Balancer and VM. He could also think about a secureprotocol 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 ofmalicious 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 engineeringresearch, 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 requirementspecification into the development process of applications in federated cloud environments. In futureworks, 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, (ReleasedDecember 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.



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 theInt. 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 andTechnology, 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 thecloud 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 Publish-Subscribe Service, In Cluster Computing, 2013, pp. 1-17.

9. R. Matulevicius and M. Dumas, Towards Model Transformation between SecureUML and UMLsec for Role-basedAccess 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 ResearchChallenges 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 RequirementsSpecification. 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. onTechnology 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 SecurityApplications Conference (ACSAC), 2001, pp. 366-374.

15. M. Zulkernine, M. Graves, and M.U.A. Khan, Integrating Software Specification into Intrusion Detection. InJournal 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 ScenarioSpecification. 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 Conferenceon 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 DrivenSecurity. 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 ModelingSecure 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-BasedFramework. 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 ScalableComputing: 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. onDependable, 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 GenerationComputer 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 271-295.

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 onDependable, 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 ReferenceArchitecture. 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 InformationLeakage in Third-Party Compute Clouds. In Proc. of the 16th ACM Conf. on Computer and communicationssecurity 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 - aguided 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.


18 M. FICCO ET AL.

Table V. Stereotype base class description

Stereotype Base class Description

Cloud Service Subsystem, Service made available to users or developers on demandvia the Internet from a Cloud Provider.

Critical Component, Label a system, object or link as critical.Subsystem, Link

Data security Subsystem, Enforce basic security requirementsComponent under the defined adversary model.

Encrypted Link Model an encrypted connection. It is assumed to be susceptibleto message deletion by the default attackers.

Fair exchange Subsystem Enforce the fair exchange principle on communication.That is, ensure no cheating of cooperating parties.

Host Probe Component Host-based Intrusion Detection System that collects informationfrom the host where it is installed.

Internet Link Internet connection. It is assumed to be susceptible to message deletion,addition and content exposure by the default attacker.

Intrusion Detection Component IDS used to monitors network or system activitiesSystem 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 Link, Node LAN connection or a LAN network (node).

It is assumed to be unaffected by the default external attacker.Load Balancer Node Software that distributes processing and communications activity

Component evenly across a virtual computer network so thatno single virtual machine is overwhelmed.

Network Probe Component Network-based Intrusion Detection System thatprovides realtime network monitoring.

No down-flow, Subsystem Ensure secure information flow.No up-flow

Provable Subsystem Provide evidence of activities to obtain non-repudiation.Rbac Subsystem Enforce Role-based access control

Secure Links Subsystem Enforce secure communication links underComponent the defined adversary model.

Security Mechanism Component Every software package added to secure other components.Virtual Machine Node Resource that can be used to run applications and workloads.

Wire Link Wire connection. It is assumed to be unaffectedby the default external attacker.

Firewall Component System designed to prevent unauthorizedaccess to or from a private network.

Disaster Recovery Component Actions to minimize the negative effects of a disaster andmaintain or quickly resume critical functions.

Data Loss Component System designed to detect potential data breach andPrevention (DLP) prevent them by monitoring, detecting and blocking sensitive data.

Replica Component, Node, Data or computation replication can be adopted in order toSubsystem provide fault tolerance solutions. “Mode” attribute specify

the replication mechanism: “Active”, “Passive”. “Type” attribute specifydifferent passive replicas: “Primary” and “Backup”.

Rule Object It defines “Attributes”, “Condition” and“Reaction” of an IDS rule.
