Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)

Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)

Table of Contents




Abstract

Few software development life cycle (SDLC) models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model to ensure the software being developed is well secured. This white paper recommends a core set of highlevel secure software development practices called a secure software development framework (SSDF) to be integrated within each SDLC implementation. The paper facilitates communications about secure software development practices among business owners, software developers, project managers and leads, and cybersecurity professionals within an organization. Following these practices should help software producers reduce the number of vulnerabilities in released software, mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences. Also, because the framework provides a common vocabulary for secure software development, software consumers can use it to foster communications with suppliers in acquisition processes and other management activities.

Keywords

secure software development, secure software development framework (SSDF), secure software development practices, software acquisition, software development, software development life cycle (SDLC), software security

Introduction

A software development life cycle (SDLC)1 is a formal or informal methodology for designing, creating, and maintaining software (which includes code built into hardware). There are many models for SDLCs, including waterfall, spiral, agile, and development and operations (DevOps). Few SDLC models explicitly address software security in detail, so secure software development practices usually need to be added to and integrated within each SDLC model. Regardless of which SDLC model is used to develop software, secure software development practices should be integrated throughout it for three reasons: to reduce the number of vulnerabilities in released software, to mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and to address the root causes of vulnerabilities to prevent future recurrences. Most aspects of security can be addressed at multiple places within an SDLC, but in general, the earlier in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the same level of security. This principle, also known as shifting left, is critically important regardless of the SDLC model.

There are many existing documents on secure software development practices, including those listed in the References section. This white paper does not introduce new practices or define new terminology; instead, it describes a subset of high-level practices based on established standards, guidance, and secure software development practice documents. These practices collectively called a secure software development framework (SSDF), should be particularly helpful for the target audiences to achieve secure software development objectives. Note that these practices are limited to those that bear directly on secure software development (e.g., securing the development infrastructure or pipeline itself is out of scope).

This white paper is intended to be a starting point for discussing the concept of an SSDF and therefore does not provide a comprehensive view of SSDFs. Future work may expand on the material in this white paper, potentially covering topics such as how an SSDF may apply to and vary for different software development methodologies and how an organization can transition from using just their current software development practices to also incorporating the practices specified by the SSDF. It is likely that future work will primarily take the form of use cases so that the insights will be more readily applicable to certain types of development environments.

This white paper expresses secure software development practices but does not prescribe exactly how to implement them. The focus is on implementing the practices rather than on the tools, techniques, and mechanisms used to do so. For example, one organization might automate a particular step, while another might use manual processes instead. Advantages of specifying the practices at a high level include the following:

• Can be used by organizations in any sector or community, regardless of size or cybersecurity sophistication

• Can be applied to software developed to support information technology (IT), industrial control systems (ICS), cyber-physical systems (CPS), or the Internet of Things (IoT)

• Can be integrated into any existing software development workflow and automated toolchain; should not negatively affect organizations that already have robust secure software development practices in place

• Makes the practices broadly applicable, not specific to particular technologies, platforms, programming languages, SDLC models, development environments, operating environments, tools, etc.

• Can help an organization document its secure software development practices today and define its future target practices as part of its continuous improvement process

• Can assist an organization currently using a classic software development model in transitioning its secure software development practices for use with a modern software development model (e.g., agile, DevOps)

• Can assist organizations that are procuring and using software to understand secure software development practices employed by their suppliers

This white paper also provides a common language to describe fundamental secure software development practices. This is similar to the approach of the Framework for Improving Critical Infrastructure Cybersecurity, also known as the NIST Cybersecurity Framework [2]. 2 Expertise in secure software development is not required to understand the practices. This helps facilitate communications about secure software practices among both internal and external organizational stakeholders, such as the following:

•Business owners, software developers, project managers, and leads, and cybersecurity professionals within an organization

• Software consumers, including both federal government agencies and other organizations, that want to define required or desired characteristics for software in their acquisition processes in order to have higher-quality software (particularly with fewer security vulnerabilities)

• Software producers (e.g., commercial-off-the-shelf [COTS] product vendors, government off-the-shelf [GOTS] software developers, software developers working within or on behalf of software consumer organizations, software testers/quality assurance personnel) that want to integrate secure software development practices throughout their SDLCs, express their secure software practices to their customers, or define requirements for their suppliers provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation.

Secure Software Development Framework (SSDF)

This white paper introduces a software development framework (SSDF) of fundamental, sound, and secure software development practices based on established secure software development practice documents. For the purposes of this white paper, the practices are organized into four groups:

• Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for each individual project.

• Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.

• Produce Well-Secured Software (PW): Produce well-secured software that has minimal security vulnerabilities in its releases.

• Respond to Vulnerabilities (RV): Identify vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Each practice is defined with the following elements:

• Practice: A brief statement of the practice, along with a unique identifier and an explanation of what the practice is and why it is beneficial.

• Task: An individual action (or actions) needed to accomplish a practice. • Implementation Example: An example of a type of tool, process, or another method that could be used to implement this practice; not intended to imply that any example or combination of examples is required or that only the stated examples are feasible options.

• Reference: An established secure development practice document and its mappings to a particular task.

Although most practices are relevant for any software development effort, some practices are not always applicable. For example, if developing a particular piece of software does not involve using a compiler, there would be no need to follow a practice on configuring the compiler to improve executable security. Some practices are more fundamental, while others are more advanced and may depend on certain fundamental practices already being in place. Also, practices are not all equally important in any particular case. Risk should be considered when deciding which practices to use and how much time and resources to devote to each practice.4 Finally, the frequency for performing recurring practices is not specified because the frequency appropriate for any particular situation depends on risk and other factors.

About KSRA

The Kavian Scientific Research Association (KSRA) is a non-profit research organization to provide research / educational services in December 2013. The members of the community had formed a virtual group on the Viber social network. The core of the Kavian Scientific Association was formed with these members as founders. These individuals, led by Professor Siavosh Kaviani, decided to launch a scientific / research association with an emphasis on education.

KSRA research association, as a non-profit research firm, is committed to providing research services in the field of knowledge. The main beneficiaries of this association are public or private knowledge-based companies, students, researchers, researchers, professors, universities, and industrial and semi-industrial centers around the world.

Our main services Based on Education for all Spectrum people in the world. We want to make an integration between researches and educations. We believe education is the main right of Human beings. So our services should be concentrated on inclusive education.

The KSRA team partners with local under-served communities around the world to improve the access to and quality of knowledge based on education, amplify and augment learning programs where they exist, and create new opportunities for e-learning where traditional education systems are lacking or non-existent.

FULL Paper PDF file:

NIST.CSWP.04232020

Bibliography

author

Donna Dodson Applied Cybersecurity Division Information Technology Laboratory
Murugiah Souppaya Computer Security Division Information Technology Laboratory
Karen Scarfone Scarfone Cybersecurity Clifton, VA

Year

2020

Title

Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)

Publish in

NIST CYBERSECURITY, WHITE PAPER, APRIL 23, 2020

Doi

https://doi.org/10.6028/NIST.CSWP.04232020

PDF reference and original file: Click here

 

Website | + posts

Nasim Gazerani was born in 1983 in Arak. She holds a Master's degree in Software Engineering from UM University of Malaysia.

Website | + posts

Professor Siavosh Kaviani was born in 1961 in Tehran. He had a professorship. He holds a Ph.D. in Software Engineering from the QL University of Software Development Methodology and an honorary Ph.D. from the University of Chelsea.

+ posts

Somayeh Nosrati was born in 1982 in Tehran. She holds a Master's degree in artificial intelligence from Khatam University of Tehran.