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 "OWASP Risk Rating Methodology"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]<br>
 
[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]<br>
 
{{Template:OWASP Testing Guide v2}}
 
{{Template:OWASP Testing Guide v2}}
==Application Security Risks Evaluation==  
+
==Application Security Risks==  
 
===Background===
 
===Background===
 
Application security risk analysis consists in the assessment of the levels of risk calculated for threats and vulnerabilities. Risk Assessment practitioners usually refer to application security risk analysis as technical risk assessment. In the technical risk analysis model, threat and vulnerability represents the two factors (i.e. multipliers) used for risk calculation. Depending on the model used, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the finding it is possible to prioritize fixing vulnerabilities with the highest security risks: the ones characterized by with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors to decide deciding the strategy for mitigating application security risks such the evaluation of business impacts derived by the exploitation of the vulnerability. Technical risks and business impact analysis are both evaluated as part of the information risk management strategy identification that includes selection and adoption of countermeasures justified by the identified risks to assets and the reduction of those risks to acceptable levels. For the purpose of this guide we limit the scope of risk evaluation to technical impact analysis that is the evaluation of risk for known threats and vulnerabilities.<BR>
 
Application security risk analysis consists in the assessment of the levels of risk calculated for threats and vulnerabilities. Risk Assessment practitioners usually refer to application security risk analysis as technical risk assessment. In the technical risk analysis model, threat and vulnerability represents the two factors (i.e. multipliers) used for risk calculation. Depending on the model used, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the finding it is possible to prioritize fixing vulnerabilities with the highest security risks: the ones characterized by with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors to decide deciding the strategy for mitigating application security risks such the evaluation of business impacts derived by the exploitation of the vulnerability. Technical risks and business impact analysis are both evaluated as part of the information risk management strategy identification that includes selection and adoption of countermeasures justified by the identified risks to assets and the reduction of those risks to acceptable levels. For the purpose of this guide we limit the scope of risk evaluation to technical impact analysis that is the evaluation of risk for known threats and vulnerabilities.<BR>
  
===Risks Evaluation===  
+
==Risks Formulation==  
  
 
According to NIST publication 800-27 Risk is defined as the probability that a particular threat-source will exercise particular information system vulnerability and the resulting impact if this should occur. <BR>
 
According to NIST publication 800-27 Risk is defined as the probability that a particular threat-source will exercise particular information system vulnerability and the resulting impact if this should occur. <BR>
Line 16: Line 16:
 
Exposure quantifies the likelihood that the vulnerability can be compromised through its availability. For example, an easily exploited vulnerability on an internet facing host would be highly exposed, and therefore very likely to be compromised. An internal host with a vulnerability that was difficult to exploit would present a much lower threat.<BR>
 
Exposure quantifies the likelihood that the vulnerability can be compromised through its availability. For example, an easily exploited vulnerability on an internet facing host would be highly exposed, and therefore very likely to be compromised. An internal host with a vulnerability that was difficult to exploit would present a much lower threat.<BR>
  
===Threat Categorizations===  
+
==Threat Categorizations==  
 
For the purpose of the OWASP guide, threats can be identified for each of the testing category using threat categorization models as part of a threat modeling framework (e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not particular endorse any vendor specific threat categorization, but rather recommends to adopt a threat categorization and risk ranking that depends on specific objectives.
 
For the purpose of the OWASP guide, threats can be identified for each of the testing category using threat categorization models as part of a threat modeling framework (e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not particular endorse any vendor specific threat categorization, but rather recommends to adopt a threat categorization and risk ranking that depends on specific objectives.
 
In general categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures. Some threat categorizations also include risk rankings for the identified threats (e.g. STRIDE/DREAD)
 
In general categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures. Some threat categorizations also include risk rankings for the identified threats (e.g. STRIDE/DREAD)
Line 24: Line 24:
 
*Overall risk strategy selection  
 
*Overall risk strategy selection  
  
===Risks Calculation===  
+
==Risks Calculation==  
 
Before any kind of calculation can be done appropriate values for the impact, ease of exploitation and exposure have to be found. Every risk parameter can be assigned a qualitative value based on its importance (e.g. severity). Using qualitative values rather than quantitative ones can help avoid the ranking becoming overly subjective. The same argument holds true for the number of different qualitative values, hence, only three different values (high, medium, low) are used.
 
Before any kind of calculation can be done appropriate values for the impact, ease of exploitation and exposure have to be found. Every risk parameter can be assigned a qualitative value based on its importance (e.g. severity). Using qualitative values rather than quantitative ones can help avoid the ranking becoming overly subjective. The same argument holds true for the number of different qualitative values, hence, only three different values (high, medium, low) are used.
  
Line 33: Line 33:
 
* Threat modeling risk rankings (DREAD, TRIKE, PTA, CORAS/SECURIS, PTA)
 
* Threat modeling risk rankings (DREAD, TRIKE, PTA, CORAS/SECURIS, PTA)
  
 +
==Examples==
  
  

Revision as of 17:40, 19 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents

Application Security Risks

Background

Application security risk analysis consists in the assessment of the levels of risk calculated for threats and vulnerabilities. Risk Assessment practitioners usually refer to application security risk analysis as technical risk assessment. In the technical risk analysis model, threat and vulnerability represents the two factors (i.e. multipliers) used for risk calculation. Depending on the model used, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the finding it is possible to prioritize fixing vulnerabilities with the highest security risks: the ones characterized by with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors to decide deciding the strategy for mitigating application security risks such the evaluation of business impacts derived by the exploitation of the vulnerability. Technical risks and business impact analysis are both evaluated as part of the information risk management strategy identification that includes selection and adoption of countermeasures justified by the identified risks to assets and the reduction of those risks to acceptable levels. For the purpose of this guide we limit the scope of risk evaluation to technical impact analysis that is the evaluation of risk for known threats and vulnerabilities.

Risks Formulation

According to NIST publication 800-27 Risk is defined as the probability that a particular threat-source will exercise particular information system vulnerability and the resulting impact if this should occur.
For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact, Ease of Exploitation and Exposure as risk parameters of the following empirical formula:

Risk = Impact x Ease of Exploitation x Exposure

By breaking down the security findings in this way, threats criticality and the implication of the vulnerability exposure may be better evaluated and risks can be prioritized and managed. The risk evaluation is taken out of the context of the nature of the application or host (e.g. server, firewall or workstation), and regardless of the type of data stored on it.
The impact and the easiness of exploitation of a threat are usually considered the main factors in determining the criticality of threats. In this case, impact is taken as a measure of the implication of a discrete component being compromised (e.g. attack potency). The ease of exploitation for a threat can be further described as a factor of discoverability and reproducibility of a threat. Exposure quantifies the likelihood that the vulnerability can be compromised through its availability. For example, an easily exploited vulnerability on an internet facing host would be highly exposed, and therefore very likely to be compromised. An internal host with a vulnerability that was difficult to exploit would present a much lower threat.

Threat Categorizations

For the purpose of the OWASP guide, threats can be identified for each of the testing category using threat categorization models as part of a threat modeling framework (e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not particular endorse any vendor specific threat categorization, but rather recommends to adopt a threat categorization and risk ranking that depends on specific objectives. In general categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures. Some threat categorizations also include risk rankings for the identified threats (e.g. STRIDE/DREAD) Example of specific objectives for the risk evaluation can be:

  • Regulatory and requirements compliance
  • Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
  • Overall risk strategy selection

Risks Calculation

Before any kind of calculation can be done appropriate values for the impact, ease of exploitation and exposure have to be found. Every risk parameter can be assigned a qualitative value based on its importance (e.g. severity). Using qualitative values rather than quantitative ones can help avoid the ranking becoming overly subjective. The same argument holds true for the number of different qualitative values, hence, only three different values (high, medium, low) are used.

However while determining qualitative values for risk several criteria and qualitative ranking systems can be used:

  • Proprietary common vulnerability list risk ranking
  • Industry standard vulnerability severity and risk rankings (CVSS)
  • Security-enhancing process models vulnerability root cause categorization (CLASP)
  • Threat modeling risk rankings (DREAD, TRIKE, PTA, CORAS/SECURIS, PTA)

Examples

Category Ref Number Name Finding Affected Item Comment/Solution Risk Value
Information Gathering Application Discovery
Spidering and googling
Analisys of error code
SSL/TLS Testing
DB Listener Testing
File extensions handling
Old, backup and unreferenced files
Business logic testing
Authentication Testing Default or guessable account
Brute Force
Bypassing authentication schema
Directory traversal/file include
Vulnerable remember password and pwd reset
Logout and Browser Cache Management Testing
Session Management Testing Session Management Schema
Session Token Manipulation
Exposed Session Variables
Session Riding
HTTP Exploit
Data Validation Testing Cross site scripting
HTTP Methods and XST
SQL Injection
Stored procedure injection
ORM Injection
LDAP Injection
XML Injection
SSI Injection
XPath Injection
IMAP/SMTP Injection
Code Injection
OS Commanding
Buffer overflow
Incubated vulnerability
Denial of Service Testing Locking Customer Accounts
User Specified Object Allocation
User Input as a Loop Counter
Writing User Provided Data to Disk
Failure to Release Resources
Storing too Much Data in Session
Web Services Testing XML Structural Testing
XML content-level Testing
HTTP GET parameters/REST Testing
Naughty SOAP attachments
Replay Testing
AJAX Testing AJAX Vulnerabilities



OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents