Article Preview
Top1. Introduction
Today, security is considered as a key requirement in almost all systems. Implementation and architecting software systems with the incorporation of security considerations would be a cost-effective approach to preventive software maintenance. Security patterns were a programming rethinking approach so that security and safety features get embedded within the system at earlier stages of its development lifecycle. Patterns were initially proposed to outline recurring software engineering problems and solutions with a view to be used during software design phase (Vlissides, Helm, Johnson, & Gamma, 1995). It is also commonly recognised that there is a need for a pattern language to categorise security problems in software designs (Fernandez & Rouyi, 2001; Ruiz, Arjona, Mana, & Rudolph, 2017). Moreover, there have been further attempts to formalise and develop security patterns catalogues (Schumacher et al., 2013; Hamid, Gurgens, & Fuchs, 2016). These catalogues have gathered common solutions to known security problems using systems engineering and software development techniques. Identification and correction of errors early in the development lifecycle would cost less than fixing accumulated errors in design and implementation (Menzies, Nichols, Shull, & Layman, 2017). For security problems, therefore, one may ask a relevant question “Can we detect security problems and even resolve them early before it is too late?” This question has led to active research on the representation and analysis of security requirements (Liu, Yu, & Mylopoulos, 2003; Haley, Laney, Moffett, & Nuseibeh, 2008; Giorgini, Massacci, Mylopoulos, & Zannone, 2005; Souag, Mazo, Salinesi, & Comyn-Wattiau, 2016). There are various approaches for eliciting security requirements of a system-to-be. Abe, Hayashi, & Saeki (2015) propose an elicitation approach by which security functions are extracted from target documents, in line with the international standard of Common Criteria - ISO/IEC 15408. Riaz, Stallings, Singh, Slankas, & Williams (2016) have developed a framework within which security patterns are collected and security goals are identified. Work in the domain of this research assumes that security requirements can be elicited by arguing thoroughly about vulnerability in existing requirements models, such as trust assumptions (Haley, Robin, Moffett, & Nuseibeh, 2004), anti-goals (Van Lamsweerde, 2004; Li, Paja, Mylopoulos, Horkoff, & Beckers, 2016), misuse cases (Sindre & Opdahl, 2005; Ikram, Siddiqui, & Khan, 2014), abuse frames (Lin, Nuseibeh, Ince, Jackson, & Moffett, 2003), risk analysis (Massacci, Prest, & Zannone, 2005; Asnar et al., 2007; Souag et al., 2016), etc. Yet little has been done to suggest systematic changes in requirements models to resolve these vulnerabilities. Partly due to the fact that it is impossible to detect and resolve once-for-all the vulnerabilities, especially when not all problematic trust assumptions or anti-goals may be detected. Therefore, an appropriate approach would be helpful to slot in new security patterns. Capturing lessons learnt from the past as well-known security patterns, one may still need to enforce them to a requirements model for a new software project. In this paper, we have represented security patterns formally on basis of existing requirements modelling languages, such that an analysis tool can be developed to detect and resolve security problems in the modelled requirements. For such automated analysis, it is a reasonable assumption for stakeholder requirements to be modelled using a formal language: once requirements have been modelled as such, the tool could guarantee all instances of the security pattern can be detected and necessary changes can be suggested. To illustrate, we tried a single security pattern for recurring problems in role-based access control. Despite the possibility of selecting a different formal requirement modelling language for defining a security pattern, we selected elements from the goal oriented requirements modelling language i*/Tropos (Yu, 1996; Bresciani, Perini, Giorgini, Giunchiglia, & Mylopoulos, 2004) for two reasons. One, it is widely used in early requirements engineering which leads to many published models in the literature. Second, we have developed a tool support using the Eclipse Modelling Framework, which enables the techniques presented here. Our main contribution is to show that such formally defined security pattern can be directly used to detect and resolve the security problem on requirements models published in the literature. The key techniques used are model-driven query and transformation (Graaf, Weber, & Van Deursen, 2008) and model-driven development of requirements models (Budinsky, Brodsky, & Merks, 2003), both are integrated in our requirements engineering tools. The remainder of the paper is organised as follows. Section 2 explains key techniques used, including a language for modelling stakeholder requirements, model-driven software development and model-driven transformations; Section 3 briefly outlines access control mechanisms and types. The following section discusses the enforcing of a role-based access control pattern, and reviews several applications of the tool. Sections 5 and 6 provide an overview of related works and applications followed by a summary of key points and potential further work.