RE: [was] Agenda for Thursday 25th

["Dawes, Rogan (ZA - Johannesburg)" <rdawes@deloitte.co.za>]

Hi Mark,

I was thinking that consumers could follow the work of Jeremiah Grossman
with his web server fingerprinting program. (I can't remember the name,
though). We may not really have to specify the processor architecture. I
guess that we could follow a "we know the version has problems, recommend an
upgrade even the problems are not directly applicable to this arch"
approach.

Rogan

> -----Original Message-----
> From: Mark Curphey [mailto:mark@curphey.com] 
> Sent: 25 September 2003 04:57 PM
> To: was@lists.oasis-open.org
> Subject: Re: [was] Agenda for Thursday 25th
> 
> 
> Thanks Ingo. This sounds like a great plan. I will take care 
> of the items listed below in the initial draft. 
> 
> The idea of also writing a Java executor sounds like a good 
> one. I guess there is no substituition of understanding what 
> is lacking than to do it for real. I suggest we spend todays 
> meeting time discussing how we can achieve this and the mechanics. 
> 
> On the editor: Ignore my comments, I keep forgetting we 
> already have it done.
> 
> Of the initial draft, I will add in the 'applicableTo" 
> element (note the naming convention!). I guess one of the 
> questions / concerns I have is how this would work in 
> practice. This assumes that a tool has already been able to 
> accuratley determine the "applicableTo" criteria ie identify 
> its an Intel architecture would be hard even if it is IIS.
> 
> I got a little side-tracked with some personal things this 
> week so haven't yet completed the thesaurus and riskRanking 
> work. It will be done before the weekend is out.
> 
> ----- Original Message ----- 
> From: "Ingo Struck" <ingo@ingostruck.de>
> To: "Dawes, Rogan (ZA - Johannesburg)" 
> <rdawes@deloitte.co.za>; <mark@curphey.com>; 
> <was@lists.oasis-open.org>
> Sent: Thursday, September 25, 2003 4:36 AM
> Subject: Re: [was] Agenda for Thursday 25th
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Folks, 
> 
> I will try to participate today - let's see if it works overseas. ;o)
> Sorry for my silence during the last weeks, but we are currently
> setting up a very gainful project right now, that will last 
> till December.
> 
> Some annotations regarding the "draft"
> - - naming: please remove all non-alpha chars from the names.
>   names containing blanks or other special characters are 
> always problematic
>   during data processing (normalization etc. pp.)
>   "VulnDB's" or "Risk Ranking" are not acceptable
> - - naming: please hold on to a strict naming convention, lets say
>   all lowercase or java convention (starting with a lowercase char),
>   e.g. "Risk Ranking" -> "riskRanking"
> - - Remedy group: I don't think that a "Patch" is sufficient 
> here. Most often
>   the remedy does not consist of a simple patch, but of an abstract
>   instruction. Thus the remedy should contain a textual 
> description too.
> - - ApplicableTo left out: I guess this is *the* criterion 
> one would like to
>   search for. The default scenario for me is: "I have got app 
> server x and
>   web server y on platform z, so what issues are known for that?"
>   Everything else is only a refinement (e.g. "only those of 
> the last month",
>   "only the GPLd ones", etc.)
>   So the applicableTo thing is a central point for retrieval.
>   BTW the ApplicableTo as found in the current VulnXML DTD is one of
>   the most over-worked things there: the cardinality and 
> structure of the
>   parts should be exactly what we need, so we could just 
> adopt that part.
> - - data entry stuff: I still dont understand why we should 
> write yet another
>   "skunkwork" editor to perform data entry based upon xml:schema while
>   having a completely functional DTD based editor online that could be
>   easily adapted.
> 
> As for the extension of the VulnXML execution logic:
> I think it would be better to write a working executor based upon
> what we have now as a proof-of-concept (the python based stuff
> is rather outdated and I dont know, if someone is willing to adapt it)
> before thinking of extensions. 
> 
> Let's discuss the the minutiae later on. :o)
> 
> Kind regards
> 
> Ingo
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (GNU/Linux)
> 
> iD8DBQE/cqkkhQivkhmqPSQRAnKEAKDMk0h8XCWwL3CKr/C9HZPd/yRFwACgpcs8
> /gaQ2BP2Su54u+3yIjZmI68=
> =wxw4
> -----END PGP SIGNATURE-----
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/was/members/leave
_workgroup.php.


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php
.

Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer") that must be accessed and read by clicking here or by copying and pasting the following address into your Internet browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre@Deloitte.co.za.