RE: [was] Agenda for Thursday 25th

[Mark Curphey <mark@curphey.com>]

That makes sense. 

I think this seems like another one of those things that if we design this correctly these sort of things could be implemented as a function of some kind. Things like authenticate, create session or determine the platform would all be good candidates at first glance. 

IMHO the strategy for WAS should be to show how this would work and maybe build reference implementations, but abstract it in such a way that other tools can provide that functionality themselves and not force it to be needed. Seem sensible ?

Rogan / Ingo – What do you think would be a reasonable timeframe for building the executor so we can start discussing extensions to the current VulnXML ?




---- "Dawes, Rogan (ZA - Johannesburg)" <rdawes@deloitte.co.za> wrote:
> 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.
> 
> 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.
> 
> 
>