Structured Semantics for the CORAS Security

Risk Modelling Language

Heidi E. I. Dahl1,4, Ida Hogganvik2,3 and Ketil Stølen1,3

1 SINTEF ICT, Oslo, Norway2 Scandpower Risk Management AS, Kjeller, Norway

3 Department of Informatics, UiO, Oslo, Norwayheidi.dahl@sintef.no, iho@scandpower.com, ketil.stolen@sintef.no

Abstract. The CORAS security risk modelling language is a customisedgraphical language for communication, documentation and analysis ofsecurity threat and risk scenarios. This paper presents a semantics for theCORAS language. The semantics is structured in that it provides step-by-step instructions on how to correctly interpret an arbitrary CORASdiagram. The result is a readable paragraph of English. This enablesusers of the CORAS language to easily extract the intended meaning of agiven diagram. The semantics is modular in the sense that the semanticsof any diagram can be deduced from the semantics of its elements andrelations.

1 Introduction

CORAS is a method for security risk analysis [5]. It comes with a specialisedlanguage for communication, documentation and analysis of security threat andrisk scenarios. The language was originally de�ned as a UML [16] pro�le [15, 17],and has later been customised and re�ned in several aspects, based on experi-ences from industrial case studies, and by empirical investigations documentedin [6], [7] and [8].

The CORAS language is in particular intended to support brainstorming ses-sions used to identify and estimate security risks. Such brainstorming sessions arecharacterised by the involvement of people with thorough knowledge of speci�c,but only partly overlapping aspects of the target of analysis. Typical partici-pants are the intended users of the target, its designers, developers, and relevantdecision makers. These people have normally quite di�erent backgrounds and itmay be di�cult for the analysts to make them work well together as a group.Our experiences indicate that the CORAS language improves both the e�ciencyof the analysis process and the quality of the results.

We claim that our graphical approach to security risk modelling contributesto solving three issues related to security analysis:

� How to facilitate communication in a group consisting of people with di�erent

backgrounds and competences: Our aim has been to provide the participants

4 Main author

with a means of communication that covers both technical and more high-level information, without being too complicated to understand. O�ering acommon basis for communication will hopefully reduce misunderstandingsand thereby give a more correct risk picture.

� How to estimate the likelihoods and consequences of identi�ed risks: In prac-tice, reliable data on which this can be based is often not available. Theparticipants must use their expert knowledge, experience and familiaritywith the domain to estimate both the likelihoods and the consequences ofincidents that might not have happened yet. Our aim has been to o�er astructured, graphical risk picture to make the complexity more manageable.A graphical representation may illustrate who or what caused the incidentsand the weaknesses in the system that made them possible.

� How to document the security analysis in a comprehensible manner: The�ndings of a security analysis constitute vital information not only to theparticipants in the analysis, but to the organization as a whole. Our aimhas been to de�ne a documentation method that should be more or lessself-explanatory, and not rely on extensive training to be understood.

Although we have aimed at making a language that is easily understandable,situations are bound to arise where the intended meaning of a construct or anexpression needs further explanation. The main contribution of this paper is thede�nition of a structured semantics aiming to ful�l this need. The semantics takesan arbitrary CORAS diagram and delivers its intended meaning as a readableparagraph of English. It is structured in the sense that it comes with step-by-step instructions allowing the translation to be conducted automatically. Thesemantics has been developed to meet the following success criteria:

1. The translation from CORAS diagrams to English should be modular. If weadd new relations and/or elements to a diagram we have already translated,the translation of the modi�ed diagram is the union of the translation of theoriginal diagram with the translation of the new relations and/or elements.

2. The resulting paragraph should be understandable English. The purpose of thetranslation is to provide a description, in English, of a CORAS diagram, inorder to communicate the meaning of the diagram to those not familiar withthe intended meaning of the various elements and relations of the CORASlanguage.

3. The translation should be easy to perform. Anyone, even someone unac-quainted with CORAS diagrams, should be able to translate a CORASdiagram into English.

4. The translation should be possible to automate. Automatic translation is afeature that will be implemented in the CORAS tool in the future (seehttp://coras.sourceforge.net for downloads and documentation).

5. It should be possible to translate inconsistent diagrams, and the transla-

tion should enable the user to identify inconsistencies. Inconsistent diagramsshould still be possible to translate, and the resulting paragraph in Englishshould be su�ciently clear to allow the user to identify the cause of theinconsistency.

The remainder of the paper is structured into four sections. Sec. 2 introducesthe CORAS language. Sec. 3 provides an overview of the structured semanticsand relevant notation. The semantics is divided into two main steps: the trans-lation from the graphical to the textual syntax, which is described in Sec. 3.1,and the translation from the textual syntax to English, which is described inSec. 3.2. Sec. 4 gives an example of the translation of a diagram. Finally, Sec. 5presents our conclusions and related work.

2 The CORAS Language

The CORAS language originates from a UML pro�le developed as a part ofthe EU funded research project CORAS (IST-2000-25031) [1] (http://coras.sourceforge.net). As a result of our work to satisfy the modelling needs in asecurity risk analysis, the language and its guidelines have evolved into a morespecialized and re�ned approach. The language is meant to support the analystduring the security risk analysis, and serves di�erent purposes in each phaseof the analysis. A security risk analysis is normally structured into �ve phases:(1) context establishment, (2) risk identi�cation, (3) risk estimation, (4) riskevaluation and (5) treatment identi�cation [3].

In the context establishment we employ assets overview diagrams to specifythe parties of the security analysis and their assets. The purpose is to obtain aprecise de�nition of what the valuable aspects of the target of analysis are, andwhich are the most important. From empirical investigations [6] and �eld trialswe know that asset identi�cation and valuation is very di�cult, and that mis-takes or inaccuracies made there may jeopardize the value of the whole securityanalysis.

During risk identi�cation we use threat diagrams to identify and documenthow vulnerabilities may be exploited by threats to initiate unwanted incidents,and which assets they a�ect. The threat diagrams give a clear and easily under-standable overview of the risk picture and make it easier to see who or what thethreat is, how the threat works (threat scenarios) and which vulnerabilities andassets they involve.

The threat diagrams are used as input for the risk estimation phase, whereunwanted incidents are assigned likelihood estimates and possible consequences.The likelihood estimation is often a di�cult task, but illustrating the unwantedincidents in the correct context has proved very helpful in practice.

After the risk estimation, the magnitude of each risk can be calculated on thebasis of its likelihood and consequence, and modelled in risk overview diagrams.The risk overview diagrams specify which threats initiate the di�erent risks, andexactly which assets they may harm. This risk representation is then comparedto prede�ned risk tolerance levels to decide which ones need treatments.

In the treatment identi�cation, the threat diagrams containing the risks thatcannot be tolerated are used as basis for treatment identi�cation. In this phasethe appropriate treatments are identi�ed and modelled in treatment diagrams.

The resulting treatment diagrams can be seen as a plan for how to deal with theidenti�ed risks.

Communicating the results of an analysis in such a way that they are well un-derstood by decision makers can be challenging. The CORAS language supportsthis by o�ering treatment overview diagrams. Treatment overview diagrams mayfor example be used to provide a high level summary when presenting the main�ndings from an analysis.

To summarise, the CORAS language consists of �ve di�erent kinds of dia-grams: assets overview diagrams, threat diagrams, risk overview diagrams, treat-ment diagrams and treatment overview diagrams. Their basic building blocks arepresented in Fig. 1.

Fig. 1. Basic building blocks of the CORAS diagrams

In the rest of the paper, we focus on assets overview diagrams and threatdiagrams. The semantics is de�ned accordingly for risk overview, treatment andtreatment overview diagrams as explained in the full report [4].

2.1 Constructing an Assets Overview Diagram

Fig. 2 presents the syntax of an assets overview diagram.

Fig. 2. Graphical syntax of assets overview diagrams

Assets overview diagrams are used early in the analysis to �x its scope. Therelevant assets are placed in the diagram, and when appropriate connected by

indirect harm relations to indicate that harm to one asset may a�ect another.Parties may be added, and connected to assets with protect relations. A protectrelation may be annotated with a risk level, indicating the level of risk a party iswilling to accept with regards to the asset in question. The di�erent kinds of risklevels is shown in Fig. 2: it is either a risk value which is either a numerical valueor a linguistic term such as �low�/�medium�/�high�, a likelihood and consequence

pair giving the maximal acceptable values, or a risk function of such a pair.Hence, the parties are the customers, institutions or organisations on behalf ofwhom the analysis is carried out. In practice there is often only one party.

To summarise, assets overview diagrams are constructed from two basicbuilding blocks, using two relations:

Basic building blocks: Asset, Party.Relations: Protect (may be annotated with a risk level), Indirect harm.

2.2 Constructing a Threat Diagram

Fig. 3 presents the syntax of a threat diagram.

Fig. 3. Graphical syntax of threat diagrams

When constructing a threat diagram, we start by placing the assets to thefar right, and potential threats to the far left. The construction of the diagramis an iterative process, and we may add more threats later on in the analysis.The assets were �xed when the assets overview diagram was constructed.

Next we place unwanted incidents to the left of the assets. They representevents which may have a negative impact on one or more of the assets. Thisimpact relation is represented by drawing an arrow from the unwanted incidentto the relevant asset, and may be annotated with a consequence value.

The next step consists in determining the di�erent ways a threat may initiatean unwanted incident. We do this by placing threat scenarios, each describinga series of events, between the threats and unwanted incidents and connectingthem all with initiate relations. An initiate relation may originate from eitherthreats, threat scenarios or unwanted incidents, and terminate at threat scenarios

or unwanted incidents, and displays the causal relationship between the elements.In the case where a vulnerability is exploited when passing from one element toanother, the vulnerability is positioned on the arrow between them.

There is also the possibility of an impact relation from a threat scenario to anasset, however this relation is mainly used in the early stages of the analysis andmay not be annotated with a consequence. This has to do with the di�erencebetween unwanted incidents and threat scenarios: unwanted incidents are usedto give a description of single events that may have a consequence for an asset.Threat scenarios are used to describe the sequences of events leading up to anunwanted incident. In the case where a threat scenario has direct consequencesfor an asset, a new unwanted incident should eventually be inserted to expressthis.

At this point, likelihoods may be added to threat scenarios, unwanted inci-dents and initiate relations. The likelihoods of the �rst two are the likelihoodthat they will happen at all. The likelihood of an initiate relation is the likelihoodof the second element, given the �rst.

To summarise, threat diagrams are constructed from seven basic buildingblocks, using two relations:

Basic building blocks: Deliberate, Accidental, and Non-Human Threat,Vulnerability, Threat Scenario, Unwanted Incident, Asset.Relations: Initiate (may be annotated with a likelihood), Impact (mayin some cases be annotated with a consequence).

3 The Structured Semantics

The structured semantics for the CORAS language is divided into two separatesteps:

(A) The translation of a diagram into its textual syntax, and(B) The translation of its textual syntax into its meaning as a paragraph in

English.

Hence, the semantics enables the user of CORAS to extract the meaning of anarbitrary CORAS diagram by applying �rst (A), then (B) (this is written as(B ◦A)).

Both these steps, and therefore the structured semantics, are modular: adiagram is translated relation by relation. Step (A) is described in Sec. 3.1, andStep (B) in Sec. 3.2. In both sections, we make use of the naming conventionsin Table 1. For simplicity we use a (possibly decorated) p to represent a party,and a (possibly decorated) a to represent an asset, etc.

3.1 Step (A): From the Graphical to the Textual Syntax

The textual syntax of the CORAS language is de�ned using a standardisedEBNF notation [11]. For the complete syntax, and translation rules for all the

Element Instance

party p

asset a

deliberate threat dt

accidental threat at

non-human threat nht

vulnerability v = {v}vulnerability set V = {v1, . . . , vn}

Element Instance

threat scenario ts

unwanted incident ui

likelihood l

consequence c

risk r

risk value rv

risk function rf

treatment scenario trs

Table 1. Naming conventions

relations in the CORAS language, see the full report [4]. In this section, weexplain how a diagram is translated from the graphical to the textual syntax,using the assets overview diagram as an example. The other kinds of diagramsare translated accordingly.

The EBNF grammar for the assets overview diagram is the following:

relation = protect | indirect harm;

protect = party[risk level]

· · · asset ;indirect harm = asset −→ asset ;

party = identi�er ;asset = identi�er ;

risk level = risk value | risk function(likelihood , consequence) |(likelihood , consequence);

risk value = linguistic term | numerical value;likelihood = linguistic term | numerical value;

consequence = linguistic term | numerical value;

The EBNF de�nes the structure of the diagram, as it was explained in Sec. 2.The assets overview diagram has two relations which we want to translate: theprotect relation in Fig. 4(a) and the indirect harm relation in Fig. 4(b).

(a) (b)

Fig. 4. Relations of the assets overview diagram

The translation from the graphical to the textual syntax is essentially replac-ing all the icons with their textual label. In the assets overview diagram, this

means that the protect relation in Fig. 4(a) is translated into prl· · · a, and the

indirect harm relation in Fig. 4(b) into a1 −→ a2.The other diagrams are translated in the same manner.

3.2 Step (B): From the Textual Syntax to English

In this step of the structured semantics we apply the semantic function [[_ ]] tothe textual expressions resulting from Step (A), obtaining a sentence in Englishfor each expression. We start by de�ning the semantics for the basic buildingblocks, and these de�nitions are then used to de�ne the semantics for the rela-tions.

The translation rules of the initiate and treat relations involving unwantedincidents are identical to those involving threat scenarios. The rules for theformer can be obtained by replacing ts with ui in the latter.

We simplify accordingly for the three di�erent kinds of threats, specifying therules with dt for direct threat in the semantics of the initiate and treat relations.This can be replaced by either at or nht for accidental and non-human threats.

In the semantics of risks and of the protect relation, we present the ruleswith rv for risk level. This can be replaced by either a risk function rf (l , c) or alikelihood and consequence pair (l , c).

The translation rules of the treat relations does not depend on the treatmentcategory. We therefore present only the rules with av , the rules for the othertreatment categories can be obtained by replacing av with dl , dc, sh or re (seethe semantics of the treatment categories for de�nitions).

Translating the Basic Building Blocks

[[ p ]] := party `p'[[ a ]] := asset `a'

[[ dt ]] := deliberate threat `dt '[[ at ]] := accidental threat `at '

[[nht ]] := non-human threat `nht '[[ v ]] := vulnerability `v '

[[V ]] := vulnerability set `v1 ', . . . , `vn '[[ ts ]] := threat scenario `ts'

[[ ts(l) ]] := threat scenario `ts', which has [[ l ]],[[ ui ]] := unwanted incident `ui '

[[ ui(l) ]] := unwanted incident `ui ', which has [[ l ]],[[ r ]] := risk `r '

[[ r(rv) ]] := risk `r ', which has [[ rv ]],

[[ r(rf (l , c)) ]] := risk `r ', which has [[ rf (l , c) ]],[[ r(l , c) ]] := risk `r ', which has [[ (l , c) ]],

[[ trs ]] := treatment scenario `trs'[[ rv ]] := risk value `rv '

[[ rf (l , c) ]] := risk function `rf ' of [[ (l , c) ]][[ (l , c) ]] := [[ l ]] and [[ c ]]

[[ l ]] := likelihood `l '[[ c ]] := consequence `c'

Translating the Protect relation

[[ prv· · · a ]] := [[ p ]] wants to protect the value of [[ a ]], but accepts [[ rv ]] or less

Translating the Indirect harm relation

[[ a1 −→ a2 ]] := [[ a2 ]] may be harmed indirectly via [[ a1 ]]

Translating the Initiate relation

[[ dt Vn l1−−−→ ts(l2 ) ]] := there is a [[ l1 ]] that [[ dt ]] will exploit [[Vn ]] toinitiate [[ ts(l2 ) ]]

[[ ts1 (l1 ) Vn l3−−−→ ts2 (l2 ) ]] := after [[ ts1 (l1 ) ]] has taken place, there is a [[ l3 ]]that [[Vn ]] will be exploited to initiate [[ ts2 (l2 ) ]]

[[ dt −→ r(rv) ]] := [[ dt ]] may initiate [[ r(rv) ]][[ ts(l) −→ r(rv) ]] := [[ ts(l) ]] may initiate [[ r(rv) ]]

[[ r1 (rv1 ) −→ r2 (rv2 ) ]] := [[ r1 (rv1 ) ]] may initiate [[ r2 (rv2 ) ]]

Translating the Impact relation

[[ ts(l) −→ a ]] := [[ ts(l) ]] may impact [[ a ]]

[[ ui(l) c−→ a ]] := [[ ui(l) ]] may impact [[ a ]] with [[ c ]][[ r(rv) −→ a ]] := [[ r(rv) ]] may impact [[ a ]]

Translating the Treatment categories

[[ av ]] := avoids the risk

[[ dl ]] := reduces the likelihood

[[ dc ]] := reduces the consequences

[[ sh ]] := shares the risk

[[ re ]] := retains the risk

Translating the Treat relation

[[ trs av−→ dt ]] := [[ trs ]] [[ av ]] of [[ dt ]] attacking the system

[[ trs av−→ v ]] := [[ trs ]] [[ av ]] of [[ v ]] being exploited

[[ trs av−→ ts(l) ]] := [[ trs ]] [[ av ]] of [[ ts(l) ]] being initiated

[[ trs av−→ r(rv) ]] := [[ trs ]] [[ av ]] of [[ r(rv) ]]

[[ trs av−→ a ]] := [[ trs ]] [[ av ]] of [[ a ]] being harmed

4 Example Translation

To illustrate how a diagram is translated we will use the threat diagram in Fig. 5

Fig. 5. Threat diagram

The threat diagram is translated relation by relation using the two-stepstrategy outlined above. The resulting sentences have been arranged for bet-ter readability. The diagram has 8 relations: 7 initiate relations (5 annotatedwith vulnerabilities and 2 with likelihoods) and 1 impact relation (annotatedwith a consequence). Translating top to bottom from left to right gives us:

� Accidental threat Employee may exploit vulnerability• Old antivirus to initiate threat scenario Malicious code on com-

puter spreads via LAN, which has likelihood 1 per year.• Physical access to network to initiate threat scenario Malicious

code on computer spreads via LAN, which has likelihood 1 per

year.� After threat scenario Malicious code on computer spreads via LAN,which has likelihood 1 per year, has taken place,• vulnerability set Old �rewall, Old version of webserver may beexploited to initiate threat scenario Servers infected by malicious

code, which has likelihood 1 per 10 years.

• vulnerability Old �rewall may be exploited to initiate threat scenarioMalicious code tra�c jams network, which has likelihood 1 per

year.� After threat scenario Servers infected by malicious code, which haslikelihood 1 per 10 years, has taken place, there is a likelihood 0.5 thatthreat scenario Application servers malfunctioning, which has likeli-hood 1 per 5 years, will be initiated.

� After threat scenario Malicious code tra�c jams network, which haslikelihood 1 per year, has taken place, there is a likelihood 0.1 that threatscenario Application servers malfunctioning, which has likelihood 1

per 5 years, will be initiated.� After threat scenario Application servers malfunctioning, which haslikelihood 1 per 5 years, has taken place, unwanted incident Corruptionof data, which has likelihood 1 per year may be initiated.

� Unwanted incident Corruption of data, which has likelihood 1 per year,may impact asset Data privacy with consequence 2.

We may now check whether the likelihoods of the diagram have been as-signed consistently. If for example the statistically independent threat scenariosts1(l1), . . . , tsn(ln) initiate threat scenario ts(l), and the likelihoods associatedwith the initiate relations are li1, . . . , lin respectively, then the following inequal-ity should be true:

l ≥ l1 · li1 + · · ·+ ln · lin .

This is an equality only when the threat diagram is complete, i.e. when alleventualities are taken into account and all likelihoods given. If the inequality isstrict, it simply means that there are causes of ts(l) that are not accounted for.

In this example, all threat scenarios and unwanted incidents have been as-signed likelihoods, so it is possible to check for inconsistencies with respect tothe initiate relations which have also been assigned likelihoods. The relevanttranslations are:

� After threat scenario Servers infected by malicious code, which haslikelihood 1 per 10 years, has taken place, there is a likelihood 0.5 thatthreat scenario Application servers malfunctioning, which has likeli-hood 1 per 5 years, will be initiated.

� After threat scenario Malicious code tra�c jams network, which haslikelihood 1 per year, has taken place, there is a likelihood 0.1 that threatscenario Application servers malfunctioning, which has likelihood 1

per 5 years, will be initiated.

The �rst implies that the likelihood or frequency of Application servers

malfunctioning being initiated by Servers infected by malicious code is1 per 20 years, and the second that the frequency of Application servers

malfunctioning being initiated by Malicious code tra�c jams network

is 1 per 10 years. This tells us that the frequency of Application servers

malfunctioning should be at least 3 per 20 years if the diagram is to be

consistent, which is ok as the frequency is given as 1 per 5 years or 4 per

20 years. The fact that the two frequencies are not equal tells us that if theassigned frequencies are correct, the diagram is incomplete (but consistent): thereare additional causes for Application servers malfunctioning which are notaccounted for.

5 Conclusion

The CORAS language has been designed to be easily understandable in orderto aid communication in a security risk analysis context. Even so, situationsare bound to arise where there is a need to explain the intended meaning ofa construct or expression. An example of such a situation is when the analysisresults are distributed to parties, within the client company, which have not beenpart of the analysis process.

In order to �ll this need, this paper has presented a structured semantics forthe CORAS security risk modelling language. We have provided instructions onhow to translate the two main CORAS diagrams, via the textual syntax, into aparagraph of English.

The paper satis�es the success criteria stated at the end of Section 1 in thefollowing sense:

1. The translation from CORAS diagrams to English should be modular. Wedivided the translation into two independent steps: (A) Graphical to tex-tual syntax, and (B) Textual syntax to English. Both of these componenttranslations are modular (the diagram and textual expressions are translatedrelation by relation) so the complete translation (B ◦A) is modular.

2. The resulting paragraph should be understandable English. The wording ofthe English phrases in the structured semantics is based on the descriptionsused by CORAS developers to explain the diagrams to non-specialists duringa CORAS security risk analysis. This gives us a translation into phrases ofclear understandable English.

3. The translation should be easy to perform. The translation of a diagram isdone by pattern matching, �rst by matching each relation to a translationrule and removing unwanted optional elements, then by matching the result-ing textual expression to a rule in the structured semantics.

4. The translation should be possible to automate. The translation rules and thestructured semantics are presented in such a way that the pattern matchingmay be done automatically. However, the structuring of the translation de-pends to a large degree on the structure of the original diagram. Thus it isdi�cult to give a general recommendation on how this is done. This meansthat while it is possible to automatically structure the translation to re�ectthe branching nature of the CORAS diagrams, a more comprehensive struc-turing may require human intervention unless the structure of the diagramadheres to a prede�ned style.

5. It should be possible to translate inconsistent diagrams, and the translation

should enable the user to identify inconsistencies. As a CORAS diagramis translated relation by relation and not from a more global perspective, itdoes not matter to the translation whether or not the diagram is inconsistent.However, the inconsistencies may not be conspicuous before the translationis appropriately structured.

Related Work

Misuse cases [2, 19, 20] was an important source of inspiration in the developmentof the UML pro�le mentioned in Sec. 2. A misuse case is a kind of UML use case[12] which characterizes functionality that the system should not allow. Thereare a number of security oriented extensions of UML, e.g. UMLSec [13] andSecureUML [14]. These and related approaches have however all been designedto capture security properties and security aspects at a more detailed level thanour language. Moreover, their focus is not on brainstorming sessions as in ourcase. Fault tree is a tree-notation used in fault tree analysis (FTA) [10]. Thetop node represents an unwanted incident, or failure, and the di�erent eventsthat may lead to the top event are modelled as branches of nodes, with the leafnode as the causing event. Our threat diagrams often look a bit like fault trees,but may have more than one top node. Event tree analysis (ETA) [9] focuses onillustrating the consequences of an event and the probabilities of these. Eventtrees can to a large extent also be simulated in our notation. Attack trees [18] aimto provide a formal and methodical way of describing the security of a systembased on the attacks it may be exposed to. The notation uses a tree structuresimilar to fault trees, with the attack goal as the top node and di�erent ways ofachieving the goal as leaf nodes. Our approach supports this way of modelling,but facilitates in addition the speci�cation of the attack initiators (threats) andthe harm caused by the attack (damage to assets).

Further Work

The work presented in this paper is the starting point for several research activ-ities. The most immediate would be empirical testing of the translation processand the resulting sentences. The CORAS tool will be updated to re�ect thestructure of the textual syntax and facilitate automatic translation.

The development of the CORAS method and language continues in severalprojects at SINTEF ICT, building on experiences from industrial case studies.There is also ongoing work aiming for an integrated approach to security andusability analysis.

Acknowledgements

The research for this paper has been funded by the SECURIS (152839/220) andDIGIT (180052/S10) projects of the Research Council of Norway, and the EU-project S3MS (IST-2006-027004). The authors thank Iselin Engan, Mass SoldalLund and Atle Refsdal for valuable input.

References

[1] Jan Øyvind Aagedal, Folker den Braber, Theo Dimitrakos, Bjørn Axel Gran, Dim-itris Raptis, and Ketil Stølen. Model-based risk assessment to improve enterprisesecurity. In EDOC'02, pages 51�64. IEEE Computer Society, 2002.

[2] Ian F. Alexander. Misuse cases: Use cases with hostile intent. IEEE Software,20(1):58�66, 2003.

[3] AS/NZS 4360:2004. Australian/New Zealand Standard for Risk Management,2004.

[4] Heidi E. I. Dahl, Ida Hogganvik, and Ketil Stølen. Structured semantics for theCORAS security risk modelling language. Technical Report A970, SINTEF ICT,2007.

[5] Folker den Braber, Ida Hogganvik, Mass Soldal Lund, Ketil Stølen, and FredrikVraalsen. Model-based security analysis in seven steps � a guided tour to theCORAS method. BT Technology Journal, 25(1):101�117, 2007.

[6] Ida Hogganvik and Ketil Stølen. On the comprehension of security risk scenarios.In IWPC'05, pages 115�124. IEEE Computer Society, 2005.

[7] Ida Hogganvik and Ketil Stølen. Risk Analysis Terminology for IT systems: Doesit match Intuition? In ISESE'05, pages 13�23. IEEE Computer Society, 2005.

[8] Ida Hogganvik and Ketil Stølen. A Graphical Approach to Risk Identi�cation,Motivated by Empirical Investigations. In MoDELS'06, volume 4199 of LNCS,pages 574�588. Springer, 2006.

[9] IEC60300. Event Tree Analysis in Dependability management � Part 3: Applica-tion guide � Section 9: Risk analysis of technological systems. 1995.

[10] IEC61025. Fault Tree Analysis (FTA). 1990.[11] ISO/IEC 14977:1996(E). Information technology � Syntactic metalanguage �

Extended BNF, �rst edition, 1996.[12] Ivar Jacobson, Magnus Christenson, Patrik Jonsson, and Gunnar Övergaard.

Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley, 1992.

[13] Jan Jürjens. Secure Systems Development with UML. Springer, 2005.[14] Torsten Lodderstedt, David A. Basin, and Jürgen Doser. SecureUML: A UML-

based modeling language for model-driven security. In UML'02, volume 2460 ofLNCS, pages 426�441. Springer, 2002.

[15] Mass Soldal Lund, Ida Hogganvik, Seehusen Fredrik, and Ketil Stølen. UMLpro�le for security assessment. Technical Report STF40 A03066, SINTEF ICT,2003.

[16] OMG. Uni�ed Modeling Language Speci�cation, version 2.0, 2004.[17] OMG. UML Pro�le for Modeling Quality of Service and Fault Tolerance Charac-

teristics and Mechanisms, 2005.[18] Bruce Schneier. Attack trees: Modeling security threats. Dr. Dobb's Journal of

Software Tools, 24(12):21�29, December 1999.[19] Guttorm Sindre and Andreas L. Opdahl. Eliciting security requirements with

misuse cases. In TOOLS-PACIFIC'00, pages 120�131, 2000.[20] Guttorm Sindre and Andreas L. Opdahl. Templates for misuse case description.

In REFSQ'01, pages 125�136, 2001.