(Draft) Mitigating the Risk of Software Vulnerabilities by Adopting A

(Draft) Mitigating the Risk of Software Vulnerabilities by Adopting A

NIST CYBERSECURITY WHITE PAPER (DRAFT) CSRC.NIST.GOV 1 Mitigating the Risk of Software 2 Vulnerabilities by Adopting a Secure 3 Software Development Framework (SSDF) 4 5 Donna Dodson 6 Applied Cybersecurity Division 7 Information Technology Laboratory 8 9 Murugiah Souppaya 10 Computer Security Division 11 Information Technology Laboratory 12 13 Karen Scarfone 14 Scarfone Cybersecurity 15 Clifton, VA 16 17 18 June 11, 2019 19 20 21 22 NIST CYBERSECURITY WHITE PAPER (DRAFT) MITIGATING THE RISK OF SOFTWARE JUNE 11, 2019 VULNERABILITIES BY ADOPTING AN SSDF 23 Abstract 24 Few software development life cycle (SDLC) models explicitly address software security in detail, 25 so secure software development practices usually need to be added to each SDLC model to ensure 26 the software being developed is well secured. This white paper recommends a core set of high- 27 level secure software development practices, called a secure software development framework 28 (SSDF), to be added to each SDLC implementation. The paper facilitates communications about 29 secure software development practices amongst business owners, software developers, and 30 cybersecurity professionals within an organization. Following these practices should help software 31 producers reduce the number of vulnerabilities in released software, mitigate the potential impact 32 of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of 33 vulnerabilities to prevent future recurrences. Software consumers can reuse and adapt the practices 34 in their software acquisition processes. 35 Keywords 36 secure software development; secure software development framework (SSDF); secure software 37 development practices; software acquisition; software development; software development life 38 cycle (SDLC); software security. 39 Disclaimer 40 Any mention of commercial products or reference to commercial organizations is for information 41 only; it does not imply recommendation or endorsement by NIST, nor does it imply that the 42 products mentioned are necessarily the best available for the purpose. 43 Additional Information 44 For additional information on NIST’s Cybersecurity programs, projects and publications, visit the 45 Computer Security Resource Center. Information on other efforts at NIST and in the Information 46 Technology Laboratory (ITL) is also available. 47 48 Public Comment Period: June 11, 2019 through August 5, 2019 49 National Institute of Standards and Technology 50 Attn: Computer Security Division, Information Technology Laboratory 51 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 52 Email: [email protected] 53 All comments are subject to release under the Freedom of Information Act (FOIA). 54 55 ii NIST CYBERSECURITY WHITE PAPER (DRAFT) MITIGATING THE RISK OF SOFTWARE JUNE 11, 2019 VULNERABILITIES BY ADOPTING AN SSDF 56 Acknowledgments 57 The authors wish to thank all the individuals and organizations who provided comments on the 58 preliminary ideas and drafts, particularly BSA | The Software Alliance, the Information Security 59 and Privacy Advisory Board (ISPAB), and the members of the Software Assurance Forum for 60 Excellence in Code (SAFECode). 61 Audience 62 There are two primary audiences for this white paper. The first is software producers (e.g., 63 commercial-off-the-shelf [COTS] product vendors, government-off-the-shelf [GOTS] software 64 developers, custom software developers) regardless of size, sector, or level of maturity. The second 65 is software consumers, both federal government agencies and other organizations. Readers of this 66 document are not expected to be experts in secure software development in order to understand it, 67 but such expertise is required to implement its recommended practices. 68 Personnel within the following Workforce Categories and Specialty Areas from the National 69 Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework [1] are most 70 likely to find this publication of interest: 71 • Securely Provision (SP): Risk Management (RSK), Software Development (DEV), 72 Systems Requirements Planning (SRP), Test and Evaluation (TST), Systems Development 73 (SYS) 74 • Operate and Maintain (OM): Systems Analysis (ANA) 75 • Oversee and Govern (OV): Training, Education, and Awareness (TEA), Cybersecurity 76 Management (MGT), Executive Cyber Leadership (EXL), Program/Project Management 77 (PMA) and Acquisition 78 • Protect and Defend (PR): Incident Response (CIR), Vulnerability Assessment and 79 Management (VAM) 80 • Analyze (AN): Threat Analysis (TWA), Exploitation Analysis (EXP) 81 Trademark Information 82 All registered trademarks or trademarks belong to their respective organizations. 83 Note to Reviewers 84 This white paper is intended as a starting point for discussing the concept of a secure software 85 development framework (SSDF), and it does not provide a comprehensive view of SSDFs. Future 86 work will expand on the material in this white paper, potentially covering topics such as how an 87 SSDF may apply to and vary for different software development methodologies, and how an 88 organization can transition from using just their current software development practices to also 89 incorporating the practices specified by the SSDF. It is likely that the future work will primarily 90 take the form of use cases so the insights will be more readily applicable to certain types of 91 development environments. iii NIST CYBERSECURITY WHITE PAPER (DRAFT) MITIGATING THE RISK OF SOFTWARE JUNE 11, 2019 VULNERABILITIES BY ADOPTING AN SSDF 92 Table of Contents 93 1 Introduction ............................................................................................................ 1 94 2 Secure Software Development Framework (SSDF) ............................................. 3 95 References ................................................................................................................... 17 96 Appendix A— Acronyms ............................................................................................ 19 97 iv NIST CYBERSECURITY WHITE PAPER (DRAFT) MITIGATING THE RISK OF SOFTWARE JUNE 11, 2019 VULNERABILITIES BY ADOPTING AN SSDF 98 1 Introduction 99 A software development life cycle (SDLC) is a formal or informal methodology for designing, 100 creating, and maintaining software. There are many models for SDLCs, including waterfall, spiral, 101 agile, and Development and Operations (DevOps). Few SDLC models explicitly address software 102 security in detail, so secure software development practices usually need to be added to and 103 integrated within each SDLC model to ensure the software being developed under that model is 104 well secured. Regardless of which SDLC model is used to develop software, secure software 105 development practices should be integrated throughout it for three reasons: to reduce the number 106 of vulnerabilities in released software, to mitigate the potential impact of the exploitation of 107 undetected or unaddressed vulnerabilities, and to address the root causes of vulnerabilities to 108 prevent future recurrences. Most aspects of security can be addressed at multiple places within an 109 SDLC, but in general, the earlier in the SDLC security is addressed, the less effort is ultimately 110 required to achieve the same level of security. 111 There are many existing documents on secure software development practices. This white paper 112 does not introduce new practices or define new terminology; instead, it describes a subset of high- 113 level practices based on established standards, guidance, and secure software development practice 114 documents. These practices, collectively called a secure software development framework (SSDF), 115 should be particularly helpful for the target audiences to achieve security software development 116 objectives. 117 This white paper expresses secure software development practices but does not prescribe exactly 118 how to implement them. The most important thing is implementing the practices and not the 119 mechanisms used to do so. For example, one organization might automate a particular step, while 120 another might use manual processes instead. Advantages of specifying the practices at a high level 121 include the following: 122 • Can be used by organizations in any sector or community, regardless of size or 123 cybersecurity sophistication 124 • Can be applied to software developed to support information technology (IT), industrial 125 control systems (ICS), cyber-physical systems (CPS), or the Internet of Things (IoT) 126 • Can be integrated into any existing software development workflow and automated 127 toolchain; should not negatively affect organizations that already have robust secure 128 software development practices in place 129 • Makes the practices broadly applicable—not specific to particular technologies, platforms, 130 programming languages, SDLC models, development environments, operating 131 environments, tools, etc. 132 • Can help an organization document its secure software development baseline today and 133 define its future target baseline as part of its continuous improvement process. 134 • Can assist an organization currently using a classic software development model in 135 transitioning its secure software development practices for use with a modern software 136 development model (e.g., agile, DevOps). 137 This white paper also provides a common language to describe fundamental secure software 138 development practices. This is similar

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    23 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us