You are here

Home/Security/Application Security

You are here

Home/Security/Application Security
Put it to work on your software team

Threat modeling gets its manifesto: Map out your app sec risk first

public://pictures/John-Mello-Journalist.png
John P. Mello Jr. Freelance writer
 

Despite its importance in creating a proactive posture toward cyber attacks, threat modeling remains largely misunderstood by many organizations. To clarify matters, a group of 15 security community leaders released the Threat Modeling Manifesto to inform and educate other practitioners as well as to inspire them to adopt threat modeling and improve security and privacy during software development.

Marc French, one of the manifesto's creators and the CISO and managing director of the Product Security Group, said the main aim of the Manifesto was to share best practices—and to stress why threat modeling is so important.

"There's always been a misconception about threat modeling. People do it a bunch of different ways. There isn't a lot of guidance about why it's important, when it should be done."
—Marc French

Here's what you need to know about the manifesto, and how to put it to work on your own software team.

The manifesto explained

Crafted along the lines of the Agile Manifesto, the Threat Modeling Manifesto contains ideas but isn't a how-to and is methodology-agnostic. It consists of a statement of values and principles. These include:

Values

  • A culture of finding and fixing design issues over checkbox compliance
  • People and collaboration over processes, methodologies, and tools
  • A journey of understanding over a security or privacy snapshot
  • Doing threat modeling over talking about it
  • Continuous refinement over a single delivery

Principles

  • The best use of threat modeling is to improve the security and privacy of a system through early and frequent analysis.

  • Threat modeling must align with an organization’s development practices and follow design changes in iterations that are each scoped to manageable portions of the system.
  • The outcomes of threat modeling are meaningful when they are of value to stakeholders.
  • Dialog is key to establishing the common understandings that lead to value, while documents record those understandings and enable measurement.

Kim Wuyts, a contributor to the manifesto and a privacy researcher at the DistriNet Research Group at KU Leuven, said that while practical approaches to threat modeling may differ, SecOps teams can all agree on these common principles and values that form the foundation for threat modeling practices.

"We hope this manifesto can be of inspiration to other threat modelers, both experienced ones and those new to the field."
—Kim Wuyts

Good and bad patterns

The manifesto also delineated patterns that benefit threat modeling, as well as those that don't.

Good patterns

  • Achieve thoroughness and reproducibility by applying security and privacy knowledge in a structured manner.
  • Allow for creativity by including both craft and science.
  • Assemble a diverse team with appropriate subject-matter experts and cross-functional collaboration.
  • Support your approach with tools that allow you to increase your productivity, enhance your workflows, enable repeatability, and provide measurability.
  • Use successfully field-tested techniques that are aligned to local needs and that are informed by the latest thinking on the benefits and limits of those techniques.

Bad patterns

  • Threat modeling does not depend on one’s innate ability or unique mindset; everyone can and should do it.
  • Go beyond just analyzing the problem; reach for practical and relevant solutions.
  • Do not lose sight of the big picture, since parts of a model may be interdependent. Avoid exaggerating attention on adversaries, assets, or techniques.
  • It is better to create multiple threat modeling representations because there is no single ideal view, and additional representations may illuminate different problems.

Why threat modeling matters

Threat modeling is sometimes misunderstood because it brings together two groups with goals that can conflict. Performing a thorough analysis with a structured threat modeling process can help define how likely it is that an issue is a risk, said Charles Ragland, a security engineer with Digital Shadows.

"Determining these risk levels can often be the source of misunderstandings between security professionals and developers, as each group has different goals."
—Charles Ragland

What makes threat modeling so important is that it can identify security design issues before any code is written, when the project is still on paper, said Sherif Koussa, founder of Software Secured.

"Compare that to finding flaws after the source code has been written when it can become very expensive, if not impossible, to make design or control changes."
—Sherif Koussa

Threat modeling is imperative to proactively secure applications by conceptualizing fundamental flaws within an application's architecture or design, said Ben Pick, a senior application security consultant with nVisium.

"If done correctly, it will assist with eliminating technical debt due to integrating security as an afterthought."
—Ben Pick

Getting started with threat modeling

While every organization's threat modeling journey will have its own twist and turns, here are some things to keep in mind when embarking on the process.

Threat modeling is essentially a manual process, said Software Secured's Koussa.

"The teams have to sit down and discuss architecture. They have to talk out the threat model. That's why it's different from things like static and dynamic code analysis. It can't really be automated as static and dynamic analysis can."
—Sherif Koussa

Threat modeling should be used to identify the big problems in a project, said Product Security Group's French.

"Threat modeling identifies the big architectural flaws in your project that are not going to be caught by a technology scan. It focuses on those big, hard-to-crack problems that don't get solved by running security tools over the top of your code."
—Marc French

nVisium's Pick said that threat modeling should be initially done in the project's design phase.

"To minimize time spent on developing a threat model, it should be created right after—or if possible, in tandem with—the software and architectural design phase has been completed within the SDLC. Doing so allows developers and security champions to fully understand the design and architecture of the application to better inform scoping of potential threats."
—Ben Pick

Brandon Hoffman, CISO at Netenrich, said threat modeling is a continuous process. "As is the case with most things in security, there is no time when it is done. It must always be changing and adapting as the threat landscape changes."

Koussa added that it has to be done every time a company designs a new feature or product, because "a lot of the time, software developers will just jump into code without thinking about security."

Reduce friction to make it happen in your organization

For threat modeling to take root in an organization, the value of threat modeling must be demonstrated to participants, Said French.

"I usually start upstream. I start with the product management organization before I get to the engineers. I explain why it's important to have their customers do these things. So when it's time to talk to the engineers, it's a much different conversation. It's about what the customer expects because it's what they see from your competitors. That reduces friction."
—Marc French

Developer buy-in to threat modeling can also be acquired by appealing to their desire to produce quality code, French added:

"For engineers, it's all about software craftsmanship. Secure apps are considered quality apps, and engineers want to push out quality code."

Keep learning

Read more articles about: Security, Application Security
Twitter Twitter Facebook Watsapp Email share