Fig 2 - uploaded by Tong Li
Content may be subject to copyright.
![Security requirements operationalization example We leverage existing security patterns [2, 3] to help analysts without security knowledge to operationalize security requirements. In particular, we assign each security pattern a tag, which specifies the security property that a security](profile/Tong-Li-57/publication/268334033/figure/fig4/AS:668771664543752@1536458998532/Security-requirements-operationalization-example-We-leverage-existing-security-patterns.png)
Security requirements operationalization example We leverage existing security patterns [2, 3] to help analysts without security knowledge to operationalize security requirements. In particular, we assign each security pattern a tag, which specifies the security property that a security
Source publication
Security patterns capture proven security knowledge to help analysts tackle security problems. Although advanced research in this field has produced an impressive collection of patterns, they are not widely ap-plied in practice. In parallel, Requirements Engineering has been increas-ing focusing on security-specific issues, arguing for an upfront t...
Contexts in source publication
Context 1
... use the concept Security Goal to represent security requirements. A se- curity goal is specified in a template, <Importance><Security Property> [<Asset>, <Interval>], as shown in Fig. 2. Our approach iteratively carries out security requirements analysis in each of the three layers. In particular, we iteratively refine security goals to "operationalizable" ones, among which we identify critical security goals that need to be treated. Then we operationalize critical security goals into specific security mechanisms, ...
Context 2
... security pattern a tag, which specifies the security property that a security pattern can potentially tackle. Thus, by matching the security property specified within a critical security goal and the tag of a security pattern, we can identify a number of security pattern candidates, among which the analyst must select. For example, as shown in Fig. 2, there are seven security pattern candidates that are identified to tackle the critical security goal High Application Integrity [Energy Management System, Price calculation] according to its security property Application Integrity. However, the selection among security pattern candidates is a non-trivial task, whose complexity grows ...
Citations
... We found extensions that model contextual aspects [37,38,39,30,40,29]. ...
Purpose
Human-centric characteristics of the end-users of software systems, such as gender, age, emotions, personality, language, culture, and physical and mental impairments, play an essential role in the uptake and usage of the software. Current software tools suffer from the lack of in-depth elicitation and understanding of these human-centric requirements during the design and modelling of the system. This can lead to ineffective and hard to use software for some users.
Methods
In this paper, to be able to account for contextual variables in human interaction with diverse characteristics, we propose an approach for using personas and contexts to model human-centric aspects of the software in goal models. To achieve this, we select the iStar language due to its ability to model social, intentional and strategic dimensions, and propose an extension of it to model human-centric aspects of the software. Our novel approach is illustrated with two examples.
Results
We conducted user evaluation studies to understand how users model human aspects, and also to measure the effectiveness of our approach. Results show the lack of consideration of the human-centric aspects in existing modelling frameworks and how our extended model can simplify the understanding and addressing of such aspects.
Conclusions
This shows and encourages that more research on modelling human aspects of the end-users is required to achieve human-centred modelling.
... In order to guide software practitioners into the proper utilization of security patterns in their projects, the security pattern research community must attend to the fine-grain details of selecting and applying patterns in practice. We have observed a variety of pattern selection techniques in the literature including the utilization of feature models [6,87], ontology [88,89], and selection rules [90,91]. There is a lesser degree of variety in the techniques used for applying patterns. ...
Security patterns are a well-established means to encapsulate and communicate proven security solutions and introduce security into the development process. Our objective is to explore the research efforts on security patterns and discuss the current state of the art, which will serve as a guideline for interested researchers, practitioners, and teachers. We have conducted a systematic mapping study of relevant literature from 1997 until the end of 2017 and identified 403 relevant papers, 274 of which were selected for analysis based on quality criteria. This study derives a customized research strategy from established systematic approaches in the literature. The first 3 research questions address the demographics of security pattern research such as topic classification, trends, and distribution between academia and industry, along with prominent researchers and venues. The next 9 research questions focus on more in-depth analyses such as pattern presentation notations and classification criteria, pattern evaluation techniques, and pattern usage environments. We observe that security pattern research is an active and growing field and the patterns are increasingly being used to improve software development approaches. Pattern evaluation is currently the least explored topic by researchers and there is a lack of empirical studies in the field.
... Liaskos and Mylopoulos [42] represented the temporal values of goal models in a lightweight and concise manner in an iStar extension, by numeric values. Another iStar extension [40] represents contextual goal models in security requirements. ...
iStar is a goal-based requirements modelling language, being used in both industrial and academic projects of different domains. Often the language is extended to incorporate new constructs related to a particular application domain or to adjust it to practical situations during requirements modelling. Currently, the language is undergoing standardisation, and several studies have focused on the analysis of iStar variations to identify similarities and to define a core. This does not imply or constrain the need for iStar to continue to be extended. This paper contributes to the understanding of how iStar is extended by analysing how iStar researchers perform iStar extensions. To address this question, we followed a qualitative approach based on interviews involving 20 researchers from different research groups that proposed iStar extensions. The analysis revealed a good understanding about what extending a modelling language means and pointed out differences about how extensions are proposed. We discovered categories that impact positively on iStar extensions (such as reusing existing extensions, proposing extensions in abstract and concrete syntaxes, and creating new modelling tools), and other categories that impact negatively (such as modifying representations of the original constructs, proposing extensions in an ad hoc fashion and not carefully choosing graphical representations). We also evaluated the findings of interviews through an online survey answered by 30 iStar researchers. Finally, we proposed a set of guidelines to support the proposal for better future iStar extensions.
... During subsequent evaluation of the three-layer framework, we discovered challenges to selecting security patterns during the analysis of security goal operationalization. In subsequent research, we studied the systematic modeling and selection of security patterns [43], while [45] exclusively investigated the impact of security mechanisms on requirements specifications. This paper extends and improves our initial proposal of the three-layer framework [42] and leverages the prototype tool [44] to perform a case study in order to evaluate the framework. ...
... In particular, the current work (1) revises the security requirements analysis process, describing each step in more detail; (2) defines a collection of formal inference rules to (semi-)automate the analysis process; (3) evaluates our framework over a number of research questions using a large and realistic case study; and (4) includes in-depth discussions on the motivation, benefits, and potential of the framework. Two further papers [43,45] that deal with details of selecting and applying security patterns are not covered here. ...
... Specifically, most of these techniques require to capture the positive/negative influences of security solutions on the system non-functional requirements (i.e., softgoals) by using contribution links. Since our framework leverages security solutions from existing security pattern repositories (e.g., [59]), we can elicit the above contribution links from the security pattern specifications, which is detailed in our companion paper [43]. ...
Security has been a growing concern for large organizations, especially financial and governmental institutions, as security breaches in the systems they depend on have repeatedly resulted in billions of dollars in losses per year, and this cost is on the rise. A primary reason for these breaches is that the systems in question are “socio-technical” a mix of people, processes, technology, and infrastructure. However, such systems are designed in a piecemeal rather than a holistic fashion, leaving parts of the system vulnerable. To tackle this problem, we propose a three-layer security analysis framework consisting of a social layer (business processes, social actors), a software layer (software applications that support the social layer), and an infrastructure layer (physical and technological infrastructure). In our proposal, global security requirements lead to local security requirements, cutting across conceptual layers, and upper-layer security analysis influences analysis at lower layers. Moreover, we propose a set of analytical methods and a systematic process that together drive security requirements analysis across the three layers. To support analysis, we have defined corresponding inference rules that (semi-)automate the analysis, helping to deal with system complexity. A prototype tool has been implemented to support analysts throughout the analysis process. Moreover, we have performed a case study on a real-world smart grid scenario to validate our approach.
... Tong Li et al [28,29] proposed the analysis and modeling of security patterns in contextual goal models considering the need of integration of security patterns at requirement analysis stage and difficulty in their application. They proposed mapping of security pattern with contextual goal model. ...
Many approaches for modeling security requirements have been proposed, but software industry did not reach on an agreement on how to express security requirements in a system model or software architecture. The main objective of this perspective paper is to summarize the problem space of representation of security patterns when designing security requirements. Many security patterns are proposed in the literature to help the developers who lack expertise in security to implement it. Application of security patterns has been hindered by the fact that they lack directions for their implementation in a specific scenario. This paper presents a technique for using mitigation use cases for representing solution provided by security patterns. Different challenges and issues were identified related to the application of security patterns in industry.
... The root of this hierarchy is iStar, represented at the top of the Fig. 8 by the Eric Yu Thesis ( Yu, 1995 ). Therefore, iStar has 43 papers that extend ( Cares et al., 2007;Ingolfo et al., 2013;Islam et al., 2012;Li et al., 2016;Mate et al., 2014;Mendonça et al., 2016;Murukannaiah and Singh, 2014;Siena et al., 2008 andvan der Raadt et al., 2005 ) 7 87,5% 6 Gharib and Giorgini, 2015b;Li et al., 2014;Liaskos et al., 2009;Liaskos et al., 2011 andMouratidis andGiorgini, 2007 ) 6,5 81,25% 16 Ali et al., 2010;Amyot et al., 2010;Bresciani et al., 2004;Cares et al., 2005;Chopra et al., 2010;Elahi et al., 2010;Estrada et al., 2013;Gharib and Giorgini, 2013;Giorgini et al., 2005c;Giorgini et al., 2008;Hayashi et al., 2015;Molina et al., 2010;Montali et al., 2011;Mouratidis et al., 2013 andRios et al., 2016 ) 6 75% 20 Bresciani and Donzelli, 2003;Dalpiaz et al., 2011;De Kinderen and Ma, 2015;Duran et al., 2015;Gharib and Giorgini, 2015a;Guimarães et al., 2015;Guizzardi et al., 2011;Guzman et al., 2016;Horkoff and Yu, 2010;Ingolfo et al., 2014a;Liaskos et al., 2006;Mellado et al., 2014;Mouratidis et al., 2016;Pourshahid et al., 2011;Sánchez et al., 2016;Silva et al., 2011;Teruel et al., 2011 andWang et al., 2016 ) 5,5 68,75% 10 Basak et al., 2016;Crook et al., 2011;Gans et al., 2001;Marosin et al., 2016;Morales et al., 2015;Siena et al., 2012 andVasquez et al., 2013 ) 5 62,5% 18 Danesh and Yu, 2014;Gailly et al., 2008;Gans et al., 2006;Giachetti et al., 2011;Giorgini et al., 2005b;Ingolfo et al., 2014b;Lapouchnian and Lespérance, 2006;Lei et al., 2015;Liu et al., 2003;Morales et al., 2011;Piras et al., 2016;Schulz et al., 2013;Shamsaei et al., 2013;Siena et al., 2009;Sutcliffe, 2006;Sutcliffe, 2011 andZhang et al., 2011 ) 4,5 56,25% 8 R. Ali et al., 2008;Dubois et al., 2011;Ghanavati et al., 2014;Marosin et al., 2014;Mussbacher and Nuttall, 2014;Pimentel et al., 2014 andRashidi-Tabrizi et al., 2013 ) 4 50% 5 Chung, 2006;Franch et al., 2011;Louaqad andEl Mohajir, 2014 ) [ the original proposal of Yu. Two of these are branches that have more extensions, they are GRL (Goal-Oriented Requirement Language) and Tropos . ...
... Several works defined a construct to introduce context in iStar: Franch et al., 2011;Lei et al., 2015;Li et al., 2014 andMurukannaiah andSingh, 2014 ). In papers Ali et al. (2014Ali et al. ( , 2010 and Li et al. (2014 ), the context identification is using the identifier in a square. ...
... Several works defined a construct to introduce context in iStar: Franch et al., 2011;Lei et al., 2015;Li et al., 2014 andMurukannaiah andSingh, 2014 ). In papers Ali et al. (2014Ali et al. ( , 2010 and Li et al. (2014 ), the context identification is using the identifier in a square. In the extension Ali et al. (2009 ), the context representation is made similarly to Ali et al. (2014 ), but this identification is linked to another iStar diagram detailing the associated context. ...
iStar is a general-purpose goal-based modelling language used to model requirements at early and late phases of software development. It has been used in industrial and academic projects. Often the language is extended to incorporate new constructs related to an application area. The language is currently undergoing standardisation, so several studies have focused on the analysis of iStar variations to identify the similarities and defining a core iStar. However, we believe it will continue to be extended and it is important to understand how iStar is extended. This paper contributes to this purpose through the identification and analysis of the existing extensions and its constructs. A Systematic Literature Review was conducted to guide identification and analysis. The results point to 96 papers and 307 constructs proposed. The extensions and constructs were analysed according to well-defined questions in three dimensions: a general analysis; model-based analysis (to characterise the extensions from semantic and syntactic definitions); and a third dimension related to semiotic clarity. The application area targeted by the iStar extensions and their evolutions are presented as results of our analysis. The results point to the need for more complete, consistent and careful development of iStar extensions. The paper concludes with some discussions and future directions for this research field.
... Quality-Based Software Reuse (Leite et al. 2005) is another goal-oriented modeling approach that, in combination with aspect orientation, explicitly addresses the need to apply reusable artifacts in new contexts. A pattern-based approach, combined with contextual goal modeling (Li et al. 2014) has also been suggested. However, both approaches suffer from similar problems, as reuse hierarchies are not taken into account. ...
A fundamental task when reusing software artifacts is to determine the most appropriate artifact for the current reuse context. Goal modeling allows modelers to capture the advantages and disadvantages of reusable candidate artifacts, which in turn helps reason about the most appropriate candidate artifact. However, goal models are rarely used in isolation for the description of an artifact, but are combined with other models that impose additional constraints on the most appropriate candidate. Furthermore, reusable artifacts are assembled into reuse hierarchies to realize an application. This paper presents a novel goal model evaluation mechanism for the selection of the most appropriate candidate, which (i) takes into account additional configuration constraints expressed with feature models and run-time constraints expressed with workflow models that may affect the selection of reusable software artifacts, (ii) considers reuse hierarchies, and (iii) establishes a history of design decisions. Furthermore, a proof-of-concept implementation of the novel evaluation mechanism is discussed.
... 1) Proposing a systematic method to model CAPEC attack patterns as contextual goal models in order to semiautomatically select and apply attack patterns based on system context. The method is line with the one we have applied to security patterns [11], but has been adjusted to accommodate specific concepts in attack patterns. We have pragmatically applied this method to model 102 CAPEC attack patterns, which can be reused for operationalizing attack strategies. ...
... A pattern consists of three primary pattern concepts: Context, Problem, and Solution [14], which specify a particular solution can be applied to solve a problem in certain context. In our previous work, we have mapped such pattern concepts to contextual goal model elements (Table I) to semi-automate selection and application of security patterns [11]. Attack patterns, as a different type of pattern, are specified in the same spirit, but from an attacker's viewpoint, i.e., what an attacker wants to attack (problem), how does the attacker perform the attack (solution). ...
... In this paper, we extract security knowledge from well documented security patterns, specifically the work done by Fernandez et al. [5] and Scandariato et al. [22]. In particular, this paper exclusively focuses on the security mechanism (i.e. the solution) that is provided by each security pattern, while the reason for applying the security mechanism (i.e., the problem) was captured and analyzed in our previous work [15]. As we aim to analyze the impact of security mechanisms on system requirements, we mainly extract the knowledge of security mechanisms from the Solution section that specifies the requirements that need to be satisfied by a security mechanism, rather than the Implementation section that describes detailed design of a security mechanism. ...
... Modeling and Analyzing Security Patterns. Our previous work proposed to seamlessly integrate security patterns into security requirements analysis by modeling security patterns as contextual goal models, which facilitates the context-based selection among alternative security mechanisms [15]. After Table 1: Part of the description of the Virtual Private Network pattern [5] Context: Users scattered in many fixed locations, who need to communicate securely with each other. ...
Context and motivation] Security mechanisms, such as fire-walls and encryption, operationalize security requirements, such as confidentiality and integrity. [Question/problem] Although previous work has pointed out that the application of a security mechanism affects system specifications, there is no systematic approach to describe and analyze this impact. [Principal ideas/results] In this paper, we investigate more than 40 security mechanisms that are well documented in security pattern repositories in order to better understand what they are and how they function. [Contribution] Based on this study, we propose a conceptual model for security mechanisms, and evaluate this model against 20 security mechanisms. Using the conceptual model, we provide a systematic process for analyzing and enforcing security mechanisms on system requirements. We also develop a prototype tool to facilitate the application and evaluation of our approach.
Security patterns encompass security-related issues in secure software system development and operations that often appear in certain contexts. Since the late 1990s, about 500 security patterns have been proposed. Although the technical components are well investigated, the direction, overall picture, and barriers to implementation are not. Here, a systematic literature review of 240 papers is used to devise a taxonomy for security pattern research. Our taxonomy and the survey results should improve communications among practitioners and researchers, standardize the terminology, security patterns; software patterns; systematic literature review (SLR)and increase the effectiveness of security patterns.
