Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

OWASP

http://www.owasp.org

Approaches to Quantitative Risk Analysis for Web Applications

Lars EweCTO / VP of Eng.Cenziclars@cenzic.com

July, 2009

OWASP

Agenda

Risk Analysis for Web Applications

Common Scoring Systems

Cenzic HARM (Hailstorm Application Risk Metric)

Q & A

2

OWASP

Risk Analysis for Web Applications

Why a quantitative risk metric?

To help IT management manage risk and prioritize vulnerabilities and remediate those that pose the greatest risk.

Common risk metrics

What’s impacted? How big is the impact?

What kind of damage can be done? What kind of data can potentially be compromised? Etc.

How easy is the exploit? What are the required prerequisites / circumstances?

Remediation complexity

… 3

OWASP

Common Scoring Systems

Low-Medium-High qualitative system

Probably most common risk metric in use

Lacks granularity, doesn’t scale well

Not quantitative

4

OWASP

Common Scoring Systems – contd.

CVSS (Common Vulnerability Scoring System)

CVSS consists of three base groups (each consisting of a set of metrics):

Base –

Represents the intrinsic qualities of a vulnerability

Temporal –

Reflects the characteristics of a vulnerability that change over time

Environmental –

Represents the characteristics of a vulnerability that are unique to any user’s environment

Each group produces a numeric score (0 to 10)

For scoring guidelines and equations, see CVSS guide

5

OWASP

A Brief Look At CVSS Metrics

6

Name Values Description

Access Vector local, adjacent network, network

Reflects how the vulnerability is exploited

Access Complexity

high, medium, low

Measures the complexity of the attack required to exploit the vulnerability

Authentication multiple, single, none

Measures the number of times an attacker must authenticate to a target in order to exploit a vulnerability

Confidentiality Impact

none, partial, complete

Measures the impact on confidentiality of a successfully exploited vulnerability

Integrity Impact

none, partial, complete

Measures the impact to integrity of a successfully exploited vulnerability

Availability Impact

none, partial, complete

Measures the impact to availability of a successfully exploited vulnerability

Base –

Represents the intrinsic qualities of a vulnerability

OWASP

A Brief Look At CVSS Metrics

7

Name Values Description

Exploitability unproven, proof-of- concept, functional, high, not defined

Unproven, proof-of-concept, functional, high, not defined

Remediation Level

official fix, temporary fix, workaround, unavailable, not defined

Describes the level of available remediation

Report Confidence

unconfirmed, uncorroborated , confirmed, not defined

Measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details

Temporal –

Reflects the characteristics of a vulnerability that change

OWASP

A Brief Look At CVSS Metrics

8

Name Values Description

Collateral Damage Potential

none, low, low- medium, medium-high, high, not defined

Measures the potential for loss of life or physical assets through damage or theft of property or equipment

Target Distribution

none, low, medium, high, not defined

Measures the proportion of vulnerable systems

Security Requirements

low, medium, high, not defined

Allows for customization of CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of confidentiality, integrity, and availability

Environmental –

Represents the characteristics of a vulnerability that are unique to any user’s environment

OWASP

Cenzic HARM (Hailstorm Application Risk Metric)

Quantitative risk metric

The HARM score is built with inherent flexibility

HARM has a modifier, that we call a weight. This is the “application weight”

or “asset value”.

With the HARM Score, more is bad: 500 is worse than 50

Harm score example:

9

OWASP

Cenzic HARM – contd.

HARM takes 4 distinct impact areas into consideration:

Browser

Session

Application

Infrastructure (server environment)

Default HARM scores per vulnerability types represent Cenzic’s analysis of the risk inherent in the vulnerabilities, but can be modified by users

Visualize these four impact areas as a target in a topological ringed sense. Each quadrant of the target (“impact area”) is divided into 5 rings, ring 5 being the centermost ring, or the “bull’s eye”. The least type of application risk would hit Ring 1

10

OWASP

Cenzic HARM – Impact Areas

11

Each application risk level (ring) is named as followed:

1.Low

2.Moderate

3.Serious

4.Severe

5.Critical

OWASP

Cenzic HARM – contd.

Mathematically our Base Risk Equation is 2 raised to the power of the impact area value, times 10

Thus a vulnerability that is a critical security issue for the server environment (level 5) would score 320 (2^5 x 10)

12

OWASP

Cenzic HARM – contd.

So for each impact we can create a graph that shows the score of a risk level from 1 to 5 using the base risk equation:

13

OWASP

Cenzic HARM – contd.

Any vulnerability can impact a Web application in up to 4 different ways (4 impact areas). Within those 4 areas, the degree of the risk can be 1 (“low”) to 5 (“Critical”). The worst possible vulnerability would hit the “bull’s eye”

in all 4

areas:

14

OWASP

Cenzic HARM – contd.

What are the placement criteria Cenzic uses to determine the application risk level (ring) for a vulnerability? Answer: Security values. Each security value also has 5 degrees of risk. Examples of security values and associated risk degrees:

A buffer overflow may give instant control of a system and is rated "Access 5”

A flat file containing 10,000 credit card numbers that may be exposed to the internet in the Web server root is rated "Confidentiality 5“

Both are worst case scenarios scoring 320

15

OWASP

Cenzic HARM – contd.

In summary, scoring a vulnerability is a matter of:

How the application cluster is hit (which impact areas are affected)

How hard (degree of effect within each impact area)

In what way (security values) and an estimate of the probability of success.

Vulnerability risk is the sum of the risk score from each of the four impact areas. Vulnerability Risk Equation (using α, β, σ, ε

for the 4 different impact areas):

16

OWASP

Cenzic HARM – contd.

There are some addl. risk weights HARM considers:

Attack Complexity (χ). Examples:

Multi-staged XSS attack: "Complexity 3", with a Risk Weight of .8

Simple SQL Injection (' or 1=1 --'): “Complexity 5”, with a Risk Weight of 2

Detection Precision (δ). Examples:

Fuzzing and trapping error signatures, like buffer overflow: “Category 1 or 2”, with a Precision Weight < 1

In the case of XSS we inject a watermarked script into the application and monitor in Web browser for the presence of an event that matches our watermark. This allows us to detect XSS with less than 1% false positives: “Category 5”, with a Precision Weight of 1

Asset Value (ω)

Assigned by user (default: 1) 17

OWASP

Cenzic HARM – contd.

We can now compute the Adjusted Vulnerability Risk (using additional risk weights) as follows:

18

OWASP 19