Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

5/1/2019
02:30 PM
Steve Lipner
Steve Lipner
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Staffing the Software Security Team: Who You Gonna Call?

Recruiting developers and testers from the product group is a great way to build a top-notch application security team. Here's why.

As executive director of SAFECode, theSoftware Assurance Forum for Excellence in Code, I get to talk with a lot of companies — both SAFECode members and not — about their software security programs. These conversations cover a range of topics, including selection of effective tools, security training for developers, and how to integrate software security practices into rapid development models such as Agile and DevOps.

One common concern I hear is how to create a software security team that can manage the process and training as well as build or acquire the tools. One of the earliest findings of the BSIMM study of software security initiatives was that pretty much every company's software security program includes such a team. In my experience, the effectiveness of the software security team is critical to the success of the software security program.

But where should the software security team sit within the organization? My view is that a software security team that's part of, or aligned with, the development organization is more likely to succeed than one that's part of a compliance or audit function. In part, it's the difference between a predilection to build security in and one to test security in after the fact.

There's also a cultural aspect to having the software security team closely aligned with the development organization. Even though the software security team isn't an audit or compliance function, part of its job is to deliver unpleasant messages. I remember times when I was leading a software security team and had to change the requirements for our security development life cycle process very late in the release cycle of a major product. A new class of security vulnerability had been discovered and publicized, and our choice was either to run a pretty immature tool late in the product release cycle and triage and fix the bugs it reported or to "take the risk" and wind up handling a ton of vulnerability reports immediately after the product shipped.

We chose to require the product teams to run the tool. Nobody was happy with that choice, including the security team, but we were able to defend the requirement as the better option for the company, the product, and the customers. Part of the reason was that most of the software security team members had product team experience and could remind product team folks of the consequences of not fixing vulnerabilities when we could: "Remember the awful press when the 'so-and-so' vulnerability was disclosed and exploited?" "Remember the fire drill when all those vulnerabilities were reported right after "version x" shipped?" Nobody was crazy about our decision, but everybody was less crazy about the alternative.

How did we find the folks to work on the product security team? As we started down the software security path, we discovered that most product teams had one or a few members who were really "into" security. Those were the developers or testers who filed really interesting — and important — security bugs during security bug bashes. They were the program managers who created really accurate and useful threat models, or who pushed effectively to get security bugs fixed. They were the folks who created their own tools to identify new kinds of security problems and shared them across their team. Some of them were passionate about their product team and chose to work as formal or informal security champions but others discovered they really wanted to spend full time working on software security. They naturally gravitated toward our software security team.

Our "product team hires" not only helped make products more secure, they also helped us teach new security team hires from outside the company about product teams' functioning and culture. And they were among our most effective advocates for integrating security into the culture of product teams. Hiring great security people from product teams is an effective way to build a software security team. And the product teams aren't likely to push back too much — they'll be happy to have people in the software security team who understand the challenges and realities of shipping.

 

 

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

Steve Lipner is the executive director of SAFECode. He was the creator and long-time leader of the Microsoft Security Development Lifecycle (SDL), an achievement that was recognized in 2017 with his election to the National Academy of Engineering.  He has also been ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
The Mainframe Is Seeing a Resurgence. Is Security Keeping Pace?
Ray Overby, Co-Founder & President at Key Resources, Inc.,  8/15/2019
GitHub Named in Capital One Breach Lawsuit
Dark Reading Staff 8/14/2019
The Flaw in Vulnerability Management: It's Time to Get Real
Jim Souders, Chief Executive Officer at Adaptiva,  8/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-15296
PUBLISHED: 2019-08-21
An issue was discovered in Freeware Advanced Audio Decoder 2 (FAAD2) 2.8.8. The faad_resetbits function in libfaad/bits.c is affected by a buffer overflow vulnerability. The number of bits to be read is determined by ld->buffer_size - words*4, cast to uint32. If ld->buffer_size - words*4 is ne...
CVE-2019-15292
PUBLISHED: 2019-08-21
An issue was discovered in the Linux kernel before 5.0.9. There is a use-after-free in atalk_proc_exit, related to net/appletalk/atalk_proc.c, net/appletalk/ddp.c, and net/appletalk/sysctl_net_atalk.c.
CVE-2019-15293
PUBLISHED: 2019-08-21
An issue was discovered in ACDSee Photo Studio Standard 22.1 Build 1159. There is a User Mode Write AV starting at IDE_ACDStd!IEP_ShowPlugInDialog+0x000000000023d060.
CVE-2019-5034
PUBLISHED: 2019-08-20
An exploitable information disclosure vulnerability exists in the Weave Legacy Pairing functionality of Nest Cam IQ Indoor version 4620002. A set of specially crafted weave packets can cause an out of bounds read, resulting in information disclosure. An attacker can send packets to trigger this vuln...
CVE-2019-5035
PUBLISHED: 2019-08-20
An exploitable information disclosure vulnerability exists in the Weave PASE pairing functionality of the Nest Cam IQ Indoor, version 4620002. A set of specially crafted weave packets can brute force a pairing code, resulting in greater Weave access and potentially full device control. An attacker c...