Syntactic and Semantic Extensions to Secure Tropos to Support Security Risk Management

: The need to consider security from the early stages of the development process of information systems has been argued by academics and industrialists alike, and security risk management has been recognised as one of the most prominent techniques for eliciting security requirements. However, although existing security modelling languages provide some means to model security aspects, they do not contain concrete constructs to address vulnerable system assets, their risks, and risk treatments. Furthermore, security languages do not provide a crosscutting viewpoint relating all three – assets, risks and risk treatments – together. This is problematic since, for a security analyst, it is diﬃcult to detect what the potential security ﬂaws could be, and how they need to be ﬁxed. In this paper, we extend the Secure Tropos language, an agent-and goal-oriented security modelling language to support modelling of security risks. Based on previous work, where we had observed some inadequacies of this language to model security risks, this paper suggests improvements of Secure Tropos semantics and syntax. On the syntax level we extend the concrete and abstract syntax of the language, so that it covers the security risk management domain. On the semantic level, we illustrate how language constructs need to be improved to address the three different levels of security risk management. The suggested improvements are illustrated with the aid of a running example, called eSAP, from the healthcare domain.


Introduction
Information systems (IS) undoubtedly play an important role in todays society and more and more are at the heart of critical infrastructures.As such, developers of IS face an increasing complexity because of issues such as interoperability with other systems and IS's operation in open, distributed and mobile environments.In such context, the need to secure IS and the information stored in them is vital.Security risk management activities are considered as central by IS professionals towards the development of secure IS.These activities do not only support information system developers in the handling of security vulnerabilities but they also provide a framework in terms of which the return on investment of the security solutions is evaluated against the economic and business consequences of not implementing them.Therefore, the motivation of our work comes from the need to facilitate a framework to support IS developers to identify security risks and develop appropriate security requirements.
A central focus of IS development is to consider security issues from the very early phases, a.k.a.Requirements Engineering (RE).The associated scientific literature features a number of modelling languages specifically dedicated to security sensitive contexts.However, although existing security modelling languages provide some means to model security aspects, they do not contain concrete constructs to address vulnerable system assets, their risks, and risk treatments.Furthermore, security languages do not provide a crosscutting viewpoint relating all three -assets, risks and risk treatments -together.This is problematic since, for a security analyst, it is difficult to detect what the potential security flaws could be, and how they need to be fixed.This situation advocates for the design of yet another modelling language.However, defining a complete new notation does not appear to us as viable option from a sustainability perspective for the modelling community.As demonstrated for example with UML in software engineering, a consensus over unified and common notations has been proved to be a big push for the adoption of modelling practices in public and private companies.At RE level we plead for a similar approach and rather than the development of a totally new language we improve existing languages, offering an ontological basis sufficiently closed to the risk management domain.
With respect to the above objective, we have identified Secure Tropos [30],which uses the concept of security constraint and methods such as security attack scenarios to analyse security requirements, as a suitable candidate language.The selection of Secure Tropos results from a detailed analysis [24] of the adequacy of its concepts to the Information System Security Risk Management (ISSRM) domain model [26] [25].In this paper, based on our previous work [24], we extend the Secure Tropos language to support modelling of security risks.In particular, this paper suggests improvements of Secure Tropos's semantics and syntax.On the syntax level we extend the concrete and abstract syntax of the language, so that it covers the security risk management domain.On the semantic level, we illustrate how language constructs need to be improved to address the three different levels of security risk management.
This paper is structured as follows.Section 2 describes the ISSRM domain model and process.Section 3 describes the Secure Tropos language and it discusses how the current version of the language is suitable for ISSRM.Section 4 presents our extensions to the Secure Tropos language and Section 5 discusses our results; presents areas for future work and it concludes the paper.It is worth noting that a running example from the health and social care domain is employed throughout the paper to demonstrate the applicability and improve understanding of our work.

Information System Security Risk Management (ISSRM)
The main objective of ISSRM [26] [23] [24] is defined as the protection of essential IS constituents against all harm to information security.The domain model (see Fig. 1) is defined after careful survey [25] [26] of the risk management standards [18] [5], security-related standards [1] [16], security risk management methods [2] [48] [15] and software engineering frameworks [14] [12].It is important to note that security risk management is a specification of risk management in general, leading to conceptual and semantic differences between the two domains.For example, the standard definition of a risk (in general) coming from ISO Guide 73 [18] and the one of a security risk defined in ISO/IEC 27000 [17] are different and involve different components, the main difference being the absence of the vulnerability concept in a risk in general.The domain model is structured around three groups of concepts: asset-related concepts, risk-related concepts and risk treatment-related concepts.In this section, we briefly discuss these concepts (see [26] for more details).
Asset-related concepts describe the elements that need to be protected within the organisation and the criteria that guarantee security of these elements.Assets are things that have value to the organisation and that need to be protected (e.g., medical reimbursement process, operating systems, people encoding data).Assets are structured to business assets and IS assets.Business assets are assets related to the organisation in terms of its business model and are necessary for achieving its objectives (e.g., information, process, capabilities, employees' skills).IS assets are component or part of the IS supporting business assets (e.g., laptop computer, system administrator).Security criterion is a property or constraint on business assets characterising their needs for security.It is expressed in terms of confidentiality, integrity, and availability (examples of security criteria applied on business assets are confidentiality of the list of names, integrity of the medical reimbursement process).Risk-related concepts present how risk itself is Figure 1: The ISSRM domain model [26] [23] [24] defined.A risk is the combination of a threat with one or more vulnerabilities leading to negative impacts harming one or more of the assets.Example of a risk is a cracker using social engineering on a member of the organisation, because of weak awareness of the staff, leading to non-authorised access on personal computers and loss of confidentiality and integrity of sensitive information.A threat and a vulnerability are composing a security event (e.g., a cracker using social engineering because of lack of awareness).A threat (e.g., a cracker using social engineering) is the potential attack targeting IS assets that may lead to harm.A vulnerability (e.g., weak awareness) is a characteristic of an IS asset that can constitute a weakness or a flaw in terms of security.A threat is composed of a threat agent and an attack method .A threat agent is an agent that can potentially cause harm to assets of the IS (e.g., a cracker with considerable technical ability).An attack method is a standard means by which a threat agent carries out a threat (e.g., system intrusion).Impact is also a component of risk.It is the potential negative consequence of a risk that may harm assets of a system when a threat is accomplished (e.g., password discovery, loss of names confidentiality).Risk treatment-related concepts are the decisions, requirements and controls defined and implemented to mitigate the risks.A risk treatment is the treatment decision for a risk.It can include risk reduction (e.g., take measurements to avoid network intrusions), risk avoidance (e.g., do not connect IS to the Internet), risk transfer (e.g., take an insurance for covering the loss of service), and risk retention (e.g., accept that the service could be unavailable for one hour) decisions.Based on the taken decision, security requirements are defined to mitigate the risks (e.g., back-up copies of information and software shall be taken and tested regularly in accordance with the agreed backup policy).Generally, risk reduction decision leads to security requirements.Risk transfer decision needs also some security requirements about third parties.Avoiding risk and retaining risk do not need any additional security requirement.Finally, controls are the implementation of security requirements (e.g., backup procedure, building guard).
The ISSRM process consists of six steps [25] [23] [24].The process begins with (a) a study of the organisation's context and the identification of its assets.In this step, the organisation and its environment are described, and an overview of the IS, when already in place, is made.Then, based on the level of protection required for the assets, one needs to determine the (b) security objectives.Security objectives are defined in terms of confidentiality, integrity and availability of the assets.The main step of the process is (c) risk analysis, that elicits which risks are harming assets and threatening security objectives.It consists of identifying risks and estimating their level in a qualitative or quantitative manner.We speak about risk assessment [18] only after the level of analysed risks is evaluated against the security needs, which are determined during step (b) of the process.This risk has an estimated level high enough to be considered.It could be necessary at this step to fully review the context and assets identification, if the risk assessment is considered as unsatisfactory.Once risk assessment is performed, decisions about (d) risk treatment are taken, like reducing the risk with some controls or transferring the risk to a third party.Security requirements on the IS can thus be determined as security solutions to mitigate the risks (step (e)).At the end of the risk treatment step, followed by the security requirements definition, if they are considered as unsatisfactory, the risk treatment step can be revised, or all of the preceding steps can be revised from the definition of the context and the assets.Requirements are finally instantiated into (f ) security controls, i.e. system specific countermeasures, that are implemented within the organisation.
The ISSRM process is iterative.Several iterations need to be performed, until reaching an acceptable level for all risks.Even after reaching an acceptable level for all risks, the ISSRM process should be monitored and regularly reviewed.Risks are obviously not static and should be monitored either automatically or manually by the risk analyst in an organisation.Each modification in the organisation's business, in its context and/or in its IS can produce modifications on risks and its different levels.In an ideal way, the ISSRM process should in fact be continuously performed, in order to keep the organisation's business and its associated security needs aligned with the measures taken and the ensuing security level.

Secure Tropos
In this section, we present a summary of Secure Tropos.We also analyse how the current version of the language is suitable for ISSRM.

Secure Tropos for IS Modelling
Tropos [6] supports development of IS through four phases: early and late requirements, architectural and detailed design.Early requirements analysis aims at defining and understanding a problem by studying its existing organisational setting.Late requirements analysis defines the system-to-be in the context of its operational environment.Architectural design deals with the definition of the system global architecture in terms of subsystems.Detailed design specifies each architectural component in terms of inputs, outputs, control and other relevant information.In this paper, we particularly focus on the early stages of the IS development.This means we will consider how Secure Tropos is applied during early and late requirements analysis.
Secure Tropos [32] [36] is based on the Tropos methodology [6] with the scope to address IS security during its development.The key points of the methodology are: (i ) social issues of security are analysed during the early requirements stage; (ii ) security is considered simultaneously with the other requirements of the system-to-be; (iii ) although introduced incrementally during the requirements phases, security is addressed in depth during the system design phases.
Secure Tropos supports the analysis of security considerations during an information systems development based on a number of models.The security enhanced actor model (SEAM)identifies and analyses actors of the environment, actors of the system and dependency relationships between them.Here, an actor describes an entity that has strategic goals and intentions within the system or within the organisational setting [6].In order to deal with the security issues, security constraints are introduced.A security constraint represents a restriction related to security that the system must have and actors must respect [32] [38].
A Dependency relationship between two actors indicates that one actor (the depender) depends for some reason (dependum) on another actor (the dependee) [6].Secure dependency, introduces security constraint(s) that must be respected by actors for the dependency to be satisfied [36].This means that the depender expects from the dependee to satisfy the security constraint(s) and also that the dependee will make an effort to deliver the dependum by satisfying the security constraint(s) [38].The security enhanced goal model (SEGM), allows a deeper understanding of how the actors reason about goals to be fulfilled, plans to be performed and availability of resources [6].It completes the security enhanced actor model with the reasoning that each actor makes about its internal goals, plans and resources.A hardgoal hereafter, represents an actor's strategic interest.A softgoal, unlike a goal, does not have clear criteria for deciding whether it is satisfied or not and, therefore, it is subject to interpretation (goals are said to be satisfied while softgoals are said to be satisficed ).A plan represents a way of doing things.A resource represents an informational or physical entity.In the security enhanced goal model, elements are linked by the means-ends, decomposition and contribution relationships.
To facilitate security analysis, Secure Tropos introduces the concept of secure goal (and task) [32].A secure goal represents the strategic interest of an actor with respect to security.Secure goals are mainly introduced to achieve possible security constraints that are imposed to an actor or exist in the system.How secure goals are achieved is described by a secure task.A Security reference diagram assists the identification of security requirements [32].In this type of diagram, a threat represents circumstances that have the potential to cause loss or problems, which can put in danger the security features of the system.On the other hand, an actual attack is defined with the aid of a security attack scenario [32].Here, developers can identify the goals of the possible attacker and through these identify a set of possible attacks to the system.The attacks relationship shows what is the target of an attacker's plan.

Research Method
The main objective of this paper is to investigate how we can improve Secure Tropos [32] in order to support management of IS security risk at the early stages of the IS development.To reach this objective, we follow the research method presented in Fig. 2. First, we investigate the situation AS-IS.This means we need to understand how the current version of the language can be used to deal with ISSRM.We have reported this analysis in [24] and present major findings in Table 1 and section 3.3.
Next step is to deal with the observed limitations of the Secure Tropos support for ISSRM and to define the situation TO-BE.This means we need to understand how it is possible to improve the language that it would sufficiently support the ISSRM concepts and the risk management process.In Section 4, we introduce extensions to Secure Tropos.
The study of Secure Tropos is done at the different levels of the modelling language.We analyse abstract syntax of the language by extending the current meta-model of Secure Tropos with concepts to address ISSRM.Based on this, we extend concrete syntax, thus, allowing modeller to represent asset, risk and risk treatment models.Finally, at the semantic level, we align Secure Tropos constructs with the ISSRM concepts, thus providing the semantical and methodological hints of language application.[36] in order to understand its major principles and concepts.Next, we have applied Secure Tropos in the running example -eSAP [30].This application was strongly followed by the process guidance and the concepts suggested by the ISSRM domain model [25] [23] [24] [26].We have resulted in the semantic alignment between ISSRM and Secure Tropos as illustrated in Table 1.This table shows how (and if) Secure Tropos can be aligned with the principles of ISSRM.The first two columns list the concepts of the ISSRM domain model, the third column provides synonyms of the ISSRM concepts found in the Secure Tropos literature [32] [35] [39] [38] [36].The fourth column lists the Secure Tropos constructs used to address the ISSRM concepts.
Our alignment of Secure Tropos constructs with the concepts of the ISSRM domain model has shown several limitations of Secure Tropos, to investigate security risk management at the early stages (requirements) of the IS development.At the same time, it suggests a number of possible improvements for Secure Tropos, in the context of security risk management.We have noticed that Secure Tropos could be improved with additional constructs to better cover the concepts of ISSRM.Table 1 indicates that several concepts such as risk and risk treatment are not in the Secure Tropos approach.Thus, one needs either to define graphical constructs to address these concepts, or to provide methodological guidelines how these concepts might be addressed in the model.
Our analysis showed that Secure Tropos has to provide guidelines as to when and how to use each constructs, in order to avoid misinterpretations of the ISSRM concepts.For example, as shown in Table 1, the plan construct can be used to model business assets, IS assets, threats and security requirements.One security requirements).Another solution is to design a discriminating concrete syntax, which would allow to separate these concerns.Finally, decomposition of the model into separate diagrams, where separate concerns (business assets, IS assets, attack scenario and security requirements) would be modelled, should be considered.The latter two aspects we develop in Section 4.
Finally, the semantics of individual modelling constructs should be adapted so that they adequately represent ISSRM concepts.For example, the belief construct only partially covers vulnerability.A possible improvement, on the one hand, is to suggest the modelling construct which would adequately support modelling of system vulnerabilities.On the other hand, recently in [10], Elahi and Yu have introduced vulnerable points.We will investigate the latter option in Section 4.

A Risk-aware Secure Tropos
The purpose of this section is to develop syntactic, semantic and methodological extensions to Secure Tropos, that would support modelling security risks and their countermeasures.First, we suggest extensions to the concrete syntax and show how they are addressed in the abstract syntax.Next, we define methodological guidelines to use Secure Tropos for security risk management.

Concrete Syntax
In Section 3 (Table 1), we have separated concrete syntax of Secure Tropos according to three construct categories: asset-related concepts (Fig. 3), riskrelated concepts (Fig. 4 and 5), and risk treatment-related concepts (Fig. 6).In addition to the ISSRM constructs aligned in Table 1, here in Fig. 3, 4, 5 and 6, we consider how ISSRM relationships (e.g., supports, constraint of, exploits, targets, mitigates, and others) can be expressed with Secure Tropos.We also make a link between Secure Tropos concrete and abstract syntax, which is considered in Section 4.2.

Asset-related concepts.
The ISSRM assets (see Fig. 3) are modelled using actor, hardgoal, plan, resource, softgoal constructs and their compositions constructed using dependency, meansends, contribution, and decomposition relations.Moreover, ISSRM supports relationship, between IS and business assets, is expressed using the different Secure Tropos relationships.The ISSRM security criterion is represented through softgoal and/or security constraint.Softgoal represents generally high-level security criteria and security constraint their refinement.Note that in Secure Tropos, one security constraint can be decomposed to others, thus, forming a security constraint hierarchy.The ISSRM relationship constraint of is addressed both implicitly and explicitly in Secure Tropos.Firstly, in the Secure Tropos actor model, we can observe an implicit restriction of the dependum (hardgoal, task or resource) in the dependency relationship.This means that security constraint is imposed to the depender or/and dependee actor.Secondly, in the Secure Tropos SEGM, the ISSRM constraint of relationship is presented explicitly by the restricts relationship.It shows the actual goal, plan or resource restricted by the security constraint.

Risk-related concepts.
As presented in Table 1, standard Secure Tropos constructs can be used to model risk-related concerns.However, there exists a high degree of misinterpreting the presented information.Thus, we recommend to differentiate concrete syntax of these Secure Tropos concepts.Liu Et.Al [21], use black shadows to represent malicious language constructs.Elsewhere, Sindre and Opdahl [45], model malicious information using contrasting construct colours (e.g., white vs. black).For Secure Tropos, we suggest to use more solid (darker) colours applied for the construct background (see Fig. 4).We represent threat agent as an actor, attack method as a plan, threat as a hardgoal and/or plan.As proposed in Section 3.3, vulnerability point is introduced to represent a vulnerability.This extension coming from Elahi and Yu [10] is more aligned with vulnerability of ISSRM than the existing Belief.Secure Tropos attacks relationship represents the targets relationship of ISSRM.In order to be compliant with ISSRM, we also introduce the exploits relationship, which defines a link between a plan (ISSRM threat) and an asset with a vulnerability point.
After defining how we can represent threat agent, attack method, and vulnerability, we can combine these concepts to represent the event of the risk (see Fig. 5).To generalise this representation, one can use the Secure Tropos threat con-structs.The former representation of the risk event is used in the security attack scenario, in order to represent details of the event.The latter representation is used in the security reference diagram, to identify risks to assets.Here, a risk is understood as the combination of the risk event (represented as the Secure Tropos threat) and impact (represented using the impacts relationship).For the necessity of differentiating ISSRM concepts, we also need to update the visual syntax of risk treatment-related concepts.Constructs, like actor, hardgoal, plan, softgoal, and security constraint (and/or their combinations), which represent security requirements and/or controls, need to carry a dotted background pattern (see Fig. 6).Security requirement mitigates the identified risk.To represent this, we introduce mitigates relationship, defining a link between constructs representing the ISSRM security requirement concept and the threat (as the ISSRM event of the risk).

Abstract Syntax
In Section 3, we have not presented abstract syntax of Secure Tropos due to the need of the simple introduction of the language itself.However, to illustrate how Due to the need of reducing presentation complexity, in addition to these two meta-models, we will discuss abstract relationships of the security constraint and attack scenario diagram separately.

The Security Enhanced Actor Model.
Fig. 7 presents the SEAM abstract syntax.The major element is an Actor who might be a depender or dependee in a Dependency relationship [6] [49].A Security Constraint is imposed to an Actor, that represents a restriction on the Hardgoal(s), Plan(s) and/or Resource(s) on an Actor related to security issues [32].A Security Constraint enhances the language by defining the notion of Secure Dependency.
A Secure Dependency introduces one or more Security Constraint(s) that must be fulfilled for the dependency to be valid [32].We distinguish among three types of secure dependencies: dependee secure dependency, depender secure dependency, and double secure dependency.Different Secure Dependency types are defined using Depender and Dependee attributes of Security Constraint.Dependee secure dependency is represented when Dependee SC is defined (Security Con-  As already illustrated in the SEAM meta-model, Security constraint is imposed to Actor.It Restricts (see Fig. 9) execution of Plans, availability of Resources and achievement of Hardgoals held by this Actor.One analyses Security Constraints using a number of modelling techniques, such as security constraint decomposition; security constraint delegation and security constraint assignment [30].A secure goal represents the strategic interest of an Actor with respect to security.Constraints by defining Satisfies relationship (see Fig. 9).A secure plan is defined as a Plan (by managing isSecure attribute) that represents a particular way for satisfying a secure goal.On the other hand, a secure resource is defined as an entity that is security critical for the system under development.As discussed above, Security Constraint is one of the major elements which defines security concerns in the model; thus, it requires a special attention (see Fig. 9).Security Constraint has a number of relationships with other constraints of the language.Security Constraint can Restrict Plan, Resource and Hardgoal.The visual representation for Restrict is used in the SEGM model, however its implicit meaning is contained already in the SEAM model because Security Constraint places restrictions on the Secure Dependency fulfillment.

Security Attack Scenarios.
Fig. 10 presents the abstract syntax of Secure Tropos used when defining the security attack scenarios.Here we have to note that, in security attack scenarios, two conceptually different sets of constructs are used: asset-and risk-related constructs to address the corresponding ISSRM concepts.Thus, they both obey the same syntax rules (presented in Fig. 7 and 8) when combined within this conceptual boundary.The difficulty arise when one wants to show relationship between them both.We need to distinguish system actors (assets) from malicious actors (attakers).First, we introduce an attribute attacker to the class Actor, as shown in Fig. 10.Next, we define an integrity constraint, saying that Actor A who executes a Plan exploiting/attacking other elements in the diagram, and Actor B who holds exploited/attacked elements, are different.Finally, for actor A, we set an attribute attacker true, meaning a malicious actor (graphical representation is provided in Fig. 4).Actor B's attribute is set as false, meaning that this actor represents attacked assets (graphical representation in Fig. 3).
Two relationships are defined between elements held by these two actors.A Plan executed by an attacker Exploits a target (Hardgoal, Resource, or Plan).
Exploits relationship points to the vulnerability point (see attribute vulnerabil-ityPoint) of the target.The Attacks relationship shows a link between a Plan executed by a malicious actor and the Resource used by an attacked actor.
In the next subsection, we will provide methodological guidelines for the Risk-aware Secure Tropos application.We will use the eSAP example, already introduced in Section 3.

Application of Risk-aware Secure Tropos
The objective of this section is to demonstrate how concrete and abstract syntax extensions are used in an example.Here, we will use the eSAP example [30] again and incrementally provide guidelines for modelling with Risk-aware Secure Tropos.
Language application includes three major stages.The first stage covers the two first steps of the ISSRM process, presented in Section 2: context and asset identification and determination of security objectives.The second stage comprises risk analysis and assessment.Finally, the third stage corresponds to security requirements definition, coming from risk treatment decisions, and leading to new controls.At this stage, concrete syntax of Secure Tropos does not differ from the standard one presented in [35] [34] [40] [31] [39] and used in Section 3.However, as we discussed in Section 3, here we need to make a separation between two ISSRM concepts, namely business assets and IS assets.We do this separation by constructing two diagrams: one presenting business assets (Fig. 11), another introducing IS assets (Fig. 12).In the first diagram shown in Fig. 11, there is no information about how the eSAP system supports different processes or information (i.e.how it supports the business assets).Here, we represent only goals (e.g., Care information collected), plans (e.g., Collect info about treatment) and resources (e.g., Patient personal information) related to business artefacts and activities.
Following the steps of the risk management process, we need to define security objectives.In Secure Tropos, it is possible to identify general security objectives using softgoals (e.g., Privacy in Fig. 11) and then to refine them using security criteria expressed with security constraints (e.g., Keep system data privacy and Share info only if consent obtained).This strategy is a 'top-down' security objectives identification.However, in Secure Tropos, after defining actor model, it is more natural to define implicit security objectives as the secure dependencies.Then, identified security constraints (e.g., Share info only if consent obtained) are examined with respect to security objectives of higher level (e.g., Keep system data privacy and Privacy) for the system.This strategy we name as 'bottom-up'.
Then, the IS assets are represented in a diagram, shown in Fig. 12.Here, the main objective is to discover what plans have to be performed, resources should be available, and goals need to be fulfilled, in order to support business assets.Satisfying security constraints is performed through secure goals, which are considered as IS assets.In Fig. 12, Share info only if consent obtained is satisfied if the goal Consent has been obtained is fulfilled.The plan Perform authorisation checks satisfies the security goal System privacy ensured, thus, contributing to the support of business assets through guaranteeing security constraints.In Fig. 12, business assets and IS assets are mixed, because we need to represent how IS assets support business assets.At the second stage, we introduce possible risks to the eSAP system.We start by determining the security events.Fig. 13 focuses on a possible event of the risk to which eSAP could be exposed, called Authentication attack.It describes a situation where a threat agent passes himself off as a trusted actor in order to fake identity and to damage the Patient personal information in the Information database.The Authentication attack impacts Privacy.The traceability between Privacy and Patient personal information shows the harm at the business level (Fig. 11).However, in this situation Privacy can be interpreted twofold.Firstly, it can represent an asset, which is important to an organisation.Then, the impacts link represents a harm the risk makes.Secondly, Privacy could be considered as a security criterion, which needs to be respected.In this case, impact defines negation of the security criterion.
After identifying the possible risk, we need to refine it in terms of threat, vulnerability, threat agent and attack method.This is done in the security attack scenario in Fig. 14.Here, an Attacker has a threat (Collect info about breaking the system) to an IS asset Information database, which supports business asset Patient personal information.Attacker attacks Information database through exploiting the vulnerability identified in Perform authorisation check.Thus, the exploits link   In order to mitigate the identified risk about an Authentication attack, in our example, we have chosen a risk reduction decision.This means we have to design goals and plans that mitigate the risk.In this example, we substitute plans Perform authorisation check and Check authentication (see Fig. 12) with plan Perform cryptographic procedures decomposed in Encrypt data and Decrypt data (see Fig. 15).Note that new plans have a dotted background pattern, thus, identifying that they represent security requirements in this diagram.In this situation, the Keep system data privacy also becomes a security requirement mitigating the risk.
As discussed in Section 2, ISSRM process is iterative.After definition of security requirements, one needs to test the system again against new possible risk events.For example, modeller can now identify Cryptographic attack.This means that the modeller will need to analyse new vulnerabilities and define new countermeasure.The first iteration activity is to assume new security requirements become controls, and are, therefore, part of IS.This means that plans Perform cryptographic procedures, Encrypt data, and Decrypt data should become IS assets, so removing their pattern in the diagram.A risk analysis and assessment can be performed again.We will evaluate our proposal according to the principle of semiotic clarity proposed by Opdahl and Henderson-Sellers and Moody [43] [29].According to this principle, there should be a one-to-one correspondence between a visual language construct and its referent concept.Otherwise we need to speak about language redundancy, overload, incompleteness (deficit), and under-definition (excess) problems.

Redundancy
means that two language constructs have the same or overlapping semantics.Redundancy problems with respect to ISSRM were identified in Secure Tropos.Firstly, in Risk-aware Secure Tropos, we have decreased redundancy level by introducing different visual constructs to model asset-, risk-, and risk treatmentrelated concepts.Secondly, it might seen that, within the conceptual groups, there is still a high degree of redundancy.For example, an ISSRM asset can be expressed using almost all concepts of Risk-aware Secure Tropos (e.g., Actor, Hardgoal, Softgoal, Plan, Resource).However, we do not see it as a limitation, but rather the opposite.When following the ISSRM asset definition, we need to have means to express information (by Resource), process (by Plan) and different organisational objectives (by different types of a Goal).Similar needs can be observed within other two conceptual groups.
An ISSRM security criterion can be represented either by Softgoal or by Security constraint.This correspondence is not used for the same modelling purpose.We represent abstract security criterion (e.g., confidentiality, integrity, and availability) using Softgoals and more concrete security criterion using Security constraints.
As mentioned previously, the concept of event is represented by Threat in the security reference diagram and by a set of constructs (e.g., goals, plans, actors, etc.) in the security attack scenario.Hopefully, this separation of concepts to different levels of abstraction gives better model analysis possibilities, and facilitates the user to catch the information provided in the diagrams [28].However, this needs to be validated in empirical settings.

Overload
exists if the same language construct has several meanings.In our proposal, there is a link impacts, which is used to represent impacts negates and impact harms concepts of the ISSRM domain model.We allow this overload, first, because it keeps the language relatively simple, without too many modelling constructs.Second, the semantical difference is captured in the label of the impacted construct (Goal, Plan, Resource or Softgoal), as we have discussed in Section 4.3.

Incompleteness
(or deficit) appears when a language does not convey information on a certain phenomenon.With respect to the incompleteness, first, we need to discuss concepts, which, although present in the ISSRM domain model, are skipped in the Risk-aware Secure Tropos.These are Risk treatment (and relationships decision to treat and leads to), relationships provokes and refines.
We do not define visual construct for Risk treatment (also relationships decision to treat and leads to), because this concept does not present any modification done to the modelled IS.This concept stands as a rationale and indicates modeller's mental decision.Nevertheless, it needs to be recorded in the system specification, additionally to the created IS model, using other means.
In Risk-aware Secure Tropos, we do not define the single concept of Risk.We represent it as combination of a Threat and Impacts relationship.This means that the ISSRM relationship significance assessed by is not explicitly represented by a link.However, we can implicitly identify this relationship by analysing links between security criteria (expressed using Softgoals or Security constraints) and the concerned risk (expressed by the Threat and Impacts).
Due to the overlapping semantics of the Impacts relationship, we can only implicitly define provokes relationship.This is done through multiple use of the impacts link.However, language does not allow modelling which impact has provoked which impact.This information needs to be captured using other means.
Some concepts addressed in Risk-aware Secure Tropos are considered differently than how they are defined in the ISSRM domain model.For example, the ISSRM threat consists of a threat agent and an attack method.Following principles of Tropos, we define that attack agent (Actor) holds threat and attack method (expressed using Hardgoals and Plans).
Further, the ISSRM event consists of threat and vulnerability.In case of Riskaware Secure Tropos, we define event either as a Threat or as a combination of an Actor, Goal, Plan, Vulnerability point, Targets and Exploits.In this situation, we are not able to identify the precise vulnerability per se (only the point where it exists).This means that exact vulnerability needs to be specified using other means.

Under-definition
(or excess) arises when a language construct has no semantics.In our proposal, we do not observe any under-definition problem.

Related Work
At the various IS development stages, security can be addressed using various models; for example, goal models created with i * [49], Tropos [6] or KAOS [47]; UML class diagrams [41]; BPMN [42], and so on.But these languages were not designed with security in mind and, thus, their support for it is weak.There are also security modelling languages specifically dedicated for analysis and modelling of IS security concerns.For example, Abuse frames [20] suggest means to consider security during early RE.UMLsec [19] and SecureUML [22] are used to address security during system design.Goal modelling languages have also been adapted to security.Secure i * [10] addresses security trade-offs.KAOS extension to security [46] adds anti-goal models designed to elicit attackers rationales.Tropos has been extended to the Secure Tropos [32] methodology considered in this paper.Abuse cases [27], Misuse cases [45] and Mal-activity [44] diagrams address security concerns through negative scenarios or processes executed by the attacker.Relevant to risk, Mellado et al. [8] and [9] have presented work related to security requirements approaches based on risk.the Tropos Goal-Risk (GR) framework is another Tropos extension that considers the concept of 'risk' [3].Its objective is to assess the risk of uncertain events over organisation strategies and to evaluate the effectiveness of treatments [4].Regarding our scope, it is necessary to note that the range of risks supported by Tropos GR framework is not focussed on IS security.It is open to risk in general, taking place in different domains at the level of an organisation, like risk in project management or financial risk.Finally, in [13], a model is proposed to explain the relationships between security requirements and risk components, for certification and accreditation purpose.It is used for identifying the risk components, and map them to concepts in domain-specific taxonomies (e.g., of threats, assets, vulnerabilities, countermeasures) defined within the approach.This model is based on the Common Criteria model [7], that is considered in our ISSRM domain model too.
In most cases, the above languages have not been specifically designed with security aspects in mind.Such aspects have been incrementally introduced and have enriched existing languages, because of the growing importance of security.As a consequence, such languages have progressively included security concepts, without a real systematic language design approach.Moreover, no perfect match with respect to ISSRM is provided by any existing modelling language.Although some languages include some risk concepts, their approaches are not complete regarding ISSRM.The languages also lack guidelines on how they can fulfil the needs of different stakeholders; i.e., representing and unifying individual viewpoints and concerns related to IS security and security risk management.

Conclusions
In this paper, we have analysed how Secure Tropos can be used to manage security risks at the early stages of IS development.First, we have identified language limitations with respect to the ISSRM domain model.Next, we have extended both language syntax and semantics, in order to respect the guidelines of ISSRM.Our work has resulted in a Risk-aware Secure Tropos.In addition to the language itself, we have defined methodological guidelines for the language application.
Our proposal has few limitations with respect to Secure Tropos, from which it was derived.In this work, we have stressed that our purpose is to develop a security risk management approach specifically used during the early stages of IS development.This means that we do not consider Secure Tropos extensions to security, which are defined at the late stages of system development.For example, we do not take into account actor capability analysis [37] [33], or how Secure Tropos models can be used in the system design stages [39].We understand that these extensions are important for the later modelling stages, however, with respect to Risk-aware Secure Tropos, they require additional investigation.
Although we have applied our proposal to the running eSAP example, we acknowledge that more practice-oriented case study is necessary.As the future work, we plan to experiment the language in a case study to validate its usefulness and effectiveness.Application of the Risk-aware Secure Tropos would be easier if it was supported by a software tool.Currently, we are working in the area of the meta-case tool development [11].We hope that a meta-case tool would allow us to engineer case tools from the modelling language meta-model.The meta-model of the Risk-aware Secure Tropos will be used as the input to generate a prototype tool supporting our proposal, and to test it in the experimental environment.

Table 1 :
Alignment ISSRM and Secure Tropos possible solution in this situation might be introduction of labels in front of the construct label (e.g., [BS]business assets, [IS] -IS assets, [Th]threat, and [SR]

Fig. 8
Fig. 8 presents the SEGM abstract syntax.Again the major element of this meta-model is an Actor who executes Plans, uses Resources, and has Goals.Plans can be and/or decomposed to other Plans, Resources, or Hardgoals.Hardgoals (and Secure goals) are achieved through and/or Means-ends relationship by satisfying other Hardgoals, executing Plans or making Resources available.In order to satisfice Softgoals, a sufficient degree contribution should be defined with other Softgoals, Security constraints, Plans, Resources or Hardgoals.As already illustrated in the SEAM meta-model, Security constraint is imposed to Actor.It Restricts (see Fig.9) execution of Plans, availability of Resources and achievement of Hardgoals held by this Actor.One analyses Security Constraints using a number of modelling techniques, such as security constraint decomposition; security constraint delegation and security constraint assignment[30].A secure goal represents the strategic interest of an Actor with respect to security.

Figure 9 :
Figure 9: Abstract syntax of Security constraint and Threat

Figure 10 :
Figure 10: Abstract syntax of Security attack scenario

Figure 11 :
Figure 11: Modelling of eSAP business assets

Figure 12 :
Figure 12: Modelling of eSAP IS assets

Figure 13 :
Figure 13: Identification of an authentication attack

Figure 15 :
Figure 15: Risk treatment and security requirements definition