Difference between revisions of "Threat Modeling Cheat Sheet"

From OWASP
Jump to: navigation, search
(Introduction)
Line 19: Line 19:
 
# Impact of exploitation of vulnerability by a threat agents
 
# Impact of exploitation of vulnerability by a threat agents
 
# Controls  and process needed to treat specific risks
 
# Controls  and process needed to treat specific risks
 
'''Application Security Threat Modeling'''
 
 
  
 
= Define The Target Of Evaluation =
 
= Define The Target Of Evaluation =

Revision as of 21:56, 11 April 2016

Cheatsheets-header.jpg

Last revision (mm/dd/yy): 04/11/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

Define The Target Of Evaluation

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

Identify Possible Attackers that could exist within the Target Of Evaluation

  • Use Means, Motive, and Opportunity to understand Threats posed by Attackers
  • Rank Attackers from least dangerous to most dangerous based on Means, Motive & Opportunity

Select the most dangerous Attacker in your Target Of Evaluation

Conduct the Threat Model

  • 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.

Enumerate Threats posed by most dangerous Attacker in Target of Evaluation

Enumerate Threats posed by most dangerous attacker in designated areas of the physical & logical Maps of the Target of Evaluation

  • For logical map example: External firewall boundary, Internal firewall boundary, application server, and internal network.
  • 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...)
 - Application Decomposition
 - Attack Tree
 - Vulnerability/Exploit Mapping
 - Application Testing

create risks in risk log for every identified threat or attack to any assets

rank risks using risk matrix from most severe to least severe

Identify risk owners

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

TODO

Other Cheatsheets