A Case Study on Data Vulnerabilities in Software Development Lifecycle Model

A Case Study on Data Vulnerabilities in Software Development Lifecycle Model

Syed Muzamil Basha, Ravi Kumar Poluru, J. Janet, S. Balakrishnan, D. Dharunya Santhosh, A. Kousalya
DOI: 10.4018/978-1-7998-2367-4.ch002
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Software security has become a very critical part of our lives. A software developer who has a fundamental understanding of software security can have an advantage in the workplace. In the massive Equifax breach that occurred in 2017 that exposed data of roughly 140 million people, attackers exploited a vulnerability in Apache Struts, CVE-2017-5638, which allows remote attackers to execute arbitrary commands when specially crafting user-controlled data in HTTP headers. Sensitive data exposure issues are essential to know to protect customer data. It is fascinating to understand how attackers can exploit application vulnerabilities to perform malicious activities. The authors also want the reader to be aware of the fact that we should always be thinking about how our applications handle user-controlled data so that we can put guards in place to minimize security issues in the development of new applications.
Chapter Preview
Top

Introduction

In developing software, developers, project managers, and other stakeholders go through a process called the system development life cycle. This process starts with the most essential step, requirements gathering. In the requirements gathering step, stakeholders define and agree on what the system needs to do. This is also where security requirements with the help of the stride method, able to analyze the flow of data and assemble the set of assets that must be secured in a given system.According to the National Institute of Standards and Technology (NIST), the system development life cycle is the overall process of developing, implementing,and retiring information systems through a multi-step process from initiation, analysis, design, implementation, maintenance, and disposal. In the beginning, we perform a requirements gathering, and we want to involve security as early as possible in the project.

The goal, in general, is to be able to answer the following:

  • Q1: What critical assets and services do we need the system to protect (Gunjal, B, 2019) ?

  • Q2: How should we define user roles?

  • Q3: What kinds of privileges to they each have?

  • Q4: What is the attack surface of the system?

During requirements gathering, what are the critical assets and services that need to be protected? Are there any user roles with different privileges? Also, determine where data can be entered or extracted. Next, we want to create a threat model.To do that, we want first to create a data flow diagram. This involves determining our trust boundaries.We use the STRIDE (Sangchoolie et al., 2018) mnemonic to determine a list of possible threats and some vulnerabilities to the system. The STRIDE mnemonic stands for: S - spoofing, T - tampering, R - repudiation, I -information leakage, D - Denial of Service, and E - Elevation of Privilege.

Three objectives of security: confidentiality, integrity, and availability. Confidentiality is preserving authorized restrictions on access and disclosure. To meet the objective of confidentiality, encrypt the data as it flows from one system to another. Example, use access control lists to allow only certain users access, to certain types of data (Wang, Y et al., 2018). Data integrity is the property that data meet with an expectation of quality and that the data can be relied on. We could meet the objective of integrity using a message authentication code to verify that what we downloaded off the internet was what we expected. An example of that is using the HMac algorithm (McBride, et al., 2018). Last, our third security objective is availability. It's because the definition of that is ensuring timely and reliable access to and use of information. An example of the threat to availability is a Distributed denial-of-service (DDoS) attack (Baker & Şimşek, 2018). Then, a flood of requests come at a short time interval, and your system no longer has the ability to keep up with serving those requests.

In this chapter, we made a deep discussion on concepts in threat modeling and cryptography. That helps in creating threat models and think critically about the threat models created by other people. Also, a basic understanding of applied cryptography, such as encryption and secure hashing — discussion on issues with improperly handling user-controlled data. At the very least, it is fascinating to understand how attackers can exploit application vulnerabilities to perform malicious activities. However, on a much more critical level, it helps those of us who work on creating and maintaining application code to protect the users who use our applications. Description on the three most common types of injection problems: SQL injection, Cross-site Scripting, and Command injection.Discussion on issues with application authentication and session management.

Top

Methodology

Threat modeling is a process with three main goals.

Complete Chapter List

Search this Book:
Reset