Subject: Re: [mile] Nits on SCI draft and point for discussion: discussion on enumeration ID

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 9 Jul 2012 17:09:55 +0900

Hi Kathleen and all

Again, thank you for raising discussion for the SCI draft.

> In IODEF, the Method Class includes a Reference Class.
> I know that you can include just a CVE number using the SCI draft, but it
requires the use of the new Vulnerability Class (or other extended class
with the embedded Reference class from IODEF).
> I think it would be cleaner to use the Reference class in IODEF when the
purpose is just to include a CVE number and URL or other enumerated values
directly into the Reference class.
> The part missing from the IODEF draft is a an exact specification on how
to include the enumerations in a standard way.
> The discussion by Adam and Dave provided an option everyone seemed to
agree upon, the preferred option required a change to IODEF, which will be
possible soon (there were options do not require that modification). 

Well, I believe I have never said that defining new Reference class is bad
idea. (or at least, I had no intention to say so.)
I actually think it is one good option.

My point was that having two ways of describing enumerated ID is not that
elegant, but if it was people's choice, I am also happy to go for that.

> If people agree, can we update your draft to include that method and make
a clear distinction from when you include a full XML document and when you
just include an enumerated value, like for CVE using the IODEF method class
and a format specified in the SCI draft for that?
> This would also require a second IANA table as it would not require the
use of an SCI extension and would specify the format to represent the
enumerated value and included URL.

So, you would prefer to remove the function of including enumeration IDs
from the SCI draft?
If so, I am not sure whether it is a good idea or not.
If SCI classes are unable to include enumeration IDs, sometimes
vulnerability information can be found in both Reference class and
Vulnerability class, in this case, for instance.
I think it is a bit messy.

Thus, my suggestion is that SCI draft waits until the new iodef draft is
ratified.
Then the draft can create new classes such as Vulnerability and
AttackPattern "by extending the newly defined Reference class".
How does it sound? (I've posted this opinion to the MILE mailing list
before.)
I would like to hear comment on this option.

> I would like to hear opinions on the SCI method versus creating a second
table that allows the use of the IODEF Reference class directly (no
extension required).
> The table would explicitly state how to format the reference to the
enumerated values and would allow any enumerated value (of a registered
format) to be included directly in the reference class.

Having two IANA tables could be seen as a drawback, but I think it is not a
big deal, IMHO.

Thank you, for your kind discussion, and I am looking forward to hearing
people's opinion.

Sincerely,
Take

From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, July 07, 2012 1:53 AM
To: [email-masked]; [email-masked]
Subject: Nits on SCI draft and point for discussion

Hi Take, 
 
I am reading through the SCI draft again and noticed a few nits:
 
In the paragraph right before the start of section 4, there is a typo in the
first word, it should say “Another”.
 
In figure 1, there are two bars for each of the included classes under
EventData, is that correct?
 
Section 4.3.1:  Says the following:
“It is recommended that Method class SHOULD contain one or more of the
   extension elements whenever available.”
 
Can you explain the reasoning?  It does only say should, so it is optional,
but I would like to understand the reason for the statement.
 
Discussion Point:
 
In IODEF, the Method Class includes a Reference Class.  I know that you can
include just a CVE number using the SCI draft, but it requires the use of
the new Vulnerability Class (or other extended class with the embedded
Reference class from IODEF).  I think it would be cleaner to use the
Reference class in IODEF when the purpose is just to include a CVE number
and URL or other enumerated values directly into the Reference class.  The
part missing from the IODEF draft is a an exact specification on how to
include the enumerations in a standard way.  The discussion by Adam and Dave
provided an option everyone seemed to agree upon, the preferred option
required a change to IODEF, which will be possible soon (there were options
do not require that modification).  
 
If people agree, can we update your draft to include that method and make a
clear distinction from when you include a full XML document and when you
just include an enumerated value, like for CVE using the IODEF method class
and a format specified in the SCI draft for that?  This would also require a
second IANA table as it would not require the use of an SCI extension and
would specify the format to represent the enumerated value and included URL.
 
I would like to hear opinions on the SCI method versus creating a second
table that allows the use of the IODEF Reference class directly (no
extension required).  The table would explicitly state how to format the
reference to the enumerated values and would allow any enumerated value (of
a registered format) to be included directly in the reference class.
 
Thank you!
Kathleen
 
Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO |
617-851-5807 | [email-masked]  | EMC Corporation