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
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19317
PUBLISHED: 2019-12-05
lookupName in resolve.c in SQLite 3.30.1 omits bits from the colUsed bitmask in the case of a generated column, which allows attackers to cause a denial of service or possibly have unspecified other impact.
CVE-2019-19602
PUBLISHED: 2019-12-05
fpregs_state_valid in arch/x86/include/asm/fpu/internal.h in the Linux kernel before 5.4.2, when GCC 9 is used, allows context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact because of incorrect fpu_fpregs_owner_ctx caching, as demonstr...
CVE-2019-19601
PUBLISHED: 2019-12-05
OpenDetex 2.8.5 has a Buffer Overflow in TexOpen in detex.l because of an incorrect sprintf.
CVE-2019-19589
PUBLISHED: 2019-12-05
The Lever PDF Embedder plugin 4.4 for WordPress does not block the distribution of polyglot PDF documents that are valid JAR archives.
CVE-2019-19597
PUBLISHED: 2019-12-05
D-Link DAP-1860 devices before v1.04b03 Beta allow arbitrary remote code execution as root without authentication via shell metacharacters within an HNAP_AUTH HTTP header.