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
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "The security team seem to be taking SiegeWare seriously" 
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-2012-1114
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the filter parameter to cmd.php in an export and exporter_id action. and the filteruid parameter to list.php.
CVE-2012-1115
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the export, add_value_form, and dn parameters to cmd.php.
CVE-2012-1592
PUBLISHED: 2019-12-05
A local code execution issue exists in Apache Struts2 when processing malformed XSLT files, which could let a malicious user upload and execute arbitrary files.
CVE-2019-16770
PUBLISHED: 2019-12-05
A poorly-behaved client could use keepalive requests to monopolize Puma's reactor and create a denial of service attack. If more keepalive connections to Puma are opened than there are threads available, additional connections will wait permanently if the attacker sends requests frequently enough.
CVE-2019-19609
PUBLISHED: 2019-12-05
The Strapi framework before 3.0.0-beta.17.8 is vulnerable to Remote Code Execution in the Install and Uninstall Plugin components of the Admin panel, because it does not sanitize the plugin name, and attackers can inject arbitrary shell commands to be executed by the execa function.