ArticlePDF Available

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.
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
... 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. ...
Article
Full-text available
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.
... 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. ...
Preprint
Full-text available
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.
... 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. ...
... If we take the time difference between the first and the last event, this will likely be close to the total development time. This can be done for all users of both the control and [112,113]. ...
... However, the relative cost of fixing defects grows significantly through the software development life-cycle. [1] found that resolving the defects in maintenance can cost 100 times more compared to early detection and fix. Software defect prediction (SDP) plays an important role of reducing the cost by recognizing defect-prone modules of a software prior to testing [2]. ...
... It is time consuming, disrupts schedules, and hurts the reputation of software products. Moreover, it is generally accepted that fixing bugs costs more the later they are found and that maintenance is costlier than initial development (Boehm, 1981;Boehm & Basili, 2001;Boehm & Papaccio, 1988;Dawson et al., 2010;Hackbarth et al., 2016). The effort invested in bug fixing therefore reflects on the health of the development process. ...
Article
Full-text available
The effort invested in software development should ideally be devoted to the implementation of new features. But some of the effort is invariably also invested in corrective maintenance, that is in fixing bugs. Not much is known about what fraction of software development work is devoted to bug fixing, and what factors affect this fraction. We suggest the Corrective Commit Probability (CCP), which measures the probability that a commit reflects corrective maintenance, as an estimate of the relative effort invested in fixing bugs. We identify corrective commits by applying a linguistic model to the commit messages, achieving an accuracy of 93%, higher than any previously reported model. We compute the CCP of all large active GitHub projects (7,557 projects with 200+ commits in 2019). This leads to the creation of an investment scale, suggesting that the bottom 10% of projects spend less than 6% of their total effort on bug fixing, while the top 10% of projects spend at least 39% of their effort on bug fixing — more than 6 times more. Being a process metric, CCP is conditionally independent of source code metrics, enabling their evaluation and investigation. Analysis of project attributes shows that lower CCP (that is, lower relative investment in bug fixing) is associated with smaller files, lower coupling, use of languages like JavaScript and C# as opposed to PHP and C++, fewer code smells, lower project age, better perceived quality, fewer developers, lower developer churn, better onboarding, and better productivity.
... Finding and fixing bugs accounts for a significant portion of maintenance cost for software (Britton et al., 2013), and the cost of bug fixing increases exponentially with time (Dawson et al., 2010). Hence, automatic program repair has long been a focus of software engineering, with the goal of lowering down the cost and reducing the introduction of new bugs during bug fixing. ...
Preprint
Full-text available
The advance in machine learning (ML)-driven natural language process (NLP) points a promising direction for automatic bug fixing for software programs, as fixing a buggy program can be transformed to a translation task. While software programs contain much richer information than one-dimensional natural language documents, pioneering work on using ML-driven NLP techniques for automatic program repair only considered a limited set of such information. We hypothesize that more comprehensive information of software programs, if appropriately utilized, can improve the effectiveness of ML-driven NLP approaches in repairing software programs. As the first step towards proving this hypothesis, we propose a unified representation to capture the syntax, data flow, and control flow aspects of software programs, and devise a method to use such a representation to guide the transformer model from NLP in better understanding and fixing buggy programs. Our preliminary experiment confirms that the more comprehensive information of software programs used, the better ML-driven NLP techniques can perform in fixing bugs in these programs.
Chapter
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.
Chapter
Firmware verification for small and medium industries is a challenging task; as a matter of fact, they generally do not have personnel dedicated to such activity. In this context, verification is executed very late in the design flow, and it is usually carried on by the same engineers involved in coding and testing. The specifications initially discussed with the customers are generally not formalised, leading to ambiguity in the expected functionalities. The adoption of a more formal design flow would require the recruitment of people with expertise in formal and semi-formal verification, which is not often compatible with the budget resources of small and medium industries. The alternative is helping the existing engineers with tools and methodologies they can easily adopt without being experts in formal methods.
Secure software development-the role of it audit
  • 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
  • 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
  • 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
  • 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