From 3e0aae4d9a337418a6dfffadf926f315a9ff2ee1 Mon Sep 17 00:00:00 2001 From: Sebastien Torres Date: Thu, 1 May 2025 09:44:46 +0100 Subject: [PATCH] Correctly italicise first section... ...of the second bullet point of the 'first steps' section. --- Continuous_Threat_Modeling_Handbook.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Continuous_Threat_Modeling_Handbook.md b/Continuous_Threat_Modeling_Handbook.md index 83a9afa..d518bcd 100644 --- a/Continuous_Threat_Modeling_Handbook.md +++ b/Continuous_Threat_Modeling_Handbook.md @@ -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.