model-based risk management using uml and up

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, P.O.Box 83, N-0314 Oslo, Norway {folker.den.braber, ketil.stoelen, jan.aagedal}@informatics.sintef.no 2 CLRC Rutherford Appleton Laboratory, Oxfordshire, OX11 0QX, UK [email protected] 3 Institute for Energy Technology, P.O. Box 173, N-1751 Halden, Norway [email protected]

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

Risk management process

0RGHOEDVHG ULVNDVVHVVPHQW PHWKRGRORJ\

Integrated risk management and development process

Platform for toolinclusion 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. WD U J HW ,G H QW LI\ & R Q WH [W

(Prepare/Describe the TOE) •the strategic contexts •the organisational contexts •the risk m anagement context •develop criteria •decide the structure

1

1..* Rem ote network 1

DGPLQLVWUDWHV

Intranet

1

1 M ain network

VPN technique 1

1

Adm inistrator

1..*

1

1 1

1..* Gateway

1..* Rem ote network PC

1 Rem ote network Gateway

1 1 Database

XVHV

1..* M ain network PC

1 M ain network Gateway

,G H QW LI\ 5 LVN

W hat can happen? How can it happen?

D VVH WV

People

$ QD O\ VH 5 LVN V

D eterm ine likelihood

D eterm ine consequences

A sset

Inform ation

WK U H DW VF H Q DU LR

read personal card

H ardw are

Software

prevents Unauthorised Login

includes sign security statement

Login

Estim ate level of risk

Doctor

includes

prevents

Check Password

Disobbeying security rules

Crook

( Y D OX D WH 5 LV NV

com pare against criteria, set risk priorities

Specialist

Read M edical files

Tap 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

Requirem ents •identify treatm ent options •evaluate treatment options •select treatm ent options •prepare treatment plans •im plem ent plans $' 9 ,& ( 

K D] D U GV

Consequence

D ata loss

H azard

*

KDV

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.

P H W V \ V  6 $ 5 2 &

P S R O H Y H G

P  6 $ 5 2 &

Identify risks

Analyse risks

Risk evaluation

Treat risks

Monitor and Review MANAGE RISK

LWHUDWH

V V H F R U S W Q H

V G R K W H

Identify context

INSTANTIATION OF



Communicate and Consult

QR WLS HF Q,

LWHUDWH

RQWL DU RE DO (

Choose a part $UFKLWHFWDSDUW

$QDO\VHDSDUW

&RPSRVHLQ

Choose a part $UFKLWHFWDSDUW

$QDO\VHDSDUW

LWHUDWH

QR LW FX UVW QR &

Choose a part $UFKLWHFWDSDUW

$QDO\VHDSDUW

&RPSRVHLQ

&RPSRVHLQ

LWHUDWH

QR LLW VQ UD7

Choose a part $UFKLWHFWDSDUW

$QDO\VHDSDUW

&RPSRVHLQ

UHYLHZULVNV

UHYLHZULVNV

UHYLHZULVNV

UHYLHZULVNV

DQGFRQVXOW

DQGFRQVXOW

DQGFRQVXOW

DQGFRQVXOW

DESIGN USING information & computational Analyse viewpoint Risks

enterprise viewpoint Identify Risks

Identify Assets

,QFHSWLRQ

engineering & technology viewpoint

INSTANTIATION OF

&25$6IUDPHZRUN

V V H F  R N U V S L  U  W 6 Q H $ 5 P 2 H J & D Q D P

system implementation Test

Analyse Evaluate

Value Assets

Monitor

(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] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

AS/NZS 4360:1999 Risk management. Barber, B., Davey, J. The use of the CCTA risk analysis and management methodology CRAMM. Proc. MEDINFO92, North Holland, 1589 –1593, 1992. 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. CORAS: A platform for risk analysis of security critical systems. IST-2000-25031, 2000. (http://www.nr.no/coras/) IEC 1025: 1990 Fault tree analysis (FTA). IEC 61508: 2000 Functional safety of electrical/electronic/programmable safety related systems. ISO/IEC 10746 series: 1995 Basic reference model for open distributed processing. ISO/IEC TR 13335-1:2001: Information technology – Guidelines for the management of IT Security – Part 1: Concepts and models for IT Security. ISO/IEC 17799: 2000 Information technology – Code of practise for information security management. Krutchten, P. The Rational unified process, an introduction. Addison-Wesley, 1999. Littlewood, B. A reliability model for systems with Markov structure. Appl. Stat. 24:172-177, 1975. Putman, J. R. Architecting with RM-ODP. Prentice Hall, 2001. Redmill, F., Chudleigh, M., Catmur, J. Hazop and Software Hazop. Wiley, 1999. Sindre, G., Opdahl, A. L. Eliciting security requirements by misuse cases. In Proc. TOOLS_PACIFIC 2000. IEEE Computer Society Press, 120-131, 2000. UML proposal to the Object Management Group, Version 1.4, 2000.