[Owasp-testing] Defining Risk

Yvan Boily yboily at gmail.com
Mon Dec 18 08:28:59 EST 2006


Perhaps using CVSS for rating vulnerabilities, that way there is at
least a clearly quantifiable mechanism for rating the individual
vulnerability.

Once you have a CVSS metric you can assess the risk of the
vulnerability in the context of the entire system you are analyzing.

In the past I have experimented with using weighted graphs of the
communications path through the deployment environment to calculate
the risk, with the weight of each node on the graph being dependent on
the security controls in place.

Thoughts?

On 12/18/06, Sebastien Deleersnyder <sebastien.deleersnyder at ascure.com> wrote:
> Hi,
>
> 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
> vulnerability?
> *Activity: Are there active attempts under way to exploit the
> vulnerability?
> 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
> state;
> *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.
>
> Regards,
>
> Sebastien
>
> > -----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.
> OWASP
> > has always stood for practical workable solutions and not for too much
> > theory.  Personally, I've never bought into any methodology that is
> very
> > 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
> factors
> > and calculate the likelihood, then estimate a few factors and
> calculate
> > 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
> _______________________________________________
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
> http://lists.owasp.org/mailman/listinfo/owasp-testing
>


-- 
____
ygjb
Computer Science is no more about computers than astronomy is about
telescopes. E. W. Dijkstra


More information about the Owasp-testing mailing list