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.
This topic (or one very similar) has come up before. Please see the
thread including this email:
> 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
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
> --) Configuration needed for successful exploitation (default or
> --) 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
> 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,
> --) 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
> 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
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?
Jacques A Vidrine / NTT/Verio
firstname.lastname@example.org / email@example.com / nectar@FreeBSD.org