During a threat modeling exercise for a large development team, hacker and security advocate Alyssa Miller was floored when a developer commented that it would be great when the team moved to a DevOps software development framework.
The misconception? That threat modeling would no longer be required under an agile software development methodology. Yet the discipline is widely applicable to every aspect of business, including development and DevOps software life cycles, Miller says.
"The attitude of a lot of organizations is that they look at DevOps as incompatible with threat modeling because threat modeling is traditionally seen as this giant, onerous task," she says. "But if you understand the purpose of threat modeling, you can streamline it and do it in a different way that it fits in DevOps."
On Nov. 17, Miller and 14 other security professionals published the "Threat Modeling Manifesto," a document spelling out the general principles of how best to consider attack vectors on software. As a blueprint, the document uses the style and content of the "Agile Manifesto," a statement published by 17 developers nearly two decades ago that set out simple and elegant goals for agile software developers.
The threat modeling advocates aim to simplify the discipline to its essential concepts in hopes of making threat modeling more popular, says Chris Romeo, CEO of Security Journey, an application security training program.
"The whole point is to try to solve this common problem — what are the principles that we use to drive threat modeling in our daily practice?" he says. "It is not a how-to guide. It is not methodology-specific. It is about how we get people to understand threat modeling and implement it in their organizations."
The original "Agile Manifesto" came out of the principles behind a number of development methodologies, such as scrum and pragmatic programming. The "Threat Modeling Manifesto" distills current application security processes for agile software down to four basic questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?
In addition, the manifesto attempts to focus developers on five values — security culture, a focus on people, treating security as journey, continuous refinement, and modeling threats — rather than talking about the process.
"We believe that following the guidance in the Manifesto will result in more effective and more productive threat modeling," the group stated in the document. "In turn, this will help you to successfully develop more secure applications, systems, and organizations and protect them from threats to your data and services. The Manifesto contains ideas, but is not a how-to, and is methodology-agnostic."
Businesses that avoid regular threat modeling put themselves at an increased risk of compromise. Many companies put threat modeling — or, more specifically, digital footprint or attack surface identification — behind both indicators of compromise and threat intelligence in terms of importance, according to the "2020 SANS Cyber Threat Intelligence (CTI) Survey."
By simplifying threat modeling, the security group hopes to make it more likely that businesses — and particularly developers — will include threat models in their processes. Miller recommends that developers and application security teams write information about threats in plain language in the user story.
"Now it all comes together into the software development pipeline, where it all flows to the various components of DevOps," she says. "It is all about continuous improvement anyway. We know that one practice is not going to secure the world, but we want to make sure that we are a little bit better tomorrow than we are today."
Because developers outnumber application security professionals (some experts put it at 100 to 1), threat modeling has to be done by more than just the application security team, says Security Journey's Romeo.
"We think threat modeling is the biggest bang-for-the-buck type of activity that you can do in application security," he says, "We all agree that threat modeling is something that the developers have to do. There is no way that application-security teams can do all the threat modeling."