[Owasp-testing] Defining Risk

Sebastien Deleersnyder sebastien.deleersnyder at ascure.com
Mon Dec 18 05:22:26 EST 2006


We should maybe take a step back here.

My understanding of testing the security of a web application is that we
try to detect the vulnerabilities. 
For each of the found vulnerabilities we score them: Critical / High /
Medium or Low.

Besides that we should indicate what the related risks are: eg.
Impersonation, DoS. But then calculating these risks depends on the
threats and assets of the web application that is tested. This requires
a threat modeling or risk analysis exercise. If input on Threats and
asset value is available, the risks can be calculated.

In most testing engagements we only rate the found vulnerabilities and
indicate how to integrate this with the risk rating of the customer.

This can be rephrased as:
For each of the found vulnerabilities we score them: Critical / High /
Medium or Low. Based on three major guidelines, but each time with the
vulnerability viewpoint in mind:
*Impact: If the vulnerability is exploited, how serious is the impact on
business operations?
*Ease: What are the impediments to an attacker attempting to exploit the
*Activity: Are there active attempts under way to exploit the
The first two guidelines represent a simplified view of the "cost of
attack" and "probability of attack" parameters used in classic risk
assessment methodologies. However, impact focuses on the specific
actions an attacker could take if successful, while ease gauges how much
knowledge and effort would be required on the part of the attacker to be
successful. The third guideline has become increasingly important as
more and more vulnerabilities are discovered.  

It also helps to give examples:

Critical Level: these are the most critical issues and vulnerabilities.
Attackers can gain control over the attacked machine as root or
administrator. These are high vulnerabilities where administrative
access has been obtained on the target.
High Level: these are major issues and vulnerabilities that cause severe
damage. These are vulnerabilities that give intruders the opportunity to
perform the following:
*run arbitrary code on target or to place the target in an unpredictable
*view and modify arbitrary files or parameters on the target;
*impersonate an authorized user or process on the target;
*crash target or cause denial of service.
Medium Level: these are issues and vulnerabilities that cause medium
damage to the customer, without limiting the daily operation of the
customer, allows and attacker to:
*change the content of a web server;
*view specific files with known paths;
*saturate logging and accounting files;
*gain information that can lead to a high or very high  impact attack.
Low Level: these are issues and vulnerabilities which have minor or no
impact for the customer. However, these are bad for the image of the
customer and/or cause an information leakage:
*IP-address of internal machines or internal contact which is displayed
in the source code of the web pages;
*Allows an attacker to gain general information about target

This is a simpler approach and can normally be integrated with any risk
calculation methodology.

We can of course keep the references tho the more complicated methods.



> -----Original Message-----
> From: owasp-testing-bounces at lists.owasp.org [mailto:owasp-testing-
> bounces at lists.owasp.org] On Behalf Of Jeff Williams
> Sent: maandag 18 december 2006 7:46
> To: Daniel Cuthbert; owasp-testing at lists.owasp.org
> Subject: Re: [Owasp-testing] Defining Risk
> Thanks Daniel for pointing this out.  I agree with your comments.
> has always stood for practical workable solutions and not for too much
> theory.  Personally, I've never bought into any methodology that is
> quantitative as there is simply way too much uncertainty in appsec
> estimates to make the math work well.
> I think the basic process is pretty simple.  Estimate a bunch of
> and calculate the likelihood, then estimate a few factors and
> the business impact.  Then multiply these to get the overall risk.
> I believe we should flesh out these factors, show people how to weight
> the factors as appropriate for their business, and be done with it.
> This process is pretty close to what I'm talking about.
>   -
> http://www.riskmanagementinsight.com/media/docs/FAIR_introduction.pdf.
> My papers on this from the 90's
>   - http://www.acsac.org/1998/presentations/fri-b-1030-jelen.pdf
>   - http://www.sse-cmm.org/docs/Arguing.pdf
> --Jeff
> -----Original Message-----
> From: owasp-testing-bounces at lists.owasp.org
> [mailto:owasp-testing-bounces at lists.owasp.org] On Behalf Of Daniel
> Cuthbert
> Sent: Sunday, December 17, 2006 7:48 AM
> To: owasp-testing at lists.owasp.org
> Subject: [Owasp-testing] Defining Risk
> I've spent today looking at what has been written so far and I feel
> we are venturing into some dangerous territory with what we are
> suggesting.
> We need a easy to use, and understand, method of defining risk and
> the one we have at the moment will cause more confusion than good.
> https://www.owasp.org/index.php/How_to_value_the_real_risk_AoC
> The section on Quantitative Risk Calculation seems to be heavily
> based upon some complex mathematical formula, but does anyone
> honestly know how to do this?
> I've shown this to a number of pentesters and colleagues and they all
> agree that they would not use the above approach as it's overly
> complicated.
> Thoughts?
> _______________________________________________
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
> http://lists.owasp.org/mailman/listinfo/owasp-testing
> _______________________________________________
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
> http://lists.owasp.org/mailman/listinfo/owasp-testing
---- eMail Disclaimer ----
This message may be confidential. It is also solely for the use of the individual or group to whom it is addressed. If you have received it 
by mistake, please let us know by e-mail reply. Ascure is not liable for any direct or indirect damage arising from errors, inaccuracies or 
any loss in the message, from unauthorized use, disclosure, copying or alteration of it.
For the complete version or other languages of this disclaimer see http://www.ascure.com/disclaimer.htm

More information about the Owasp-testing mailing list