An Engineering Process to Address Security Challenges
in Cloud Computing
Marcos Arjona University of Málaga Málaga, Spain Email: [email protected] Rajesh Harjani University of Málaga Málaga, Spain Email: [email protected] Antonio Maña University of Málaga Málaga, Spain Email: [email protected] Anto Muñoz University of Málaga Málaga, Spain Email: [email protected] ABSTRACTMany companies are rushing out to the cloud mainly because these platforms share services, features and resources among all cloud entities at different levels of operation. However, the cloud is prone to a certain number of security threats. One of the most relevant concerns in the migration to the cloud is the collection of unconsidered security issues that arises in the usage of cloud services. From our point of view the cloud has an evident potential but it has to be improved overcoming certain security challenges. This paper presents a novel engineering process alongside a modeling tool supporting the development of cloud applications, founded in certification-based technologies such as Trusted Computing (TC). One relevant advantage of the proposed methodology is the flexibility to integrate security in early stages of designing process, defining a certification-driven security engineering ready to be adopted by current development processes with low impositions. This approach provides means to identify security requirements and transform them into certification requirements via security solutions, which have been built for an easy and sound development of secure cloud applications on the basis of existing certified cloud services. This approach implies an adequate support for cloud system engineers and developers to make appropriate design decisions in their development processes adopting reliable security mechanisms.
I INTRODUCTION
Cloud computing provides a great opportunity in terms of cost and energy savings arisen from compute, data storage, network usage and security capabilities, offered as services on demand. The
economic aspects of the cloud computing paradigm have made it one of the fastest growing
trends in computing [1] [2] [3]. Nevertheless,
applications deployed on the cloud are still exposed to many threats that cannot be prevented by the cloud infrastructure itself. This is caused by the inherent difficulty to be in control of processes and data traffic that are outside the organization boundaries, endangering the chain of trust and increasing the complexity to verify security properties for software services.
The provision and security of the application and services are sensitive to potential interferences between the features and behavior of all the inter-dependent services at any layers of the cloud stack, as well as dynamic changes in them [4]. Those changes in the data isolation scheme operated by a cloud, can affect the privacy of the data processed by software applications available as a SaaS layer service in the same cloud. Likewise, changes in cloud messaging services at the PaaS layer could affect the availability of the same SaaS application. We highlight the fact that the effects of such interdependencies are not limited only to bottom up dependencies, but also inefficiencies of software applications available at the SaaS layer can affect overall cloud performance. Similarly, denial-of-service (DoS) attacks to specific services at the SaaS layer may affect the availability of other services at all layers in the cloud stack. From a security engineering point of view the absence of common ownership of the infrastructure, platform and software application layer services, together with the increasing population of them at all the three cloud layers, increase the risks, which make it very difficult to deal with appropriate pre-deployment controls and joint verification of the
services running on a cloud. Therefore, without a different approach to assure these services it’s almost impossible to guarantee the non-existence of interactions and dependencies that can cause security issues and vulnerabilities.
Companies such as LinkedIn, Sony, Zappos, Nintendo, AT&T, Global Payments, and even the US Department of Defense have recently suffered from the leakage/loss of password and account data [5]. Likewise, Dropbox has claimed improper access to accounts using stolen passwords led to a spam attack [6]. Amazon and Gmail outages have left behind millions of disappointed customers not only because of access to their services but also those (even third party) that depended on their cloud infrastructure. Many related incidents that threaten the availability of cloud services, the security of the underlying cloud infrastructure [7] [8], and the privacy of the cloud customers and users are exposed. These security issues are mainly motivated by unpredicted security issues or the reduced control over cloud software applications where data is de facto transferred to the provider of the cloud service. The complexity and potential interference between security mechanisms can lead to breaches of data integrity, confidentiality and privacy in the absence of adequate security controls. It is relevant to mention the vulnerability of the mechanisms of the cloud
infrastructure itself (e.g., subverting
administrative privileges and functions of the cloud infrastructure and attacking virtual machine monitors [9]).
One relevant aspect is that current general engineering processes for design and development of services and applications, usually rely on functional aspects and requirements of the system to be created. In fact, non-functional properties, if considered, in the development of cloud-based systems, are mainly concerned with safety or performance and usually neglecting security issues. In some cases, security flaws exist due to the fact that several cloud-based applications were result of redevelopment of existing desktop ones with very restricted connectivity and operated in known environments, where security was usually sufficiently managed by standard mechanisms. This situation is changing, the evolution of applications towards devices connected via Internet, wireless communication or other interfaces, as well as the trend towards always growing number of devices (Internet of Things)
which requires a re-consideration of current systems engineering processes and the application of tailored processes for new situations, contexts and security requirements. We defend that it is no longer possible to achieve the required level of security by adding just late measures at some stage of the process, thus security engineering needs to be an active part of the design in all stages of the development process.
The paper is structured as follows. Section II presents the state of the art, Section III presents the CUMULUS Engineering Process, which is divided in three subsections; the first one dedicated to the engineering phase; the second one describing the development phase; and the last one that presents a set of assisting tools for the application of this methodology. Section IV describes the security artifacts involved in our model. Section V describes how this proposed engineering process deals with the assurance and certification mechanisms. Finally, Section VI presents the conclusions and the ongoing work.
II STATEOF THE ART
As we previously aimed, the Cloud Computing paradigm provides means to access external IT platforms and services without the necessity of investments in expensive infrastructures and the maintenance costs derived. However, the development of software and data management in cloud implies important security concerns. Among the most outstanding examples are the possibilities of compromising the integrity, confidentiality [10] [4] and/or privacy of customer data on clouds [11] spamming, wrapping, cross-site scripting attacks [12], and/or DoS attacks [13]; reducing or restricting application and data availability; authentication, authorization and accounting (AAA) vulnerabilities. Besides,
Grobauer et al. [14] review potential
vulnerabilities in cloud computing, identifying the lack of certification schemes and security metrics for cloud as the most relevant reason of the existence of such vulnerabilities. Heiser and Nicolett [10] evaluate the cloud security risks. These authors put forward the idea that the cloud computing environments share IT risks with any external provided services and they describe how these cloud-based services should be evaluated. Such evidences about cloud security risks provide a complete meaning and scope to our proposal,
where our presented security engineering process is ready to monitor and support the design of cloud applications in a context of trust. Security experts, Certification Authorities and software developers follow the same engineering guidelines to ensure a reliable interoperability between them along the different designing stages. Thereby, this approach allows to manage all the security aspects involved in the software development, taking into account that security-aware systems require and assume a high degree of security expertise, with a great enforcement of standardization [15], usually tailored to functional specifications of the cloud platform and also considering the difficulty of the orchestration [16] of available services.
One of the most common notations in the design of systems is the Unified Modeling Language (UML) [17]. A high number of frameworks support its specification and usage thanks to the Meta Object Facility (MOF) [18] features for the compatibility compliance. Its simplicity, intuitive usage and extensive documentation turn it into the most used language by industries for their designing processes. But this notation is very general to address security in scenarios such as cloud platforms. But new formalisms have been done to extend the language with other required features like the Systems Modeling Language (SysML) [19], an interdisciplinary language that extends UML with many elements, diagrams, labels and mechanisms to describe additional behavior of actors involved in heterogeneous systems, but still not suitable for cloud infrastructures. Other UML extensions have emerged over time, and some of them targeting the creation of secure systems like UMLsec, presented in [20] and expanded in [21] with reliable demonstrations [22] or [23] but it only faces a subset of local security requirements and cannot address the complexity to deal with remote cloud services and platforms.
Several actions have been done by means of UML profiles to support the web services development. Rich Services Profile [24] is a great approach to define platform specifications and interactions between the different actors and entities. Another option was presented in [25] as the Extra-Functional Service Profile (EFSP) based in the Service Component Architecture (SCA) [26]. In this approach all functional requirements can be described a priori in the web services, providing platform independent mechanisms to define how
to achieve them in the final design. Several attempts to use and extend this profile are reviewed in [27]. But their bounded usability in non-functional requirements makes it inaccurate in the development of evolving contexts such as cloud services. UML Profile For Web Services (UP4WS) [28], is another proposal to represent essential and mandatory extensions required in web services describing mechanisms to generate source code from the UML models, using a collection of rules for model transformations. Furthermore, most recent UML profiles support design and modelling of cloud applications in
consonance with our approach. For instance, [29]
mentions system modelling has to be addressed at a higher level of abstraction to prevent the effects of technology changes in applications. This proposal or even other ones targeting multicloud
[30] scenarios define a model-driven framework
which enables to develop cloud applications in an automated way but neglecting security challenges or concerns. And this trend is a common fact in
several approaches [31] where development of
cloud applications proves its complexity but they are not sufficiently addressed under a security perspective. This powerful techniques requires specific training and expertise to understand the collection of rules, behaviours, identities and metaelements conforming the profile. System engineers would have to learn and gain sufficient expertise before starting the development phase. Therefore, in this state of the art we can notice that most of the current UML based modeling approaches do not specifically address security aspects relatives to cloud platforms like certification processes, monitoring capabilities or verification of the chain of trust to use cloud services. On the other hand there are methodologies that are so complex that their usage is not feasible. Under these circumstances our proposal gain importance because it provides system engineers a complete set of tools for incorporating security in their cloud applications and also integrating mechanisms to query, retrieval, manage and use certified cloud services.
III CUMULUS ENGINEERING
PROCESS
This section presents the CUMULUS Engineering Process (CEP) describing its artifacts and
functionalities. It addresses the complete lifecycle of our proposed methodology including a complete set of metamodels, processes and tools to support the development of secure cloud applications. The CEP faces several challenges along the stages of the workflow, supporting the interaction of different actors, but the most outstanding goals are divided in two different approaches:
1) Engineering phase: provides to Cloud Security Experts (CSE) support to capture security requirements and to represent the necessary security elements concerning them. The CEP defines a series of automatic transformations
to convert security knowledge into
certification requirements. This methodology establishes a mapping between these two requirement types by means of Service Assurance Profiles (SAPs), which describes the required certification mechanisms to achieve the transformation.
2) Development phase: supports the creation of applications ready to take advantage of the security knowledge collected in the engineering phase. To achieve this, the CEP defines an API, which helps Cloud Systems Developers (CSD) to request certified cloud services fulfilling certification requirements. The CSDs locate the most appropriate certificates from the available ones in the cloud platform, using the SAPs to query if the platform performs the required assurance features.
Following, we describe how the CEP addresses the emergent security challenges, the roles and processes involved in the different responsibility areas. While the cloud service certification is determined by the SAPs, the anchorage elements of the assurance process are the CUMULUS Certification Models (CCMs), which defines the template to certify cloud services, enabling them to be requested and followed by the certificates. 1 ENGINEERING PHASE
The CEP defines a methodology that is able to deal with the security knowledge, aspects, authorities and dependencies required to create certified cloud services. CSEs are responsible to gather and represent their security knowledge following the CEP guidelines, because they have a reliable expertise and skilled abilities that ensure an adequate credibility and trustiness on the security mechanisms. But the underlying goal is to
allow non security experts to develop cloud applications taking advantage of this knowledge. The CSEs have to interact with the CUMULUS Framework Specification (CFS), which is a manager installed in the cloud platform to enable all the CUMULUS platform capabilities and ensuring CUMULUS-aware certified services. In this specification arise the CCMs establishing the types of evidence as well as the ways, tests, monitors and processes of combining them in order to produce certificates. The CSEs are in charge of the creation of security configurations reflecting a specific collection of security requirements. This configuration together with the security elements such as SAPs are packaged in form of Domain Security Metamodels (DSMs) expanded in subsection IV-B. This creation process is guided and supported by the CUMULUS Engineering Tool (CET) supervising that these configurations conforms the CUMULUS predefined language and fulfills a series of validation and verification rules. These DSMs are stored in the CUMULUS Knowledge Repository (CKR) presented in subsection IV-C.
The Certification Authority (CA) will use the CCMs as template to issue several certificates for different cloud services including SaaS, PaaS and IaaS services. The certification mechanisms are based not only on a mix of evidences, including continuous cloud service data monitoring but also static, dynamic, offline, online or even Trusted Platform Modules (TPMs) based tests as shown in Section V. Therefore the CSEs will define and include in the DSMs, the SAPs describing how to fulfill certification requirements, and they can only be achieved by all the available CUMULUS-aware certificates generated by the CAs.
The Cloud Providers (CP) are active participants of the methodology because the objective of the CEP is to improve the security of the cloud infrastructure and their services in order to gain competitive advantage over other CPs. To achieve this, they have to deploy an instance of the CFS into the cloud infrastructure. Thereby, the obtained interoperability between the CUMULUS-aware applications and the cloud platform allows to request available cloud services previously certified by the CAs in runtime, giving evolving and reengineering capabilities to the software conceived using the CEP approach.
When the engineering phase ends, the final result of the process represent the joint work of the previous roles. A DSM expressing the configuration, which gathers security elements,
essential knowledge, solution mechanisms,
functional behavior and the SAPs claiming the certificates to secure cloud applications achieving certification requirements. A CA approving and creating certificates based on the CCMs. And finally, the CP who deploys a CUMULUS-aware infrastructure integrating an instance of the CFS, to satisfy specific cloud services requests. This lifecycle is managed by the CET, which supervises all the intermediate stages and it verifies all the artifacts involved in this engineering phase. 2 DEVELOPMENT PHASE
This phase, unlike the previous one, describes another series of processes but they only involve one type of user, the aforementioned CSDs. The main goal is to design CUMULUS-aware applications tailored to a specific set of security requirements. The starting point of the process is the analysis of the security requirements of the cloud application. This activity provides the description and specification of the system in
terms of functional and non-functional
requirements. On one hand, the application domain is necessary to identify the artifacts and security concerns belonging to the specific environment where it will be deployed. Therefore, the gathering of security requirements and the domain identification are needed to retrieve the DSMs, from the CKR. Following, these DSMs are used to transform security requirements into certification requirements by means of the included SAPs, which finally are used to select the appropriate elements and cloud services to be retrieved from the CFS instance deployed in the CUMULUS-aware cloud platform.
By analyzing the application, we obtain the security requirements and properties needed to fulfill the security objectives of the system. For
example, if a security requirement was avoid
access to unauthorized data storage, it could be described by using Confidentiality as a security property. Therefore the CSDs query the CKR to retrieve the most appropriate DSMs capable to solve those security requirements. The DSMs configuration is used to solve this conversion by means of SAPs, used to achieve the certification requirements and also it defines how the security
mechanisms have to be deployed in the application architecture. These processes to access, import, verify and deploy security elements are supported by the CET, which supervises, validates and automatically controls the flow of the process at any time.
Furthermore, another goal of this phase is the integration of a library in the developed cloud
application, which provides a direct
communication with the CFS to adapt the software in response to dynamic changes, setting the platform to adopt new security requirements, giving capabilities to request the platform for new certified services, verify used certificates, change unavailable services, check updated security concerns, etc. Proceeding this way, the cloud application can ask in runtime to a CUMULUS-aware cloud platform, which integrates a CFS instance, for all the necessary modifications to accomplish a new reconfiguration.
3 CUMULUS ENGINEERING TOOL As aforementioned, the CEP establishes a set of procedures to provide interoperability between the different actors and entities, and it has to take into account the two workflows and interests of the different approaches (engineering and
development). Therefore, our proposed
methodology is closely linked to the use and management of the CET. Its assistance covers the
overall methodology, offering tailored
functionalities for all the roles and supervising all the intermediate stages, checking and validating the state of the artifacts produced in the lifecycle. The CET is founded in the Unified Modelling Language (UML), a widely used formalism to specify object oriented systems. It defines a notation to build several types of diagrams, each one representing a particular view of the models to be created in the CEP. The flexibility provided by UML allows to extend its modeling capacity using profiles, which facilitates the performance of model-based testing. Besides, it is also possible to add rules to the models by using the Object Constraint Language (OCL) [32], which specifies pre and post conditions to operations, allowing to define constraints to the expected behavior. Bearing in mind the UML adaptability and flexibility, we consider it our best option for the CEP and the best way to model the different
security requirements for cloud based systems, in order to express its attributes, behavior and mechanisms by means of metamodels. And this well-known language can be easily integrated into existing development processes with minor impositions. The CET uses several artifacts that are used for a) defining the structure that represents the security knowledge of any domain and b) gathering the security knowledge of a specific domain. These artifacts are the Core Security Metamodel (CSM) the DSM and the CKR, described in the Section IV. The CET has been created as a plugin for MagicDraw [33], taking advantage of such proven and reliable modeling framework used by many companies. The CET is designed to help and support the CEP, providing a common platform for the participant actors in the CUMULUS approach. The collection of features is intended to:
1) Support to create and manage the CSMs
2) Support to load the CSM and use it to create
DSMs, allowing users to describe the security knowledge in a supervised framework, validating the models with OCL Rules
3) Support CSDs to search, retrieve and use
DSMs to fulfill security requirements in order to develop secure cloud applications.
IV SECURITYARTIFACTS
The CEP has to address the management of many security elements and concerns during the workflow lifecycle. Also, the CET has to deal with all the different goals and challenges of the two engineering approaches. In order to accomplish this purpose, our proposal establishes three different security artifacts sustaining all the functional requirements of the modeling process.
• The CSM defines the structure of the
knowledge. It includes the definition of security properties, threats, assertions, certification models, assumptions, etc. The CSM has no specific security information on its own, it just defines the language.
• The DSM allows CSEs to capture security
knowledge in compliance with the
environment of their applications (company policies, standards, etc.). It uses the CSM language as basis for instantiation.
• The CKR stores the DSMs in an online
catalog, with search capabilities in order to retrieve DSMs to be used by the CSDs.
A. CORE SECURITY METAMODEL In order to manage and use all these security elements in the CEP, involving several roles, we have to define an artifact to describe the common language and the rules to be used and followed in the different stages of the process. This goal is materialized as a metamodel, shown in Figure 1. It contains elements and relations to represent security concepts such as properties, requirements, threats, attacks, domains, tests, etc. It is important to note that this language deals only
with concepts (e.g. attack) and not with instances
of these concepts (e.g. unauthorized data access).
Thus, this artifact is domain-independent and defines the common language used to express security-related information. The central element of the CSM is the concept of security requirement. In fact, one of the main objectives of the CSM is to serve as a basis for the definition and description of mechanisms to convert security requirements into certification requirements. Defining the CSM as a metamodel provides many advantages for later instantiation phases. First of all, this artifact is a self-contained collection of elements with the necessary rules to verify its consistency. The standard UML guarantees that users cannot override the grammar rules of this language and additionally the CET adds explicit rules to avoid misconceptions with the different metaclasses. Furthermore, all the elements include a clear description of their function, helping CSEs to understand how they have to use the CSM in their process. Due to the complexity of the metamodel, the CSM is divided into different expertise sub metamodels. Each one focuses on a specific area, allowing users with experience and knowledge in that field to fulfill those classes and use them in the creation of DSMs. Following, we introduce the different expertise sub-models displayed in Figure 1. All metaclasses have the prefix CP- which means CUMULUS Project and they also display different colors, each one assembles and represents a sub-model of the CSM.
• Properties sub-model (PM - Yellow): focused
on the definition of the security properties and the necessary attributes to describe them.
• Domain sub-model(DM - Brown): it describes
the domain of the DSM with assets of the real world to protect that can be found in the domain along with labeling mechanisms to identify and mark additional assets.
Fig 1. Core Security Metamodel
• Solution sub-model(SM - Pink): it describes
how to achieve security requirements by means of security mechanisms and solutions. Linking the security property with the SAPs.
• Requirements sub-model(RM - Green): it
includes the necessary elements to characterize the security requirements like assumptions, threats or attacks. Due to their common characteristics, this sub-model also includes the certification requirements representation.
• Assurance sub-model(AM - Dark Blue): it
defines the assurance and certification of the security property creating a SAP to be used to achieve obtain the certification requirement.
• V&V sub-model(VVM - Light Blue): it is used
for the validation and verification of the test-based certification model.
B. DOMAIN SECURITY METAMODEL The DSM is an instance of the CSM in a specific domain. Therefore the DSM uses the CSM as the language for the creation of all the elements to be represented in the model, by using its metaclasses, attributes, relations, etc. Each DSM belongs only to one domain, but it could represent many security elements, each one with its own collection of attached concepts and creating a security configuration with all of them. A DSM is
composed of instances of the different metaclasses that we explained in the Subsection IV-A.
The CSEs create DSMs in the Engineering Phase and the contained knowledge is exploited by the CSDs in the Development Phase, enhancing cloud applications with security. For that reason, the DSMs are created by experts in their security field. These users apply their security knowledge and expertise inherent to the domain to elaborate a DSM enriched with all the stuff they consider relevant to appear. A great representation of the security knowledge is fundamental for the proper usage of DSMs. The CSEs should include in the DSM as many elements as possible to describe security threats and concerns about security requirements. Thereby, the CSDs will receive more benefits in order to check the final architecture, because they can verify all these described security threats and concerns by creating multiple tests for all of them, even for elements they were not aware of them, and probably would be initially ignored.
The main goal of the DSM is to represent security knowledge, but on the other hand, collect the necessary security elements to elaborate solutions for security requirements. These elements are fulfilled by means of security properties, realized by security mechanisms and defined by SAPs,
«Metaclass» CP_AM_Monitoring-Based_Certification_Model «Metaclass» CP_RM_Application_Security_Requirement «Metaclass» CP_AM_Test-Based_Certification_Model «Metaclass» CP_AM_TPM-Based_Certification_Model CP_AM_Service_Assurance_Profile «Metaclass» CP_RM_Certification_Requirement «Metaclass» CP_RM_Security_Requirement «Metaclass»
CP_VVM_DynamicVerification CP_AM_MonitoringEvidence«Metaclass»
«Metaclass» CP_AM_Certificate_Template «Metaclass» CP_AM_Certification_Model «Metaclass» CP_DM_Context_Contraint «Metaclass» CP_VVM_StaticVerification «Metaclass» CP_SM_SecuritySolution «Metaclass» CP_DM_Asset_Element «Metaclass» CP_AM_TestEvidence «Metaclass» CP_RM_Assumption «Metaclass» CP_AM_TCEvidence CP_DM_Stereotype «Metaclass» CP_AM_Property «Metaclass» CP_AM_Assertion «Metaclass» CP_AM_Evidence «Metaclass» CP_PM_Attribute «Metaclass» CP_PM_Property «Metaclass» CP_DM_Domain «Metaclass» CP_RM_Threat «Metaclass» CP_RM_Attack «Metaclass» CP_AM_TOC implies 1..* 1..* defined into 0..1 1..* realized by 1..* addressed by 1..* 1..* ensured by 0..* 1..* defines provided by 0..* 1..* executed by 0..* 1..* applies to 1..* 1..* contains 0..1 1 0..* has 1..* susceptible to 1..* 0..* defined by 0..1 * 1..* 0..* defined by 1..* 0..1 0..1 has 0..* has ** relies on
which finally references the CCMs. Following, we are going to briefly explain all the elements of an example DSM. This configuration without an associated scenario makes it slightly more complex to follow, but our purpose is to demonstrate how the security knowledge is gathered using the CSM. As we can see in Figure 2, the DSM domain (CP_DM_Domain metaclass in the CSM) is
Cloud Storage in eHealth, which specifies the usage of cloud locations to store all the data records and information about patients in an eHealth environment. The eHealth is a complex domain which has many privacy and law requirements, and it also imposes very restricted rules about the protection of the patient data. Thus, CSEs and CSDs receive a clear idea of the type of knowledge of this domain and the information contained in the DSM.
PatientData (CP_DM_Stereotype) stereotype has been created in this domain to provide a labeling mechanism to identify the assets to be protected. Specifically in this domain there are two assets
(CP_DM_Asset_Element) to assure, the
patientData, describing the file records or any patient personal data uploaded to the cloud
storage service and the recordPath that represents
a path to a location where the data is stored.
Both applied to Secure Storage of Data
(CP_DM_Application_Security_Requirement), which indicates the security requirement demanding a secure file storage to avoid the exposure of private patient data. The involved
security property is the Data Storage
Confidentiality (CP_PM_Property), described as the capability to ensure that information is accessible only to those authorized to have access. The Secure Storage of Data is characterized by several potential threats and attacks. The extension of this sub-model part will be crucial to define security concerns to be considered in future testing stages. As an example, the DSM represents the Data Disclosure (CP_RM_Threat). It describes how cloud storage users access information stored by the service persistent storage without sufficient permissions. Motivated to obtain private data from another user, the goal is to access confidential data records of a patient from the cloud storage.
Once the Secure Storage of Data has been
described, the CSDs express how can it be solved
by means of the User data protection in storage
(CP_SM_SecuritySolution) solution, which
indicates that the cloud storage service, with or without support from the underlying operating system, must provide the means of protecting patient data from disclosure, while data remains in the persistent medium (storage). This security objective includes the specific mechanism to realize it, such as an AES mechanism, which is a high grade symmetric encryption using NIST approved algorithm as we can see in Figure 2. The security requirement will be transform into the certification of patientData (CP_RM_
Certification_Requirement) ensuring the Data
Storage Confidentiality, providing the certification
mechanisms by means of the SAP, Confidentiality
PatientData Cloud Storage Assurance Profile.
Therefore, our goal has to successfully define a package of mechanisms to provide the certification process, based in the CCM, upon the evidences, relying on tests, etc. All these elements are
modeled in the SAP like the Confidentiality
PatientData Cloud Storage Template of Certificate (CP_AM_Certificate_Template)
which contains the expected Uploaded fileData
Target of Certification (CP_AM_TOC), which establishes a service architecture (SaaS) described as the functionality that allows the consumer to upload and securely store data. It also contains two Assertions (CP_AM_Assertion), the first one is a TPM-Based Assertion that relies on a
Confidentiality Cloud Storage Assurance TPM-Based certification model (CP_AM_TPM-Based_Certification_Model). The second one is a Static TestBased Assertion based on a
Confidentiality Cloud Storage Assurance Static Test-Based certification model (CP_AM_Test-Based_Certification_Model). This model is capable to reference dynamic or static tests but for our demonstration we only include an
OfflineTesting (CP_VVM_StaticVerification) represented in the model, the only displayed element belonging to the V&V sub-model. The assertions belong to security properties, but they have to be described in a more specific way closer to the architecture, in order to understand details
about the implementation. Confidentiality
property (CP_AM_Property) described in the context of Storage is extended with several
attributes (CP_PM_Attribute), defining a Key
Length of 256 bits, the Level of 3, the encryption
type as Crypto ID with the AES value, and the
Fig 2. Domain Security Metamodel
C. CUMULUS KNOWLEDGE REPOSITORY
The CKR provides different usage profiles for CSEs and CSDs, allowing two types of accesses depending on the user role and the current stage of the process. One of the main advantages is to manage either a centralized or a distributed set of repositories for DSMs groups and categories. They can be technology, platform, proprietary or even CCMs-based repositories.
In the engineering phase the CSEs store and retrieve the DSMs. For this purpose, CKR processes the information to catalog the stored artifacts, sorting them in a database, using the security knowledge, keywords and metadata to index them, optimizing the access and management of these artifacts. Before the storage process, the CET always checks the state of the DSMs, testing if the internal configuration of the metamodel is valid, coherent, and conforms the semantic rules aimed by the model checking. Besides, the CET verifies if the uploaded DSM is a new element or a newer version of an older one. In the development phase, the CKR only provides means to retrieve DSMs from the repository,
searching and locating DSMs based in the security requirements requested by the CSDs. The CKR interface has to display information about the located artifacts to verify its details and correspondence with the expected security knowledge. The emergent idea is to support CSDs to choose and select the most appropriate DSMs for the application security requirements. Finally, imported DSMs from the CKR are loaded and their elements ready to be deployed to enhance cloud applications under development.
V ASSURANCE &CERTIFICATION
Certification of the different components that constitute the core of complex and fast changing systems is one of the most efficient approaches to reduce risks and enhance cloud assurance, and consequently increasing trust in cloud services. However, current research on service certification mainly concentrates on the use of certificates in service oriented applications without addressing the question of how to certify software that will run on top of a cloud stack.
This section introduces the CCMs as artifacts, defining the process through which CAs certify cloud services. These CCMs represent the
<<Metaclass>>
Confidentiality Cloud Storage Assurance TPM-Based : CP_AM_TPM-Based_Certification_Model
<<Metaclass>>
Confidentiality Cloud Storage Assurance Static Test-Based : CP_AM_Test-Based_Certification_Model description = "The cloud storage service, with or without
support from the underlying operating system, must provide the means of protecting patient data from disclosure while data remains in the persistent medium (storage).
This security objective includes/covers the part of the storage process of transmitting the patient record data to the actual physical storage."
mechanism = "High-grade symmetric encryption using standardized NIST approved algorithm AES with an allowed cryptographic key size (FIPS PUB 197)"
<<Metaclass>>
User data protection in storage : CP_SM_SecuritySolution
description = "The patient records or any patient personal data uploaded to the cloud storage service" type = "file"
<<Metaclass>>
patientData : CP_DM_Asset_Element
abstractCategory = "Confidentiality" context = "InStorage"
description = "To ensure that information is accessible only to those authorized to have access"
<<Metaclass>>
Data Storage Confidentiality : CP_PM_Property
description = "A cloud storage user accesses information stored by the service persistent storage without sufficient permissions."
impact = "High"
motivation = "Obtain private data from an user. " objective = "Access to confidential data records of a patient from the cloud storage."
type = "Active"
<<Metaclass>>
Data Disclosure : CP_RM_Threat
description = "This component defines a service architecture and functionality allowing the consumer to upload and securely store data " type = SaaS
<<Metaclass>>
Upload fileData TOC : CP_AM_TOC
description = "It must be a secure file storage which avoids the exposure of private patient data."
<<Metaclass>>
Secure Storage of Data : CP_RM_Application_Security_Requirement
<<Metaclass>>
Static Test-Based Assertion : CP_AM_Assertion
<<Metaclass>>
Confidentiality PatientData Cloud Storage Template of Certificate : CP_AM_Certificate_Template description = "Specifies the usage of Cloud locations to store all the data records and information about patients in a eHealth environment."
<<Metaclass>>
Cloud Storage in eHealth : CP_DM_Domain
<<Metaclass>>
TPM-Based Assertion : CP_AM_Assertion
description = "It represents a path to the patient data where data is stored" type = "field"
<<Metaclass>>
recordPath : CP_DM_Asset_Element
Confidentiality PatientData Cloud Storage Assurance Profile : CP_AM_Service_Assurance_Profile <<Metaclass>> certification of patientData : CP_RM_Certification_Requirement abstractCategory = "Confidentiality" context = "Storage" <<Metaclass>> Confidentiality : CP_AM_Property type = Simple value = "AES" <<Metaclass>> Crypto_ID : CP_PM_Attribute <<Metaclass>> OfflineTesting : CP_VVM_StaticVerification PatientData : CP_DM_Stereotype type = Simple <<Metaclass>> Mode of Operation : CP_PM_Attribute type = Simple value = "256" <<Metaclass>> Key Length :
CP_PM_Attribute type = Simple value = "3" <<Metaclass>> Level : CP_PM_Attribute : defined by : defined by : defined by : applies to : contains : ensured by : has : has : relies on : contains : relies on : addressed by : provided by : defined by : has : has : implies : applies to
integration of different types of evidences. For instance, test-based certificates of cloud services that have been issued under certain operational conditions can be combined with monitoring-based certificates when constraints are violated. But they also may include evidences taken from TC proofs as part of a TPM-based certification model. Conceptually, a TC proof refers to a measurement of the Hardware and Software configuration in a given state. This measurement report can be stored in a shielded physical storage of TPM, and it may include measurement of BIOS, boot sector, operating system and cloud applications software. Software certification comprises a wide range of formal, semiformal, and informal evaluation techniques. Consequently, there are different types of certificates and certification processes. However, some common certification schemes are either insufficient or not applicable in their current form for assessment in cloud computing. Therefore, CCMs tries to fill the gap offering a proper schema to deal with the necessary certification mechanisms suitable to these environments. In a TPM-based cloud service certification scenario, a CA performs a series of tests in order to certify one or more security properties of the service being tested. In case of online testing, the service is running on top of a cloud with a particular Hardware and Software configuration, and the CA is in charge of evaluating this service according to that particular configuration. The CA follows the CCM referenced in the SAP in order to represent the certificate for that particular service. The next step is to bind the certificate to that particular Hardware and Software state of the cloud stack. For this purpose, a key pair bound to the cloud stack state is generated using the TPM, and the public key of the key pair is included in the certificate together with some additional information as the state and the signature. Once the cloud provider installs in the CFS the service and its associated certificate issued by the CA, users can check if the current cloud state matches the one within the certificate. VI CONCLUSION
This paper focuses on the description of CEP to be followed in order to develop cloud-based applications. The short amount of tools and methodologies for the creation of secure cloud applications, supporting also the integration of
security mechanisms at design time in early stages of the development, demonstrate the necessity and importance of this approach.
The main purpose of the CEP is the flexible integration of security requirements into an overall framework for the development of cloud applications, together with an easy integration of this methodology into existing system designing processes with minimum amount of changes. Our proposal describes several actions to extend and goals to achieve. In this sense, it is important to highlight the fact that in order to accomplish all the goals of this approach, it relies on the full implication of the CAs to follow the CCM templates, CPs to deploy instances of the CFS in their platforms, and the usage of the CET for the development and assurance processes. Therefore, the most important goals are:
• Enable easy and sound development of secure
cloud applications on the basis of existing CUMULUS-aware certified cloud services.
• Support the security engineering of cloud
applications increasing the overall quality of the development process, where security artifacts are essential in this approach. Therefore, we have presented the CSM, a DSM example, along with its structure and a brief explanation of the gathered security knowledge. And we also have shown how this approach demands the involvement of a CKR to store and retrieve all these artifacts.
• Create different CCMs to be used as reliable
schemas or templates to certify cloud services which have been briefly presented to understand their meaning and purpose.
• Define SAPs that provide means to achieve
certification requirements of cloud applications Summarizing, we have presented the current vision of our methodology and we have described and consolidated the foundations that would support this engineering process, the mechanisms and the actions in the CUMULUS approach. ACKNOWLEDGMENT
This research was undertaken as part of the EU Framework Programme in the CUMULUS, Certification infrastructure for multi-layer cloud services and the Andalusian Government funded project ICES, Identification and Certification of Software Elements.
References
[1]
"Forecast: Public cloud services, worldwide and regions, industry sectors, 2009-2014," Gartner report, Tech. Rep.[2]
"New Market Research Report: Global cloud computing markets (2010-2015)" Markets and Markets, October 2010.[3]
"The economic impact of cloud computing on business creation, employment and output in europe" Katholieke Universiteit Leuven,Faculteit Economie en
Bedrijfswetenschappen, Review of Business and Economics May 2009.
[4]
D. Catteddu and G. Hogben, "Cloudcomputing: Benefits, risks and
recommendations for information security" 2009.
[5]
(2012, August) You’ve been hacked. again: Why linkedin’s breach is worse than youthink. [Online]. http://aol.it/NXBpFc
[6]
(2012, August) Dropbox: Yes, we werehacked. [Online].
http://gigaom.com/2012/08/01/dropbox-yes-we-were-hacked/
[7]
(2011, April) Amazon gets ’black eye’ fromcloud outage. [Online]. http://shar.es/KStyl
[8]
(2013, January) Cloudoutage. [Online].http://cloutage.org/
[9]
Thomas Ristenpart, Eran Tromer, Hovav Shacham, and Stefan Savage, "Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds" in 16th ACM conference on Computer and communications security (CCS '09), pp. 199–212, New York, USA, 2009.[10]
Jay Heiser and Mark Nicolett, "Assessing the security risks of cloud computing" June 2008.[11]
Richard Austin et al., "Domain 5: Information Lifecycle Management" December 2009.[12]
"Security Guidance for Critical Areas of Focus in Cloud Computing V2.1" December 2009.[13]
Meiko Jensen, Jörg Schwenk, Nils Gruschka, and Luigi Lo Iacono, "On technical security issues in cloud computing" in IEEEInternational Conference on Cloud
Computing (CLOUD ’09), pp. 109–116, Washington, DC, USA, 2009.
[14]
Bernd Grobauer, Tobias Walloschek, andElmar Stocker, "Understanding cloud
computing vulnerabilities" IEEE Security and Privacy , vol. 9, no. 2, pp. 50-57, March 2011.
[15]
A V Parameswaran and Asheesh Chaddha, "Cloud Interoperability and Standardization," Cloud. Computing Infosys, vol. 7, 2009.[16]
Lizhe Wang et al., "Scientific Cloud Computing: Early Definition and Experience." HPCC, vol. 8, pp. 825-830, 2008, September.[17]
Unified modelling language. [Online].http://www.uml.org/
[18]
(2005) Meta Object Facility (MOF) 2.0 CoreSpecification. [Online].
http://www.omg.org/mof/
[19]
Systems Modeling Language. [Online].http://www.sysml.org
[20]
Jan Jürjens, "UMLsec: Extending UML for Secure Systems Development" in 5th International Conference on The Unified Modeling Language (UML'02), 2002.[21]
Jan Jürjens, Secure Systems Development with UML.: Springer, 2005.[22]
Thomas Ruhroth and Jan Jurjen, "Supporting Security Assurance in the Context of Evolution: Modular Modeling and Analysis with UMLsec" in IEEE 14th International Symposium on High-Assurance Systems Engineering, HASE'12, 2012, pp. 177-18.[23]
Ling Shen, "Design and verification of secure channel based on UMLsec" in IEEE 3rd International Conference on Communication Software and Networks (ICCSN), May 2011.[24]
Vina Ermagan and Ingolf H. Krüger, "A UML2 Profile for Service Modeling" in Model Driven Engineering Languages and Systems. 2007, vol. 4735, pp. 360-374.[25]
Guadalupe Ortiz and Juan Hernandez, "Toward UML Profiles for Web Services and their Extra-Functional Properties" in IEEEInternational Conference on Web
Services(ICWS '06). IEEE Computer Society, Washington, DC, USA, 2006, pp. 889-892.
[26]
Michael Beisiegel et al., "Service Component Architecture. Building Systems using a Service Oriented Architecture," November 2005.[27]
Guadalupe Ortiz and Juan Hernández, "Aspect-Oriented Techniques for WebServices: A Model-Driven Approach"
International Journal of Business Process Integration and Management, vol. 2, no. 2, 2007.
[28]
Wafi Dahman, A UML Based Methodology for the Development of Web Services, An Approach to Model Transformation and Code Generation. PhD Thesis, July 2010.[29]
Roshan Kumar, Jeevith Bopaiah, Pranja Jain, Dr. Naili N, and Dr. K. Chandra Sekaran, "Model Driven Approach For Developing Cloud Application" International Journal of Scientific & Technology Research, vol. 2, no. 10, October 2013.[30]
Joaquín Guillén, Javier Miranda, Juan Manuel Murillo, and Carlos Canal, "A UMLProfile for Modeling Multicloud
Applications," in Service-Oriented and Cloud Computing., 2013, vol. 8135, pp. 180-187.
[31]
Dr. Zaigham Mahmood and Dr. Saqib Saeed, "2. Software Development Life Cycles for Cloud Platforms" in Software Engineering Frameworks for the Cloud Computing Paradigm.: Springer, 2013.[32]
Object constraint language. [Online].http://www.omg.org/spec/OCL
[33]
Magicdraw: business process, architecture, software and system modeling tool withteamwork support. [Online].
http://www.nomagic.com/products/magicdra w.html
