OWASP Risk Rating Methodology

Revision as of 20:35, 22 December 2006 by Jeff Williams (Talk | contribs)

Jump to: navigation, search


OWASP Testing Guide v2 Table of Contents


The OWASP Risk Rating Methodology

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. Having a system in place for rating risks will save time and eliminate arguing about priorities. This system will help to ensure that you don't 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 basic 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 customization for more information about tailoring the model for use in your organization.


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.

The approach presented here builds on the standard risk model:

      Risk = Likelihood * Impact

In the sections below, we break down the factors that make up "likelihood" and "impact" and show how to combine them to determine the severity of the risk.

  • Step 1: Identifying a Risk
  • Step 2: Factors for Estimating Likelihood
  • Step 3: Factors for Estimating Business Impact
  • Step 4: Customizing Your Risk Rating Model
  • Step 5: Determining Severity of the Risk

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
How motivated is this group of attackers to find and exploit this vulnerability? Low or no reward, possible reward, high reward
How much opportunity does this group of attackers have to find and exploit this vulnerability? No known access, limited access, full access
How large is this group of attackers? Developers, system administrators, intranet users, partners, authenticated users, anonymous Internet users

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
How well known is this vulnerability to this group of attackers? Limited insiders, all insiders, public knowledge
Intrusion detection
How likely is an exploit to be detected? Active detection in application, logged and reviewed, logged without review, not logged

Step 3: Factors for Estimating Impact

When considering the impact of a successful attack, it's important to realize that there are two kinds of effects. The first is the "technical impact" on the application, the data it uses, and the functions it provides. The other effect is the "business impact," which is the effect on the business of the successful attack.

Understanding the technical impact is

, it is even more important to gain insight into the business impact, which is the effect on the business if this risk is ever realized. In any case,

Technical Impact Factors

The next set of factors are related to the technical impact to the application. These are the consequences to the application of a successful exploit of the vulnerability you're evaluating.

Loss of confidentiality
How much data is disclosed and how sensitive is it? Minimal non-sensitive data disclosed, minimal critical data disclosed, extensive non-sensitive data disclosed, extensive critical data disclosed, all data disclosed
Loss of integrity
How much data was corrupted and how damaged is it? Minimal slightly corrupt data, minimal seriously corrupt data, extensive slightly corrupt data, extensive seriously corrupt data, all data totally corrupt
Loss of availability
How much service was lost and how vital was it? Minimal secondary services interrupted, minimal primary services interrupted, extensive secondary services interrupted, extensive primary services interrupted, all services completely lost
Loss of accountability
Are the attackers' actions traceable to an individual? Fully traceable, possibly traceable, completely anonymous

Business Impact Factors

Technical risk does not take into account business impacts. Technical risk, although useful in a limited way (primarily to developers), is not useful for the vast majority of risk decisions. In general, you should be aiming to justify your findings with a business risk, particularly if the audience for the risk table or report is executive level. This justifies action being taken, whereas a purely technical risk, even high ones, would most likely not be acted upon.

Business risk is the primary motivator for undertaking remediation activities. Business risks incorporate one or more elements of the following impacts:

Asset classification

Not all risks are worth fixing, and some loss is not only expected, but justifiable based upon the cost of fixing the issue. For example, if it would cost $100,000 to implement controls to stem $2000 of fraud per year, it would take 50 years return on investment to stamp out the loss. The only way to understand the cost to a business is to classify the asset. Assets are not just physical, they are intangibles, such as data.

  • Reputation
  • Financial
  • Governance or ethical risks
  • Legal or compliance
  • Privacy
  • Regulatory (for organizations regulated in some way)

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.

This is a step that you should only have to do once.

Step 5: Determining the Severity of a Risk

In this step we're going to put together the likelihood estimate and the impact estimate to calculate an overall severity for this risk.

First we need to figure out the overall likelihood. Reviewing all the likelihood factors, your job is to determine whether there is realistically a LOW, MEDIUM, or HIGH likelihood of this being discovered and exploited. Many security practitioners are willing to eyeball the factors and make this judgement. However, if you need to have repeatable results, you can simply average the scores for all of the threat and vulnerability factors.


Next, we need to figure out the overall impact. The process is similar here. You can make an estimate based on the factors, or you can average the scores for each of the factors.


Now, we can combine the overall likelihood and impact scores to get a final severity rating for this risk.



  • NIST 800-30 Risk Management Guide for Information Technology Systems [1]
  • AS/NZS 4360 Risk Management [2]
  • Industry standard vulnerability severity and risk rankings (CVSS) [3]
  • Security-enhancing process models vulnerability root cause categorization (CLASP) [4]
  • Microsoft Web Application Security Frame [5]
  • Security In The Software Lifecycle from DHS [6]
  • Threat Risk Modeling [7]
  • Pratical Threat Analysis [8]
  • A Platform for Risk Analysis of Security Critical Systems [9]
  • Model-driven Development and Analysis of Secure Information Systems [10]
  • Value Driven Security Threat Modeling Based on Attack Path Analysis[11]