Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Nessus>
  3. devel
Risk...
arboi at noos
Aug 25, 2002, 3:27 AM
Post #1 of 8 (1080 views)
Permalink
The notion of "risk" in the Nessus report has never been formalized.
One can find "Critical", "High", "Serious", "Medium", "Low", "None",
and miscellaneous comments. AFAIK, nobody really knows if "serious" is
worse than "critical" or "high".

1. If we keep the current system, we should at least define a precise
scale, or even replace it with a grade.

But some people will give more importance to the disponibility of their
service (e.g. ISP with peering or QoS agreements), others will
consider the confidentiality of their data as vital (e.g. army)

2. Maybe we could add a "security objective", e.g. taken from "DICP"
= disponibility, integrity, confidentiality, proof / imputability
(= authentication & logs).
[.I'm not sure that "DICP" is international. French bankers love it]


So we might say, e.g. for a denial of service where the source address
of the packets can be spoofed "Risk: D5 P4", or for a buffer overflow
that allows full root control of the machine "Risk: 5" (no need to add
an objective, everything is concerned)

However, I don't think that's great, because
i. "D1 I0 C5 P4" is not simple, most people will prefer a simple
grade.
ii. Only the consequence of the attack appears in the grade, not the
probability / ease.
iii. Environments are differents and what looks critical here will be
only medium there.
I'm afraid that we'll never be able to solve this point, though.

3. So I thought that the "risk" could be computed from several factors
and user-defined tables / functions.

First, consequences, maybe related to the security objectives?!
- access to "restricted" information (e.g. webroot)
- potential access to a few files
- potential access to sensitive user files
- potential access to any files
etc.
Note that attack against integrity of system data may lead to
disponibility, confidentiality or proof problems; attacks against
confidentiality of system data may create proof problems...
So most people just want to know if their machine can be compromised
or not.
An overall "consequence" mark could be computed with just a mean of
the DICP marks.
e.g. somebody give more weight to confidentiality, others to
integrity...

Second, ease of attack:
- immediate (e.g. just use a browser)
- working exploit "in the wild"
- buggy exploit released, has to be fixed
- technical details known, no exploit released
- technical details unknown, but confirmed by "serious people".
- theoretical

A table would give the final mark. The idea is that "risk" is not
"linear". An theoretical attack that have the worst consequences is
usually considered as much more dangerous than a very easy attack that
has only small consequences.
To avoid brain damaged questions, maybe this table should be hard
coded in Nessus.

Is this a brain damaged idea?

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/
Risk... [ In reply to ]
arboi at noos
Aug 25, 2002, 3:27 AM
Post #2 of 8 (1058 views)
Permalink
The notion of "risk" in the Nessus report has never been formalized.
One can find "Critical", "High", "Serious", "Medium", "Low", "None",
and miscellaneous comments. AFAIK, nobody really knows if "serious" is
worse than "critical" or "high".

1. If we keep the current system, we should at least define a precise
scale, or even replace it with a grade.

But some people will give more importance to the disponibility of their
service (e.g. ISP with peering or QoS agreements), others will
consider the confidentiality of their data as vital (e.g. army)

2. Maybe we could add a "security objective", e.g. taken from "DICP"
= disponibility, integrity, confidentiality, proof / imputability
(= authentication & logs).
[.I'm not sure that "DICP" is international. French bankers love it]


So we might say, e.g. for a denial of service where the source address
of the packets can be spoofed "Risk: D5 P4", or for a buffer overflow
that allows full root control of the machine "Risk: 5" (no need to add
an objective, everything is concerned)

However, I don't think that's great, because
i. "D1 I0 C5 P4" is not simple, most people will prefer a simple
grade.
ii. Only the consequence of the attack appears in the grade, not the
probability / ease.
iii. Environments are differents and what looks critical here will be
only medium there.
I'm afraid that we'll never be able to solve this point, though.

3. So I thought that the "risk" could be computed from several factors
and user-defined tables / functions.

First, consequences, maybe related to the security objectives?!
- access to "restricted" information (e.g. webroot)
- potential access to a few files
- potential access to sensitive user files
- potential access to any files
etc.
Note that attack against integrity of system data may lead to
disponibility, confidentiality or proof problems; attacks against
confidentiality of system data may create proof problems...
So most people just want to know if their machine can be compromised
or not.
An overall "consequence" mark could be computed with just a mean of
the DICP marks.
e.g. somebody give more weight to confidentiality, others to
integrity...

Second, ease of attack:
- immediate (e.g. just use a browser)
- working exploit "in the wild"
- buggy exploit released, has to be fixed
- technical details known, no exploit released
- technical details unknown, but confirmed by "serious people".
- theoretical

A table would give the final mark. The idea is that "risk" is not
"linear". An theoretical attack that have the worst consequences is
usually considered as much more dangerous than a very easy attack that
has only small consequences.
To avoid brain damaged questions, maybe this table should be hard
coded in Nessus.

Is this a brain damaged idea?

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/
Re: Risk... [ In reply to ]
sullo at cirt
Aug 25, 2002, 6:00 AM
Post #3 of 8 (1059 views)
Permalink
> The notion of "risk" in the Nessus report has never been
formalized.

I agree that the words used within Nessus to describe risk should
be standardized, but I would be afraid that having a matrix as
described would be too complicated to use effectively (by either a
plugin writer or an end user). Ease-of exploitation can change in a
second when someone posts a program to Bugtraq, which
requires someone to go back and re-rate a plugin on an on-going
basis.

The OSVDB (osvdb.org) is, I think, going to use a two-level system:
critical and non-critical. The criteria for a vulnerability to be critical
are not entirely worked out, but it will be a well defined set of items.
Any of the following could make a vul critcal:
- remote file access (any type)
- denial of service
- privilege escalation
- etc

Everything else is non-critical (information disclosure, XSS, etc).

The simplicity of the rating scale makes it easy grade something,
it does not rely on ease-of exploit, and it does not matter how the
vul is effected by a user's environment.

This also prepares for the possibility that, someday, Nessus *
could* pull the risk ratings from OSVDB directly as plugins are
distributed (as items will have references to Nessus script IDs).

IMHO...

-Sullo

___________________________________________________
http://www.cirt.net/
Home of Nikto
Re: Risk... [ In reply to ]
arboi at noos
Aug 25, 2002, 6:13 AM
Post #4 of 8 (1060 views)
Permalink
"sullo" <sullo@cirt.net> writes:

> I agree that the words used within Nessus to describe risk should
> be standardized, but I would be afraid that having a matrix as
> described would be too complicated to use effectively

OK, let's say it will be hard coded into the tool.
But would a two axis score (risk / ease of attack) be too complex?
(you may answer "yes", I have many brain-damaged ideas currently :)

> The OSVDB (osvdb.org) is, I think, going to use a two-level system:
> critical and non-critical.

Mmmhhh... Much simpler than the current situation, but a little too
simple maybe?
Anyway, that's a good thing they chose an even number of marks. With
odd numbers, everybody chooses the middle mark!

Note: we definitely need "None" for information gathering plugins.
Re: Risk... [ In reply to ]
hdm at digitaloffense
Aug 25, 2002, 11:01 AM
Post #5 of 8 (1056 views)
Permalink
On Sunday 25 August 2002 08:13, Michel Arboi wrote:
> "sullo" <sullo@cirt.net> writes:
> > I agree that the words used within Nessus to describe risk should
> > be standardized, but I would be afraid that having a matrix as
> > described would be too complicated to use effectively
>
> OK, let's say it will be hard coded into the tool.
> But would a two axis score (risk / ease of attack) be too complex?
> (you may answer "yes", I have many brain-damaged ideas currently :)

The OSVDB project also has support for scoring and weights, just those
fields are currently not mandatory. Nessus could suck down a fresh copy
of the database and then use their own scoring tables to generate risk
levels (or just about anything else they want to with the data).

-HD
RE: Risk... [ In reply to ]
victor at opticom
Aug 26, 2002, 12:19 AM
Post #6 of 8 (1059 views)
Permalink
> 3. So I thought that the "risk" could be computed from several factors
> and user-defined tables / functions.
>
> First, consequences, maybe related to the security objectives?!
> - access to "restricted" information (e.g. webroot)
> - potential access to a few files
> - potential access to sensitive user files
> - potential access to any files
> etc.
> Note that attack against integrity of system data may lead to
> disponibility, confidentiality or proof problems; attacks against
> confidentiality of system data may create proof problems...
> So most people just want to know if their machine can be compromised
> or not.
> An overall "consequence" mark could be computed with just a mean of
> the DICP marks.
> e.g. somebody give more weight to confidentiality, others to
> integrity...
>
> Second, ease of attack:
> - immediate (e.g. just use a browser)
> - working exploit "in the wild"
> - buggy exploit released, has to be fixed
> - technical details known, no exploit released
> - technical details unknown, but confirmed by "serious people".
> - theoretical
>
> A table would give the final mark. The idea is that "risk" is not
> "linear". An theoretical attack that have the worst consequences is
> usually considered as much more dangerous than a very easy attack that
> has only small consequences.
> To avoid brain damaged questions, maybe this table should be hard
> coded in Nessus.

I don't think that this table should be hard coded, at least there should be
possibility to change it. I imagine this as following: assign a weight (for
example, from 0 to 10) to marks on both axis. Te final mark will be computed
by multiplying these two weights, so final risk factor will have value from
0 to 100. Nessus should have some pre-selected weights for all marks, but
user have to have possibility to change the weights - it will allow the user
to put his own priorities on different kinds of attacks: for example, ISP
can give more priority to DoS attacks with working exploits widely
available, and less - to theoretically possible attacks which leads to file
access.

Best regards,
Victor
Re: Risk... [ In reply to ]
peak at argo
Aug 29, 2002, 3:48 PM
Post #7 of 8 (1059 views)
Permalink
On 25 Aug 2002, Michel Arboi wrote:

> The notion of "risk" in the Nessus report has never been formalized.
[...]
> 1. If we keep the current system, we should at least define a precise
> scale, or even replace it with a grade.

IMHO, the risk level, as shown by Nessus, should help people to say "jeez,
this looks bad, I ought to check this manually right now" and "well, this
can probably wait until these twenty critical vulns are looked at". It
should not try to substitute for a real risk assessment.

I think there should be 3-4 levels. Perhaps something like

Low minimal risk, might provide information useful
to the attacker (e.g. path disclosures)
Medium some security mechanisms can be circumvented
(e.g. open proxy, open relaying)
High full control over some unprivileged account on
the target system (e.g. IIS unicode bug),
DoS of a single service
Critical maximum risk, full control over the target system
(e.g. vulns in privileged daemons),
complete system DoS

> 2. Maybe we could add a "security objective", e.g. taken from "DICP"
> = disponibility, integrity, confidentiality, proof / imputability
> (= authentication & logs).
> [.I'm not sure that "DICP" is international. French bankers love it]

I have seen CIA = Confidentiality, Integrity, Availability. Nice
abbreviation, isn't it? :) (But an objective corresponding to "P" in
"DICP" (accountability?) is missing.)

I am afraid the result would be too complicated both for the users (to
understand it) and to the developers (to provide meaningful data). I
think it would be sufficient to add some kind of category to the risk
level--either the actual set of threatened security objectives or one of
predefined subsets (after all, there are only several meaningful
combinations):

Data disclosure threat to confidentiality
Data corruption thread to integrity (and availability)
Denial of service thread to availability
Full access threat to all objectives
etc.

without assigning individual risk level to every single objective.
Again,

> 3. So I thought that the "risk" could be computed from several factors
> and user-defined tables / functions.

If it was so easy, people would not pay big bucks for CRAMM. ;)

> Second, ease of attack:
> - immediate (e.g. just use a browser)
> - working exploit "in the wild"
> - buggy exploit released, has to be fixed
> - technical details known, no exploit released
> - technical details unknown, but confirmed by "serious people".
> - theoretical

Well, are your going to update scripts every time a new exploit is
released?


--Pavel Kankovsky aka Peak
"Welcome to the Czech Republic. Bring your own lifeboats."
RE: Risk... [ In reply to ]
John.Benninghoff at Rbcdain
Sep 6, 2002, 2:42 PM
Post #8 of 8 (1057 views)
Permalink
-----Original Message-----
> From: Michel Arboi [mailto:arboi@noos.fr]
> Sent: Sunday, August 25, 2002 8:13 AM
> To: nessus-devel@list.nessus.org
> Subject: Re: Risk...
>
>
> "sullo" <sullo@cirt.net> writes:
>
> > I agree that the words used within Nessus to describe risk should
> > be standardized, but I would be afraid that having a matrix as
> > described would be too complicated to use effectively
>
> OK, let's say it will be hard coded into the tool.
> But would a two axis score (risk / ease of attack) be too complex?
> (you may answer "yes", I have many brain-damaged ideas currently :)

I'll jump in here (late) and say that I really _like_ having the risk
score as simple as possible. I don't think a two axis score would really
help standardize the risk, as risk assesment is fairly subjective and
will often be different for different sites.

>
> > The OSVDB (osvdb.org) is, I think, going to use a two-level system:
> > critical and non-critical.
>
> Mmmhhh... Much simpler than the current situation, but a little too
> simple maybe?
> Anyway, that's a good thing they chose an even number of marks. With
> odd numbers, everybody chooses the middle mark!
>
> Note: we definitely need "None" for information gathering plugins.

This sounds like a 3 level system, which is what nessus has now:
security_note, security_warning, security_hole. For my site, I also use
3 levels of risk: informational, recommended fix, and required fix. This
works well with nessus, because I assign the risk level to each item by
altering the .nasl code to fit with our policies & requirements.

Perhaps this suggests standardizing on 3 levels and adding a "custom risk"
feature: the 3 generic levels of informational, "low" risk, and "high" risk
can be used as a starting point, (and assigned by the plugin author) but
nessus will let you override the risk level if, for example, a "high" risk
item is only a "low" risk item at your site.

Would this be helpful ?

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal