Security Patterns for Local Assurance in Cloud Applications

Security Patterns for Local Assurance in Cloud Applications

University of Malaga, Proteus Malaga, Spain

{marcos, joseruiz, amg}@lcc.uma.es Abstract

Development of cloud applications demands a high level of expertise, knowledge and skills to make good use of the flexibility, efficiency and scalability of cloud resources. Security, in particular, is one of the most important disciplines due to the extensive level of knowledge required. In order to improve systems with adequate design decisions about security, engineering approaches become critical in order to manage the security elements. The CUMULUS engineering process addresses this problem providing a modelling framework for supporting the design of cloud applications, relying in Security Patterns, which are a proven mechanism to define the necessary architecture for fulfilling security requirements.

Keywords: Security Engineering Process; Security Certification; Security in the Cloud; Security Patterns; Modeling; Security Design

1. Introduction

Development of cloud applications demands a high level of expertise, knowledge and skills to produce reliable software, but to obtain high quality software developers have also to take advantage of the flexibility, efficiency and scalability of cloud services and putting all the efforts in a good use of the distributed and heterogeneous cloud resources. In order to deal with such a compendium of decisions, characteristics and, functionalities, developers and system engineers use different approaches and methodologies to improve their designs and guide their software development. These techniques are usually very limited and they require from users the responsibility to know and follow the specifications and guidelines of cloud providers in order to integrate, use their services and enhance their cloud applications. In this context, security is one of the most risky disciplines due to the extensive and complicated knowledge involved. Security information is an evolving issue. New threats are discovered daily and engineers have to guarantee the best security level at all expenses.

Therefore, security engineering approaches become more critical and suitable by bringing precise mechanisms and by assisting users in the complex task of managing security elements. The CUMULUS engineering process addresses this problem by providing a modeling framework to support design decisions in the development of cloud applications. This methodology relies in Computer-Oriented Security Patterns (COSPs), which are a new kind of machine-processable security patterns. COSPs provide security properties that fulfill the security requirements of the system in a way that facilitates their use and integration in system design models. Therefore, when developers use the CUMULUS framework for fulfilling security requirements of their cloud applications they receive

tailored security knowledge for their systems and an adequate collection of COSPs to be used in their designs that solve the security concerns.

This paper is structured as follows: Section II presents the related work, Section III presents the CUMULUS Engineering Process, which is divided in four subsections: the first one is dedicated to the gathering of security knowledge; the second one describes our approach to develop cloud applications; the third one presents the differences between security requirements and certification requirements and the last one describing the necessity of a great approach to deal with solutions. Section IV describes the CUMULUS-aware Security Patterns. And, finally, Section V presents the conclusions and the ongoing work.

2. Related Work

This paper argues the complexity involved in the process of integrating security mechanisms in cloud applications. This challenging task is aligned in the goal of the CUMULUS EU project [1], providing mechanisms to solve security requirements by means of a database of security knowledge and artifacts. Therefore, framed under the scope to provide a complete security engineering process, there are three different expertise areas involved: i) the knowledge engineering to capture all the required data, ii) the requirements engineering

to establish the proper approach to analyze security risks and manage these concerns and 3) the security patterns used to guide the integration and realization of the security mechanisms.

Security knowledge is a vast compendium of expertise, ideas and elements that generates an intricate net of related data and multiple dependencies. That way, several proposals have been created to address the gathering of such information and relations. The two more representative are differentiated by the methodology they use for storing the security knowledge, whether using a metamodel approach or an ontology one. Both alternatives represents valid mechanisms and each one offers great advantages over the other. The usage of ontologies [2] is very popular due to the reusability of knowledge in the semantic web in order to collect the security information, using domain-independent engineering such as OWL ontologies [3] and RDF graphs. More specifically for software engineering, many ontology proposals have emerged for fulfilling the great quantity of security elements, rules and actions that have to be considered for engineering knowledge representation. Many of them can be merged into a higher level ontology that abstracts the categories that crosscut different engineering domains [4]. On the other hand, metamodel-based approaches, usually created using UML [5], have become powerful alternatives

because they can be easily adopted by developers of engineering processes.

In the search for the most suitable methodologies for cloud developers in the context of security requirements engineering we can find approaches such as the IRIS metamodel [6], which demonstrate the viability of these modelling artefacts for all the activities involved in the risk analysis and security management of software development. Moreover, the sustainability of a high assurance level demands not only the understanding of security technologies and mechanisms but also the related principles and concepts involved in the design of secured systems. Multiple quality factors are crucial in the security requirements engineering [7] and many of them evolve [8], change and cause dependencies hard to express by means of ontologies. Even with metamodels, the design of a suitable and complete methodology represents a challenging task. Therefore, all this complexity usually manifests itself in a vast collection of frameworks [9] and approaches to cover the multiple considerations, pros and cons of security requirement engineering dealing with security knowledge.

Security Patterns (SPs) have been a useful practice for software development in order to create designs relying in the same architectural diagram or scenarios with shared components. Unfortunately, nowadays they are not a solid alternative to be considered in current designing processes. Previous experiences with SPs [10] aim to integrate security aspects and solutions in the system design stage by means of security and reusable security libraries. Besides, several exploitation security engineering processes have been emerging in order to give SPs the worthy reputation they deserve such as the SCRIP (SeCurity pattern Integration Process) [11] based on metamodels and UML profiles; or the SEPP (Security Engineering Process using Patterns) [12], addressing functional security requirements from the SPs perspective.

A recent trend to integrate SPs in security engineering processes extends and wraps the capabilities of these artifacts by providing mechanisms to be automatically managed by modelling frameworks and tools, improving the accessibility of the security knowledge contained in SPs to be extracted and used with different engineering purpose. The COSPs (Computer-Oriented Security Patterns) [13] widely describes this new paradigm with the virtues and advantages of this proposal. Framed in a Security Engineering Process several successful attempts shows the potential of this line of work and the great adaptation to multiple environments, even with different abstraction levels such as embedded systems, securing a system of metering devices [14] or a complex approach, designing the architecture of a business production office, guaranteeing the assurance of the component interaction and coordination of a System of Systems [15].

3. CUMULUS Engineering Process

This section presents the CUMULUS Engineering Process (CEP) describing its artifacts and functionalities. This comprehensive methodology can be fully reviewed in [16] and, therefore, we are going to present just the most related and interesting part of the process within the scope of this paper. The multilayered architecture of the CEP is composed of

several security artifacts interacting between each other in order to become a unique methodology as a whole. One of these security artifacts are the COSPs, and to dig into their reason in the overall process we have to describe why the previous modeling stages of the CEP requires an artifact with such features as the ones provided by the COSPs. This Section enumerates the different actions where these artifacts are required and leaves the details of what is the composition of a SP to Section IV.

3.1 Cloud Security Knowlege

As the aforementioned introduction states, the development of cloud applications is not an easy task but it is affordable. One of the most important goals of the CEP is to support the creation of cloud applications by providing adequate security design decisions. Therefore, an essential mission of the procedure is how to collect the security knowledge and how much is necessary. In order to accommodate this functionality, the CEP and the modeling framework provide to Cloud Security Experts (CSE) support for capturing security elements and represent it in a structured way, having to overcome a number of assessment criteria. Thereby, the CEP establishes a series of premises in order to guarantee that security knowledge could be properly addressed in order to be created and managed in subsequent processes. These guidelines and design policies are essentially framed in four different activity areas:

1) Define a common language to express the elements, rules and component interaction for the CEP. It is created as a UML metamodel, with a high abstraction level and addressing the “concepts” involved in the next modelling and transformation stages (e.g. describing the overall function of a SP into the metamodel, defining the placement of these and how they are related with the other concepts contained of the language, etc.). This artifact is known as the Core Security Metamodel (CSM) and it can be considered as a modelling template.

2) Represent security knowledge using as basis the previous language. This information is packaged in a new metamodel called Domain Security Metamodel (DSM). Its main task is not just to collect and represent security elements as a UML diagram, but all the data has to be modeled following the schema expressed in the CSM. Proceeding this way, the CSEs have to conform and meet with all the rules imposed by the CSM language. This model-based creation procedure is automatically handled and verified by the modeling framework thanks to the UML inheritance properties, which helps to check the validity of the DSM under development.

3) Additional verification and validation (V&V) processes are required in the CEP because the fulfillment of the template assures that security knowledge has the proper structure and the information has a correct syntax in the terms defined in the CSM. Unfortunately this is not enough and the DSM needs also to verify the semantic of the security knowledge. The meaning and purpose of the contained elements has to respect basic but strong rules that cannot be expressed in the CSM. The V&V mechanisms consist in OCL rules for model

checking running over the different metamodels supervising all the intermediate designing stages along all the CEP.

4) Store, sort and catalog all the created security artifacts into the CUMULUS repositories. The modeling framework allows uploading of the different elements collecting security knowledge such as DSMs or COSPs into remote locations. There they are indexed and catalogued for latter search requests and allowing their retrievals. The repositories are crucial components in the CEP because the location of the most appropriate security artifacts is essential for the CSEs. When the artifacts are stored in the repositories they can be considered as security libraries. They are self-contained collections of security knowledge, mechanisms, solutions and implementations that can be located, imported and loaded in the modelling framework and removed when they are no

longer necessary.

These four activities summarize the main workflows of the CEP. They are closely related because their joint work is necessary for obtaining reliable and usable results. The security knowledge offered by the CUMULUS platform to CSEs has to be complete, coherent, validated, well-described, structured and includes the precise procedure with the actions and the mechanisms for fulfilling security requirements.

3.2 Security Requirements and Certification Requirements The CEP addresses many security concepts during its workflow and most of them are included in the CSM language definition. The security requirements are one of these elements. It is a joint point between security experts and cloud developers because all the security knowledge relies in the recognition and identification of security requirements either formally (using their names) or informally with an approximate description of the security issue or concern.

As we can see in Figure 1, the security requirements could represent either specific application details or tailored aspects belonging to the domain. In both cases, the attached security knowledge such as well-known threats or security policies extends the information and data for describing concerns and characteristics of these elements. The Figure also shows an important section of the CEP approach, where security requirements in the context of cloud applications usually have to be achieved by certification requirements (although this is not always necessary). This transformation mechanism is done by the modelling framework using the security knowledge expressed in the DSMs. It also takes into account the rules and regulations contained in the COSPs. It is possible that some security issues can be addressed just with local solutions, deploying mechanisms in the user side of the design. In any case, the common scenario in the development of cloud applications is to claim the security assurance of the involved cloud services and, therefore, the design has to be transformed with the security–to-certification requirement conversion.

Security requirements own specific meaning for all software developments where security concerns and risks could emerge in the system. Certification requirements belong only to online platforms and resources where several components or processes have to be issued in order to check their certificate compliance. Cloud systems meet these conditions and they can take advantage of the CEP by providing to cloud developers a CUMULUS-aware platform enable to interact with the modeling framework and capable to answer with adequate certificated services to fulfill the certification requirements.

Ultimately, certification requirements in the context of the CEP are a way to describe the assurance profile with the desired and mandatory conditions to be achieved by the cloud services. This collection of necessities are defined as a template where the main components are the certificates. Besides, there are also others like the certification model used to create the certificates or the testing mechanisms used to issue them. The CEP focuses in this part of the lifecycle by retrieving all the available certified services that conforms the service assurance profile. This way, we need a mechanism to identify if the certification requirements are necessary or adequate for solving specific security requirements.

3.3 Cloud Applications Development

Once the security knowledge has been gathered and uploaded to the repositories as security libraries, the CUMULUS platform is enabled to support the development of cloud applications, ready to take advantage of these security data. This phase of the process is covered by the CEP but it also requires the expertise and knowledge of Cloud Software Developers (CSD), responsible of the software development. When the process to create cloud applications starts, the system engineers create their own software designs following their specific methodologies and working methods. Usually, they have to reach the quality levels required by the company criteria and guidelines. All these formal specifications guide many design decisions of the CSDs, pointing for instance some

Figure 1. Extract of the Core Security Metamodel

+descripti on : String «Metaclass» RM_Application_Security_Requirement +descripti on : String «Metaclass» RM_Domain_Security_Requirement +URI : String +xml : String +ver sion : String

«Metaclass» AM_Service_Assurance_Profile +descripti on : String +URI : String +xml : String «Metaclass» RM_Certification_Requirement «Metaclass» RM_Security_Requirement +descripti on : String «Metaclass» DM_Security_Mechanism +type : String +descripti on : String «Metaclass» SM_Security_Solution +descripti on : String «Metaclass» SM_Security_Pattern +descripti on : String «Metaclass» RM_Security_Policy +descripti on : String +Category : String +context : String «Metaclass» PM_Property +impact : String +objective : Str ing +descripti on : String «Metaclass» RM_Threat +xml : String +id : String «Metaclass» AM_Certificate 0..* implies 1..* 1..* addressed by 1..* 1..* satisfy by 0..* ensured by1..* 0..* realized by 1..*1..* susceptible to 1..* realized by correspond to regulated by 1..* includes provided by 1..*

standards to comply, technologies to use or components to integrate in the architecture. Regarding security, not many of them tackle the issue. Only a few establishes or defines protective measures or design principles in order to include security mechanisms in the design.

Under the assumption that they are not aware of security mechanisms and concerns they need to have sufficient expertise in order to make an initial security risk analysis of the application for extracting the list of security requirements. Following with the CEP approach, these experts needs to understand basic principles of security to detect potential security concerns and threats of their systems. This will allow them to make an informal description of what they want to solve in order to access the CUMULUS repositories to retrieve fixing mechanisms for these discovered security issues. Therefore, CSDs request to the CUMULUS platform the security knowledge related to their collected requirements and necessities. As described above, the string used to search and locate security libraries could be as simple as the name of a security requirement or a non-formal description of security concerns. In any case it can be more extensive and complex for instance claiming for security properties in order to solve security threats and using specific technologies for the implementation of the solutions. All the info that CSDs include to retrieve data from repositories will help them to find the most appropriate security knowledge to download. When system engineers retrieve the security libraries and the solution mechanism attached to these, the modeling framework load all the data and enables the framework to deploy the security knowledge and components into system models. The CSDs are responsible to indicate where the security requirements are necessary but all the deployment and integration processes are automatically managed and supported by the framework. Development of cloud applications in the context of the CEP involves a complex approach due to multiple considerations which influences the security mechanisms. Some security concerns and requirements in cloud can be achieved just by using secured or certified services of the CUMULUS platform, but in some cases solutions could imply the usage of local and trusted software in the user side, outside the cloud platform but interacting with it. Therefore all these different configurations could affect the treatment of security components and how the solutions have to be addressed and deployed in order to obtain a proper and secure design of the system.

4. CUMULUS-aware Security Patterns

As we have stated, COSPs represent an important element in the CEP due to their role describing when and how solutions must be used. Besides they are very useful if the solutions need to achieve specific certification requirements as part of the included security knowledge in the DSM. In our goal to integrate these artifacts into the CEP, we have to understand the distinctive elements of the COSPs and expand them with extra fields to support necessary CUMULUS features. We call this new elements CUMULUS-aware Security Patterns (CSPs). 4.1 COSPs

There are different definitions of the concept and realization of security patterns and even in papers that use a

similar definition the levels of description are different [17]. Besides, patterns are usually dismissed by researchers because they feel they are not “scientific enough”. This reasoning comes because most of the security patterns are document-based and human oriented or the process to define them lacks a well-defined and rigorous process for developing systems based on them. Therefore, most of the problems are that the contents of the patterns are currently text based or document (graphic) based but not automation-oriented. For that reason we use a new type of security pattern called Computer-Oriented Security Pattern (COSP) that aims to fulfill the gaps described before. Its main characteristics are:

• Machine-processable: COSPs are designed to be treated by computer-assisted means for their specification, development, searching and cataloguing. Besides, they can be used and integrated in modeling and development environments. A very important output of this characteristic is that it allows the creation and use of an online distributed catalog of patterns with advanced searching and browsing capabilities. Besides, the management of security patterns as computer objects in modeling and design frameworks is a very useful and valuable functionality for users. • Engineering-oriented: COSPs enables an easy

integration in engineering activities and processes, facilitating the tasks of adopting security patterns. This is a very hard task in the IT world, as users and companies usually work with just one process and they are very reluctant to adopt new ones, even if it brings new and better functionalities. Therefore, COSPs are designed with the capability to work with existing processes and methodologies, acting more as an evolution and facilitating their work instead of a new and complete engineering approach that requires new knowledge, expertise and tools.

• Trusted: trust management mechanisms should be a core element in the new patterns. That way engineers will be able to use security patterns from sources they trust, with guarantees of authenticity, integrity and with reliable assessment of their quality and reputation. This is done by providing COSPs repositories where users can check the patterns authorship or reputation and auditors could check their state and trustiness. Creating a trusted community will improve greatly the use of COSPs, their growth and impact.

• Detailed and precise: COSPs allow security experts to capture and represent a rich set of characteristics and details with enough rigor and precision to suit the needs of different users and scenarios but without sacrificing their generality, which is necessary in order to ensure their reusability. For this reason COSPs provide ontological support that improves selection capabilities and interoperability between different patterns. That way when users search for a specific property (such as Authentication) the system would return all patterns with properties defined by ontological rules to the searched property (e.g. Client Authentication, Mutual Authentication, etc.).

• Open and decentralized: COSPs allow security experts to publish their patterns in an open way allowing other experts to analyze, improve them or even using them for creating a new branch with different characteristics. COSPs contain mechanisms for pattern identification, tracing (versions), etc.

In order to adequately represent COSPs in a way that fulfills all the above mentioned goals we consider that XML is the best possible container as it allows modular representation of the security pattern elements, it is easy to parse, can contain at the same time complex structures and precise references to specific elements (including cross-referencing) and has standards supporting the envisaged trust management mechanisms. Moreover, XML is already extensively used in system engineering activities and this fact will clearly facilitate the desired integration with engineering tools such as UML modeling suites. In fact, there is a standard XML-based format to contain UML models called XMI. This facilitates our task of developing our current security patterns since it allows us to directly embed UML models in the pattern structure.

Following we provide the structure of a COSP along with a short description of each field.

1. Pattern Reference

As COSP are machine-processable the references are done by means of unique IDs using a coding scheme that facilitates their distributed creation.

2. Intent

This section describes the security properties provided by the pattern along with the elements of the system that are the recipients of these properties. These elements are called “Assets” and essentially they are the elements to be protected.

3. Example

In traditional security patterns this is a human-oriented element. We maintain this orientation in the COSPs but with additional support for automated processing.

4. Context

This section describes the context where the pattern can be applied and information that facilitates its integration in the design of the system.

5. Problem

We describe the problem the pattern solves by means of restrictions and metrics of the pattern related to the security properties. For this reason this is done in the Intent element.

6. Solution

COSPs provide here a complete model that includes: (i) the elements of the system that are protected by the pattern; (ii) the functional elements of the system that are associated to the elements defined in the pattern; and (iii) the pattern-specific elements along with their interrelations and another necessary related model (e.g. behavior, business, etc.)

7. Implementation

This section explains the considerations of the pattern for the implementation together with a series of OCL rules used to verify and test the sound integration of the pattern in the system.

8. Consequences

Here we define a series of properties that are obtained for the system once the pattern is integrated and a series of elements defining the limits and limitations of the pattern.

9. Related Patterns

It provides a series of references to other COSPs using their unique identifiers along with version numbers and checksums.

10. Trust Mechanisms

This element is essential in COSPs due to their computer-oriented format. The trust mechanisms supported are digital signatures together with unique PatternIDs. We are also considering other forms of trust (e.g. reputation-based or quality-based).

4.2 CUMULUS-aware Security Patterns

Due to its characteristics, functionality and potential COSPS are the better solution for the CEP because they can provide not only the architecture of the mechanisms but also the behavior, the procedure and considerations to be taken into account when their security knowledge have to be extrapolated to the system designs. All the fields in the COSPs could be directly applicable to the conditions and necessities of the CEP thanks to their domain independent description, although in order to support the complete methodology we have to expand them with some specific attributes of the CEP.

In order to avoid confusions these expanded artifacts are called CUMULUS-aware Security Patterns (CSPs), which inherits the strength and proven applications of the COSPs but modified in order to be accommodated in the CEP. It is important to highlight that one of the most important reasons to use COSPs as basis for the CSPs is to reuse the current list of already developed artifacts which have been created and filled with security knowledge and solutions targeting different scenarios, providing a great starting point in such cases where cloud applications can use or reengineer these existent solutions.

Therefore, in addition to the five main characteristics of the COSPs, these new artifacts introduces a new one:

• Cloud-oriented: CSPs have to provide means to express how a local solution in the user side of the system is enabled to access, interact and coordinate actions with a cloud platform, specifically a CUMULUS-aware platform running an instance of the CUMULUS framework [16]. In other words, the CSPs have to be able to express the fulfillment of security requirements by means of certification requirements, incorporating mechanisms to express how the CUMULUS platform covers and supports different stages of the assurance mechanism and how both sides (client and cloud platform) have to interoperate between themselves.

At this point is essential to understand why the XML schema with the structure of the COSPs has to be expanded to adopt the new considerations and requirements of the CEP. The figure 2 shows the sense of these new attributes as extensions of the common COSPs.

1. Subsystems solution

Unlike the COSP solution (6), in order to address the interaction between the local assurance and the platform running the remote cloud services, a new type of model is required. This model allows the division of the pattern into functional subsystems or components, which have to be aligned with the solution itself, but can express the relations and communications between both sides at an abstract level but sufficient enough to guide the implementation of these discretized elements.

2. Certification Requirement

This section includes references to the certification requirements designed by CSDs to achieve certain security requirements, by using different cloud certified services from the CUMULUS platform. This elements work as links between the CSPs and the DSM, as they contain the expected Service Assurance Profile. That is, a collection of the desired and mandatory characteristics to be provided (and fulfilled) by the cloud services in order to achieve the security requirement.

3. Reasoner

Here we describe several raising considerations from the complex component solution models. As in the case of the implementation (7), an OCL design validation and verification is required during the integration but also regarding to the components interaction we introduce a mechanism of OCL reasoning, created to response adequately to component or service dependencies or impositions from the cloud platform that have to be properly addressed.

5. Conclusions

The CUMULUS engineering process is a complete methodology that enables a sound development of cloud applications. Its main goal is the fulfillment of security requirements by means of flexible certification requirements. In order to address these transformations it relies in three

different expertise areas: 1) a requirements engineering that analyzes the security risks of the system for capturing security requirements; 2) a powerful and modular approach to capture security knowledge and represent it conforming a common language and template; and 3) the usage of CUMULUS-aware Security Patterns in order to support the process to combine the local assurance in the client side with the remote assurance based in certified services obtained in the CUMULUS cloud platform.

Summarizing, we have presented the CUMULUS approach focused in how the CEP addresses the gathering of security knowledge and why it requires a powerful and reliable mechanisms such as CSPs to accomplish this task. We also present here the foundations for the future work, exploiting and improving the integration of these security artifacts in the CEP. Acknowledgment

This research was undertaken in the Seventh EU Framework Programme as part of the CUMULUS EU Project (Certification Infrastructure for Multi-layer Cloud Services). References

[1] CUMULUS Project. http://cumulus-project.eu/

[2] S. Seedorf and F. Forschungszentrum. Applications of Ontologies in Software Engineering. In 2nd International Workshop on Semantic Web Enabled Software Engineering (SWESE 2006)

[3] Z. Liu, A. Ranganathan and A. Riabov. A Knowledge Engineering and Planning Framework based on OWL Ontologies. In International Competition on Knowledge Engineering for Planning and Scheduling (ICKEPS 2007), 2007

[4] M. Sicilia, E. García, S. Sánchez, and D. Rodríguez. Ontologies of engineering knowledge: General structure and the case of software engineering. The Knowledge Engneering Rev., vol.24:3, pp.309-326, 2009.

[5] B. D. Czejdo and T. Morzy. Knowledge, Knowledge security and Meta-knowledge. WSKS 2, vol. 19. Communications in Computer and Information Science, 245-252. 2008

[6] S. Faily and I. Fléchais. A Meta-Model for Usable Secure Requirements Engineering. In Software Engineering for Secure Systems, 2010. SESS ’10. ICSE Workshop on, pages 126–135. IEEE Computer SocietyPress, May 2010

[7] Al-Shorafat, Wafa Slaibi, "Security in software engineering

requirement," 8th International Conference for Internet Technology and Secured Transactions (ICITST), pp.666,673, 2013

[8] I. Côté, M. Heisel. A UML Profile and Tool Support for Evolutionary Requirements Engineering. 15th European Conference on Software Maintenance and Reengineering (CSMR), pp.161-170, 2011 [9] G. Elahi. Security Requirements Engineering: State of the Art and

Practice and Challenges, 2009

http://www.cs.utoronto.ca/~gelahi/DepthPaper.pdf

[10] D. Serrano, J.F. Ruiz, A. Munoz, A. Mana, A. Armenteros, B. Gallego. Development of Applications Based on Security Patterns. Second International Conference on Dependability, 2009. DEPEND '09, pp.111-116, 2009

[11] R. Bouaziz, S. Kallel, B. Coulette. An Engineering Process for Security Patterns Application in Component Based Models. 22nd IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE), pp.231-236, 2013.

[12] D. Hatebur, M. Heisel, H. Schmidt. A Security Engineering Process based on Patterns. 18th International Workshop on Database and Expert Systems Applications, DEXA '07, pp.734,738, 2007 Figure 2. CUMULUS-aware Security Patterns

[13] A. Mana, E.B. Fernandez, J.F. Ruiz, C. Rudolph. Towards Computer-oriented Security Patterns. The 20th International Conference On Pattern Languages Of Programs PLoP’13. 2013

[14] J.F. Ruiz, M. Arjona, A. Mana, N. Carstens. Secure Engineering and Modelling of a Metering Devices System. Seventh International Workshop on Secure Software Engineering (SecSE 2013), September, 2013

[15] J.F. Ruiz, C. Rudolph, A. Mana, M. Arjona. A Security Engineering Process for Systems of Systems using Security Patterns. 8th Annual IEEE International Systems Conference, 2014

[16] R. Harjani, M. Arjona, H. Koshutanski, A. Maña, R. Díaz, C. Sánchez. D4.1 CUMULUS aware engineering process specification. CUMULUS Project, Tech. Rep. 2013

[17] A.V. Uzunov, E.B. Fernandez, K. Falkner. Securing distributed systems using patterns: A survey, Computers & Security, vol. 31, no. 5, pp.68-703, 2012