This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Threat Modeling Cheat Sheet"

From OWASP
Jump to: navigation, search
(Introduction)
Line 20: Line 20:
 
# Controls  and process needed to treat specific risks
 
# Controls  and process needed to treat specific risks
  
= Define The Target Of Evaluation =
+
=Why do we need to perform threat modeling=
== Create a logical map of the Target of Evaluation ==
 
== Create a physical map of the Target of Evaluation ==
 
== Identify the Assets within the physical and logical Targets of Evaluation ==
 
  
= Define The Attackers =
+
1. Performing threat model at the architecture level, helps in
== Identify Possible Attackers that could exist within the Target Of Evaluation ==
+
a. confirming on suitability of the identified security features to be implemented
* Use Means, Motive, and Opportunity to understand Threats posed by Attackers
+
b. identification of any gaps in the security features to be implemented
* Rank Attackers from least dangerous to most dangerous based on Means, Motive & Opportunity
+
c. identification of any further security features
==Select the most dangerous Attacker in your Target Of Evaluation ==
+
d. identification of policy and process requirements
 +
e. identification of requirements to be fed into security operations
 +
f. identification of logging and monitoring requirements
 +
g. arriving at abuse cases when used in agile methodology
 +
h. understanding business continuity requirements
 +
i. understanding capacity and availability requirements
  
= Conduct the Threat Model =
+
2. Performing threat model at the design level, helps in,
* Assume the attacker has a zero day, because he does. In this methodology we assume compromise; because a zero day will exist or already does exist (even if we don't know about it). This is about what can be done by skilled attackers, with much more time, money, motive and opportunity than we have.
+
a. identification of vulnerabilities that need to be closed at design level and input this into build phase
== Enumerate Threats posed by most dangerous Attacker in Target of Evaluation ==
+
b. identification of information assets that need security controls
=== Enumerate Threats posed by most dangerous attacker in designated areas of the physical & logical Maps of the Target of Evaluation ===
+
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)
* For logical map example: External firewall boundary, Internal firewall boundary, application server, and internal network.
+
d. identification of security test cases / security test scenarios to test the security requirements
* For physical map example: External to company (wifi attacks from parking lots for example), inside company branch (consultant on local network), in data centre (oops!).
 
=== Enumerate Attacks posed by most dangerous attacker in designated areas of the logical and physical maps of the target of evaluation ===
 
  
* Not used in this methodology (compromise is assumed and not demonstrated - just because we can't get in doesn't make it risk free...)
+
=Starting the threat modeling exercise=
  - Application Decomposition
+
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
  - Attack Tree
+
It is also important to the following before starting with this exercise,
  - Vulnerability/Exploit Mapping
+
1. Make of list of all the stakeholders who need to participate in this exercise. For example application architects, infrastructure architects, solution architects, business owners
  - Application Testing
+
2. Get management buy-in to ensure that there is management support for involvement of all necessary stakeholders.
 +
3. 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
  
== create risks in risk log for every identified threat or attack to any assets ==  
+
1. The trust boundaries to and within the solution that we build
== rank risks using [http://en.wikipedia.org/wiki/Risk_Matrix risk matrix] from most severe to least severe ==
+
2. The actors that interact within and outside of the trust boundaries
== Identify risk owners ==
+
3. Information flows within and to and from the trust boundaries
 +
4. Information persistence within and out of trust boundaries
 +
5. Threats to transgression of trust boundaries by actors and for information flow and persistence
 +
6. Vulnerabilities at trust boundaries as accessed by actors and for information flow and persistence
 +
7. Threat agents that can exploit the vulnerabilities
 +
8. Impact of exploitation of vulnerability by a threat agents
 +
9. Decision tree to treat the risk
 +
 
 +
=Decompose and Model the system=
 +
 
 +
To perform a threat model, it is important to understand how the system works and interacts with its ecosystem.
 +
To start with, create a high level information flow diagram, something like this:
 +
 
 +
 
 +
 +
1. Identify the trusted boundaries of your system / application / module / ecosystem that you may want to start off with.
 +
2. Add actors – internal and external
 +
3. Define internal trusted boundaries. These can be the different security zones that have been designed
 +
4. Relook at the actors you have identified in #2 for consistency
 +
5. Add information flows
 +
a. Information in transit
 +
b. Information at rest
 +
c. Information processing
 +
d. In the above diagram, following are the information flows:
 +
i. Login Information
 +
ii. Transmit login information
 +
iii. Data process
 +
iv. Data store
 +
6. Identify the information elements and their classification as per your information classification policy
 +
7. Where possible add assets to the identified information  flows
 +
8. Identify threat agents for each of the information flows
 +
9. Draw attack vectors and attack trees in an iteratively to make sure that no major attack vector is missed.
 +
10. For each of the information flows perform threat assessment using any of the methodologies that meets the organisation’s requirements:
 +
a. STRIDE
 +
b. DREAD
 +
c. Any other model that meets your organisation’s requirements
 +
11. Add a probability value to the materialisation of each of the threat
 +
12. Add a value for impact of each threat materialisation
 +
13. Identify the acceptable level of risk for the organisation or the identified scope
 +
14. Identify the risks for mitigation that are above the acceptable level of risk
 +
15. Mitigate the risks by doing one or more of the following:
 +
a. Accept
 +
b. Transfer
 +
c. Avoid
 +
d. Reduce
 +
 
 +
=How to work on getting the mitigations in place, track them to closure and keep monitoring risks=
 +
1. Upon completion of the initial threat modelling exercise, assign the 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.
 +
b. If there is an identified risk with the application design assign the risk 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.
 +
2. Maintain a Threat Traceability Matrix which at the minimum lists the following:
 +
a. Information flow (along with the list of assets)
 +
b. Threats for the information flows
 +
c. Probability of occurrence of the risk
 +
d. Impact of materialisation of the risk
 +
e. Risk owner – responsibility wise
 +
f. Risk owner – accountability wise
 +
g. Mitigation
 +
h. Last review date
 +
i. Next review date
 +
j. Instances of materialisation of the risk
 +
3. 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
 +
 
 +
=Further Reading=
 +
https://www.owasp.org/index.php/Application_Threat_Modeling
  
= Remediation/Countermeasures =
 
== Agree on risk mitigation with risk owners and stakeholders ==
 
* tolerate, transfer, treat, terminate
 
== Treat risks accordingly ==
 
== Test risk treatment to verify remediation ==
 
=== Reduce risk in risk log for verified treated risk ===
 
=== Periodically retest risk ===
 
  
 
== Authors and Primary Editors  ==
 
== Authors and Primary Editors  ==

Revision as of 19:38, 15 May 2016

Cheatsheets-header.jpg

Last revision (mm/dd/yy): 05/15/2016

DRAFT CHEAT SHEET - WORK IN PROGRESS

Introduction

The objective of this cheat sheet is to provide guidance to developers, reviewers, designers and architects on conducting successful threat modeling. The main goal of threat modeling is to understand the controls needed for a software system. This is a complex endeavor that will involve investigations into:

  1. The trust boundaries to and within the solution that we build
  2. The actors that interact within and outside of the trust boundaries
  3. Information flows within and to and from the trust boundaries
  4. Information persistence within and out of trust boundaries
  5. Vulnerabilities at trust boundaries
  6. Threat agents that can exploit the vulnerabilities
  7. Impact of exploitation of vulnerability by a threat agents
  8. Controls and process needed to treat specific risks

Why do we need to perform threat modeling

1. Performing threat model at the architecture level, helps in a. confirming on 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 d. identification of policy and process requirements e. identification of requirements to be fed into security operations f. identification of logging and monitoring requirements g. arriving at abuse cases when used in agile methodology h. understanding business continuity requirements i. understanding capacity and availability requirements

2. 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 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) 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 also important to the following before starting with this exercise, 1. Make of list of all the stakeholders who need to participate in this exercise. For example application architects, infrastructure architects, solution architects, business owners 2. Get management buy-in to ensure that there is management support for involvement of all necessary stakeholders. 3. 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

1. The trust boundaries to and within the solution that we build 2. The actors that interact within and outside of the trust boundaries 3. Information flows within and to and from the trust boundaries 4. Information persistence within and out of trust boundaries 5. Threats to transgression of trust boundaries by actors and for information flow and persistence 6. Vulnerabilities at trust boundaries as accessed by actors and for information flow and persistence 7. Threat agents that can exploit the vulnerabilities 8. Impact of exploitation of vulnerability by a threat agents 9. Decision tree to treat the risk

Decompose and Model the system

To perform a threat model, it is important to understand how the system works and interacts with its ecosystem. To start with, create a high level information flow diagram, something like this:


1. Identify the trusted boundaries of your system / application / module / ecosystem that you may want to start off with. 2. Add actors – internal and external 3. Define internal trusted boundaries. These can be the different security zones that have been designed 4. Relook at the actors you have identified in #2 for consistency 5. Add information flows a. Information in transit b. Information at rest c. Information processing d. In the above diagram, following are the information flows: i. Login Information ii. Transmit login information iii. Data process iv. Data store 6. Identify the information elements and their classification as per your information classification policy 7. Where possible add assets to the identified information flows 8. Identify threat agents for each of the information flows 9. Draw attack vectors and attack trees in an iteratively to make sure that no major attack vector is missed. 10. For each of the information flows perform threat assessment using any of the methodologies that meets the organisation’s requirements: a. STRIDE b. DREAD c. Any other model that meets your organisation’s requirements 11. Add a probability value to the materialisation of each of the threat 12. Add a value for impact of each threat materialisation 13. Identify the acceptable level of risk for the organisation or the identified scope 14. Identify the risks for mitigation that are above the acceptable level of risk 15. Mitigate the risks by doing one or more of the following: a. Accept b. Transfer c. Avoid d. Reduce

How to work on getting the mitigations in place, track them to closure and keep monitoring risks

1. Upon completion of the initial threat modelling exercise, assign the 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. b. If there is an identified risk with the application design assign the risk 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. 2. Maintain a Threat Traceability Matrix which at the minimum lists the following: a. Information flow (along with the list of assets) b. Threats for the information flows c. Probability of occurrence of the risk d. Impact of materialisation of the risk e. Risk owner – responsibility wise f. Risk owner – accountability wise g. Mitigation h. Last review date i. Next review date j. Instances of materialisation of the risk 3. 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

Further Reading

https://www.owasp.org/index.php/Application_Threat_Modeling


Authors and Primary Editors

TODO

Other Cheatsheets