Skip to content

Correctly italicise first section... #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: development
Choose a base branch
from
Open

Correctly italicise first section... #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Continuous_Threat_Modeling_Handbook.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ The overall exercise of threat modeling must be performed as a team. Delegate th
Threat modeling creates an opportunity for informative discussion within the team and is not limited to team members with specific responsibilities.

* *Define the scope* – are you threat modeling a full system or just a small design change? Decide which elements of the system will be part of the threat model. 
* *Identify all important assets *so that the model includes all relevant parts of the system. If you are worried about too much detail, start with a top-level description of the system and repeat the process for more detailed views of smaller parts.
* *Identify all important assets* so that the model includes all relevant parts of the system. If you are worried about too much detail, start with a top-level description of the system and repeat the process for more detailed views of smaller parts.
* *Draw diagram(s)* – based on the scope, create diagrams of the system to be modeled. These should include, minimally, the personas who use the system (users, administrators, operators, etc.), the way they interact with the system, browsers, desktop clients, servers, load-balancers and firewalls, etc. You can use a picture of a diagram on a whiteboard, or a diagram created in Visio™, Lucidchart™, Draw.io, etc. In order to make it easy to keep the diagram up to date, we recommend the use the open-source tool [PyTM](https://github.com/izar/pytm), or [Dataflow](https://github.com/sonyxperiadev/dataflow), a declarative markup language that generates diagrams. What matters is that the team agrees that the diagram correctly represents the pieces of the system.
* *Draw dataflows* – picture the interactions between the pieces in terms of data flowing. Annotate it with details: protocol, authentication, etc.
* *Mark where the important data lives, transits and is transformed* – this is very important, as here you’ll find out which data you are trying to protect and where it appears in the system. Continue to the section, "*DFD Details*", below to ensure the final DFD(s) include the required information.
Expand Down