> 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
> 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