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