NIST Maturity mover using Threat Modeling

Original post by @JSnurka

My organization is working to move our NIST maturity and one of the ways my team can help is in the area of Threat Modeling.

There are some specific questions around TM but it seems that NIST looks at Networking, Database and Application Threat Modeling separately. To be honest, I didn’t know modeling was done in different pillars but holistically.

Here are a few of the NIST questions. I would love feedback on how I can use a tool like IriusRisk to move the needle on these.

  1. Which of the following describe how network threat modeling is performed by the organization?
  2. TM performed against network attack surfaces
  3. Against data flow
  4. What is the estimated % of all databases for which the organization performs threat modeling to identify and prioritize potential threats?
  5. Which of the following describe the organization’s implementation of threat modeling

#3 is focused on application TM incorporated in SDLC

BTW - NIST defines SDLC as System Development Lifecycle

I think your assessment of threat modeling is correct. It should be done holistically but I think most organization mature into that mind set. Its easier (in my opinion) to threat model only by attack surface (which of course requires that I have actually inventoried my attack surfaces).

If you review the NIST publication - SP 800-154 - Guide to Data-Centric System Threat Modeling (Draft), they look at threat modeling as a natural extension of risk analysis. After all, threat modeling is just architectural risk analysis right?

Although that document does limit its scope to “data centric threat modeling” which focuses more on the storage of data versus the security of a particular host, I feel that it was a valuable addition to any team’s processes.

Their four step process aligns pretty well with Shostack’s 4 Question framework.

  • Step 1 - Identify and Character the system and data of interest (What are we working on?)
  • Step 2 - Identify and Select the attack vectors to be included in the Model (What can go wrong?)
  • Step 3 - Characterize the Security Controls for Mitigating the Attack Vectors (What are we going to do about it?)
  • Step 4 - Analyze the Threat Model (Did we do a good job?)

Using IriusRisk could move the needle on all of those questions. Threat Modeling attack surfaces and data flows are a natural use of the product. Using project components, you could even taken advantage of shared attack surfaces or shared infrastructure that would have a one to many relationship. What percentage is databases have been threat modeled would be simple to calculate and would just require some evidence of a software inventory cross-compared with threat models. Might even use that build a timeline and workplan for which threat models need to be completed over x time period.

I think I would need more context on #3 to answer it effectively but would strongly advocate for a risk based approach to threat modeling which is generally a highly favored approach by NIST.

Are you referencing a certain publication? I wasn’t able to find that maturity reference after a quick scan within 54 Rev5 or NIST CSF.

Original post by @JSnurka

Thank you @jrabe3

We are using a tool called Blue Lava to measure our cyber maturity. The questions I listed were pulled directly from their questionnaire. Supposedly it’s based on NIST but I didn’t do a search myself.

Data-Centric threat modeling makes sense. My team’s mandate is to follow the data. Who has access, how is it stored/protected, how it moves, and what happened with it. (logging) To do that, we focus on architectural diagrams which is why we are excited about IriusRisk.

Our plan is to start with moving some architectural diagrams into IriusRisk for modeling. A natural outgrowth from that is to have dev teams and infra teams use the tool to identify risks earlier.