Application Security

4/17/2018
06:00 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

NIST Seeking Comments on New AppSec Practices Standards

Working in conjunction with SAFECode, NIST is opening the floor to suggestions at RSA about secure software development life cycle guidelines.

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.

Interop ITX 2018

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Worst Password Blunders of 2018 Hit Organizations East and West
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
8 Security Tips to Gift Your Loved Ones For the Holidays
Steve Zurier, Freelance Writer,  12/18/2018
How to Engage Your Cyber Enemies
Guy Nizan, CEO at Intsights Cyber Intelligence,  12/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
[Sponsored Content] The State of Encryption and How to Improve It
[Sponsored Content] The State of Encryption and How to Improve It
Encryption and access controls are considered to be the ultimate safeguards to ensure the security and confidentiality of data, which is why they're mandated in so many compliance and regulatory standards. While the cybersecurity market boasts a wide variety of encryption technologies, many data breaches reveal that sensitive and personal data has often been left unencrypted and, therefore, vulnerable.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-16883
PUBLISHED: 2018-12-19
sssd versions from 1.13.0 to before 2.0.0 did not properly restrict access to the infopipe according to the "allowed_uids" configuration parameter. If sensitive information were stored in the user directory, this could be inadvertently disclosed to local attackers.
CVE-2018-17192
PUBLISHED: 2018-12-19
The X-Frame-Options headers were applied inconsistently on some HTTP responses, resulting in duplicate or missing security headers. Some browsers would interpret these results incorrectly, allowing clickjacking attacks. Mitigation: The fix to consistently apply the security headers was applied on th...
CVE-2018-17193
PUBLISHED: 2018-12-19
The message-page.jsp error page used the value of the HTTP request header X-ProxyContextPath without sanitization, resulting in a reflected XSS attack. Mitigation: The fix to correctly parse and sanitize the request attribute value was applied on the Apache NiFi 1.8.0 release. Users running a prior ...
CVE-2018-17194
PUBLISHED: 2018-12-19
When a client request to a cluster node was replicated to other nodes in the cluster for verification, the Content-Length was forwarded. On a DELETE request, the body was ignored, but if the initial request had a Content-Length value other than 0, the receiving nodes would wait for the body and even...
CVE-2018-17195
PUBLISHED: 2018-12-19
The template upload API endpoint accepted requests from different domain when sent in conjunction with ARP spoofing + man in the middle (MiTM) attack, resulting in a CSRF attack. The required attack vector is complex, requiring a scenario with client certificate authentication, same subnet access, a...