informa
Commentary

NIST Brings Threat Modeling into the Spotlight

NIST recommendations typically become part of government procurement, which means threat modeling will soon be written into questions for organizations that sell to the federal government.

One noteworthy element of the National Institute of Standards and Technology's recent Recommended Minimum Standard for Vendor or Developer Verification of Code is the prominence given to threat modeling, which is ranked first in NIST's six recommended technique classes for software verification, alongside more traditional (but still important) methods, including automated testing, code-based analysis, dynamic analysis, check included software, and fixing bugs.

NIST recommends that threat modeling should be done "multiple times during development, especially when developing new capabilities, to capture new threats and improve modeling."

This is a welcome addition to US government recommendations and aligns with a growing recognition that threat modeling is a critical software security practice. We can also see this from the Food and Drug Administration's premarket cybersecurity guidance and a series of threat modeling boot camps.

The inclusion is significant because NIST's recommendations are designed to be adopted into government procurement processes, which means threat modeling will soon be written into procurement questions for organizations that sell to the federal government. NIST doesn't have the authority to directly mandate this standard.

There are also implications for the wider software industry because once government suppliers begin to implement NIST's recommendations, there'll be a trickle-down effect through the market. Software developers will adopt the recommended security practices to remain competitive and to avoid barriers to supplying the federal government in the future.

As NIST brings threat modeling to the fore, this is a moment for forward-thinking organizations to begin to put it into practice. Not only will it help them get ahead of the game, win new contracts, and meet compliance, it will also have a substantial and positive impact on software security and help organizations derive more value, efficiency, and collaboration from their development teams.

What Is Threat Modeling?
The first place for organizations to start is to familiarize themselves with what NIST means by threat modeling. The Threat Modeling Manifesto, a consensus document from 15 experts, defines it as "analyzing representations of a system to highlight concerns about security and privacy."

In simple terms, threat modeling enables organizations to visualize and identify potential threats in software even before a line of code has been written. This allows developers and security teams to avoid design mistakes, and informs decisions in design, development, testing, and operations.

Good threat modeling always focuses on answering four 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?

    There are many wins when you consider these factors right from the outset. This is what we call "starting left in software security," a progression of the shift-left movement that has been dominant in software security for years. You can find flaws and vulnerabilities that other techniques cannot. It saves time and money by finding and addressing potential threats earlier, which means developers don’t have to go back and redesign software to fix vulnerabilities when the product is close to deployment.

    It also means that delivery becomes more predictable because you avoid surprises from penetration testers. And you gain the ability to plan both development and testing by helping teams understand what's being built and how to secure it.

      One of the greatest benefits of threat modeling is actually not technical but cultural, as it provides security language for engineers who want to build secure applications. We believe all engineers want to ship quality code, but they don’t always know how, and there’s always pressure to ship faster.

      If developers are given the tools and training to ensure their code is security-fit-for-purpose from the outset, and security teams work to help them measure and analyze the work, it creates a healthy outcome where security is treated as the responsibility of the engineers. This approach requires threat modeling tools, like the four-question framework, that are understandable by people across the company.

      Threat Modeling as a Starting Point
      The immediate and most important benefit of implementing threat modeling, however, is to identify threats that may appear throughout the design process so that the appropriate countermeasures can be put in place. This is presumably why it tops the list of NIST's recommendations — if threat modeling is undertaken at the outset, it feeds and informs all subsequent security activities. The ultimate objective of the recommended minimum standard is, after all, to ensure software used within the federal government is robust.

      The good news for organizations is that threat modeling can generate quick wins and scale across an organization once the fundamentals are in place, especially if organizations make the most of breakthroughs in automation. Developers are already extremely busy and AppSec teams (where they even exist) are stretched. Therefore, organizations will do well by automating what can be automated, through threat libraries and intelligence from other threat models that can be shared across development teams.

      Recommended Reading: