Date: Tue, 22 Feb 2005 14:26:11 -0600 From: Jacques Vidrine <nectar@FreeBSD.org> To: cykyc@yahoo.com Cc: freebsd-vuxml@freebsd.org Subject: Re: Adding Additional Attributes to VuXML Message-ID: <421B9563.9090201@FreeBSD.org> In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com> References: <20050221160356.61989.qmail@web50302.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?421B9563.9090201>