[Owasp-testing] Defining Risk

Daniel Cuthbert daniel.cuthbert at owasp.org
Mon Dec 18 10:26:37 EST 2006

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:

1: Impact
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)

3: Exposure
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  
lan applications)
Low (host is on a secured lan with very limited access)

4: Nominal Value
High (Any business critical system!)
Medium (important applications)
Low (workstations)

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  

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
> reference.
> 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
> applications.
> 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.
> Marco
> On Mon Dec 18  8:49 , Eoin  sent:
>> Gents,
>> 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  
>> statistics.
>> Some of the intro documentation can still be used also.
>> -ek
>> 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
> usual)
>> 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?
>> -ek
>> On 17/12/06, Daniel Cuthbert daniel.cuthbert at owasp.org
>>> wrote:
>> 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
>> -- 
>> Eoin Keary OWASP - Ireland
>> http://www.owasp.org/local/ireland.html
>> http://www.owasp.org/index.php/OWASP_Testing_Project
>> http://www.owasp.org/index.php/OWASP_Code_Review_Project
>> -- 
>> Eoin Keary OWASP - Ireland
>> http://www.owasp.org/local/ireland.html
>> http://www.owasp.org/index.php/OWASP_Testing_Project
>> http://www.owasp.org/index.php/OWASP_Code_Review_Project

More information about the Owasp-testing mailing list