From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 20:26:14 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D7A016A4CE for ; Tue, 22 Feb 2005 20:26:14 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4739443D1D for ; Tue, 22 Feb 2005 20:26:13 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id AF44B3E2C45; Tue, 22 Feb 2005 14:26:12 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id CFBAB600542; Tue, 22 Feb 2005 14:26:11 -0600 (CST) Message-ID: <421B9563.9090201@FreeBSD.org> Date: Tue, 22 Feb 2005 14:26:11 -0600 From: Jacques Vidrine Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cykyc@yahoo.com References: <20050221160356.61989.qmail@web50302.mail.yahoo.com> In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-vuxml@freebsd.org Subject: Re: Adding Additional Attributes to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:26:14 -0000 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 () 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