Just what we need–yet another “framework” for improving software security.
We’ve already got the PCI DSS (Payment Card Industry Data Security Standard), the BSIMM (Building Security In Maturity Model), the OWASP (Open Web Application Security Project), the SAMM (Software Assurance Maturity Model), the ISO (International Organization for Standardization), the SAFECode (Software Assurance Forum for Excellence in Code)—the list goes on.
And it’s about to go on some more. The framework in the works—a white paper draft at the moment—from the National Institute of Standards and Technology (NIST), is called SSDF, as in, “Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF).” It went public June 11 and the comment window is open through August 5.
The framework recommends 19 practices, organized into four groups:
- Prepare the organization.
- Protect the software.
- Produce well-secured software.
- Respond to vulnerability reports.
Following the practices, the paper says, “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. Software consumers can reuse and adapt the practices in their software acquisition processes.”
Report
Get the latest edition
Recommendations, not mandates
All good. A more-than-worthy goal. Who wouldn’t want to mitigate the risks of software vulnerabilities? It’s just that it sounds a bit like issuing a framework for controlling the speed of vehicles on public ways when there have been dozens of laws on the books for decades designed to do the same thing.
Beyond that, whatever the specifics of the final version of the NIST Secure Software Development Framework, they will be recommendations, not mandates. NIST is a federal agency, under the Department of Commerce, but is not a regulatory agency and therefore has no leverage to force compliance with the framework.
And yet … perhaps it will fill a void. The goal of the proposed framework seems to be less about trying to reinvent the wheel and more about bringing various types of high-quality wheels together in one place so people who need wheels can decide what fits their needs.
Consolidating software security best practices
Indeed, the practices refer heavily to the multiple frameworks listed above, indicating that this is a consolidation of existing best-practice recommendations.
As one of the co-authors, Murugiah Souppaya, of the computer security division of the Information Technology Laboratory (within NIST), put it, “The paper facilitates communications about secure software development practices among groups across different business sectors around the world by providing a common language that points back to the existing industry sectors specific practices.”
He added that this “common language” is meant to help them describe their current practices. “This will allow them to set their desired baseline and identify areas for improvement,” he said.
Of course, none of the existing frameworks has transformed software security so far. There are headlines daily about breaches enabled by vulnerabilities—sometimes rampant—in applications or devices controlled by software.
So even if the NIST Secure Software Development Framework is the best one yet, if organizations aren’t persuaded to invest the time and money to follow the recommendations, it is unlikely to generate even incremental, never mind transformational, improvements in software security.
Taking the long view
What are its chances of breaking that precedent? Not high—at least not in the short term—in the view of Sammy Migues.
Migues, principal scientist at Synopsys and a co-author of the BSIMM, said this doesn’t mean the proposed NIST SSDF has no potential value. “Yes, following it would help,” he said. “But who is going to follow it? Only those for whom it is mandated, and only if they’re audited.”
And the number of those is likely to be small indeed. Migues noted that NIST “doesn’t make law or set policy. It’s an innovation organization for cheerleading and awareness. So unless some other organization that has the imprimatur of authority holds people to it, it’s unlikely that it will be followed,” he said.
The marketplace—both public and private—could exert some leverage, he said, if entities putting jobs out to bid made a software security framework like this one part of the RFP (request for proposals). “They could say, ‘This is one of the things you have to comply with to get the contract,’” he said.
But given the number of frameworks/standards already in existence, it is difficult to see how “one more arrow in the quiver” would be the one that suddenly disrupts the marketplace like that.
Even dynamic environments resist change
Part of the problem, he said, is that it’s hard to change people who are set in their ways, even in an industry that is evolving as rapidly as IT.
“There are a couple of things I really like [in the proposal]—one of them is to implement a supporting toolchain. They’ve actually put thought into it—they’re saying you can’t just download free stuff. And putting these in as actual tasks, along with who should think about them, is useful,” he said.
“But every development manager has his or her way of doing things. Do you think any of them are going to look at this and say, ‘Wow. I’ve been doing this for 20 years and have been doing it wrong all that time! I need to start doing it completely differently’? Not a chance.”
NIST SSDF encourages incremental change
Still, if a framework like this makes its way into the education system, it could yield incremental changes that would become transformative over time, he said.
“It can’t come from a vendor, but from neutral third parties,” he said. “If it makes its way into textbooks, college courses and RFPs, then it might gain some traction with regulatory bodies.”
NIST is hopeful that its Secure Software Development Framework’s “high-level” approach will make it more palatable to an “audience” of organizations with vast diversity in size and industry verticals. “The most important thing is implementing the practices and not the mechanisms used to do so. For example, one organization might automate a particular step, while another might use manual processes,” the paper says.
To that, Souppaya adds that the intent is for the NIST SSDF to be “customized by different sectors and individual organizations to best suit their risks, situations, and needs as organizations will have different software development methodologies, different programming languages, different toolchains, etc.”
How the NIST SSDF could get the job done
Migues agrees that flexibility is important—that getting the job done is more important than how the job gets done. But he said many organizations might not know the options for the “how.”
“What’s missing is workshops—something like a session at RSA with CISOs—that would guide people through how to do it based on their needs,” he said. “Just because I buy a Julia Child cookbook doesn’t mean I can do the recipes if I don’t know how to cook.”
Something along that line may be in the works. The authors of the white paper call it “a starting point” that they intend to expand to cover topics such as “how an SSDF may apply to and vary for different software development methodologies.”
That future work, they said, “will primarily take the form of use cases so the insights will be more readily applicable to certain types of development environments.”
Continue Reading
SANS report: Securing the shifting landscape of application development
