=Paper=
{{Paper
|id=Vol-67/paper-4
|storemode=property
|title=Building an Experience Factory for a Model-based Risk Analysis Framework
|pdfUrl=https://ceur-ws.org/Vol-67/gwem2003-GS.pdf
|volume=Vol-67
}}
==Building an Experience Factory for a Model-based Risk Analysis Framework==
https://ceur-ws.org/Vol-67/gwem2003-GS.pdf
Building an Experience Factory for a Model-based Risk
Analysis Framework
Chingwoei Gan, Eric Scharf
Department of Electronic Engineering,
Queen Mary University of London
E1 4NS, United Kingdom
{chingwoei.gan, e.m.scharf}@elec.qmul.ac.uk
Abstract: This paper describes the integration of an experience factory in a model-
based risk analysis framework called CORAS1. CORAS aims at developing a new
model-based risk analysis framework for security critical application. The
framework’s cornerstone of combining methods for risk analysis of critical systems
and semiformal modelling methods in a tool-supported environment targeting
openness and interoperability has not been tried before. We adapted the experience
factory concept to fit our needs in documenting and exploiting the risk analysis
results, as well as to support the structured process of risk management. Our
internet-enabled experience factory takes advantage of XML as the vehicle for data
exchange within an environment that involves heterogeneous tools. The
effectiveness of the framework will be reviewed and measured against the objectives
of the project during planned future trials.
1 Introduction
The increased reliance of modern businesses and corporations on IT-related services
imposes new and increasingly demanding requirements on the underlying infrastructure.
An unambiguous understanding of the limitations of the existing infrastructure – through
risk analysis - has become an important prerequisite for designing new services with a
satisfactory degree of security. Risk analysis is now considered a useful and critical means
for abstracting information from reality into a more formal description. Its importance has
been recognized in the process industry, finance and business areas where methods for
risk management have been developed [Di02].
Traditionally, risk analysis of security critical systems is performed on the basis of
informal descriptions of the target of evaluation. Such an approach is prone to
misunderstandings [St02]. Further, the growing complexity of today’s systems urges the
improvement of existing methods of analyzing systems and their security specification in
order to increase the likelihood that all possible security threats are taken into
consideration. Consequently, the demand for a more orderly and formal treatment of risks
is getting greater.
1
CORAS is a research and development project under the European Information Society Technologies Fifth
Framework Programme (IST-2000-25031), to be completed by July 2003; website: http://www.nr.no/coras
More recently we have witnessed the emergence of an improved methodology for security
risk assessment in CORAS [Aa02, St02, Gu02, Iv02] and other similarly-motivated
projects such as Reactive System Design Support (RSDS) [LAC00, La00, LAK00] and
Surety Analysis [WCF99]. These initiatives share one thing in common – the integration
of state-of-the-art Unified Modelling Language (UML) based methodology and
conventional risk analysis techniques including Fault Tree Analysis (FTA), Failure Mode
and Effect Criticality Analysis (FMECA) and Hazard and Operability study (HAZOP).
CORAS, on which the main subject of this paper is built, aims to produce an improved
methodology for precise, unambiguous, and efficient risk analysis of security critical
systems. The focus of the CORAS project is on the tight integration of viewpoint-
oriented visual modelling in the risk assessment process. An important aspect of the
CORAS project is the practical use of UML in the context of security and risk assessment.
A further overview of CORAS and its methodology can be found in Section 2.
During risk assessment, knowledge and experiences are gained, other computerized tools
are queried and a lot of documents of different types are produced by the risk analysis
team. In the context of CORAS, this includes UML diagrams, textual report, tree
diagrams, tables, guidelines and many others. It is a non-trivial task when dealing with
information of such volume and variety in a heterogeneous operating environment.
Further, the risk management process is an elaborate process, involving both humans and
computerized tools, and as such, is prone to delays and errors. A system is needed which
effectively manages, queries and reuses different types of risk analysis results according
to a given assessment scenario. We have implemented such a system, known as the
CORAS platform, designed to integrate the various components, technologies and results -
risk analysis methods, semiformal methods, object-oriented modelling methods, and tools
- into an overall tool-supported CORAS framework/process.
A framework that attempts to operate within an organization and to realize the goal of
organizational learning will require some measure of Knowledge Management (KM). We
have chosen to incorporate the concept of Experience Factory (short: EF [BCR94]) into
the CORAS platform. EF is an example of knowledge management approach initially
designed for software organizations. In our work to carry out model-based risk
assessment, we have found that a tailored version of the experience factory approach is
beneficial for creating a learning organization even though the main subject of our project
does not fall into the conventional category of software development. The CORAS
experience factory is the first known application of EF in the field of model-based risk
analysis.
In this paper we introduce the CORAS framework (Section 2) and how this framework is
supported by our adapted experience factory (Section 3) - including certain design issues,
taxonomy of our experience package and the experience repository - in order to document
and exploit the risk analysis results effectively. We also look at the various issues faced
during development, and the rationale behind the choice of using XML as the building
blocks of our CORAS platform and the decision to adopt a web-based approach. Finally,
we summarize our experiences and conclude with future directions in Section 4.
2 CORAS Framework
2.1 Overview of the CORAS Framework
The CORAS framework has four main anchor-points – a risk management process based
on AS/NZS 4360 2 and ISO/IEC 17799 3 , a risk documentation framework based on
Reference Model for Open Distributed Processing (RM-ODP) viewpoints architecture, an
integrated risk management & development process based on (Rational) Unified Process
and a XML-based tool independent platform.
This framework is also characterised by a careful integration of aspects from partly
complementary risk assessment methods like HAZOP, FTA, FMECA, Markov analysis
and CRAMM4 . A more in-depth discussion into each of these anchor-points is covered in
[Aa02, St02, Gu02, Iv02]. For the purpose of this paper, we focus only on the CORAS
risk documentation framework and the CORAS platform, for which an EF has been set
up.
2.2 CORAS Risk Documentation Framework
The CORAS risk documentation framework divides the RM-ODP viewpoint structure
into 22 concerns targeting security in general and model-based risk assessment in
particular. Implicit within the risk documentation framework is the CORAS risk
management process (Figure 2.1), which is to be performed in a sequential fashion.
Each cross-viewpoint concern is tied to a particular sub-process within the risk
management process, and may contain concrete elements which are relevant for the
purpose of risk assessment. One or several of its viewpoints may be empty, depending on
the concern in question as well as the target and rigour of evaluation. However if not
empty, each concern-viewpoint will contain a set of element instances. Different instances
of the same element may occur within different viewpoints of the same concern. Elements
can be classified into:
• Elements containing non-CORAS specific documentation, which refers to elements
that are not prepared as a part of the CORAS risk management process.
• Modelling elements expressed in UML.
• Reports and logs from intrusion detection systems, as well as computerised
vulnerability & threat management tools .
• Risk assessment tables and FTA tree diagrams .
For simplicity, we refer to these elements as experience from hereon.
2
Australian/New Zealand Standard AS/NZS 4360:1999: Risk Management. 1999.
3
ISO/IEC 10746 series: Basic reference model for open distributed processing. 1995.
4
Central Computer & Tele-communications Agency’s Risk Analysis and Management Methodology.
CORAS Risk Management Process
1. 2. 3. 4. 5.
Subprocess Identify Context Identify Risks Analyse Risks Evaluate Risks Treat Risks
Activity 1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 4.1 4.2 4.3 4.4 4.5 5.1 5.2
risk theme relationship
risk evaluation criteria
treatment assessment
target of evaluation
unwanted incidents
risk theme priority
risk management
treatment priority
security policies
vulnerabilities
organisational
risk estimates
consequence
risk priority
risk themes
frequency
treatment
approval
SWOT
system
threats
assets
technology
engineering
computational
information
enterprise
Concerns
Viewpoints
Figure 2.1 CORAS Risk Documentation Framework
2.3 CORAS Platform
From a conceptual view, the CORAS platform, or better understood as the computerized
part of the CORAS framework, integrates experience from three broad categories of
toolkits or applications. The resulting experience will be sorted and stored in the platform
according to the CORAS risk documentation framework. The motivation behind such a
high level of data integration and tools interoperability is to ensure broad applicability of
CORAS. The pre-requisite to achieving this goal is therefore to have a common data
exchange format that is capable of open sharing, in which case the universal XML format
has been chosen. Besides, given the ubiquity of XML-related tools, we can reduce the cost
and time of deployment significantly.
The three categories of toolkits that can conceivably communicate with the CORAS
platform are: UML Comp uter Aided Software Engineering (CASE) tools, risk assessment
tools and intrusion detection tools (including vulnerability & threat management tools).
Each toolkit category generates experience in a specific XML data model that can be
transported and exchanged within the confine of the platform. Some of the supported
XML data models are:
• Data based on XML Metadata Interchange (XMI) standardised by the Object
Management Group and targeting tools for UML modelling.
• XML-compliant data format targeting risk assessment tools.
• Data based on Intrusion Detection Messaging Exchange Format (IDMEF). IDMEF is
an XML data model designed to represent the information exported by the intrusion-
detection systems.
• XML-compliant data format targeting vulnerability assessment tools.
Figure 2.2 illustrates the concept behind the CORAS integration platform.
(Target of Assessment)
VA Tool Security Critical System
(Nessus )
FMECA FTA HAZOP
TM Tool
Tools Tools Tools
(Snort)
UML CASE
Tools
CORAS XMI
XML
IDMEF Models in Output
IDMEF Data
Data Data UML
XML
IDMEF CORAS XMI
CORAS
CORAS Platform Specific
Specific
Tags Tags
Reusable Assessment
Elements Repository
Repository CORAS
Repository
Figure 2.2 CORAS Integration Platform
Given our conceptual view of the CORAS platform, we discovered a list of high-level
requirements that the platform should satisfy. The requirements are as below:
• The CORAS platform shall support geographically distributed organizations allowing
them to share and manage experience packages remotely.
• The repository shall be robust, reliable and portable to standard computer platforms .
• The GUI shall be platform independent, and allow for visual information navigation.
• The data model shall be simple but powerful enough to model diverse classes of
experience packages. The CORAS platform will adapt to the current practices,
processes, and products or different organizations, and not vice-versa.
• To allow for effective and efficient use of the repository, the CORAS platform shall be
furnished with easy-to-use GUIs and search mechanisms enabling the users to “plug
into” the platform, thereby manipulate experience they deem relevant.
• The platform shall increase the reusability of CORAS results and to promote the
sharing of such results, as well as to improve the effectiveness and efficiency of model-
based risk assessment.
Armed with these requirements, we embarked to discover other strategies that are needed
in building an EF for the CORAS framework.
3 Experience Factory in CORAS
3.1 Appl ying the EF approach to CORAS
As part of a concerted effort for improving risk assessment, in the project we are
concerned with establishing an experience management system at both logical and
physical organizational level that supports the unique model-based risk assessment
approach of CORAS. We need a system that can analyze and synthesize our assessment
results and experience, acting as a repository for such experience, and supplying that
experience to future assessments on demand.
The EF approach aims to establish an organizational infrastructure to facilitate systematic
and continuous organizational learning through the sharing and reuse of experiences in
software engineering [BCR94]. It is clear from the beginning that the EF concept was
motivated by the lack of understanding of the nature of software and software
development in software business. To some extent, software is different from most
products. First of all, software is developed in the creative, intellectual sense, rather than
produced in the manufacturing sense. Each software system is developed rather than
manufactured. Likewise in the context of CORAS, risk management is an evolving
process developed in an iterative and interactive manner, instead of being carried out in a
simple straight-line process. Secondly, there is a non-visible nature to software. Unlike an
automobile or a television set, it is hard to see the structure or the function of software.
Similarly for CORAS, the outcome of the risk management process is not immediately
apparent. The CORAS risk management process requires understanding, continuous
improvement, and the packaging of experience for reuse.
Hence, the EF approach seems like a good fit for CORAS. However, we have not, at least
at the present time, incorporated the entire EF concept within our framework, as has been
accomplished by a number of software development organizations including SEL-NASA
[Ba02, Ba92], FC-MD [Ba01], PERFECT [Pe96] and Daimler Benz AG [HSW98]. One
reason is that the EF/QIP approach remains a theoretical, abstract framework, which lacks
explicit and easily applicable guidelines on implementation (also pointed out in [HSW98,
KJL00]). The time aspect is also a critical point, for instance the EF at NASA evolved
over 15 years whereas our EF is supposed to be running within 6 months! Thus, our
objective is to build a scale-down but functional EF, tailored to our specific organizational
need within the shortest possible time -frame, without the overhead – both time and
resources – that is normally required of an organization wishing to tap into the many
benefits of EF.
3.2 Building the EF – Top-down Approach
There are two approaches to starting an EF – top-down or bottom-up. The top-down
approach compares and organization’s process with some generally accepted standard
process. Five key steps characterize the top-down approach [KJL00]: (1) Obtain
commitment (2) Establish structure (3) Establish processes (4) Produce baseline (5)
Identify potential changes. The bottom-up approach assumes that process change must be
driven by an organization’s goals, characteristics, product attributes, and experiences. In
CORAS there are four existing standardization initiatives: (1) AS/NZS 4360 (2) ISO/IEC
17799 (3) UP (4) RM -ODP. These initiatives were already glued together in a
comprehensive risk analysis framework. The goal is to provide the facility to support a
smooth operation of such a framework. It was obvious that the top-down approach is most
suitable for our purpose, so any change will be driven and guided, not by experience, but
by a set of best practices and the inherent organizational requirements.
EF is based on the Quality Improvement Paradigm (QIP). The QIP focuses on the notion
that improving the software process requires the continual accumulation of evaluated
experiences (learning) in a form that can be effectively understood and modified
(experience models) into a repository of integrated experience models (experience base)
that can be accessed and modified to meet the needs of the current project (reuse)
[BCR94]. This paradigm implies the logical separation of project development (performed
by the Project Organization) from the systematic learning and packaging of reusable
experience (performed by the Experience Factory) [ABT00]. In particular, the EF
analyses and synthesizes all kinds of experiences drawn from these projects, acts as a
repository for such experiences by documenting, storing, qualifying, and updating them
using a so-called experience base (EB; Figure 3.1), and supplies those experiences back to
projects on demand. The task of the EF, besides support during the risk assessment
process, is to package experience by building informal, formal or schematized various risk
management processes, components and other forms of knowledge.
Experience Factory Organization
Project #1 CORAS
Experien ce Base
Project Organization Experience Factory
Figure 3.1 EF Organization
The interacting PO and EF also realize two feedback loops, a project feedback loop that
takes place in the usage phase and an organizational feedback loop that takes place after a
project is completed. The second feedback loop changes or improves the organization’s
understanding of risk assessment by packaging and reusing experience and making it
accessible to future projects. New methods and techniques can be defined or old ones
refined.
3.3 Information Structure for the EF
* 1
Project
1 uses 1 creates
Reusable element repository Repository Assessement repository
1
version : undefined
last_updated : undefined is organised by 1
Concern
1 n
1
1
*
* 5
is divided into
belongs to
*
Reusable element Element * 1 Viewpoint
is linked to*
*
Risk analysis element
CORAS experience package
author : string
date of creation : string
finalized : boolean
description : string
assessment area : string
linked to : undefined
title : string
list of elements : undefined
Figure 3.2 Information Structures for the CORAS Repository and CEP
In practice, the result of the PO is the Assessment Repository while the EF materializes in
the form of a Reusable Element Repository (Figure 3.2). From the information structure,
it is clearly seen that the content of a concern with respect to a particular viewpoint is
found in the element class itself. Elements in this respect are all kind of experience stored
either in AR or RER. The RER focuses on storing reusable UML models, table patterns
and formats, as well as supporting the process of experience internalization in an effort to
improve the risk management practice. The AR focuses on storing and delivering concrete
experience from already completed assessments and/or assessments in progress. Although
the roles of the AR and RER are separate, they interact to support each other. Further,
though not shown, the reusable element class and risk analysis element class inherit from
the XML data models (or types).
During the design stage, a proposal to incorporate the CEP as part of the elements was
also considered, but eventually abandoned. The reasons being that – firstly, to impose
package type at the lowest level, i.e. by integrating any specific information inside the
UML model itself will be troublesome as there are many different types of UML diagram,
which prohibits a clear-cut approach (if only there is just one type of diagram - class
diagram!); secondly, one could encode any additional CORAS-specific tags in the
generated XML output but this approach by means of post-rendering complicates the
process of information exchange with the repository and may result in a non-canonical
XML document.
The internal data structure of both sub-repositories mirror the decomposition model that
links together CORAS concerns and viewpoints as outlined previously in Figure 2.1. The
sub-repositories are also organized into groups of elements which we regard as CORAS
Experience Packages – the main product of our EF. Such packaging scheme functions by
giving a structure on how to cluster together various experience in support of the
operation of the CORAS platform.
3.4 CORAS Experience Package
As a means to support efficient manipulation of the repository, a unique CORAS
Experience Package (CEP) class has been introduced into the information structure. One
or more element(s) in the repository can be linked to a CEP class, which is also an
element per se. A CEP class is described by three parts: (i) a characterization part used to
classify packages in the experience base; (ii) a relationship part used to establish relations
between packages; and (iii) a body part that contains the content of the experience
package itself.
Each CEP is associated with a package type that defines the type of attributes that will be
used in its characterization part; the type of links that will be used in its relationship part,
and the type of entities that will compose its body.
Package attributes contains well-defined naming and typing. These attributes build
classification taxonomy for each CEP. The attributes effectively define facets that are
filled in by the author of an experience package to characterize the package being
submitted to the repository. These attribute values are then used to search the repository
for packages of interest. Package attributes are typed as “title”, “author”, “date of
creation”, “description”, “finalized” and “assessment area”.
Package links also have well-defined naming and typing. As they are used to establish
relationships between packages, a package link can be typed as a pointer to a CEP or a list
of them. The CORAS platform is built atop of a web-based native XML database that
supports URL addresses as pointers to internal CEPs. For this reason, a link can be typed
as a URL address or a list of them.
Package entities are typed as an element or as a list of elements. There is no constraint on
the type pf elements that can be stored within a package. From a practical point of view,
the repository may store of wide variety of elements that capture experience, including
annotation and feedback. An example of important constituents is guidelines and
methodology for the use of UML to support the risk assessment methodology. Package
entities can also employ similar URL referencing mechanism as package links.
Figure 3.3 illustrates the properties of a CEP, along with its attributes, links and entities in
the top left dashed box of the diagram. In the bottom is an instance of a CEP with all the
parameters instantiated. The arrows show the association between linked entities and their
original representation (in the forms of tables, UML diagrams, fault tree etc.).
The CEP class is an important component, without which the EF concept would not have
been possible to be put to practise. The usefulness of the CEP is summarized as follows:
- All CEP attributes are useful for searching.
- CEP links are useful for associating present CEP with other similarly motivated CEP.
- CEP entities contain useful experience for reuse.
Generally, CEP allows experience to be packaged in a systematic and structured manner
thereby fulfilling our initial goals. Similar to the JCI EMS [Li02], the CORAS experience
management system consists of only one package type, making it a specialized experience
base, exclusively for risk analysis elements. It is also possible to have different types of
CEPs, for instance a package of type “Project” that may be useful in cataloguing groups
of smaller packages.
Attributes
Title: string CORAS
Experience CEP2
Author: string …
Date of creation: string Package
Type …
Description: string …
Finalized: Boolean
Disclosure of patient
data over network
Assessment area: string Disclosure of data
through the firewall
Disclosure during
transfer on ISP
Disobedient users
(from Internet) network,dueto
physical access
D
Links Special hw and sw at
Special hw and sw at Unauthorised use
Anyother
connectionto
Installation of
"malicious" sw by
Linked to: linked to other CEPs
thelines(OTE, theswitches ofATTRACT Internetfrom
ATTRACT users users that disobeys
Vodaphone) (FORTHnet) rules
thatdisobeysrules
21 <> <>2 3
22 24
Theme1 Theme2
Asset3
Each box can be split into two boxes,
with an AND-gate between Asset1
value =1
value = 3
CriteriaID Criteriadescription Asset4 Asset5
Entities
…
…
Asset2
value = 5
value =7 value =3
<> <>
List of elements: linked to other elements Stakeholder1 Stakeholder2
CEP1
Title: Telemedicine Trial 2 Linked to: CEP2
Author: Eva S & Eva S
Date of creation: September 9 2002 List of elements:
Description: teleconsultation services in cardiology swot1.xml
Finalized: No sys_desc.xml
Assessment area: Telecardiology, WebOnCOLL abstract.xml
Figure 3.3 CEP and its instantiation
3.5 Technologies for Deployment
One of the aspects in which experience management differs, or rather expands fro m
knowledge management is that the former also looks at the methods and technologies that
are suitable in facilitating the necessary process. Here, it is important to note that EF, as
an important ingredient of experience management system, can benefit fro m the use of
tools. Thus, one of the crucial decisions to be made when building an EF infrastructure is
the choice between using open-source technologies or proprietary tools such as Lotus
Notes - a workflow application, SpotFire - a Visual Query Interface (VQI) tool [Ma01] or
Nvivo [Pe96]. We examined the potential of applying workflow and VQI technologies to
the specific problem in CORAS, but decided they had inadequate support for retrieval.
Tools like Nvivo can be used to automate the searching and coding, as well as facilitate
searching for trends and packaging the results. However the tool is not portable to the
Web, which is one of our project requirements. The fact that none of these tools are open-
source tools is superfluous. Consequently, we decided to implement our system utilizing a
suite of open-source tools, built upon a native XML database called eXist5 . eXist is tightly
integrated with Apache’s Cocoon6 publishing framework. Cocoon offers a powerful
mechanism called XSP to write XML-based dynamic web pages which fits well with
eXist’s search engine that has been designed to provide fast XPath queries, using indexes
for all elements, text and attribute nodes. eXist is lightweight and well suited for the
deployment of our repositories. The server is accessible through easy to use HTTP and
XML-RPC interfaces and supports the XMLDB API for Java programming. Furthermore,
the latest version of eXist also supports Web-based Distributed Authoring and Versioning
(WebDAV) a powerful HTTP extension that allows users to collaboratively edit and
manage files on remote web servers.
Some of the advantages of adopting a web-based approach are:
-The system can be easily deployed across different platform and OS, making it a highly
distributed and portable solution.
-The system can be extended to interoperate with future web services to provide
additional value-added functionalities.
3.6 Initial Results and Trials
Six trials have been planned for the CORAS project; three within e-commerce (one of
which has already been completed) and three within telemedicine (two of which has been
completed) to measure the effectiveness of the framework. The completed trials were
conducted prior to the completion of the prototype CORAS platform, so no substantial
findings on the use of the platform are currently available. However, initial informal
evaluation of the platform, which focused mainly on its usability and linked interfaces,
has found the system to be acceptable. Users are able to navigate and query the repository,
as well as to manipulate results via the CEPs. Future trials will evaluate the platform and
test its effectiveness in supporting the CORAS methodology.
5
Open-source XML database, largely developed by Wolfgang Meier (http://exist.sourceforge.net)
6
Open-source XML publishing framework (http://xml.apache.org/cocoon)
4 Conclusion and Future Work
In this paper we described an ongoing work that aims to build a generalized Experience
Factory approach into CORAS, which is model-based risk analysis framework for
security critical applications. The planned usage of the platform is geared towards
consistent use and integration into the CORAS risk management process. The purpose is
to promote the reuse and sharing of risk analysis results, as well as to improve the
effectiveness and efficiency of model-based risk assessment. We looked at the properties
of the prototype EF-driven CORAS platform including the information structure of the
repository and its experience package. The prototype and its web approach, takes
advantage of modern technologies like XML for distributed storage, access and
dissemination of relevant knowledge. The prototype encompassed only some of the
automated features that are required of a system aimed at supporting an EF. Much
technical and organizational work are pending. The ultimate goal of an EF -driven system
is to turn an organization into one which is shaped by constant learning. Therefore, having
obtained and stored the explicit knowledge/experience in the experience base, the next
step is to ensure that such experience is internalized as active knowledge and practical
skills. This is still a largely semi-automated process in CORAS which indicates room for
further research and improvement.
Immediate plans have been made to extend the functionality of the CORAS platform. This
includes adding: (1) automatic consistency and semantic translation for the stored
experiences (for instance between a RA table and UML model) (2) content management
features: authentication and backup (3) an XML data model targeting model-based risk
analysis (currently absent in the XML industry).
Acknowledgement
The authors wish to thank the European Commission for supporting the CORAS project,
as well as all the partners from the project consortium - CTI (Greece), FORTH (Greece),
IFE (Norway), Intracom (Greece), NCT (Norway), NR (Norway), RAL (UK), Sintef
(Norway), Solinet (Germany) and Telenor (Norway) – for their excellent contribution
and cooperation.
Bibliography
[Aa02] Aagedal, J. Ø., Braber, F. den, Dimitrakos, T., Gran, B. A., Raptis, D., Stølen, K.:
Model-based Risk Assessment to Improve Enterprise Security, 6th IEEE International
Enterprise Distributed Object Computing Conference, September, 2002.
[ABT00] Althoff, K.-D., Bomarius, F. & Tautz, C.: Knowledge Management for
Building Learning Software Organizations In Information System Frontiers Journal, Vol.
2, Nr. 3/4, 349-367, 2000.
[Ba92] Basili, V.; Caldiera, G.; McGarry, F.; Pajerski, R.; Page, G.; Waligora, S.: The
Software Engineering Laboratory-an Operational Software Experience Factory,
International Conference on Software Engineering, 1992.
[Ba01] Basili, V.; Costa, P.; Lindvall, M.; Mendonca, M.; Seaman, C.; Tesoriero, R.;
Zelkowitz, M.: An experience management system for a software engineering research
organization, Proceedings of the 26th Annual NASA Goddard Software Engineering
Workshop, 2001.
[Ba02] Basili, V.R., McGarry, F.E., Pajerski, R., Zelkowitz, M.V.: Lessons learned from
25 years of process improvement: The Rise and Fall of the NASA Software Engineering
Laboratory, Proceedings of the 24th International Conference on Software Engineering,
2002. ICSE 2002. May 2002.
[BCR94] Basili, V. R., Caldiera, G., and Rombach, D. H.: The Experience Factory,
Encyclopaedia of Software Engineering -2 Volume Set, pp. 469-476, 1994.
[Di02] Dimitrakos, T. et al.: Integrating Model-based Security Risk Management into e-
Business Systems Development. 2nd IFIP Conference on e-commerce, e-business, e-
government. Lisbon, 7-9 October, 2002.
[Gu02] Gustavsen, T.S., Houmb, S-H., Gran, B. A. Stølen, K.: Security Risk Analysis in
e-Commerce, 7th Nordic Workshop on Secure IT Systems 2002.
[HSW98] Houdek, F., Schneider, K. and Wieser, E.: Establishing Experience Factories at
Daimler Benz: An Experience Report, Proc. 20th Int’l Conf. on Software Engineering,
Kyoto, May 1998.
[Iv02] Djordevic, I., Gan, C., Scharf, E., Mondragon, R. et al.: Model-based risk
management of security critical systems. In Proc. Risk Analysis III, series: Management
Information Systems, Vo lume 5, WIT Press, 2002.
[KJL00] Koennecker, A., Jeffery, R., Low, G.: Implementing an experience factory based
on existing organisational knowledge, Proceedings of the 2000 Australian Software
Engineering Conference, 2000.
[La00] Lano, K., Clark, D., Androutsopoulos, K. and Kan, P.: Invariant-based Synthesis
of Fault-tolerant Systems. TRTFT 2000, Pune, India, 2000.
[LAC00] Lano, K., Androutsopoulos, K. and Clark, D.: Structuring and Design of
Reactive Systems using RSDS and B. FASE 2000, LNCS, Springer-Verlag, 2000.
[LAK00] Lano K., Androutsopoulos, K. and Kan, P.: Structuring Reactive Systems in B
AMN. In ICFEM 2000, IEEE Computer Society Press, 2000.
[Li02] Lindvall, M., Frey, M., Costa, P., Tesoriero, R.: Lessons Learned about Structuring
and Describing Experience for Three Experience Bases, Lecture Notes in Computer
Science, 2001.
[Ma01] Manoel Gomes de Mendonça Neto, Carolyn B. Seaman, et al.: A Prototype
Experience Management System for a Software Consulting Organization. Proceedings of
the International Conference on Software Engineering and Knowledge Engineering
(SEKE01), Buenos Aires, Argentina, June 2001.
[Pe96] PERFECT Consortium: PIA Experience Factory, The PEF Model, ESPRIT Project
9090, D-BL-PEF-2-PERFECT9090, 1996.
[St02] Stølen, K. et al.: Improving security through model-based risk assessment,
Business CBSE Chapter 11, Kluwer Academic Publishers, 2002.
[WCF99] Wyss G., Craft, R., and Funkhouser, D.: The Use of Object-Oriented Analysis
Methods in Surety Analysis. Sandia National Laboratories Report, 1999.