• Ingen resultater fundet

As mentioned in Sec. 2.1.3, threat modeling is often an integral part of arisk analysis or risk assessments28. Several models and standards exist; this section covers the most reputable ones including those part of international guidelines. Methods for performing a risk analysis is not directly concerned with this thesis, but knowledge of it provides a baseline for understanding the processes the researcher or organization might follow to map the threat landscape and where this thesis’ products eventually will fit in. It can also be used for a reader to select an appropriate risk analysis framework.

2.2.1 A general view: DS/ISO 27000-series

[13, 54] both presents standardized guidelines for a general approach of risk assessment. For standardization frameworks like these, “A single risk model [. . . ] cannot meet the diverse needs of the organizations [. . . ] that rely on [standards]” [54] (i.e. DS/ISO 27000 and NIST 800-30) and thus the standards presents best practices and guides the organizations towards understanding what risks are important to them.

We naturally use the DS/ISO 27000-series here (see also Sec. 2.3.1), as it is a standard directly applicable to Danish organizations by EU-law. [13] lists the following activities of a risk assessment:

28The use of the terms vary and often a risk analysis is only a part of an overall risk assessment.

• Risk identification

• Risk analysis

• Risk evaluation

The risk identification is the activity to identify assets, threats to these, existing controls (procedures or mitigation plans), identification of vulnerabilities and the consequences they may have on the assets (measured against the classic CIA-properties of confidentiality, integrity and availability29, often includes non-repudiation as well).

Therisk analysisactivity details two general types of methodologies [13]:

Qualitative risk analysis “[. . . ]uses a scale [. . . ] to describe the magnitude of potential consequences (e.g. Low, Medium and High) and the likelihood that those consequences will occur.”. This approach can be easier to interpret to all personal, but is dependent on a well-chosen scale. It can be used as an initial screening and where resources or numerical data are insufficient to perform a quantitative analysis.

Quantitative risk analysis “[. . . ]uses a scale with numerical values (rather than descriptive scales [. . . ]) for both consequences and likelihood, using data from a variety of sources.”.

This approach is dependent on both the model to use well-chosen values and that the sources used are complete. If not, the lack of valid data may hide new risks and weaknesses from the results.

It is advised that the chosen methodology aligns with the chosen risk evaluation criteria such that the necessary insight and value is gained in the end. In practice it is often found that the risk analysis models combine both of the above types of methodologies to some extent.

Therisk evaluation is the activity of comparing the risks and their connected values to the risk evaluation criteria established for the organization. Here, risk are prioritized according to the information security properties of the organization (e.g. confidentiality may not be relevant and should thus be ranked lowest or even removed) and the assets’ importance. From this, decisions on mitigation of risks can be made30; this process is further described in [13] (page 20 and onward), but out of scope of this report.

For mature organizations, the risk analysis/risk assessment is an ongoing process, where the analysis is regularly maintained [6, 13, 54].

For context, the risk assessment as described here, is a part of the overall information security risk management process as described in ISO 31000 and shown in Figure 2.4. The take of [54] on the same process is depicted in Figure 2.5, with a close-up of the risk assessment process in itself in Figure 2.6. Despite different wording, the processes are quite identical.

29A short explanation can be found here:

http://whatis.techtarget.com/definition/Confidentiality-Figure 2.4: The full risk management process of ISO 31000 as applied in the DS/ISO 27000-series. From [13].

2.2.2 Specific methodologies

[58] presents a (qualitative) framework for comparing risk analysis models. As examples, they compare OCTAVE (not OCTAVE Allegro, which is a later, revised model of OCTAVE but for all organizational sizes[6]), CORAS [32], ISRAM31, CORA32 andIS Risk Analysis Based on a Business Model by KAIST33.

OCTAVE and CORAS are characterized as qualitative models, while the others are quantitative [58]. They have chosen these, as they are well-documented [58]. I include OCTAVE Allegro too,

integrity-and-availability-CIA(accessed 2017-04-30).

30The mitigation process in [13] is calledrisk treatment. A full wordlist of the DS/ISO 27000-series on information security management systems is found in [14].

31https://www.sciencedirect.com/science/article/pii/S0167404804001890?np=y

32Not very used at all and difficult to find anything about, as the maintaining organization does not exist any longer. Short description here: http://www.blacksheepnetworks.com/security/resources/encyclopedia/

products/prod131.htm.

33http://koasas.kaist.ac.kr/handle/10203/3686

Figure 2.5: The risk management process as depicted in NIST 800-30 [54].

which is a successor to OCTAVE and thus quite similar, but more versatile [6].

In the following we use the criteria used in [58] to describe what differences risk analysis method-ologies have.

In general, but depending on the specific model utilized, the organization identifies their assets and then formulates specific requirements of the security of the organization as a whole (most likely based on current standards). The threat modeling, which will tell something about the probability of attack scenarios on the assets, is combined with theimpact some attack scenario will have on the organization to return arisk score. This is typically done using a risk matrix (see an example in Fig. 2.7), where values (discrete or continuous cf. Sec. 2.2.1) of probability

and impact are assigned to the scenarios for prioritization of the results.

Combined with an assessment of the mitigations in place and the risk acceptance, the organization can then take an informed stance on the threats against them and where to put in an effort to improve the results cf. the above.

It is noteworthy how the identification of assets and subsequently the attack scenarios against them differ from model to model; in [58] this is characterized as“Whether risk analysis is done on single assets or groups of assets”, whilst it does not look on how the attack scenarios themselves are defined, as it is not a property of all the five examples used.

One approach is to perform a pen-test-like scan much like PTES, where tools are used to identify attack scenarios against either pre-defined assets or where an intelligence gathering-phase (as described in Sec. 2.1.2) are to discover them.

This is opposite to “asset/asset container”-driven models like [6, 32], where“[i]nstead of running vulnerability tools and using the results to seed threat identification, in OCTAVE Allegro users map an information asset to all of the containers in which it is stored, transported, or processed and consider threats to each of those containers. There is still a technology view, but it is not impeded by the execution of cumbersome tools that require specialized knowledge and resources.”

[6]. As IT security has become an increasingly complicated field that system owners has to prioritize among many other specialized skills, such models have won popularity, as they are

Figure 2.6: The risk assessment process (part of the risk management process, see Fig. 2.5) as depicted in NIST 800-30 [54].

easier to use and does not demand external consultancy aid.

[58] uses“The main formulae used” to cover this question, as it relates to exactly the “easeness”

of use.

This in turn is connected to the property of interval vs. external aid from the criteria“The people involved in the risk analysis”; All of the mentioned methodologies, except for CORA, are internally focused, which supports the above claim of its popularity.

Within these two extremes, we also see differences in the way the attacker is analyzed. Some models use an approach like PTES, were one try to find all possible attack vectors using prior knowledge, research and automated tools; attack trees as described in Sec. 2.1.3 are an example hereof, where a methodically “top-to-down”-approach is used beginning with the attacker type.

Other models like OCTAVE Allegro [6] and Microsofts framework [34]34 applies an “attacker goal-oriented” approach applied from inside and out. Here, the models asks the user to methodi-cally start by establishing what types of goal an attacker might have against each asset/asset container; this is a great approach for “regular” teams of developers, where security knowledge is not prevalent [51].

The other criteria used in [58] are whether results are comparable across multiple applications of the method (for OCTAVE (Allegro), CORAS and ISRAM they are not) and the amount of preparation done before the actual risk analysis. OCTAVE (Allegro) and ISRAM does a great deal beforehand, CORAS a medium amount, while CORA and IS a minimal amount.

34The acronyms STRIDE and DREAD used for threat classification respectively calculation of the risks (quantitatively) are a part of this.

Figure 2.7: Example of a risk matrix identical to the one used in e.g. CORAS [32]. Taken from https://causalcapital.blogspot.dk/2015/08/making-risk-matrix-useful.html.

For further on this, we refer to [58] directly.