MODEL-BASED RISK MANAGEMENT
USING UML AND UP
Folker den Braber1, Theo Dimitrakos2, Bjørn Axel Gran3, Ketil Stølen1, Jan Øyvind Aagedal1
1
Sintef Telecom and Informatics, [Link] 83, N-0314 Oslo, Norway
{[Link], [Link], [Link]}@[Link]
2
CLRC Rutherford Appleton Laboratory, Oxfordshire, OX11 0QX, UK
[Link]@[Link]
3
Institute for Energy Technology, P.O. Box 173, N-1751 Halden, Norway
[Link]@[Link]
Abstract
CORAS is a research and technological development project under the Information
Society Technologies (IST) Programme (Commission of the European Communities,
Directorate-General Information Society). CORAS started up in January 2001 and runs
until July 2003. The main result of the CORAS project is the CORAS framework for
model-based risk assessment. It employs UML-oriented modelling for three main
purposes. (1) To describe the target of assessment at the right level of abstraction; (2)
As a medium for communication and interaction between different groups of
stakeholders involved in risk assessment; (3) To document risk assessment results and
the assumptions on which these results depend. This paper provides a brief overview of
the CORAS framework with particular emphasis on the role of UML and UP.
1 INTRODUCTION
CORAS [4] aims at an improved methodology for precise, unambiguous, and efficient risk
assessment of security critical systems. The focus of the CORAS project lies on the tight
integration of viewpoint-oriented UML modelling in the risk management process. An
important angle of the CORAS project, is the practical use of UML [15] and UP [10] in the
context of security and risk assessment.
CORAS addresses security critical systems in general, but puts particular emphasis on IT
security. IT security includes all aspects related to defining, achieving, and maintaining
confidentiality, integrity, availability, non-repudiation, accountability, authenticity, and
reliability of IT systems [8]. An IT system in the sense of CORAS is not just technology, but
also the humans interacting with the technology and all relevant aspects of the surrounding
organisation and society.
The CORAS consortium consists of three commercial companies: Intracom (Greece), Solinet
(Germany) and Telenor (Norway); seven research institutes: CTI (Greece), FORTH (Greece);
IFE (Norway), NCT (Norway), NR (Norway), RAL (UK) and Sintef (Norway); as well as one
university college: QMW (UK). Telenor and Sintef are responsible for the administrative and
scientific coordination, respectively.
The remainder of this paper is divided into five sections. Section 2 provides and overview of
the CORAS framework which is the main result of the CORAS project. Sections 3 - 6
describe the main constituents of the CORAS framework: the risk management process
(Section 3), the system documentation framework (Section 4), the platform for tool
integration (Section 5), and the integrated risk management and development process (Section
6).
2 THE CORAS FRAMEWORK
The main CORAS result is the CORAS framework for model-based risk assessment. As
illustrated by Figure 1, the CORAS framework has four main anchor-points.
System
documentation
framework
Integrated risk
Risk
0RGHOEDVHG management
management ULVNDVVHVVPHQW and
process PHWKRGRORJ\ development
process
Platform for tool-
inclusion based on
data integration
Figure 1 The CORAS framework for model-based risk assessment
The CORAS risk assessment methodology integrates aspects of HazOp analysis [13], Fault
Tree Analysis (FTA) [5], Failure Mode and Effect Criticality Analysis (FMECA) [3], Markov
Analysis [11] as well as CRAMM [2]. It is model-based in the sense that it gives detailed
recommendations for the use of UML modelling in conjunction with assessment. In fact, it
employs modelling technology for three main purposes:
1. To describe the target of assessment at the right level of abstraction.
2. As a medium for communication and interaction between different groups of stakeholders
involved in risk assessment.
3. To document risk assessment results and the assumptions on which these results depend.
Model-based risk assessment is motivated by several factors:
• Risk assessment requires correct descriptions of the target system, its context and all
security relevant features. The modelling technology improves the precision of such
descriptions. Improved precision is expected to improve the quality of risk assessment
results.
• The graphical style of UML is believed to further communication and interaction between
stakeholders involved in a risk assessment. This is expected to improve the quality of
results, and also speed up the risk assessment process since the danger of wasting time
and resources on misconceptions is reduced.
• The modelling technology facilitates a more precise documentation of risk assessment
results and the assumptions on which their validity depends. This expected to reduce
maintenance costs by increasing the possibilities for reuse.
• The modelling technology provides a solid basis for the integration of assessment
methods that should improve the effectiveness of the assessment process.
• The modelling technology is supported by a rich set of tools from which the risk
management may benefit. This may improve quality (as in the case of the two first
bullets) and reduce costs (as in the case of the second bullet). It also furthers productivity
and maintenance.
• The modelling technology provides a basis for tighter integration of risk management and
assessment in the system development process. This may considerably reduce
development costs and help ensure that the specified security level is achieved.
3 THE RISK MANAGEMENT PROCESS
The CORAS risk management process is based on AS/NZS 4360: 1999 Risk Management [1]
and ISO/IEC 17799-1: 2000 Code of Practise for Information Security Management [9].
Moreover, it is complemented by ISO/IEC TR 13335-1: 2001 Guidelines for the Management
of IT Security [8] and IEC 61508: 2000 Functional Safety of Electrical/Electronic/
Programmable Safety Related Systems [6]. As indicated by Figure 2, AS/NZS 4360 provides
a sequencing of the risk management process into sub-processes for context identification,
risk identification, risk analysis, risk evaluation, and risk treatment. For each of these stages,
the CORAS methodology gives detailed advice with respect to which models should be
constructed, and how they should be expressed.
DGPLQLVWUDWHV
WD U J HW Intranet Adm inistrator
1 1..*
1 1 1
,G H QW LI\ & R Q WH [W 1..*
(Prepare/Describe the TOE) Rem ote network M ain network
•the strategic contexts VPN technique 1 1 1
•the organisational contexts 1 1 1 1
•the risk m anagement XVHV
Database
1..*
context
Gateway
•develop criteria 1..* 1..*
•decide the structure Rem ote network PC M ain network PC
1 1
Rem ote network M ain network
Gateway Gateway
,G H QW LI\ 5 LVN
W hat can happen? How can it D VVH WV A sset
happen?
$ QD O\ VH 5 LVN V People Inform ation H ardw are Software
WK U H DW
D eterm ine D eterm ine prevents
VF H Q DU LR
read personal Unauthorised
likelihood consequences card Login
includes
sign security
Login
statement
Estim ate level of risk includes prevents
Doctor
Check Password Disobbeying
security rules
Crook
( Y D OX D WH 5 LV NV
com pare against criteria, set risk Read Tap
priorities Specialist M edical files Communication
includes
prevents
$ FF H S W5 LV NV
W rite
M edical files
Use VPN -
includes Firewall/Encryption
7 U H DW 5 LVN V
$' 9 ,& ( Requirem ents K D] D U GV
•identify treatm ent options Consequence H azard
•evaluate treatment options
•select treatm ent options
•prepare treatment plans
•im plem ent plans * KDV
D ata loss W et com puter
Figure 2: The CORAS risk management process and the role of UML
Context identification establishes the strategic, organisational and risk management context.
Context identification is supported by models of the following kinds:
• SWOT: Describes the relationship between the organisation and its environment,
identifying the organisation’s strengths, weaknesses, opportunities and threats.
• Context: Describes the organisation and its capabilities, as well as its goals and objectives
and the strategies that are in place to achieve them.
• Target: Describes the goals, objectives, strategies, scope and parameters of the activity, or
system to which the risk management process is being applied. Figure 2 illustrates the use
of a UML class-diagram to specify some aspects of a potential target.
• Assets: Describes the identified assets, their dependencies as well as the results from the
asset valuation. Figure 2 illustrates the use of a UML class-diagram to specify relevant
assets of a potential target.
• Security Requirements: Describes the security requirements needed to preserve the
identified assets.
• Risk Evaluation Criteria: Describes the criteria against which risk is to be evaluated.
Risk identification is the process of determining what can happen why and how. Risk
identification is supported by models of the following kinds:
• Threat Scenarios: Describes potential threat scenarios. Threats (and also hazards) to a
system may for example be specified with the help of a misuse case diagram inspired
from [14] as indicated by Figure 2.
• Deviations: Describes potential deviations.
• Hazards: Describes potential hazards. The class-diagram at the bottom of Figure 2
captures a consequence-hazard relationship.
Risk analysis is the systematic use of available information to determine how often specified
models may occur and the magnitude of their consequences. Risk analysis is supported by
models of the following kinds:
• Consequence Estimates: Describes consequence estimates for the identified hazards.
• Hazard Frequencies: Describes frequency estimates for the identified hazards.
• Threat Frequencies: Describes frequency estimates for the identified threats.
Risk evaluation is the process to determine risk management priorities by comparing the level
of risk against predetermined standards, target risk levels or other criteria. Risk evaluation is
supported by models of the following kinds:
• Risk Estimates: Describes risk estimates for the identified hazards.
• Risk Priorities: Describes hazard priorities based on the estimated risks.
• Risk Themes: Describes how the hazards should be grouped into hazard themes.
• Risk-Theme Relationships: Describes the relationships between the hazard themes.
• Risk-Theme Priorities: Describes hazard-theme priorities based on the estimated risks.
Risk treatment is the selection and implementation of appropriate options for dealing with
risk. Risk treatment is supported by models of the following kinds:
• Policy: Describes required changes to policies to handle identified security problems.
• Security Requirements: Describes strengthened security requirements to handle identified
security problems.
• Security Architectures: Describes required changes to security architecture to handle
identified security problems.
• Testing: Describes requirements to testing to further investigate potential security
problems.
• Monitoring: Describes requirements to system monitoring to help handling potential
security problems.
• Treatment Priorities: Describes a list of solutions with priorities.
4 SYSTEM DOCUMENTATION FRAMEWORK
The CORAS system documentation framework is based on the ISO/IEC 10746 series: 1995
Basic Reference Model for Open Distributed Processing (RM-ODP) [7]. RM-ODP defines a
reference model for distributed systems architecture, based on object-oriented techniques.
RM-ODP divides the system documentation into five viewpoints. It also provides modelling,
specification and structuring terminology, a conformance module addressing implementation
and consistency requirements, as well as a distribution module defining transparencies and
functions required to realise these transparencies.
The CORAS system documentation framework extends RM-ODP with
• concepts and terminology for risk management and security;
• carefully defined models within each viewpoint (as already exemplified in Section 3)
targeting model-based risk management and assessment of security-critical systems;
• libraries of reusable model fragments targeting risk assessment;
• additional support for conformance checking;
• a risk management module containing the risk management process, relevant standards,
risk assessment methodology as well as formats for tool integration.
5 PLATFORM FOR TOOL INTEGRATION
The CORAS platform will be based on data integration implemented in terms of XML
(eXtensible Markup Language) technology. The platform will be built around an internal data
representation formalised in XML/XMI (characterised by XML schema). Standard XML
tools are supposed to provide much of the basic functionality. This functionality may be used
to experiment with the CORAS platform and also support the CORAS crew during two major
trials planned for 2002.
Based on XSL (eXtensible Stylesheet Language), relevant aspects of the internal data
representation may be mapped to the internal data representations of other tools (and the other
way around). This allows the integration of sophisticated case-tools targeting system
development as well as risk analysis tools and tools for vulnerability and treat management.
6 INTEGRATED RISK MANAGEMENT AND DEVELOPMENT
PROCESS
The CORAS integrated risk management and development process is based on an integration
of AS/NZS 4360 [1] and an adaptation of UP [10] to support RM-ODP [7] inspired viewpoint
oriented modelling.
Figure 3 provides an overview of the relationship between the various stages of the risk
management process, RM-ODP and the main UP workflows. Emphasis is placed on
describing the evolution of the correlation between risk management and viewpoint oriented
modelling throughout the systems development and maintenance lifecycle.
V
V
H Communicate and Consult
F
R
N U
V S
L
U
W
Identify Identify Analyse Risk Treat
6 Q context risks risks evaluation risks
H
$
5 P
2 H
J Monitor and Review
& D
Q
D
MANAGE RISK
&25$6IUDPHZRUN
V LWHUDWH LWHUDWH LWHUDWH LWHUDWH
V
QR
RQWL
H
P F
QR
Choose a part Choose a part
LW
Choose a part
QR Choose a part
H R
U
WLS DU FX LLW
W
UVW VQ
$UFKLWHFWDSDUW $UFKLWHFWDSDUW $UFKLWHFWDSDUW $UFKLWHFWDSDUW
V S
HF RE
INSTANTIATION OF
INSTANTIATION OF
W
UD7
\
V
Q
H Q, $QDO\VHDSDUW
DO $QDO\VHDSDUW
QR $QDO\VHDSDUW $QDO\VHDSDUW
6
$
P ( &
S
5 R &RPSRVHLQ &RPSRVHLQ &RPSRVHLQ &RPSRVHLQ
O
2 H
& Y
H UHYLHZULVNV UHYLHZULVNV UHYLHZULVNV UHYLHZULVNV
G
DQGFRQVXOW DQGFRQVXOW DQGFRQVXOW DQGFRQVXOW
DESIGN USING
V enterprise viewpoint information & engineering & system implementation
G computational technology
R
K Identify Analyse viewpoint viewpoint
W
H Risks Risks Test
P
6 Analyse
$
5 Evaluate
2 Identify Value
& Monitor
Assets Assets
,QFHSWLRQ (ODERUDWLRQ &RQVWUXFWLRQ 7UDQVLWLRQ
Figure 3 Integrated risk management and development process
As based on the UP, the CORAS process is also both stepwise incremental and iterative. In
analogy to the RM-ODP viewpoints, the viewpoints of the CORAS framework are not
layered; they are different abstractions of the same system focusing on different areas of
concern.
REFERENCES
[1] AS/NZS 4360:1999 Risk management.
[2] Barber, B., Davey, J. The use of the CCTA risk analysis and management
methodology CRAMM. Proc. MEDINFO92, North Holland, 1589 –1593, 1992.
[3] Bouti, A., Ait Kadi, D. A state-of-the-art review of FMEA/FMECA. International
Journal of Reliability, Quality and Safety Engineering 1:515-543, 1994.
[4] CORAS: A platform for risk analysis of security critical systems. IST-2000-25031,
2000. ([Link]
[5] IEC 1025: 1990 Fault tree analysis (FTA).
[6] IEC 61508: 2000 Functional safety of electrical/electronic/programmable safety
related systems.
[7] ISO/IEC 10746 series: 1995 Basic reference model for open distributed processing.
[8] ISO/IEC TR 13335-1:2001: Information technology – Guidelines for the management
of IT Security – Part 1: Concepts and models for IT Security.
[9] ISO/IEC 17799: 2000 Information technology – Code of practise for information
security management.
[10] Krutchten, P. The Rational unified process, an introduction. Addison-Wesley, 1999.
[11] Littlewood, B. A reliability model for systems with Markov structure. Appl. Stat.
24:172-177, 1975.
[12] Putman, J. R. Architecting with RM-ODP. Prentice Hall, 2001.
[13] Redmill, F., Chudleigh, M., Catmur, J. Hazop and Software Hazop. Wiley, 1999.
[14] Sindre, G., Opdahl, A. L. Eliciting security requirements by misuse cases. In Proc.
TOOLS_PACIFIC 2000. IEEE Computer Society Press, 120-131, 2000.
[15] UML proposal to the Object Management Group, Version 1.4, 2000.