• How do engineering-led security cultures work in practice?
  • Has DevOps culture changed what security does, how it’s done—or both?
  • As an industry, are we getting any better at this?

As co-author of the new BSIMM10 study, which is the latest version of the Building Security In Maturity Model announced on September 18, 2019, we set out to answer these and other questions related to how organizations are executing their software initiatives using concrete data pulled from more than 120 recognizable organizations—including Aetna, General Electric, The Home Depot, and Wells Fargo.

I’ll be speaking at the BSIMM North American Conference in San Diego next week. Before that, however, I wanted to share some of what we learned this year.

The BSIMM study provides a framework for companies seeking to mature their security programs using best-in-class firms as a point of reference. By looking at how those on the front end of security are attacking their problems, BSIMM provides actionable recommendations for others to follow.

This year, one of the most important themes we’ve seen arise—both through the BSIMM data and other research, such as from Gartner—is an increased interest in engineering-led efforts. Put simply, an engineering-led security culture is one of the capabilities associated with an organization’s security initiative, conceived and implemented by folks within the engineering organization rather than a central and separate security team. In other words, engineering and development drive security for the products they develop.

Engineering-led cultures also help drive to product-centric models, rather than centralized governance-centric, which has been the norm. Here, again, it’s about moving control to those that are closest to the product itself—engineering and development. This is a significant change from the historical operating model where a central security team pushes requirements and policies to engineering without necessarily having a strong understanding of the product and the customer.

A recent Gartner survey reported that 85% of firms have either adopted (or plan to adopt) a “product centric” application delivery model; the survey also reports that this model was used for 40% of their work in 2018. Gartner’s Bill Swanton indicated this finding goes hand in hand with the adoption of a more agile DevOps culture. BSIMM10 concludes that engineering-led security initiatives are gaining traction and can be effective, something the survey didn’t observe in prior years. Based on the data we’ve seen, security is getting closer and closer to the front end of product development. Firms can no longer afford to ignore this trend.

Engineering-led security initiatives are changing their firm’s risk management paradigm, from proactive governance through security assurance to resilient delivery pipelines that rapidly respond to continuous security telemetry. They aren’t just “trying something new” in one or two teams—but rather, using techniques at scale across their software and infrastructure portfolios. They’re continuing those behaviors year on year.

This shift to engineering-led efforts is having a material impact on how organizations prioritize security activities. This year’s BSIMM study spells this out, as firms are now focusing more effort on security initiatives that are central to development, such as:

  • Monitor automated asset creation [AM3.3]
  • Automated verification of operational infrastructure security [CMVM3.5]
  • Integrate SW-defined lifecycle governance [SM3.4]

In plain terms, we find firms: (these mirror the above)

  • Attempting to get a handle on their attack surface and inventory, particularly in terms of where their responsibilities are increased by self-service IT in the cloud
  • Reduce effort by driving automated compliance to infrastructure security standards
  • Automate as much of the vulnerability discovery process as possible, to make risk decisions in real time

In summary, engineering-led security cultures deliver more of their efforts as code and automation, rather than as policy/process documentation. This includes things like organization-specific SAST rules in the build rather than coding standard documents, security features and the enablement of services rather than remediation advice—and so forth.

So, we are getting better at this—and automation is key to that. But with automation comes its own risks. We can’t avoid the “think” steps intrinsic to building and maturing a security initiative—risk-based controls tuned to an organization’s tolerances and to the particular exposure business applications represent. Threat modeling, and other techniques, also work best when driven by humans in a thoughtful risk-based way.

The bottom-line is, as organizations seek to differentiate themselves and operate in a software-centric delivery model, engineering-led cultures will be enablers. I encourage security practitioners to take a few minutes to read the BSIMM study and consider which of these recommendations might be beneficial, now or in the future.

Share This