NIST Seeking Comments on New AppSec Practices Standards

RSA CONFERENCE 2018 – San Francisco – The standards keepers at the National Institute of Standards and Technology (NIST) are turning their eyes to the world of application security. Working together with the nonprofit secure development coalition SAFECode, NIST has revved up its engines to work on a new special publication titled the Guide to Secure Software Development Life Cycle (SSDLC) Practices: A Producer and Consumer Perspective. The title might be a mouthful, but its purpose is fairly simple: to set the bar on what it means to securely develop software.

The guide is a work in progress with a still uncertain publication date, but NIST and SAFECode have made enough early conceptual headway that they're comfortable turning to the security community to help them flesh out ideas for the standards. That public opinion gathering will commence Wednesday at RSA Conference in the form of a public working group session at the InterContinental Hotel at 4:30. In the run-up to this kickoff workshop, Dark Reading caught up with Steve Lipner, SAFECode's executive director, to discuss the work his organization is doing to spearhead the publication and what he hopes its dissemination will do for application security industry-wide.

Dark Reading: Can you tell us a little about the genesis of this project and your collaboration with NIST?

Steve Lipner: One of the things we at SAFECode have been doing for probably more than 10 years is publishing best practices and recommended approaches for secure development, basically getting the developers to build secure software rather than trying to test it in after the fact.

There's been a lot pickup of those sort of processes in the industry at large. But government guidance has been really silent on secure development practices up to today. And so we've been talking with NIST management for some time about producing a special publication on that topic. 

After a lot of conversation, NIST has stepped up and they've done a lot of work internally, thinking about the issues and getting prepared. I think they're a while away from issuing something, but they're at the point where they've thought about it enough that they want to get public input.

Dark Reading: Once this publication does get issued, what do you hope its existence will actually do for the industry?

Steve Lipner: So, I think there are three things. Number one, it'll provide another element of guidance for developers. There's SAFECode guidance out there, and there's other guidance out there that rules by simple numbers, but I think some organizations will look to this guidance and say, "That's something we're especially willing to rely on."

I think it will provide a vehicle for customers to ask for secure development in an authoritative way. That will incentivize more developers to step up and start to adopt secure development processes, because they're going to be faced with these, hopefully, realistic and well-aligned requirements that will move them that way.

And then the third thing is specifically for government procurements, which is a small subset, but it's important. I think it will give government program offices, government system integrators, a tool to understand what best practices are and to integrate some of those things into the way they build software for the government.

Dark Reading: Obviously, with your presence here at RSA to stage this working group, SAFECode and NIST are reaching out to the security community, but can we also expect similar input-gathering from the development tribe that's most likely to be impacted by these standards? 

Steve Lipner: SAFECode members and other commercial organizations that have secure development processes involve their developer communities (in developing these standards). So, I'm hoping that the bridge will get crossed by the impetus of the commercial players who see this being done and that they'll make sure that their development organizations are on board. You can't really do a secure development life cycle or create a security development life cycle process without having your developers bought in.

Dark Reading: In that same vein, will NIST be working to tie in a lot of the new development practices and standards that are cropping up as IT shops move to DevOps software delivery methodologies?

Steve Lipner: When we started building software security processes (at SAFECode), that was consistent with a two- or three-year development life cycle. But in my experience, just a year or two after we created our initial development process, we had to say, "Okay, how do you apply this process to Agile (and DevOps)? 

And so we started to think about "What does that mean?" and "How do we adapt?" The answer is that secure code is still secure code, but you have to have different ways of parsing the tools, testing the delivery, [and knowing] where the feedback loop goes. Just because you're doing DevOps or just because you're doing Agile doesn't mean you can't do secure development, if you decide that secure development is important. [We'll be] getting that reflected in a NIST special publication that is specific enough so that customers can tell whether developers have done it. But it will also be general enough so that there is flexibility for other processes and different tools. 

There are going to be challenges in getting the document right, but I don't believe it's an impossible task, by any means.

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry's most knowledgeable IT security experts. Check out the Interop ITX 2018 agenda here.