A Collaborative Risk Management Framework for Enterprise Architecture

Abstract

The occurrence of risks in an enterprise can result in differences between business goals and their realization. Risk management is a central activity in the design of an enterprise: risk assessments supports the identifications of problems that expose the enterprise to risk, while risk treatment plans are drivers for enterprise engineering. Risk treatment plans are typically created in isolation, and often informal. We deal with this problem by developing a collaborative risk management framework, that involves all levels of an organization in con-ducting risk assessments and formalizing the treatment plans. We propose procedures to perform an integrated risk analysis, as well as metrics to deal with the collaborative aspect of risk management.

Full text

A Collaborative Risk Management Framework for
Enterprise Architecture
Diana Marosin and Dirk van der Linden
CRP Henri Tudor, Luxembourg
Radboud University Nijmegen, the Netherlands
Email: {diana.marosin, dirk.vanderlinden}@tudor.lu
Sergio Sousa
POST Technologies
Luxemborug
Email: sergio.sousa@post.lu
Abstract—The occurrence of risks in an enterprise can result
in differences between business goals and their realization. Risk
management is a central activity in the design of an enterprise:
risk assessments supports the identifications of problems that
expose the enterprise to risk, while risk treatment plans are
drivers for enterprise engineering. Risk treatment plans are
typically created in isolation, and often informal. We deal with
this problem by developing a collaborative risk management
framework, that involves all levels of an organization in con-
ducting risk assessments and formalizing the treatment plans.
We propose procedures to perform an integrated risk analysis,
as well as metrics to deal with the collaborative aspect of risk
management.
Keywords—Enterprise Architecture, Collaborative Risk Man-
agement, Risk Treatment Plan, Project Management
I. INTRODUCTION
Enterprises seem to have a set of common drivers which
they apply in order to gain advantages from Enterprise En-
gineering (EE) approaches (e.g. business-IT alignment, cost
reduction, standardization, governance, agility, compliance
regulations, risk management). Risk management helps an
enterprise to achieve their objectives by taking decisions
about uncertain elements, caused both by internal and external
factors. Most risk management processes involve activities to
establish the context of the organization, clarify what criteria
should be used for establishing the significance of a risk,
assess risks, and treat them via the selection of risk treatment
options [1].
The focus of existing work is on providing tools and
techniques to support risk assessment: CORAS [2] is a model-
driven risk analysis approach that covers the whole risk man-
agement process and allows for the modelling of associated
concepts. Asnar et al. [3], [4] presented a modelling and
reasoning framework, the Tropos Goal-Risk Framework, which
considers risk at an organizational level. Other goal-oriented
modelling frameworks provide risk management capabilities,
such as KAOS and its security extension [5], Misuse cases
[6], Malactivity diagrams [7], BPMN [8], Secure-i* modelling
framework [9], and Secure Tropos [10], [11].
Although the preceding approaches deal with risk treatment
selection, their output remains a set of (generally disconnected)
requirements or countermeasures related to the risks. More-
over, the risk treatment’s plans, schedules, and costs are not
taken into account in the proposed formalisms. Our aim is
to provide a mechanism that involves more stakeholders in
the evaluation of risk and selections of treatment plans, as
different people might have different understandings about
specific risks.
A first step in formalizing risk treatment plans, in par-
ticular mitigation and avoidance was made by the authors
in [12]. They present a formal framework, eATO1, which
combines two methodologies (Attack-Defence-Trees from IT
security [13], [14] and goal-oriented modelling in order to aid
decision making, and to support a full analysis of enterprise
plans. Furthermore, the framework gives the option to model
and analyse multiple alternatives for the risk treatment plan.
Therefore, the eATO framework has provided a vocabulary
and formal procedures to represent risk assessments and risk
treatment plans in a coherent manner.
While eATO provides support for modelling a plan and the
associated risks (and in doing so adds value to the classical
quantitative/qualitative risk analysis and provides valuable
support for decision making [12]), the framework has some
problematic areas. Risk management should be performed at
all levels of an organization, starting from the strategic level
and refining the analysis to the implementation level [15], [1],
[16]. Information that is not properly or enough communicated
makes the traceability of decision taken at different levels of
an organisation hard to obtain. Furthermore, the assessment
and understanding of risks can differ as we sweep in between
different levels of the organisation. The occurrence and impact
of the same risk can differ from department to department,
based on the local available information or simply on the
experience of the stakeholders involved. This introduces a
coherency misalignment between the layers of the organi-
sation and influences negatively the power of reaction of
an organisation. The timely consistency of the organisation
is also affected. Therefore, by dealing with communication
and collaboration aspects we aim to create a truly integrated
tool, which will support enterprise risk management for all
enterprise activities, at different levels of abstraction. Col-
laborative risk management enhances and extends enterprise
risk management’s focus on the crucial interaction of cross-
functional and cross-organizational participation [17].
Communication is the most essential part of effective
project management and risk management [18], [19]. Project
teams, upper management, and executives should communicate
1The name of the framework signifies the three independent abstraction
levels at which it operates: Actions, Threats and Opportunities, extended with
the risk treatment layer (counter-measures) layer.

in a crisp, concise, complete, correct, and timely fashion [20].
Collaboration itself is a joint effort of multiple individuals or
work groups used to accomplish a common task or project,
and deliver outcomes that are not easily or effectively achieved
by working alone. Collaborative relationships are attractive for
organisations because the synergies realised by combining ef-
fort and expertise produce benefits greater than those achieved
through individual effort [21], [22].
The rest of this paper is structured as follows. In Section II
we recall the foundations of eATO. We introduce the running
example in Section III. In Section IV we set the foundations
of a collaborative framework. We present a collaborative at-
tribute domains (metrics) for our framework and we introduce
procedures for task assignment and delegation in Section V.
Outputs of the framework are presented in Section VI. We
conclude and set lines for future work in Section VII.
II. FO UN DATIO NS O F EATO
The key starting point of our framework is Attack-Defence-
Trees (ADT), which have been successfully used in IS Security
to model an attacker’s actions and their possible counter
measures [14], [13]. On basis of the ADTs we introduced an it-
erative approach for decision making based on risk assessment.
An ADT models security attacks and countermeasures using
conjunctive, disjunctive and attack nodes. In our framework
trees represent the enterprises goals instead of attacks, and
we introduce two additional notions: opportunity nodes and
exclusive disjunctive nodes [12].
A plan of an enterprise architecture includes the stakehold-
ers’ (strategic) goals and the means to achieve them. Each
goal is depicted in sub-goals, the architectural principles the
company should follow in order to achieve the goals, and
the atomic actions that need to be taken. A plan can be
represented as a tree. A root node represents a strategic goal
of the stakeholders. The children nodes represent architectural
principles or sub-goals. Each child of the tree can be refined
as follows: A conjunctively refined node is satisfied if all
of its children are fulfilled. A disjunctively refined node is
satisfied if at least one of its children is fulfilled. An exclusive
disjunctively refined node is satisfied iff one of its children is
fulfilled. Note that an exclusive refinement of a node represents
a decision, since choosing one option automatically contradicts
the other. A non-refined node of the tree is called a leaf. A
leaf node represents one atomic phase of the planning. It can
be an atomic action or a whole project.
In order to evaluate an eATO we define metrics and rules
that are propagated from the evaluated nodes to the entire
tree. The metrics are added in form of attributes assigned to
the different nodes and the propagation rules are defined in
a so-called “attribute domain”. An attribute domain contains
functions to compute the different types of nodes, and also the
influence of risks over actions and countermeasures over risks.
The mathematics behind the attribute domains will be left out,
as this paper aims in introducing work in progress.
III. RUNNING EXAMPLE
The running example we use is a case study of the fictional
company ArchiSurance [23], [24] and its plan of achieving
profitability [12]. ArchiSurance faces a number of challenges
regarding its business processes and information systems as
the result of a merger between three previously independent
insurance companies. The board’s main driver is simply to
increase the “Profit” (see Fig.1). After analysing the current
situation the board decided that, in order to increase the profit,
the company needs to work on “data consistency” and “cost
reduction”. These goals are further refined into three actions:
“create a single source of data”, “reduction of infrastructure
costs”, and “reduce personal costs”. The different tasks are
assigned to different departments that are responsible for their
implementation. This is illustrated in the top part of Fig. 1.
At this stage the board evaluated the expected benefits and
threats linked to these tasks, and ended up with the attributes
displayed on a white background. Our running example will be
motivated and developed step by step in the remaining sections
of this paper.
IV. CATO: A COLLABORATIVE RISK MANAGEMENT
FRAMEWORK
In order to define the cATO we will tackle three dimensions
of the problems detected in the eATO: information integration,
information propagation and incentives generation. Note, the
proposed cATO framework is a combination of individual
eATO running on different levels of the enterprise (or in
different departments).
Information integration: Standalone documentation has
the problem that it tends to be forgotten, inconsistent, outdated,
and never consulted. The cATO should be integrated with
existing tools (e.g. Wikis, task managers) in order to keep
information consistent across different tools and provide extra
incentives for members of a company to use and update the
framework on a regular basis.
Information propagation: The second shortcoming of
eATO that we will treat is the fact that information is stored
in isolation, and not easily communicated between different
levels of the organisation. Considering our running example
(see Fig. 1) using only eATOs the board would get to the
conclusion that “reducing the infrastructure costs” would bring
them a benefit of e550k and that there is a low risk of being
1 week delayed, whereas the IT Department would get to the
conclusion that the expected benefit is indeed e550k but that
there is a not negligible risk of being delayed of 2 weeks
due to the possibility of the main software developer leaving
the company. The eATO does not define an automatic way
to notify the stakeholders involved in upper layers from the
information gathered by the different departments (concretely
the information on a grey background wouldn’t be presented
to the board in an eATO). With the cATO we provide a mech-
anism to propagate the information gathered at the different
organisational levels to the upper levels.
Incentives generation: The final challenge we face is
to increase the motivation to use cATO by automatically
generating useful documentation based on the information
stored in its internal nodes. Users will be more motivated to
provide all available information on their projects if the output
of cATO in this regard will prove to be useful and time saving.
Integration with existing tools
Records management is a key driver in increasing orga-
nizational efficiency and offers significant business benefits.

B: 300k€
T: (3w, 4w, {create
common app})
Steering board + consultants
Reduce
infrastructure costs (DL)
Virtualize
infrastructure
Create common
application (DL)
IT Department
B: 550k€
PD: (L, 1w)
B: 300k€
PB: (H,20k€)
B: 550k€
T: (7w, 10w, {create DB specs})
PD: (M, 2w)
PB: (H, 20 k€)
Main developer
leaves the team
PD: (M, 8w)
Reduce
infrastructure costs (DL)
Reduce
personal costs
Cost
reduction
Data
consistency
Profit
Goals
Sub-goals
Create single source
of data (DL)
IT
IT
HR
Actions
B: 350k€
B: 120k€
B: 670k€
PD: (L, 1w)
B: 350k€
B: 1 020k€
PD: (L, 1w)
DB ready (DL) Develop app
Sell Server
Hire
Create single source
of data (DL)
Create DB
specifications (DL) Populate data
IT Department / Infrastructure
Infrastructure
Software
HR
DB ready (DL)
IT Department /
Infrastructure
Create DB
specifications (DL)
IT Department /
Software
Legend
PB: (H,20k€)
B: 300k€
T: (2w, 3w, {create DB spec})
T: (1w, 2w, {create
common app})
T: (1w, 2w, {create
common app})
T: (3w,5w,
{create DB spec})
T: (3w, 5w,
{create DB spec})
Grey: Result from delegation
T: (3w, 4w, {create
common app})
B: 250k€
T: (5w, 10w, {})
PB: (H,20k€)
T: (4w, 10w,
{DB ready}) PD: (M, 5w)
PD: (M, 5w)
B: 550k€
T: (7w, 10w, {create
DB specs})
PD: (M, 2w)
PB: (H, 20 k€)
B: 670k€
T: (7w, 10w, {create
DB specs})
PD: (M, 2w)
PB: (H, 20 k€)
T: (7w, 10w, {create DB specs})
PD: (M, 2w)
B: 970k€
T: (10w, 10w, {})
PD: (M, 2w)
PB: (H, 20k€)
Bold: Computed values
Free server
Goals
Actions
White: Evaluated values
Values: Symbols: Abreviations:
B: Benefit
PB: Probable Benefit
T: (time investment, deadline,
dependencies)
PD: Probable Delay
DL: Deadlocked
node
and-relation
or-relation
threat
opportunity
Warning
B: 300k€
T: (3w, 4w, {create
common app})
Fig. 1: “ArchiSurance” - Running example
Records management means that not too much reliance is
placed on the memories of a few individuals [15]. Wikis and
Task managers are some of the tools widely used in different
organisations. Therefore, we propose to integrate these tools
into our framework by adding meta-information to each node
of a cATO.
A selected node automatically has its wiki pages associated
with itself. This page can then be filled by the task owner
with the different documents associated with that task (e.g.
simple analyses of the problem, specific implementation of
the considered node). The goal is to have direct access to all
the documentation available for a certain task without having
to search through the entire Wiki. We also propose to integrate
the cATO with a task manager, adding to each node the
information on which stage the task currently is. Updating the
status of a task is then possible through both the task manager
and cATO. This has the advantage that sharing all information
on a task can be done by simply giving different collaborators
access to the cATO.
Furthermore, the goal of a task manager is to keep track
of the task’s progress and their status. A task has a certain
life-cycle within which it evolves from stage to stage. The
selection of a proper life-cycle is out of the scope of this paper,
but in order to be fully integrated with the cATO the selected
life-cycle needs to have two key states of the analysed task.
Uncommitted states: An uncommitted or analysis stage is a
stage in which a task is placed when it is being analysed in
order to detect its impact on the organisation. It is possible
that a task in this stage will never be implemented depending
on the result of the analysis and choices of the decision takers.
Every uncommitted task should appear in the task manager of
the task owner as an analysis request. Committed states: A
task in a committed stage was selected for implementation. In
this case a plan is designed to fulfil the given task and actions
have to be performed accordingly to the committed plan. The
task should appear as a due work in the task manager of the
task owner.
In order to fully benefit from the cATO the companies
should define propagation rules for the task stages. The enter-
prise decides in which stage the parent and children are placed
depending on the stage towards where they are transited.
Defining these rules is company specific. An example could be:
“if all committed sub-tasks of a given task are set to completed,
set also the task itself to complete” or “if a task is aborted,
abort all sub-tasks”.
V. COLLABORATIVE ASPECTS AND METRICS
Effective risk management depends to a high extent on
metrics [25] that give insight on the severity of risks. In this
section we present textually suggested metrics that support
the collaborative aspects of risk assessment and treatment. We
keep the mathematical formalism to the minimum, for the ease
of lecture. We also briefly introduce recommendations for task
delegation and assignment.
A. Metrics for collaborative risk assessment and treatment
Plans are often executed in multiple steps due to lack of
resources to perform every action in parallel or because certain
actions rely on the results of other actions. It is important to

introduce a notion of task dependencies in order to efficiently
represent the order in which tasks need to be performed and
to be able to analyse these dependencies and detect potential
threats resulting from these tight connections between tasks.
M1: (Task dependencies) The task dependencies of node
nare defined as a tuple Dn= ({n1, ..nd}), with n1, .., nd
being the tasks that need to be completed before ncan be
completed.
Situations can occur where different co-workers are waiting
for each others to complete their respective tasks in order to
progress with their own. Considering the running example (see
Fig. 1) on one hand, in order to “create a single source of data”
the infrastructure section decided to wait for the software team
to “create a common application” such that they know the exact
requirements of the database. On the other hand, the software
development section decided to wait for the completion of the
database before starting the development of the application.
The teams are in a “deadlock” situation where both wait for
each other and no real progress is made. Both teams seem
to have a valid reason for waiting. In a real situation such a
deadlock could be detected within a few days after the two
teams would communicate their respective plans. By using the
task dependency model we provide a way to detect possible
“deadlock” situations as early as possible, avoiding delays.
M2. (Task deadlock) A task dependency graph of a task n
can be obtained by recursively visiting all the nodes on which
ndepends (Fig.2). Task nis said to be in a potential deadlock
if it can find itself in its dependency graph. In such a case
nshould mark all the nodes on the path and itself as being
part of a potential deadlock (Fig.2.A). Furthermore if a node
depends directly on a deadlocked task, it should mark itself as
deadlocked too (Fig.2.B).
n7
n8
A. B.
n1
n2
n3
n4
n5
n6
n
n7
n7
n1
n2
n3
n4
n5
n6
n
n7
Fig. 2: Task dependencies and deadlocks
Except deadlocks other risks can occur due to task de-
pendencies. Risk is also present whenever a project’s objec-
tives are unrealistic, such as short deadlines, or insufficient
resources [25]. Therefore, uncertainties can be associated with
the outcomes of the project as well as with the ability to
deliver the project on time, within budget and compliant to
the specifications [15].
M3. (Time dependency) The time dependencies of node
nare defined as a tuple Tn= (ti, d, Dn), with ti, the time
investment to complete task n, without considering any depen-
dencies, dthe targeted deadline and Dn, the task dependencies
of task n.
Using the given definition, we can perform a sanity check
and decide whether the given deadline for a task nis realistic
iff maxi∈Dn(di) + tin≤dn. This means that a deadline is
realistic as long as the maximum deadline of the depended
tasks added up with the time to be invested on the task itself
is within the given deadline. An alarm can be triggered if a
task did not start before the deadline becomes unrealistic.
M4. (Total time investment) The total time investment
totalti(n)is the time needed for parent pto complete its child
nwithout taking into consideration external dependencies. Let
tinbe the time investment needed to complete solely nwithout
considering any dependencies and let Dibe the dependencies
of a node iand let Cbe the set of children of p, then
totalti(n) = tin+ maxj∈Di∩Ctotalti (i).
Let us consider the node “create single source of data”
from our running example. In order to complete the action
“populate data” the action “create DB specification” needs to
be performed first. In this case the time investment to “populate
data” is 2 weeks and to complete“create DB” is 1 week, but
since “populate data” needs to be performed after “create DB
specification”, from the parent’s perspective the total amount
of time that needs to be invested in order to complete “populate
data” is the sum of both time investments, so 3 weeks.
M5. (Probable delay) A task is considered to be threatened
if in the worst case scenario (all threats occur) it is impossible
to complete the task before its deadline. The time to com-
plete nin the worst case scenario is computed as being the
maximum time needed to complete the children of n, summed
up with its own dependencies and delays introduced by threats
directly associated to it. If in the worst case scenario the time of
completion is longer than the imposed deadline, the probable
delay is computed as being the difference in between deadline
and completion time.
It can happen that some unexpected events could lead to
benefits for the organization, such positive risks are called
opportunities. From a time perspective an opportunity would
be an event that could lead to achieving objectives sooner than
expected.
M6. (Probable time gain) An opportunity that is success-
fully taken is always profitable to the node it is associated
with, since it reduces its time of execution. In order to know
how a parent-node is affected by opportunities that are taken
by its children, we compute the maximum total time invested
by the parent in order to complete the children in the best case
scenario and compare it with the total time investment in case
no opportunities are taken. The total time gain the parent node
will have is the difference in between the normal case and the
best case scenario summed with the time gained by taking its
own opportunities.
B. Task delegation and assignment
The goals of the organisation are defined by the upper
management, refined and assigned down the hierarchy and
broken down in chunks that can be handled by individual
members of the company. Of course the upper management
can identify risks associated with their activities, but many
more can be detected at the different levels of the enterprise.
As already explained previously, even if eATO would be used
in the entire organisation, no mechanism exists to link the
different eATO models together and report relevant risks and
misalignments to the upper management. In order to overcome

this problem we introduce the notion of delegation of tasks in
the cATO.
Delegating a task in cATO (see Fig.3) consists of asso-
ciating a person with a node of the model. The assigned
employee then has the possibility to either accept, reject or
further delegate the task. Depending on the nature of the
delegated node (uncommitted or committed), the responsibility
of the assignee will either be to analyse or to implement the
given task. When accepting the task, a new cATO model is
automatically generated with a root node (goal) representing
the delegated node. The benefit of this approach is that the
results of the analysis can automatically be reported in form
of additional information to the upper management, where
different tasks have been assigned to different departments.
Considering the task “reduce infrastructure costs”, the up-
per management initially assessed the risk of a potential delay
to be low and evaluated it to 1 week, on the other hand the
IT department evaluated that there is a significant probability
of getting a 2 weeks delay (marked in grey) due to the main
developer leaving the company. Additional information on the
timing is also provided to the board which could initially not
be evaluated. This is only possible because there is now a
direct link in between the two cATO, the one managed by the
board and the one managed by the IT department.
Delegation should be a procedure that contains all the
information needed to complete a task. If a delegated node
has external dependencies associated with it, that are treated
by someone else than its newly designated owner, then the
delegated node appears as part of an and-relation whose root is
an assignment identifier. One of the children of this root-node
is the assigned task and the other children are its dependencies.
The latter appear as being delegated, since they are under the
responsibility of other members of the enterprise.
Reduce infrastructure
costs
Virtualize
infrastructure
Create common
application
Create common
application
Task: Create common app...
Assigned to: Software team Accept Reject Delegate
{Create DB
specifications}
Develop
application
Create DB
specifications
Legend
Grey: Result from delegation
White: Evaluated values
node
and-relation
or-relation
Fig. 3: Delegating a task with dependencies
VI. OU TP UT S OF T HE C ATO
The method we developed in this paper has the advantage
for project managers and for the board of an enterprise that
it automatically provides them with information from all
organisational levels, and with a single point of entry where
they can find all the documents related with the evolution of
their enterprise’s tasks. The next question that arises is how
to motivate employees to actually deliver this information.
Non-managerial staff might not have an interest in designing
their own cATO since they do not directly benefit from the
information they provide. In order to motivate them, we have
to be able to produce an output that is worth the amount of
effort they put into creating and maintaining the cATO.
One of the biggest burdens most workers suffer from is
documenting their work and keeping this documentation up-to-
date. By automatically generating documents from the cATO
we can compensate for the time consumed designing it. The
documents that can be automatically generated are as follows:
Risk Registry and Risk Matrix: One of the most
common methods for sharing and discussing an enterprise’s
risks is using Excel sheet based risk registries and matrices
(see Fig. 4). With the information provided in the cATO one
can easily generate such documents. The first step is to assign a
mapping from its quantitative value to a qualitative counterpart
for each risk metric. After this mapping is done, one can
automatically generate a risk registry, a risk matrix dealing
with threats, and a risk matrix showing the opportunities for
any of the nodes in the cATO. The person generating these
documents can have the choice to generate it for his own
projects, or to generate a full set of documentation, including
risks identified by those responsible for any delegated or
dependent tasks. It is important that the risk register should not
become a static document. It should be treated as a dynamic
element and considered to be the risk action plan for a unit
or the organization as a whole[15]. Generating it based on an
up-to-date cATO when needed ensures that risk analysis are
done on the latest available information.
Gantt Chart: By using cATO combined with the life-
cycle integration (Section IV.A) and time dependencies metrics
(Section V.A) we introduced, it is possible to always have an
up-to-date Gantt chart (see Fig. 5). Considering that all tasks
will be performed as soon as all the dependent tasks have
been fulfilled and considering the evaluated time of execution,
we can generate a Gantt chart associated with the normal
execution of a plan. The chart associated with the worst case
scenario is generated by assuming that all tasks will suffer from
their threats and will be delivered in the best case on the day
of their deadline. Finally, a chart for the best case scenario can
also be generated by assuming that all tasks will be completed
as soon as possible and that all opportunities will be taken.
VII. CONCLUSIONS AND FUTURE WORK
Collaborative risk management is supposed to enable enter-
prises to conduct a more accurate risk analysis and implement
a more efficient risk treatment plan. Communication and
collaboration, on one hand, enables an early identification
of potential negative impacts of threats and, on the other
hand, creates transparency, common understanding and aware-
ness among stakeholders. In this paper we have extended
our previous work, eATO, in creating a collaborative risk
management framework. Our framework, the cATO, involves
all stakeholders in identifying risks and in evaluating and
finding solutions for the risk treatment plans. It encourages
to divide the analysis of the enterprise in sub-systems, where
planning and control is the responsibility of the risk owners.
In this paper, we avoided the mathematical formalism of the
introduced metrics.
There are two additional directions that were not elabo-
rated. Firstly, we will investigate how the data collected in a
cATO can be represented in order to enable pattern detection.
Doing so we intend to use historical data from cATO models
in order to detect similarities in past and present situations.
We could then suggest the current task owner to refer to the
documentation available from previous projects and one could

Risk Registry
Threats Warnings
Name Risk Owner Context Comments Likelihood Impact Countermeasure Comments Likelihood Impact Id Type Comment
Main developer
leaves team
IT / Software Team
Create Common
Application
Our main developer
is thinking to take a
job at IBM
M 8 weeks delay Hire
We can launch a recruiting
process in order to anticipate
his departure
M 3 weeks delay
1 Deadlock
Opportunities
Name Risk Owner Context Impact Countermeasure Comments Likelihood Impact
Free Server IT / Infrastructure
Virtualize
Infrastructure
H Sell Server
We can sell the server in
order to gain some money
out of it
H L
A possible deadlock has been
detected involving following
nodes:
- DB ready
Action Taken
Residual
Threat
Comments
By virtualizing the infrastructure
some servers might get unused
Opportunity
Fig. 4: “ArchiSurance” - generated risk registry and risk matrix
Fig. 5: “ArchiSurance” - generated Gantt chart
also enumerate the risks that have previously been identified
in similar tasks. Secondly, a Java based tool is currently under
development. We intend to use it to conduct a survey in the
industry. This will give insights about the usability and related
benefits of using the cATO in regard with the modelling effort.
We intend to extend the set of metrics with respect to the needs
of the industry (e.g. ROI, (probable) benefits and costs).
REFERENCES
[1] ISO 31000, Risk management Principles and guidelines. Geneva:
International Organization for Standardization, 2009.
[2] M. S. Lund, B. Solhaug, and K. Stølen, Model-Driven Risk Analysis -
The CORAS Approach. Springer, 2011.
[3] Y. Asnar and P. Giorgini, “Modelling risk and identifying countermea-
sure in organizations,” in Proceedings of CRITIS ’06. Springer.
[4] Y. Asnar, R. Moretti, M. Sebastianis, and N. Zannone, “Risk as
dependability metrics for the evaluation of business solutions: A model-
driven approach,” in Proceedings of ARES ’08, 2008, pp. 1240–1247.
[5] N. Mayer, “Model-based management of information system security
risk,” Ph.D. dissertation, University of Namur, 2009.
[6] R. Matulevi˘
cius, N. Mayer, and P. Heymans, “Alignment of misuse
cases with security risk management,” in Proceedings of SREIS’08.
IEEE Computer Society, 2008, pp. 1397–1404.
[7] M. J. M. Chowdhury, R. Matulevicius, G. Sindre, and P. Karpati, “Align-
ing mal-activity diagrams and security risk management for security
requirements definitions,” in Requirements Engineering: Foundation for
Software Quality, ser. LNCS, B. Regnell and D. Damian, Eds. Springer,
Jan. 2012, no. 7195, pp. 132–139.
[8] O. Altuhhova and R. Matulevi˘
cius, “Security Risk Management using
Business Process Modelling Notations.”
[9] L. Lin, E. Yu, and J. Mylopoulos, “Secure-I*: Engineering Secure
Software Systems through Social Analysis,” Int. J. Software and In-
formatics, vol. 3, no. 1, pp. 89–120, 2009.
[10] R. Matulevi˘
cius, N. Mayer, H. Mouratidis, E. Dubois, P. Heymans, and
N. Genon, “Adapting Secure Tropos for Security Risk Management
during Early Phases of the Information Systems Development,” in
Proceedings of CAiSE’08. Springer, 2008, pp. 541–555.
[11] R. Matulevi˘
cius, H. Mouratidis, N. Mayer, E. Dubois, and P. Heymans,
“Syntactic and Semantic Extensions to Secure Tropos to Support
Security Risk Management,” vol. 18, no. 6, pp. 816–844, mar 2012.
[12] S. Sousa, D. Marosin, K. Gaaloul, and N. Mayer, “Assessing Risks
and Opportunities in Enterprise Architecture using an extended ADT
Approach,” in EDOC13, D. Gasevic, Ed. IEEE Computer Society,
September 2013, pp. 81–90.
[13] B. Kordy, S. Mauw, M. Melissen, and P. Schweitzer, “Attack-defense
trees and two-player binary zero-sum extensive form games are equiv-
alent,” in Proc. of, ser. GameSec’10. Springer, 2010, pp. 245–256.
[14] S. Mauw and M. Oostdijk, “Foundations of attack trees,” in ICISC 2005.
LNCS 3935. Springer, 2005, pp. 186–198.
[15] P. Hopkin, Fundamentals of risk management: understanding, evalu-
ating, and implementing effective risk management. The Institute of
Risk Management, 2012.
[16] ISO 31010, Risk management Risk assessment techniques. Geneva:
International Organization for Standardization, 2009.
[17] A. J. Gallagher, “Collaborative Risk Management: “Risk management”
vs. “Managening risk”,” 2013.
[18] Washington State Department of Transportation, “Project Risk Manage-
ment Guidance for WSDOT Projects,” Tech. Rep., July 2010.
[19] G. Westerman, “IT Risk as a Language for Alignment,” MIS Quarterly
Executive, vol. 8, no. 3, 2009.
[20] British Standards Institute, “The British Code of Practice for Risk
Management and Guidance for ISO31000,” 2011.
[21] A. T. Himmelman, “Collaboration for a Change: Definitions, decision-
making roles, and collaboration process guide,” 2002.
[22] R. Keast and M. P. Mandell, “What is collaboration?” 2009.
[23] J. Cummins and N. Doherty, “The economics of insurance intermedi-
aries,” The Journal of Risk and Insurance, vol. 73, no. 3, 2006.
[24] H. Jonkers, I. Band, and D. Quartel, “The ArchiSurance Case Study,”
The Open Group, White Paper, Spring 2012.
[25] T. Kendrik, “Defining and Implementing Metrics for Project Risk
Reduction,” 2005.