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

From: <[email-masked]>
Date: Fri, 6 Jul 2012 12:52:58 -0400

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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 9 Jul 2012 16:38:33 +0900

Hi Kathleen,

Thank you for your kind comments.

> In the paragraph right before the start of section 4, there is a typo in
the first word, it should say “Another”.
Thank you for that :)

> In figure 1, there are two bars for each of the included classes under
EventData, is that correct?
The original IODEF draft had more bars for that, but the extension couldn't
have more than two bars for that to fit the Fig. 1 in the draft.
I hope it is ok.

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

Yes, the section 4.3.1 defines the AttackPattern class as an element of
AdditionalData class, but AdditionalData class can appear everywhere in the
IODEF document.
With the sentence, I intends to say that the expected location of the
AttackPattern element is under the AdditionalData of the Method class, as
described in Figure 1.

In my understanding, people have discussed on the MILE mailing list and
wished to identify the expected location of the newly defined class.

Yes, it is optional, since not every response team can provide structured
attack pattern information when sending IODEF document. (maybe I've
misunderstood your question?)

Regarding the discussion point, let me send another email with different
title.

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, 

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

---

From: "Panos Kampanakis" <[email-masked]>
Date: Tue, 10 Jul 2012 14:35:43 -0400

Hi Kathleen,

Maybe I didn't completely get the suggestion, but why would creating a new
IODEF Reference Class with a predefined IANA table table fall within SCI's
scope? Is it only in order to pre-define CVE, CEE etc to be included in the
references in SCI? I think that makes sense. 

But I believe that., as Take suggested, if the Reference Class is updated in
IODEF then the new Reference Class can be used in SCI, after the "allowed
reference item" new IANA table is defined.

Rgs,

Panos

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, July 06, 2012 12:53 PM
To: [email-masked]; [email-masked]
Subject: [mile] Nits on SCI draft and point for discussion

Hi Take, 

In the paragraph right before the start of section 4, there is a typo in the
first word, it should say "Another".

Discussion Point:

Thank you!

Kathleen

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 08:42:56 -0400

Hi Panos,

Thanks for weighing in!  I am not quite clear on your response, so let me try again to see if I can better explain the questions I was hoping to get consensus on from the WG.  If you and others could clarify your preferences in approach for these options, it would be very helpful.  My questions are based on the current proposal in the SCI draft and to figure out if that is right or if we want to do this another way.

We will need guidance to be written somewhere to establish a consistent way to represent enumerated values.  We can either do this in the SCI draft in a new section or in a separate draft as Adam Montville proposed a while back.  Getting working group consensus on how we want to represent these values and if we should do this in the SCI draft or another draft would be good in addition to consensus on where we think the values should be placed (in the IODEF Reference class or in the Reference classes embedded in the extensions of the SCI draft as is currently proposed in the draft).  The update to IODEF would handle any changes to the Reference class as you clearly stated.

I think there are a few other points we will need to make sure we have consensus on from the SCI draft to help wrap it up, but let's see if we can tackle these first.

Thank you!
Kathleen

From: Panos Kampanakis [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 2:36 PM
To: Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Nits on SCI draft and point for discussion

Hi Kathleen,

Maybe I didn't completely get the suggestion, but why would creating a new IODEF Reference Class with a predefined IANA table table fall within SCI's scope? Is it only in order to pre-define CVE, CEE etc to be included in the references in SCI? I think that makes sense.
But I believe that., as Take suggested, if the Reference Class is updated in IODEF then the new Reference Class can be used in SCI, after the "allowed reference item" new IANA table is defined.

Rgs,
Panos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, July 06, 2012 12:53 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [mile] Nits on SCI draft and point for discussion

Hi Take,

Discussion Point:

Thank you!
Kathleen

Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | [email-masked]<mailto:[email-masked]>  | EMC Corporation

---

From: "Panos Kampanakis" <[email-masked]>
Date: Wed, 11 Jul 2012 11:13:51 -0400

Now I understand, and remember the discussion.

My personal opinion is that the way of represented the enumerated values
should be a separate document. SCI defines the extensions, but the
enumerated value representations could better be served separately and used
in other models too. Also, I think these changes should not apply to IODEF
Reference classes, but to the SCI Reference classes. This falls within this
draft's scope (extensions for structure cyber security). Doing it in IODEF I
think may fall out of scope for this work.

Thank you,

Panos

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2012 8:43 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Nits on SCI draft and point for discussion

Hi Panos,

Thanks for weighing in!  I am not quite clear on your response, so let me
try again to see if I can better explain the questions I was hoping to get
consensus on from the WG.  If you and others could clarify your preferences
in approach for these options, it would be very helpful.  My questions are
based on the current proposal in the SCI draft and to figure out if that is
right or if we want to do this another way.

We will need guidance to be written somewhere to establish a consistent way
to represent enumerated values.  We can either do this in the SCI draft in a
new section or in a separate draft as Adam Montville proposed a while back.
Getting working group consensus on how we want to represent these values and
if we should do this in the SCI draft or another draft would be good in
addition to consensus on where we think the values should be placed (in the
IODEF Reference class or in the Reference classes embedded in the extensions
of the SCI draft as is currently proposed in the draft).  The update to
IODEF would handle any changes to the Reference class as you clearly stated.

I think there are a few other points we will need to make sure we have
consensus on from the SCI draft to help wrap it up, but let's see if we can
tackle these first.

Thank you!

Kathleen

From: Panos Kampanakis [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2012 2:36 PM
To: Moriarty, Kathleen; [email-masked]; [email-masked]
Subject: RE: Nits on SCI draft and point for discussion

Hi Kathleen,

Rgs,

Panos

Hi Take, 

Discussion Point:

Thank you!

Kathleen

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 20 Jul 2012 14:08:30 -0400

I agree, but I think we should go further than what you are suggesting.  We should identify, in a separate document (doc A), a method to identify an identifier format and namespace using an IANA registry.  We should then in SCI and/or IODEF define how the namespace and ids are used relative to the registry defined in doc A.  Think of this as an encoding of the information that doc A specifies.  This would provide a foundation for other efforts to define how to use identifier formats described by doc A.  This will be of great use to future SACM efforts at minimum.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Panos Kampanakis
Sent: Wednesday, July 11, 2012 11:14 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] Nits on SCI draft and point for discussion

My personal opinion is that the way of represented the enumerated values should be a separate document. SCI defines the extensions, but the enumerated value representations could better be served separately and used in other models too. Also, I think these changes should not apply to IODEF Reference classes, but to the SCI Reference classes. This falls within this draft's scope (extensions for structure cyber security). Doing it in IODEF I think may fall out of scope for this work.

Thank you,
Panos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, July 11, 2012 8:43 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Nits on SCI draft and point for discussion

Hi Panos,

Thank you!
Kathleen

Hi Kathleen,

Rgs,
Panos

Hi Take,

Discussion Point:

Thank you!
Kathleen

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 20 Jul 2012 18:44:03 +0000

Makes sense.
Panos

From: Waltermire, David A. [mailto:[email-masked]]
Sent: Friday, July 20, 2012 2:08 PM
To: Panos Kampanakis (pkampana); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] Nits on SCI draft and point for discussion

Sincerely,
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Panos Kampanakis
Sent: Wednesday, July 11, 2012 11:14 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Nits on SCI draft and point for discussion

Thank you,
Panos

Hi Panos,

Thank you!
Kathleen

Hi Kathleen,

Rgs,
Panos

Hi Take,

Discussion Point:

Thank you!
Kathleen

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Sat, 21 Jul 2012 09:57:46 +0900

Hi all,

I agree with both of you on that we intend to define proper method to embed
identifier and namespace.
I was thinking that the SCI draft could use the draft doc A for describing
SCI classes.
I think that was what we have discussed in Paris.

On the other hand, I think we need to discuss whether we design doc A based
on the Reference class or not.
Allow me the repetition I’ve mentioned in the mailing list before:

If we define draft doc A based on IODEF reference class, the structure
cannot be used within the SCI draft as it is.
(pros and cons are described in former emails.)
But if the community thinks that is better idea than other options, that is
fine. 
In that case, I would suggest to define all of the SCI classes by extending
the newly defined Reference class, instead of allowing doc A and SCI draft
to have different ways of embedding the identifiers.

The direction of how to define the draft doc A is the bottleneck of SCI
draft work, and I hope we could agree upon clear direction on this by the
end of the Vancouver meeting.

Thank you.
Take

From: Panos Kampanakis (pkampana) [mailto:[email-masked]] 
Sent: Saturday, July 21, 2012 3:44 AM
To: Waltermire, David A.; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [mile] Nits on SCI draft and point for discussion

Makes sense.
Panos

From: Waltermire, David A. [mailto:[email-masked]] 
Sent: Friday, July 20, 2012 2:08 PM
To: Panos Kampanakis (pkampana); [email-masked];
[email-masked]; [email-masked]
Subject: RE: [mile] Nits on SCI draft and point for discussion

I agree, but I think we should go further than what you are suggesting.  We
should identify, in a separate document (doc A), a method to identify an
identifier format and namespace using an IANA registry.  We should then in
SCI and/or IODEF define how the namespace and ids are used relative to the
registry defined in doc A.  Think of this as an encoding of the information
that doc A specifies.  This would provide a foundation for other efforts to
define how to use identifier formats described by doc A.  This will be of
great use to future SACM efforts at minimum.

Sincerely,
Dave

Panos Kampanakis

draft’s scope (extensions for structure cyber security). Doing it in IODEF I

Thank you,
Panos

Hi Panos,

I think there are a few other points we will need to make sure we have
consensus on from the SCI draft to help wrap it up, but let’s see if we can
tackle these first.

Thank you!
Kathleen

Hi Kathleen,

Maybe I didn’t completely get the suggestion, but why would creating a new
IODEF Reference Class with a predefined IANA table table fall within SCI’s
scope? Is it only in order to pre-define CVE, CEE etc to be included in the
references in SCI? I think that makes sense. 
But I believe that., as Take suggested, if the Reference Class is updated in
IODEF then the new Reference Class can be used in SCI, after the “allowed
reference item” new IANA table is defined.

Rgs,
Panos

Hi Take, 

 

 
Discussion Point:

 
 
Thank you!
Kathleen

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Sun, 22 Jul 2012 13:58:24 +0000

I think, as Dave also suggested, that doc A doesn't need to be based on IODEF Ref Class or SCI. It will just define the identifier format and namespace. Then that can be used in IODEF's Ref Class, SCI's References or other places.

Panos

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Friday, July 20, 2012 8:58 PM
To: Panos Kampanakis (pkampana); 'Waltermire, David A.'; [email-masked]; [email-masked]
Subject: RE: [mile] Nits on SCI draft and point for discussion

Hi all,

I agree with both of you on that we intend to define proper method to embed identifier and namespace.
I was thinking that the SCI draft could use the draft doc A for describing SCI classes.
I think that was what we have discussed in Paris.

On the other hand, I think we need to discuss whether we design doc A based on the Reference class or not.
Allow me the repetition I've mentioned in the mailing list before:

If we define draft doc A based on IODEF reference class, the structure cannot be used within the SCI draft as it is.
(pros and cons are described in former emails.) But if the community thinks that is better idea than other options, that is fine. 
In that case, I would suggest to define all of the SCI classes by extending the newly defined Reference class, instead of allowing doc A and SCI draft to have different ways of embedding the identifiers.

The direction of how to define the draft doc A is the bottleneck of SCI draft work, and I hope we could agree upon clear direction on this by the end of the Vancouver meeting.

Thank you.
Take

From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Saturday, July 21, 2012 3:44 AM
To: Waltermire, David A.; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] Nits on SCI draft and point for discussion

Makes sense.
Panos

Sincerely,
Dave

Thank you,
Panos

Hi Panos,

Thank you!
Kathleen

Hi Kathleen,

Rgs,
Panos

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 06, 2012 12:53 PM
To: [email-masked]; [email-masked]
Subject: [mile] Nits on SCI draft and point for discussion

Hi Take, 

 

 
Discussion Point:

 
 
Thank you!
Kathleen

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Sun, 22 Jul 2012 23:14:22 +0900

Thank you for your kind clarification.
I agree on that as well.

Sincerely,
Take

> Sent: Sunday, July 22, 2012 10:58 PM
> To: Takeshi Takahashi; 'Waltermire, David A.';
> [email-masked]; [email-masked]
> I think, as Dave also suggested, that doc A doesn't need to be based on
> IODEF Ref Class or SCI. It will just define the identifier format and
> namespace. Then that can be used in IODEF's Ref Class, SCI's References
> or other places.
> 
> Panos
> 
> 
> 
> 
> (pros and cons are described in former emails.) But if the community
thinks
> that is better idea than other options, that is fine.
> draft work, and I hope we could agree upon clear direction on this by
> the end of the Vancouver meeting.
> 
> Thank you.
> Take
> 
> 
> 
> should identify, in a separate document (doc A), a method to identify
> an identifier format and namespace using an IANA registry.  We should
> then in SCI and/or IODEF define how the namespace and ids are used
relative
> to the registry defined in doc A.  Think of this as an encoding of the
> information that doc A specifies.  This would provide a foundation for
> other efforts to define how to use identifier formats described by doc
> A.  This will be of great use to future SACM efforts at minimum.
> 
> Sincerely,
> Dave
> 
> enumerated value representations could better be served separately and
> used in other models too. Also, I think these changes should not apply
> to IODEF Reference classes, but to the SCI Reference classes. This falls
> within this draft's scope (extensions for structure cyber security).
> Doing it in IODEF I think may fall out of scope for this work.
> 
> Thank you,
> Panos
> 
> 
> Thanks for weighing in!  I am not quite clear on your response, so let
> me try again to see if I can better explain the questions I was hoping
> to get consensus on from the WG.  If you and others could clarify your
> preferences in approach for these options, it would be very helpful.  My
> questions are based on the current proposal in the SCI draft and to figure
> out if that is right or if we want to do this another way.
> 
> We will need guidance to be written somewhere to establish a consistent
> way to represent enumerated values.  We can either do this in the SCI
> draft in a new section or in a separate draft as Adam Montville proposed
> a while back. Getting working group consensus on how we want to represent
> these values and if we should do this in the SCI draft or another draft
> would be good in addition to consensus on where we think the values should
> be placed (in the IODEF Reference class or in the Reference classes
> embedded in the extensions of the SCI draft as is currently proposed in
> the draft).  The update to IODEF would handle any changes to the Reference
> class as you clearly stated.
> 
> consensus on from the SCI draft to help wrap it up, but let's see if we
> can tackle these first.
> 
> Thank you!
> Kathleen
> 
> 
> 
> Maybe I didn't completely get the suggestion, but why would creating a
> new IODEF Reference Class with a predefined IANA table table fall within
> SCI's scope? Is it only in order to pre-define CVE, CEE etc to be included
> in the references in SCI? I think that makes sense.
> But I believe that., as Take suggested, if the Reference Class is updated
> in IODEF then the new Reference Class can be used in SCI, after the
"allowed
> In the paragraph right before the start of section 4, there is a typo
> in the first word, it should say "Another".
> 
optional,
> 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.
> 
> 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
>