NIST’s Threat Modeling Recommendation and Methodology

The National Institute of Standards and Technology (NIST) has recommended threat modeling as the first technique (out of six recommended techniques) for software security [1]. This was defined as part of NIST's responsibilities and initiatives under Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity (in the US) [2].

NIST has also previously published its guidance methodology for threat modeling (NIST 800-154) that organizations can use as part of their risk assessment and management processes [3]. The methodology is defined as data-driven, i.e., focusing on the security of particular instances of data, and it is aligned with the four key questions framework as described by the Threat Modelling Manifesto [4][5]. This shows a consensus in the community of what threat modeling means and helps drive more focus on further automation and relevant content to secure systems and software right from the outset.

NIST’s Recommendation

NIST’s recommendation of threat modeling is part of a growing realization and awareness in the community that this practice is critical for systems and software security. Several other organizations, including OWASP, SANS, the FDA [6], and Gartner [7] all see threat modeling as a fundamental component of secure design.

NIST recommends conducting threat modeling early, and then multiple times during development. The NIST guideline [1] refers to the DoD Enterprise DevSecOps Reference Design document [8] on how to integrate threat modeling into the DevSecOps pipeline. NIST indicated that threat modeling can identify input vectors that are of most concern, and their test cases should be defined and adapted based on their potential impact, i.e., should be more comprehensive in areas of greatest consequences.

NIST’s Methodology

NIST states that threat modeling allows organizations to consider specific security needs of the system and data, going beyond generalized "best practice" recommendations. In its NIST 800-154 publication [3], it presents a set of principles and a methodology for doing data-centric threat modeling. While it places more focus on data security, e.g., the operational unavailability of a system that does not host the data of interest would be out of scope, the presented methodology can also be used to achieve any security objective for other systems and applications in terms of protecting their CIA (Confidentiality, Integrity, and/or Availability).

The threat modeling approach presented in the NIST 800-154 publication has four steps:

Identify and characterize the system and data of interest;
Identify and select the attack vectors to be included in the model;
Characterize the security controls for mitigating the attack vectors; and
Analyze the threat model.

These steps can be directly mapped to the four key questions framework, initially introduced by Adam Shostack, and referenced in the Threat Modelling Manifesto [4]:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?

The document explains what 'characterization' means in the context of data-centric threat modeling. It includes the list of 1) Authorized locations for the data, 2) How the data moves, 3) The security objectives (in terms of CIA), and 4) Who or what process can access the data. This will guide the following steps, in terms of the identification of attack vectors, e.g., per data location, and then for each selected attack vector, the security controls that would mitigate the associated risk. The final step is then to evaluate and analyze the produced threat model including the effectiveness and efficiency of controls taking into account not only the impact on the risk, but also the impact on functionality, usability, and performance of the system.

The NIST document states that one of the most challenging parts of threat modeling is determining the right trade-offs when making decisions about reducing the attack surface, i.e., how can risk be reduced across all attack vectors, cost-effectively, and with an acceptable negative impact on an organization's operations. To facilitate comparisons, the document recommends using scoring and weighting approaches to further prioritize attack vectors and controls based on risk appetite and the impact on specific sets of characteristics, e.g., costs, functionality, usability, etc.

While NIST presents a primarily qualitative approach in this publication, it recognizes that with the emergence of automated tools, threat modeling will gain in scalability and more quantitative approaches can be carried out to threat model large and complex systems. IriusRisk is one of the tools that fit this description. The IriusRisk threat modeling solution follows the methodology described here. It helps the user capture the design and architecture under consideration and automatically identifies threats and controls that would be needed to implement, deploy, or simply secure the assets of interest.

References

‍