In current practices security concerns are typically addressed at the design or implementation stages, leaving aside the rationale for security analysis. The reason is that a systematic approach to address security from late development stages to early analysis stages does not exist. This paper presents transformation rules to perform model translation from misuse case diagram to Secure Tropos model. The translation justi es the system security concerns, and keep the traceability of the security decisions. Our proposal is based on the systematic domain model for information systems security risk management (ISSRM); thus, it preserves the semantics of both security languages' constructs and synchronise the mechanisms across language boundaries to elicit, correct and complete security requirements. An example from banking sector demonstrates the applicability of our proposal.
It is recognised that blemishes in requirements, on one hand, cost 10 to 200
times more once handled [
In this paper we introduces a set of transformation rules to translate misuse
case diagrams [
The structure of the paper is organised as follows: in Section 2 we give the
background knowledge of security languages and introduce their alignment to
the ISSRM domain model. In Section 3 we introduce the transformation rules
to translate misuse cases to Secure Tropos. We illustrate our proposal through
an online banking example [
The ISSRM domain model [
i ) Assets-related concepts describe the organisation's assets classi ed as business and IS assets along with the security criteria for business assets expressed in terms of con dentiality, integrity and availability.
ii ) Risk-related concepts de ne risk, composed of a threat with one or more vulnerabilities. An impact is the consequences of an event that negates the security criterion. An event is an aggregation of threat and one or more vulnerabilities. A vulnerability is the characteristics of IS assets that expose weakness or aw. A threat is an incident initiated by a threat agent to target one or more IS assets. A threat agent is an agent who has means to harm IS assets intentionally. An attack method is a standard means to execute threat.
iii ) Risk-treatment related concepts describe a decision (e.g., avoidance, reduction, retention, or transfer) to treat the risk and security requirement is its re nement. A control is the implementation of requirements.
The ISSRM application follows the general risk management process
based on the security standards (see details in [
Misuse cases [
As illustrated in Fig. 2 misuse cases are integrated in use case diagrams to express the system unwanted behaviour (e.g., misuse cases Money stolen, Enter pin code result repeatedly, and Transfer money to own account) initiated by a misuser (e.g., Attacker). This depiction results in security use cases e.g., Perform cryptographic procedures. 2.3
Secure Tropos [
Secure Tropos uses relationships to connect constructs. Dependency link shows that one actor (depender) depends on another actor (dependee) to attain some dependum (e.g., goal, plan or resource). A secure dependency is restricted by the security constraint that must be respected by both actors (e.g., relationship between Customer and Banking IS). A means-end link indicates how the goal (end) is satis ed. A decomposition relationship represents a breakdown of plan into several plans or goals. Restricts and attacks relationships are introduced in Secure Tropos where former shows a security constraint restriction on a goal achievement and prior indicates the target of attacker's plan.
Tropos methodology covers the overall IS development, however we limit our
scope to the goal and security attack scenario modelling (which correspond to
the Tropos late requirements stage [
As discussed in [
This section introduces a set of rules for translating Misuse cases to Secure Tropos model. They are based on ISSRM model and its application process.
Asset-related concepts are translated using following transformation rules: TMS1. A system boundary that presents software system in the misuse case diagram is translated to the Secure Tropos actor.
This rule is based on alignment between the Secure Tropos actor and misuse case system boundary to the ISSRM IS asset as introduced in Table 1 (line c). In Fig.3 we present a Secure Tropos actor Banking IS with its boundary.
TMS2. A use case is translated either to Secure Tropos goal or plan belonging to the boundary of the system actor. Correspondingly, an includes link is translated either to means-ends relationship (where ends is the goal and means is the 0 1 Risk related concepts
a Asset Asset related b Business asset concepts c IS asset d Security Criteria Security constraint e Risk f Impact
Actor, goal, plan, resource Risktreatment related concepts 3 3.1 g Event h Threat i Vulnerability j Threat agent k Attack method l Risk treatment m Security re
quirement n Control
Contribution between threat and other construct Threat Goal, plan Vulnerability point Actor Plan, attacks relationship Actor, goal, plan, resource, security Security use case constraint
Misuse structs
2 Actor and use case System Misuser & Misuse case Misuser Misuse case plan) or to decomposition relationship (where some plan is decomposed). Note: we assume OR)means-ends, and AND)decomposition in Secure Tropos model.
It is de ned according to the lines a and b. Here the developer decides whether a use case is translated to Secure Tropos goal or plan. In Fig. 3, we translate the use case Transaction be performed to goal meaning that the use case Perform transaction should be plan, because only a plan could be means to achieve the goal (ends) in Secure Tropos. On the other hand, the use case Account privacy guaranteed is translated to a goal. Here we also de ne two plans Perform authorisation and Perform cryptographic procedures that are the means to achieve this goal. We illustrate the OR relationship to specify two alternates to achieve the goal Account privacy guaranteed.
In Fig. 2, two actors (e.g., Customer and Bank officer) communicate to the Banking IS. Based on the Table 1 lines a and b we translate these actors to the Secure Tropos actors in Fig. 3 by introducing the following rule: TMS3. An actor from the misuse case is translated to a Secure Tropos actor.
An interaction of actor with system presents how actors collaborate to achieve their goals. In misuse cases it is de ned by communication links while Secure Tropos uses dependency links. A communication link would be translated using either of the three following cases:
TMS4. (i) If the system is dependee, then the communication link is translated as depender and the use case to which the misuse case actor communicates is de ned as dependum (according to TMS3) in the Secure Tropos dependency; (ii) If the system is depender, then the communication link is translated as dependee and the developer specify the dependum manually, since it is not possible to capture it from the misuse case diagram; (iii) A security constraint could be de ned to restrict the goal/plan (as well as the dependum). The restricted goal/plan is translated from the use case, to which the actor communicates in the misuse case diagram.
Following TMS4, the communication links (see Fig. 2) between actors Bank officer and Customer with Banking IS are translated to the dependency links (see Fig. 3). However, it is not possible to capture security constraints (Table 1, col 2 , line d ). Although, we de ned them manually (e.g., Only by bank customer and Only by authorised bank officer) by identifying the elements that needs to be restricted e.g. dependum goal Manage account in Fig. 3.
Translating risk-related concepts, generate the Secure Tropos attack scenario (see Fig. 3) using the following transformation rules:
TMS5. A misuser is translated to Secure Tropos actor. In the discussion below we recall this actor as a threat agent.
It is based on line j in Table 1, which identi es that the misuser and the Secure Tropos actor are aligned to the ISSRM threat agent. Thus in Fig. 3 we identify a threat agent as Attacker.
TMS6. A misuse case is translated to the plan of threat agent. Using TMS2, an includes link is translated to the Secure Tropos decomposition relationship.
In Table 1, this rule refers to lines h and k , according to which ISSRM threat and attack method are presented as misuse case and plan (and goal ). Therefore, Money stolen, Steal money, Enter pin code repeatedly, Enter user code once and Transfer money to own account are translated to plan constructs in Secure Tropos model (see Fig. 3). To simplify the translation misuse cases are transformed to only Secure Tropos goals.
TMS7. A threatens relationship is translated to the Secure Tropos exploits link. The exploits link is pointed to the vulnerability point, which needs to be added to the appropriate Secure Tropos construct.
In the example, threatens relationship is translated to Secure Tropos exploits link from the threat agent's plan Enter pin code repeatedly to the vulnerability point identi ed in the Enter result of pin generator (see Fig. 3). Secure Tropos threat agent and his plans; correspond to the combination of the ISSRM threat agent, attack method and threat. Following Table 1 de ne a Secure Tropos threat (aligned to the ISSRM event ) as a generalisation of the Secure Tropos threat agent and its boundary. For example, Money stolen.
Translating risk treatment-related concepts, a security use case Perform cryptographic procedures is already translated to the Secure Tropos plan (see Fig. 3) as discussed in rule TMS2. Now we introduce that:
TMS8. A mitigates relationship from the misuse case diagram is translated to the mitigates link in Secure Tropos.
In the ISSRM domain model (Fig. 1) the mitigates relationship indicates the mitigation of potential risk event by introducing appropriate security requirements. The security use case Perform cryptographic procedures mitigates the threat Money Stolen, thus it is translated to the Secure Tropos mitigates to reduce the risk event Money stolen. 4
Semi-automated Transformation: The transformation rules could support a semiautomatic model translation. When translating the models, the developer needs to indicate if the (mis)use cases need to be translated to the goal or plan (see rule TMS2). It in uences the translation of includes relationship either to meansends or decomposition. Also in TMS4, the developer indicates whether the Secure Tropos actor (translated from the misuse case software boundary) plays the role of dependee or depender in the translated dependency link(s). Additionally, the developer de nes the labels for dependum and security constraint(s) (as illustrated in Fig. 3). The remaining rules could be applied automatically.
Transformation Completeness: The transformation does not contribute with complete model in the target language but helps developers to concentrate on the details, which give the added value for the target model. The transformation highlights the major overlapping semantic areas of two security languages. The translated Secure Tropos model give reason for the system security.
Transformations and Misuse Case Textual Template: Matulevicius et al. [
In this paper we tackled to eradicate the gap between the functional (software) system requirements and their relation to early security requirement analysis. We de ne a set of transformation rules from misuse case diagrams to Secure Tropos models. The transformation highlights and preserves the security-related semantics. The resulted model helps understanding the environment and gives reasoning on the bene ts and trade-o s of the security decisions taken. Therefore, it bene ts the overall model maintainability management between the two di erent presentations of security problem. In the example we have illustrated the applicability of our proposal, we acknowledge the importance of the industrial case study to validate the rules. The translation can be applied to existing or legacy systems to nd the missing rationale for implemented security primitives and can provide alternate security solutions to solve the problem.
We agree to the importance of validating the current work and as a future work we encourage to empirically validate the translation through perception, performance and correctness tests. Furthermore, we plan to expand the scope by introducing a semi-automated transformation rules for other security languages. Such approach would result in a systematic model-driven security engineering, which would facilitate systematic security de nition from the early requirements to system design and implementation.