NIST White Paper - Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)

こんにちは、丸山満彦です。

NISTがセキュアソフトウェア開発フレームワーク（SSDF）に関する白書を公表していますね。ビジネスオーナー、ソフトウェア開発者、プロジェクトマネジャー、組織内のサイ バーセキュリティの専門家等の間で、安全なソフトウェア開発の実践に関するコミュニケーションが重要となってきますが、この白書を理解することにより、それが進むとしていますね。。。

ソフトウェア開発者は、リリースしたソフトウェアの脆弱性を減らし、未知の脆弱性や対処されていない脆弱性を悪用された場合の潜在的な影響を緩和し、脆弱性の根本原因を解決し、再発を防ぐことができるようになるとのことです。。。。

● NIST - ITL

・2020.04.23 White Paper - Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)

・2020.04.23 [PDF] Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)

-----

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 high-level 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.

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].²

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, governmentoff-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

This white paper’s practices are not based on the assumption that all organizations have the same security objectives and priorities; rather, the recommendations reflect that each software producer may have unique security assumptions, and each software consumer may have unique security needs and requirements. While the desire is for each software producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented and the formality of the implementation will vary based on the producer’s security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation.

 ---

² The SSDF practices may help support the NIST Cybersecurity Framework Functions, Categories, and Subcategories, but the SSDF practices do not map to them and are typically the responsibility of different parties. Developers can adopt SSDF practices, and the outcomes of their work could help organizations with their operational security in support of the Cybersecurity Framework.

³ Future work may provide more practical guidance for software consumers on how they can leverage the SSDF in specific use cases.

 ---

2 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 other 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.⁴ Finally, the frequency for performing recurring practices is not specified because the frequency appropriate for any particular situation depends on risk and other factors.

The table that defines the practices is below. Remember that these practices are only a subset of what an organization may need to do, with the practices focused on helping organizations achieve secure software development objectives. The practices are not listed sequentially or in order of importance. The information in the table is space constrained, and much more information on each practice can be found in the references (with the bolded text on each line being the identifier used for that reference in the table):

• BSIMM10: Building Security in Maturity Model (BSIMM) Version 10 [3]
• BSA: BSA, Framework for Secure Software [4]
• IDASOAR: Institute for Defense Analyses (IDA), State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation 2016 [5]
• ISO27034: International Organization for Standardization/International Electrotechnical Commission (ISO/IEC), Information technology – Security techniques – Application security – Part 1: Overview and concepts, ISO/IEC 27034-1:2011 [6]
• MSSDL: Microsoft, Security Development Lifecycle [7]
• NISTCSF: NIST, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1 [2]
• OWASPASVS: OWASP, OWASP Application Security Verification Standard 4.0 [8]
• OWASPTEST: OWASP, OWASP Testing Guide 4.0 [9]
• PCISSLRAP: Payment Card Industry (PCI) Security Standards Council, Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0 [10]
• SAMM15: OWASP, Software Assurance Maturity Model Version 1.5 [11]
• SCAGILE: Software Assurance Forum for Excellence in Code (SAFECode), Practical Security Stories and Security Tasks for Agile Development Environments [12]
• SCFPSSD: SAFECode, Fundamental Practices for Secure Software Development:

Essential Elements of a Secure Development Lifecycle Program, Third Edition [13]

• SCSIC: SAFECode, Software Integrity Controls: An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain [14]
• SCTPC: SAFECode, Managing Security Risks Inherent in the Use of Third-Party Components [15]
• SCTTM: SAFECode, Tactical Threat Modeling [16]
• SP800-53: Joint Task Force Transformation Initiative, Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication (SP) 800-53 Revision 4 [17]
• SP800-160: NIST, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, NIST SP 800-160 Volume 1 [18]
• SP800-181: NIST, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST SP 800-181 [1]

 ---

⁴ Organizations seeking guidance on how to get started with secure software development can consult many publicly available references, such as “SDL That Won’t Break the Bank” by Steve Lipner from SAFECode (https://i.blackhat.com/us-18/ThuAugust-9/us-18-Lipner-SDL-For-The-Rest-Of-Us.pdf) and “Simplified Implementation of the Microsoft SDL” by Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=12379).