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

From: Lagadec Philippe <[email-masked]>
Date: Thu, 22 Sep 2011 15:15:44 +0200

Hello,

I would like to complement one comment made by Paul: 
In many cases it would be much better to use references with identifiers, rather than including full data records in XML.

In fact in the list of formats covered by the extension (CVE, CVRF, OVAL, etc), there are two different types of data, that we could roughly summarize as "enumerations" and "reports" or something like that.

CVE, CPE, CWE, CAPEC are enumerations: given a unique identifier, anyone should be able to query a well-known public repository and get all the data corresponding to the identifier. (CPE is a bit different but let's keep it simple)
For example for a known vulnerability such as CVE-2010-3654, all the authoritative (and up to date) information can be obtained from http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3654 or http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3654 
(and all this information is also available in XML format for automation purposes)
In this case, it is not useful to duplicate the public information in an IODEF record. If it is duplicated for each incident, then it increases the amount of data and it takes more processing time to parse. Also there is a risk that the information is either not up-to-date or even wrong after a while.
I think the only case where it makes sense to include a full CVE/NVD/CVRF/CPE/CWE/CAPEC record in IODEF, is when the incident is related to a previously unknown vulnerability/weakness/etc that is not already available in the public repositories.

On the other hand, CEE, XDAS, CVRF, OVAL, XCCDF, are not enumerations but records containing data to report a specific event, vulnerability assessment, compliance report, etc.
In this case it makes sense to include the full XML data since it is not supposed to be available in a public repository.

Therefore I think the RFC should put more emphasis on the way to add a clear reference to a CVE id, CWE id, etc. 
One solution could be to add a clearly identified string attribute for a CVE identifier, for example.
Or when SpecificationName="cve-id" (or something like that), then the Record attribute should only contain a string with the CVE identifier, not XML data.

Hope this helps,

Philippe.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: 12 September 2011 12:24
To: [email-masked]; [email-masked]
Cc: 'Kadobayashi Youki'
Subject: Re: [mile] Comments for the IODEF-extension to support structured cybersecurity information

Hi Paul and all,

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

[...]

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

[...]

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

---

From: "Martin, Robert A." <[email-masked]>
Date: Thu, 22 Sep 2011 09:44:53 -0400

Hello,

I agree that this would be a useful simplification of the proposed MILE 
extensions especially for CVE, CPE and CWE.

However I would be concerned with this approach for CAPEC, where we 
believe that in the future it may be useful to not only utilize a CAPEC 
ID for Clickjacking (CAPEC 103), but it also may make sense to talk 
about the way the attacker pursued the attack.  For instance we could 
say that the attacker used CAPEC-103's Attack Execution Flow Attack Step 
Technique ID 4 followed by an Experiment Attack Step Techniques ID 3 and 
then using Exploit 2 with Attack Step Technique ID 2.

While currently CAPEC's content is not complete enough to support this 
short-hand for conveying this depth of detail on the specific attack 
involved in an incident, I wouldn't want us to close the door to making 
use of this structure when we want to.

I don't think we would need the full CAPEC xml to support this type of 
slice through CAPEC content but we definitely would need more than just 
and CAPEC ID.

Regards,

Bob

On 9/22/11 9:15 AM, Lagadec Philippe wrote:
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
> .
>

---

From: "Martin, Robert A." <[email-masked]>
Date: Thu, 22 Sep 2011 10:04:56 -0400

Sorry for the typo in the last sentence of my previous message.

There should be the word "a" instead of "and" as the 3rd from last word 
in that sentence. The correct concluding sentence is:

"I don't think we would need the full CAPEC xml to support this type of 
slice through CAPEC content but we definitely would need more than just 
a CAPEC ID."

Regards,

Bob

On 9/22/11 9:44 AM, Martin, Robert A. wrote:
> about the way the attacker pursued the attack. For instance we could say
> that the attacker used CAPEC-103's Attack Execution Flow Attack Step
>> In many cases it would be much better to use references with
>> identifiers, rather than including full data records in XML.
>>
>> In fact in the list of formats covered by the extension (CVE, CVRF,
>> OVAL, etc), there are two different types of data, that we could
>> roughly summarize as "enumerations" and "reports" or something like that.
>>
>> CVE, CPE, CWE, CAPEC are enumerations: given a unique identifier,
>> anyone should be able to query a well-known public repository and get
>> all the data corresponding to the identifier. (CPE is a bit different
>> but let's keep it simple)
>> For example for a known vulnerability such as CVE-2010-3654, all the
>> authoritative (and up to date) information can be obtained from
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3654 or
>> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3654
>> In this case, it is not useful to duplicate the public information in
>> an IODEF record. If it is duplicated for each incident, then it
>> increases the amount of data and it takes more processing time to
>> parse. Also there is a risk that the information is either not
>> up-to-date or even wrong after a while.
>> I think the only case where it makes sense to include a full
>> CVE/NVD/CVRF/CPE/CWE/CAPEC record in IODEF, is when the incident is
>> related to a previously unknown vulnerability/weakness/etc that is not
>> already available in the public repositories.
>>
>> On the other hand, CEE, XDAS, CVRF, OVAL, XCCDF, are not enumerations
>> but records containing data to report a specific event, vulnerability
>> assessment, compliance report, etc.
>> In this case it makes sense to include the full XML data since it is
>> not supposed to be available in a public repository.
>>
>> Therefore I think the RFC should put more emphasis on the way to add a
>> clear reference to a CVE id, CWE id, etc.
>> Or when SpecificationName="cve-id" (or something like that), then the
>> Record attribute should only contain a string with the CVE identifier,
>> not XML data.
>>
>> Hope this helps,
>>
>> Philippe.
>>
>>
>> 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.
>>
>> 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'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.

---

From: "Cichonski, Paul" <[email-masked]>
Date: Thu, 22 Sep 2011 16:59:47 -0400

Philippe / Bob,

I agree with most of what you are saying, just a few minor comments:

On 9/22/11 9:15 AM, Lagadec Philippe wrote:
> Therefore I think the RFC should put more emphasis on the way to add 
> a clear reference to a CVE id, CWE id, etc.
> Record attribute should only contain a string with the CVE 
> identifier, not XML data.

I agree that more emphasis should be placed on the use of these identifiers, rather than embedding large chunks of XML that may be found in some public repository. I only want to caution against removing the ability to embed XML for these areas entirely. There may be situations where IODEF is being used in environments that do not have easy access to the public repository, or where organizations using IODEF make some organizationally-specific decision not to use the public repository. Whatever the case, I think it is useful to allow for the embedded XML in case someone identifies a use for it, and allow organizations (or information-sharing networks) adopting this standard to define their own granular usage policies.

On 9/22/11 9:44 AM, Martin, Robert A. wrote:
> believe that in the future it may be useful to not only utilize a 
> CAPEC ID for Clickjacking (CAPEC 103), but it also may make sense to 
> talk about the way the attacker pursued the attack. For instance we 
> could say that the attacker used CAPEC-103's Attack Execution Flow 
> Attack Step Technique ID 4 followed by an Experiment Attack Step 
> Techniques ID 3 and then using Exploit 2 with Attack Step Technique ID 2.

I think that this is a different side of the same issue I was raising above. The only difference is that in this case, it is not pure reference data that is being embedded in the IODEF, but a cross-section of a larger graph of reference data that is annotated with incident-specific details of how that reference data applies. I think this type of model would be very useful when it is complete since it provides some of the context connecting the reference data to the specific incident that I had mentioned in my original email.

Thanks,
Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin, Robert A.
> Sent: Thursday, September 22, 2011 10:05 AM
> To: Lagadec Philippe
> Cc: [email-masked]; 'Kadobayashi Youki'
> say
> >> One solution could be to add a clearly identified string attribute
> for
> >> a CVE identifier, for example.
> >> For instance, SpecificationName values of Vulnerability could be
> cve,
> >> cvrf, "link", or others.
> >> I would like to thank you once again for your kind comments, and
> would
> >> also appreciate further comments.
> >>
> >> Take
> >>
> >>

---

From: Lagadec Philippe <[email-masked]>
Date: Fri, 23 Sep 2011 10:34:55 +0200

Paul, Take,

I think that using reference attributes (iodef:Reference, cf. RFC5070) as suggested by Take is a very useful addition, but some text is missing to clarify the usage and avoid misinterpretation.

In the case of CVE/CWE/CPE/etc, URLs pointing to a specific repository are mostly useful to humans when an Internet connection is available.
For a given vulnerability such as CVE-2010-3654, there can be several URLs pointing to different repositories (CVE, NVD, OSVDB, etc). Moreover, URLs are related to the underlying web application so they might change over time. Whereas, identifiers are unique and are not supposed to change.
In general, and especially for automation purposes or when using a network that is not connected to the Internet, the primary information we need is the identifier. Then we may add the full XML record and/or a URL reference if needed.

So I think that the text should clarify how to use the Reference tag to provide proper unique identifiers.
For all cases where public unique identifiers are involved, including CVE, CWE and CAPEC, I think there should always be a Reference with a ReferenceName containing the identifier.
Optionally there can also be a Reference URL and full Record data when needed.

Here is an example of the potential usage (compatible with Take's draft version 1):

    <Method>
      <AdditionalData>
        <Vulnerability>
          <SpecificationName>cve</SpecificationName>
          <Reference>
             <ReferenceName>CVE-2010-3654</ReferenceName>
             <URL>http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3654</URL>
          </Reference>
          <Record>[OPTIONAL data in CVE format]</Record>
        </Vulnerability>
        <Weakness>
          <SpecificationName>cwe</SpecificationName>
          <Reference>
             <ReferenceName> CWE-119</ReferenceName>
             <URL>http://cwe.mitre.org/data/definitions/119.html</URL>
          </Reference>
          <Record>[OPTIONAL data in CWE format]</Record>
        </Weakness>
        <AttackPattern>
          <SpecificationName>capec</SpecificationName>
          <Reference>
             <ReferenceName>CAPEC-14</ReferenceName>
             <URL>http://capec.mitre.org/data/definitions/14.html</URL>
          </Reference>
          <Record>[OPTIONAL data in CAPEC format]</Record>
        </AttackPattern>
      </AdditionalData>
    </Method>

Alternatively, a second solution would be to add an "ID" attribute to the Vulnerability, AttackPattern and Weakness classes, following the same design as the PlatformID class. This solution would be more coherent and would highlight the need for identifiers.
However, I think it should be a STRING rather than an ML_STRING, because identifiers are not supposed to contain several lines.

Here is an example of the potential usage, for the same data as above:

    <Method>
      <AdditionalData>
        <Vulnerability>
          <SpecificationName>cve</SpecificationName>
          <ID>CVE-2010-3654</ID>
          <Reference><URL>http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3654</URL></Reference>
          <Record>[OPTIONAL data in CVE format]</Record>
        </Vulnerability>
        <Weakness>
          <SpecificationName>cwe</SpecificationName>
          <ID>CWE-119</ID>
          <Reference><URL>http://cwe.mitre.org/data/definitions/119.html</URL></Reference>
          <Record>[OPTIONAL data in CWE format]</Record>
        </Weakness>
        <AttackPattern>
          <SpecificationName>capec</SpecificationName>
          <ID>CAPEC-14</ID>
          <Reference><URL>http://capec.mitre.org/data/definitions/14.html</URL></Reference>
          <Record>[OPTIONAL data in CAPEC format]</Record>
        </AttackPattern>
      </AdditionalData>
    </Method>

To go further, in order to obtain more compact XML and to simplify parsing, I think it would be better to use XML attributes rather than tags for short strings and URLs, for example:

        <Vulnerability SpecificationName="cve" ID="CVE-2010-3654">
          <Reference><URL>http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3654</URL></Reference>
          <Record>[OPTIONAL data in CVE format]</Record>
        </Vulnerability>

The three solutions are functionally equivalent, but I would recommend the third one for practical reasons.

Regards,

Philippe.

-----Original Message-----
From: Cichonski, Paul [mailto:[email-masked]]
Sent: 22 September 2011 23:00
To: [email-masked]
Cc: 'Kadobayashi Youki'; Martin, Robert A.; Lagadec Philippe
Subject: RE: [mile] Comments for the IODEF-extension to support structured cybersecurity information

Philippe / Bob,

Thanks,
Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Martin, Robert A.
> There should be the word "a" instead of "and" as the 3rd from last
> word in that sentence. The correct concluding sentence is:
>
> "I don't think we would need the full CAPEC xml to support this type
> of slice through CAPEC content but we definitely would need more than
> just a CAPEC ID."
>
> Regards,
>
> Bob
>
> CAPEC
> >> For example for a known vulnerability such as CVE-2010-3654, all
> >> the authoritative (and up to date) information can be obtained from
> >> (and all this information is also available in XML format for
> >> automation purposes) In this case, it is not useful to duplicate
> >> the public information
> in
> >> In this case it makes sense to include the full XML data since it
> >> is not supposed to be available in a public repository.
> >>
> a
> identifier,
> >>> elements) could be included using a reference to some
> >>> authoritative repository that stores the data. Under the existing
> >>> approach, a
> single
> >>> reference data could easily be included by providing a tuple of
> >>> the
> 1)