Analysis of Security Requirements Engineering : Towards a Comprehensive Approach

Software’s security depends greatly on how a system was designed, so it’s very important to capture security requirements at the requirements engineering phase. Previous research proposes different approaches, but each is looking at the same problem from a different perspective such as the user, the threat, or the goal perspective. This creates huge gaps between them in terms of the used terminology and the steps followed to obtain security requirements. This research aims to define an approach as comprehensive as possible, incorporating the strengths and best practices found in existing approaches, and filling the gaps between them. To achieve that, relevant literature reviews were studied and primary approaches were compared to find their common and divergent traits. To guarantee comprehensiveness, a documented comparison process was followed. The outline of our approach was derived from this comparison. As a result, it reconciles different perspectives to security requirements engineering by including: the identification of stakeholders, assets and goals, and tracing them later to the elicited requirements, performing risk assessment in conformity with standards and performing requirements validation. It also includes the use of modeling artifacts to describe threats, risks or requirements, and defines a common terminology. Keywords—Security requirements; Requirements engineering; Security standards; Comparison; Risk assessment


INTRODUCTION
Security needs have evolved with the evolution of information systems (IS).IS are more and more open and interconnected, which makes securing these IS more necessary and more challenging.But, in the Software Development Life Cycle (SDLC), security issues are often addressed at the design phase at best, or at maintenance phase at worst by fixing detected vulnerabilities.As reported in this paper [1], finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.A model developed by MIT, whose objective is to prove the return of investment on secure software development, showed that the earliest the security is addressed, the highest the benefit (21%) [2].Thus, it is critical to address security issues at the earliest phase.This is the reason why OWASP recommends focusing a big part of security flaws detecting efforts on the requirements engineering phase and the design phase as shown in fig. 1 [3].Requirements engineering is the very first step to make any software.It is usually applied to functional requirements, and can be extended to quality and security requirements, traditionally considered non-functional.By integrating security requirements into requirements engineering, a big improvement can be made in term of security vulnerabilities, software maintenance efforts and development costs.Many initiatives propose different approaches to security requirements engineering (SRE), along with literature reviews of these approaches.In the first section, these works will be presented.The term "approach" will be used to refer to any method, framework, etc. which sets out clear steps to obtain security requirements.In the second section, the selection and comparison process followed for featured SRE approached will be explained.Then, approaches will be compared according to the predefined criteria.In the final section, a common terminology will be defined for the concepts used by the approaches.Then the outline of our comprehensive approach to SRE will be presented, along with its desired qualities.To achieve our aim, relevant literature reviews were studied and primary approaches were compared to find their common and divergent traits.This section presents the reviews and approaches featured in our research.These approaches were selected by applying the selection & comparison process detailed in the next section.

A. Reviews 1) Survey and analysis on Security Requirements
Engineering: [4] It is the most recent detailed analysis on the subject.They discuss various types of security requirements with given examples, stretching the importance of considering security requirements as functional requirements.They compare approach activities to identify the weaknesses of www.ijacsa.thesai.orgeach.The choice of an approach over another depends on covered activities and existing SW development methods in an organization.
2) A Comparison of SRE methods: [5] proposed a conceptual framework against which approaches can be evaluated.They made a commendable effort to categorize existing approaches: Multi-view approaches, Goal-based approaches … 3) A systematic review of security requirements engineering : [6]A systematic, thorough review which aims to supply researchers with a summary of all the existing information about security requirements in a thorough and unbiased manner, providing a background in which to appropriately position new research.
4) Security Requirements for the Rest of Us -A Survey : [7]This survey highlights mainstream approaches.It focuses on the importance of simplifying SRE methods since a lightweight method is more likely to be adopted than a complex one.It also stretches the importance of scholar education of developers and software engineers on the SRE discipline. Construct satisfaction arguments: show that the system can satisfy the security requirements.

2) KAOS anti-models:
To elaborate security requirements, Van Lamsweerde suggests using KAOS by constructing intentional anti-models.KAOS is a Goal Oriented Method for requirements engineering.A goal is a desired property of the IS to be, that has been expressed by a stakeholder.The satisfaction of this goal will depend on successful cooperation between all agents of the IS.KAOS documents requirements using a goal tree, with strategic goals as the root and IS requirements as leafs.Security requirements using anti-models are elaborated in 3 steps.First, model the security goals.Then, derive from the former model an anti-model based on threats.Finally, derive from both former models countermeasures and define the security requirements.A requirement is defined as a terminal goal under the responsibility of an agent in the software.
3) MOSRE: The aim of the Model Oriented Security Requirements Engineering approach [9] is the use of models (App's use cases, misuse cases, …) to make the traceability and analysis of requirements easier.It's tailored for web applications.The particularity to MOSRE is that it encompasses identification of goals for the whole IS, the elicitation and the modeling of non-security requirements (functional or non-functional) before dealing with the security requirements.It is thus a method that can be applied to the whole requirements engineering phase, with a special focus on security.MOSRE   Negotiation and validation of requirements 4) MSRA: The focus of the MSRA (Multilateral security requirements analysis) approach is to identify and analyze security requirements from the multiple views of stakeholders [10].Security requirements result from the reconciliation of multilateral security goals, which are selected from a rich taxonomy.Security goals, and later requirements, contain the attributes "stakeholders" who have an interest in the requirement, "counter-stakeholders" towards whom a requirement is stated, and other attributes such as "owner", "degree of agreement" between stakeholders, the "information" to be protected by the requirement, the security "goal" that the requirement achieves… A singularity of MSRA is that, when resolving conflicts between requirements, it takes into account both functional (assumed to be extracted prior to applying MSRA) and security goals.There is a variant of MSRA, the Confidentiality Requirements Elicitation and Engineering (CREE) approach, which focuses only on confidentiality requirements and how they can be formalized.The steps followed by the MSRA are:  Identify stakeholders  Identify episodes: Episodes are similar to scenarios, but are of a lower granularity.They are used to partition the security goals and are later useful in identifying conflicts between multiple security goals.www.ijacsa.thesai.org Elaborate security goals: Identify and describe the security goals of the different stakeholders for each of the episodes.
 Identify facts and assumptions: These are the properties of the environment that are relevant for stating security goals.
 Refine stakeholder views on episodes: Elaborate the stakeholder views taking facts, assumptions, and the relationships between episodes into account.
 Reconcile security goals: Identify conflicts between security goals, find compromises between conflicting goals, and establish a consistent set of security system requirements.
 Reconcile security and functional requirements: Trade functionality for security and vice versa in case of conflicting functional and security requirements.

5) Secure TROPOS:
Tropos is a requirements-driven software development methodology.It's based on the i* framework, an agent-oriented modeling framework.While Tropos guides the development of agent-based systems through all phases of the SDLC, it is very focused on the requirements engineering phase.Secure Tropos [11] is based on the concepts of social relationships for defining the obligations of actors to other actors : functional dependency, ownership, provisioning, trust, and delegation of permission.Secure Tropos steps are:  Early requirements phase: studies the organizational setting of the future system o Actor diagram : identifying stakeholders and trust relationships between them (Trust modeling, Functional Modeling and Trust Management implementation) o Goal diagrams for each actor  Late requirements phase: describes the future system within its operational environment, along with relevant functions and qualities, using further actor and goal diagrams.
 Requirements analysis : o Expressing system requirements in form of actors' properties and relations o validation of both functional and security requirements Secure Tropos has been applied to the Italian data protection legislation compliance [12].

6) Holistic security requirements engineering:
Holistic security requirements engineering [13] was conceived to overcome the shortcomings of other approaches to SRE.This approach, aimed at electronic commerce systems, defines risks, business processes and stakeholder & environmental demands as sources of security requirements.This leads to holistic security requirements, defined as "a need or restriction from a user, a stakeholder or the environment related to the goal to improve the system security".
The approach is described by this biphasic process with the following activities: This approach had been extended to specifically treat privacy (P-SQUARE) and acquisition (A-SQUARE).[15] is a process centered on the security evaluation standard Common Criteria [16] and based on the notion of reuse.It deals with security requirements in a systematic and intuitive way.It provides a security resources repository and integrates the Common Criteria into the software lifecycle, so that it unifies the concepts of requirements engineering and security engineering.In order to support this approach, many concepts and techniques are used: a security resources repository (with www.ijacsa.thesai.orgassets, threats, requirements, etc), misuse cases, threat/attack trees, and security uses cases.SREP has been developed by taking into account the standard ISO/IEC 27002 [17].

9) STS:
Going from the statement that software operates within the context of larger socio-technical systems, STS is an approach for modeling and reasoning about security requirements in such systems [18].Security requirements are specified, via the STS-ml requirements modeling language, as contracts that constrain the interactions among the actors.The requirements models of STS-ml have a formal semantics which enables automated reasoning for detecting possible conflicts among security requirements.STS was applied to an e-Government system for tax collection.
STS steps are:  Model system components and interaction with STSml language o Social view for stakeholders o Information view o Authorizations view  Use the models to specify security requirements as constraints on the interactions.Security requirements are specified in the STS-ml language.
 Use the automated reasoning to detect conflicts

III. COMPARISON OF SRE APPROACHES
This section presents the process followed to select and compare the approaches featured in our research and shows the results of the comparison.

A. Comparison Process
To guarantee the comprehensiveness of our approach, a documented selection and comparison process was followed (see fig. 2).This process is inspired by an evaluation method for engineering approaches in the secure SDLC named SecEval [19].This distinguishes our work from the previous reviews as they compare only a certain set of approaches, without explaining the inclusion or exclusion criteria.Documenting our process makes this comparison reproducible for future research.

1) Sources :
The aforementioned reviews were a very rich source.To complete the information gathered, we queried different scientific databases to find novel research in the area.This way, we obtained other approaches that have not yet been featured in any of the previous reviews, such as MOSRE and STS.Other sources were: Sciencedirect, ResearchGate and GoogleScholar.
2) Selection criteria: Selection criteria were applied on the gathered research.The first criterion is if the proposed approach is focused on the early phase of the development lifecycle.Indeed, many approaches go straight to the design phase by proposing modeling approaches, without specifying how to extract those requirements in the first place.Others propose activities to enhance security through the whole Software Development Life Cycle such as CLASP [20] and Microsoft SDL [21].To have a precise scope, only the methods that focus on the requirements engineering phase were kept.The second criterion is the novelty.Chosen approaches have been referenced in the years 2008 and up.The third criterion is that chosen approaches offer a clear process or clear steps about how to extract the security requirements, and not just general guidelines about security requirements, or their management.
3) Information extraction: Once the final approaches were selected, the following information was extracted to be used as comparison criteria.
 Steps: What are the clear steps followed to obtain security requirements  Security Objectives: Whether the approach addresses all security objectives (Confidentiality, Integrity, Availability, …) or focuses on a single one  Tool / Notation support: Whether there is a tool or a notation developed to support the use of the approach  Use / Application: Whether the approach had been applied to a case study or a real IS. Compliance with security standards: Whether the approach is compliant or inspired by any security standard  Reusability of requirements: Whether the approach promotes the reuse of obtained requirements www.ijacsa.thesai.org Use of ontology/taxonomy: Whether the approach uses an existing ontology ot taxonomy to define the approach steps and to define the security requirements  Domain specific: Whether the approach is dedicated to a certain type of software (Web applications, Mobile, E-Gov, etc.)

B. Comparison Results:
Tab. 1 summarizes the steps found in each approach, and gives a synthetic view about the most and the least common steps.No single approach includes these steps all at once.First, we can see that "Identifying vulnerabilities/threats" and "Identifying security goals" are the most common steps since we can't derive requirements without establishing goals, and it's important to know a system's vulnerabilities and threats to be able to secure it.Then, other steps are also quite persistent such as "Identifying stakeholders", "Creating security artifacts" and "Validation of requirements".Identifying stakeholders is a way to make sure that all the systems goals have been mapped, since different stakeholders will have different views of the systems, and thus different goals.Creating security artifacts is important as it helps clarify the requirements by incorporating artifacts such as attack trees and misuse cases.It will also help designers and developers during later phases of the project.As for Requirements validation, the goal of it is to make sure that all goals have been covered by the elicited requirements, with no conflicts between them.Finally, some steps are often neglected even if they're very important, such as "Risk assessment" and "Repository enhancement".Risk assessment builds on the identified threats and vulnerabilities to identify analyze and evaluate risks by choosing for example the risks to accept and those to mitigate.Assessing risks leads to thinking about security controls, which could lead to new requirements.Keeping and enhancing a repository is a way to promote de reuse of requirements.Such a repository can be used to validate the obtained requirements and identify new ones.
As for the characteristics comparison, we present in tab. 2 the results for each approach regarding to the aforementioned comparison criteria.First thing we deduce is that there is no approach that fulfills all criteria.Apart from Secure Tropos, all approaches try to cover most security objectives, especially the CIA triad (Confidentiality, Integrity, and Availability).Some approaches are defined from the beginning to better suit certain systems such as Web Applications that are more and more used to replace custom applications.When applied, they are aimed at highly data sensitive systems such as e-gov, e-commerce and e-health.As for artifacts and notation, the most used are UML based (misuse cases, UMLSec [22]) and attack trees.Some approaches have developed their own notation system, or even a tool to create their artifacts and support their approach.The conformity to security standards is quite present, especially for the approaches that include risk assessment.Common security standards used are the ISO 27000 family of standards [23] and the SSE-CMM (Systems Security Engineering-Capability Maturity Model) [24].For the purpose of better understanding of requirements, some approaches propose their own format in which requirements are documented.The rarest characteristics were the use of a taxonomy or ontology to build the approach, and the existence of a tool supporting the approach.

A. Common Terminology:
From studying each approach, we can identify a set of concepts that are consistent through most approaches: Stakeholder, Asset, Risk, etc… These concepts are drawn from both the fields of security and requirements engineering.Tab. 3 below offers a definition of these concepts to establish a common terminology based on the ISO/IEC 27000:2016 vocabulary [25].Some existing papers offer detailed taxonomies [26]and facilitate applying SRE approaches.This is the terminology that we will base our approach on.

B. Proposed Activities
Based on the previous section, we can give guidelines about a new comprehensive approach that takes into account the strengths and weaknesses of studied approaches.We will try to avoid being too specific about a domain or any other specificity that might limit the use of our approach.Still, the new approach has to include important concepts and techniques such as: identification of stakeholders, identification of assets and threats, risk assessment and reuse of requirements.It also has to follow general guidelines of requirements engineering by documenting, tracing and validating requirements.These are the activities that we propose for our approach:  If those activities are followed correctly, our approach would have the following qualities:  Environment reconnaissance: The more complex the IS, the more important it is to identify the stakeholders and the assets.Elicited security requirements will have to be traced all the way back to the related assets and related stakeholders.
 Risk assessment: The finality of securing a system is to be prepared against all risks.Thus, it is important for our approach to identify all vulnerabilities and threats, to enable a thorough risk assessment.www.ijacsa.thesai.org Ease of use: It should be detailed and documented enough to be applied easily.Complicated and time consuming steps (ex: modeling artifacts) should be simplified and kept to a minimum.

V. CONCLUSION & PERSPECTIVES
Our aim was to define the outline of a comprehensive approach to security requirements engineering.To achieve that, a thorough analysis of existing SRE approaches was conducted.The outline, along with a common terminology, was drawn from this analysis.The first contribution of our research is that it can be used by fellow researchers or practitioners to position themselves between heterogeneous approaches.Our comparison criteria and common terminology allows a better understanding of each approach, and can help choose the most appropriate approach for a certain need.The second contribution is our comprehensive approach that conciliates between the different trends to security requirements engineering: goal oriented, risk analysis oriented and multilateral.As such, it distinguishes itself by being faithful to the fundamentals of requirements engineering, to security standards and by facilitating the use of security requirements in later phases of the SDLC through requirements formatting and security enhanced system artifacts.When eliciting requirements, regardless of the approach used, security requirements shouldn't be an afterthought, but an indivisible part of requirements engineering for the system as a whole.Security requirements should be confronted with other functional, quality or performance requirements for further validation and conflict resolution so they would be incorporated in the system's design.
Our plans for future work are to fully develop our approach following the described outline.We would document the inputs, activities and outputs of each step, describe the artifacts to be created, and develop a format for security requirements.We would also explain how our approach integrates with security in later phases of the SDLC.We plan to validate our approach by applying it to a concrete security sensitive system, and measure security metrics to improve its efficiency.

Stakeholder
Person or organization that can affect, be affected by, or perceive themselves to be affected by a decision or activity.Some approaches include other systems that have an interest in the IS.

Asset
Anything that has value to the organization, its business operations and their continuity, including Information resources that support the organization's mission (Data).

Information, Resource, Object
Goal A Security objective that must be achieved by the system to be Objective

Fig. 1 .
Fig. 1.Recommended proportions of Test Effort in SDLC II.RELATED WORK

Fig. 2 .
Fig. 2. Selection & Comparison process  Includes modeling activities (design): Whether the approach includes high level design activities, taking into account the obtained security requirements.

1 )
[8]F : Security Requirements Framework by Haley et al.[8]is a mix between engineering requirements and security requirements.It's iterative as it goes back and forth between modeling and requirements engineering.SREF follows 4 steps:  Identify functional requirements  Identify security goals o Identify assets o Generate threat description o Apply management principles (separation of duties, functions, ..)  Identify security requirements: constraints on one or more security goal.The security requirements are denoted textually.
Phase I: Preparation, aims to gather requirements from each of the sources.

TABLE III .
COMMON TERMINOLOGY Easy and faithful transition from requirements engineering phase to design phase: Use of modeling artifacts to describe threats, risks and requirements.Use of existing risk management standard and Bodies Of knowledge (ISO 27002, ISO 27005, EBIOS, BSI, etc.) for threats, risk assessment and security goals.