Supporting the Security Certification of
Cloud-Computing-Infrastructures
Amir Shayan Ahmadian
1
, Fabian Coerschulte
1
and Jan J
¨
urjens
1,2
1
Chair of Software Engineering, Technical University Dortmund, Otto-Hahn Strasse 12, 44227 Dortmund, Germany
2
Fraunhofer ISST, Emil-Figge-Straße 91, 44227 Dortmund, Germany
Keywords:
Cloud Computing, Certifying Cloud Providers, Risk Analysis Methods, Risk Treatment Methods.
Abstract:
Outsourcing services into the cloud is a worthwhile alternative to classic service models from both a customers
and providers point of view. Therefore many new cloud providers surface, offering their cloud solutions. The
trust and acceptance for cloud solutions are however still not given for many customers since a lot of security
incidents related to cloud computing were reported. One possibility for companies to raise the trust in the own
products is to gain a certification for them based on ISO27001. The certification is however a large hurdle,
especially for small and medium enterprises since they lack resources and know-how. In this paper we present
an overview of the ClouDAT framework. It represents a tool based approach to help in the certification process
for cloud services specifically tailored to SMEs.
1 INTRODUCTION
Cloud computing is a business model that kept gain-
ing importance in the recent years. The National In-
stitute of Standards and Technology describes cloud
computing as “ubiquitous, convenient, on-demand
network access to a shared pool of configurable com-
puting resources (e.g., networks, servers, storage, ap-
plications, and services) that can be rapidly provi-
sioned and released with minimal management effort
or service provider interaction” (National Institute for
Standards and Technology, 2011). Cloud computing
provides a very interesting opportunity for IT enter-
prises to service a large amount of customers by of-
fering dynamic scalability, elasticity, and a cost model
that is based on pay-as-you-go model.
The utilization of cloud computing services has
been ever growing in the past years and the growth of
this business model is expected to continue in the near
future (Armbrust et al., 2009). However, the accep-
tance of cloud computing is growing slowly, due to
the fact that cloud computing introduces new threats
and vulnerabilities. Therefore, besides all the advan-
tages of cloud computing, cloud providers need to
convince the cloud customers of security.
A possible way to encounter scepticism and raise
acceptance is the certification of cloud providers ac-
cording to standards like ISO27001 (ISO, 2013).
However, for small and medium-sized enterprises
(SMEs), offering cloud solutions is a rather complex
task, due to the lack of know-how and resources to
conduct an ISO27001 compliant risk assessment and
generate the appropriate documentation to reach the
certification. The ClouDAT project (ClouDAT, 2015)
offers a framework helping SMEs handling the certi-
fication process. It contains a cloud-specific risk as-
sessment process and allows the automatic generation
of ISO27001 compliant documentation based on the
outcomings of the risk assessments.
In Section 2 we present a high-level overview of
ClouDAT and introduce the risk analysis process.
In Section 3 we deliver an in-depth insight into the
underlying metamodel to introduce the key concepts
of ClouDATs risk analysis. Based on this insight,
Section 4 gives a detailed introduction into the
methodology associated with the metamodel to point
out the benefits that ClouDAT offers SMEs. More-
over, in Section 5, we introduce UMLsec (J
¨
urjens,
2005a), an extension of UML for secure system
development, along with the CARiSMA (CARiSMA,
2015) tool that supports UMLsec models.
65
Ahmadian A., Coerschulte F. and JÃijrjens J.
Supporting the Security Certification of Cloud-Computing-Infrastructures.
DOI: 10.5220/0005885600650074
In Proceedings of the Fifth International Symposium on Business Modeling and Software Design (BMSD 2015), pages 65-74
ISBN: 978-989-758-111-3
Copyright
c
 2015 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

2 THE SECURITY
CERTIFICATION APPROACH
In the first step we introduce the structure of the Clou-
DAT framework and outline its risk analysis process.
2.1 The ClouDAT Framework
The result of the ClouDAT project (ClouDAT, 2015)
is the ClouDAT framework. This framework is avail-
able as open source and supports SMEs by providing
a means for certifying cloud services. Generally, the
ClouDAT framework establishes an Information Se-
curity Management System (ISMS) based on the ISO
27001 (ISO, 2013) standard. The development of an
ISMS allows organizations to implement a framework
for managing the security of their information assets
such as financial information, employee and customer
information. The framework contains different parts:
• A metamodel for the risk analysis process com-
plying with ISO 27001 standard.
• A metamodel for the risk treatment process com-
plying with ISO 27001 standard.
• A catalog of security requirements.
• A catalog of cloud-specific threats.
• A catalog of security controls.
• Different editors to model cloud environment and
use cases, security requirements, and security
controls.
In the rest of this section, the above mentioned
parts are described along with the ClouDAT risk anal-
ysis process. The metamodels are introduced in the
respective sections.
2.2 The Overview of the ClouDAT Risk
Analysis Process
Figure 1 (Alebrahim et al., 2014) presents an
overview of the our risk analysis process, which com-
plies with ISO 27001 standard. In the following, we
summarize the different phases of the process.
2.2.1 Cloud Elements Identification
In this phase, the scope and the boundaries of the
ISMS is defined. To this end, we employ the Cloud
System Analysis Pattern (CSAP) (Beckers et al.,
2011). CSAP provides a structured approach to de-
scribe cloud environments. It provides a framework
to model their elements, such as data elements, phys-
ical objects, and stakeholders. Moreover, it describes
the relations between the cloud elements.
The process of the asset identification starts with
instantiating the CSAP. In the first step, the cloud cus-
tomers and the required cloud services are identified.
Then the cloud is instantiated, which consists of dif-
ferent types of cloud elements.
2.2.2 Refine Cloud Elements
This phase complies with Section 4.2.1 d of the ISO
27001 standard. The main goal of this phase is to
determine the cloud elements that are important to the
risk analysis. Later, for these cloud elements, the risk
analysis is performed. The results of this phase are
collected in a table, which is called cloud element list.
This table contains all mandatory cloud elements for
the risk analysis.
The cloud elements refinement is performed in
two steps (Alebrahim et al., 2014):
• Refine cloud elements and their location: In this
step the abstract mandatory cloud elements are re-
fined into more concrete and detailed cloud ele-
ments. Moreover, the location of the cloud ele-
ments are identified.
• Assign responsibilities and relationships: In this
step the responsibilities of the cloud elements are
identified and the relations between the cloud ele-
ments are determined.
2.2.3 Instantiate Threats and Vulnerabilities
In this phase, for all the cloud elements that were
specified in the previous phase a threat analysis is per-
formed. Generally, in the threat analysis, it is investi-
gated whether a cloud element is endangered. More-
over, it is examined if a cloud element has vulnerabil-
ities that can be exploited by a threat. In the ClouDAT
framework a catalog of predefined threats and vulner-
abilities for cloud elements is provided. This catalog
is based on previous works, for instance (Cloud Secu-
rity Alliance, 2011), (Heiser and Nicolett, 2008), (Eu-
ropean Network and Information Security Agency,
2009). Additionally, the list of cloud computing top
threats (Cloud Security Alliance, 2013) from Cloud
Security Alliance (CSA) is considered. The provided
catalog is a starting point for the threat analysis and
should not be considered as complete.
2.2.4 Assess Risks
This phase complies to section 4.2.1 of the ISO 27001
standard. The results of this phase declare the exist-
ing risk to the cloud elements, and specify whether a
cloud element requires risk treatment. Before starting
the risk analysis, the risk approach and the risk ac-
ceptance level must be specified. Generally, the risk
Fifth International Symposium on Business Modeling and Software Design
66

process
external
input
output
input /
1. Instantiate
CSAP
CSAP
instance
CSAP
Risks to
Assets
List of Security
Requirements
Risk Acceptance Level
Level Definition
List of
Controls
Organization
Information
2. Refine
Assets
TP
3. Instantiate
Threats and
Vulnerabilities
SRP
Control
Patterns
4. Assess
Risks
5. Instantiate
Requirements
6. Instantiate
Controls
7. Generate
Documentation
List of
Assets
List of
Threats
Docu-
menta-
tion
Figure 1: A snapshot from the control list.
assessment is based on the business impact, and the
security failures. Business impacts express the con-
sequences that affect the failure of the security goals.
Furthermore, considering the threats and the vulnera-
bilities that are identified in the last phase, we need to
determine the likelihood of potential security failures
for all menaced cloud elements.
The multiplication of the likelihoods for the se-
curity failures and the values that are assigned to
the business impacts estimates the risk levels of the
cloud elements. By comparing the estimated risk lev-
els of cloud elements and the defined risk acceptance
level, the cloud elements that require risk treatment
are identified.
2.2.5 Instantiate Security Requirements
In this phase we consider all the cloud elements with
an unaccepted risk level. We need to define a risk
treatment method to reduce the risks. We comply with
ISO 27001 Sect. 6.1.3 by defining and applying an
information security risk treatment process. The ISO
27001 specifies the following treatments:
• Applying appropriate controls.
• Accepting risks.
• Avoiding risks.
• Transferring the associated business risks to other
parties.
In Section 4 we describe our risk treatment
method completely. In this section, we only summa-
rize our method. Generally, if a cloud element has an
unacceptable risk level, security requirements have to
be defined. To this end, security requirement patterns
(SRP) are defined (Section 3). In a concrete certifi-
cation process, security requirement patterns are in-
stantiated, and for each cloud element with an unac-
cepted risk level, a security requirement will be de-
fined. ClouDAT framework provides a catalog of pre-
defined SRPs.
2.2.6 Instantiate Controls
Our risk treatment process complies with ISO 27001,
and mainly contains applying appropriate security
controls considering the security controls provided in
Annex A of the ISO 27001. Generally, the selec-
tion of the controls is based on the cloud elements
with unaccepted risk level, which are identified dur-
ing risk assessment. Similar to security requirement
patterns, the representation of the security controls is
specified by control patterns (CP), and a catalog of
predefined security controls is provided. As we men-
tioned above, we describe our risk treatment method
in more details in Section 4.3.
2.2.7 Generate Documentation
In the final phase of our risk analysis process, a doc-
ument is generated. This document contains the list
of refined cloud elements, the list of threats and cor-
responding vulnerabilities, the list of cloud elements
with unaccepted risk level, the list of security require-
ments, and finally the list of selected controls to re-
duce the identified risks. The resulting documentation
is used as a reference for the certification. In the fol-
lowing sections, we describe the underlying concepts
Supporting the Security Certification of Cloud-Computing-Infrastructures
67

Figure 2: Risk analysis metamodel excerpt.
of the risk analysis process in more details together
with the basic metamodels.
3 RISK ANALYSIS METAMODEL
This section describes the foundations of the risk
analysis process in detail. Therefore, it takes a closer
look at a simplified version of the risk analysis meta-
model defined by the ClouDAT process.
Figure 2 shows an excerpt of the full risk analysis
metamodel class diagram. Since we only want to dis-
cuss the key concepts, this illustration hides several
classes and additional implementation detail.
The goal of the risk analysis phase is to identify
the risks affecting the cloud elements that were found
during the “Cloud Elements Identification” phase (see
Section 2.2.1 and (Alebrahim et al., 2014)). The cen-
tral element for this step of the ClouDAT approach
is the CloudElement. This can basically be anything
of value to the company; from documentation to real
physical systems. A cloud element is identified by
a unique name und contains additional information
such as type, owner, descriptions and a location. Ad-
ditionally it can be excluded from the scope of the
risk analysis once a convincing explanatory statement
(rational) for this case is given.
CloudElements can be subject to requirements
verbalized by stakeholders. The requirements are ex-
pressed using ClouDATs pre-defined Requirement-
Patterns illustrated in Figure 3. They consist of fixed
text passages and generic text passages. Fixed text
Figure 3: Selectable text metamodel.
passages represent the meaning of a security require-
ment and can not be edited by the user. Generic text
passages can for example be multi selections or re-
lations to specific cloud elements. The requirement
patterns can be seen as clozes the user has to fill out
in order to instantiate a certain requirement.
Figure 4 illustrates an example requirement. It
consists of fixed text and multi selections. The ele-
ments in squared brackets represent the different op-
tions for a multi selection. Since Figure 3 provides
a sufficient understanding of the concepts, Figure 2
does not show additional implementation detail for
the instantiation of requirements based on require-
ment patterns, thus showing only the requirement
class.
Requirements can be endangered by threats that
Fifth International Symposium on Business Modeling and Software Design
68

Figure 4: An example of security requirement pattern.
are based on ThreatPatterns defined by the ClouDAT
framework. The ThreatPatterns are shown in Figure
3 and are very similar to RequirementPatterns. Fig-
ure 5 shows an example for a threat pattern defined
by ClouDAT. Since the threats indirectly endanger the
CloudElements, there is also an association to it.
Figure 5: An example of threat pattern.
The presence of threats entails risks. While threats
are very abstract and by themselves propose no dan-
ger to a company, risks do. A risk represents the “po-
tential that a given threat will exploit vulnerabilities
of an asset or group of assets and thereby cause harm
to the organization”(ISO, 2008). The risk class con-
tains a description, which serves as unique identifier
for a risk and a risk owner, which is the person re-
sponsible for a given risk. It is also possible, that a
risk is accepted by the management without further
treatment (acceptedMgmtApproval). This case how-
ever demands for a convincing explanatory statement
(rationalMgmtApproval). Furthermore a risk consists
of likelihoods, business impacts (assetValue) and the
resulting risk levels for the protection goals confiden-
tiality, integrity, availability and privacy. Since a certi-
fication requires every risk to be handled or accepted,
it is mandatory to deliver an acceptance rule for ev-
ery risk. The acceptance rule is called RiskMethod
in ClouDAT, and contains a name, description and
riskAcceptanceLevel. The acceptance level can be
seen as a threshold not to be exceeded by risks using
the RiskMethod.
The risks exceeding the acceptance level have to
be treated by the user. Therefore ClouDAT allows the
definition of RiskTreatments that consist of a treat-
ment action and a justification that explains, why a
certain action has been taken. ClouDAT allows to
treat a risk by applying controls, accepting the risk,
avoiding the risk or transfering the risk. In case a risk
is treated by applying controls, the user has to specify
the measures that were used to reduce the risk.
ClouDAT distinguishes between controls and
measures. A control describes an action that can be
taken to reduce a risk but is defined on a very abstract
level, while a measure is a concrete implementation
of a control. A control for example is “Asymmetric
encryption” and a possible measure based on this con-
trol could be the implementation of a specific encryp-
tion protocol like RSA.
The class ControlPattern allows the definition of
controls and consists of an id, name, description and
indicators whether it is required by ISO27001 or it is
an organizational or a technical control. Furthermore
it is possible to provide example measures or an ex-
ample for the control based on the IT-Grundschutz.
Controls can also suggest the use of other controls or
require the implementation of other controls. For ex-
ample, the control “Password management system”
requires the implementation of a “User registration
and de-registration” system and suggests the “Use of
secret authentication information”. CloudDAT pro-
vides an extensive list of possible controls based on
the ISO27001 (see Section 4).
A control can provide MeasurePatterns which can
be seen as implementation possibilities for the given
control. A MeasurePattern consists of a name, de-
scription and an indication whether the Measure is
neccessary to implement the control or just a se-
lectable implementation method. The concrete in-
stantiation of a MeasurePattern is a Measure, that is
associated with requirements and CloudElements.
4 RISK TREATMENT METHOD
As we mentioned in Section 2.2.5, our risk treatment
method complies with the ISO 27001 and is speci-
fied with four different treatment methods, applying
appropriate controls, accepting risks, avoiding risks,
and transferring the associated business risks to other
parties.
According to the ISO 27001 Sect. 6.1.3, consid-
ering the risk assessment results, an appropriate secu-
rity risk treatment option must be selected. To this
end, all the security controls that are necessary to
the risk treatment must be determined. Afterwards,
a comparison of the determined controls with those
in the ISO 27001 must be performed, verifying that
no mandatory controls have been excluded. Subse-
quently, a statement of applicability that incorporates
the mandatory controls and explanations for inclu-
sions and exclusions of the controls must be provided.
In the following sections, we describe these steps in
more details.
Supporting the Security Certification of Cloud-Computing-Infrastructures
69

4.1 Security Controls
In order to apply appropriate controls, we need to
specify a list of security controls, from which the
proper security controls are selected to reduce the
risks of the organization. ”Controls include any pro-
cess, policy, device, practice, or other action which
modify risks” (ISO, 2014). The Annex A of the ISO
27001 standard provides the normative controls of the
standard. Different international organizations have
provided governance documents such as the NIST-
SP800-53 (Nist and Aroms, 2012), the DISA Se-
cure Application Security Technical Implementation
Guide (STIG) (DISA, 2015), and the Cloud Security
Alliance Cloud Control Matrix (CCM) (Cloud Secu-
rity Alliance, 2014). In such documents, a set of se-
curity controls are collected. Likewise, in the course
of ClouDAT project, we provide a control list. The
control list contains:
• Security controls of ISO 27001 standard.
• Self-defined security controls: Security require-
ments have to be fulfilled by controls, hence to
cover all security requirements we have defined a
few security controls additionally.
• Security patterns: A security pattern, using some
security mechanism, describes a solution to the
problem of controlling a set of threats. We con-
sider some of the security patterns, which are pro-
vided in (Fernandez-Buglioni, 2013), as security
controls.
4.2 The Structure of the Control List
Figure 6 presents a snapshot of the control list. Due to
the lack of space, we do not show the whole table. The
control list is simply a table which contains all above
mentioned security controls. For each control a set
of aspects are defined. In the following, we describe
these aspects.
• ID: The documented controls presented in control
list are generally based on the security controls
provided in annex A of ISO 27001, and sections
5 to 18 of ISO 27002 respectively. These controls
are identified by the same ID as in the ISO doc-
uments. In the cases, which the standards do not
provide appropriate controls, self-defined controls
are provided, with the IDs beginning at 19.1 in or-
der to avoid conflicts with the ISO controls.
• Control Text: A short title for the control. For ISO
controls, the title matches the one in the original
document. Self-defined controls are labeled simi-
larly.
• Dependencies: This entry gives a list of other con-
trols. Mainly two kinds of dependencies are de-
fined:
– Necessary: The other control should be imple-
mented as well in the most cases. If the user
chooses not to apply the necessary control, the
reason must be justified.
– Suggested: The other control might be useful
to support the current control or its measure.
The tool offers these controls as an option to
the user.
• ISO 27001 - 2005 reference: The controls are
based on the ISO revision of 2013. For the con-
trols that have equivalent controls in the version
2005, the ID is given respectively.
• Security Requirement: List of relevant security
requirements.
• Refinement of (ID): A reference to the control,
which is refined by the provided control.
• Refined by (ID): A reference to the control, which
refines the provided control.
• Protected Asset: List of the assets, which are pro-
tected by the provided control.
• Instance Type: The instance type of the control,
when it is possible.
• Asset necessary to perform control with relevant
security aspect: The implementation of a control
can lead to the creation of additional assets, that
need to be protected accordingly.
• BSI References: The related entries from the BSI
Grundschutz catalogues.
• Also used in: List of similar controls from CCM
(Cloud Control Matrix).
• Technology/Organization: Each control is classi-
fied whether it is primarily (+) or supportively
(∼) technical or organizational.
• Description of control: A textual description of
the control.
4.3 Risk Treatment Process
In Section 2.2.5, we described that after risk assess-
ment, for the cloud elements with unaccepted risk
level, appropriate security requirements are elicited.
In the control list for each control a set of security
requirements are specified. This mapping between
controls and requirements simply indicates, which
control fulfills which security requirement. Conse-
quently, according to the elicited requirements, we
can determine the necessary controls to reduce the
Fifth International Symposium on Business Modeling and Software Design
70

ID (ISO
27002)
Control/Measure – Text (ISO
27002)
Dependencies
Req
(Ausarbeitung)
Protected
Cloud
Element
A.5.1.2
Review of the information security
policy.
5.1.1 necessary
- referenced
indirectly from
Security
Management and
others
generic
A.6.1.1
Information security roles and
responsibilities
A.9.2.3 necessary
A.5.1.1 necessary
- referenced
indirectly from
Security
Management and
others
generic
A.6.1.2
Segregation of duties
5.1.1 necessary
Security
Management 7
Security
Management 15
generic
A.6.1.3
Contact with authorities
Necessary: A.6.1.3
Security
Management 18
generic
A.6.1.4
Contact with special interest groups
-
- referenced
indirectly from
Security
Management
generic
A.6.1.5
Information security in project
management
Necessary: 25.4
generic
Figure 6: A snapshot from the control list.
risks. In this process the dependencies between the
controls are considered.
After the selection of the controls, we need to
verify whether the risk levels of the cloud elements
are reduced. To this end, we need to perform the
risk assessment for particular cloud elements to check
whether the controls reduce the risk levels or a modi-
fication of the controls or other controls are required.
This process is iterated until there exists no cloud ele-
ments with an unaccepted risk level. However, some-
times we need to avoid or ignore the risk. Or alter-
natively, we need to transfer the risk to other parties.
These decisions are manually made by the security
analyzer and must be reasoned.
Furthermore, we need to provide a statement of
applicability (compliant with Sect. 6.1.3 c-d of the
ISO 27001). To this end, we have provided a tem-
plate. This template is simply a table, in which for
each selected control either must be justified why the
control is excluded, or the overview of the implemen-
tation is provided, i.e. the necessary and suggested
controls to perform the control are listed.
As an example for the risk treatment process, con-
sider the case, in which the confidentiality of the per-
sonal data in a organization, for which we have have
performed the risk analysis, is threaten. In Section 3,
we have introduced the security requirement patterns.
In our SRP catalog such a pattern exists:
“Confidentiality of personal data of [cloud cus-
tomer, end customer] shall be achieved.”
As we have already mentioned, a SRP has variable
and fixed text passages. To instantiate the security re-
quirement pattern, from the list of identified and re-
fined cloud elements, an element as a representation
of the cloud customer or end customer must be in-
serted into the variable text passage. Assume that the
name of the Organization is Organization A, then the
instantiated requirement is:
“Confidentiality of personal data of Organization
A shall be achieved.”
Using the provided mappings between security re-
quirements and security controls in the control list, we
Supporting the Security Certification of Cloud-Computing-Infrastructures
71

select the relevant control:
“To address the security requirement, we apply the
controls of the ISO 27001, e.g. access control pol-
icy (A.9.1.1), working in secure areas (A.11.1.5), net-
work controls (A.13.1.1), including the controls that
are specified as necessary to perform along with men-
tioned controls.”
5 CARISMA, AN EXTERNAL
SECURITY ANALYSIS TOOL
Along the risk assessment process, which is pro-
vided by the ClouDAT framework to certify cloud
providers and generate documentation, the ClouDAT
framework offers the functionality to analyze differ-
ent cloud services and softwares with the help of ex-
ternal security analysis tools. For instance, consider
the case, in which the cloud provider uses self devel-
oped cryptographic protocols instead of the standard
protocols. In this case, an external tool for analyz-
ing the protocols is needed. An appropriate external
tool with different functionalities for security analy-
sis is the CARiSMA tool framework. It offers differ-
ent automatic verification plugins of UML diagrams
for critical requirements. Generally, it provides au-
tomated analysis of UMLsec (J
¨
urjens, 2005a) models
for security requirements.
UMLsec is an extension of UML in form of an
UML profile that provides model-driven development
for secure information systems (Fern
´
andez-Medina
et al., 2009). It can be used to express security re-
quirements within UML diagrams (such as secure in-
formation flow (J
¨
urjens, 2000)). Tags and stereotypes
are used to express security requirements and assump-
tions on system environments. Moreover, constraints
are used to determine whether requirements are satis-
fied by the system design UMLsec (J
¨
urjens, 2005a).
The UMLsec approach has been used in a number
of applications (J
¨
urjens and Wimmel, 2001a; J
¨
urjens
and Wimmel, 2001b; J
¨
urjens, 2001).
System security analysis using UMLsec requires
an architectural analysis of the software system. To
this end, all the components, objects, cloud elements,
and the dependencies between them are needed.
In the case of a legacy system, these can be ex-
tracted from the code base using techniques for pro-
gram comprehension such as (Ratiu et al., 2008).
In a certification process, it is possible to use dif-
ferent CARiSMA plugins as external tools for se-
curity analysis. For instance, we consider Control
A.9.1.1 from ISO 27001 standard. It states, that an
access control policy based on business and informa-
tion security requirements must be established, docu-
mented, and reviewed (ISO, 2014). There exists dif-
ferent approaches to establish access controls. Gener-
ally, an access control method restricts the access to
information and information processing facilities. If a
cloud provider requires an external tool to control the
access to information, the RABAC analyzer plugin of
the CARiSMA can be used (CARiSMA, 2015). This
plugin is based on the concept of Role Attribute Based
Access Control (RABAC) (Jin et al., 2012), and is im-
plemented and integrated to the ClouDAT framework
for the access control analysis in cloud environments.
Above, we mentioned that a cloud provider may
need an external tool to analyze cryptographic pro-
tocols. CARiSMA offers Sequence Diagram Crypto
FOL-Analyzer (J
¨
urjens, 2005b) for security analysis
of cryptographic protocols. This plugin as an input
receives a protocol, which is expressed as an UML
sequence diagram, and performs the analysis.
The CARiSMA website (CARiSMA, 2015) pro-
vides more information about the different plugins for
the security analysis.
6 CONCLUSIONS
The certification of cloud computing infrastructures
is a very complex task for small and medium-sized
enterprises. It requires a lot of effort to be taken be-
cause it is mandatory to do a detailed risk assessment
and analysis and create detailed documentation of the
efforts taken. ClouDAT provides a full fledged frame-
work to support small and medium-sized enterprises
in the cloud system certification process based on
ISO27001. It consists of a detailed workflow on how
to conduct the risk analysis and contains detailed lists
of assets, requirements, threats, risks and controls to
support the user during assesment phases. ClouDAT
allows the user to analyse a modeled scenario both
using integrated analysis methods and external anal-
ysis tools, thus exposing potential certification prob-
lems during analysis. Furthermore ClouDAT allows
the automatic generation of ISO27001 compliant cer-
tification document, which helps the user in the certi-
fication process.
ACKNOWLEDGEMENTS
This work was performed in the project ClouDAT
which was supported by the Ministry of Innovation,
Science, Research and Technology of the German
State of North Rhine-Westphalia and EFRE under
grant number 300267102.
Fifth International Symposium on Business Modeling and Software Design
72

REFERENCES
Alebrahim, A., Hatebur, D., and Goeke, L. (2014). Pattern-
based and ISO 27001 compliant risk analysis for cloud
systems. In Evolving Security and Privacy Require-
ments Engineering (ESPRE), 2014 IEEE 1st Work-
shop on, pages 42–47.
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz,
R. H., Konwinski, A., Lee, G., Patterson, D. A.,
Rabkin, A., Stoica, I., and Zaharia, M. (2009). Above
the clouds: A berkeley view of cloud computing.
Technical Report UCB/EECS-2009-28, EECS De-
partment, University of California, Berkeley.
Beckers, K., Schmidt, H., Kuster, J., and Fassbender, S.
(2011). Pattern-Based Support for Context Establish-
ment and Asset Identification of the ISO 27000 in the
Field of Cloud Computing. In Availability, Reliability
and Security (ARES), 2011 Sixth International Con-
ference on, pages 327–333.
CARiSMA (2015). Carisma framework. https://www-
secse.cs.tu-dortmund.de/carisma/.
Cloud Security Alliance (2011). Security guidance
for critical areas of focus in cloud computing
v3.0. https://downloads.cloudsecurityalliance.org/ ini-
tiatives/guidance/csaguide.v3.0.pdf.
Cloud Security Alliance (2013). The notorious
nine cloud computing top threats in 2013.
https://cloudsecurityalliance.org/download/the-
notorious-nine-cloud-computing-top-threats-in-
2013/.
Cloud Security Alliance (2014). Cloud Control Ma-
trix. https://downloads.cloudsecurityalliance.org/init
iatives/ccm/ccm-v3.0.1.zip.
ClouDAT (2015). Cloudat project. http://ti.uni-
due.de/ti/clouddat/de/.
DISA (2015). Application Security and Development
STIG V3 R10. http://iase.disa.mil/stigs/Documents/
U Application Security and Development V3R4
STIG.zip.
European Network and Information Security Agency
(2009). Cloud computing - benefits, risks
and recommendations for information security.
https://resilience.enisa.europa.eu/cloud-security-and-
resilience/publications/cloud-computing-benefits-
risks-and-recommendations-for-information-security.
Fernandez-Buglioni, E. (2013). Security Patterns in Prac-
tice: Designing Secure Architectures Using Software
Patterns. Wiley Publishing, 1st edition.
Fern
´
andez-Medina, E., J
¨
urjens, J., Trujillo, J., and Jajodia,
S. (2009). Model-driven development for secure infor-
mation systems. Information & Software Technology,
51(5):809–814.
Heiser, J. and Nicolett, M. (2008). Assess-
ing the security risks of cloud computing.
https://www.gartner.com/doc/685308/assessing-
security-risks-cloud-computing.
ISO (2008). ISO/IEC 27005 Information technology - Se-
curity techniques -Information security risk manage-
ment. ISO 27005:2008, International Organization for
Standardization, Geneva, Switzerland.
ISO (2013). ISO/IEC 27001 Information Security Manage-
ment System (ISMS) standard. ISO 27001:2013, In-
ternational Organization for Standardization, Geneva,
Switzerland.
ISO (2014). ISO/IEC 27000 Information technology Secu-
rity techniques Information security management sys-
tems Overview and vocabulary. ISO 27000:2014, In-
ternational Organization for Standardization, Geneva,
Switzerland.
Jin, X., Sandhu, R., and Krishnan, R. (2012). Rabac: Role-
centric attribute-based access control. In Proceedings
of the 6th International Conference on Mathematical
Methods, Models and Architectures for Computer Net-
work Security: Computer Network Security, MMM-
ACNS’12, pages 84–96, Berlin, Heidelberg. Springer-
Verlag.
J
¨
urjens, J. (2000). Secure information flow for concurrent
processes. In 11th International Conference on Con-
currency Theory (CONCUR 2000), volume 1877 of
Lecture Notes in Computer Science, pages 395–409.
Springer Verlag.
J
¨
urjens, J. (2001). Modelling audit security for smart-card
payment schemes with UMLsec. In 16th International
Conference on Information Security (IFIPSEC”01),
pages 93–108. IFIP, Kluwer.
J
¨
urjens, J. (2005a). Secure Systems Development with UML.
Springer. Chinese translation: Tsinghua University
Press, Beijing 2009.
J
¨
urjens, J. (2005b). Verification of low-level crypto-
protocol implementations using automated theorem
proving. In 3rd ACM & IEEE International Confer-
ence on Formal Methods and Models for Co-Design
(MEMOCODE 2005), pages 89–98. Institute of Elec-
trical and Electronics Engineers.
J
¨
urjens, J. and Wimmel, G. (2001a). Formally testing fail-
safety of electronic purse protocols. In 16th Interna-
tional Conference on Automated Software Engineer-
ing (ASE 2001), pages 408–411. IEEE.
J
¨
urjens, J. and Wimmel, G. (2001b). Security modelling
for electronic commerce: The Common Electronic
Purse Specifications. In First IFIP Conference on
e-Commerce, e-Business, and e-Government (I3E),
pages 489–505. Kluwer.
National Institute for Standards and Technology (2011).
The NIST Definition of Cloud Computing. Technical
report, Special Publication 800-145 of the National
Institute of Standards and Technology (NIST).
http://csrc.nist.gov/publications/nistpubs/800-
145/SP800-145.pdf.
Nist and Aroms, E. (2012). NIST Special Pub-
lication 800-53 Revision 4 Recommended
Security Controls for Federal Information
Systems and Organizations. CreateSpace,
Paramount, CA. http://nvlpubs.nist.gov/nistpubs/
SpecialPublications/NIST.SP.800-53r4.pdf.
Supporting the Security Certification of Cloud-Computing-Infrastructures
73

Ratiu, D., Feilkas, M., and J
¨
urjens, J. (2008). Extracting
domain ontologies from domain specific apis. In 12th
European Conference on Software Maintenance and
Reengineering (CSMR 08), pages 203–212. IEEE.
Fifth International Symposium on Business Modeling and Software Design
74