[Owasp-testing] Defining Risk
sebastien.deleersnyder at ascure.com
Tue Dec 19 04:32:49 EST 2006
It should also be clear that we are testing for vulnerabilities and also
report them as such, but that will go into the following section?
PS: didn't we start with this :-)?
From: owasp-testing-bounces at lists.owasp.org
[mailto:owasp-testing-bounces at lists.owasp.org] On Behalf Of Eoin
Sent: dinsdag 19 december 2006 9:40
To: Daniel Cuthbert
Cc: owasp-testing at lists.owasp.org
Subject: Re: [Owasp-testing] Defining Risk
This is nicer, easier to apply, sharper and in my view better suited.
On 18/12/06, Daniel Cuthbert <daniel.cuthbert at owasp.org> wrote:
anyone who knows me well, knows i'm blonde and therefore need it done
as simply as possible :0)
Where I work (Corsaire), we use a well proven way of defining risk.
This isn't something we plucked out of the blue, but something that
came with over 8 years experience in doing this voodoo and based on
client feedback, it works!
Risk = imp x eoe x exp x nominal value.
We have gone over the above little equation in previous mails, so i
wont bother doing it again. But the main difference here is applying
it and defining a rating. I have always liked the following method:
Critical (attacker owns the box, end of story)
High (attacker gains access through some vulnerability and can then
do further damage)
Medium (attacker can't really gain direct access, but can cause other
Low (info leakage etc)
2: Ease of exploitation
Easy (any muppet with a browser can do it)
Moderate (attacker needs to have some skills and knowledge)
Difficult (no skript kiddy or hacking exposed reader could do it)
Very high (any issue which is externally facing and available to the
world and does not need any authentication)
High (the issue is exposed over the web or via 3rd parties but only
to authenticated/registered users)
Medium (the host is widely available to known users. Think corporate
Low (host is on a secured lan with very limited access)
4: Nominal Value
High (Any business critical system!)
Medium (important applications)
Any manager reading the above, and applying it to a vulnerability
such as weak session ID generation, would understand it. The biggest
problem we are currently facing in our industry is one of standards.
There are so many ways to define this and that, we need to be strong
and say "THIS IS THE OWASP WAY"
On 18 Dec 2006, at 22:06, Marco M.Morana wrote:
> Dan & Eoin
> The critique expressed herein on quantitative risk models reflects
> my opinion too. It
> was introduced herein as an example (not the method just an
> example) and leaving room
> for a qualitative risk analysis to be compared with and eventually
> chosen as a
> My day to day experience with qualitative risk analysis consists on
> assigning to each
> vulnerability a risk factor based upon impact and easy of
> exploitation. The limitation
> I see on this is that relies mostly on the experience and knowledge
> of the pen tester
> while assigning risk factors. Experienced pen testers can do a risk
> evaluation in a
> bit based upon similar scenarios, type of vulnerability and
> knowledge of similar
> So probably the question is how this risk evaluation guideline can
> can help less
> experienced pen testers. I think a risk questionnaire could
> probably help evaluate
> risks for common vulnerabilities in typical attack scenarios.
> On Mon Dec 18 8:49 , Eoin sent:
>> If we can get something "simple" but effective quickly I would go
>> for that.
>> I would prefer if we stayed away from academic risk analysis and
>> Some of the intro documentation can still be used also.
>> On 18/12/06, Daniel Cuthbert daniel.cuthbert at owasp.org> wrote:
>> Agreed, this is the common approached used by most of the clients
>> we work with,
> especially the banking sector.
>> Matteo i know you don't want to change it and get a draft out, but
>> we need to be
> aware that many will follow our guide as the gospel on app testing
> and i'd rather we
> delay some bits so that newcomers to our industry have a good solid
> footing and not
> the one i had when this industry was started (
>> a.k.a make up what you want, there isn't anyone to disagree)
>> What do you think? should we quickly agree on something less
>> complex and get it
> written up (i can do this as im currently on holiday and have less
> commitments than
>> On 18 Dec 2006, at 19:01, Eoin wrote:
>> Yep agreed.
>> One thing I've always hated about assigning risk is to use these
>> formulas which at
> times do not take context into account, if the vulnerability is
> internal facing only,
> is it exposed to unauthenticated users or authenticated only.
>> There must be a rule of thumb relating to assigning how much of a
>> risk a particular
> vulnerability is but avoiding complex academic formulas.
>> To me Risk is as simple as defining how damaging a vulnerability
>> exploit may be if
> exploited and how easy/accessible it is to commit the exploit.
>> Also taking into account if the vulnerability is externally facing
>> or is it internal
> on a "secure" LAN segment?
>> On 17/12/06, Daniel Cuthbert daniel.cuthbert at owasp.org
>> 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
>> 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.
>> 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
>> Owasp-testing mailing list
>> Owasp-testing at lists.owasp.org
>> Eoin Keary OWASP - Ireland
>> Eoin Keary OWASP - Ireland
Eoin Keary OWASP - Ireland
---- 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-testing