Yes, You Can Measure It With The BSIMM - Jonathan Cartu Internet, Mobile & Application Software Corporation
671
post-template-default,single,single-post,postid-671,single-format-standard,qode-quick-links-1.0,ajax_fade,page_not_loaded,,qode_grid_1300,qode-theme-ver-11.2,qode-theme-bridge,wpb-js-composer js-comp-ver-5.2.1,vc_responsive
 

Yes, You Can Measure It With The BSIMM

Yes, You Can Measure It With The BSIMM


You can debate—in fact there is some ongoing debate—whether it’s possible to measure overall cybersecurity in the business world.

But there should be no debate that it is possible to measure one of cybersecurity’s chief components: software security. The BSIMM (Building Security In Maturity Model), a one-of-a-kind observational model built from real-world data by the Synopsys Software Integrity Group, has been making that possible for more than a decade. Nearly 200 companies can now attest to its usefulness as a management tool. 

Indeed, with the release of BSIMM10 this week, there are now 119 data points in that measurement. That is the number of individual activities (you can think of them as controls) the BSIMM observational model has gathered across the software security initiatives (SSIs) of 122 organizations, primarily in eight industry verticals: cloud, internet of things (IoT), independent software vendors (ISV), high technology, healthcare, insurance, financial services and retail. 

Not that every activity is mandatory for every firm, or even recommended. It is up to individual organizations to decide for themselves which activities will help them achieve the right software security posture across their application portfolio. 

That’s because, from the beginning, the goal of the BSIMM has been to observe and report, not dictate or direct. It makes it clear up front that it is a “measuring stick” for software security that includes some “how to” guidance culled from 10 years of direct experience, but it doesn’t try to be a one-size-fits-all “what to do” guide. That journey is personal for every organization.

Instead, the BSIMM functions as a “what’s happening now” guide. The activities are grouped under 12 practices that are, in turn, grouped under four domains: governance, intelligence, SSDL (secure software development lifecycle) and deployment.

The activities show what participating organizations are doing and the types of tools they are using to enable their SSIs. Perhaps more importantly, the BSIMM shows how often each activity has been seen in the current data pool. That allows any organization—those participating and those that aren’t—to see what is useful, or perhaps not useful, for others in their industry and across all verticals.

BSIMM reports are free to download, licensed under the Creative Commons Attribution-ShareAlike 3.0 license.

All of which can take any firm a long way toward knowing how to measure and improve its software security. Also scattered through the practices are references to specific types of tooling to improve security. They include those for automation, multiple types of software analysis, fuzz testing and penetration testing.

An ongoing evolution

The BSIMM is an annual exercise, in part because software security practices continue to evolve—rapidly. This year’s report, authored by Sammy Migues, principal scientist, and Michael Ware, managing principal, both at Synopsys; and John Steven, former senior member, technical, at Synopsys and now CTO at ZeroNorth, is an example of that. This year’s report notes two significant evolutionary changes:

DevOps’ impact:The BSIMM10 data show that the DevOps movement, along with growth in CI/CD tooling and digital transformation, is affecting the way firms approach software security. 

So BSIMM10 has updated activity descriptions to reflect these changes. It also adds three new activities to reflect how firms are working to make sure “building security in” to software development doesn’t slow it down.

The new activities focus on automation, first because it is replacing much slower human- and document-driven application lifecycle management processes. 

But second, while automation fulfills the need for speed, it needs oversight. So two other activities focus on monitoring automated creation of virtual assets and making sure those assets adhere to security expectations, not only when they are created but also over the long term.

Engineering taking a driver’s seat: SSI culture is changing—there is a new wave of engineering-led software security efforts originating bottom-up in development and operations teams rather than top-down from a centralized software security group (SSG). 

The report reflects that, noting that the change is “in response to both the demands of modern software delivery practices such as Agile and DevOps as well as undesirable friction with existing SSIs.”

The engineering-driven cultures “prioritize speed and automation, prototyping controls incrementally and building on the existing tools and techniques that already drive software delivery.”

Despite the different and sometimes competing priorities and approaches of the top-down and bottom-up cultures, sometimes they both exist within the same organization. “Aligning them while maintaining a single coherent SSI direction will require a concerted effort by all stakeholders,” the report says. As in, it’s important to play nicely together. 

Migues, who has been an author of the BSIMM report since the beginning, said he sees this culture shift as likely to create some turmoil over the next several years. But ultimately, he said, “it will be a good thing.”

“Although it’s adversarial, it’s not the end of the world,” he said. “We have no idea how developers will be developing code in five years, so to imagine how it’s going to look then is foolishness. But ultimately, the [software security] ship is going to go truer, better and faster.”

Three stages of maturity

Besides those changes, the BSIMM10 data reinforce an encouraging trend seen from the start—when organizations put in the time and energy, their SSIs “grow up.” They mature, as intended. This is clear enough in the data to prompt this year’s report to define three phases of SSI maturity—emerging, maturing and optimizing. 

The three stages essentially reflect the labels. An “emerging” SSI is just starting. A team has been “tasked with booting a new SSI from scratch or formalizing nascent or ad hoc security activities into a holistic strategy,” the report says. 

The initial strategy will include some foundational activities, there will be some money and staff to support…

[

Computer Network Development Jon Cartu

Source link

No Comments

Post A Comment