The AORDD Process

The underlying methodology of the AORDD framework is the AORDD process.

The AORDD process [47] is based on the CORAS integrated system development and risk management process [97], structured according to the phases of the Rational Uni…ed Process (RUP) [86] and the viewpoints of the Reference Model for Open Distributed Processing (RM-ODP) [56]. As for the CORAS integrated system development and risk management process, the whole or a part of an information system con…gured into a ToE is designed, analysed and composed according to a particular RM-ODP viewpoint in all iteration of the AORDD process. (Note that the ToE is called Target of Assessment (ToA) in CORAS).

Hence, security assessment is an integrated activity of the development that drives all iterations of the AORDD process. Security as a quality attribute of the ToE is by this addressed as early as possible and hopefully at the right time for a reasonable price. More information on how to integrate security assessment into the development of an information system is given in Stølen et al. (2002) [97].

Rather than describing all perspectives of the AORDD process the following description is focused on providing an overview of the AORDD process and to explain how it di¤ers from the CORAS integrated system development and risk management process. Readers are referred to Stølen et al. (2002) [97] for other details.

The AORDD process di¤ers from the CORAS process in that it provides tech-niques, syntax and some semantic for describing security solutions (called treat-ment options in CORAS) as security solution aspects and for composing the security aspects with a primary design model. This is then used as input to the AORDD security solution trade-o¤ analysis in sub-process 5.

Modelling the security solutions as security solution aspects ease the task of de-veloping and evaluating alternative security solutions in the risk treatment sub-process (sub-sub-process 5) of the CORAS risk management sub-process, which is part of the CORAS integrated system development and risk management process.

This also enhances software evolution and increases reusability. However, as the CORAS risk management process and the underlying CORAS MBRA

method-82 11. The AORDD Process

ology do not include guidelines for evaluating alternative security solutions and identifying the most e¤ective set of security solutions for a security problem or challenge, which is a critical success factor for cost-e¤ective development of secu-rity critical information systems, these issues need to be addressed explicitly in the AORDD process. Thus, the AORDD process provides activities, techniques and guidelines that assist a decision maker, designer or the like in choosing from alternative security solutions. The AORDD process also o¤ers guidelines on how to estimate the involved variables in security solution decision support.

Figure 11.1 illustrates the iterative nature of the AORDD process while Figure 11.2 gives an overview of the activities involved in the requirement and design phases. The AORDD process consists of a requirement phase, a design phase, im-plementation phase, deployment phase and a maintenance phase. Development spirals from requirements to maintenance and in each phase development ac-tivities are structured into iterations. Work moves from one phase to the next after …rst iterating through several sub-phases that end with acceptable analysis results.

It should be noted that the analysis activity in AORDD di¤ers from the assess-ment activity, as shown in Figure 11.1. In the AORDD process assessing risks concern identifying potential security problems and to identify and evaluate al-ternative security solutions to solve the security problem or challenge while the analyse activity refers to the veri…cation and analysis of the composed models to identify design ‡aws. Details on the latter is in Georg, Houmb and Ray (2006) [35].

As can be seen in Figure 11.1 each phase and all iterations in each phase includes a security assessment activity. This security assessment activity is where the secu-rity risks to a ToE (or information system) is identi…ed and where the alternative security solutions to solve the security risks are analysed. As described in Chap-ter 5 security assessment is a specialisation of risk management for the security domain that was adapted into a MBRA domain for security critical information systems by the CORAS project. In the AORDD framework the risk assessment process of CORAS has been augmented with activities to support and execute the AORDD security solution trade-o¤ analysis.

The activities of the security assessment step in the AORDD process is as fol-lowing:

Sub-process 1: Context identi…cation

–Activity 1.1: Identify purpose and scope of assessment

–Activity 1.2: Describe the target of evaluation (ToE), business perspectives and the security environment

11. The AORDD Process 83

Fig. 11.1.Outline of the AORDD process

Inception

Refine and update Refine and update

Inception

Refine and update Refine and update

Inception

Refine and update Refine and update

Inception

Refine and update Refine and update

Fig. 11.2.Overview of the activities of the requirement and design phase of the AORDD process

84 11. The AORDD Process

–Activity 1.3: Identify system stakeholders

–Activity 1.4: Identify assets and have stakeholders assign values to assets –Activity 1.5: Describe the asset-stakeholder graph

–Activity 1.6: Describe relevant security policies (SP)

–Activity 1.7: Identify and describe the security risk acceptance criteria (SAC) Sub-process 2: Risk identi…cation

–Activity 2.1: Identify security threats to assets from the security environment –Activity 2.2: Identify vulnerabilities in ToE, security policies, security processes,

security procedures and the security environment

–Activity 2.3: Document misuse scenarios and group misuses into misuse groups

Sub-process 3: Risk analysis

–Activity 3.1: Estimate impact of misuse –Activity 3.2: Estimate frequency of misuse Sub-process 4: Risk evaluation

–Activity 4.1: Determine level of risk for each set of impact and frequency –Activity 4.2: Evaluate risks against the security risk acceptance criteria

(SAC)

–Activity 4.2: Categorise risks in need of treatment into risk themes –Activity 4.3: Determine interrelationships among risk themes –Activity 4.4: Identify con‡icts among risk themes

–Activity 4.5: Prioritise risk themes and risks –Activity 4.6: Resolve identi…ed con‡icts Sub-process 5: Risk treatment

–Activity 5.1: Identify alternative security solutions and group these into se-curity solution sets

–Activity 5.2: Identify e¤ect and cost of all alternative security solutions –Activity 5.3: Model all security solutions as security solution aspects using

RDD modelling elements

–Activity 5.4: Compose security aspects with primary model and compose RDD information

11. The AORDD Process 85 –Activity 5.5: Evaluate and …nd the best-…tted security solution or set of

security solutions using the AORDD security solution trade-o¤ analysis The main di¤erence from the activities of the CORAS security assessment process is the re…nement of the activities in sub-process 1, the use of the concept misuse rather than unwanted incident in sub-process 2, a clear separation of potential con‡icts among risk themes and risks in sub-process 4 and a re…nement and extension of the activities of sub-process 5. It is in sub-process 5 that the security solution decision support is made explicit by use of the AORDD security solution trade-o¤ analysis to support the choice of security solution or set of security solutions among alternatives.

As can be seen in Figure 11.2 the security assessment step in the requirement spec-i…cation phase is done using the functional and security requirements as the ToE.

The result of this activity is a set of unresolved security problems or challenges.

These problems are either solved in sub-process 5 of the respective iteration or transformed into security requirements for the next iteration. In the design phase the security risk assessment is done using the available design speci…cation as the ToE. Similar to the requirement phase the security problems or challenges identi…ed are either solved as a security solution design decision in sub-process 5 of the security assessment step of a particular iteration or transformed into security requirements in the next iteration. This means that whenever new se-curity requirements are introduced the relevant parts of the information system goes through a new requirement security risk assessment before proceeding to the next development phase.

Details on the AORDD process are in Houmb et al. (2004) [47]. Details on the AORDD security solution trade-o¤ analysis are in Part 4, Houmb et al. (2006) [48] in Appendix B.2 and Houmb et al. (2005) [44] in Appendix B.3. Details on the AORDD framework are in Houmb and Georg (2005) [42], Appendix B.1.

Part IV