RSAC 2018: Building a Software Security Maturity Program
Building an internal, holistic software security program that can mature over time can be challenging.
In Realizing Software Security Maturity: The Growing Pains and Gains presented at RSAC 2018, Senior Application Security Engineer Kelby Ludwig and Director of Application Security Mark Stanislav explain how they did it at Duo.
.@kelbyludwig breaks down the difference between two software security maturity models, BSIMM & SAMM #rsac2018 - South 208 pic.twitter.com/NzNWJGmKo7
— Duo Security (@duosec) April 17, 2018
Kelby listed out the strategic and tactical practices a software security program might take, including a comparison of Building Security in Maturity Model (BSIMM) and Security Assistance Management Manual (SAMM).
Typically, the percentage of our Application Security (AppSec) team members to our Product Engineering staff is 10.9.
At Duo, our AppSec team has a few key team values:
Engineering is Family - Maintaining a good relationship between Security and Engineering means seeking to empower engineers with knowledge, while ensuring interactions are empathetic, patient and respectful.
Low Friction, High Value - We need to show actual value in the things that we do (rather than doing best practices that are ineffective), meaning less roadblocks while being more mindful of overhead on engineers.
Build a Paved Road - We want to provide Engineering with the capabilities to efficiently solve complicated problems. This means building in guardrails to help engineers feel confident and help them accelerate innovation and output - giving AppSec more time to spend on problems with less clear solutions.
How Could It Go Right? - The AppSec team should seek to enable, inform and contextualize risks that could be introduced by a new feature or design to encourage and support innovation for Engineering, and avoid being the team of "no."
No Code Left Behind - At Duo, we're building out a full inventory of our wide variety of software (including many different languages) that we integrate with to support two-factor authentication. It's important to ensure that security testing accounts for old code changes in new deploys.
At Duo, we've implemented both controls that exist in BSIMM and SAMM - both prescriptive and descriptive models, while still retaining the ability to add context that is important to our organization. The AppSec team calls this the Duo Application Security Maturity Model (DASMM).
At Duo, we strongly prefer standardization over reinventing the wheel - we took existing standards and modified them for our needs. We prefer to not spend a lot of time resolving already-solved problems.
Mark went over the Security Development Lifecycle (SDL), which includes training, requirements, design, implementation, verification, release and response.
The AppSec team holds formal training with guest speakers, sends out surveys to Engineering to gauge security skill and interest, and provides informal, gamified training Capture the Flag (CTF) and card-game tournaments to encourage security learning.
When it comes to threat modeling, or reviewing software design to contextualize actual threats and risk, it is a collaborative process with engineers. They often take pride in understanding how people break their software. At this stage, we will decide what is a priority threat model, as not every problem can be addressed.
Many companies only conduct the security assessment stage (a final pentest) that finds a lot of bugs. For us, this should be a re-validation of everything we've already seen in the prior stages. It's important to remember that the scope of the software you're looking at isn't the entire security model. Once integrated with other software, the security model at final deployment can change quite a bit.
The AppSec team also provides ad-hoc help, including the review of small code diffs and proactive searching (not waiting for people to approach them). They also hold office hours open to engineers, which helps realize the low-friction, high-value approach.
They also have an AppSec intake form that allows engineers to submit issues, which helps keep the security reporting process frictionless. The AppSec team also provides a formal report for major assessments, code models and reviews, which sets a level of professionalism within the organization, can be used for customer reviews, compliance and incident response purposes.
Find stakeholders within your engineering team that are security champions, invest in them and scale up your security efforts through those people - even if you don't have the headcount to do that as a dedicated role.