Reusable knowledge in security requirements engineering: a systematic mapping study

Abstract

International audienceSecurity is a concern that must be taken into consideration starting from the early stages of system development. Over the last two decades, researchers and engineers have developed a considerable number of methods for security requirements engineering. Some of them rely on the (re)use of security knowledge. Despite some existing surveys about security requirements engineering , there is not yet any reference for researchers and practitioners that presents in a systematic way the existing proposals, techniques, and tools related to security knowledge reuse in security requirements engineering. The aim of this paper is to fill this gap by looking into drawing a picture of the literature on knowledge and reuse in security requirements engineering. The questions we address are related to methods, techniques, modeling frameworks, and tools for and by reuse in security requirements engineering. We address these questions through a systematic mapping study. The mapping study was a literature review conducted with the goal of identifying, analyzing, and categorizing state-of-the-art research on our topic. This mapping study analyzes more than thirty approaches, covering 20 years of research in security requirements engineering. The contributions can be summarized as follows: (1) A framework was defined for analyzing and comparing the different proposals as well as categorizing future contributions related to knowledge reuse and security requirements engineering; (2) the different forms of knowledge representation and reuse were identified; and (3) previous surveys were updated. We conclude that most methods should introduce more reusable knowledge to manage security requirements

Security attack analysis using attack patterns

“…However, as pointed out by Souag et al, security knowledge is hard to acquire for software designers in reality [26]. Without bridging the knowledge gap, the assumptions made in the above approaches become unrealistic, preventing the real adaption of those attack analysis approaches.…”

“…Souag et al survey reusable knowledge-based security requirements engineering approaches over the last 20 years, which shows that 9 out of 95 surveyed papers represent reusable knowledge in the form of patterns (other forms include catalogs, taxonomies, etc.) [26]. Although patterns can be reused in a comparatively easy manner, Araujo et al have pointed out that analysts need first to have a thorough understanding of available patterns in order correctly select and apply them [33].…”

Using the AMAN-DA method to generate security requirements: a case study in the maritime domain

“…The reader may refer to the tutorial in [42] to know about all the concepts and relations used in Secure Tropos. The choice of Secure Tropos was motivated by the fact that it is one of the richer modeling frameworks in terms of concepts that are used to model security requirements according to a recent systematic mapping study [11] on the subject. However, one needs to be "knowledgeable" about security and security requirements when using Secure Tropos, which is not always the case as reported in the introduction.…”

“…The security goals being not enough to generate security requirements, two ontologies (security and domain ones) were used as a source of knowledge to discover threats, vulnerabilities, security requirements and their actors, organizational goals, and other domain specific concepts. Acknowledging the small number of publications tackling this issue and providing an evaluation of proposals on real cases [11], we felt the motivation and necessity to undertake this empirical research.…”

A Goal based Framework by adopting SQUARE Process for Privacy and Security Requirement Engineering

“…These are considering as technical choice made during implementation [1]. The different between security and privacy is that threats to individual privacy often rise from authorized users of the system rather than from unauthorized one [2].…”