Subject: Re: [mile] ID for structured information / list of specification IDs

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 26 Sep 2011 15:01:54 +0900

I've got an error message, so let me resend the email below.
Please accept my apologies if you receive duplication.

Take

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Monday, September 26, 2011 2:43 PM
To: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; 'Robert Martin';
[email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; 'Youki Kadobayashi'
Subject: ID for structured information / list of specification IDs

Hi Bob, Brian, David, Paul, Philippe, and all,

Thank you for the comments. I really appreciate that.

The attached is the draft that reflects (I hope) the discussion last week.

Regarding the "reference to the information" issue, the draft is written
following Philippe's third option.
The draft added the IDs for structured information (such as
VulnerabilityID), and made both embedded XML and link information optional.

   +------------------------+
   | Vulnerability          |
   +------------------------+
   | STRING Version         |<>--(0..*)--[ Record ]
   | ENUM SpecificationID   |<>--(0..*)--[ Reference ]
   | STRING VulnerabilityID |<>--(0..*)--[ PlatformID ]
   |                        |<>--(0..*)--[ Scoring ]
   +------------------------+

As Paul suggested, the class has both Record and Reference elements.
As Philippe suggested, maybe we had better add some sentences on desired
usage (e.g. Reference SHOULD be preferred blabla...).

Another big change is the introduction of Figure 1.
The draft expects an IANA registry to manage this list, and thus expects
future-proof.

   ID         Secification Name       Version  Namespace
   ---------  ----------------------  -------  ------------------------
   CAPEC_1.6  Common Attack Pattern   1.6      http://capec.mitre.org
              Enumeration and                  /observables
              Classification (CAPEC)
   CEE_0.6    Common Event Expression 0.6      http://cee.mitre.org
              (CEE)
   CPE_2.3    Common Platform         2.3      http://cpe.mitre.org
              Enumeration (CPE)                /language/2.0
   CVE_1.0    Common Vulnerability    1.0      http://cve.mitre.org
              and Exposures (CVE)              /cve/downloads/1.0
   CVRF_1.0   Common Vulnerability    1.0      http://www.icasi.org
              Reporting Format                 /CVRF/schema/cvrf/1.0
              (CVRF)
   CVSS_2.0   Common Vulnerability    2        http://scap.nist.gov
              Scoring System (CVSS)            /schema/cvss-v2/1.0
   CWE_5.0    Common Weakness         5.0      TBD
              Enumeration (CWE)
   CWSS_0.8   Common Weakness         0.8      TBD
              Scoring System (CWSS)
   OCIL_2.0   Open Checklist          2.0      http://www.mitre.org
              Interactive Language             /ocil/2.0
              (OCIL)
   OVAL_5.10  Open Vulnerability and  5.10     http://oval.mitre.org
              Assessment Language              /XMLSchema
              (OVAL)                           /oval-definitions-5
   XCCDF_1.2  Extensible              1.2      http://checklists.nist
              Configuration                    .gov/xccdf/1.2
              Checklist Description
              Format (XCCDF)
   XDAS_1998  Distributed Audit       1998     TBD
              Service (XDAS)
   19770-2    ISO/IEC 19770           Part 2   TBD

                     Figure 1: List of specifications

I am still in the middle of looking for proper namespace and schemata, but I
hope this direction of this draft change is acceptable to the community.

Sincerely,
Take

2011/9/23 Lagadec Philippe <[email-masked]>:
> 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-20
> 10-3
> 654</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></
> Refe
> rence>
>          <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><
> /Ref
> erence>
>          <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-20
> 10-3
> 654</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,
>
> 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.
>> 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.
>
> 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:
>> 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.
>
> 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
>
>
>
>> -----Original Message-----
>> 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'
>> Subject: Re: [mile] Comments for the IODEF-extension to support 
>> structured cybersecurity information
>>
>> 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:
>> > 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:
>> >> 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
>> >>
>> >>
>> >> _______________________________________________
>> >> mile mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/mile
>> >> .
>> >>
>> _______________________________________________
>> 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: "Cichonski, Paul" <[email-masked]>
Date: Fri, 30 Sep 2011 09:43:54 -0400

Thanks Take,

I think this looks good, Philippe's approach makes sense.

-Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Takeshi Takahashi
> Sent: Monday, September 26, 2011 2:02 AM
> To: [email-masked]
> Subject: Re: [mile] ID for structured information / list of
> specification IDs
>
> Regarding the "reference to the information" issue, the draft is
> written following Philippe's third option.
> As Philippe suggested, maybe we had better add some sentences on
> desired usage (e.g. Reference SHOULD be preferred blabla...).
>
> The draft expects an IANA registry to manage this list, and thus
> expects future-proof.
>
>
> I am still in the middle of looking for proper namespace and schemata,
> but I hope this direction of this draft change is acceptable to the
> community.
>
> Sincerely,
> Take
>
>
>
>