From: v b (r0cketgrl@yahoo.com)
Date: Fri Nov 04 2005 - 14:48:00 EST
All --
Asset valuation has always been a speed bump in the
security management life cycle. Many of the
organizations for whom I have performed assessments
haven't a clue about the value and criticality that
their systems and information assets have in regard to
their business. Thus, for many businesses, it is
close to impossible to quantify the ALE for any
vulnerability/risk model. So the industry has swung
more toward qualifiable risk models.
It is possible to use a hybrid model for some
organizations, if they have some historical data to
feed into the algorithms one uses. But this is not
likely, thus, the whole point of using qualifiable
models over quantifiable is that it is easier.
Qualifiable algorithms are subjective, whereas
quantifiable are more objective. But if you don't
have the appropriate data, then I agree with Pete. You
don't have a realistic view of the organization's
security posture. As for pen-tests, it is true that
it's nearly impossible to quantify ALE, as there are
too many variables in the vulnerability/impact
scenarios.
I have seen several white papers and discussions
regarding the use of a hybrid model to demonstrate a
more objective snapshot of a company's risk posture.
Does anyone out there have any links to additional
discussions on the topic of hybrid risk analysis
models?
Regards
Valerie
--- Pete Herzog <lists@isecom.org> wrote:
> Rafael,
>
> Part of the problem is, as everyone else is telling
> you too, that
> traditional risk metrics in pen-tests cannot be
> true.
>
> We have updated this in OSSTMM 3.0. If you look at
> the RAV Spreadsheet
> in http://www.isecom.org/securitymetrics.shtml
> you'll see the changes.
> The OSSTMM has pulled out of RISK completely because
> it is so biased
> (which is why it regarded qualitative methods for
> engaging risks in the
> past).
>
> New metrics are quantification-based-- facts only
> from operations used
> to discern a score that stands as a foundation for
> any risk assessments
> one plans to do as it is itself only an indicator of
> current operations.
>
> While the amount of publicly available info on
> osstmm 3.0 and
> accompanying RAVs is sparse, the spreadsheet does go
> into good detail
> and many companies are already applying this model
> successfully. It
> allows them to compare security in operations
> between companies,
> industries, even departments and vectors within the
> same organization.
> The RAVs are flexible and therefore allow then all
> vectors to be summed
> together to provide a total for the whole
> organization.
>
> Sincerely,
> -pete.
>
>
> Michael Gargiullo wrote:
> > I agree with Marc completely.
> >
> > Only the company can give you those numbers. It's
> management's job to
> > determine what their assets are, and costs
> involved if they loose those
> > assets.
> >
> > You, as the Pen Tester, cannot determine what the
> value of a certain
> > machine or service is to the company.
> >
> > You can however, tell them what the low hanging
> fruit is, and take a
> > best guess as to what their "Crown Jewels" are.
> So you'd go for the SQL
> > server, and the Active Directory, and the Radius
> Server, etc...
> >
> > As for explaining difficulty, if you have in depth
> knowledge of how the
> > vulnerability works, and if an exploit is in the
> wild (proof of concepts
> > count), you can state explicitly "At this moment
> in time, this is
> > difficult to exploit, but that could change
> tomorrow". Remember,
> > Vulnerability scans and pen tests are a snapshot
> (A moment in time).
> > Networks change, some change yearly, some change
> monthly, and some
> > networks change hourly.
> >
> > -Mike
> >
> > -----Original Message-----
> > From: Marc Heuse [mailto:Marc.Heuse@nruns.com]
> > Sent: Tuesday, November 01, 2005 3:22 AM
> > To: 'RSMC'; pen-test@securityfocus.com
> > Subject: RE: Risk metrics
> >
> > Hi,
> >
> > if there would be standard metrics, they would
> have been in the guide
> > :-)
> >
> > to be serious: in risk management there are
> standard metrics.
> > the most used one is to determine Likelyhood and
> Impact of a risk.
> > These are then described as low/medium/high (or
> very low, low, medium,
> > high,
> > criticak; or ... well you get the picture). Or you
> put values in there,
> > e.g. liklyhood that it happens once a year is 20%,
> impact would be
> > $10k. This is then called Expected Anual Loss, or
> Anual Loss Expectancy.
> > And then there is CRAMM (british standard) which
> uses values from 1-10
> > for these.
> >
> > Basically it is very hard to use likelyhood and
> impact in a pentest
> > report.
> > Who can convince everyone that the liklyhood of
> exploition of a weak
> > password
> > is xx%? It just doesnt work. Then the impact - if
> you are not working
> > within
> > the company for whom you are performing the
> pentest, it is very, very
> > hard
> > to have an idea of the costs.
> >
> > So for pentesting - especially when providing
> pentest services - other
> > metrics are needed. But there are no standards for
> that.
> >>From my philosophy and experience there are just a
> few metrics helpful:
> > criticality of a vulnerability (metric like 1:
> unharmful information
> > gathering to 10: remote control of a complete
> network/infrastructure),
> > and level of exposure (e.g. 1: controlled keyboard
> access only,
> > 10: Internet connection without filtering).
> > Some customers also want to know the difficulty
> level to exploit or
> > knowledge level required by the attacker (e.g. 1:
> needs to be able
> > to move a mouse, 10: strong reverse engineering,
> assembler coding,
> > machine level knowledge on several platforms etc.
> required). But this
> > is a trap - if there is a tool or exploit which
> you dont know, or is
> > released some days/weeks later, the difficulty
> drops - but nobody will
> > update a table in a report in return.
> >
> > Cheers,
> > Marc
> >
> >
>
====================================================================
> > Marc Heuse
> > n.runs GmbH
> > Mobile Phone: +49-160-98925941
> > Key fingerprint = AE3F CDC0 8C7B 8797 BEAC 4BF8
> EC8F E64B 0A84 EA10
> >
>
====================================================================
> >
> > -----Original Message-----
> > From: RSMC [mailto:smcsoc@yahoo.es]
> > Sent: Montag, 31. Oktober 2005 14:57
> > To: pen-test@securityfocus.com
> > Subject: Risk metrics
> >
> > Hi,
> >
> > As OSSTMM states, "Reports must use only
> qualitative
> > metrics for gauging risks based on industry
> accepted
> > methods".
> > What metrics are more suitable to use in
> pen-testing
> > services?
> >
> > Thanks in advance,
> >
> > Rafael San Miguel Carrasco
> >
>
>
------------------------------------------------------------------------------
> Audit your website security with Acunetix Web
> Vulnerability Scanner:
>
> Hackers are concentrating their efforts on attacking
> applications on your
> website. Up to 75% of cyber attacks are launched on
> shopping carts, forms,
> login pages, dynamic content etc. Firewalls, SSL and
> locked-down servers are
> futile against web application hacking. Check your
> website for vulnerabilities
> to SQL injection, Cross site scripting and other web
> attacks before hackers do!
> Download Trial at:
>
> http://www.securityfocus.com/sponsor/pen-test_050831
>
=== message truncated ===
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
------------------------------------------------------------------------------
Audit your website security with Acunetix Web Vulnerability Scanner:
Hackers are concentrating their efforts on attacking applications on your
website. Up to 75% of cyber attacks are launched on shopping carts, forms,
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are
futile against web application hacking. Check your website for vulnerabilities
to SQL injection, Cross site scripting and other web attacks before hackers do!
Download Trial at:
http://www.securityfocus.com/sponsor/pen-test_050831
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:08 EDT