Subject: Re: [mile] Fw: New Version Notification for draft-takahashi-mile-sci-02.txt

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 11 Nov 2011 00:16:53 +0900

Hi Panos and Kathleen,

First of all, I really appreciate your kind comments. Thank you.
And I am sorry for my late reply.

> 1) Some extended classes apply only to some Specifications. For example, a
> Vulnerability class can be OVAL, CVRF spec but not CEE or OCIL. In the
same
> manner an Event Report class cannot have a SpecificationID of CAPEC_1.6 or
> OVAL. A PlatformID class can only be CPE spec. So, the SpecificationID can
> be restricted to some values only for each class, which if added will help
> clarify what standard/spec (CEE, CPE, etc) applies to each class
introduced.
> The restriction can be stated in the restriction attribute of parent class
> of the introduced extended class.

Yes I understand your concern.
I was thinking to have either a single table that lists all the
specifications (as described in the current draft), or multiple tables that
list applicable specifications for each class (i.e., creating separate
tables for Attack Pattern and Vulnerability and Weakness classes),
Though this is still an open issue, I personally preferred to have a single
table that lists all the specifications since one specification may be used
by multiple classes.
In my understanding, having only one table makes things simpler.

As you pointed out, the current design may allow a user to put CVE inside
AttackPattern class, for instance.
I know it is not the expected usage, but I left it as an usage issues, and
the draft didn't restrict on that.
The draft only describes some typical specification names used by each
class.
For instance, the SpecificationID of AttackPattern class has the following
sentence: "The value should be chosen from the IDs listed in Figure 1, such
as CAPEC_1.6."

You've raised another solution, which utilizes restriction attribute.
It sounds very smart.
Could you elaborate more on how to use the restriction attribute to maintain
the future-proof design of the table?
Maybe there could be a good solution that enables us to have single table,
and could properly limit the choice of specifications for each class, and
maintains future extensibility?

> 2) Would MAEC and CCE be worth to be included in the extension?

Sure, I believe so. I will do that.

> 3) How do the extended classes incorporate XCCDF's  <xccdf:Benchmark>
> element and CCE? What class would be suitable for these? Is it
Remediation?
> It doesn't seem one of the proposed classes conceptually covers
> configuration or benchmark checks or XCCDF or CCE references.
> 4) Does OVAL fit in the Remediation class? OVAL provides vulnerability
> description and machine state for vuln assessments, I wonder if
Remediation
> class would be the one suitable to include such info.

Paul has also raised this Remediation class issue before, and the issue was
unsolved yet.
I am not sure whether "Remediation" is a good term for the class, but in the
future, I am hoping to see some language or data providing some
countermeasure or remediation.
I do not know any remediation language or the likes at this moment, though.

On the other hand, verification could be seen as a tool to support
remediation.
So, I've written OVAL and XCCDF as example specifications used by
Remediation class.

Anyway, I agree to change the name.
Maybe having remediation class at this stage is not the best idea.
I should change it into verification class.

As you pointed out, the draft still have several issues that require
discussion.
Let me prepare some slides and discuss these issues at the meeting in
Taipei.

I appreciate your thoughtful comments.
Thank you.

Take

2011/11/10  <[email-masked]>:
> Panos,
>
> Thank you for the review.  Do others have opinions on the questions
raised?
>
> Take,
>
> I would also like to see MAEC in the proposal.  Is there a reason why it
was not included?
>
> Thank you,
> Kathleen
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Panos Kampanakis
> Sent: Tuesday, November 08, 2011 6:34 PM
> To: 'Takeshi Takahashi'; [email-masked]
> Subject: Re: [mile] Fw: New Version Notification for
draft-takahashi-mile-sci-02.txt
>
> Hi Take,
>
> A few comments/questions:
>
> 1) Some extended classes apply only to some Specifications. For example, a
> Vulnerability class can be OVAL, CVRF spec but not CEE or OCIL. In the
same
> manner an Event Report class cannot have a SpecificationID of CAPEC_1.6 or
> OVAL. A PlatformID class can only be CPE spec. So, the SpecificationID can
> be restricted to some values only for each class, which if added will help
> clarify what standard/spec (CEE, CPE, etc) applies to each class
introduced.
> The restriction can be stated in the restriction attribute of parent class
> of the introduced extended class.
>
> 2) Would MAEC and CCE be worth to be included in the extension?
>
> 3) How do the extended classes incorporate XCCDF's  <xccdf:Benchmark>
> element and CCE? What class would be suitable for these? Is it
Remediation?
> It doesn't seem one of the proposed classes conceptually covers
> configuration or benchmark checks or XCCDF or CCE references.
>
> 4) Does OVAL fit in the Remediation class? OVAL provides vulnerability
> description and machine state for vuln assessments, I wonder if
Remediation
> class would be the one suitable to include such info.
>
>
> Rgs,
> Panos
>
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Takeshi Takahashi
> Sent: Sunday, October 30, 2011 1:29 AM
> To: [email-masked]
> Subject: [mile] Fw: New Version Notification for
> draft-takahashi-mile-sci-02.txt
>
> Hello all,
>
> The new version of our draft is available online.
>
> http://tools.ietf.org/html/draft-takahashi-mile-sci-02
>
> The major change to previous version is its schema.
> I would appreciate any comments on this draft.
>
> Thank you.
>
> Take
>
>
> 2011/10/29  <[email-masked]>:
>> A new version of I-D, draft-takahashi-mile-sci-02.txt has been
> successfully
>> submitted by Takeshi Takahashi and posted to the IETF repository.
>>
>> Filename:        draft-takahashi-mile-sci
>> Revision:        02
>> Title:           IODEF-extension to support structured cybersecurity
> information
>> Creation date:   2011-10-29
>> WG ID:           Individual Submission
>> Number of pages: 26
>>
>> Abstract:
>>   This document extends the Incident Object Description Exchange Format
>>   (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched
>>   cybersecurity information exchange among cybersecurity entities by
>>   embedding structured information formatted by specifications,
>>   including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R)
>>   [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], ISO/
>>   IEC 19770-2 [ISOIEC19770-2], OCIL [OCIL], OVAL(R) [OVAL], XCCDF
>>   [XCCDF], and XDAS [XDAS].
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
>
>
>
> _______________________________________________
> 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: "Panos Kampanakis" <[email-masked]>
Date: Sun, 13 Nov 2011 18:06:25 -0500

Hi Take 

Ø  I was thinking to have either a single table that lists all the

I see your point. The fact that it is still an open issue is indeed a
limitation. I think that defining what SpecificationID can go in each class
currently at least, would make the extension clearer, especially since the
extension focuses on some standards (CVE, CEE, OVAL etc), thus mapping
classes only with suitable Specifications makes the extension more concise,
in my mind.

For my suggestion, let’s take Vulnerability that is an extension to the
Incident.Method.AdditionalData element. IODEF Method class has a
“restriction” attribute. “This     attribute indicates the disclosure
      guidelines to which the sender expects the recipient to adhere for
      the information represented in this class and its children.  This
      guideline provides no security since there are no specified
      technical means to ensure that the recipient of the document
      handles the information as the sender requested.
”
So, in the example , the Method class that nests the AttackPattern and the
Vulnerability under it can explain the restriction attribute that the Attack
Pattern can only have SpecId being CAPEC and CVE  for example.
 
<Method>
      <Description>Structured information on attack pattern, exploited
                   vulnerability, and weakness</Description>
      <AdditionalData dtype="xml">
        <iodef-sci:AttackPattern SpecificationID="CAPEC_1.6"
         AttackPatternID="CAPEC-14">
          <iodef-sci:Record>[CAPEC-formatted data]</iodef-sci:Record>
          <Reference>
            <ReferenceName>Link to Capec-14</ReferenceName>
            <URL>http://capec.mitre.org/data/definitions/14.html</URL>
          </Reference>
        </iodef-sci:AttackPattern>
        <iodef-sci:Vulnerability SpecificationID="CVE_1.0"
         VulnerabilityID="CVE-2010-3654">
          <iodef-sci:Record>[CVE-formatted data]</iodef-sci:Record>
          <iodef-sci:PlatformID SpecificationID="CPE_2.3">
            <iodef-sci:ID>[CPE ID]</iodef-sci:ID>
          </iodef-sci:PlatformID>
          <iodef-sci:Scoring SpecificationID="CVSS_2.0">
            <iodef-sci:Score>[CVSS scores]</iodef-sci:Score>
          </iodef-sci:Scoring>
        </iodef-sci:Vulnerability>
        <iodef-sci:Weakness SpecificationID="CWE_5.0"
         WeaknessID="CWE-119">
          <iodef-sci:Record>[CWE-formatted data]</iodef-sci:Record>
          <iodef-sci:Scoring SpecificationID="CWSS_0.8">
            <iodef-sci:Score>[CWSS scores]</iodef-sci:Score>
          </iodef-sci:Scoring>
        </iodef-sci:Weakness>
      </AdditionalData>
    </Method>

Rgs,

Panos

 

From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Thursday, November 10, 2011 10:17 AM
To: [email-masked]; Panos Kampanakis (pkampana)
Cc: [email-masked]
Subject: RE: [mile] Fw: New Version Notification for
draft-takahashi-mile-sci-02.txt

Hi Panos and Kathleen,

same
introduced.

Remediation?
Remediation

Take

raised?
was not included?
Panos Kampanakis
same
introduced.
Remediation?
Remediation

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

---

From: Brian Trammell <[email-masked]>
Date: Mon, 14 Nov 2011 09:57:46 +0800

Hi, Panos, all,

If I understand the proposal here correctly, it is not clear to me that this is an appropriate application of the Method@restriction attribute. Again, from 5070:

"...the disclosure guidelines to which the sender expects the recipient to adhere for the information represented in this class..."

The important word here is "disclosure". Disclosure guidelines, here, means "please feel free to share this with anyone, please don't share it with anyone, please only share it with entities with some property", and so on. 

As I understand it, we're trying instead to model "I am not going to send you certain types of data in the contents of a subelement of the element on which this attribute is set"... which in and of itself also seems kind of odd. Doesn't this belong in the schema, as opposed to in the content inline? In other words, what would it mean to send a document with an inline restriction which is violated?

With respect to schema enforcement, I haven't looked deeply into this, but it seems like using an enumerated type for SpecificationID could achieve what we want; the problem with this is that the schema would then need to incorporate the registry, or be partially automatically generated therefrom.

Best regards,

Brian (as contributor)

On Nov 14, 2011, at 7:06 AM, Panos Kampanakis wrote:

> I see your point. The fact that it is still an open issue is indeed a limitation. I think that defining what SpecificationID can go in each class currently at least, would make the extension clearer, especially since the extension focuses on some standards (CVE, CEE, OVAL etc), thus mapping classes only with suitable Specifications makes the extension more concise, in my mind.
>  
> For my suggestion, let’s take Vulnerability that is an extension to the Incident.Method.AdditionalData element. IODEF Method class has a “restriction” attribute. “This     attribute indicates the disclosure
> So, in the example , the Method class that nests the AttackPattern and the Vulnerability under it can explain the restriction attribute that the Attack Pattern can only have SpecId being CAPEC and CVE  for example.
>  
> <Method>
> Subject: RE: [mile] Fw: New Version Notification for draft-takahashi-mile-sci-02.txt
>  
> Hi Panos and Kathleen,
>

---

From: <[email-masked]>
Date: Sun, 13 Nov 2011 21:26:16 -0500

Hello,

In addition to Brian's comments, while the use of restriction within IODEF and any extension to IODEF do not provide any security (these are just common formats to exchange data), restriction is used as a data marker in RFC6045-bis.   The restriction option as defined in RFC5070 is leveraged by RID [RFC6045-bis] to act according to policy to encrypt either a class or an entire document that is marked confidential (private or need-to-know) using XML encryption.  RID can use this tag when embedded in any extensions as well.  Additional markers for data types will be added in the Data Marker draft, but those have not yet been defined (just discussed a bit on the mailing list).

Thanks,
Kathleen
________________________________________
From: Brian Trammell [[email-masked]]
Sent: Sunday, November 13, 2011 8:57 PM
To: Panos Kampanakis
Cc: 'Takeshi Takahashi'; Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] Fw: New Version Notification        for draft-takahashi-mile-sci-02.txt

Hi, Panos, all,

Best regards,

Brian (as contributor)

---

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

Hi Panos, Brian, and Kathleen,

Thank you for your kind discussion.

I understand the concern you (Panos) raised.
Then, how about this approach?

We provide tables describing the mapping between current existing major
specifications and the classes in the appendix II of the draft.
Let me attach the document with newly created appendix. (See Section 10,
Appendix II)

I hope this approach could solve your concern.

Sincerely,
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 11:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] Fw: New Version Notification for

Hello,

In addition to Brian's comments, while the use of restriction within IODEF
and any extension to IODEF do not provide any security (these are just
common formats to exchange data), restriction is used as a data marker in
RFC6045-bis.   The restriction option as defined in RFC5070 is leveraged by
RID [RFC6045-bis] to act according to policy to encrypt either a class or an
entire document that is marked confidential (private or need-to-know) using
XML encryption.  RID can use this tag when embedded in any extensions as
well.  Additional markers for data types will be added in the Data Marker
draft, but those have not yet been defined (just discussed a bit on the
mailing list).

Thanks,
Kathleen

Hi, Panos, all,

If I understand the proposal here correctly, it is not clear to me that this
is an appropriate application of the Method@restriction attribute. Again,
from 5070:

"...the disclosure guidelines to which the sender expects the recipient to
adhere for the information represented in this class..."

The important word here is "disclosure". Disclosure guidelines, here, means
"please feel free to share this with anyone, please don't share it with
anyone, please only share it with entities with some property", and so on.

As I understand it, we're trying instead to model "I am not going to send
you certain types of data in the contents of a subelement of the element on
which this attribute is set"... which in and of itself also seems kind of
odd. Doesn't this belong in the schema, as opposed to in the content inline?
In other words, what would it mean to send a document with an inline
restriction which is violated?

With respect to schema enforcement, I haven't looked deeply into this, but
it seems like using an enumerated type for SpecificationID could achieve
what we want; the problem with this is that the schema would then need to
incorporate the registry, or be partially automatically generated therefrom.

Best regards,

Brian (as contributor)

On Nov 14, 2011, at 7:06 AM, Panos Kampanakis wrote:

> specifications (as described in the current draft), or multiple tables 
> that list applicable specifications for each class (i.e., creating 
> separate tables for Attack Pattern and Vulnerability and Weakness 
> classes), Though this is still an open issue, I personally preferred 
> to have a single table that lists all the specifications since one 
> specification may be used by multiple classes.
> > 1) Some extended classes apply only to some Specifications. For 
> > example, a Vulnerability class can be OVAL, CVRF spec but not CEE or 
> > OCIL. In the
> same
> > manner an Event Report class cannot have a SpecificationID of 
> > CAPEC_1.6 or OVAL. A PlatformID class can only be CPE spec. So, the 
> > SpecificationID can be restricted to some values only for each 
> > class, which if added will help clarify what standard/spec (CEE, 
> > CPE, etc) applies to each class
> introduced.
> > The restriction can be stated in the restriction attribute of parent 
> > class of the introduced extended class.
>
> specifications (as described in the current draft), or multiple tables 
> that list applicable specifications for each class (i.e., creating 
> separate tables for Attack Pattern and Vulnerability and Weakness 
> classes), Though this is still an open issue, I personally preferred 
> to have a single table that lists all the specifications since one 
> specification may be used by multiple classes.
> As you pointed out, the current design may allow a user to put CVE 
> inside AttackPattern class, for instance.
> I know it is not the expected usage, but I left it as an usage issues, 
> and the draft didn't restrict on that.
> sentence: "The value should be chosen from the IDs listed in Figure 1, 
> such as CAPEC_1.6."
>
> Could you elaborate more on how to use the restriction attribute to 
> maintain the future-proof design of the table?
> Maybe there could be a good solution that enables us to have single 
> table, and could properly limit the choice of specifications for each 
> class, and maintains future extensibility?
>
> > 3) How do the extended classes incorporate XCCDF's  
> > <xccdf:Benchmark> element and CCE? What class would be suitable for 
> > these? Is it
> Remediation?
> > 4) Does OVAL fit in the Remediation class? OVAL provides 
> > vulnerability description and machine state for vuln assessments, I 
> > wonder if
> Remediation
> Paul has also raised this Remediation class issue before, and the 
> issue was unsolved yet.
> I am not sure whether "Remediation" is a good term for the class, but 
> in the future, I am hoping to see some language or data providing some 
> > 1) Some extended classes apply only to some Specifications. For 
> > example, a Vulnerability class can be OVAL, CVRF spec but not CEE or 
> > OCIL. In the
> same
> > manner an Event Report class cannot have a SpecificationID of 
> > CAPEC_1.6 or OVAL. A PlatformID class can only be CPE spec. So, the 
> > SpecificationID can be restricted to some values only for each 
> > class, which if added will help clarify what standard/spec (CEE, 
> > CPE, etc) applies to each class
> introduced.
> > The restriction can be stated in the restriction attribute of parent 
> > class of the introduced extended class.
> >
> > 3) How do the extended classes incorporate XCCDF's  
> > <xccdf:Benchmark> element and CCE? What class would be suitable for 
> > these? Is it
> Remediation?
> > 4) Does OVAL fit in the Remediation class? OVAL provides 
> > vulnerability description and machine state for vuln assessments, I 
> > wonder if
> Remediation
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Takeshi Takahashi

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 14 Nov 2011 12:38:25 +0900

And the schema in the draft will be modified, following the suggestion from
Brian.
Thank you, Brian, for the suggestion.

Sincerely,
Take

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 12:23 PM
To: [email-masked]'; [email-masked]';
[email-masked]'
Cc: [email-masked]'

Sincerely,
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 14, 2011 11:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] Fw: New Version Notification for

Hello,

Thanks,
Kathleen

Hi, Panos, all,

Best regards,

Brian (as contributor)

> > Of

---

From: "Panos Kampanakis" <[email-masked]>
Date: Mon, 14 Nov 2011 16:23:39 -0500

I see Brian's points, they make sense.
Appendix II for addressing the issues are a good idea in my opinion.

Rgs,
Panos

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Sunday, November 13, 2011 10:23 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mile] Fw: New Version Notification for

Sincerely,
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 14, 2011 11:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] Fw: New Version Notification for

Hello,

Thanks,
Kathleen

Hi, Panos, all,

Best regards,

Brian (as contributor)

---

From: <[email-masked]>
Date: Mon, 14 Nov 2011 18:04:10 -0500

Looks good to me also; the tables in Appendix II should become the initial contents of an IANA registry for each class.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Panos Kampanakis
> Sent: Monday, November 14, 2011 4:24 PM
> To: 'Takeshi Takahashi'; Moriarty, Kathleen; [email-masked]
> Cc: [email-masked]
> > For my suggestion, let's take Vulnerability that is an extension to
> > the
> "restriction" attribute. "This     attribute indicates the disclosure
> > "

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 15 Nov 2011 09:56:28 +0900

Hi David and all,

Thank you for the email.
I think my previous email may have caused some confusion, sorry, but I
personally still prefer to have a single table for all the specification,
rather than having separate tables for each specification.
So, the table in Figure 1 (Sec 4.1) would be the table to be registered in
the IANA.
In this way, some other future IETF drafts could use the table.

The appendix II provides separate tables to provide usage guideline of
specifications for each class by showing which specifications could be used
by which classes.
Since appendix is a non-normative part of the draft (correct me if I am
wrong), I've added several potential works in the table. (the table in
Figure 1 does not have these works.)

Let me raise this issue at the session.

Thank you.
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, November 15, 2011 8:04 AM
To: [email-masked]
Subject: Re: [mile] Fw: New Version Notification for
draft-takahashi-mile-sci-02.txt

Looks good to me also; the tables in Appendix II should become the initial
contents of an IANA registry for each class.

Thanks,
--David

> Of Panos Kampanakis
> We provide tables describing the mapping between current existing 
> major specifications and the classes in the appendix II of the draft.
> Let me attach the document with newly created appendix. (See Section 
> 10, Appendix II)
>
> In addition to Brian's comments, while the use of restriction within 
> IODEF and any extension to IODEF do not provide any security (these 
> are just common formats to exchange data), restriction is used as a data
marker in
> RID [RFC6045-bis] to act according to policy to encrypt either a class 
> or an entire document that is marked confidential (private or 
> need-to-know) using XML encryption.  RID can use this tag when 
> embedded in any extensions as well.  Additional markers for data types 
> will be added in the Data Marker draft, but those have not yet been 
> defined (just discussed a bit on the mailing list).
>
> Thanks,
> Kathleen
> If I understand the proposal here correctly, it is not clear to me 
> that this is an appropriate application of the Method@restriction 
> attribute. Again, from 5070:
>
> "...the disclosure guidelines to which the sender expects the 
> recipient to adhere for the information represented in this class..."
>
> The important word here is "disclosure". Disclosure guidelines, here, 
> means "please feel free to share this with anyone, please don't share 
> it with anyone, please only share it with entities with some property",
and so on.
>
> As I understand it, we're trying instead to model "I am not going to 
> send you certain types of data in the contents of a subelement of the 
> element on which this attribute is set"... which in and of itself also 
> seems kind of odd. Doesn't this belong in the schema, as opposed to in the
content inline?
> With respect to schema enforcement, I haven't looked deeply into this, 
> but it seems like using an enumerated type for SpecificationID could 
> achieve what we want; the problem with this is that the schema would 
> then need to incorporate the registry, or be partially automatically
generated therefrom.
> > specifications (as described in the current draft), or multiple 
> > tables that list applicable specifications for each class (i.e., 
> > creating separate tables for Attack Pattern and Vulnerability and 
> > Weakness classes), Though this is still an open issue, I personally 
> > preferred to have a single table that lists all the specifications 
> > since one specification may be used by multiple classes.
> limitation. I think that defining what SpecificationID can go in each 
> class currently at least, would make the extension clearer, especially 
> since the extension focuses on some standards (CVE, CEE, OVAL etc), 
> thus mapping classes only with suitable Specifications makes the 
> extension more concise, in my mind.
> >
> Vulnerability under it can explain the restriction attribute that the 
> Attack Pattern can only have SpecId being CAPEC and CVE  for example.
> >
> > <Method>
> > > example, a Vulnerability class can be OVAL, CVRF spec but not CEE 
> > > or OCIL. In the
> > same
> > > CAPEC_1.6 or OVAL. A PlatformID class can only be CPE spec. So, 
> > > the SpecificationID can be restricted to some values only for each 
> > > The restriction can be stated in the restriction attribute of 
> > > parent class of the introduced extended class.
> >
> > specifications (as described in the current draft), or multiple 
> > tables that list applicable specifications for each class (i.e., 
> > creating separate tables for Attack Pattern and Vulnerability and 
> > Weakness classes), Though this is still an open issue, I personally 
> > preferred to have a single table that lists all the specifications 
> > since one specification may be used by multiple classes.
> > I know it is not the expected usage, but I left it as an usage 
> > issues, and the draft didn't restrict on that.
> > The draft only describes some typical specification names used by 
> > each class.
> > sentence: "The value should be chosen from the IDs listed in Figure 
> > 1, such as CAPEC_1.6."
> >
> > table, and could properly limit the choice of specifications for 
> > each class, and maintains future extensibility?
> >
> > > <xccdf:Benchmark> element and CCE? What class would be suitable 
> > > for these? Is it
> > Remediation?
> > > vulnerability description and machine state for vuln assessments, 
> > > I wonder if
> > Remediation
> > I am not sure whether "Remediation" is a good term for the class, 
> > but in the future, I am hoping to see some language or data 
> > providing some countermeasure or remediation.
> > Let me prepare some slides and discuss these issues at the meeting 
> > in Taipei.
> >
> > > example, a Vulnerability class can be OVAL, CVRF spec but not CEE 
> > > or OCIL. In the
> > same
> > > CAPEC_1.6 or OVAL. A PlatformID class can only be CPE spec. So, 
> > > the SpecificationID can be restricted to some values only for each 
> > > The restriction can be stated in the restriction attribute of 
> > > parent class of the introduced extended class.
> > >
> > > <xccdf:Benchmark> element and CCE? What class would be suitable 
> > > for these? Is it
> > Remediation?
> > > vulnerability description and machine state for vuln assessments, 
> > > I wonder if
> > Remediation
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Takeshi Takahashi

---

From: <[email-masked]>
Date: Mon, 14 Nov 2011 20:20:17 -0500

Hi Take,

> So, the table in Figure 1 (Sec 4.1) would be the table to be registered in the IANA.

In that case, it would be good to add a list of the applicable classes for each specification to that table.  I agree with the original concern that use of each specification should be restricted to the applicable class (or classes), and would like to see that expressed in normative text.

Thanks,
--David

> Sent: Monday, November 14, 2011 7:56 PM
> To: Black, David; [email-masked]
> > > > Behalf Of