Subject: Re: [mile] Comments for the IODEF-extension to support structured cybersecurity information

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 12 Sep 2011 19:23:52 +0900

Hi Paul and all,

Thank you for your kind comments. I really appreciate that.

> - Some of the sections specify the inclusion of embedded XML as an
> ML_STRING (4.2, 4.4, 4.6, 4.7). This may add a lot of burden to validation
> and processing of the IODEF instance document. Processors will essentially
> have to extract the ML_STRING and treat it as a separate XML instance
> document (adhering to the schema resolved from IANA registry); this will
> require a separate validating parse as well as additional resources to
> process than it would if it were just a part of the containing IODEF
> instance.
>
> Instead of the ML_STRING, would it be better to somehow specify the schema
> element that should be used when capturing data associating with a
> specific specification? If actual XML is used instead of the ML_STRING,
> than the entire document can be validated/processed in the same parse. One
> way to do this while maintaining the decoupled nature provided by the
> ML_STRING would be to make the "Record" element an xsd:any tag, and
> provide guidance that the element used in place of the xsd:any tag (in an
> instance document) must match the root namespace element specified in the
> IANA
> registry of the specification. This will allow for a single instance
> document, instead of an instance document with many ML_STRINGS that must
> be converted/interpreted separately.

Thank you for the explanation.
I was sticking to ML_STRING since some of the future specification could be
non-XML.
But after reading emails from you and David repeatedly, I changed my mind,
and I think this IODEF-extension should focus on embedding XML-based
specification only.
So, I defined a new data type "EM_XML" for embedded complete XML document,
and use this data type for Record elements.
I hope this corresponds to the concern.

> - It seems that some of the context required to successfully interpret the
> data is missing in the current approach. The current structure of
> inclusion treats the IODEF document as a bag into which these additional
> structured objects are included (e.g., Vulnerability, Weakness, Scoring,
> EventRecord, AttackPattern). However, the relationships between these
> objects, within the context of the larger incident, is missing. For
> example, I have no way of knowing that a specific CVSS score (Scoring
> element as defined in section 4.1) relates to a specific CVE
> (Vulnerability element as defined in section 4.3), as found on a specific
> platform (PlatformId element as defined in section 4.5). There are many
> different permutations of this example, but the main issue is that the
> relationships between these atomic objects are not captured in the
> document; we say they were involved in the incident, but no specific
> details describing that involvement.
>
> One way of capturing these relationships may be to use the more
> aggregate-data models to describe them. For example, if a detailed
> vulnerability data model is used in the Vulnerability section, then that
> data model will provide the relationships between the CVE, the CVSS score
> of the CVE, and the CPEs associated with it. In this case there would be
> no need to provide additional data in the Scoring and PlatformId elements,
> unless it is provided to ease the parsing burden if that is the only thing
> a client is looking for. More guidance is needed to show how these
> relationships should be resolved and interpreted within the context of the
> larger incident.

Thank you for the comment.
PlatformID and Scoring were added under the Vulnerability and Weakness
classes.
I also added PlatformID under the AttackPattern class.
To clarify the relationships among them, the number of Record within each
Attackpattern, Vulnerability, and Weakness is limited to one at maximum.
(i.e., if someone wants to insert multiple CVE entries, then he needs to use
multiple Vulnerability elements, each of which contains single CVE entry.)
On the other hand, I still kept PlatformID element under System since the ID
is still useful for describing iodef:Flow information.

> - To decrease the size of the IODEF document, many of the embedded
> "Records", that are currently ML_STRINGs (but could also be XML elements)
> could be included using a reference to some authoritative repository that
> stores the data. Under the existing approach, a single IODEF instance
> document will be mixing content across logical levels: the instance data
> associated with the actual incident, and the reference data describing
> components involved in the incident. The reference data could easily be
> included by providing a tuple of the 1) identifier of the object and 2)
> a reference to one or more authoritative repositories from which to
> retrieve the metadata
> about the object this identifier represents. We may also need to provide
> guidance on how to retrieve data from specific repositories.
>
> The embedding model can still be allowed (especially in environments that
> can't reach out to external resources), but including a referential model
> would be useful for those environments that can make use of it.

Yes, I agree.
To cope with that, I prepared "reference" element under AttackPattern,
Vulnerability, Weakness, EventReport, and Remediation classes, and noted
either the Record or the reference need to be included.

But I am not sure whether this is the best way to achieve this.
Another candidate way to handle this is adding one value to the ENUM list of
SpecificationName.
For instance, SpecificationName values of Vulnerability could be cve, cvrf,
"link", or others.
When "link" is used for SpecificationName, a link is described in the Record
element, though the Record element should be a valid XML document to pass
the XML validations.

Could I hear your comments on this?

> - Would it be desirable to add in a greater degree of de-coupling into
> this spec to make it more "future-proof"? Some of the specs listed are not
> yet final, and those that are may not always be in favor. It may be
> possible to extend the IANA registry model so that we have a registry that
> is keyed off the IODEF object type (e.g., Vulnerability, Scoring,
> AttackPattern, ...), and for each type lists the specifications that
> should/may be used to express this data and the specific guidance on how
> each spec should be used. May be a good idea (or something like this) if
> we desire this level of modularity.
>

Yes, I agree. I think this is the point David also raised.
I've heard there is an IANA desk available at the IETF conference site.
Since I am a bit confused on the IANA issues, I will go there and ask the
IANA experts what would be the appropriate way to proceed this issue
further.
My intention is also the same, I would like to make the document
futureproof, and for that I would like to have a pool of namespace list that
is extensible.

> 4.1 - Scoring : Incident.Assessment.AdditionalData.Scoring:
>
> - See high-level comment, but it is unclear what each atomic "score" is
> actually scoring. No context provided as far as how the score relates to
> some other object contained in the IODEF instance document and it does not
> seem like it is a score for the overall incident.

I believe this is the issue related to your above comments on information
structure.
I've changed the structure, thus this issue is consequently solved, I hope.

> - Spec says Score attribute must be "zero or one", but since a CVSS score
> would fall somewhere between that range (assuming it was divided by 10) it
> will not normally be either zero or one. It may also help to include
> requirements relating to the decimal precision point of the "score".
> - Some scoring systems provide a parameter string
> (AV:N/AC:L/Au:N/C:P/I:N/A:N) that is useful in certain situations, where
> would this go?
> - How to reflect the fact that a particular score value did (or did not)
> reflect environmental or temporal metrics?
> - These same type of ambiguities likely exist for CWSS as well. It may be
> a good idea to provide more granular guidance on how to handle these
> things and possibly providing a "processing-instruction" element that will
> contain text with instructions on processing scores from specifications
> where there is no guidance provided in the spec (i.e., the "other" scoring
> specs). This "processing-instruction" concept may help in every section in
> 4.x.

I agree the concern you raised above.
Well, my intention is that this extension document should not define how to
describe CVSS/CWSS scores (and their elements) in XML format.
(I mean, this document should not define the XML schema for describing these
information in XML.)
I would rather like to see that this extension document references an
external XML schema for describe these CVSS/CWSS scores and components.
The same discussion applies to how to describe XDAS-based event data
expression. (I might be wrong, but according to the Jan. 1998 version of
XDAS, the schema of XDAS is not defined. Maybe later version is available
somewhere?)

In a way, I think we still do not have enough schemata to facilitate
information exchanges, and this area is evolving actively as we can see here
in the MILE group.

Regarding the processing instruction, let me work on this for a while.

> 4.3 - Vulnerability : Incident.Method.AdditionalData.Vulnerability
>
> - NIST will be releasing a vulnerability data model (should be end of this
> month), that will be loosely based off of the current NVD CVE feeds
> (building off the lessons learned from disseminating this data over the
> past few years). This could be another option for representing
> Vulnerability data and how it connects CVE to [CVSS, CWE, CPE].

I'm looking forward to the release. Thank you for the information.

> - For the "Record" element, the schema is supposedly defined by IANA
> registry. For some things that have multiple different schemas associated
> with them (e.g., both NVD and MITRE manage different "columns" of data for
> CVE), with no one schema being "authoritative", but each schema containing
> different types of data. Will the IANA registry handle this?

I think this shouldn't be a problem, but let me confirm it when I visit IANA
desk at the IETF Taipei meeting.

> 4.7 Remediation - Incident.AdditionalData.Remediation
>
> - XCCDF, OVAL, and OCIL have traditionally been used for compliance
> "verification" and it is not clear how they will be used within a
> remediation context; XCCDF may apply, but OVAL and OCIL do not have any
> state-changing capabilities (or if they do I have not seen them in use).
> NIST/MITRE/NSA/DHS is working on a new "ERAP" framework that includes
> remediation specifications, you may want to reach into that, but I'm not
> sure what the level of maturity is.
> - XCCDF, OVAL and OCIL may be better suited in either the "Method" or
> "System" elements, where they can help provide structured content
> describing what to look for on a network to determine if the incident is
> taking place, or if the network is vulnerable to the possibility of the
> incident taking place.
> - If XCCDF will be used, then guidance should be provided for how to use
> it (e.g., fix/fix-text elements)
>

Thank you for your comment on this.
Well, I also think XCCDF, OVAL, OCIL is used for the purpose of
verification.
On the other hand, I am hoping to see information description for
remediation in the future.
For that purpose, I wanted to prepare Remediation class.
Maybe we could see verification as a tool for remediation?
If so, I still would like to put these specifications here.
But if verification and remediation are totally different concept in the
sense of English wording, I need to change the name of the class from
Remediation to Verification.
Would you think it is ok to put verification tools inside remediation? Or is
it peculiar?

I've added current working-in-progress version of the draft to facilitate
discussion since some of the discussion above could be confusing without
revised draft.
But the draft is still work in progress, and I will work further on the
draft.

I would like to thank you once again for your kind comments, and would also
appreciate further comments.

Take

2011/9/7 Cichonski, Paul <[email-masked]>:
> All,
>
> The NIST security automation team reviewed the latest draft of the
> "IODEF-extension to support structured cybersecurity information"
> specification" (we were using the draft from 08/26/2011 -
> https://tools.ietf.org/html/draft-takahashi-mile-sci-00).
>
> We have a few comments relating to how some of the security automation
> models are being used within IODEF, these comments are provided below.
>
> ** High Level Comments **:
>
> - Some of the sections specify the inclusion of embedded XML as an
> ML_STRING (4.2, 4.4, 4.6, 4.7). This may add a lot of burden to validation
> and processing of the IODEF instance document. Processors will essentially
> have to extract the ML_STRING and treat it as a separate XML instance
> document (adhering to the schema resolved from IANA registry); this will
> require a separate validating parse as well as additional resources to
> process than it would if it were just a part of the containing IODEF
> instance.
>
> Instead of the ML_STRING, would it be better to somehow specify the schema
> element that should be used when capturing data associating with a
> specific specification? If actual XML is used instead of the ML_STRING,
> than the entire document can be validated/processed in the same parse. One
> way to do this while maintaining the decoupled nature provided by the
> ML_STRING would be to make the "Record" element an xsd:any tag, and
> provide guidance that the element used in place of the xsd:any tag (in an
> instance document) must match the root namespace element specified in the
> IANA
> registry of the specification. This will allow for a single instance
> document, instead of an instance document with many ML_STRINGS that must
> be converted/interpreted separately.
>
> - It seems that some of the context required to successfully interpret the
> data is missing in the current approach. The current structure of
> inclusion treats the IODEF document as a bag into which these additional
> structured objects are included (e.g., Vulnerability, Weakness, Scoring,
> EventRecord, AttackPattern). However, the relationships between these
> objects, within the context of the larger incident, is missing. For
> example, I have no way of knowing that a specific CVSS score (Scoring
> element as defined in section 4.1) relates to a specific CVE
> (Vulnerability element as defined in section 4.3), as found on a specific
> platform (PlatformId element as defined in section 4.5). There are many
> different permutations of this example, but the main issue is that the
> relationships between these atomic objects are not captured in the
> document; we say they were involved in the incident, but no specific
> details describing that involvement.
>
> One way of capturing these relationships may be to use the more
> aggregate-data models to describe them. For example, if a detailed
> vulnerability data model is used in the Vulnerability section, then that
> data model will provide the relationships between the CVE, the CVSS score
> of the CVE, and the CPEs associated with it. In this case there would be
> no need to provide additional data in the Scoring and PlatformId elements,
> unless it is provided to ease the parsing burden if that is the only thing
> a client is looking for. More guidance is needed to show how these
> relationships should be resolved and interpreted within the context of the
> larger incident.
>
> - To decrease the size of the IODEF document, many of the embedded
> "Records", that are currently ML_STRINGs (but could also be XML elements)
> could be included using a reference to some authoritative repository that
> stores the data. Under the existing approach, a single IODEF instance
> document will be mixing content across logical levels: the instance data
> associated with the actual incident, and the reference data describing
> components involved in the incident. The reference data could easily be
> included by providing a tuple of the 1) identifier of the object and 2)
> a reference to one or more authoritative repositories from which to
> retrieve the metadata
> about the object this identifier represents. We may also need to provide
> guidance on how to retrieve data from specific repositories.
>
> The embedding model can still be allowed (especially in environments that
> can't reach out to external resources), but including a referential model
> would be useful for those environments that can make use of it.
>
> - Would it be desirable to add in a greater degree of de-coupling into
> this spec to make it more "future-proof"? Some of the specs listed are not
> yet final, and those that are may not always be in favor. It may be
> possible to extend the IANA registry model so that we have a registry that
> is keyed off the IODEF object type (e.g., Vulnerability, Scoring,
> AttackPattern, ...), and for each type lists the specifications that
> should/may be used to express this data and the specific guidance on how
> each spec should be used. May be a good idea (or something like this) if
> we desire this level of modularity.
>
> - All of the elements defined in sections 4.x contain a "Version"
> attribute that the spec says MUST be 1.00. May want to provide more
> guidance on what this means and what it is a version of.
>
> - OCIL should be listed in the spec list in the intro since it is listed
> in section 4.7.
>
> ** Low Level Comments **:
>
> 4.1 - Scoring : Incident.Assessment.AdditionalData.Scoring:
>
> - See high-level comment, but it is unclear what each atomic "score" is
> actually scoring. No context provided as far as how the score relates to
> some other object contained in the IODEF instance document and it does not
> seem like it is a score for the overall incident.
> - Spec says Score attribute must be "zero or one", but since a CVSS score
> would fall somewhere between that range (assuming it was divided by 10) it
> will not normally be either zero or one. It may also help to include
> requirements relating to the decimal precision point of the "score".
> - Some scoring systems provide a parameter string
> (AV:N/AC:L/Au:N/C:P/I:N/A:N) that is useful in certain situations, where
> would this go?
> - How to reflect the fact that a particular score value did (or did not)
> reflect environmental or temporal metrics?
> - These same type of ambiguities likely exist for CWSS as well. It may be
> a good idea to provide more granular guidance on how to handle these
> things and possibly providing a "processing-instruction" element that will
> contain text with instructions on processing scores from specifications
> where there is no guidance provided in the spec (i.e., the "other" scoring
> specs). This "processing-instruction" concept may help in every section in
> 4.x.
>
> 4.3 - Vulnerability : Incident.Method.AdditionalData.Vulnerability
>
> - NIST will be releasing a vulnerability data model (should be end of this
> month), that will be loosely based off of the current NVD CVE feeds
> (building off the lessons learned from disseminating this data over the
> past few years). This could be another option for representing
> Vulnerability data and how it connects CVE to [CVSS, CWE, CPE].
> - For the "Record" element, the schema is supposedly defined by IANA
> registry. For some things that have multiple different schemas associated
> with them (e.g., both NVD and MITRE manage different "columns" of data for
> CVE), with no one schema being "authoritative", but each schema containing
> different types of data. Will the IANA registry handle this?
>
> 4.5 PlatformID - Incident.EventData.Flow.System.AdditionalData.PlatformID
>
> - Typo for name of CPE, should be "Common Platform Enumeration", not
> "common attack pattern enumeration and classification".
> - ISO 19770-2 may also be a good spec to list here, it is not yet in wide
> adoption, but there is a lot of talk around how to integrate 19770-2 and
> CPE.
>
> 4.6 EventReport -
> Incident.EventData.Record.RecordData.RecordItem.EventReport
>
> - Typo for name of CEE, should be "common event expression", not "common
> attack pattern enumeration and classification".
> - May also want to include The Open Group's XDAS v2, which is also trying
> to standardize event data expression.
>
> 4.7 Remediation - Incident.AdditionalData.Remediation
>
> - XCCDF, OVAL, and OCIL have traditionally been used for compliance
> "verification" and it is not clear how they will be used within a
> remediation context; XCCDF may apply, but OVAL and OCIL do not have any
> state-changing capabilities (or if they do I have not seen them in use).
> NIST/MITRE/NSA/DHS is working on a new "ERAP" framework that includes
> remediation specifications, you may want to reach into that, but I'm not
> sure what the level of maturity is.
> - XCCDF, OVAL and OCIL may be better suited in either the "Method" or
> "System" elements, where they can help provide structured content
> describing what to look for on a network to determine if the incident is
> taking place, or if the network is vulnerable to the possibility of the
> incident taking place.
> - If XCCDF will be used, then guidance should be provided for how to use
> it (e.g., fix/fix-text elements)
>
> 10 References
>
> - OCIL 2.0 is final (1.1 is listed)
> - CPE 2.3 is final (no version currently listed)
> - XCCDF 1.2 is in final stages of release, should reference this vs 1.1.4.
>
> Thoughts?
> Paul Cichonski
>
>
>
>
>
>
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

-- 
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 11:27:05 -0400

Hi Take,

I agree with most of your comments on points that I've raised, but I'll leave
the topic of how best to embed XML to those with more expertise in XML parsing.

I can help with the IANA issues, as I've been an IETF WG chair for a while,
and so have some experience in working with IANA.

> IANA experts what would be the appropriate way to proceed this issue further.

RFC 5226 provides background on IANA's registry function and what should be
specified when creating a new registry:
        http://datatracker.ietf.org/doc/rfc5226/

> > we desire this level of modularity.

There are many IANA registries that have this sort of structure - an example
that Paul Hoffman and I are very familiar with is the IKEv2 registry:
        http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml

With the current enumeration approach, the IANA registry created by this draft
would record the enumeration value and cite the RFC that provides the details
(e.g., XML namespace, usage guidance).  The desire for usage guidance suggests
that adding values to this registry may be best done via publication of an RFC
that registers the enumeration value and contains the guidance, so that the
guidance is reviewed and IANA doesn't need to get involved in editing or
maintaining the guidance (if concerns arise with the guidance, the RFC that
contains it can be replaced if appropriate).

Feel free to contact me directly (off the list) if I can help further with IANA
concerns.

Thanks,
--David

> -----Original Message-----
> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Monday, September 12, 2011 6:24 AM
> To: [email-masked]; [email-masked]
> Cc: Black, David; [email-masked]; [email-masked]; [email-masked];
> 'Kadobayashi Youki'
> Subject: Re: [mile] Comments for the IODEF-extension to support structured cybersecurity information
>
> Hi Paul and all,
>
> > instance document) must match the root namespace element specified in the IANA
> I was sticking to ML_STRING since some of the future specification could be non-XML.
> and I think this IODEF-extension should focus on embedding XML-based specification only.
> and use this data type for Record elements. I hope this corresponds to the concern.
>
> PlatformID and Scoring were added under the Vulnerability and Weakness classes.
> Another candidate way to handle this is adding one value to the ENUM list of SpecificationName.
> For instance, SpecificationName values of Vulnerability could be cve, cvrf, "link", or others.
> element, though the Record element should be a valid XML document to pass the XML validations.
>
> IANA experts what would be the appropriate way to proceed this issue further.
> I believe this is the issue related to your above comments on information structure.
> (I mean, this document should not define the XML schema for describing these information in XML.)
> Well, I also think XCCDF, OVAL, OCIL is used for the purpose of verification.
> On the other hand, I am hoping to see information description for remediation in the future.
> discussion since some of the discussion above could be confusing without revised draft.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 13 Sep 2011 13:03:15 +0900

Hi David,

Thank you very much for your kind assistance, and I really appreciate that.
Let me read through the information you kindly gave me, and revise the
draft.

Best Regards,
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 13, 2011 12:27 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Comments for the IODEF-extension to support structured
cybersecurity information - IANA

Hi Take,

I agree with most of your comments on points that I've raised, but I'll
leave
the topic of how best to embed XML to those with more expertise in XML
parsing.

further.

 

With the current enumeration approach, the IANA registry created by this
draft
would record the enumeration value and cite the RFC that provides the
details
(e.g., XML namespace, usage guidance).  The desire for usage guidance
suggests
that adding values to this registry may be best done via publication of an
RFC
that registers the enumeration value and contains the guidance, so that the
guidance is reviewed and IANA doesn't need to get involved in editing or
maintaining the guidance (if concerns arise with the guidance, the RFC that
contains it can be replaced if appropriate).

Feel free to contact me directly (off the list) if I can help further with
IANA
concerns.

Thanks,
--David

specification only.
classes.
the XML validations.
further.
structure.
verification.
revised draft.
> > 4.5 PlatformID -
Incident.EventData.Flow.System.AdditionalData.PlatformID

---

From: "Cichonski, Paul" <[email-masked]>
Date: Mon, 19 Sep 2011 14:28:50 -0400

Hey Take,

Thank-you for your quick response, I have provided comments inline below:

On 9/12/2011 6:24 AM, Takeshi Takahashi wrote:
> > ML_STRING (4.2, 4.4, 4.6, 4.7). This may add a lot of burden to
> > validation and processing of the IODEF instance document. Processors
> > will essentially have to extract the ML_STRING and treat it as a
> > separate XML instance document (adhering to the schema resolved from
> > IANA registry); this will require a separate validating parse as well
> > as additional resources to process than it would if it were just a
> > part of the containing IODEF instance.
> >
> > Instead of the ML_STRING, would it be better to somehow specify the
> > schema element that should be used when capturing data associating
> > with a specific specification? If actual XML is used instead of the
> > ML_STRING, than the entire document can be validated/processed in the
> > same parse. One way to do this while maintaining the decoupled nature
> > provided by the ML_STRING would be to make the "Record" element an
> > xsd:any tag, and provide guidance that the element used in place of
> > the xsd:any tag (in an instance document) must match the root
> > namespace element specified in the IANA registry of the
> specification.
> > This will allow for a single instance document, instead of an
> instance
> > document with many ML_STRINGS that must be converted/interpreted
> > separately.
> 
> But after reading emails from you and David repeatedly, I changed my
> mind, and I think this IODEF-extension should focus on embedding XML-
> based specification only.
> So, I defined a new data type "EM_XML" for embedded complete XML
> document, and use this data type for Record elements.

I like this approach, in the updated draft that you had attached I still see the "Record" element types defined as ML_STRING, but I am assuming you will be replacing this with EM_XML in the future versions.

> > - It seems that some of the context required to successfully
> interpret
> > the data is missing in the current approach. The current structure of
> > inclusion treats the IODEF document as a bag into which these
> > additional structured objects are included (e.g., Vulnerability,
> > Weakness, Scoring, EventRecord, AttackPattern). However, the
> > relationships between these objects, within the context of the larger
> > incident, is missing. For example, I have no way of knowing that a
> > specific CVSS score (Scoring element as defined in section 4.1)
> > relates to a specific CVE (Vulnerability element as defined in
> section
> > 4.3), as found on a specific platform (PlatformId element as defined
> > in section 4.5). There are many different permutations of this
> > example, but the main issue is that the relationships between these
> > atomic objects are not captured in the document; we say they were
> > involved in the incident, but no specific details describing that
> involvement.
> >
> > vulnerability data model is used in the Vulnerability section, then
> > that data model will provide the relationships between the CVE, the
> > CVSS score of the CVE, and the CPEs associated with it. In this case
> > there would be no need to provide additional data in the Scoring and
> > PlatformId elements, unless it is provided to ease the parsing burden
> > if that is the only thing a client is looking for. More guidance is
> > needed to show how these relationships should be resolved and
> > interpreted within the context of the larger incident.
> 
> To clarify the relationships among them, the number of Record within
> each Attackpattern, Vulnerability, and Weakness is limited to one at
> maximum.
> (i.e., if someone wants to insert multiple CVE entries, then he needs
> to use multiple Vulnerability elements, each of which contains single
> CVE entry.) On the other hand, I still kept PlatformID element under
> System since the ID is still useful for describing iodef:Flow
> information.

I think this approach is better since the context is at least provided by the enclosing element. I am not certain to what extent it will be used since most of the PlatformID and Scoring information relative to AttackPattern, Vulnerability and Weakness will be contained in the more robust data models capturing the object information (e.g., capec, cvrf), but I seen no harm in adding it and see if people decide to use it.

I would suggest the following minor changes:

- For "Scoring" as it appears in "Vulnerability" and "Weakness" section, would it make sense to require that the score be either CVSS, or CWSS based on the enclosing section? So the "Vulnerability" section would require that the score be a CVSS score, and the "Weakness" section would require a CWSS score.
- For all occurrences of PlatformId within AttackPattern, Vulnerability, and Weakness; it may help to add a bit of informative text making the context more explicit. So, starting at line 319 for AttackPattern: "An identifier of software platform" could be changed to "An identifier of software platform involved in the specific attack pattern". For Vulnerability, starting on line 464: "An identifier of software platform" could be "An identifier of the software platform affected by the vulnerability". And for Weakness, starting on line 600: "An identifier of software platform" could be "An identifier of software platform affected by the weakness". This is a bit pedantic, but I think making that explicit will help the developers coding to this spec.
- Similar to above, for Weakness, starting on line 603 the description of "Scoring" could be changed from "An indicator of the severity of the vulnerability" to "An indicator of the severity of the weakness".

> > "Records", that are currently ML_STRINGs (but could also be XML
> > elements) could be included using a reference to some authoritative
> > repository that stores the data. Under the existing approach, a
> single
> > IODEF instance document will be mixing content across logical levels:
> > the instance data associated with the actual incident, and the
> > reference data describing components involved in the incident. The
> > reference data could easily be included by providing a tuple of the
> 1)
> > identifier of the object and 2) a reference to one or more
> > authoritative repositories from which to retrieve the metadata about
> > the object this identifier represents. We may also need to provide
> > The embedding model can still be allowed (especially in environments
> > that can't reach out to external resources), but including a
> > referential model would be useful for those environments that can
> make use of it.
> 
> Yes, I agree.
> Vulnerability, Weakness, EventReport, and Remediation classes, and
> noted either the Record or the reference need to be included.
> 

Do you mean from an XML-schema perspective, in a way that makes this "one or the other" requirement enforceable via schema? The easiest way to do this would probably be through the use of xsd:choice. For example, the "Vulnerability" schema snippet would look like this (note that if you go this way you may want to create some abstract schema types that include the common elements/attributes, which all of the elements [e.g., Vulnerability, Weakness, etc..] could use via extension):

    <xsd:element name="Vulnerability">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="SpecificationName" type="xsd:string"/>
                <xsd:element name="SpecificationVersion" type="xsd:string"/>
                <xsd:choice>
                    <xsd:element name="Record" type="xsd:string"/>
                    <xsd:element name="Reference" type="iodef:Reference"/>
                </xsd:choice>
            </xsd:sequence>
            <xsd:attribute name="Version" type="xsd:string"/>
        </xsd:complexType>
    </xsd:element>

> When "link" is used for SpecificationName, a link is described in the
> Record element, though the Record element should be a valid XML
> document to pass the XML validations.
> 

I'm not sure if I like this approach, since the "link" type is not of the same logical category of the other things enumerated (it is really just the format of representing those other things, either via-reference or via-value). Also, if a system uses "link" the information as to the actual type of "thing" is lost. However, I do agree that we probably need to provide more detailed semantics relating to how to dereference a "thing" when a reference is used. One possible way of doing this would be to use the W3C XLink specification instead of the iodef:reference element. XLink (http://www.w3.org/TR/xlink/) provides a standardized way of linking to external resources. We could probably use xlink in combination with the IANA registry system to formalize how users should de-reference "things" from remote repositories (this should probably be a new thread if we decide to explore this approach).

> > this spec to make it more "future-proof"? Some of the specs listed
> are
> > not yet final, and those that are may not always be in favor. It may
> > be possible to extend the IANA registry model so that we have a
> > registry that is keyed off the IODEF object type (e.g.,
> Vulnerability,
> > Scoring, AttackPattern, ...), and for each type lists the
> > specifications that should/may be used to express this data and the
> > specific guidance on how each spec should be used. May be a good idea
> > (or something like this) if we desire this level of modularity.
> >
> 
> Since I am a bit confused on the IANA issues, I will go there and ask
> the IANA experts what would be the appropriate way to proceed this
> issue further.
> futureproof, and for that I would like to have a pool of namespace list
> that is extensible.

It looks like David (Black) already commented on this to a much greater degree than I would have been able to. Suggest we start a new thread if we need more discussion on the IANA topic.

> Well, my intention is that this extension document should not define
> how to describe CVSS/CWSS scores (and their elements) in XML format.
> (I mean, this document should not define the XML schema for describing
> these information in XML.) I would rather like to see that this
> extension document references an external XML schema for describe these
> CVSS/CWSS scores and components.

I agree with this approach, I had mis-read this section. 

> expression. (I might be wrong, but according to the Jan. 1998 version
> of XDAS, the schema of XDAS is not defined. Maybe later version is
> available
> somewhere?)

The Open Group is currently working on an XDAS v2 and I think they are planning to have a draft schema out by the end of the calendar year (I could be totally off on that date).

> But if verification and remediation are totally different concept in
> the sense of English wording, I need to change the name of the class
> from Remediation to Verification.
> Would you think it is ok to put verification tools inside remediation?
> Or is it peculiar?

I will defer to those working more closely in this area to answer this.

Thanks,
Paul