Update: threat_modeling_cheat_sheet

[sebob]

What is missing or needs to be updated?

There is no alternative to the "System Modeling" section

How should this be resolved?

Text to add as a subsection for "System Modeling", just below this section.

#### Alternative for DFD
An alternative to Data Flow Diagrams (DFD) could be the brainstorming technique, which is an effective method for generating ideas and discovering the project's domain. Applying brainstorming in this context can bring numerous benefits, such as increased team engagement, unification of knowledge and terminology, a shared understanding of the domain, and quick identification of key processes and dependencies. One of the main arguments for using brainstorming is its flexibility and adaptability to almost any scenario, including business logic. Additionally, this technique is particularly useful when less technical individuals participate in the session, as it eliminates barriers related to understanding and applying the components of DFD models and their correctness.

Brainstorming engages all participants, fostering better communication and mutual understanding of issues. Every team member has the opportunity to contribute, which increases the sense of responsibility and involvement. During a brainstorming session, participants can collaboratively define and agree on key terms and concepts, leading to a unified language used in the project. This is especially important in complex projects where different teams might have different approaches to terminology. Due to the dynamic nature of brainstorming, the team can quickly identify key business processes and their interrelations.

Integrating the results of brainstorming with formal modeling techniques can lead to a better understanding of the domain and more effective system design.

[kwwall]

Brainstorming is a useful threat-modeling technique and I use it a lot, but I don't see it as an alternative to DFDs, so I don't think it should be presented as such. DFD is a useful artifact that is easier to explain and dates way back in computer science / software engineering literature. And multiple people who understand DFDs generally will gather than same meaning from a specific DFD because it has some semi-formal rules associated with it's presentation. Thus once the threat model is created, DFDs can serve as a communication mechanism.

However, brainstorming is more of a discovery aid. It's a valuable one at that, but I'm not sure there is a standard nomenclature to represent a brainstorming session, which is why I don't see it as an alternative to DFDs. I'd be okay with this if it wasn't portrayed as an alternative to DFDs though, but instead as an additional useful technique.

[mackowski]

I agree with @kwwall here. I would like to have a 'brainstorming' section somewhere in the document but this does not fit for e as an alternative to DFD. I belive that sometimes simple 'brainstorming' is better than following more complex methodology (for full or part of the threat modeling process), specially when we know that the brainstorming will be done more often.

In "System Modeling" I see that sometimes we do not have a DFD and we do the brainstorming to create DFD. Also sometimes DFD is not the best choice (the system is too complex, creating DFD will take too much time, people in the room are not familiar with it, etc.). In such situation we want to do brainstorming to discover the space that we want to threat model, and as @sebob mention unification of knowledge and terminology, a shared understanding of the domain. But the outcome of this brainstorming is System Model - it can be in form of DFD in can be an ugly drawing on the whiteboard, it can be something else.

My point is brainstorming is part of the system modeling regardless if the outcome (so the system model) is in the form of DFD of something else (even notes would be fine but not easy to use in my opinion).

If we can democratise this part and let our users know that DFDs are good but you do not need to have a perfect DFD to do the threat modeling and almost any model that you will create will work - I am for such changes. Also if we can put the note that "System Modeling" is not only about creating DFD - "System Modeling" is about creating a model of the system (that can be in the form of DFD) as well as many other things that @sebob mentioned like: unification of knowledge and terminology, a shared understanding of the domain. That would be a good change in my opinion.

[jmanico]

If both @kwwall and @mackowski agree then I absolutely think we need this in the doc. Let's do it.

[sebob]

Great, I'm very happy to hear that. Do you have any suggestions for changes or improvements that I should make? If not, let's proceed because I have a few more things I want to address. From my experience, it's clear that people need more information about threat modeling because they often get lost. This cannot be a taboo subject; we need to work on spreading knowledge on this topic.

Please let me know what our next steps are – thanks!

[mackowski]

@sebob please create a PR for us to review. If you will need any help let us know.