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

From: "Cichonski, Paul" <[email-masked]>
Date: Tue, 6 Sep 2011 13:39:31 -0400

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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 8 Sep 2011 20:39:00 +0900

Hello Paul and all,

Thank you very much for your thoughtful comments.
I really appreciate that, and would like to reflect your points to the
draft.
Let me try it first, and come back to you later.

Sincerely,
Take

2011/9/7 Cichonski, Paul <[email-masked]>:
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 26 Sep 2011 14:09:49 +0900

Hi Paul,

Thank you for your kind reply.

>> 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.
>
> 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 agree, and I think the platform ID and scores embedded inside these
structured information (such as capec and cvrf) should be prioritized to the
values of PlatformID and Scoring elements. (if any inconsistency exists.)
So, to avoid any inconsistency, I've added the following text.

"Some of the structured information may include platform ids within it. In
this case, the PlatformID element SHOULD not be used since the Record
element contains the platform ids. If a reader/receiver detects platform ids
in both Record and PlatformID elements and their inconsistency, it SHOULD
prefer the platform ids derived from the Record element, and SHOULD log the
inconsistency so a human can correct the problem."

> 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>

Thank you for the comments.
Following the email from Philippe, I've slightly changed the structure of
the Vulnerability class.
By introducing the vulnerabilityID attribute, the current structure do not
need any choice structure any more.

I've changed the draft to reflect your kind comments including the comments
I omitted from this email.
Let me share the latest version of the draft in the other email thread.

I appreciate your kind comments. Thank you.

Sincerely,
Take

2011/9/20 Cichonski, Paul <[email-masked]>:
> Hey Take,
>
> Thank-you for your quick response, I have provided comments inline below:
>
> On 9/12/2011 6:24 AM, Takeshi Takahashi wrote:
>> Hi Paul and all,
>>
>> Thank you for your kind comments. I really appreciate that.
>>
>> > 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.
>
> 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.
>>
>> 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.
>
> 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.
>> 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.
>
> 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>
>
>
>> 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?
>
> 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.
>> >
>>
>> 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.
>
> 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.
>
>> 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.
>
> I agree with this approach, I had mis-read this section.
>
>> 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?)
>
> 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).
>
>> 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 will defer to those working more closely in this area to answer this.
>
> Thanks,
> Paul
>