ArticlePDF Available

Integrating Software Assurance into the Software Development Life Cycle (SDLC)

  • January 2010
Authors:
Maurice Dawson at Illinois Institute of Technology
Maurice Dawson
Darrell Norman Burrell at Marymount University
Darrell Norman Burrell
Emad Rahim at Bellevue University
Emad Rahim
Stephen Brewster at Capitol Technology University
Stephen Brewster
Download full-text PDF
Read full-text
Download citation

Abstract and Figures

This article examines the integration of secure coding practices into the overall Software Development Life Cycle (SDLC). Also detailed is a proposed methodology for integrating software assurance into the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP). This method for integrating software assurance helps in properly securing the application layer as that is where more than half of the vulnerabilities lie in a system.
Figures - uploaded by Maurice Dawson
Author content
All figure content in this area was uploaded by Maurice Dawson
Content may be subject to copyright.
Content uploaded by Maurice Dawson
Author content
All content in this area was uploaded by Maurice Dawson
Content may be subject to copyright.
M. Dawson, D. N. Burrell, E. Rahim and S. Brewster JISTP - Volume 3, Issue 6 (2010), pp. 49-53
49
INTEGRATING SOFTWARE ASSURANCE INTO THE SOFTWARE
DEVELOPMENT LIFE CYCLE (SDLC)
Maurice Dawson
1,2
, Darrell Norman Burrell
3,4
, Emad Rahim
5,6
and Stephen Brewster
7
1
Morgan State University, USA,
2
Colorado Technical University, USA,
3
A. T. Still University, USA,
4
Virginia International University, USA,
5
Morrisville State College, USA,
6
Walden University, USA
and
7
Capitol College, USA
ABSTRACT
This article examines the integration of secure coding practices into the overall Software Development
Life Cycle (SDLC). Also detailed is a proposed methodology for integrating software assurance into the
Department of Defense Information Assurance Certification & Accreditation Process (DIACAP). This
method for integrating software assurance helps in properly securing the application layer as that is
where more than half of the vulnerabilities lie in a system.
Keywords: Secure Coding; Software Assurance; Secure Software Development Lifecycle.
INTRODUCTION
In the past software product stakeholders did not view software security has high priority. It was
believed that a secure network infrastructure would provide the level of protection needed against
malicious attacks. In recent history network security alone has proved inadequate against such attacks.
Users have been successful in penetrating valid channels of authentication through techniques such as
cross site scripting, Structured Query Language (SQL) Injection, and Buffer Overflow exploitation. In
such cases system assets were compromised and both data and organizational integrity were
damaged. The Gartner Group reports that more than 70 percent of current business security
vulnerabilities are found within software applications rather than the network boundaries (Aras, Barbara,
& Jeffrey, 2008). A focus of application security emerged in order to reduce the risk of poor software
development, integration, and deployment. Through this need software assurance quickly became an
Information Assurance (IA) focus area in the financial, government, and manufacturing sectors to
reduce the risk of unsecure code.
MEETING DEPARTMENT OF DEFENSE (DOD) DEMANDS
The United States Army is the primary customer may defense contractors. The Army is managed and
ran by the Department of Defense (DoD). The primary objective of the DoD is to provide military forces
in an effort to deter war and to protect the security of the United States of America. The Department of
Defense (DoD) has addressed security through governance issued under the Office of Management
and Budget (OMB) Circular A-130. The focus of Information Technology security was further derived by
DoD Directive 8500.2. It specifically states that all IA and IA-enabled IT products incorporated into DoD
Full Article Available Online at: Intellectbase and EBSCOhost │ JISTP is indexed with Cabell‘s, JournalSeek, etc.
JOURNAL OF INFORMATION SYSTEMS TECHNOLOGY & PLANNING
Journal Homepage: www.intellectbase.org/journals │ ©2010 Published by Intellectbase International Consortium, USA
Integrating Software Assurance into the Software Development Life Cycle (SDLC)
50
information systems shall be configured in accordance with DoD-approved security configuration
guidelines. On April 26, 2010, the DoD released the third version of the Application Security and
Development Security Technical Implementation Guide (STIG) provided by the Defense Information
Systems Agency (DISA). This document provides DoD guidelines and requirements for integrating
security throughout the software development lifecycle. As a leader in the development and fielding of
unmanned aerial vehicles, it is our responsibility to meet the needs and demands of our customer to the
best of our ability. Therefore we must adhere to the integration of security throughout our SDLC in an
effort to meet the requirements of our customer.
COMMON INDUSTRY STANDARDS FOR SOFTWARE DEVELOPMENT
Software engineering is the process of developing and implementing algorithms. Software Assurance is
the level of confidence that software algorithms function as specified free of intentional and
unintentional vulnerabilities. Generally an organization‘s software development life cycle is based upon
the waterfall model. There are five phases to the Software Development Life Cycle (SDLC). The figure
below details a process flow diagram of the waterfall SDLC.
Figure 2: Common Defense & Aerospace SDLC
An allocated baseline is created during the Requirements and Analysis phase. This baseline contains
all of the requirements for a specific system allocated across four different functional areas. Once each
functional area lead identifies its allocated requirements as correct, the allocated baseline becomes a
verified baseline. Software is one of the four functional areas in which system requirements are
allocated. These requirements are then used to design code, integrate and test a completed software
configuration item within the system. The IA security controls for the system are identified during the
requirements and analysis phase. They are provided by customer and implemented through the
Defense Information Assurance Certification and Accreditation Process (DIACAP) in compliance with
DoD Instruction (DoDI) 8510.01. The respective Program Management Office of the DoD for provides
an organization‘s IA department with a list of IA requirements that are to be met. These requirements
serve as the DIACAP Implementation Plan (DIP), which must be executed in order to reduce the
security risk of the system to an acceptable level and receive an Authority To Operate (ATO). The ATO
is needed in order for our systems to be fielded within the DoD network. However, the execution of the
DIP occurs during the CSCI Test phase of the SDLC. Therefore any and all vulnerabilities are being
identified and mitigated after the software has been designed, developed, unit tested, and submitted for
computer software configuration item testing.
M. Dawson, D. N. Burrell, E. Rahim and S. Brewster JISTP - Volume 3, Issue 6 (2010), pp. 49-53
51
PROCESS TO SECURE SOFTWARE CODE
In the event of a vulnerability finding, the software code may require redesign and implementation. This
iterative cycle is costly in time and resources. To truly understand security threats to a system, security
must be addressed beginning with the initiation phase of the development process. For an organization
this means they must allow the IA controls and requirements to drive design and influence the software
requirements. Therefore, any identified security threats found during the requirements and analysis
phase will drive design requirements and implementation. Security defects discovered can then be
addressed at a component level before implementation. The cost of discovery and mitigation can be
absorbed within the review, analysis and quality check performed during the design, and
implementation of our SDLC. The resultant product is one with security built in rather than security
retrofitted. A study was performed by the IBM System Science Institute in order determine the relative
cost in order to fix defects within the SDLC. Figure 2 displays their findings.
Figure 3: IBM System Science Institute Relative Cost of Fixing Defects
Defects found in testing were 15 times more costly than if they were found during the design phase and
2 times more than if found during implementation.
SECURE SDLC
DoDI 8500.2, IA Implementation, states that the Information Systems Security Engineer (ISSE) must
work with the system architects, engineers, and developers to ensure that IA controls are designed and
implemented into the system throughout the development process. Though this requirement is for
government entities, it serves as a guide into how an organization could also integrate security into
software development. The software development process which an organization should have should
serve as the baseline process in which the integration of security controls and activities must take
place. The objectives are as follows for secure development:
Reduce cost of fixing vulnerabilities.
Increase the integrity, availability, and confidentiality of our software.
Integrating Software Assurance into the Software Development Life Cycle (SDLC)
52
Conform to DoD standards of secure software development
The security activities involved should seamlessly interface with existing activities found with the
organization‘s SDLC. In order to achieve such a unified process we must first examine the activities
required within a Secure SDLC. The International Information Systems Security Certification
Consortium, Inc (ISC)2, a global leader in the creation of security certification standards, has published
best practices for integrating security into the system development life cycle. The security activities
suggested by (ISC)2 should be further derived into the secure SDLC using existing SDLC phase
definitions. The following diagram depicts the activities within the Secure SDLC with the Department:
Figure 4: Industry Standard Secure Software Development Life Cycle Activities
Using this outlined Secure SDLC, security can be addressed over the course of the software‘s
development life cycle. DIACAP artifacts can now be gathered during each phase and compiled in
order to deliver a more complete system profile. Installation and deployment activities will incorporate
security controls in order to maintain the security posture of the system from implementation through
integration and test. Threat analysis, system modeling, and security design review will provide the
opportunity to identify system exploitable attributes before any code is written. Vulnerability
assessments using static code scan tool and surface scan tools will provide output for determining if the
software was developed to specifications identified during the security design review. The end product
will be both hacker resistant and security hardened.
M. Dawson, D. N. Burrell, E. Rahim and S. Brewster JISTP - Volume 3, Issue 6 (2010), pp. 49-53
53
SUMMARY
The Secure SDLC has as its base components all of the activities and security controls needed to
develop DoD compliant and industry best practices hardened software. A knowledgeable staff as well
as secure software policies and controls is required in order to truly prevent, identify, and mitigate
exploitable vulnerabilities within developed systems. Not meeting the least of these activities found
within the secure SDLC provides an opportunity for misuse of system assets from both insider and
outsider threats. Security is not simply a network requirement, it is now an Information Technology
requirement which includes the development of all software for the intent to distribute, store, and
manipulate information. Therefore, as a developer in the defense industry contractors must implement
the highest standards of development in order to insure the highest quality of products for its customers
and the lives which they protect.
REFERENCES
Aras, O, Barbara, C, & Jeffrey, L. (2008). Secure software development-the role of it audit. Information
Systems Control Journal, 4.
Defense Information Systems Agency, DISA Field Security Operations. (2006). Application services
security technical implementation guide, Washington, DC: Defense Information Systems Agency.
Retrieved from
http://iase.disa.mil/stigs/stig/application-services-stig-v1r1.pdf
Defense Information Systems Agency, DISA Field Security Operations. (2010). Application services
security technical implementation guide, Washington, DC: Defense Information Systems Agency.
Retrieved from http://iase.disa.mil/stigs/stig/
Paul, M. (2008). The need for software security. Retrieved from
https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/CSSLP
_WhitePaper.pdf
Dowd, M, McDonald, J, & Schuh, J. (2007). The art of software security assessment. Boston, MA:
Pearson Education, Inc.
Maxon, R. (2008). Software assurance best practices for air force weapon and information technology
systems – are we bleeding?. Published manuscript, Department of Systems and Engineering
Management, Air Force Institute of Technology, Wright-Patterson Air Force Base, OH. Retrieved
from
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA480286&Location=U2&doc=GetTRDoc.pdf
... Dawson et al. [6] examined the integration of secure coding practice into a secure SDLC, compliant with the standard adopted by the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP). They show the importance of integrating software security assurance as a means of protecting the application layer, where, according to them, more than half of the vulnerabilities are found in a system. ...
... On the other hand, a pipeline implementing a continuous deployment scenario would also include the Release & Monitoring activities described above. 6 https://owasp.org/www-project-top-ten/ The first pipeline (Developing) takes the application code as input from a git repository and addresses most of the Developing macro-phase activities, starting with the Quality Code Analysis. ...
View
... The previously mentioned costs of implementing fairness metrics and auditing practices are smaller than the costs of addressing system limitations later in the development process. Implementing solutions at the design phase, compared to the testing phase or deployment stage, can ultimately cut costs by a significant amount (Dawson et al. 2010). ...
Beyond ideals: why the (medical) AI industry needs to motivate behavioural change in line with fairness and transparency values, and how it can do it
Article
Full-text available
Artificial intelligence (AI) is increasingly relied upon by clinicians for making diagnostic and treatment decisions, playing an important role in imaging, diagnosis, risk analysis, lifestyle monitoring, and health information management. While research has identified biases in healthcare AI systems and proposed technical solutions to address these, we argue that effective solutions require human engagement. Furthermore, there is a lack of research on how to motivate the adoption of these solutions and promote investment in designing AI systems that align with values such as transparency and fairness from the outset. Drawing on insights from psychological theories, we assert the need to understand the values that underlie decisions made by individuals involved in creating and deploying AI systems. We describe how this understanding can be leveraged to increase engagement with de-biasing and fairness-enhancing practices within the AI healthcare industry, ultimately leading to sustained behavioral change via autonomy-supportive communication strategies rooted in motivational and social psychology theories. In developing these pathways to engagement, we consider the norms and needs that govern the AI healthcare domain, and we evaluate incentives for maintaining the status quo against economic, legal, and social incentives for behavior change in line with transparency and fairness values.
View
... Some sample numbers from Google are that it takes $5 to fix a bug during unit testing and $5,000 to do so during system testing [13]. The IBM System Science Institute reported that bugs were 15 times more costly to fix during testing than during the design phase [11]. In addition, they found that patching a bug in the maintenance phase was 100 times more costly than having fixed it in the design phase. ...
A Study of Grammar-Based Fuzzing Approaches
Article
  • Jun 2022
Fuzzing is the process of finding security vulnerabilities in code by creating inputs that will activate the exploits. Grammar-based fuzzing uses a grammar, which represents the syntax of all inputs a target program will accept, allowing the fuzzer to create well-formed complex inputs. This thesis conducts an in-depth study on two blackbox grammar-based fuzzing methods, GLADE and Learn&Fuzz, on their performance and usability to the average user. The blackbox fuzzer Radamsa was also used to compare fuzzing effectiveness. From our results in fuzzing PDF objects, GLADE beats both Radamsa and Learn&Fuzz in terms of coverage and pass rate. XML inputs were also tested, but the results only show that XML is a relatively simple input as the coverage results were mostly the same. For the XML pass rate, GLADE beats all of them except for the SampleSpace generation method of Learn&Fuzz. In addition, this thesis discusses interesting problems that occur when using machine learning for fuzzing. With experience from the study, this thesis proposes an improvement to GLADE’s user-friendliness through the use of a configuration file. This thesis also proposes a theoretical improvement to machine learning fuzzing through supplementary examples created by GLADE.
View
... After all, one of the main reasons why technology providers engage with auditors is that it is cheaper and easier to address system vulnerabilities early in the development process. For example, it can costs up to 15 times more to fix a software bug found during the testing phase than fixing the same bug found in the design phase [140]. This suggests that-despite the associated costs-businesses have clear incentives to design and implement effective EBA procedures. ...
Operationalising AI governance through ethics-based auditing: an industry case study
Article
Full-text available
  • May 2022
Ethics-based auditing (EBA) is a structured process whereby an entity’s past or present behaviour is assessed for consistency with moral principles or norms. Recently, EBA has attracted much attention as a governance mechanism that may help to bridge the gap between principles and practice in AI ethics. However, important aspects of EBA—such as the feasibility and effectiveness of different auditing procedures—have yet to be substantiated by empirical research. In this article, we address this knowledge gap by providing insights from a longitudinal industry case study. Over 12 months, we observed and analysed the internal activities of AstraZeneca, a biopharmaceutical company, as it prepared for and underwent an ethics-based AI audit. While previous literature concerning EBA has focussed on proposing or analysing evaluation metrics or visualisation techniques, our findings suggest that the main difficulties large multinational organisations face when conducting EBA mirror classical governance challenges. These include ensuring harmonised standards across decentralised organisations, demarcating the scope of the audit, driving internal communication and change management, and measuring actual outcomes. The case study presented in this article contributes to the existing literature by providing a detailed description of the organisational context in which EBA procedures must be integrated to be feasible and effective.
View
... In this work, we propose to apply the surprisal measure to software engineering artefacts, motivated by many researchers arguing that software developers need to be aware of unusual or surprising events in their repositories, e.g., when summarizing project activity [19], notifying developers about unusual commits [7,9], and for the identification of malicious content [26]. The basic intuition is that catching bad surprises early will save effort, cost, and time, since bugs cost significantly more to fix during implementation or testing than in earlier phases [17], and by extension, bugs cost more the longer they exist in a product after being reported and before being addressed. ...
Is Surprisal in Issue Trackers Actionable?
Preprint
Full-text available
  • Apr 2022
Background. From information theory, surprisal is a measurement of how unexpected an event is. Statistical language models provide a probabilistic approximation of natural languages, and because surprisal is constructed with the probability of an event occuring, it is therefore possible to determine the surprisal associated with English sentences. The issues and pull requests of software repository issue trackers give insight into the development process and likely contain the surprising events of this process. Objective. Prior works have identified that unusual events in software repositories are of interest to developers, and use simple code metrics-based methods for detecting them. In this study we will propose a new method for unusual event detection in software repositories using surprisal. With the ability to find surprising issues and pull requests, we intend to further analyse them to determine if they actually hold importance in a repository, or if they pose a significant challenge to address. If it is possible to find bad surprises early, or before they cause additional troubles, it is plausible that effort, cost and time will be saved as a result. Method. After extracting the issues and pull requests from 5000 of the most popular software repositories on GitHub, we will train a language model to represent these issues. We will measure their perceived importance in the repository, measure their resolution difficulty using several analogues, measure the surprisal of each, and finally generate inferential statistics to describe any correlations.
View
... This shows that security is one of the serious issues in the current era that need to be addressed carefully during SDLC. Further, the relative cost of addressing bugs and failure increase as the project progress as mentioned in the IBM system science institute report [26]. Therefore, handling security from the beginning of the project is necessary to save the software from future security breaches. ...
View
Quantifying the Cost of Web Accessibility Barriers for Blind Users
Article
When a website is not accessible for users with disabilities, there is a cost imposed on that user. This study quantifies the time disparity experienced by blind users when they encounter web accessibility barriers. The resulting data illustrates a significant reason why web accessibility is imperative, by highlighting and measuring the cost of inaccessibility through the lens of the inequity that accessibility barriers place on the time of users with disabilities in both personal and business settings. This data is needed for policymakers who are creating new regulations or statutes, as well as for informing future technical standards for web accessibility.
View
A Descriptive Study on Metaverse: Cybersecurity Risks, Controls, and Regulatory Framework
Article
Full-text available
  • Jan 2023
Maximalist, interconnected set of experiences straight out of sci-fi, based on 3D virtual environment through personal computing, and augmented reality headsets-a world known as the Metaverse-this is the futuristic vision of internet that technology giants are investing in. There has been some research on data privacy risks in the metaverse; however, detailed research on the cybersecurity risks of virtual reality platforms like metaverse have not been performed. This research paper addresses this gap of understanding the various possible cybersecurity risks on metaverse platforms. This study tries to understand the risks associated with metaverse by describing the technologies supporting metaverse platform and understanding the inherent cybersecurity threats in each of these technologies. Further, the paper proposes a cybersecurity risk governance regulatory framework to mitigate these risks.
View
SecTutor: An Intelligent Tutoring System for Secure Programming
Chapter
  • Jun 2022
SecTutor is a tutoring system that uses adaptive testing to select instructional modules that allow users to pursue secure programming knowledge at their own pace. This project aims to combat one of the most significant cybersecurity challenges we have today: individuals’ failure to practice defensive, secure, and robust programming. To alleviate this, we introduce SecTutor, an adaptive online tutoring system, to help developers understand the foundational concepts behind secure programming. SecTutor allows learners to pursue knowledge at their own pace and according to their own interests, based on assessments that identify and structure educational modules based on their current level of understanding.
View
View
Secure software development-the role of it audit
  • Jan 2008
  • 4
  • O Aras
  • C Barbara
  • L Jeffrey
Aras, O, Barbara, C, & Jeffrey, L. (2008). Secure software development-the role of it audit. Information Systems Control Journal, 4.
Software assurance best practices for air force weapon and information technology systems – are we bleeding? Published manuscript, Department of Systems and Engineering Management, Air Force Institute of Technology, Wright-Patterson Air Force Base, OH. Retrieved from http
  • Jan 2008
  • R Maxon
Maxon, R. (2008). Software assurance best practices for air force weapon and information technology systems – are we bleeding?. Published manuscript, Department of Systems and Engineering Management, Air Force Institute of Technology, Wright-Patterson Air Force Base, OH. Retrieved from http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA480286&Location=U2&doc=GetTRDoc.pdf
The art of software security assessment
  • Jan 2007
  • M Dowd
  • J Mcdonald
  • J Schuh
Dowd, M, McDonald, J, & Schuh, J. (2007). The art of software security assessment. Boston, MA: Pearson Education, Inc.
Software assurance best practices for air force weapon and information technology systems-are we bleeding
  • Jan 2008
  • R Maxon
Maxon, R. (2008). Software assurance best practices for air force weapon and information technology systems-are we bleeding?. Published manuscript, Department of Systems and Engineering Management, Air Force Institute of Technology, Wright-Patterson Air Force Base, OH. Retrieved from http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA480286&Location=U2&doc=GetTRDoc.pdf