OWASP - User contributions [en]

OWASP Risk Rating Methodology

2006-12-22T15:47:59Z

Mmorana: /* References */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting==

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for Information Technology Systems[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

* Threat Risk Modeling [http://www.owasp.org/index.php/Threat_Risk_Modeling]

* TRIKE Threat Modeling Methodology [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]

* Pratical Threat Analysis [http://www.ptatechnologies.com/]

* A Platform for Risk Analysis of Security Critical Systems [http://www2.nr.no/coras/]

* Model-driven Development and Analysis of Secure Information Systems [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]

* Value Driven Security Threat Modeling Based on Attack Path Analysis[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-22T15:45:59Z

Mmorana: /* References */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting==

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for Information Technology Systems[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

* Threat Risk Modeling [http://www.owasp.org/index.php/Threat_Risk_Modeling]

* TRIKE Threat Modeling Methodology [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]

* Pratical Threat Analysis [http://www.ptatechnologies.com/]

* A Platform for Risk Analysis of Security Critical Systems [http://www2.nr.no/coras/]

* Model-driven Development and Analysis of Secure Information Systems [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]

* T-MAP [http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-22T15:42:25Z

Mmorana: /* References */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting==

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for Information Technology Systems[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

* Threat Risk Modeling [http://www.owasp.org/index.php/Threat_Risk_Modeling]

* TRIKE Threat Modeling Methodology [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]

* Pratical Threat Analysis [http://www.ptatechnologies.com/]

* A Platform for Risk Analysis of Security Critical Systems [http://www2.nr.no/coras/]

* SECURIS [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]

* T-MAP [http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-22T15:39:39Z

Mmorana: /* References */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting==

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for
Information Technology Systems [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

* Threat Risk Modeling [http://www.owasp.org/index.php/Threat_Risk_Modeling]

* TRIKE Threat Modeling Methodology [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]

* Pratical Threat Analysis [http://www.ptatechnologies.com/]

* CORAS [http://www2.nr.no/coras/]
* SECURIS [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]
* T-MAP [http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-22T15:38:22Z

Mmorana: /* References */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting==

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for
Information Technology Systems [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

* Threat Risk Modeling [http://www.owasp.org/index.php/Threat_Risk_Modeling]

* TRIKE Threat Modeling Methodology [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]

* PTA [http://www.ptatechnologies.com/]
* CORAS [http://www2.nr.no/coras/]
* SECURIS [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]
* T-MAP [http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-22T15:34:10Z

Mmorana: /* Impact Factors */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting==

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for
Information Technology Systems [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

Threat modeling tools

* DREAD [http://www.owasp.org/index.php/Threat_Risk_Modeling]
* TRIKE [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]
* PTA [http://www.ptatechnologies.com/]
* CORAS [http://www2.nr.no/coras/]
* SECURIS [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]
* T-MAP [http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-22T15:32:24Z

Mmorana: /* Definitions */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]]

{{Template:OWASP Testing Guide v2}}

==Overview==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. It's important to have a system in place for rating risks, as it is all too easy to get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organization. But a vulnerability that is critical to one organization may not be very important to another. So we're presenting a framework here that you should customize for your organization.

We have worked hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on tailoring and weighting the model to customize it for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Our approach builds on the standard risk model:

Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations should customize and weight these factors to create their own standard for rating risks.

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to understand the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution, and use the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a vulnerability, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

===[[Threat Agent]] Factors===

; Skill level
: How technically skilled is this group of attackers? No technical skills, some technical skills, advanced computer skills, network and programming skills, security penetration skills

; Motivation
: How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward

; Opportunity
: How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, some access, full access

; Size
: How large is this group of attackers? All internet users, authenticated users, partners, intranet users, application users, administrators, developers

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically impossible, difficult, easy, automated tools available

; Ease of exploit
: How easy is it for this group of attackers to actually exploit this vulnerability? Theoretical, difficult, easy, automated tools available

; Awareness
: How well known is this vulnerability to this group of attackers? Public knowledge, all insiders, limited insiders

; Intrusion detection
: How likely is an exploit to be detected? Not logged, logged without review, logged and reviewed, active detection in application

==Step 3: Factors for Estimating Impact==

Impact is generally calculated based on annualized loss expectancy (ALE). Businesses should create a standard for what dollar amounts are significant to their business and establish some levels for Impact. Understanding the assets and functions involved, and the importance of confidentiality, integrity, and availability to the business is critical to getting good estimates of the real business impact. Reputation damage is frequently the driver here.

===[[Impact]] Factors===

The next set of factors are related to the [[impact]] to your business. The goal here is to estimate the likelihood of the particular vulnerability involved being identified and exploited. It's important to consider the totality of the circumstances here

; Ease of discovery
: How easy is it for this group of attackers to discover this vulnerability? Practically

==Step 4: Tailoring and Weighting

The real tailoring comes from weighting these factors according to your business. Having a risk ranking framework that's customizable for a business is critical for adoption. Otherwise, you'll spend lots of time arguing about the risk ratings that are produced.

==Step 5: Calculating the Overall Severity of a Risk==

Based on the factors and weights, you calculate whether the likelihood is L, M, or H and whether the impact is L, M, or H. Then you can calculate the overall risk with a 9-box.

HIGH LIKELIHOOD
Medium
High
Critical

MEDIUM LIKELIHOOD
Low
Medium
High

LOW LIKELIHOOD
Note
Low
Medium

LOW IMPACT
MEDIUM IMPACT
HIGH IMPACT

If the list is okay with this approach, I will write it up in time for the release. I can imagine a simple tool that queries you for information like what are your different user groups, etc.. then the tool allows you to weight the factors, then it produces a custom risk rating tool for your organization's application security findings. Built into report generator this would be very cool.

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST

* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==References==

* NIST 800-30 Risk Management Guide for
Information Technology Systems [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])

* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])

* Microsoft Web Application Security Frame [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp]

* Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]

Threat modeling tools

* DREAD [http://www.owasp.org/index.php/Threat_Risk_Modeling]
* TRIKE [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf]
* PTA [http://www.ptatechnologies.com/]
* CORAS [http://www2.nr.no/coras/]
* SECURIS [http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm]
* T-MAP [http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf]

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-12-21T14:54:57Z

Mmorana: /* Quantitative Risk Calculation Example */

OWASP Risk Rating Methodology

2006-11-21T02:46:18Z

Mmorana: /* Qualitative Risk Calculation Example (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, Web Application Security Frame[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp] etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05

'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example a buffer overflow vulnerability is found in a web application that is categorized as data validation threat according to the SecurityFrame. Since only client side validation is implemented instead of both client and server side input validation, the server is partially exposed to data validation threats. Therefore Exp = 7 is assigned (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calculation Example (TBD)===

Risk Parameters:
Impact (Imp)
* Critical
* High
* Medium
* Low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:42:15Z

Mmorana: /* Quantitative Risk Calculation Example */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, Web Application Security Frame[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp] etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05

'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example a buffer overflow vulnerability is found in a web application that is categorized as data validation threat according to the SecurityFrame. Since only client side validation is implemented instead of both client and server side input validation, the server is partially exposed to data validation threats. Therefore Exp = 7 is assigned (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calculation Example (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:41:41Z

Mmorana: /* Quantitative Risk Calculation Example */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, Web Application Security Frame[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp] etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example a buffer overflow vulnerability is found in a web application that is categorized as data validation threat according to the SecurityFrame. Since only client side validation is implemented instead of both client and server side input validation, the server is partially exposed to data validation threats. Therefore Exp = 7 is assigned (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calculation Example (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:35:53Z

Mmorana: /* Qualitative Risk Calcluation Example (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, Web Application Security Frame[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp] etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calculation Example (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:33:37Z

Mmorana: /* Threat Categorizations */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, Web Application Security Frame[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/TMWA.asp] etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calcluation Example (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:28:37Z

Mmorana: /* Qualitative Risk Calcluation Example */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calcluation Example (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:28:03Z

Mmorana: /* Risks Calculation Models (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models==
===Quantitative Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

===Qualitative Risk Calcluation Example ===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low
{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:25:40Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Risk Calculation Example ===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:22:37Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a data validation threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 
Using the values in the example:
* Cri=7.07
* Exp=7
Risk: sqrt((7^2+7.05^2))=7 (Medium Risk)

In general not all values fall nicely as 1 (Low,) 7 (Medium) or 10 (High), therefore a method should be available to associate qualitative values to generic numbers. This can be done by assigning qualitative values to the numeric criticality. In this case appropriate intervals have to be defined based upon the following:
*the combination of a Medium and Low value must lead to a Low value
*the combination of a High and a Medium value must lead to a High value

Using these two conditions the boundaries can be determined by using the root mean square again.
* Boundary between Low (L) and Medium (M): B1 > sqrt(M^2+L^2)/2)
* Boundary between Medium (M) and High (H): B2 < sqrt(M^2+H^2)/2)

Therefore the interval is L ≤ B1 < M < B2 ≤ H, or in numeric values L ≤ 5 < M < 8 ≤ H.
For example a Risk value between 1 and 5 is considered low, between 5 and 8 is considered medium and between 8 and 10 is considered High.

{{Category:OWASP Testing Project AoC}

OWASP Risk Rating Methodology

2006-11-21T02:05:23Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure) 

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T02:04:44Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats. Therefore Exp = 7 (partial exposure)

'''Risk Value Calculation'''
After the criticality ('''Cri''') and the vulnerability exposure ('''Exp''') values have been determined a final risk value can be computed. Since both criticality and exposure are defined by a quantitative value the risk value is again calculated by using the root mean square:
 
Risk = sqrt((Cri^2+Exp^2)/2)
 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T01:57:11Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05
 
'''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.
The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats that is a 7 value.

TBD 
Risk Value Calculation'''
TBD 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T01:56:09Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05

''''''Vulnerability Exposure Calculation'''
The vulnerability exposure (Exp) is the measure of susceptibility to a particular threat.

The vulnerability exposure of an asset can be measured on the 1 to 10 scale, where 1 indicates that the particular asset is not exposed to the vulnerability and 10 indicates that the asset is extremely open to the particular issue.
For degree to which an asset is exposed to the vulnerability can be factored as a degree of mitigation of the vulnerability due to countermeasures. A vulnerability with no countermeasures fully exposes the asset to the attack. For the purpose of vulnerability exposure three different qualitative values should be used; full, partial and none. For every threat it must be determined if a countermeasure has been found or not. If a countermeasure was found for a threat that exactly addresses the vulnerability that enables the threat, this threat can be regarded as fully mitigated (10 value). However, if a countermeasure has been found for a threat, but it does not provide this degree of protection the mitigation is only partial (7 value). Naturally, if no countermeasure was found, there is no mitigation (1 value).

For example the threat is found for a buffer overflow vulnerability that is categorized as data validation threat according to the SecurityFrame. Since only client side validation instead of both server side and client side input validation the buffer overflow vulnerability partially exposes the server to data validation threats that is a 7 value.

TBD 
Risk Value Calculation'''
TBD 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T01:30:35Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with the following qualitative values:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((10^2+7^2)/2)= 8.63

Finally the Criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05

''''''Vulnerability Exposure Calculation'''
TBD 
Risk Value Calculation'''
TBD 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T01:23:51Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with:
*DaP = Low (1)
*NoC = Medium (7)
*Dis = High (10)
*Rep = Medium (7)

Based upon these values, the following factors can be calculated:
*Imp: sqrt((1+7^2)/2)=5
*EoE: sqrt((100+49)/2)= 8.63

Finally the criticiality for the Threat is:
*Cri: sqrt((5^2+ 8.63^2)/2)= 7.05 (Medium)

''''''Vulnerability Exposure Calculation'''
TBD 
Risk Value Calculation'''
TBD 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T01:20:44Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the root mean square formula:

M = sqrt(H^2+L^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the corresponding numeric values for each of the qualitative risk parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact Value for a Threat: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a Threat: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

For example, based upon the questionnaire, a configuration management threat is rated with:
DaP = Low (1)
NoC = Medium (7)
Dis = High (10)
Rep = Medium (7)

The Impact for the Threat is = sqrt((1+7^2)/2)=5
The Ease of Explotation for the Threat is = sqrt((100+49)/2)= 8.63
The Criticiality for the Threat is =sqrt((5^2+ 8.63^2)/2)=7.05 (Medium)

''''''Vulnerability Exposure Calculation'''
TBD 
Risk Value Calculation'''
TBD 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T01:03:51Z

Mmorana: /* Example: B (TBD) */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==Application Security Risk Analysis==
===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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD[http://www.owasp.org/index.php/Threat_Risk_Modeling], TRIKE[http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf], PTA [http://www.ptatechnologies.com/], CORAS[http://www2.nr.no/coras/], SECURIS[http://heim.ifi.uio.no/~ketils/securis/the-securis-technical-description.htm], T-MAP[http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/ChenValueBasedSecurityThreatModel.pdf])

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

'''Threat Criticality Calculation'''
As already mentioned above, the criticality of threats is determined by the Impact ('''Imp''') and the Ease of exploitation ('''EoE''') risk factors.
The impact mainly depends on the Damage Potential ('''DaP''') and the number of components ('''NoC''') that are affected by a threat. The Ease of Exploitation ('''EoE''')is determined by the Degree of Discoverability ('''Dis''') and Reproducibility ('''Rep''').

However, before any kind of calculation can be done, appropriate values for these parameters have to be found. A generic questionnaire can provide some example questions that support the determination of these qualitative values based upon each threat categorization.
For the scope of this risk model, the SecurityFrame Threat categorization will be used.

Based on the values assigned to the risk parameters of DaP, NoC, Dis and Rep the two representative values for Criticality ('''Cri''') of the Threat and Ease of Exploitation ('''EoE''') have to be determined.

Hence, some kind of function has to be found, that should provide the following features for its result:
* depend on all corresponding parameters
* be some kind of average of the individual values
* be more dependent on high input values

To provide these features the root mean square formula will be used [http://en.wikipedia.org/wiki/Root_mean_square].
However, before any calculation can be carried out, numeric representations have to be found for the qualitative values. Since the combination of a High and a Low value should lead to a Medium value, the numeric values can be determined by applying the following formula:

* the combination of a High and a Low value should lead to a Medium value
V= sqrt(V1^2+V2^2)

Hence, if the Low and High value have been defined, it is possible to calculate the corresponding Medium value. Throughout this model the numeric values for High and Low will be 10 and 1 respectively, which leads to a rounded value of 7 for Medium. Using the numeric values of the parameters, the values for impact and ease of exploitation can be calculated by using the following formulas:

Impact value for a threat can be calculated with the following formula: 
Imp = sqrt((DaP^2+NoC^2)/2) 
where:
*DaP = Damage Potential Value for Threat
*NoC = Number of Affected Components Value for Threat

Ease of Explotation for a threat can be calculated with the following formula: 
EaE= sqrt((DiS^2+Rep^2)/2) 
where:
*Dis = Discoverability Value for Threat
*Rep = Reproducibility Value for Threat

The two calculated values can be finally combined to determine the criticality value of a threat as:
Cri = sqrt((Imp^2+EaE^2)/2)

''''''Vulnerability Exposure Calculation'''
TBD 
Risk Value Calculation'''
TBD 

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-21T00:56:01Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-21T00:43:40Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-21T00:34:17Z

Mmorana: /* EoE */

OWASP Risk Rating Methodology

2006-11-21T00:33:37Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-21T00:32:27Z

Mmorana: /* Threat Categorizations */

OWASP Risk Rating Methodology

2006-11-20T03:38:12Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-20T03:37:17Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-20T03:31:11Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-20T03:23:14Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-20T03:16:57Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-20T03:13:25Z

Mmorana: /* Threat Criticality Calculation */

OWASP Risk Rating Methodology

2006-11-20T03:12:10Z

Mmorana: /* Example: B (TBD) */

OWASP Risk Rating Methodology

2006-11-20T02:57:35Z

Mmorana: /* Risk Ranking Systems */

OWASP Risk Rating Methodology

2006-11-20T02:54:11Z

Mmorana: /* Risk Ranking Systems */

OWASP Risk Rating Methodology

2006-11-20T02:35:54Z

Mmorana: /* Application Security Risks */

OWASP Risk Rating Methodology

2006-11-20T02:28:04Z

Mmorana: /* Risk Ranking Systems */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection

==Risk Ranking Systems==
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 risk ranking systems can be used:
* Proprietary common vulnerability list risk ranking
* Industry standard vulnerability severity and risk rankings (CVSS[http://www.first.org/cvss/])
* Security-enhancing process models vulnerability root cause categorization (CLASP [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project])
* Threat modeling risk rankings (DREAD, TRIKE, PTA, CORAS/SECURIS)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T02:18:35Z

Mmorana: /* Threat Categorizations */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment. A critical review of threat categorization frameworks can be found in the Security In The Software Lifecycle from DHS [https://buildsecurityin.us-cert.gov/daisy/bsi/87/version/12/part/4/data/Draft+Security+in+the+Software+Lifcycle+v1.2.pdf?branch=main&language=default]In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection

==Risk Ranking Systems==
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 risk 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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T02:12:35Z

Mmorana: /* Definitions */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems of NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection

==Risk Ranking Systems==
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 risk 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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T02:12:02Z

Mmorana: /* Definitions */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
For the scope of the risk assessments of this guide the definitions for risk, threat and vulnerability are taken from the the Risk Management Guide for Information Technology Systems fro NIST[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection

==Risk Ranking Systems==
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 risk 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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T01:59:29Z

Mmorana: /* Risk Raniking Systems */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection

==Risk Ranking Systems==
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 risk 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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T01:59:12Z

Mmorana: /* Risks Calculation */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection

==Risk Raniking Systems==
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 risk 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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T01:57:52Z

Mmorana: /* Risks Calculation */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*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 risk 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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T01:56:46Z

Mmorana: /* Threat Categorizations */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.
Example of specific objectives for the risk evaluation are:
*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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T01:56:09Z

Mmorana: /* Threat Categorizations */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.
Example of specific objectives for the risk evaluation are:
*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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}

OWASP Risk Rating Methodology

2006-11-20T01:55:41Z

Mmorana: /* Threat Categorizations */

[[http://www.owasp.org/index.php/Writing_Reports:_value_the_real_risk_AoC Up]] 
{{Template:OWASP Testing Guide v2}}
==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 assessment, threat and vulnerability represent the two factors (i.e. multipliers) used for risk calculation. Depending on the empirical risk formulation choosen, different parameters can be used to characterize threats and vulnerabilities and calculate the final risk value. By associating risk values to each of the findings it is possible to prioritize vulnerabilities anf fix first the ones with higher risks that is by threats with highest impact, ease of exploitation and exposure. On the other hand, information risk analysts also look to other risk factors while 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 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 found vulnerabilities and identified threats. 

===Definitions===
* '''Risk''' is the probability that a particular threat will exercise a particular information system vulnerability and the resulting impact if this should occur.
* '''Threat''' is the potential to exercise (accidentally trigger or intentionally exploit) a specific vulnerability
* '''Vulnerability''' is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentially triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

==Risks Formulation==

For the purposes of a security assessment, OWASP defines the risk associated with a security finding as a product of the Impact ('''Imp'''), Ease of Exploitation ('''EoE''') and Exposure ('''Exp'''): 
 
'''Risk = Imp x EoE x Exp 
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 testing guide, threats can be identified for each of the testing category using threat categorization frameworks(e.g. STRIDE, TRIKE, SecurityFrame etc). OWASP does not endorse any specific threat categorization, but rather recommends the adoption of a threat categorization depending on the specific objectives of the security assessment.
Example of specific objectives for the risk evaluation are:
*Regulatory and requirements compliance
*Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
*Overall risk strategy selection
In general, categorizations that focus on threats rather than attacks are more suitable for the identification of countermeasures.

==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)

==Risks Calculation Models (TBD)==
===Example: A (TBD)===

Risk Categories:
Impact (imp)
* critical
* high
* medium
* low
Ease of Exploitation (EoE)
* Easy
* Moderate
* Difficult
Exposure (Exp)
* Very high
* High
* Medium
* Low

===Example: B (TBD)===

{{Category:OWASP Testing Project AoC}}