On 2/21/05 10:03 AM, Jon Passki wrote:
> Hello All,
>
> I would like to discuss risk attributes and see if they should be
> included in VuXML as some new optional elements.
Hi Jon,
This topic (or one very similar) has come up before. Please see the
thread including this email:
http://lists.freebsd.org/pipermail/freebsd-vuxml/2004-August/000036.html.
> What I would like
> to see are possibly two new elements added that describe the
> likelihood of the vulnerability and what the vulnerability
> produces. Neither of these elements would try to directly
> communicate the impact of the risk (which is site-specific), rather
> certain attributes that can objectively described the
> vulnerability. Also, this is not a taxonomy, although it may start
> to resemble one. It's to provide consistent information across
> vulnerabilities.
I agree that risk cannot be assigned objectively. This results in some
funny things from people who try to do so, such as Secunia's rating
system: all ratings include the word critical, from "less critical"
through "extremely critical". (^_^)
> When I think of likelihood, I think of some of the following
> examples:
>
> --) Configuration needed for successful exploitation (default or
> non-default)
> --) Needed Account Access (non-anonymous, anonymous, none)
> --) Location of Exploitation (can be performed remotely, needs to
> be local)
>
Your meaning is clear enough here. What would be the purpose of
including optional elements for these? (Concrete examples, please.)
Frankly, if the existing narrative text (<description>) for an entry
does not address these points at least implicitly, then the text needs
revision.
> When I think of the production of the vulnerability, I think of
> some of the following examples:
>
> --) Network information (host names, IP addresses, MAC addresses,
> etc.)
> --) Account information (account name, individual account password,
> credential reuse, privileged account access, etc.)
> --) System/Service Information (directory names, file names,
> configuration information, recursive resource usage, etc.)
>
I don't think I understand ``the production of the vulnerability'', or
these points.
> What I'm asking is if it makes sense to add these two _optional_
> elements (or perhaps similar concepts). If it does, then I'd like
> to start a discussion on the exact content (one bikeshed at a
> time...).
Content by example is good, even very early on.
General questions that should be answered for changing the content model
by adding new items:
How would these items by used? By whom or what?
Who would provide the information? If it is optional, what would be the
consequence of 99% of entries not containing the item?
Why shouldn't these items be in an adjunct document, at least initially
until the value is proven?
Cheers,
--
Jacques A Vidrine / NTT/Verio
nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org