Keywords

1 Introduction

Security concerns play an important role in nowadays enterprises. Different enterprise stakeholders have various objectives and need to collaborate to achieve them. Thus, understanding security risks and estimating their impact could envision threats, estimate their consequences, and propose countermeasures to mitigate these threats.

Secure Tropos is an agent-oriented information and enterprise system development method that helps understanding security objectives through satisfying security constraints by considering actor dependencies [11]. In [7, 8] Security Tropos was extended to Security Risk-aware Secure Tropos (RAST), where the original language was semantically aligned to the concepts of the domain model for information systems security risk management (ISSRM) [6, 9]. The extended language supports security requirements elicitation through understanding security risks. However, even given an IS with a rather moderate complexity, identifying and mitigating security risks could become quite a complex activity. One of the reasons is the inherited complexity of the Secure Tropos model, when the model size quickly grows with introduction of different analysis concerns.

In this paper we propose an application of security risk-oriented patterns (SRPs) [2], which could overcome the above problem by suggesting the proven security solutions for the reoccurring security problems. We analyse how to apply SRPs and derive security requirements from Secure Tropos models. To answer the question, firstly, we have represented SRPs using RAST. Secondly, we have proposed a process to apply SRPs to derive security requirements from the (Secure) Tropos models. Finally, we have conducted an observatory study to understand usability of the proposed method.

The rest of the paper is structured as follows: in Sect. 2 an overview of security risk management using Secure Tropos is provided. Section 3 presents security risk-oriented patterns. In Sect. 4 we consider the process for security requirements derivation from the Secure Tropos model. Section 5 outlines the observatory study conducted in order to validate the usability and understandability of the pattern application. Section 6 discusses some related work. Finally in Sect. 6 we summarise the study discussion and present some future work.

2 Security Risk Management Using Secure Tropos

In this section we, firstly, present the ISSRM domain model used to define the SRPs and to analyse the Secure Tropos models. Secondly, we overview how Secure Tropos constructs are aligned to concepts of the ISSRM domain model.

2.1 Information Systems Security Risk Management

The ISSRM domain model (see Fig. 1) defines security risk management concepts at three interrelated levels, which help developers identify specific IS security risk management constructs [6, 9].

Fig. 1.
figure 1

The ISSRM Domain Model (adapted from [6, 9])

Full size image

Asset-related concepts (i.e., business and IS assets, and security criterion) explain the organisation’s values that need to be protected. The needed protection level is defined as the security needs, typically in terms of confidentiality, availability and integrity. Risk-related concepts (i.e., risk, impact, event, vulnerability, threat, attack method, and threat agent) define the risk itself and its components. Risk is a combination of threat with one or more vulnerabilities, which leads to a negative impact, harming some assets. An impact shows the negative consequence of a risk on an asset if the threat is accomplished. A vulnerability is a weakness or flaw of one or more IS assets. An attack method is a standard means by which a threat agent executes a threat. Risk treatment-related concepts (i.e., risk treatment decision, security requirement and control) describe how to treat the identified risks. A risk treatment leads to security requirements mitigating the risk, implemented as security controls.

The risk management process consists of six steps. First, it initiated by identifying analysed context and assets. The second step is security objective determination. The third step includes risk analysis. This step is followed with making a risk treatment decision. In the fifth step one suggests security requirements, which are implemented to security controls (sixth steps). The process is iterative and each previous step could be repeated if its result is not of satisfactory quality.

2.2 Security Risk-Aware Secure Tropos

Security Risk-aware Secure Tropos (RAST) is an extension of the i* framework [13], Tropos [4] and Secure Tropos methods [11]. By aligning the modelling constructs to the concepts of the ISSRM domain model, it becomes possible to use the targeted modelling constructs to express specific concepts from the security risk management domain. This extension enables using Secure i*/Tropos concepts wherever possible utilizing the already existing constructs, but additionally, whenever void or ambiguity exits, new constructs are introduced to address security risk management.

Asset - Related Concepts. The ISSRM assets are modelled using Secure Tropos constructs Goal, Softgoal, Actor, Plan and Resource. Goal is defined a desired state that an actor is determined to achieve (e.g., Data Employed in Fig. 2). Softgoal is a desired state that an actor is determined to achieve yet there is no clear determination of how this state is to be achieved (e.g., Confidentiality & Integrity in Fig. 2). Actor is an entity that is part of a system and is driven by certain goals and intentions (e.g., Server and Input Interface in Fig. 2). Plan is a course of action followed by an actor in order to achieve and satisfy a goal (e.g., Submit data in Fig. 2). The relationships between the assets are modelled using the constructs of contribution, means-ends, and decomposition. The ISSRM security criterion is represented by combining a Softgoal with Security constraint(s) (e.g., Confidentiality & Integrity and Maintain the integrity & confidentiality of the submitted data in Fig. 2). The ISSRM constraints of relationship can be modelled both explicitly by the Restrict link (see Fig. 2) and implicitly as security constraint placed on the security dependency link and restricting use of dependum (e.g., see connection between Server and Input Interface in Fig. 2).

Fig. 2.
figure 2

SRP1: assets and security criteria

Full size image

Risk - Related Concepts. To distinguish risk related concepts darker colours are introduced to Secure Tropos constructs. The ISSRM threat agent is represented as actor (e.g., Attacker in Fig. 5). The ISSRM attack method – as a plan and the ISSRM threat as a combination of goal and plan (e.g., submitted data obtained and Intercept transmission in Fig. 5). The ISSRM vulnerability is not represented, how it is indicated through vulnerability point (see black circle in Fig. 5).

Risk Treatment - Related Concepts. The ISSRM security requirements are modelled by combining constructs of Goal, Softgoal, Plan, and Security constraint (e.g., (S) Perform Cryptographic procedures in Fig. 6). The ISSRM mitigates relationship is used to indicate a connection where a construct or group of constructs mitigate a certain security risk.

3 Security Patterns

“A security pattern describes a particular recurring security problem that arises in specific contexts, and presents a well-proven generic solution for it” [12]. Following this definition and the principles of the security risk management (see Sect. 2.1), five security risks-oriented patterns are introduced in [2]. In this section we briefly recall these patterns and illustrate how RAST could be used to represent them.

3.1 Security Risk-Oriented Patterns

SRP1 describes how to secure the transmission of confidential data between business entities. This pattern involves an attacker who intercepts the transmission between the input interface and the server, then obstructs and modifies the data. The attack is facilitated due to the transmission medium not being encrypted and data being stored in a plain text. The risk event leads to the loss of the confidentiality of the data and loss of the integrity of the data. The risk is mitigating by introducing cryptographic and checksum countermeasures.

SRP2 enables validation of data submitted to a business activity, by predicting the need for a mechanism that scans and detects malicious data before the data is forwarded to this business activity. This pattern counters an attacker that has information regarding the systems inner functionalities. The malicious agent attacks by submitting through the input interface a malicious script that exploits the fact that incoming data are not filtered. The attack leads at the loss of confidentiality and the integrity of the business activity that is forwarded to.

SRP3 ensures the availability of a service in a Denial of Service (DoS) event. The attacker sends an exponentially growing number of simultaneous requests to the system, resulting in the system crashing due to its ability to only serve a certain number of simultaneous clients. The attack leads to the loss of the service availability.

SRP4 focuses on securing confidential information, from being accessed by unauthorised devices or people. An attacker gains access to sensitive business data through a commonly used retrieval interface. Due to the interface not having an access control mechanism, the attacker is able to retrieve the data. The attack negates confidentiality of the business data.

SRP5 specifies how to secure data stored into a business data store against internal attacks. The attack occurs due to the data being stored in a plain format, and, thus, leads to the loss of the confidentiality of the stored data and the perpetual damage of the files residing in the same instance as malicious script.

3.2 Security Risk-Oriented Patterns Expressed in Secure Tropos

In this section we demonstrate how RAST could be applied to represent SRPs; more specifically we will represent SRP1. For instance, in Fig. 2 we define Submitted data as the ISSRM business asset. Both Server and Input Interface should collaborate in the way to achieve Confidentiality and Integrity of the submitted data. This security criterion is clarified by security constraint Maintain the integrity & confidentiality of the submitted data. This constraint restricts the goal of Data employed at the Server side and Data submitted at the Input interface side. Submit Data plan is the dependum between the two actors, and two constrains indicate that this double constrained dependency should be fulfilled by Server and Input Interface’s activities.

Figure 3 introduces the Transmission Medium actor, which is used to transfer data from Input Interface to Server. This actor is part of the considered system (i.e., IS asset), thus, it is used to support the transfer of the business asset (i.e., Submitted data).

Fig. 3.
figure 3

SRP1: context pre-processing

Full size image

In Fig. 4 we identify a security even defined as Man in the middle attack that impacts the security criterion Confidentiality & integrity. In Fig. 5 this event is expanded showing how Attacker can achieve his goal Submitted data obtained by executing the attack method Intercept transmission.

Fig. 4.
figure 4

SRP1: security risk identification

Full size image
Fig. 5.
figure 5

SRP1: security threat

Full size image

To mitigate the risk in Fig. 6 we present the implementation of risk reduction decision. Hence there, the secure plan of the Ensure the integrity & confidentiality of the submitted data (see Fig. 3) is changed with Perform cryptographic procedures and Perform checksum procedures. The replacements are performed in the according actor of the model. Risk mitigation is indicated using the Mitigates relationships.

Fig. 6.
figure 6

SRP1: security requirements definition

Full size image

Although RAST contains some limitations with respect to the ISSRM domain (as indicated in [7, 8]), the language allows represent the SRP description. In our example, the recurring security problem is illustrated in Figs. 4 and 5, the context in Figs. 2 and 3. Finally we present the solution in Fig. 6. We will illustrate how graphical SRP representations can be used to derive security requirements from the Secure Tropos models in Sect. 4.

4 Deriving Security Requirements Using SRP’s

4.1 Collaboration Between System and Security Analysts

Application of SRPs to Tropos model could stimulate collaboration between two roles (as illustrated in Fig. 7) – system analyst, who is responsible for system development, for example, using i*/Tropos method, and security analyst, who is responsible for security solutions and could potentially apply SRPs to achieve her goals. In some cases both roles could be played by the same person. For instance, after creating system model using i*/Tropos method, system analyst could potentially request security analyst to determine security requirements. After analysing the system model, security analyst selects and applies the relevant SRPs. The SRP application includes (1) SRP occurrence identification and asset alignment, (2) vulnerable asset identification and secure goal introduction, and (3) security requirements introduction. After this iteration, security analyst could potentially consider whether other SRPs should be applied. If not the system model with introduced security requirements is returned back to system analyst.

Fig. 7.
figure 7

SRP1: collaboration between system and security analysts

Full size image

Next system analyst should potentially decide which security requirements could be implemented to the targeted system. In other words, system analyst needs to perform trade-off analysis to understand the cost-value benefits of the security solution. In case of necessity, system analyst could potentially request security analyst for justification of the proposed security requirements. In the latter case, the instantiated SRP’s security threat models (e.g., see Fig. 5) could be used to (4) provided security requirements rationale.

4.2 Security Requirements Derivation

Now we will illustrate how the SRPs expressed in RAST could be used to derive security requirements from the Secure Tropos models. The model [3] used to demonstrate the derivation process is presented in Fig. 8. We will use the SRP1 (illustrated in Sect. 3.2). However other SRPs can be following the same steps.

Fig. 8.
figure 8

Internet store registration; adapted from [3]

Full size image

1. Occurrence identification and asset alignment. This step includes identification of the pattern occurrences in the analysed model. This is a manual activity due to the complexity of the Secure Tropos models. In Fig. 8 we aim to apply SRP1. The contextual pattern description helps to observe the following occurrences:

  • The Internet Store actor aligns to the SRP1 Server actor, thus, giving the similar interactions with the other actors;

  • The User (Interface) aligns to the SRP1 Input Interface due to the connection to the Internet Store/Server. Given that a 1:1 occurrence not existing between SRP1 and the scenario under investigation, we assume that the User fulfils the Send Use Info plan by using an input interface provided by the Internet Store. This is why we recall the User actor as User Interface.

Following the pattern description a Transmission Medium is introduces as the intermediate actor to Send user info. This assumption is done to support the communication between the User and the Internet Store.

Next step is to consider the dependency relationship and potentially equipped it with the security constraints in order to highlight the security objectives. The extracted occurrence of the pattern is illustrated in Fig. 9.

Fig. 9.
figure 9

Asset and security criteria analysis

Full size image

2. Vulnerable asset identification and secure goal introduction. In this step vulnerable assets are identified and security criteria and constraints are explicitly introduced. The process follows the RAST methodology of separately illustrating business and IS Assets as illustrated in Figs. 9 and 10. Additionally in this instance we introduce the secure goals and secure plans suggested by the pattern. The secure goals and plans are introduced to their aligned goals.

Fig. 10.
figure 10

Model Pre-processing

Full size image

3. Security requirements introduction. Following the SRP1 risk treatment and security requirements definition, it becomes possible to introduce secure goals and plans as illustrated in Fig. 11. The previously defined model now is also equipped with security requirements such as Perform checksum procedures and Perform Cryptographic procedures. As illustrated in Fig. 11 both suggestions mitigate the security event (i.e., Man in the Middle Attack).

Fig. 11.
figure 11

Security risk identification

Full size image

4. Security requirement rationale. In some cases this step could be considered as optional, but it becomes important, once one needs to understand the rationale and trade-off of the newly introduced security requirements. Following the pattern attack scenario, in this step one defines how the security threat could be carried on the targeted system. More specifically in our case, Fig. 12 illustrates how Attacker (i.e., threat agent) could obtain the user info by intercepting transmission.

Fig. 12.
figure 12

Security threat

Full size image

5 Validation

To validate the SRPs expressed in RAST and their application process contribution we have conducted an observatory study. Its objectives were (i) to understand correctness and (ii) usability the SRP application, (ii) to compare understandability of the SRP application of the participants with the ISSRM background against participants without ISSRM background.

5.1 Observatory Study Design

Participants. We have invited six individuals with the software engineering background. Three participants (i.e., group A) had the IS-security background as they were working in the field of enterprise security and had prior knowledge of the ISSRM concepts. Other three participants (i.e., group B) had no information systems security background, but nevertheless they were practitioners working in the software engineering companies.

Design. Firstly, the participants were given the introductory lecture. Secondly, they participants were given a Secure Tropos model and were asked to derive the security requirements using the SRPs. Finally, the participants filled the questionnaire on the usability of the SRPs and their application process. Each participant took approximately 3 h to complete the process.

Treatment. The lecture included an introduction of the ISSRM domain model and security risk management process (see Sect. 2.1), RAST (see Sect. 2.2), SRPs (see Sect. 3) and their application process (see Sect. 4). The lecture was concluded with an SRP application demo.

SRP application task focussed on the pattern application process (see Sect. 4). Participants were given a model described in Sect. 3 and were requested to identify SRP occurrences as well as derive security requirements. None of the participants applied all the SRPs (see Table 1), since we limited their participation to three hours.

Table 1. Participant pattern application errors
Full size table

Questionnaire. Once the SRP application was completed, participants filled the questionnaire on the usability of the RAST process, SRPs and SRP application process. Specifically in included questions on easiness, satisfaction, and understandability of used artefacts.

5.2 Threats to Validity

The following threats to validity should be taken into account:

  • The number of participants is rather small (only six participants) thus the sample may not be accurate. The results might differ if we were able to attract more participants. However they all were practitioners working in the field of software security engineering.

  • Given treatment could influence the received results. When applying SRPs participants had some questions, and we provided then with the answers. However otherwise they would have difficulty to complete the given task.

    Each participant conducted his task individually. If participants had opportunity to discuss and to learn from each the result potentially would be different.

  • Each participant applied different SRPs. Ideally all of the participants would have to complete all SRPs for better result. However, we were limited by the time constraints (three hours per participant).

  • Participants had a varying level of prior knowledge of ISSRM domain and security risk management. Having participants with the same knowledge could potentially deliver more reliable result. We tried to mitigate this threat by provided introductory lecture.

  • The majority of the participants implemented the models using an online drawing tool. Implementing the models by hand or other modelling tool method could impact the modelling outcome.

  • The participants were not told that they were expected to perform in a certain way or that a specific result was expected from them. Stating expectations upfront would impact the overall performance of the participants. The performance could be enhanced in case the participant would want to perform according the expectations. Or the participant could suffer from a type of performance anxiety and his result would be negatively affected.

  • Participant had prior acquaintance with the conductor of the observatory study and the first author of this paper. If no prior acquaintance would occur participants could not ask the same questions or perform in the same manner they would perform to another individual. However this acquaintance was the way to involve participants in the evaluation.

  • Some SRPs were easier identified in the model comparatively to other SRPs. If all the SRPs would be identical in terms of identification ease, the result could be different. Making an SRP easier or harder to identify results in the pattern application process becoming automatically easier of harder to perform.

All the above threats had a certain effect to the overall results. We assume that in case of a more extensive study with a greater number of participants and different design, different outcomes might be received.

5.3 Observatory Study Results

Correctness of the Participant Models. Correctness of each SRP application is defined through the number of errors identified in the resulting model (i.e., the lower number indicates better model correctness). Errors are divided to two categories phrasing and modelling errors. Phrasing errors describe any error in regards to the phrasing of any of the constructs (e.g. labels of goals, plans, and etc.). Modelling errors describe errors performed in the modelling of each concept. Modelling errors include using wrong constructs when linking assets, risk components, security countermeasures and similar. Additionally, modelling mistakes also include incorrect colouring of the constructs (as the colour here brings the semantic difference between security risk concepts). Both types of errors are discovered by comparing the participants’ models with the models prepared by the first author of this paper.

Table 1 presents the result of the model correctness. It was observed that Participant 2 has made the least amount of errors compared to the other participants. It is also important is to point out that the majority of errors done by Participant 1 were rather minor in comparison to phrasing errors of the other participants. In general the majority of the errors are phrasing errors. This could be explained by the fact that the modelling language does not provide explicit guidelines on how to name the constructs during modelling.

Understandability. As mentioned in the design description, the participants were divided to two groups – group A and group B – based on their previous experience with the security engineering. The results show that participants of group A were able to apply and comprehend the used patterns as well as the pattern application process. Participant of group B were able moderately to apply and to comprehend SRPs. Group A correctly executed all the pattern application steps. Nonetheless mistakes were made in phrasing and resource decomposition (as discussed above). But they performed all the tasks in a rather reasonable time and were confident in their results.

Group B completed the SRP application process with a moderate correctness. Similar to group A, group B also made mistakes in phrasing and modelling. Furthermore, noticeable difference in the results was the level of confidence in the results of the application process. Participants of group B were notably less confident than the participants of group A in their results. As conclusion we observed that the information systems security experience had some impact and helped better contributed to the understandability of the SRPs application.

Discussion and Concluding Remarks. We draw out the concluding remarks based on our observations and the participant responses marked in the questionnaire. All participants completed the application of at least one pattern. Mistakes were observed in the phrasing and modelling of various assets of the models. In comparison less mistakes were made in modelling rather than phrasing. All the participants understood the proposed SRP representations. The pattern application process was according to the majority of the participants moderately easy to be applied. RAST affects the overall process in a moderate level.

The fact that both groups were able to complete the tasks assigned, demonstrated that the process is useable as a starting point to derive security requirements in a goal-oriented environment. The easiest part in the application process according to the majority of the participants was the pattern identification and asset alignment. The hardest step to be applied by the majority of the participants was security requirement introduction and extracted model re-integration.

Having background knowledge in IS security affects the process during the first applications and speeds up moderately the security requirement derivation process. Prior knowledge of an agent-oriented language in combination ISSRM affects rather positively the outcome of modelling. Participant that had no prior knowledge were less confident about their results. The following lessons are learnt:

  • Application of the SRPs helps to construct rather correct security models and derive appropriate security requirements. The major modelling mistakes are made due to the lack of guidance from the modelling language application.

  • The SRP application guidelines are rather understandable and moderately usable by their users. However, a priori experience in security engineering helps to see the method purpose. Potentially some security engineering training could help to improve method application.

6 Related Work

There are few studies where the secure i* framework [13] or Secure Tropos is used to capture security and privacy requirements through security patterns. Some extensions are proposed to Secure Tropos to be suited for the security pattern description language [10]. Elsewhere in [5], legal requirements are incorporated to security and privacy patterns expressed using another extension of Tropos methodology towards security. Here authors concentrate on access control, need-to-know, outsourcing, and non-repudiation patterns. In addition to these contributions, in this paper we use the Secure Tropos approach [11] to represent security risk-oriented patterns.

In [1] Ahmed has presented a method for security requirements elicitation from business processes (SREBP). This method enables security requirements derivation from BPMN models, namely value chains and business process models. The method involves collaboration between the business analyst and security analyst. In the current study we develop a method to derive security requirements from the RAST models. Hence the collaboration is defined between the security analyst and system analyst, since we consider the late requirements stage modelled in Secure Tropos.

7 Summary and Future Work

In this paper we analyse how to integrate security risk-oriented patterns into the goal-oriented IS development. We have developed a threefold procedure. Firstly, it is important to define and describe the SRPs in modelling language used for IS development, in our case RAST. Secondly this description is used to identify the pattern occurrences in the targeted IS model. Typically this step requires some model pre-processing. Finally, the security requirements are derived and introduced following the SRP description. To support this procedure we have presented a pattern presentation structure as well as their application process. The proposal is validated in the observatory study, which illustrates the SRP usability. Finally it was demonstrated that the proposed SRP’s could potentially be the starting point for security requirements derivation and security trade-off analysis.

The future work includes expansion of the SRP list with new patterns and their representation using RAST. Also it is important to define guidelines for systematic security requirements prioritisation and their implementation to security controls. Last but not least, the software tools to support the representation of the SRPs ain RAST and their application process could potentially help to decrease the application effort.