Ontology-based Analysis of Compliance and Regulatory Requirements of

Business Processes

Thorsten Humberg

, Christian Wessel

, Daniel Poggenpohl

, Sven Wenzel

Thomas Ruhroth

and Jan J

urjens

1,2

Chair of Software Engineering, Technical University Dortmund, Dortmund, Germany

Fraunhofer ISST, 44227 Dortmund, Germany

Keywords:

Cloud Computing, Compliance, Business Processes, Risks, Ontologies.

Abstract:

Despite its signiﬁcant potential beneﬁts, 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 ﬁrst, 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 signiﬁcant potential beneﬁts, in

particular a possible reduction of costs as well as a

gain in ﬂexibility. 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 ﬁnancially

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 uniﬁed 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 speciﬁc 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

 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 ﬁrst 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 deﬁned 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 fulﬁlls 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 deﬁned 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, insufﬁcient rights management or processing of

conﬁdential 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 ﬂows 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 proﬁles which

differ in expressiveness and the possibility to rea-

son about facts in the ontology. The least expres-

sive proﬁle is OWL-Lite. The OWL proﬁle 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 deﬁned 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 classiﬁca-

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 speciﬁc 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 Ofﬁce for Information Security (BSI).

Particularly important in the ﬁeld of cloud computing

are regulations concerning compliance issues. Exam-

ples include national laws regarding data privacy and

regulations relevant to speciﬁc sectors, e.g. Solvency

II for ﬁnancial 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 uniﬁed 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

speciﬁc 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 deﬁne ﬁve 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. Speciﬁc roles mentioned, e.g. executives or

data protection ofﬁcer

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. conﬁdentiality 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, identiﬁ-

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 ﬁrst

foundation we deﬁned a set of typical elements with

associated keywords. Identifying those keywords, or

synonyms thereof, can be used to generate occurences

of speciﬁc 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 deﬁne 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 speciﬁc situation, an actual

business process model must thus contain two

activities corresponding to Plan Investment and

Approve Investment. Details on how those are iden-

tiﬁed 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 deﬁned 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 identiﬁed

and veriﬁed. 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. Identiﬁcation 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. Veriﬁcation 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.

Identiﬁcation of Relevant Rules. For the ﬁrst 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 deﬁne 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

= s. We deﬁne a score

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

since the original word of the label is not involved

any more. The ﬁnal score S is then calculated with

S =

∑

i=1

where n is the number of rule elements

which are involved in the speciﬁc situation. M is de-

ﬁned 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 veriﬁed 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 speciﬁc 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 speciﬁc situation can be veriﬁed. This can be ac-

complished in various ways. A constraint may be ver-

iﬁed by an automated test routine that systematically

analyzes a given formal model, e.g. a BPMN or UML

model with regard to whether speciﬁc requirements

for a model are met.

Automated veriﬁcation 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 ﬁle separate from the ontol-

ogy. Doing this, the ontology itself remains reusable

and uncluttered by implementation-speciﬁc 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

, 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-

iﬁed 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.

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 identiﬁca-

tion the Situation Finder checks if a given BPMN pro-

cess model contains all the rule elements that deﬁne 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-

ﬂicting 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 fulﬁllment 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

deﬁne security requirements on service orchestration

level.

CloudCycle

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 ﬁnding 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-

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 ﬁlters (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 beneﬁt) of

risks. In the terminology deﬁned 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

ﬂexible, 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.baﬁn.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).

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.

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 speciﬁcation 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 Identiﬁkation von IT-

Sicherheitsrisiken. In D-A-CH Security 2011.

Schneider, K., Knauss, E., Houmb, S., Islam, S., and

urjens, J. (2011). Enhancing security requirements

engineering by organizational learning. Requirements

Engineering, pages 1–22. 10.1007/s00766-011-0141-

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