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.