Feat/update threatmodeling cs

[ThunderSon]

This is a buildup to the uplift of the threat modeling CS, based on issue #300 and this does not close the issue.
This PR is a starting point to add some peripherals to the CS.

The PR should be reviewed against the content in place, and not in what it could be missing.
For what is missing and needs to be done, this will be discussed in the issue mentioned.

[ThunderSon]

@swierckx and @ben-dale your comments are welcome as a starting point for the CS.

[ben-dale]

Your change made me double-take because it's basically the outline I started hashing out the other day (but never got a chance to push it up) so I wondered how you got hold of it 😂

The only difference was the headings I used (subject to change). The idea being that the CS could discuss each heading with the DOs and DONTs:

## Threat modeling an application
There are four key questions that form the basis of most threat modeling methodologies:
- What are we building?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?

### Understand what you are building
DOs/DONTs from Question 1
https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/

### Determine what could go wrong
A section to outline steps
DOs/DONTs from Question 2
https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/

### Identify the remediations
DOs/DONTs from Question 3
https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/

### Validate your assumptions and share your findings
DOs/DONTs from Question 4
https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/

I wasn't 100% on some of the DOs and DONTs, for example "DON’T Confuse can and should". I wasn't sure exactly what that meant.

I also had a section which mentioned some tools, but all I had was OWASP Threat Dragon. I'm not sure on OWASP's stance on recommending commercial tools like Miro etc.

[jmanico]

Please keep commercial tools and services out of cheatsheets. :)

…

-- Jim Manico @manicode

On Jun 5, 2020, at 5:59 AM, Benjamin Dale ***@***.***> wrote:  Your change made me double-take because it's basically the outline I started hashing out the other day (but never got a chance to push it up) so I wondered how you got hold of it 😂 The only difference was the headings I used (subject to change). The idea being that the CS could discuss each heading with the DOs and DONTs: ## Threat modeling an application There are four key questions that form the basis of most threat modeling methodologies: - What are we building? - What can go wrong? - What are we going to do about it? - Did we do a good enough job? ### Understand what you are building DOs/DONTs from Question 1 https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/ ### Determine what could go wrong A section to outline steps DOs/DONTs from Question 2 https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/ ### Identify the remediations DOs/DONTs from Question 3 https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/ ### Validate your assumptions and share your findings DOs/DONTs from Question 4 https://2018.open-security-summit.org/outcomes/tracks/threat-model/working-sessions/tm-cheatsheets/ I wasn't 100% on some of the DOs and DONTs, for example "DON’T Confuse can and should". I wasn't sure exactly what that meant. I also had a section which mentioned some tools, but all I had was OWASP Threat Dragon. I'm not sure on OWASP's stance on recommending commercial tools like Miro etc. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ThunderSon]

Hahaha I have my ways.

I believe the difference is perspective. Are you thinking in the headings to be actionable, or to help run the session? They're pretty similar. I set them as such to follow the flow in the questions asked, and not confuse the reader. What you did is flesh out what's happening.

For the tools, you may mention them by specifying clearly which are free, which are commercial, and they need to be mainstream (not a way for marketing) with proper support and traction.

[jmanico]

If your cheatsheet requires the discussion of commercial tools then you are not cheating enough. These cheatsheets are meant to be brief, to the point, developer engineering guides. Also, OWASP actually is a charity, a 501c3 not for profit charitable organization. These public guides are not the place for citing commercial offerings or services. Even tools that are mainstream should not be in the guides. Thank you all, -- Jim Manico @manicode

…

On Jun 7, 2020, at 5:32 AM, ThunderSon ***@***.***> wrote:  Hahaha I have my ways. I believe the difference is perspective. Are you thinking in the headings to be actionable, or to help run the session? They're pretty similar. I set them as such to follow the flow in the questions asked, and not confuse the reader. What you did is flesh out what's happening. For the tools, you may mention them by specifying clearly which are free, which are commercial, and they need to be mainstream (not a way for marketing) with proper support and traction. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.