Modifíquese el párrafo 2 de modo que diga:

The three security RM standards studied are: ISO/IEC 27005 [ISO08], NIST 800-30 [SGF02] and the IT Grundschutz [Bun05c]. We rst present the artefacts produced for ISO/IEC 27005. For the other two standards, only the metric analysis tables and the conclusions are presented. Their respective metric-related steps and the enriched ISSRM domain model are provided in Appendix D.

ISO/IEC 27005

As depicted in the research method (Section 5.1), we rst gather all metrics used throughout the standard [ISO08]. The steps of the standard involving concept mea- surement are described below. The following conventions are used: metrics are in italic and associated concepts in bold. The page number of the standard, providing information about the metric, is mentioned for traceability purpose.

• Assign values to the assets under review. [ISO08, p. 15]

• Express the business impact value for the consequence. [ISO08, p. 15] • Assess the likelihood of the incident scenarios, or event. [ISO08, p. 15] • Take into account how often the threats occur. [ISO08, p. 15]

• Take into account how easily the vulnerabilities may be exploited. [ISO08, p. 15]

• Estimate how eectively controls reduce vulnerabilities. [ISO08, p. 16]

• Estimate the level of risk, which is a combination of the likelihood of an incident and its consequence. [ISO08, p. 16]

The various metrics used are analysed in a table. The two rst columns are for the concepts of the ISSRM domain model and the concepts of the studied approach. This alignment is a reminder of the one of Table B.1 in Appendix B. The concepts are ordered by category, respectively standing in the asset-, risk- and risk treatment- related categories. The categories are delimited by a double line in the table. The two following columns depict the associated metric(s) of the studied approach, as called in the approach, and the associated metric(s) of the ISSRM domain model. Next, a Denition column indicates how this metric is dened or calculated. For example, if a level has only to be chosen by the user in a scale, this column indicates User dened for this metric. At the opposite, if the metric depends, to be calculated,

5.4 Survey of ISSRM methods for metrics validation 125

on other metrics or on some tools (matrix, software tools), this is mentioned in this column. Finally, the last column is the Unit column. If the metric is quantitative, its unit is displayed (e.g., , hours, etc.). Otherwise, the proposed scale is reported.

The only asset-related concept measured in ISO/IEC 27005 is the concept of asset (in general) (Table 5.4). The related metric is the value of assets. Primary asset and supporting asset, being specialisations of asset in general, are also measured with this metric. Then, the business impact value associated to each asset is estimated, based on the value of the asset. Risk estimation is based on the successive consider- ations of threat and vulnerability, leading to event likelihood. Combining it with the business impact value, it is possible to estimate the risk level. Finally, controls from ISO/IEC 27005, which can be aligned with both security requirement and control from our domain model, are estimated according to their eectiveness, mainly in reducing vulnerabilities. The standard, as opposed to most of the methods, only provides a gen- eral guideline to ISSRM. As a consequence, it is generally up to the user to dene if the concepts are qualitatively or quantitatively estimated (cf. Unit and Denition column).

Table 5.4: Metrics analysis table for ISO/IEC 27005

ISO/IEC 27005 [ISO08]

ISSRM concept ISO/IEC 27005 concept ISO/IEC 27005 metric ISSRM metric Definition Unit

Asset Asset Value / User defined User defined

Business asset Primary asset Value Value User defined User defined IS asset Supporting asset Value / User defined User defined Risk Risk Risk level Risk level f(Event,Consequence) User defined Event Event Likelihood Potentiality f(Threat,Vulnerability) User defined Impact Consequence Business impact value Impact level f(Asset) User defined Threat Threat Frequency of occurrence Likelihood User defined User defined Vulnerability Vulnerability Easiness of exploitation Vulnerability level User defined User defined Security requirement

Control Effectiveness Risk reduction User defined User defined Control

In ISO/IEC 27005, as said above, the value of asset in general is estimated for asset-related concepts. In the GQM study (and after the complete review of the ISSRM sources), the focus is rather put on the value of business assets, which is more relevant. IS assets being only the support of business assets, it is worth to consider the value of only business assets. Moreover, in IS security, the value of IS assets (e.g., the replacement cost of a computer) is generally considered as negligible compared to the value of the processed information at the business level (e.g., the client information, the estimates, etc.). Finally, it is necessary to consider the value of business assets for estimating the security objectives and assess the signicance of risks, as depicted in the ISSRM domain model (cf. Figure 4.4). IS assets are not involved in this process. For risk-related concepts, the metrics are very close to those proposed in Section 5.3. Risk, event, consequence, threat and vulnerability of ISO/IEC 27005 have all an associated metric. Moreover, ISO/IEC 27005 proposes additional characteristics for threat source (equivalent to threat agent in the ISSRM model). For example, it is possible to dene the motivation, the capabilities and the resources available of a threat source for a

deliberate threat, or some factors that could inuence the threat source in the case the threat is accidental. However, such characteristics are not included in the metric analysis table, because they are indicators helping to dene frequency of occurrence and the risk level in general, rather than metrics themselves (cf. Section 5.2.1. For the risk-treatment related concepts, the eectiveness of controls is estimated, which has the same objective as risk reduction of security requirements in the ISSRM domain model. The concept of risk treatment is not estimated in terms of eectiveness. Finally, the cost dimension is not needed to be measured in ISO/IEC 27005.

Figure 5.5 summarises the metrics proposal of ISO/IEC 27005 from the point of view of the ISSRM domain model. The reader should note the introduction of the Security objective class, compared to the preceding domain model of Figure 4.4.

Figure 5.5: ISSRM domain model enriched with the metrics proposed by ISO/IEC 27005

NIST 800-30

Estimation in NIST 800-30 focuses on the concept of risk (Table 5.5). First, the user denes the likelihood of the threat and then the magnitude of impact. Based on these two estimations, the risk level is dened with the help of a matrix. NIST 800-30 proposes three-level qualitative scales for each metric: High, Medium, Low.

The metrics proposed by NIST 800-30 (or semantically-equivalent metrics) have all already been identied with the GQM approach.

The IT-Grundschutz

For this standard, we study the third part entitled Risk analysis based on IT-Grundschutz [Bun05c]. Although the name of the document mentions risk analysis, the scope of the standard is RM, going from asset identication to control selection, as described in Section 2.1.

5.4 Survey of ISSRM methods for metrics validation 127 Table 5.5: Metrics analysis table for NIST 800-30

NIST 800-30 [SGF02]

ISSRM concept NIST 800-30 concept NIST 800-30 metric ISSRM metric Definition Unit Risk Risk Risk level Risk level Defined with a risk-level

matrix High, Medium, Low Event

Threat (vulnerability exercised by a given threat-source)

Likelihood Potentiality User defined High, Medium, Low

Impact Impact Magnitude Impact level User defined High, Medium, Low

The part of the IT-Grundschutz dealing with risk analysis, like the part called Methodology, is mainly devoted to binary checks of adequate protection provided by (implemented or envisaged) security measures. The concepts are not valued qual- itatively5 _{or quantitatively. The only exception is the security requirement concept,}

which is estimated at the beginning of the process on the scale normal/high/very high, in the aim of identifying the assets that need a higher level of security (Table 5.6).

When applying GQM, we also propose to estimate the security need of security objectives, which are equivalent to the security requirements in the IT-Grundschutz.

Table 5.6: Metrics analysis table for the IT-Grundschutz

The IT-Grundschutz [Bun05c]

ISSRM concept IT-Grundschutz concept IT-Grundschutz metric ISSRM metric Definition Unit Security objective Security requirement Security requirement level Security need User defined Normal, High, Very high