[Owasp-leaders] Potential Update to the OWASP Risk Rating Methodology

Josh Sokol josh.sokol at owasp.org
Tue Mar 12 17:15:48 UTC 2013


I agree with what you said Dennis and truly appreciate your comment.
Having said that, one of our primary communities of outreach is
developers.  Sure, they should have security professionals to help convey
risk, but that's not always the case.  And if those developers are using
this as a means to rate their risks because this is OWASP's suggested Risk
Rating Methdology, then we have issues.  It's not necessarily an issue of
LOW compared to what.  It's LOW based on the Risk Assessment Methodology's
suggestion for what averaged impact amounts to LOW.  And I do agree that
your scenario would be a more significant (ie. higher priority) than my
scenario and with my suggestion they would come out to the same risk.  But,
and this is just my personal opinion, I'd rather have these two both rated
at the same impact than to have my example trumped by just about everything
that averages out about a 2.25.

I agree with your assertion that context is everything, but isn't the goal
of this methodology to try and fit the impact (and subsequent risk) into
the users context using these criteria?  If so, then aren't we effectively
showing them the best-case scenario by using this average as part of the
methodology rather than the worst-case scenario by using a maximum value?

~josh

On Tue, Mar 12, 2013 at 11:53 AM, Dennis Groves <dennis.groves at owasp.org>wrote:

> On 12 Mar 2013, at 16:37, Josh Sokol wrote:
>
> [ snip ]
>
> Use SQL Injection as an example for technical impact. You have a read-only
> user and the flaw allows full disclosure of data in the database with full
> audit trails turned on. According to the methodology, this would be all
> data disclosed (9 - Confidentiality), no corrupt data (0 - Integrity), no
> loss of availability (0 - Availability), and fully traceable (0 -
> Accountability). Based on the methodology, you then average these values
> so we get a technical impact of 2.25 (LOW). I would argue, however, that
> the technical impact of this particular vulnerability for this specific
> situation would still be high. Any dissenting thoughts on this? Agreement?
>
> The problem is that it is LOW *Compared* to WHAT?
>
> It is Low compared to threats and vulnerabilities that disclose data (9 -
> Confidentiality), corrupt data (9 - all data totally corrupt), which
> results in (9 - all services completely lost) and the attacker was
> anonymous (9 - completely anonymous).
>
> Since your example doesn't have an attack like this to be compared
> against, it seems very inaccurate (to be honest most of us never find a
> smoking gun of this nature, but we often find a lot of SQLi).
>
> This is not to say that SQLi is not serious, it can be game over for a
> company. However, the risk rating methodology doesn't understand context.
>
> This is why the companies hire security consultants. It is up to use to
> take this completely arbitrary and subjective idea of risk and to adjust it
> to reflect the current business context.
>
> Everything depends heavily on the context. And our most difficult job is
> actually understanding the clients business so that when we make a
> recommendation about SQLi - it is credible and as a result we continue to
> be trusted because our recommendations are credible.
>
> Dennis
> ------------------------------
>
> Dennis Groves <http://about.me/dennis.groves>, MSc
> Email me <dennis.groves at owasp.org> or schedule a meeting<http://goo.gl/8sPIy>
> .
>
> *This email is licensed under a CC BY-ND 3.0<http://creativecommons.org/licenses/by-nd/3.0/deed.en_GB>license.
> *
>
> *Please do not send me Microsoft Office/Apple iWork documents.*
> Send OpenDocument <http://fsf.org/campaigns/opendocument/> instead!
> Stand up for your freedom to install free software<http://www.fsf.org/campaigns/secure-boot/statement>
> .
>
> The idea that some lives matter less is the root of all that’s wrong with
> the world. -- Paul Farmer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130312/5fe8bbb9/attachment.html>


More information about the OWASP-Leaders mailing list