• No se han encontrado resultados

La interoperabilidad de los recursos lingüísticos

2 Los recursos

2.1 Los recursos públicos de interés lingüístico

2.1.3 La interoperabilidad de los recursos lingüísticos

The structure of the underlying trade-o¤ analysis method and procedure for the AORDD security solution trade-o¤ analysis are such that they are easy to tai-lor, change and maintain. This ‡exibility is necessary to easily incorporate any updates from experience gained during the use of the AORDD security solution trade-o¤ analysis. To ensure the required level of ‡exibility, the trade-o¤ analysis method and procedure are built as a set of replaceable sub-components grouped into levels that are linked together through interfaces in such a way that the con-tent of each level is independent of each other provided that the required output is delivered accordingly. This means that components can be changed indepen-dently of each other while interfaces are dependent on the outputs provided from the lower level and the inputs required by the higher level and thus are depen-dent on these two types of information. For example, a component in one of the layers of the trade-o¤ method can be replaced without having to update other parts of the method provided that no interfaces are changed, but if an interface is changed, all components associated with the interface might be a¤ected.

Figure 14.1 illustrates the component-wise and hierarchical step-by-step structure of the underlying trade-o¤ method of Phase 2 of the AORDD security solution trade-o¤ analysis. The structure consists of four levels and follows the seven step trade-o¤ procedure described below. The AND gates in Figure 14.1 mean that all information coming in at the incoming arches are combined. The outgoing arches from an AND gate carries the result of the combination of the incoming information to the next level in the analysis. Each of the squares in Figure 14.1 represents a set of information, such as the set of information that contributes to the static security level. As the trade-o¤ tool directly implements the structure of the trade-o¤ analysis as shown in Figure 14.1 details of the content of each component and how information are AND-combined are described in relation to the trade-o¤ tool in Chapter 15.

The seven step trade-o¤ procedure is as follows.

Step 1: Estimate the input parameters in the set I where

I = fMI; MF; MT T M; MET M; MC; SE; SCg and MI is misuse impact, MF

122 14. Structure of the Trade-O¤ Analysis

Fig. 14.1. Overview of the structure and the step by step procedure of the trade-o¤

analysis

is misuse frequency, M T T M is mean time to misuse, M ET M is mean e¤ort to misuse, M C is misuse cost, SE is security solution e¤ect and SC is security solution cost. The output from Phase 1 of the trade-o¤ analysis is a set of secu-rity risks in need of treatment. A secusecu-rity risk is a composite of misuse, misuse frequency, misuse impact, MTTM and METM and a particular security risk is the unique combination of exactly one misuse, one misuse frequency, one misuse impact, one MTTM and one METM. The misuse cost denotes the …nancial and other costs that comes as a direct or indirect consequence of the misuse and is handled separate from the other misuse variables. The security solution e¤ect and cost are derived in activities 5.1 and 5.2 of the AORDD security assessment ac-tivity and are part of Phase 2 of the AORDD security solution trade-o¤ analysis, as described in Section 13.2.

14. Structure of the Trade-O¤ Analysis 123 Step 2: Estimate the static security level by examining the relevant factors from the development of the ToE according to the security assurance components in Common Criteria Part 3 and the asset values of the involved ToE assets as described in Section 13.2.1. Note that it is the assurance components in Com-mon Criteria Part 3 that is used and not the security functional components of Common Criteria Part 2. Recall that Common Criteria Part 2 and Part 3 are independent and that Part 2 contains classes of security functional components that address di¤erent factors of applying proper security functions to a system.

Hence, this part provides support for the selection and composition of security solutions in a system. Common Criteria Part 3 however describes a set of classes of security assurance components that are used by an evaluator in a Common Criteria evaluation to establish the necessary con…dence in the security level of a system. This is done through examining the resulting ToE or ToE design and the development documentation provided by the developer. This is the same strat-egy for evaluating software quality as is used in the safety standards IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic (E/E/PE) Safety-Related Systems [51] and DO-178B: Software Considerations in Airborne Systems and Equipment Certi…cation [89]. Similarly to the Common Criteria these two standards determine the quality of the end-product by examining the activities involved in the development. As standards tend to neither be easily accessible nor easy to interpret and employ in practice tools and methodology support are often helpful. An example of such for DO-178B is given in Gran (2002) [40], which describes a BBN topology for safety assessment of software based systems to support the DO-178B evaluation approach.

Step 3: Estimate the operational risk level using appropriate security assess-ment methods and models such as the availability prediction model described in Houmb, Georg, France, Reddy and Bieman (2005) [43]. This prediction model is tailored for estimating the level of availability for an information system or ToE but is applicable for estimating other security attributes as well. In the trade-o¤

analysis method, the prediction model is extended to include variables related to Common Criteria Part 2, such as attacker abilities, in addition to METM, MTTM, MF and MI. Figure 14.2 shows the variables involved when estimating the risk level of a ToE in the trade-o¤ analysis method for the AORDD security solution trade-o¤ analysis.

As can be seen in Figure 14.2 the operational risk level is derived by combining the existing security controls according to the recommendations in Common Cri-teria Part 2, the security risks identi…ed in the risk-driven analysis of Phase 1 of the AORDD security solution trade-o¤ analysis and the operational security level as described in Littlewood et al. (1993) [74]. It is important to note however that the main factor that separates the operational risk level from the static security

124 14. Structure of the Trade-O¤ Analysis

Fig. 14.2. Variables involved in estimating the risk level of a ToE in the trade-o¤

analysis method

level in the trade-o¤ analysis method is that the static security level expresses the risk level associated with the development activities while the operational risk level expresses the security level of the ToE and its security environment in its operational environment. Thus, the static security level makes use of the idea of quality through development activities while the risk level targets the security level of the end-product employed in its security environment. Note that both future events and current events relevant for the operational risk level can be es-timated when the subjectivistic approach is applied. Details on the subjectivistic approach is given in Chapter 7.

The operational security measures included in the trade-o¤ analysis method are the Mean Time To Misuse (MTTM), the Mean E¤ort To Misuse (METM) and the attacker abilities. MTTM denotes the mean calendar time between successful misuses (security breaches) while METM denotes the mean calendar time that an attacker needs to invest in order to perform a misuse. Here, the attacker e¤ort depends on the abilities of the attacker, such as the attacker skills (novice, standard, expert) and the resources availability to the attacker. Hence, METM is dependent on the attacker abilities. MTTM and METM are estimated according to the security adaptation of reliability theory as discussed in Littlewood et al.

(1993) [74].

The operational risk level also depends on the security functional components already employed in the ToE and the ToE security environment. In the trade-o¤

14. Structure of the Trade-O¤ Analysis 125