The …rst version of CRAMM was issued as a set of paper-based forms. Later CRAMM was supported by software tools and now it is fully computerised. CRAMM consists of three stages: (1) Asset identi…cation and valuation. (2) As- sessment of threats, which is similar to the identi…cation and analysis of risks activities in the AS/NZS 4360 risk management process. (3) Assess vulnerabili- ties and suggests countermeasures.
CRAMM has 10 prede…ned asset tables to support the identi…cation and valua- tion of assets. Furthermore, the asset tables are structured into asset categories that are linked to lists of known vulnerabilities and threats for each asset cate- gory. The CRAMM software tool lists these to you automatically based on the result of the asset identi…cation and valuation in stage 1 of CRAMM.
Furthermore, there are also sets of associated countermeasures to each of the threats and vulnerabilities stored in respective repositories in CRAMM. The CRAMM software tool also suggests countermeasures automatically based on information such as the set of assets identi…ed, the values assigned to these as- sets and the identi…ed threats and vulnerabilities. However, there is a prede…ned balance between physical, personnel, procedural and technical countermeasures that is tailored for medical systems within the CRAMM software tool. This makes the latter feature less valuable to other types of information systems. To make CRAMM e¤ective for other types of information systems all decisions made must be recorded and reviewed and the associated repositories updated to re‡ect the e¤ects of these decisions. Hence, the software tool needs to learn from experience. The CORAS approach makes use of the asset-driven approach of CRAMM and has adopted the asset valuation technique of CRAMM. More details on the CORAS approach is given in the following.
5.4 The CORAS approach to assessing and managing
security risks
IST-2000-25031 CORAS: A platform for risk analysis of security critical sys- tems [19] was a Fifth Framework European Commission IST-project that ran from 2000-2003. The aim of the CORAS project was to develop a framework for model-based risk assessment of security critical systems. The main result from the CORAS project is the methodology for model-based risk assessment that has four supporting pillars: (1) The risk documentation framework based on RM-ODP. (2) The risk management process based on the AS/NZS4360 risk man- agement process. (3) The integrated risk management and system development process based on the Uni…ed Process (UP). (4) The platform for tool inclusion
48 5. Risk Assessment and Management of Information Systems System development and maintenance process System documentation framework Risk management process
Platform for tool- inclusion based on data integration Model-based risk management RM-ODP XML AS/NZS 4360 RUP System development and maintenance process System documentation framework Risk management process
Platform for tool- inclusion based on data integration Model-based risk management RM-ODP XML AS/NZS 4360 RUP
Fig. 5.2.The …ve main components of the CORAS framework
based on data-integration using XML. However, the main bene…ts of the CORAS approach is the tailoring of a set of risk assessment methods from the safety do- main for the security domain, as well as the focus on integrating risk management into the system development process. The latter ensures that risks are handled throughout the development process at the right time and for the correct cost. Figure 5.2 gives an overview of the CORAS framework [97].
The CORAS framework is model-based in the sense that it gives detailed recom- mendations for modelling both the system and the risks and treatments identi- …ed during the security (risk) assessment using the Uni…ed Modeling Language (UML). This means that the CORAS framework provides support, guidelines and UML modelling elements which extend the value of both system development and risk assessment activities in three dimensions [97]: (1) To improve precision of descriptions of the target system. (2) As a media for communication between stakeholders involved in a risk assessment. (3) To document risk assessment re- sults and the assumptions on which these results depend. Details are in Stølen et al. (2002) [97].
Also, the risk assessment methodology in CORAS integrates techniques from partly complementary risk assessment methods. These include HazOp, FTA,
5.4 The CORAS approach 49
FMECA, Markov analysis and CRAMM. Like CRAMM the CORAS method- ology is asset-driven, which means that the identi…cation of assets is the driving task in the risk assessment process. Actually, if no assets are identi…ed there is no need to carry out the risk assessment.
5.4.1 CORAS risk management process
The CORAS risk management process is based on the AS/NZS 4360:1999 risk management process and the recommendations in ISO/IEC 17799-1:1999 [55]. The underlying terminology of the CORAS risk management process is supported by the two standards: ISO/IEC TR 13335-1 [54] and IEC 61508:1998 Functional safety of electical/elect-
ronic/progammable electronic safety-related systems [51]. As for AS/NZS 4360 the CORAS risk management process consists of seven sub-processes where …ve are sequential risk assessment related sub-processes and two are parallel risk man- agement related sub-processes. In order to adapt the standard for use in the secu- rity domain CORAS decomposed the …ve sequential sub-processes into activities as shown in the activity list below. For each sub-process the CORAS methodol- ogy provides guidelines with respect to which models should be constructed and how these models should be expressed to support the risk assessment activities. The main di¤erence from the AS/NZS 4360 risk management process is that the CORAS risk management process has a stronger focus on assets and that their process is asset-driven. The risk management process is therefore extended by relevant activities for asset identi…cation and valuation. As for CRAMM the identi…cation and valuation of assets guides the risk assessment process. More details are in Stølen et al. (2002) [97] and the other publications from the project. Please see [19] for details.
50 5. Risk Assessment and Management of Information Systems
Sub-process 1: Identify Context Activity 1.1: Identify areas of relevance Activity 1.2: Identify and value assets
Activity 1.3: Identify policies and evaluation criteria Activity 1.4: Approval
Sub-process 2: Identify Risks Activity 2.1: Identify threats to assets Activity 2.2: Identify vulnerabilities of assets Activity 2.3: Document unwanted incidents Sub-process 3: Analyse Risks
Activity 3.1: Consequence evaluation Activity 3.2: Frequency evaluation Sub-process 4: Risk Evaluation
Activity 4.1: Determine level of risk Activity 4.2: Prioritise risks
Activity 4.3: Categorise risks
Activity 4.4: Determine interrelationships among risk themes Activity 4.5: Prioritise the resulting risk themes and risks Sub-process 5: Risk Treatment
Activity 5.1: Identify treatment options