This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP Risk Rating Methodology"
| Line 11: | Line 11: | ||
==Approach== | ==Approach== | ||
| − | There are many different approaches to risk analysis. | + | 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: |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | The OWASP approach is based on these standard methodologies and is customized for application security. | ||
| Line 23: | Line 17: | ||
| − | In the sections below, we break down the factors that make up "likelihood" and "impact". Organizations | + | 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: 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 hole? 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 | ||
| − | + | 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 | |
| − | + | [[Vulnerability]] factors: | |
| + | Ease of discovery | ||
| + | Awareness | ||
| + | Tools available | ||
| + | Mitigating controls in place | ||
| + | Accountability (not logged, logged w/o review, logged and reviewed) | ||
| − | ==Step 3: Estimating Impact== | + | ==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 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. | ||
| Line 75: | Line 62: | ||
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. | 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. | ||
| − | |||
| − | |||
| − | + | ==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. | |
Revision as of 11:51, 22 December 2006
[Up]
OWASP Testing Guide v2 Table of Contents
Overview
Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Of course, a vulnerability that is critical to one organization may not be very important to another. But having a standard way of rating vulnerabilities within an organization is extremely important. A risk rating standard allows security issues to be prioritized, so that an organization can make informed decisions about where to focus security investments.
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: 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 hole? 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
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
Vulnerability factors:
Ease of discovery Awareness Tools available Mitigating controls in place Accountability (not logged, logged w/o review, logged and reviewed)
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.
Since none of these factors are very easy to measure, it's best to have enumerated lists (like accountability above) for each factor that make sense for the particular business.
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.
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
- 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.
- Regulatory and requirements compliance
- Tactical prioritization for mitigation of vulnerabilities (e.g. high risk first)
- Risk strategy selection
References
- NIST 800-30 Risk Management Guide for
Information Technology Systems [1]
- Industry standard vulnerability severity and risk rankings (CVSS[2])
- Security-enhancing process models vulnerability root cause categorization (CLASP [3])
- Microsoft Web Application Security Frame [4]
- Security In The Software Lifecycle from DHS [5]
Threat modeling tools
{{Category:OWASP Testing Project AoC}