In today’s software delivery, the Agile methodology is one of the most widely adopted approaches. Agile has several variants such as Scrum, XP, Kanban and Scrum Bann. The latest additions for large organizations are the Spotify and the Scaled Agile Framework (SAFe) approaches.1 The number of data breaches is still a common concern across the globe2 despite best practices and proven techniques supported in several application delivery methodologies. There are two categories of vulnerabilities: technical and logical.
Vulnerabilities discovered from implementation until the go-live are categorized as technical vulnerabilities; an example is cross-site scripting. Technical vulnerabilities are circumvented to a certain extent by adopting industry or domain- specific best practices, static code analysis and security testing suites.
Logical vulnerabilities are security gaps created from improper business logic—not from coding. Logical vulnerabilities can be exploited by understanding how an application works and simulating the business flow.
There is a lack of in-depth research on addressing logical vulnerabilities at the earliest software development life cycle (SDLC) phase.
By linking logical vulnerability aspects in the application development life cycle, a deeper view of the data breach and its causes can be understood. This discussion builds upon vulnerability injection points during the requirement phase, particularly focusing on logical requirements and addressing the tasks of identifying vulnerable and nonvulnerable requirements, quality gauging of security requirements and eliminating vulnerabilities in security requirements by adopting design thinking and binarization.
APPLYING DESIGN THINKING AND BINARIZATION CAN HELP IDENTIFY, EXTRACT AND ELIMINATE VULNERABILITIES IN LOGICAL SECURITY REQUIREMENTS.
The proposed scheme of using a security requirement attribute (SRA) template is effective and can be used with existing development processes in software delivery methodologies.
Background
Data breach incidents are becoming more frequent and larger in scope; recent data breaches in 2017, 2018 and 2019 affected various sectors ranging from healthcare, education, government and technology to financial.3 The top reasons for the increase in data breach incidents are listed in figure 1.4 Data breach details are sourced from the Common Vulnerabilities and Exposures (CVE) database5 and the US National Vulnerability Database (NVD).6 ,7
Research Methodology
The domains considered in this research are manufacturing and banking (figure 2). The projects chosen are application software development using the Agile methodology (SAFe and Spotify delivery methodology, respectively) with diverse technology platforms. These projects were studied from their inception until post-live in a group of Capability Maturity Model (CMM)-5 organizations.
The following techniques were used in this research:
- Design thinking—Helps identify the presence or absence of SRAs at the atomic level.8
- Binarization—The concept of a security requirement template was found in the research and can be used in a quantifiable model based on the binarization approach.
Experiment Materials and Methods
Figure 3 illustrates the logical vulnerabilities of the Shopping Cart application.
Figure 4 illustrates the logical vulnerability of an example banking application.
When one considers figure 3, although the security requirement is the prime contributor and origin of logical vulnerabilities, these vulnerabilities can have an overwhelming effect on an entire application. The majority of vulnerabilities are created during the requirement definition phase.9 Vulnerabilities are often not detected at the source level. If they are detected at the source level, it can save money and effort and improve the quality of security.
The cost of fixing a vulnerability grows with each stage of application development. Applying design thinking and binarization can help identify, extract and eliminate vulnerabilities in logical security requirements.
To security requirements as a vector of attributes called SRAs, design thinking is applied to locate the presence of these attributes in the SR. Design thinking is a human-centered, creative, iterative and practical approach to solving complex problems and finding ultimate solutions.10 Design thinking can be used for products, services, processes and physical locations—anything that needs to be optimized for human interaction. Applying design thinking to security requirements helps identify the presence or absence of SRAs. Binarization converts the attributes of data both present and absent to zero or one. Vulnerable and nonvulnerable security requirements are determined based on binary values.
Experimentation Setup
This research leverages functional security replacements from project candidates through DevOps platforms such as Confluence Wiki to focus on early prevention of vulnerability injection, which, in this case, is at the requirement phase. A banking application and a customer login module built using Java technology were chosen. This project was at the inception phase when experiments were started. Three use cases related to security replacements from this module have been depicted to demonstrate logical vulnerability. The prime contribution of this experiment is innovating the concept of SRAs in line with design-thinking principles.
The proposed approach has five stages:
- Stage 1: SRA
- Stage 2: SRA template
- Stage 3: Design thinking to extract and identify SRA
- Stage 4: Binarization and vulnerability detection
- Stage 5: Determining vulnerable and nonvulnerable security requirements
Stage 1: Security Requirement Analysis
Security requirements define an application’s security needs in natural language and produce a list of specific security characteristics that define the security needs accurately. Not all SRAs have the same priority, objective, functionality and relevance to an application. SRAs are divided into primary, precise and basic categories.
- Primary SRA—Represents the application’s core security expectations, such as meeting with compliance and project security objectives
- Precise SRA—Represents the specific functionality of security requirements. An example includes the availability, authorization and integrity of security.
- Basic SRA—Represents the mandatory general characteristics, such as clarity, unambiguity, completeness and other relevant attributes
Framing the list of SRAs relies on vital factors such as application complexity, application domain, application functionality and prevailing security threats. Considering this list of factors, figure 5 illustrates the security requirements for a banking domain.
Stage 2: SRA Template
Because security requirements must be verified against SRAs, a template is used to organize the process. Figure 5 represents the format of a template for a banking application. Here SR = {SR1, SR2, SR3... SRi} is the set of security requirements for the banking application. Figure 6 identifies the SRAs, which are non-exhaustive and domain/technology specific.
Figure 7 provides a template for the SRA evaluation.
First, the results have been computed for primary, precise and basic categories identified as Rk, Rp and Rb. Based on these results, the total evaluation result (R) has been computed to facilitate the location of missing attributes.
Stage 3: Design Thinking to Extract and Identify SRAs
Design thinking focuses on the problem of experience. Figure 8 illustrates the design thinking principles, and figure 9 explains a design thinking execution plan.
As part of the research, a modeling approach was created similar to binary tree representation such that application requirement flow is visually represented and the key requirement attributes are mapped and labeled. This visual analysis suite represents the requirement graphically in terms of group of attributes and explores the presence or absence of certain qualitative attributes.
Design Principle 1: Explore
Explore is the first principle of design thinking methodology. In this stage, the details of the security requirements are examined from the perspective of the application. As shown in figure 2, fourth project P4 from a banking domain built using Java technology was chosen. The application was designed to perform the following functions:
Application: Online Banking; The Module Under Study: Customer Login
- Prevent improper disclosure and unauthorized transactions of
- Prevent improper disclosure of
- Prevent unauthorized transactions from being entered into the computer
Design Principle 2: Define
The security requirements for the banking application’s login module are:
- SR1—The banking application should respond to the queries from users within three seconds after
- SR2—The application shall have the capability to disable an identifier automatically if it remains
- SR3—The system shall have the ability to re- authenticate the user during an active
The strategies of the Define principle are applied to all three security requirements.
Analysis reveals that SR1 satisfies the entire SRA. SR2 suffers from vulnerabilities. It is unclear, ambiguous, nontestable and an incomplete functional security requirement. SR3 belongs to the category of authentication. Analysis reveals that the statement does not satisfy any attribute except meeting with objective and compliance.
Design Principle 3: Incubate
The aim of this phase is to convert the textual results of the security requirement analysis from the previous phase into a diagrammatic representation. Analysis results of SR2 are shown in figure 10.
Figure 10 portrays the meaning and intended role of SR2 including the association with compliance and objectives of the application. The details obtained in this phase are passed to the Ideate stage for constructing the solution.
Design Principle 4: Ideate
The goal of this phase is to produce an innovative approach to represent the presence and absence of attributes. A visual analysis suite to identify the presence or absence of SRA by two buttons (yes and no) is conceptualized in figure 11.
Design Principle 5: Implement
The presence of an attribute is indicated by activating the yes (Y) button and absence by the no (N) button. Figure 12 illustrates the evaluation results.
Figure 13 illustrates how an SR2 is implemented using the analysis suite.
From figure 12, it can be verified that SR2 possesses only primary attributes; basic and precise category attributes are absent. This forms the basis for representing the results of the evaluation.
Design Principle 6: Evaluate
Evaluate is the final phase of the design principle. The focus of this phase is on tabulating the results of the analysis through an evaluation template (figure 13). The analysis results of SR2, from the previous stage, are tabulated in the template. If the attribute is present, it is indicated by the symbol Y, and if it is absent, it is indicated by the symbol N. The same process is followed for SR1 and SR3.
Figure 14 illustrates that SR1 possesses all the attributes and SR2 and SR3 do not possess the required SRAs. These results help identify the vulnerable and nonvulnerable security requirements.
Stage 4: Binarization and Vulnerability Detection
Binarization is a process of transforming real-valued data into a binary variable that has only two states: either zero or one. The binarization concept is applied here to discover the vulnerabilities in an SR. The procedure is explained in the following steps:
- Convert the entries to binary form by substituting the numerical value one for Y and zero for The binarized form of the evaluation is shown in figure 14.
- Compute the result of binarization for the Primary, Precise and Basic categories of SRA separately. It is enough if the security requirement possesses any one attribute in the Precise category. However, in the Basic and Primary categories, the security requirement must possess all the attributes. Hence, the result is computed by taking the conjugate of individual binary variables for Basic and Primary categories represented by notation Rb and Rk, respectively.
For the Precise category, the result of binarization is calculated by taking the disjunction of variables and is represented by notation Rp. Mathematically, Rk={K1 ɅK2ɅK3… Kn}; Rb ={B1ɅB2ɅB3…ɅBn}; Rp ={P1 V P2 V P3..VPn}. The Precise category SRA is related to the security functionality of the application. The application has distinct categories of security functionality. The security requirement represents any one or at the most more than one, but never all the functionalities of the application. Consequently, any security requirement can possess any one attribute or, in some special cases, more than one but never all the attributes of a Precise category. Hence, the disjunction of variables is the optimum way to verify the presence of the Precise category SRA.
-
Compute the result of binarization by taking the conjugate of individual category results Rp, Rb and Rk. Mathematically, R={RkɅ RpɅ Rb}. Value one in column R indicates the presence of all attributes and designates the corresponding security requirement as nonvulnerable. The value zero in the R column indicates the absence of a required attribute and designates the security requirement as vulnerable. Results are displayed in figure 14.
From figure 14, it is found that SR1 is nonvulnerable; SR2 and SR3 are vulnerable requirements. Thus, by applying the design thinking principles and binarization, detecting vulnerabilities in Security requirements is possible.
Discussion
The percentage of vulnerable security requirements for the given application provides a gauge of the application’s security quality. Security quality grading is subject to an application’s domain, complexity, functionality and security needs. A sample gauge of security quality in security requirements for online banking and shopping cart applications were explored in this research.
Vulnerabilities are in logical form hidden in security requirements statements. Figure 15 defines the security requirements quality gauge.
Applying the SRA concept and SRA template efficiently converts the SRAs to an objective form, which provides an objective measurement of security in the requirement phase.
THE BINARIZATION CONCEPT IS APPLIED HERE TO DISCOVER THE VULNERABILITIES IN AN SR.
Every vulnerable security requirement can be converted into a nonvulnerable security requirement by substituting the missing attributes. Figure 16 shows the correction to vulnerable security requirements.
Considering the SR2 previously noted, “The application shall have the capability to disable automatically an identifier if it remains inactive for a specific period after logging into the portal and send email.”
Using the SRA adoption steps illustrated previously, a functional requirement is made to undergo elicitation iteratively to uncover vulnerabilities in SR2. Corrections are applied to SR2 to eliminate the flaws. The improvised SR2 can be restated as: Followed by successive logging into bank portal, if user remains inactive more than three minutes, disable user login session and send an email to bank and to customer regarding disabling login session, due to inactive transaction.
Investigating the readdressed SR2 portrays that it has all the qualities to be declared as a nonvulnerable security requirement. This illustrates that every vulnerable security requirement can be changed into a nonvulnerable security requirement.
Conclusion
A practical and rigorous approach to detect vulnerabilities in security requirements and to classify them as vulnerable or nonvulnerable security requirements is recommended. The prime milestones of vulnerability detection are:
- SRAs
- A template of SRA
- Design thinking
- Binarization
The SRA concept highlights the set of essential security attributes to uphold the desired level of security in applications. Viewing security requirements as a result of attributes provides an objective measurement of security in the requirements level. Information on the absence of SRA facilitates continuous improvement in defining security requirements and business analysis. The design thinking process identifies the flaws in security requirements through visual diagrams. Binarization illustrates the presence or absence of attributes in a digitized form.
Detecting and correcting vulnerabilities in security requirements avoids possible vulnerabilities in the application and enhances the quality of application security. This ensures defining security quality in the requirement stage. The statement “Security cannot be assured, but can be pushed” can be actualized through this process of vulnerability detection.
The SRA template can be used with existing development processes and adapt to the software delivery methodologies’ needs.
The nuance is then in the choices made, which are the result of interpreting the impact and acceptable risk and the associated costs and efforts.
VIEWING SECURITY REQUIREMENTS AS A RESULT OF ATTRIBUTES PROVIDES AN OBJECTIVE MEASUREMENT OF SECURITY IN THE REQUIREMENTS LEVEL.
This research limits its scope to the Agile project delivery methodology and early prevention of logical vulnerability injection at the requirement phase only; any technical vulnerabilities introduced at any later SDLC life cycle stages are not covered in this research and could be a potential research area for future research
Endnotes
1 Vidal, L. A.; F. Marle; J. C. Bocquet; “Modeling Project Complexity,” International Conference on Engineering Design, Paris, France, August 2007
2 Mangat, M.; “89 Eye-Opening Data Breach Statistics for 2020,” phoenixNAP, 27 January 2020, http://phoenixnap.com/blog/data-breach-statistics
3 Ibid.
4 National Institute of Standards and Technology (NIST), National Vulnerability Database, USA, http://nvd.nist.gov/vuln/categories
5 Common Vulnerabilities and Exposures (CVE), http://cve.mitre.org/
6 Op cit NIST
7 FIRST, Common Vulnerability Scoring System SIG, http://www.first.org/cvss/
8 Dam, R. ; T. Y. Sian; “Five Stages in the Design Thinking Process,” Interaction Design Foundation, 2021, http://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process
9 Op cit NIST
10Op cit Dam, Sian
Thejasvi Nagaraju
Is a research scholar at Jain University (Bangalore, India). His areas of interest include data security, software delivery methodology and cloud Software as a Service (SaaS) platforms. He can be reached at thejasviphd@gmail.com and n.thejasvi@jainuniversity.ac.in.
Shubhamangala Aithal, Ph.D
Is a research guide at Jain University in the computer science and engineering divisions. Her core interests are in risk and quality management and application security. She can be reached at brm1shubha@gmail.com