Ontology-based Analysis of Compliance and Regulatory Requirements of
Business Processes
Thorsten Humberg
2
, Christian Wessel
1
, Daniel Poggenpohl
2
, Sven Wenzel
1
,
Thomas Ruhroth
1
and Jan J
¨
urjens
1,2
1
Chair of Software Engineering, Technical University Dortmund, Dortmund, Germany
2
Fraunhofer ISST, 44227 Dortmund, Germany
Keywords:
Cloud Computing, Compliance, Business Processes, Risks, Ontologies.
Abstract:
Despite its significant potential benefits, the concept of Cloud Computing is still regarded with skepticism in
most companies. One of the main obstacle is posed by concerns about the systems’ security and compliance
issues. Examining system and process models for compliance manually is time-consuming and error-prone,
in particular due to the mere extent of potentially relevant sources of security and compliance concerns that
have to be considered. This paper proposes techniques to ease these problems by providing support in
identifying relevant aspects, as well as suggesting possible methods (from an existing pool of such) to actually
check a given model. We developed a two-step approach: At first, we build an ontology to formalize rules
from relevant standards, augmented with additional semantic information. This ontology is then utilized in
the analysis of an actual model of a system or a business process in order to detect possible compliance
obligations.
1 INTRODUCTION
Cloud computing is generally regarded to be one of
the major developments in information technology in
recent years. Substituting existing self-maintained
hard- and software with resources rented on an on-
demand basis offers significant potential benefits, in
particular a possible reduction of costs as well as a
gain in flexibility. Especially for small and medium-
sized businesses (SMB) it might be an appealing al-
ternative to maintaining their own data centers.
However, running business processes in cloud en-
vironments poses new issues with respect to compli-
ance and security compared to locally hosted solu-
tions. Legal regulations such as data protection laws
or the European directive Solvency II cause additional
requirements to business processes and underlying
software systems. Hence, before outsourcing a pro-
cess or parts of it into the cloud, the processes and
systems have to be checked with respect to these re-
quirements.
Parts of this work have been funded financially
by BMBF grants 01IS11008C and 01IS11008D (Secure-
Clouds).
In this paper, we present a two-step approach to
support compliant and secure outsourcing of business
processes. We use the concept of ontologies to for-
malize various standards that contain regulations re-
garding IT-security as well as compliance aspects. We
show how this can be applied to capture the content
of these sources in a unified way, and detect depen-
dencies and references between different source doc-
uments. Using this basic regulatory ontology, we en-
hance it with further semantic information concerning
the actual aspects dealt with in particular parts of the
regulatory documents.
When using this collection of information in an
actual analysis of a system or process, it is possible to
identify specific situations that require further analy-
sis to test if the constraints they impose on a process
are met in the model. The constraints can be used to
suggest corresponding examination methods from a
repository of possible (automated) checks.
The tools developed to support our approach
are integrated into the model-based environment
CARiSMA.
In the following section, we give an overview
about the background concepts relevant to our ap-
553
Humberg T., Wessel C., Poggenpohl D., Wenzel S., Ruhroth T. and Jürjens J..
Ontology-based Analysis of Compliance and Regulatory Requirements of Business Processes.
DOI: 10.5220/0004505405530561
In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CloudSecGov-2013), pages 553-561
ISBN: 978-989-8565-52-5
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
proach. Section 3 presents the internal structure of our
ontology as well as to how it can be created based on
diverging sources of input. After formalizing the in-
formation, it can be used to investigate given models
for situations to be considered (see Section 4). Sec-
tion 5 presents various tools that have been integrated
in the model analysis tool CARiSMA to support our
analysis process. Related work is presented in section
6, followed by a discussion of our approach as well as
possible future developments in Section 7.
2 BACKGROUND
For the understanding of our work it is necessary
to introduce some terms first before we explain our
approach of ontology-based compliance analysis of
business processes in the next section.
2.1 Cloud Computing
Cloud Computing is subdivided into three layers
named service levels as defined by The American Na-
tional Institute of Standards and Technology (NIST).
We will provide a short decription of these layers. In-
frastructure as a Service (IaaS), is the lowest layer
providing basic virtual hardware resources. This may
include virtual machines or networks. Platform as a
Service (PaaS), represents a middleware for writing
distributed and scalable software, which resides upon
the IaaS layer. Software as a Service (SaaS) is the
top-most layer with ready-to-use software which was
built using PaaS solutions.
Different security needs have to be considered de-
pending on the chosen service level. In the case of
an IaaS service all security needs have to be installed
and checked starting from the operating system and
ending with the software that is executed on it be-
cause only virtual hardware is provided by the ser-
vice provider. All security requirements are in the
hands of the customer of the cloud service. On the
next level the chosen PaaS solution has to meet the
security needs necessary to build applications on top
of it. Finally on the level of SaaS software must be
chosen that fulfills the security requirements.
Furthermore the required security level depends
on other characteristics like the deployment model,
e.g., private cloud versus public clouds. While private
clouds can be considered relatively secure against at-
tacks from outside they are exposed to internal attack-
ers. Public clouds on the other hand need to be pro-
tected against attacks from the outside.
2.2 Risk & Compliance
In this paper we speak of risks meaning the compo-
nents mentioned in the IT-Grundschutz Catalogues
(Bundesamt f
¨
ur Sicherheit in der Informationstech-
nik, 2006). We do not consider probability of oc-
curence or amount of damage caused by them. Risks
in our understanding are IT security related while
compliance is seen as laws or internal regulations
which have to be held. There exists a tight bound-
ing between security risk, security and compliance as
for example compliance rules are not met when an
attacker is able to retrieve personal data from a not
properly secured server.
Risks. In this context a risk is defined as an IT secu-
rity related vulnerability in a business process which
is executed in a cloud environment. Examples are
unsecured communication channels between cloud
hosts, insufficient rights management or processing of
confidential data.
Compliance. A security analysis on the cloud com-
puting environment should be carried out before a se-
curity requirement analysis is performed on the busi-
ness operation. This will yield the maximum number
of security requirements that can be met.
The conformance to compliance regulations
should be audited on three levels.
Process & compliance analysis: Documents from
which business processes can be derived should be
analyzed.
Our approach considers processes given in form
of process models (e.g. UML activity diagrams or
BPMN models). The risk analysis also works on less
structured documents such as textual process descrip-
tions.
Design Time Compliance. The implementation of a
business process has to comply with legal regulations
and company policies. The focus here is the cloud
interface, the process steps within the cloud and the
data flows between the cloud and the user.
Runtime Compliance. It has to be ensured that all
compliance-relevant and critical processes (esp. those
outsourced into a cloud) are monitored and logged.
Such a monitoring can be performed using business
process mining and conformance checking (van der
Aalst et al., 2007). It is not further considered in this
paper.
2.3 Ontologies
Ontologies are often used to describe incomplete in-
formation about an area. In contrast to models hav-
ing a closed world assumption, ontologies employ an
open world assumption. In this paper we use the
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
554
Figure 1: Part of the ontology’s class structure: Rule,
RuleElement, and subclasses.
Web Ontology Language (OWL) (W3C OWL Work-
ing Group, 2012). OWL knows three profiles which
differ in expressiveness and the possibility to rea-
son about facts in the ontology. The least expres-
sive profile is OWL-Lite. The OWL profile OWL-DL
is semantically equivalent to the Description Logic
(Baader et al., 2003). And OWL-FULL allows on
one hand the largest expressiveness but is on the other
hand not always decidable.
In this paper we use OWL-FULL for the sake of
simplicity. It allows us to use smaller ontologies in
our context.
A graphical representation of an ontology is de-
picted in Fig. 1: The basic elements of ontologies
are the classes (also called concepts, depicted as rect-
angles, e.g., Rule) and the individuals (ovals, e.g.
Plan Investment). Classes can be seen as a set of indi-
viduals sharing common properties. The membership
of an individual to a class is depicted using a dashed
line with a triangle arrow. Thus Approve Investment
is an individual in the class Activity. The concepts can
be related by an is-a relation (solid line with triangle
arrow, e.g. MARiskRule is-a Rule), describing that
all individuals of a class also belong to the superclass.
Classes can be defined directly or by operations like
the intersection of classes.
To express that individuals are related to each
other we use roles between them. Since roles are used
as a directed property, we use as a graphical represen-
tation an arrow (see. Fig. 1) together with a describing
name.
3 REGULATORY ONTOLOGY
The principle of ontologies is especially suited for for-
malizing compliance regulations. With the classifica-
tion provided by distinct concepts, information can be
represented in a structured way, allowing for its uti-
lization in automated analysis methods. At the same
Figure 2: Main concepts of the regulatory ontology.
time, it is still possible to capture the diverse struc-
tures found in different types of relevant input stan-
dards. Furthermore, it is possible to express relations
between entities across different inputs.
An outline of our ontology used to store the com-
pliance information is given in Figure 2. All classes to
be used are derived from one of the depicted groups.
Rule. Individuals of this class and its subconcepts
are used to store the information directly imported
from the source documents.
RuleElements. contain semantical enhancements,
describing different aspects a rule can refer to, e.g.
referred activities and roles.
Situation. represents a more complex setting given
by a rule, e.g. the referenced concept of Separa-
tion of Duty.
Constraint. indicates how a specific situation can be
(automatically) checked in a given model.
In the following sections, these classes are ex-
plained in more detail.
3.1 Rules
Depending on the scope of the analysis, different
standards are relevant. Some are focused on IT-
security, e.g. the ISO 27k series (ISO, 2005) or the IT-
Grundschutz Catalogues (Bundesamt f
¨
ur Sicherheit in
der Informationstechnik, 2006) published by the Ger-
man Federal Office for Information Security (BSI).
Particularly important in the field of cloud computing
are regulations concerning compliance issues. Exam-
ples include national laws regarding data privacy and
regulations relevant to specific sectors, e.g. Solvency
II for financial institutions.
Regulations are generally given in the form of tex-
tual descriptions, with differing internal structures,
thus being inconvenient for automated processing. To
overcome these restrictions, it is necessary to repre-
sent their content in a unified way.
The ontology’s concept of classes with inheritance
offers a method to capture those structures in a way
Ontology-basedAnalysisofComplianceandRegulatoryRequirementsofBusinessProcesses
555
that on the one hand preserves this information, but
on the other hand still provides enough uniformity to
use automated analysis methods.
Two types of classes are used at this stage: Those
that contain the actual content, and others that repre-
sent the structure the content is organised in. Both
classes are derived from Rule, but only the classes
forming the content are evaluated in our automated
processing.
Additionally, object properties are used to capture
references between rules. These references may ex-
ist between rules within the same standard as well as
between different input sources.
An example is shown in Figure 1: The left hand
side shows how the concept MARiskBinding is de-
rived from Rule via several steps, and instantiated
by the individual MARiskVA 7.2.1 B1, representing a
specific entry from the document.
Creating the basic individuals representing the
content of a standard is mainly a transformation. The
generation of this stage can in general be fully auto-
mated, depending on the format the input is available
in. For example, the catalogues provided by the BSI
are available in HTML format and allow for an auto-
matic conversion into the ontology.
3.2 Rule Elements
Based on the mere representation of the content, the
ontology can be enriched with further details, namely
Rule Elements.
An individual of the concept RuleElement (or
subconcept thereof) can constitute any aspect relevant
for a rule contained in the ontology.
Currently we define five types of elements. New
concepts can easily be added as required.
Artifact. Representing objects a standard refers to,
e.g. documents or IT hardware
Role. Specific roles mentioned, e.g. executives or
data protection officer
Activity. Certain action, i.e. from a business process
model, e.g. reporting required information
Process. A more complex operation, potentially in-
volving several activities
Property. Requirements demanded by a standard,
e.g. confidentiality or non-repudiation
The usage of rule elements directly yields the pos-
sible application of related properties: There are prop-
erty relations from individuals of class Rule (or sub-
classes thereof) to those individuals representing rule
elements that are relevant for the particular rule.
Object properties between instances of rule ele-
ments can be added to the ontology, but are currently
not evaluated in our approach.
In contrast to converting the text content, identifi-
cation of rule elements requires the interpretation of
the textual representation. Given this problem, it is
not yet possible to fully automate this step. As a first
foundation we defined a set of typical elements with
associated keywords. Identifying those keywords, or
synonyms thereof, can be used to generate occurences
of specific elements.
In order to fully utilize the advantages of the ap-
proach, a manual enhancement is still necessary. A
specialized tool for this purpose is integrated into our
environment and described in Section 5.
3.3 Situations and Constraints
Based on rule elements, we define situations as
generic patterns that can occur in an examined
model. Within the ontology, a situation links to a
set of rule elements (via the InvolvedRuleElement-
property). The presence of those elements in a model
indicates the possible relevance of the particular sit-
uation. Additionally, an object property links to the
particular rules the situation originates from.
A popular example is the need to implement the
separation of duty pattern within a business pro-
cess: In this case, a pair of activities must not be
executed by the same person. The involved ele-
ments in this case are instances of the two activ-
ities. This is modeled in the ontology as shown
in Figure 3: SeparationOfDuty is an individual of
the concept Situation, described in the Rule indi-
vidual MARiskVA 7.2.1 B1. It forbids the activities
Plan Investment and Approve Investment to be car-
ried out by the same person. As shown in Figure 1,
both activities are instanciated from the RuleElement
concept Activity.
To contain this specific situation, an actual
business process model must thus contain two
activities corresponding to Plan Investment and
Approve Investment. Details on how those are iden-
tified are given in section 4.
Though a situation does not in itself contain infor-
mation about how it is to be tested on an actual model,
it can reference to individuals of the class Constraint.
If a process contains a situation, the corresponding
constraints of the situation have to be respected for
the process to be secure. The constraints can be fur-
ther parameterized using rule elements. Only rule ele-
ments applicable to the situation, i.e. associated with
the rules involved in it, can be used as parameters.
Constraints can vary in their implementation, ranging
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
556
Figure 3: Extract from the ontology, representing the Situa-
tion ”Separation of Duties”.
from textual descriptions to automated checks avail-
able in the CARiSMA framework.
Formalizing possible situations and assigning ap-
propriate constraints is a manual task as well. It con-
sists of identifying the necessary components and cre-
ating a new individual for this situation.
The generation of this compliance ontology is a
general preparation step for our process analysis. Re-
gardless, it is only defined by the considered input
standards.
4 PROCESS ANALYSIS
In the previous section we showed how the ontol-
ogy used by the analysis process is designed and cre-
ated to support the analysis of business processes. In
this section we explain how compliance and regula-
tory requirements in business processes are identified
and verified. The input for this process is a formal
model of the business process in form of e.g. a BPMN
model and the ontology containing the necessary reg-
ulations.
The analysis itself consists of three steps, namely:
1. Identification of relevant rule elements (i.e. situa-
tions in which this rule elements occur) within the
regulations applicable to the business process that
should be analyzed.
2. Mapping of the business process model elements
to rule elements of the applicable situation.
3. Verification of the rule element constraints im-
posed by the situation. An example would be a
check testing whether a separation of duty con-
straint on the business process is met.
Figure 4 gives a global view over the analysis pro-
cess. The process is discussed in more detail in what
follows.
Identification of Relevant Rules. For the first step
in the analysis process it is necessary to identify sit-
uations (see Section 3.2) in the process model which
have to be checked. As shown in the previous section
a situation consists of one or more rules and part of
the rule elements present in these rules, which may
be involved persons (roles), objects or activities.
For example in the separation of duty constraint
mentioned before, there are two actions involved:
Plan Investment and Approve Investment”. As
these are individuals of the concept Activity they can
be seen as keywords during a search for the situation
“separation of duty (SoD)”. The idea behind this is to
test the names of the activities of the business process
model for accordance with individuals of the ontol-
ogy. In this step all labels of all model elements (e.g.
text comments, labels on transitions, etc.) of the ana-
lyzed process are tested.
If all rule elements of a situation can be found
among the labels of a business process model, the
according checks for this situation will be suggested
to the user. Since the search for an exact match be-
tween an activity name and a name of an individual
may be ineffective, we utilize word databases which
consider co-occurrent words and synonyms of an ac-
tivity name. Thereby we utilize the following scoring
system.
First we define a constant score s. If a word of a
label is found directly as a keyword of a i-th rule ele-
ment it will produce a score s
i
= s. We define a score
s
i
=
s
2
for matches found via synonyms of the word
of the label because it is not the original word but
at least semantically equivalent. Matches found with
co-occurrent words have the lowest score of s
i
=
s
4
since the original word of the label is not involved
any more. The final score S is then calculated with
S =
n
i=1
s
i
where n is the number of rule elements
which are involved in the specific situation. M is de-
fined as the maximum reachable score, which is built
using n × s, where n is the above-mentioned number
of rule elements the situation is built of. We avoid
too many false-positive matches by discarding those
below a certain threshold t. Therefore only matches
which satisfy M S < t are considered for the subse-
quent analysis.
In order to get an almost complete set of appli-
cable situations for a given business process model
we expand the result by other potential situations
which may be of interest to test. Usually regulations
have cross references to other associated regulations.
These can be found easily utilizing the ontology de-
scribed in the previous section.
For example the SoD mentioned above is a
Situation individual which has an involved rule
Ontology-basedAnalysisofComplianceandRegulatoryRequirementsofBusinessProcesses
557
Figure 4: Business Process Analysis Overview.
(an object property) MaRiskVA 7.2.1 B1 which is
a MARiskBinding individual. MaRiskVA 7.2.1 B1
may have object properties to instances of other rules.
Situations associated to these rules are added to the
result set and their corresponding checks are addition-
ally recommended to the user.
Mapping of Elements. Every situation has one or
more constraints that have to be met by the an-
alyzed process model. Some of these constraints
could be verified with the aid of specialized tools,
e.g. CARiSMA. In order to realize tool-based check-
ing of situations it is necessary to specify the parame-
ters, i.e. to name the actors, the activities and objects
used in a specific situation. Therefore the second step
in the analysis process is to map the elements of the
business process model to parameters of the check.
This is a manual task, because model elements can be
named individually by the modeler of the process. For
example the name of the applicant role in the separa-
tion of duty scenario may be an arbitrary value, which
can not be determined automatically.
Constraint Checking. After all model elements
have been mapped to rule elements the constraints for
a specific situation can be verified. This can be ac-
complished in various ways. A constraint may be ver-
ified by an automated test routine that systematically
analyzes a given formal model, e.g. a BPMN or UML
model with regard to whether specific requirements
for a model are met.
Automated verification may be implemented as a
CARiSMA check. In this case, the mapping of con-
straints of the ontology to corresponding checks in
CARiSMA is stored in a file separate from the ontol-
ogy. Doing this, the ontology itself remains reusable
and uncluttered by implementation-specific informa-
tion.
5 TOOL SUPPORT
This section provides an overview of the various
implementation efforts providing the tool support for
creating and editing the regulatory ontology used dur-
ing the analysis. The tools have been integrated
with CARiSMA
2
, our Eclipse-based environment for
model analysis. First we describe the extractor used
to create the ontology using various law documents.
We then show the front end with which one is able to
create the various other concepts and relations of the
ontology. The enriched ontology can be used during
process analysis to determine the checks to use during
an analysis. The CARiSMA Situation Finder Check
is one possible way to identify applicable situations.
The process tool chain is visualized in Figure 5.
Law Extractor. This tool parses regulatory doc-
uments of various formats to create the rule indi-
viduals of the regulatory ontology. Currently sup-
ported are the MARisk (Bundesanstalt f
¨
ur Finanzdi-
enstleistungsaufsicht, 2012), the BDSG (Bundesre-
publik Deutschland, 1990) and BGB (Bundesrepub-
lik Deutschland, 1896), and the BSI catalogues (Bun-
desamt f
¨
ur Sicherheit in der Informationstechnik,
2006). The resulting OWL ontology can then be mod-
ified using the following tools.
Regulatory Ontology Editor. After extracting the
rules, the ontology can then be enriched with the reg-
ulatory ontology editor depicted in Figure 6. Text pas-
sages can be marked and stored as individuals of the
rule element subconcepts. Situations can be created
by selecting the rule elements that comprise the situa-
tion and naming it appropriately. Constraints that can
be imposed on situations are parameterized with rule
element subconcepts. Constraint individuals can then
be assigned to situations, using the situational rule el-
ements to set the parameters of the constraint.
2
http://carisma.umlsec.de
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
558
Figure 5: Regulatory Toolchain.
Figure 6: Regulatory Ontology Editor.
In addition to the integrated GUI, we have imple-
mented a web-based version provides the possibility
for distributed access to the ontology.
Situation Finder Check. There are many possible
solutions to determine which situations apply during
the execution of a given process. As an exemplary im-
plementation of the methods for situation identifica-
tion the Situation Finder checks if a given BPMN pro-
cess model contains all the rule elements that define a
situation. If all are present in the process, the check
then outputs the appropriate checks that should be run
on the given model in order to verify its validity with
regards to the regulations. Other methods for iden-
tifying situations could potentially involve references
between rules or weighted approximations based on
the types of rule elements in a situation.
Checks for Process Analysis. CARiSMA provides
some checks that support the automated process anal-
ysis of models. For example, the check for the above-
mentioned SoD constraint analyzes whether the con-
flicting actions are executed by different actors. In the
case of a BPMN model this is achieved by checking
the lanes the actions are embedded in. If the actions
are in different lanes, the actors are different and the
test passes. If the actions are in the same lane, the test
fails and the check reports this to the user. Success
or failure of the check is reported in two ways. On
the one hand a textual report is generated and on the
other hand the user is informed in a graphical manner
by coloring of the failed actions directly in the dia-
gram.
Ontology-basedAnalysisofComplianceandRegulatoryRequirementsofBusinessProcesses
559
6 RELATED WORK
The fulfillment of compliance and security require-
ments in business processes is essential to receive ac-
ceptance from customers. An approach to encode
and check security requirements in BPMN models has
been presented Wolter et. al. (Wolter et al., 2008).
However, these requirements focus only on closed
systems.
Cloud computing, which has lasted on the peak
of Gartner’s technology hype cycle (Dixon and Jones,
2011) for quite a while now, leads to outsourcing of
processes into heterogeneous environments. The use
of cloud computing technologies offers economic po-
tential for small and medium-sized enterprises. How-
ever, serious doubts wrt. security and compliance ex-
ist (BITKOM, 2009). Hence, security approaches
for closed systems are not eligible here. Menzel
et. al. (Menzel et al., 2009) propose an approach to
define security requirements on service orchestration
level.
CloudCycle
3
is a project related to our approach.
It focuses on cloud providers and offers services that
allow them to guarantee their customers that they are
compliant with security policies and further regula-
tions. The approach of CloudCycle is a suitable com-
plement for our approach. Once business processes
are successfully outsourced into the cloud their secu-
rity and compliance can be monitored.
Ontologies for cloud computing and cloud secu-
rity have been presented by Gr
¨
auler et. al. (Gr
¨
auler
et al., 2011). They analyzed the different sources of
risks within cloud computing environments and man-
ifested them in an ontology. Based on that ontology,
they provide a database of cloud providers that allows
users to select a provider based on certain security
properties. This is especially interesting for finding a
suitable cloud provider after potential risks of a busi-
ness process have been revealed by our approach.
Tsoumas and Gritzalis provide an ontology-based
approach to organize security knowledge (Tsoumas
and Gritzalis, 2006). It is designed to enable reuse
of knowledge and map requirements to implemented
controls of a system. A similar approach to formal-
ize security knowledge has been presented by Fenz
and Ekelhart (Fenz and Ekelhart, 2009). It focuses
on representing security domain knowledge and cor-
porate knowledge in an ontology. While we pro-
vide a systematic approach to represent the regula-
tory documents and to extract security or compli-
ance requirements, the above-mentioned approaches
consider only the modeling resulting security knowl-
edge. It would be interesting to consider an integra-
3
http://www.cloudcycle.org
tion of those approaches such that they could be used
to represent the knowledge that is extracted by our ap-
proach.
Peschke et. al. (Peschke et al., 2011) present the
RiskFinder which is a precursor of our risk analysis
component. It analyses UML models with respect to
security relevant vocabulary. Schneider et. al. propose
a heuristic search based on Bayesian filters (Schneider
et al., 2011). HeRA realizes a feedback-driven ap-
proach for security analysis during requirements en-
gineering (Knauss et al., 2009). These approaches
provide powerful rules, however, they work only on
single words and do not consider language databases.
Our view of IT security risks corresponds to the
use in the BSI IT-Grundschutz Catalogues (Bunde-
samt f
¨
ur Sicherheit in der Informationstechnik, 2006),
which does not include concrete values for probabil-
ities and possible extend of damage (or benefit) of
risks. In the terminology defined by other standards,
this information is included, e.g. in the ISO 27000
series (ISO, 2008) and NIST standard 800-39 (NIST
and Aroms, 2012).
7 CONCLUSIONS & OUTLOOK
When outsourcing existing or new processes into
cloud environments, problems regarding security and
compliance still represent major obstacles. The
methodology described in this paper aims at support-
ing users in examining models of their systems and
processes for potential risks. While a completely au-
tomated analysis still appears far from feasible, our
approach and tools can aid in highlighting aspects that
require further examination, either manually or tool-
supported.
Using ontologies, one can take advantage of a very
flexible, yet formalized, way of representing informa-
tion, making it accessible for automated procedures.
To further develop our concept, several points
seem worth considering. Those include enhancement
of tool-support, improvement of existing heuristics
for the detection of matchings as well as support for
established methods in knowledge systems, e.g. auto-
mated reasoning.
REFERENCES
Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D.,
and Patel-Schneider, P. F., editors (2003). The descrip-
tion logic handbook: theory, implementation, and ap-
plications. Cambridge University Press, New York,
NY, USA.
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
560
BITKOM (2009). Cloud-Computing - Evolution in der
Technik. Technical report, BITKOM.
Bundesamt f
¨
ur Sicherheit in der Informationstechnik
(2006). BSI-Grundschutz Katalog. https://www.bsi.
bund.de/ContentBSI/EN/Topics/ITGrundschutz/
itgrundschutz.html.
Bundesanstalt f
¨
ur Finanzdienstleistungsaufsicht (2012).
Mindestanforderungen an das Risikomanagement -
MaRisk. http://www.bafin.de/SharedDocs/Veroeffent
lichungen/DE/Rundschreiben/rs 1210 marisk ba.html.
Bundesrepublik Deutschland, vertreten durch das Bun-
desministerium der Justiz, v. d. d. B. d. J. (1896).
B
¨
urgerliches gesetzbuch.
Bundesrepublik Deutschland, vertreten durch das Bun-
desministerium der Justiz, v. d. d. B. d. J. (1990). Bun-
desdatenschutzgesetz.
Dixon, J. and Jones, T. (2011). Hype cycle for business
process management. Technical report, Gartner Study.
Fenz, S. and Ekelhart, A. (2009). Formalizing information
security knowledge. In Proceedings of the 4th Inter-
national Symposium on Information, Computer, and
Communications Security (ASIACCS ), page 183, New
York, New York, USA. ACM Press.
Gr
¨
auler, M., Martens, and B.; Teuteberg, F. (2011). IT-
Sicherheitsmanagement im Cloud Computing - En-
twicklung und Implementierung einer Ontologie. In
Proceedings zur INFORMATIK 2011.
ISO (2005). ISO27001: Information Security Man-
agement System (ISMS) standard. Online:
http://www.27000.org/iso-27001.htm.
ISO (2008). ISO27005: Information security risk manage-
ment. Online: http://www.27000.org/iso-27005.htm.
Knauss, E., Lubke, D., and Meyer, S. (2009). Feedback-
driven requirements engineering: The Heuristic Re-
quirements Assistant. In Proceedings of the 31st Inter-
national Conference on Software Engineering, ICSE
’09, pages 587–590, Washington, DC, USA. IEEE
Computer Society.
Menzel, M., Thomas, I., and Meinel, C. (2009). Security re-
quirements specification in service-oriented business
process management. In ARES.
NIST and Aroms, E. (2012). NIST Special Publica-
tion 800-39 Managing Information Security Risk.
CreateSpace, Paramount, CA.
Peschke, M., Hirsch, M., J
¨
urjens, J., and Braun, S.
(2011). Werkzeuggest
¨
utzte Identifikation von IT-
Sicherheitsrisiken. In D-A-CH Security 2011.
Schneider, K., Knauss, E., Houmb, S., Islam, S., and
J
¨
urjens, J. (2011). Enhancing security requirements
engineering by organizational learning. Requirements
Engineering, pages 1–22. 10.1007/s00766-011-0141-
0.
Tsoumas, B. and Gritzalis, D. (2006). Towards an
Ontology-based Security Management. In Proceed-
ings of the 20th International Conference on Ad-
vanced Information Networking and Applications
(AINA), volume 1, pages 985–992. IEEE.
van der Aalst, W., Reijers, H., Weijters, A., Vandongen,
B., Alvesdemedeiros, A., and M. Song, H. V. (2007).
Business process mining: An industrial application.
Information Systems, Vol. 32, No. 5, pp. 713-732.
W3C OWL Working Group (11 December 2012). OWL 2
Web Ontology Language: Document Overview (Sec-
ond Edition). W3C Recommendation. Available at
http://www.w3.org/TR/owl2-overview/.
Wolter, C., Menzel, M., and Meinel, C. (2008). Modelling
security goals in business processes. In Modellierung.
Ontology-basedAnalysisofComplianceandRegulatoryRequirementsofBusinessProcesses
561