2. Background and Related work
The need to take security requirements into account during system design and modeling has arisen as a result of the security concerns encountered in the connected world. Large corporations have lost millions of dollars due to security breaches, and this cost is rising [18]. According to Khan et al. [4], early security requirements analysis can cut software development and maintenance costs by 12-21%. Previous studies by academia, industry, and standards groups have proposed solutions to these issues [7, 19]. Early capturing of privacy and security requirements is critical to building public trust and promoting secure software development [5].
People around the globe are performing transactions through various channels such as the Internet, ATMs, mobile phone, and email. They make use of software, keeping in mind that it is dependable and trustworthy and that the operations are safe. However, still, due to budget constraints and the demand to deliver software to market quickly, as competition with other brands, many developers treat security as an afterthought, resulting in poor software quality [20].
Mead et al. [21] proposed a method, i.e., Security Quality Requirement Engineering (SQUARE), that elicits and documents security requirements. Goel et al. [22] recommend using Security-Requirements-Elicitation-and-Assessment-Mechanism (SecREAM) to address security vulnerabilities early in software development. According to Mouratidis et al. [23], the ’Secure Tropos Methodology’ can be used to create a unified security protection process that takes into account both the character, purpose, and planning concepts of requirement engineering and the threat, security challenges, and security strategy elements of security engineering. According to Manico [15], OWASP (Security Verification Standard (ASVS) version3.0) is a community effort to provide a framework of security criteria and controls that normalize the functional and nonfunctional security controls needed for designing, creating, and testing modern web applications. The Application Security Verification Standard (ASVS) is a set of requirements or tests used by architects, developers, testers, security professionals, and even users to determine whether or not a given application meets their standards for security [15]. Security requirements identification based on the context of usage, modeling, and risk analysis are the cornerstones of the AEGIS approach proposed by Ivan et al. [24] to build trustworthy systems. Chatterjee et al. [28] discussed ”Secure Requirement Engineering (SRE) in terms of the nonfunctional requirement that elicits a control, constraint, safeguard or countermeasure to avoid or remove security vulnerabilities from requirements, design or code.” The goal of SRE is to ensure the highest level of protection possible by putting into place all of the necessary security measures that will ensure privacy, integrity, and accessibility [25]. SRE is typically carried out at the SDLC’s initial phase, and its successful completion results in a higher-quality software product. The core RE security activities is identification and inception, documentation, elicitation, analysis and negotiation, mapping, verification and validation, prioritizing and management, authentication, and authorization [26].
From the above discussion, we concluded that security must be added to the early stage of the SDLC to make secure software applications. However, there are limited studies conducted on integrating security in the RE phase of the SDLC. Furthermore, we found there is a dire need to study the interrelationship between security best practices in Requirement Engineering (RE) against security risks in the RE phase of the SDLC. To address the research gap, there is a need for an empirical study examining security practices in RE to assist GSD organizations in securing software development processes.