FW: [avdl] Groups - Minutes 02-12-04.txt uploaded

Peter,

I'd like to thank you for your interest in AVDL and I appreciate your time and effort you have devoted to this review. While indeed your message arrived after the commenting period, the committee nevertheless has given it a full consideration at yesterday’s meeting.

Please see below the specific responses to your points.

Sincerely,

Jan Bialkowski

VP & CTO

NetContinuum, Inc.

1705 Wyatt Drive

Santa Clara, CA 95054

ph. 408.961.5600

http://www.netcontinuum.com

> -----Original Message-----

> From: Peter Michalek [mailto:peter@fortifysoftware.com]

> Sent: Thursday, March 11, 2004 11:04 AM

> To: kheineman@spidynamics.com; avdl@lists.oasis-open.org

> Subject: RE: [avdl] Groups - Minutes 02-12-04.txt uploaded

> Hi folks,

> Here are some questions and suggestions on the draft. This may be late in

> the approval process for this version, but perhaps may help with the next

> version of the schema.

> Questions and suggestions on AVDL schema draft:

> - the schema seems too complex: 2000 lines of definition, compare to 100

> lines of vulnxml dtd

> (which expands to several hundred lines for an XSD schema)

[jb: ] Yes, the schema has certain volume that we felt could not be made much shorter. Our primary mission of delivering a complete and comprehensive standard specification must have taken precedence over brevity of the schema. Surely DTD specifications in general are significantly shorter than XML schemas but they do suffer from lack of detail, strong typing, convenient documentation, OO modeling, and many other significant features, as you surely already know. For that reasons, overwhelming majority of modern standards in development today prefers to use that methodology. Finally, while I am sure original vulnxml specification served well purposes of its designers, AVDL cannot be directly compared with it as its objectives, scope, and purpose are all very different from vulnxml.

> - traversal-step

> should contain Method (e.g.POST/GET). That way, in some situations,

> the request tag doesn't need to be supplied

[jb: ]We felt strongly that conceptual simplification via reduction of number of types aids adoption of the standard and vastly reduces developers’ effort. For that we have chosen to leverage, whenever possible, similar constructs. Certainly, under certain circumstances some markup could be relocated into other containers to reduce resulting document size. We will consider such optimizations in a future revision of the specification as a backward-compatible option.

> - why is there both id and sequence number in traversal step? isn't

> sequence-number sufficient?

> id="step0001" time-stamp="29.3050" sequence-number="00001"

[jb: ] In the above context the “id” and the “sequence-number” serves distinct and different purposes. The “id” supplies a unique identification of the probe for reference purposes. The “sequence-number” gives information about logical progression of the traversal process where the site’s responses may depend on the history of the interaction. Additionally, the “id” field if present in several other constructs carrying the same meaning (and syntax) in every of those cases. The “sequence-number” appears only in this narrow context which alone is an indication of conceptual difference. The two cannot be reduced to one and the same.

> - what exactly is parent-ref?

> A reference to the direct parent of this step.?: does that mean

> traversal-steps can be nested?

[jb: ] In the above context the “parent-ref” is a reference to a traversal step that yielded the link to the current traversal step and basically answers the question “where did I come from?”. In this sense, a traversal step can and often will have several generations of ancestors. The “parent-ref” does not mean encapsulating container and thus there is no data-structure level recursion.

> - raw and parsed constitute a redundancy that may not be necessary:

> it makes implementation more complicated and storage larger.

> Wouldn't it be better to provide "raw fragments" so that only things

> that

> can't be expressed in parsed form are provided in raw form?

[jb: ] In the above context the “parsed” and “raw” forms are often mutually redundant and for that reason one of them has been made optional addressing your storage size concern. Certain attacks rely on malformed headers and protocol violations which cannot be presented in the “parsed” form. For that reason, a practically comprehensive security product will have to implemented means of operating on the “raw” form and once that is available, the “parsed” form will always be derivable from it and it is that “parsed” form that is made optional for the convenience of simpler devices that cannot comprehend HTTP.

> - it might be better to use CDATA for raw form rather than xml tags

[jb: ]Since no member of AVDL TC is aware of CDATA construct in XML schema we have assumed that you are referring to DTD element. Indeed we have neglected to consider mixing xsd and dtd paradigms but now that you have raised the point we feel that such approach would force implementers to consider XML schema parsing rules and additionally DTD syntax which increases effort and footprint of the resulting system.

> - what's going to be a typical size of the traversal? What have we learned

> from implementations so far?

> Do we need to optimize, by e.g. not duplicating raw and parsed form (see

> above)

[jb: ]Current experience with practical interoperable implementations leads us to believe that the traversal size primarily depends on the web site being traversed but indeed the duplication you mention does increase the size and for that it has already been made optional. We believe, however, that there is further room of optimizations as mentioned above.

> - user-description-type is never referenced, seems to be redundant in the

> schema

[jb: ] Yes, indeed this element as well as several dozens of others are “terminal” leaves of inheritance chains and are not referenced in the XML schema itself. They are specified for the user to use in the AVDL document. This particular element is intended for “free form” descriptions of security actions that might be considered outside of the realm of AVDL document processing, such as configuration changes to some 3^rd party systems, or “best practice advice”.

> - vulnerability-description exists on vulnerability-probe only.

> Perhaps there should be description available also in traversal part of

> schema

[jb: ]The “vulnerability-description” contains “catalog” or “signature” data referenced by a “vulnerability-probe” when such vulnerability is detected. Most certainly, certain vulnerabilities will be discovered during a site traversal. In such case, a “traversal-step” is reporting the site structure and a separate “vulnerability probe” reports the vulnerability. We have decided to separate those two since their usage have different meanings. As you surely must be aware, certain “traversal-steps” of some real applications may have several vulnerabilities. Each such vulnerability is reported by a separate “probe”. Merging the meanings of the “traversal-step” and “vulnerability-probe” would further complicate structures making usage of the standard ambiguous and the implementations unnecessarily burdened with redundant options.

> ~ Peter Michalek

> Fortify Software

> -----Original Message-----

> From: kheineman@spidynamics.com [mailto:kheineman@spidynamics.com]

> Sent: Friday, February 13, 2004 12:19 PM

> To: avdl@lists.oasis-open.org

> Subject: [avdl] Groups - Minutes 02-12-04.txt uploaded

> The document Minutes 02-12-04.txt has been submitted by Kevin Heineman

> (kheineman@spidynamics.com) to the OASIS Application Vulnerability

> Description Language TC document repository.

> Document Description:

> Download Document:

> http://www.oasis-

> open.org/apps/org/workgroup/avdl/download.php/5477/Minutes%

> 2002-12-04.txt

> View Document Details:

> http://www.oasis-

> open.org/apps/org/workgroup/avdl/document.php?document_id=5

> 477

> PLEASE NOTE: If the above links do not work for you, your email

> application

> may be breaking the link into two pieces. You may be able to copy and

> paste

> the entire link address into the address field of your web browser.

> 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/avdl/members/leave_workgroup.ph

> p.

> 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/avdl/members/leave_workgroup.php.

avdl message