Adding Additional Attributes to VuXML

[Jacques Vidrine]

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 at celabo.org / jvidrine at verio.net / nectar at FreeBSD.org