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
12 Free, Ready-to-Use Security Tools
Steve Zurier, Freelance Writer,  10/12/2018
Most IT Security Pros Want to Change Jobs
Dark Reading Staff 10/12/2018
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10839
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
CVE-2018-13399
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
CVE-2018-18381
PUBLISHED: 2018-10-16
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
CVE-2018-18382
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.