Read this OWASP presentation on how companies measure risk in their Web applications. Presented at the Bay Area OWASP event (January 2010) by Cenzic CTO, Lars Ewe.

1. Approaches to Quantitative
Risk Analysis for Web
Applications
Lars Ewe
CTO / VP of Eng.
Cenzic
lars@cenzic.com
OWASP
July, 2009
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org

2. Agenda
 Risk Analysis for Web Applications
 Common Scoring Systems
 Cenzic HARM
(Hailstorm Application Risk Metric)
Q & A
OWASP 2

3. 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
… OWASP 3

4. Common Scoring Systems
 Low-Medium-High qualitative system
 Probably most common risk metric in use
 Lacks granularity, doesn’t scale well
 Not quantitative
OWASP 4

5. 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
OWASP 5

6. A Brief Look At CVSS Metrics
Base – Represents the intrinsic qualities of a vulnerability
Name Values Description
Access Vector local, adjacent Reflects how the vulnerability is exploited
network,
network
Access high, medium, Measures the complexity of the attack required
Complexity low to exploit the vulnerability
Authentication multiple, Measures the number of times an attacker must
single, none authenticate to a target in order to exploit a
vulnerability
Confidentiality none, partial, Measures the impact on confidentiality of a
Impact complete successfully exploited vulnerability
Integrity none, partial, Measures the impact to integrity of a successfully
Impact complete exploited vulnerability
Availability none, partial, Measures the impact to availability of a
Impact complete successfully exploited vulnerability
OWASP 6

7. A Brief Look At CVSS Metrics
Temporal – Reflects the characteristics of a vulnerability that change
Name Values Description
Exploitability unproven, Unproven, proof-of-concept, functional, high, not
proof-of- defined
concept,
functional,
high, not
defined
Remediation official fix, Describes the level of available remediation
Level temporary fix,
workaround,
unavailable,
not defined
Report unconfirmed, Measures the degree of confidence in the
Confidence uncorroborated existence of the vulnerability and the credibility
, confirmed, of the known technical details
not defined
OWASP 7

8. A Brief Look At CVSS Metrics
Environmental – Represents the characteristics of a vulnerability
that are unique to any user’s environment
Name Values Description
Collateral none, low, low- Measures the potential for loss of life or physical
Damage medium, assets through damage or theft of property or
Potential medium-high, equipment
high, not
defined
Target none, low, Measures the proportion of vulnerable systems
Distribution medium, high,
not defined
Security low, medium, Allows for customization of CVSS score
Requirements high, not depending on the importance of the affected IT
defined asset to a user’s organization, measured in terms
of confidentiality, integrity, and availability
OWASP 8

9. 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:
OWASP 9

10. 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
OWASP 10

11. Cenzic HARM – Impact Areas
Each application risk
level (ring) is named
as followed:
1.Low
2.Moderate
3.Serious
4.Severe
5.Critical
OWASP 11

12. 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)
OWASP 12

13. 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:
OWASP 13

14. 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:
OWASP 14

15. 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
OWASP 15

16. 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):
OWASP 16

17. 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) OWASP 17

18. Cenzic HARM – contd.
 We can now compute the Adjusted Vulnerability Risk
(using additional risk weights) as follows:
OWASP 18

19. OWASP 19