Mail from Ingo Struck re VulnXML and WAS

Forwarded from Ingo struck, a new member whose account is not yet active and one of the original VulnXML folks....welcome to WAS Ingo.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark / WAS-list,

I saw that you currently submitted the VulnXML dtd together with the old
sample test descriptions. However, the VulnXML dtd has changed in many
points since. It underwent some normalization (nodes to attributes whereever
possible / appropriate, removal of "dummy" nodes) and some repeatability flags
have changed. See attached the current VulnXML-1.4.dtd in two versions:
raw and (heavily) commented. They reflect the current status of the VulnXML
db application that I developed during the last year.

I totally agree with the analysis of the work phases and the WAS phases
outlined in the last (anonymous) message found on the WAS list:
a) problem classification / textual description (WAS classification scheme)
b) problem grading (WAS risk ranking)
c) detailed technical description how to detect the problem (VulnXML / WAS
    vulnerability description)

These phases clearly outline a priority list too:
- - create (and agree upon) a classification scheme
- - describe a risk ranking methodology
- - integrate a technical description

Based upon some experience with thesauri within another scope I would
like to add that the central point in creating a thesaurus is not the 
thesaurus itself, but a *well-defined process how to build it up*.
Thesauri / classification schemes tend to be highly dynamic and they are
"review-intensive". What we need here is a clear description of how a
single thesaurus entry should look like, how revision management should
be accomplished and what review processes are involved in building up
a sustainable classification scheme. Adding the concrete entries should
be a peer-based review and approval process. The definition of the 
classification scheme should be independent of XML (best accompanied
by a simple BNF notation), with XML as a "sample" serialization format.

The thesaurus should then contain some basic hints for the risk ranking
methodology, e.g. a score value linked to each specific classification
entry which could then be comprised in calculating an overall risk score.
The risk methodology should take into account all information gathered
during the classification and give clear rules how to derive a risk rating
from that.

Referring to Jeff's last mail / basic characteristics breakdown,
I would tend to say that the central point of the classification scheme
is to define / look up the "security" characteristics of a concrete 
vulnerability and to provide appropriate "remedy" characteristics,
while the "basic" and "test" characteristics are part of the last
(technical) stage.

Thus I would reorder and assign Jeff's characteristics as follows:

- - classification: "security", "remedy"
- - risk ranking: -
- - technical description: "basic", "test"

While the "exploit" part is clearly out of the scope of a schematical 
description due to its algorithmic nature (like Jeff already stated) and 
should be provided as "additional info" only.

If you have a look at the current VulnXML dtd, you will see that it
already contains a rather detailed description for the "technical" part
(Jeff's, "basic" and "test") while being quite sketchy for the classification
part. That said, the VulnXML could only be a startover for the "last"
stage of the overall WAS deliverable suite, while the "interesting" part
of classification / description still needs to be worked out from scratch
or based upon other sources (like the paper Jeff mentioned).

Kind regards

Ingo Struck
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE/VG0GhQivkhmqPSQRAmONAJ9qiGM0Mh6Ki/gyM1k9NW8ilQ8hewCfQUio
VaeIromCjvFzu3gJlPBUfOQ=
=t/xW
-----END PGP SIGNATURE-----