ASPECTOS ÈTICOS

After identifying and aligning concepts, it is necessary to identify the relationships existing between them. In this section, the literature (Section 4.2) is analysed to extract relationships between the concepts. The process used is similar to the one applied for the elicitation of ISSRM concepts (Section 4.1). Based on the excerpts of sentences used for concepts identication, and sometimes on some complementary information about relationships extracted from the documents, we dene relationships between concepts.

Table 4.5: Alignment table for RE security frameworks

Type Concept Haley et al. Firesmith The DITSCAP Moffet and Nuseibeh automation framework

Asset- related concepts (1) / Asset Asset Valuable asset (2) Asset / / (3) / / /

(4) Security concern Quality subfactor /

Risk-related concepts (5) Risk Risk Risk Safety risk Security risk (6) / / / (7) Impact Harm / Harm (8) Threat Danger Threat Hazard Threat

(9) Vulnerability Safety vulnerability Vulnerability Security vulnerability (10) Attacker Attacker / (11) Action / / Risk treatment- related concepts (12) / / /

(13) Security requirement Safety requirement Security requirement Security requirement (14) / Safety mechanism Countermeasure Safety tactic Safeguard Security mechanism Countermeasure

Elicitation of the relationship between two concepts

To illustrate the analysis of relationships, we show the denition of relationships be- tween the concept (8) (most often called threat in the literature) and (9) (called vul- nerability). The existence of a relationship between two concepts is not mandatory, but after the analysis of the denitions for the concept alignment (Section 4.3.3), we claim that these two concepts are related to one another.

In RM standards [ISO02b, AS/04], the concept of vulnerability does not exist. No relationship between the two analysed concepts is thus noticed. Regarding security- related standards, threat and vulnerability are related together in ISO/IEC 13335-1. A claim is found in the denition of vulnerability:

Vulnerability: a weakness of an asset or group of assets that can be exploited by one or more threats. [ISO04b, p. 3]

However, threat in this standard is not equivalent to concept (8) but to concept (11). CC also mentions vulnerability, but this concept is not clearly related to the one of threat (cf. Figure A.1).

4.3 ISSRM concept alignment 101

The relation between the two concepts is clearer in security RM standards. ISO/IEC 27001 and ISO/IEC 27005 relate them together respectively:

Identify the vulnerabilities that might be exploited by the threats. [ISO05b, p. 4]

Vulnerabilities that can be exploited by threats to cause harm to assets or to the organisation should be identified (relates to ISO/IEC 27001, Clause 4.2.1 d) 3)). [ISO08, p. 12]

In NIST 800-27, it is threat source (concept (10)) that is related with vulnerability:

IT-related risk / Risk: The net mission/business impact considering (1) the likelihood that a particular threat source will exploit, or trigger, a particular information system vulnerability and [...] [SHF04, p. A-2]

At last for the security RM standards, in the IT-Grundschutz, vulnerability is de- ned as:

A vulnerability can result in the manifestation of a basic threat [...] [Bun05b, p. 46]

This last denition is quite dierent in terms of existing relationship to the ones already collected: it is the only one not mentioning the exploitation of vulnerabilities by a threat.

Regarding security RM methods, EBIOS relates attack and vulnerability:

Attack: Exploiting one or more vulnerabilities using an attack method with a given opportunity. [DCS04b, p. 11]

In MEHARI [CLU07b], no equivalence to concept (8) has been identied and more- over, no binary relationship between any risk-related concept and vulnerability is found. The same applies for CRAMM [Ins03], in which threat and vulnerability are only linked by their aggregation in the risk concept (cf. Figure A.2).

OCTAVE proposes a denition for vulnerability that reinforces the link mainly identied in security RM standards:

Vulnerability: a weakness in an information system, system security practices and procedures, admin- istrative controls, internal controls, implementation, or physical layout that could be exploited by a threat to gain unauthorized access to information or disrupt processing. There are two basic types of vulnerabilities (organisational and technology). [AD01a, p. 126]

In CORAS, vulnerability is not related to concept (8), but to threat being consid- ered as equivalent to concept (10):

A threat may exploit a vulnerability and cause an unwanted incident. [AD01a, p. 313]

In the last family of sources, RE security frameworks, Firesmith relates through his information models [Fir03] (safety and security) vulnerability with danger/hazard/threat (that are considered as equivalent to concept (10)). They may exploit vulnerability to result in accident/attack. In [MN03], Moett and Nuseibeh provide the same idea:

For each threat, the baseline is analysed in order to identify the vulnerabilities, i.e. the means of exploiting a threat successfully. [MN03, p. 8]

Finally, the link between threats and vulnerabilities in the conceptual model of DITSCAP automation framework is called exploit.

As a conclusion, the nal tendency is that the vulnerability is generally exploited by one of the following concepts: (8), (10) or (11). Iterative reviews of relationships bring up that concept (10) and (11) are in fact aggregated in concept (8) (cf. Figure 4.4). This explains that they can all be related to vulnerability by an exploit relationship, as it is most often the case. Considering this aggregation, the most relevant to us appears to link concept (8) (called threat in Figure 4.4) and vulnerability with an exploit link.

Summary of the relationship elicitation

It is theoretically possible to dene the same kind of alignment table for relationships between concepts, as it has been done for concepts (Section 4.3.3). The denition of such a table should indicate the multiplicities of each relationship. However, a rst try of such a work [Gen07] highlights some limitations. The set of possible relationships between the concepts is huge. As seen in the preceding section, each source has its own point of view of the relationships existing between the concepts. This point is sometimes reinforced by the diculty to interpret natural language. It was already a weakness for concept alignment, but even more for relationship elicitation between concepts. The experience [Gen07] has also shown that the utility of such a table is severely limited, because it is really dicult to read (concept alignment is more explicit than relationship alignment). The multiplicity introduction in such an alignment is complex too. The main problem remains the lack of sucient information available regarding multiplicities. Finally, such a table is not considered as necessary for the denition of relationships. Most of the needed information can be found in the collected denitions, provided in Appendix A. Sometimes, it is necessary to collect some more information (like in Firesmith's information models [Fir03]), but this case remains rare.

In this context, a review of existing relationships has been considered as suited to dene the relationships between the concepts of the ISSRM domain model. The review is done by analysing each source one by one and identifying every relationship existing between the concepts of the source. Based on the denitions of the source, every concept is analysed to see if it is linked (and how) with other concepts. The multiplicities are dened too. This review is done iteratively, for each source of the selected literature (cf. Section 4.2).

4.3.5 Conclusion about concept alignment and relationship identication Regarding the outcome of the identication and the alignment of ISSRM concepts and relationships, this research work provides a bit more formality than the dierent in- formal sources studied. For each source, a conceptual model can now be dened based on the identied concepts and relationships. Figure 4.3 shows an example of such a model for ISO/IEC Guide 73. It represents the dierent concepts involved and relates them by the identied relationships. Appendix C presents the information allowing to dene the relationships between the concepts. Since dening a conceptual model