Aplicación de las prescripciones relativas a los buques tanque

There are ve security RM methods studied: EBIOS [DCS04b], MEHARI [CLU07b],

OCTAVE [AD01b], CRAMM [Ins03] and CORAS [VML+_{07]. As for security RM}

standards, rst we present all artefacts produced for EBIOS. The metric analysis table and the conclusions are then presented for the other methods, their measurement- related steps and their enriched ISSRM domain model being proposed in Appendix D.

EBIOS

The measurement-related steps of the EBIOS method are:

• Dene security needs of essential elements with security criteria constraining them. [DCS04b, p. 24]

• Dene attack potential of relevant threat agents combined with attack meth- ods. [DCS04b, p. 26]

5_{The binary check can in a sense be seen as a special case of qualitative estimation. However it is not}

• Dene the level of vulnerabilities associated to selected threat agents. [DCS04b, p. 28]

• Dene the threat opportunity based on the level of associated vulnerabilities or directly. [DCS04b, p. 29]

• Dene the impacts of the risks equal to the maximum of the security needs concerned. [DCS04b, p. 31]

• Dene the risk level, composed by the opportunity, the attack potential and the maximum of the security needs concerned. [DCS04b, p. 31]

• Dene risk coverage by selected security objectives. [DCS04b, p. 34]

• Dene security objectives coverage by selected security requirements. [DCS04b, p. 40]

Table 5.7 summarises the dierent concepts measured and their associated metrics. EBIOS starts by asking the user to value the security needs of essential elements for each security criterion. Then, the risk level is dened incrementally. First, the attack potential is dened , characterising a threat agent using an attack method. Second, the opportunity of the threats is estimated, based on the vulnerabilities level. Third, the impact is dened, being equivalent to the maximum of elicited security needs for the assets concerned by the impact. The level of risk is dened as the set of the three previous metrics. As for ISO/IEC 27005 [ISO08], EBIOS proposes to identify some characteristics of threat agents and attack methods, like motivation or type. Regarding risk-treatment related concepts, security objectives are estimated in terms of their risk coverage. Then, security requirements are estimated in terms of their security objective coverage. The various concepts in EBIOS are estimated by qualitative values. Table 5.7 recapitulates these scales, which the method recommends to adapt depending on the context.

Table 5.7: Metrics analysis table for EBIOS

EBIOS [DCS04b]

ISSRM concept EBIOS concept EBIOS metric ISSRM metric Definition Unit Security objective Security criterion on

Essential element Security need Security need User defined 0-4

Risk Risk

{Security needs con- cerned ; Opportunity ; Attack potential}

Risk level / {0-4 ; 0-4 ; 1-3}

Event Threat Opportunity Potentiality f(Vulnerability level) 0-4 Impact Impact Security needs con-

cerned Impact level

max(Security needs) for each Business asset 0-4 Threat Threat agent and At-

tack method Attack potential Likelihood User defined 1-3 Vulnerability Vulnerability Vulnerability level Vulnerability level User defined 0-4 Security requirement Security objective (risk) Coverage / User defined 0-2 Security requirement Security (functional)

requirement

(security objective)

5.4 Survey of ISSRM methods for metrics validation 129

The set of metrics proposed by EBIOS is close to the one dened in the GQM study. At the level of asset- and risk-related concepts, we do not notice any important dierence compared to the metrics of the GQM models. Only some minor dierences are observed. For example, the risk metric is decomposed into three metrics (security needs concerned, opportunity and attack potential) instead of a single element (risk level). Another example is that the value of the business assets is not estimated in the aim of dening the security needs. Security needs are directly dened by the user. The main dierence resides at the level of risk treatment-related concepts. EBIOS proposes a metric for assessing the coverage of risk by security objectives and another one for the coverage of security objectives by security requirements. This can be explained by the main objective of the EBIOS method, which rather than reaching the best ROSI, is to cover the identied risks completely. These two metrics do not represent rst class metrics regarding our objectives and are therefore not included in our set of metrics represented in the GQM models. However, they remain relevant and potentially implementable, mainly as additional information showing that no risk has been forgotten. Moreover, these two metrics can help in the implementation of the risk reduction, because they indicate the current state of considered risk (treated or not) at any time. Figure 5.6 summarises the metrics proposal of EBIOS from the viewpoint of the ISSRM domain model.

Figure 5.6: ISSRM domain model enriched with the metrics proposed by EBIOS MEHARI

First, MEHARI denes the classication value of each asset for each classication criterion on a proposed scale from 1 to 4 (Table 5.8). The second step is the estimation, based on various criteria, of the quality of each implemented security service. This quality level helps for the determination of the (so called) seriousness of the risk and its components. Based on this quality level, the user of the method estimates

various factors playing a role in the risk measurement. First, factors related to the cause of the risk are estimated. The factors (so called) are natural exposure to risk, eectiveness of dissuasive measures and eectiveness of preventive measures. Then, with the help of these factors, the potentiality of the cause of the risk is estimated. Second, factors related to the consequence of the risk are estimated. They include the so called eectiveness of protective or connement measures, eectiveness of palliative measures, eectiveness of recuperative measures. They are used as a mitigator of the estimated intrinsic impact (i.e. impact without any measure) to determine the real impact. Finally, the seriousness of the risk is deduced based on the potentiality metric of the cause and on the impact metric of the consequence.

Table 5.8: Metrics analysis table for MEHARI

MEHARI [CLU07b]

ISSRM concept MEHARI concept MEHARI metric ISSRM metric Definition Unit Security objective Classification crite-

rion on Asset Classification value Security need User defined 1-4

Risk Risk Seriousness Risk level Seriousness = f(Potentiality, Impact) defined with tables

Tolerable risk, Inadmissible risk, Unsup- portable risk

Event Cause Potentiality Potentiality

Potentiality=f(Natural expo- sure to risk, Effectiveness of dissuasive measures, Effectiveness of preventive measures) defined directly or with tables

1-4

Impact Consequence Intrinsic impact Impact level Intrinsic impact=classification

value 1-4

Impact Consequence Impact Impact level

Impact=f(Intrinsic impact, Ef- fectiveness of protective or confinement measures, Ef- fectiveness of palliative mea- sures, Effectiveness of re- cuperative measures) defined directly or with tables

1-4

Security require-

ment Security service Quality /

Questionnaire or user defined with guidelines, f(efficiency, robustness, permanency)

1-4

Security require-

ment Security measure

Effectiveness of dis-

suasive measures Risk reduction

f(quality security service) with tool or user defined 1-4 Security require-

ment Security measure

Effectiveness of pre-

ventive measures Risk reduction

f(quality security service) with tool or user defined 1-4 Security require-

ment Security measure

Effectiveness of protective or confine- ment measures

Risk reduction f(quality security service) with tool or user defined 1-4 Security require-

ment Security measure

Effectiveness of pal-

liative measures Risk reduction

f(quality security service) with tool or user defined 1-4 Security require-

ment Security measure

Effectiveness of re-

cuperative measures Risk reduction

f(quality security service) with tool or user defined 1-4 / / Natural exposure to

risk /

f(quality security service) with tool or user defined 1-4

As already seen in other ISSRM standards and methods like [DCS04b, Bun05c], at the asset-related concepts level, the security need is directly estimated. It is the only asset-related concept estimated. For risk-related concepts, our set of metrics does not

5.4 Survey of ISSRM methods for metrics validation 131

take into account such precise factors mitigating the risk level. MEHARI is designed to assess a running IS. In this case, dening risk mitigating factors coming from already implemented security measures is suited. In our case, our set of metrics should be usable for existing IS assessment, but also for IS in development. We, thus, do not propose to use pre-dened mitigating factors. Instead, the risk reduction metric used once a risk treatment and/or a security requirement is dened plays the role of risk mitigator. First, it is more generic, so the user can determine himself how he will use this metric. Second, in the case of IS assessment based on our ISSRM model, the risk reduction metrics can be used in the same way as the mitigating factors of MEHARI. It is also necessary to note that the metric of natural exposure to risk is not associated to any concept of the ISSRM domain. It is indeed related to the context of the organisation dened during the rst step of the ISSRM process (Figure 2.1). Quality of security services has also no direct semantically equivalent concept, but regarding the set of metrics of Figure 5.3, it is directly dependent on the total risk reduction of each security requirement.

OCTAVE

Like the IT-Grundschutz [Bun05c], OCTAVE is poor in terms of estimation (Table 5.9). The method proposes to estimate the impact of the risk on a qualitative scale. This estimation provides information supporting risk ranking and countermeasures prioritisation.

As already mentioned, the impact level is taken into account in the GQM set of metrics.

Table 5.9: Metrics analysis table for OCTAVE

OCTAVE [AD01b]

ISSRM concept OCTAVE concept OCTAVE metric ISSRM metric Definition Unit Impact Impact Impact level Impact level User defined High, Medium, Low

CRAMM

CRAMM is one of the few methods suggesting quantitative estimation (Table 5.10). For example, the severity of impacts is estimated on a scale from 1 to 10, but their cost in nancial gures. Then, the value of assets is determined based on both previous metrics. For threat and vulnerability, CRAMM proposes a qualitative estimation based on pre-dened scales. The measure of risk is further dened with the help of a matrix combining asset value, threat level and vulnerability level. Based on the dierent risks levels obtained, the method proposes suited countermeasures, each having its own security level. Their priority is nally assessed with the help of various factors, determining the theoretical implementation rank of each countermeasure. Some of them are the cost of the countermeasure and its eectiveness.

Compared to the set of metrics elicited with GQM in Section 5.3, the metrics of CRAMM are all covered by equivalent metrics, except for security level, eectiveness and priority, that are associated to the security requirement concept. For the two

Table 5.10: Metrics analysis table for CRAMM

CRAMM [Ins03]

ISSRM concept CRAMM concept CRAMM metric ISSRM metric Definition Unit IS asset Asset Value Value f(Severity, Cost) 1-10; $

Risk Risk Measure of risk Risk level

Measure of risk=f(Threat level, Vulnerability level, Asset value) using risk matrix

1-7

Impact Impact Severity Impact level User defined 1-10 Impact Impact Cost Impact level

User defined (only for Unavail- ability and Physical Destruction impacts)

$

Threat Threat Threat level Likelihood User directly defined or with the help of a questionnaire

Very Low, Low, Medium, High, Very High Vulnerability Vulnerability Vulnerability level Vulnerability level User directly defined or with the

help of a questionnaire

Low, Medium, High Security requirement

Countermeasures Security level / Provided in the

countermeasure library 1-7 Control

Security requirement

Countermeasures Priority / Priority=f(cost, effectiveness, various characteristics) Rank Control

Security requirement

Countermeasures Cost Cost Provided by tool Low, Medium, High Control

Security requirement

Countermeasures Effectiveness / Provided by tool Low, Medium, High Control

rst, they are close to, and redundant with, the risk reduction. Instead of measuring an intrinsic eectiveness leading to a security level, we estimate the risk reduction level that is more explicit considering our objective of maximising risk reduction. Regarding the priority of security requirement, it is not mandatory regarding the ROSI optimisation. However, it is sometimes interesting, like for dening a risk treatment plan [ISO05b], to schedule the control implementation.

CORAS

Table 5.11: Metrics analysis table for CORAS

CORAS [VML+07]

ISSRM concept CORAS concept CORAS metric ISSRM metric Definition Unit

Asset Asset Asset value Value User defined Very low, Low, Medium, High, Very high

Risk Risk Likelihood Potentiality User defined Rare, Unlikely, Possible, Likely, Certain

Risk Risk Consequence Impact level User defined Insignifiant, Minor, Moderate, Major, Catastrophic

Risk Risk Risk level Risk level Defined with tables Low, Moderate, Major, Extreme Security requirement Treatment Risk reduction Risk reduction User defined {Low, Mod., Maj., Ext.} => {Low,

Mod., Maj., Ext.} Security requirement Treatment Cost Cost User defined Low, Medium, High

The rst concept estimated in CORAS is the asset one through the asset value (Table 5.11). It is estimated on a qualitative scale having ve levels. Risk level is then