On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework. While a solid piece of work in its own right, this document is noteworthy because it stands as one more proof point – in an already long list of proof points, that development processes, the developers themselves, and the organizations they belong to, ALL share some degree of responsibility (liability) for:
In other words, application security, governance, risk and compliance management obligations are not confined to distributed binaries – HOW those binaries are developed and deployed, WHO is doing the work, AND WHERE accountability ultimately falls is at least as critical to effective risk management – and compliance – as the actual software.
If you are developing software (or licensing software from others), including these requirements in your (their) development process is as fundamental to compliance as unit testing or signing your binaries.
We have already written on this topic as it related to GDPR, PCI Compliance, and the DTSA – now let’s take a quick look at NIST’s most recent contribution.
First, the white paper is clear that it is not attempting to reinvent the wheel. As indicated above, the NIST is tapping into a well-understood trend of extending effective risk management controls backwards beyond production environments and into the development practices that feed those environments.
Chapter 2 (Secure Software Development Framework) emphasizes this point and defines the scope of their document.
“This white paper introduces a secure software development framework (SSDF) of fundamental, sound 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:
Here are some specific NIST (DRAFT) requirements in each of these four groups WITH ADDED COMMENTARY that are worth noting:
| Practice | Task |
|---|---|
| Prepare the Organization (PO) | |
| Implement a Supporting Toolchain (PO.3): Use automation to reduce the human effort needed and improve the accuracy, consistency, and comprehensiveness of security practices throughout the SDLC, as well as a way to document and demonstrate use of these practices without significant additional effort or expense. | PO.3.1: Specify which tools or tool types are to be included in each toolchain and which tools or tool types are mandatory, along with how the toolchain components are to be integrated with each other. PO.3.2: Following sound security practices, deploy and configure tools, integrate them within the toolchain, and maintain the individual tools and the toolchain as a whole. PO.3.3: Configure tools to collect evidence and artifacts of their support of the secure software development practices. |
| Commentary (added here, not part of the NIST document) | |
| PO.3: This practice is at the heart of PreEmptive’s post-compile approach. Injecting tamper detection, escalation of privileges (rooting a device), etc. as well as the responses to these events are all injected post compile for maximum automation AND to “to document and demonstrate use of these practices without significant additional effort or expense.” | PO.3.1: This is why integration with Azure DevOps or Google’s R8 (to name just two toolchain examples) is so important and why PreEmptive has prioritized this kind of work in addition to the actual protection technologies. PO.3.2: It is important to keep all tools updated on their latest release to maintain “the toolchain as a whole.” |
| Practice | |
|---|---|
| Protect Software (PS) | Commentary (added here, not part of the NIST document) |
| Protect All Forms of Code from Unauthorized Access and Tampering (PS.1): Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code not intended to be publicly accessible, it helps prevent theft of the software and makes it more difficult for attackers to find vulnerabilities in the software. | PS.1: The requirement cannot get much more explicit than this (nor the rationale). Code MUST be protected in ALL of its forms. Why? Because bad actors will study it to find vulnerabilities that you missed and others will steal your hard work and Intellectual Property. |
| Provide a Mechanism for Verifying Software Release Integrity (PS.2): Help software consumers ensure the software they acquire is legitimate and has not been tampered with. | PS.2: Ensuring user confidence is not a one-time event. Each time an application is run, consumers need to have a reasonable assurance that their applications – nor the system running that application – have not been tampered with or in some other way compromised. Runtime – and real-time – checks with contextual responses (that don’t require outside services) are one of the most effective patterns to achieve this requirement. |
| Practice | |
|---|---|
| Produce Well-Secured Software (PW) | Commentary (added here, not part of the NIST document) |
| Verify Third-Party Software Complies with Security Requirements (PW.3): Reduce the risk associated with using acquired software modules and services, which are potential sources of additional vulnerabilities. | PW.3: If you build general purpose software and do not specifically have NIST (or related) obligations – but if your customers do – you will soon have to address them as well (to preserve marketshare). |
| Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4): Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software. These are particularly true for software that implements security functionality, such as cryptographic modules and protocols. | PW.4: Here again we see the power of PreEmptive’s post-compile injection. Once a vetted defense and response to (for example) unauthorized use of a debugger on software that uses keys has been established – REUSE it by having it injected post-compile saving each development team from having to learn both the control itself as well as the practice of knowing when to include it and how to document it. |
Including these kinds of requirements in development process are as fundamental to compliance as unit testing or signing your binaries. To understand how your organization can better secure software through automated and scalable tool chains and processes, check out PreEmptive Protection and select the tool that’s right for you.