Threat Modeling Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:40:17Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T14:45:26Z

Migration to GitHub

Show changes

Mohamed Alfateh at 12:30, 1 February 2019

2019-02-01T12:30:35Z

Mohamed Alfateh at 12:27, 1 February 2019

2019-02-01T12:27:49Z

Mohamed Alfateh at 12:24, 1 February 2019

2019-02-01T12:24:25Z

Mohamed Alfateh: The draft version for the new updated sheet

2018-11-22T13:46:36Z

The draft version for the new updated sheet

Show changes

Shruti kulkarni at 15:57, 6 December 2017

2017-12-06T15:57:38Z

Shruti kulkarni at 15:55, 6 December 2017

2017-12-06T15:55:16Z

AnnGrove: /* Why do we need to perform threat modeling */ Minor grammar edits. Clarifications.

2017-08-22T00:43:42Z

‎Why do we need to perform threat modeling: Minor grammar edits. Clarifications.

Shruti kulkarni at 13:36, 16 May 2016

2016-05-16T13:36:49Z

← Older revision		Revision as of 14:40, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Threat_Modeling_Cheat_Sheet.md Threat Modeling Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html Threat Modeling Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 134: / Line 134: @@
 # Where possible add assets to the identified information flows.
-== Define and Evaluate your Assets ==
+== Define and Evaluate Your Assets ==
 Assets involved in the information flow should be defined and evaluated according to their value of confidentiality, integrity and availability.
-=== Consider Data in transit and Data at rest ===
+=== Consider Data in Transit and Data at Rest ===
 Data protection in transit is the protection of this data while it’s traveling from network to network or being transferred from a local storage device to a cloud storage device – wherever data is moving, effective data protection measures for in transit data are critical as data is often considered less secure while in motion.
@@ Line 146: / Line 146: @@
 The risk profile for data in transit or data at rest depends on the security measures that are in place to secure data in either state. Protecting sensitive data both in transit and at rest is imperative for modern enterprises as attackers find increasingly innovative ways to compromise systems and steal data.
-== Create an information flow diagram ==
+== Create an Information Flow Diagram ==
 === Whiteboard Your Architecture ===

@@ Line 54: / Line 54: @@
 Before starting the threat modelling process; it is important to identify business objectives of the applications, and identify security & compliance requirements. This is very important to be defined in advance to help evaluating the impact of any vulnerability during the risk analysis process.
-= Identify application design =
+= Identify Application Design =
 Understanding application design is a key activity to perform application threat modelling. It will enable the user of this cheat sheet to draw an accurate data flow diagram. Therefore, it will be easier to identify all possible risks. Moreover, the more the user of this cheat sheet understands application design, the better they will understand logical application attacks. The objective of the design document is to enumerate application components.
-== Review the application design document ==
+== Review the Application Design Document ==
 If you are not performing threat modelling during the development (in the design phase) so you have to review the application design documents to understand the application structure and to help generating the data flow diagram. If there are no available design documents so you have to create one. Move to next section
-== Create design documents ==
+== Create Design Documents ==
 There are many ways to generate design documents; the 4+1 view model is one of the matured approaches to build your design document. Reference to 4+1 view model of architecture: [http://ieeexplore.ieee.org/abstract/document/469759/?reload=true http://ieeexplore.ieee.org/abstract/document/469759/?reload=true]
@@ Line 151: / Line 151: @@
 It is important to whiteboard system architecture by showing the major constraints and decisions in order to frame and start conversations. The value is actually twofold. If the architecture cannot be white-boarded, then it suggests that it is not well understood. If a clear and concise whiteboard diagram can be provided, others will understand it and it will be easier to communicate details.
-=== Manage to present your DFD in context of MVC ===
+=== Manage to Present your DFD in Context of MVC ===
 In this step Data Flow Diagram should be divided the in the context of Model, View, Controller (MVC).
-=== Use tools to draw your diagram ===
+=== Use Tools to Draw your Diagram ===
 If you don’t like to manually draw your DFD; there are several tools available that could be used:
@@ Line 175: / Line 175: @@
 Define any distinct&nbsp;boundaries (External boundaries and Internal boundaries) within which a system&nbsp;trusts&nbsp;all sub-systems (including data).
-== Define applications user roles and trust levels ==
+== Define Applications User Roles and Trust Levels ==
 Define access rights that the application will grant to external entities and internal entities.
-== Highlight Authorization per user role over the DFD ==
+== Highlight Authorization per User Role Over the DFD ==
 Highlight Authorization per user role, for example, defining app users’ role, admins’ role, anonymous visitors’ role...etc.
@@ Line 206: / Line 206: @@
 # MS STRIDE.
-== Map Threat agents to application Entry points ==
+== Map Threat Agents to Application Entry Points ==
 Map threat agents to application entry point, whether it is a login process, a registration process or whatever it might be and consider insider Threats.
-== Draw attack vectors and attacks tree ==
+== Draw Attack Vectors and Attacks Tree ==
 During this phase conduct the following activities:
@@ Line 219: / Line 219: @@
 == Mapping Abuse Cases to Use Cases ==
-== Re-Define attack vectors ==
+== Re-Define Attack Vectors ==
 In most cases after defining the attack vectors, the compromised user role could lead to further attacks into the application. For example, assuming that an internet banking user credentials could be compromised, the user of this cheat sheet has to then redefine the attack vectors that could result from compromising the user’s credentials and so on.
-= Write your Threat traceability matrix =
+= Write your Threat Traceability Matrix =
-== Define the Impact and Probability for each threat ==
+== Define the Impact and Probability for Each Threat ==
 Enumerate Attacks posed by most dangerous attacker in designated areas of the logical and physical maps of the target of evaluation.

@@ Line 280: / Line 280: @@
-= Determine countermeasures and mitigation. =
+= Determine Countermeasures and Mitigation. =
 Identify risk owners and agree on risk mitigation with risk owners and stakeholders. Provide the needed controls in forms of code upgrades and configuration updates to reduce risks to acceptable levels.
-== Identify risk owners ==
+== Identify Risk Owners ==
 For the assessors: After defining and analysing the risks, the assessor should be working on the mitigation plan by firstly identifying risk owners which is the personnel that is responsible for mitigating the risk. i.e. one of the information security team or the development team.
@@ Line 292: / Line 292: @@
-== Agree on risk mitigation with risk owners and stakeholders ==
+== Agree on Risk Mitigation With Risk Owners and Stakeholders ==
-== Build your risk treatment strategy ==
+== Build Your Risk Treatment Strategy ==
 * Reduce: building controls if the form of code upgrades, confirming a specific design for the application or building a specific configuration during the deployment phase to make sure that application risk is reduced.
@@ Line 302: / Line 302: @@
 For the assessor this is considered that last step in the assessment process. The following steps should be conducted by the risk owner, however, the assessor shall engage in 6.5 (Testing risk treatment) to verify the remediation.
-== Select appropriate controls to mitigate the risk ==
+== Select Appropriate Controls to Mitigate the Risk ==
 Selecting one of the controls to reduce the risk, either by upgrading the code, or building a specific configuration during the deployment phase and so on.
-== Test risk treatment to verify remediation ==
+== Test Risk Treatment to Verify Remediation ==
 Mitigation controls will not vanish the risk completely, rather, it would just reduce the risk. In this case, the user of this cheat sheet should measure the value of the risk after applying the mitigation controls. The value of the risk should be reduced to the acceptable criteria set earlier.
-== Reduce risk in risk log for verified treated risk ==
+== Reduce Risk in Risk Log for Verified Treated Risk ==
 After applying the mitigation and measuring the new risk value, the user of this cheat sheet should update the risk log to verify that risk has been reduced.
-== Periodically retest risk ==
+== Periodically Retest Risk ==
 = Appendix =
@@ Line 325: / Line 325: @@
 Mohamed Alfateh
 Ahmed Kanoma

@@ Line 116: / Line 116: @@
 .	Identify the risks for mitigation that are above the acceptable level of risk
-.	Mitigate the risks by doing one or more of the following:
+.	Manage the risks by doing one or more of the following:
           a.	Accept
           b.	Transfer

@@ Line 151: / Line 151: @@
 == Authors and Primary Editors  ==
-TODO
+Shruti Kulkarni - shruti.kulkarni@owasp.org
 == Other Cheatsheets ==

@@ Line 3: / Line 3: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
-<br/>
+<br />
   __TOC__{{TOC hidden}}
 = DRAFT CHEAT SHEET - WORK IN PROGRESS =
@@ Line 23: / Line 23: @@
 =Why do we need to perform threat modeling=
-.	Performing threat model at the architecture level, helps in
+.	Performing threat model at the architecture level, helps in:
-         a.	confirming on suitability of the identified security features to be implemented
+         a.	confirming suitability of the identified security features to be implemented
          b.	identification of any gaps in the security features to be implemented
          c.	identification of any further security features
@@ Line 34: / Line 34: @@
          i.	understanding capacity and availability requirements
-.	Performing threat model at the design level, helps in,
+.	Performing threat model at the design level, helps in:
-         a.	identification of vulnerabilities that need to be closed at design level and input this into build phase
+         a.	identification of vulnerabilities that need to be closed at the design level and input this into the build phase
          b.	identification of information assets that need security controls
-         c.	mapping of identified security controls into technical / administrative / physical controls as the case may be (this activity can be done at the architecture level as well, but doing it at design level helps in being granular)
+         c.	mapping of identified security controls into technical / administrative / physical controls as the case may be (this activity can be done at the architecture level as well, but doing it at the design level helps in being granular)
          d.	identification of security test cases / security test scenarios to test the security requirements
 =Starting the threat modeling exercise=
-It is important to have a risk assessment policy at an organisation which gives guidance to the practitioners on when to do a threat model, management guidance, owners of the risks etc
+It is important for an organization to have or create a risk assessment policy that gives practitioner guidance on when to do a threat model, provides management guidance on assigning owners to risks, etc.
-.Make of list of all the stakeholders who need to participate in this exercise. For example application architects, infrastructure architects, solution architects, business owners
+An organization should also complete the following before beginning the threat modeling exercise:
-.Get management buy-in to ensure that there is management support for involvement of all necessary stakeholders.
+. Make a list of all the stakeholders who need to participate in threat modeling. For example, stakeholders may include application architects, infrastructure architects, solution architects, business owners, etc.
-.It is assumed that the threat modeling exercise is led by the security team of the organisation and the risk log is maintained by the security team
+. Get management buy-in for the exercise to ensure that there is management support for involvement of all necessary stakeholders.
-Following are the activities that are a part of the exercise:
+. Confirm that the threat modeling exercise is led by the security team of the organisation and the risk log is maintained by the security team.
 . The trust boundaries to and within the solution that we build
@@ Line 66: / Line 67: @@
 . Threat agents that can exploit the vulnerabilities
-. Impact of exploitation of vulnerability by a threat agents
+. Impact of exploitation of vulnerability by a threat agent
 . Decision tree to treat the risk
@@ Line 107: / Line 108: @@
 .	For each of the information flows perform threat assessment using any of the methodologies that meets the organisation’s requirements:
-.	Add a probability value to the materialisation of each of the threat
+.	Add a probability value to the materialisation of each threat
-.	Add a value for impact of each threat materialisation
+.	Add a value for the impact of each threat materialisation
 .	Identify the acceptable level of risk for the organisation or the identified scope
@@ Line 122: / Line 123: @@
 =How to work on getting the mitigations in place, track them to closure and keep monitoring risks=
-.	Upon completion of the initial threat modelling exercise, assign the risks to the relevant business / risk owners of threats for example
+.	Upon completion of the initial threat modelling exercise, assign identified risks to the relevant business / risk owners of threats for example
-         a.	If there is an identified risk with the way the database is implemented, assign the risk to the owner of the database team.
+         a.	If there is an identified risk with the way the database is implemented, assign the risk responsibility to the owner of the database team.
-         b.	If there is an identified risk with the application design assign the risk to the owner of the application team
+         b.	If there is an identified risk with the application design, assign the risk responsibility to the owner of the application team
-         c.	However these are responsibilities that are assigned. The accountability of getting these risks addressed lies with the business owner for whose business the application is being developed for. End of the day, it is the business owner who needs to understand if the risk is aligned with the risk appetite of his/her business unit. And if the risk is above or below the acceptable level.
+         c.	Although the risks are assigned to the database and application teams, the accountability of ensuring the risks are addressed lies with the business owner for the business the application is being developed for. At the end of the day, the business owner needs to understand the risk appetite of his/her business unit and whether the risk is above or below the acceptable level.
 .	Maintain a Threat Traceability Matrix which at the minimum lists the following:
@@ Line 141: / Line 142: @@
 .	Test the risk as a part of security testing to ensure that the mitigation works as expected
-Periodically retest the risk in either a vulnerability scan or as a test scenario as part of penetration test or security test to ensure that the mitigation is still in place and works as expected
+Periodically retest the risk in either a vulnerability scan or as part of penetration test or security test to ensure that the mitigation remains in place and works as expected.
@@ Line 156: / Line 157: @@
 {{Cheatsheet_Navigation_Body}}
 [[Category:Cheatsheets]]

← Older revision		Revision as of 13:36, 16 May 2016
Line 76:		Line 76:


−	<<~~File~~ to be embedded>>	+	<<Picture to be embedded>>