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.

Application Security

9/19/2019
04:15 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

BSIMM10 Emphasizes DevOps' Role in Software Security

The latest model, with insights from 122 firms, shows DevOps adoption is far enough along to influence how companies approach software security.

DevOps has reached a point in its adoption at which it influences the way organizations approach software security. Many businesses have implemented an engineering-led security culture to establish and grow software security efforts, researchers say in the BSIMM10 report.

The Building Security in Maturity Model (BSIMM), now in its 10th edition, is the product of a multiyear study of real-world software security initiatives (SSIs) seen in 122 businesses. Synopsys researchers annually compile the BSIMM report to help organizations develop software maturity programs with insights and guidance from real-world firms across industries.

They call the BSIMM a "measuring stick" for software security. Firms can compare the report's findings to their own projects and gain a better sense of how other organizations are handling the same initiatives. "You can identify your own goals and objectives, then refer to the BSIMM to determine which additional activities make sense for you," according to the report.

Ten years ago, security was a differentiator for highly regulated firms, many of which build a governance-driven software security initiative to drive security across their portfolio, explains Sammy Migues, information security visionary at Synopsys and one of the report's authors.

Now, BSIMM10 shows changes in how companies approach software security. A new wave of engineering culture is driving security efforts from engineering teams. There are two major factors in the shift: First is the convergence of process friction, unpredictable effects on delivery schedules, tense relationships, and more human-intensive processes from current SSIs. Second are demands and pressures from modern software delivery methods like Agile and DevOps. As a result, engineering has begun to prioritize automation over human-driven tasks, experts say. Decisions that used to fall to five-person meetings can be made more quickly with Python.

There are more issues at play when it comes to engineering culture, Migues says. Management has been asking more of development teams over the past few years, and developers have dealt with new languages, security requirements, deployment environments, and other changes. Modern ops teams use new logging and analysis methods; emphasis is on efficiency.

"Anything that represents friction or opaqueness is sort of getting pushed aside," he adds. "If security is too slow for the dev team, the dev team is going to do its own security." The "old school" security team has to learn how to play in the DevOps culture, Migues emphasizes. Developers' natural response to managerial pressure is to deliver more software, and faster.

What This Means for Security Groups
The industry is seeing the rise of an organizational structure that values SSI but doesn't integrate software security groups (SSG) into the process as an assigned group, the BSIMM10 reports. The SSG starts organically, usually within the engineering group. Engineers take on roles like "BuildSec," "ContainerSec," and "DeploymentSec," testing out specific capabilities like operations security or incident response before they form dedicated security-specific divisions.

In the past year, he says, researchers have noticed a rise in software security efforts within engineering organizations as engineers build out their own security capabilities. "They're taking all these little piece parts of security related to software, and they're doing it themselves," says Migues, noting that this often happens outside the view of the central security department.

Security teams have become accustomed to testing software after its completion and deciding then whether the code is strong enough to go into production. In the future, he says, security teams will become part of the application life cycle, or "value stream," to use a DevOps term.

"If you're not part of the value stream, you're going to be ignored," Migues adds. It's not a question of hiring, he explains. It's a matter of security catching up to the DevOps culture. "You aren't going to solve tomorrow's security problems by hiring more security people."

New Additions to the BSIMM
Researchers adjusted the descriptions of several activities, and added three new ones, to the BSIMM so as to reflect what firms are doing to integrate software security. The three activities in BSIMM10 include software-defined life cycle governance, software-assisted monitoring of software-defined asset creation, and automated verification of software-defined infrastructure.

These additions reflect how businesses are working on ways to accelerate security to match the speed of delivering functionality to market. "These are also direct offshoots of this new engineering-driven culture that's sort of dragging security behind it," Migues says. Most organizations don't have a top-down push to build security into development. Instead, pockets of security are happening at the bottom and getting pulled to the top across the dev team.

It's important to understand the difficulty of integrating security into DevOps greatly varies depending on the organization, he continues. Those who are doing DevOps well have homogeneous software portfolios, which gives them an advantage. Netflix, for example, has one application and, consequently, one development culture, Migues explains. "Changing a culture in that kind of homogeneous environment is not that hard," he continues. While the process can certainly take a long time, it's more streamlined to rally everyone around a common goal.

In contrast, a Fortune 500 bank may have thousands of applications and several development teams. A process that works for one application may take years to spread across an entire bank, he adds. Smaller companies also have it easier because they have fewer heterogeneous environments. Fewer tech stacks enable a more seamless process than in larger companies.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "The 20 Worst Metrics in Cybersecurity."

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19010
PUBLISHED: 2019-11-16
Eval injection in the Math plugin of Limnoria (before 2019.11.09) and Supybot (through 2018-05-09) allows remote unprivileged attackers to disclose information or possibly have unspecified other impact via the calc and icalc IRC commands.
CVE-2019-16761
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the [email protected] npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. All versions >1.0...
CVE-2019-16762
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the slpjs npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. Affected users can upgrade to any...
CVE-2019-13581
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A heap-based buffer overflow allows remote attackers to cause a denial of service or execute arbitrary ...
CVE-2019-13582
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A stack overflow could lead to denial of service or arbitrary code execution.