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
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
How a Manufacturing Firm Recovered from a Devastating Ransomware Attack
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/20/2019
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
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-7201
PUBLISHED: 2019-05-22
CSV Injection was discovered in ProjectSend before r1053, affecting victims who import the data into Microsoft Excel.
CVE-2018-7803
PUBLISHED: 2019-05-22
A CWE-754 Improper Check for Unusual or Exceptional Conditions vulnerability exists in Triconex TriStation Emulator V1.2.0, which could cause the emulator to crash when sending a specially crafted packet. The emulator is used infrequently for application logic testing. It is susceptible to an attack...
CVE-2018-7844
PUBLISHED: 2019-05-22
A CWE-200: Information Exposure vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause the disclosure of SNMP information when reading memory blocks from the controller over Modbus.
CVE-2018-7853
PUBLISHED: 2019-05-22
A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause denial of service when reading invalid physical memory blocks in the controller over Modbus
CVE-2018-7854
PUBLISHED: 2019-05-22
A CWE-248 Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a denial of Service when sending invalid debug parameters to the controller over Modbus.