Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 9 Aug 2011 12:49:48 +0900

Thank you for those of you who kindly gave me off-line messages .

Let me share the draft with some minor modifications.

Sincerely,
Take

2011/8/5 Takeshi Takahashi <[email-masked]>:

> Dear all,

> The attached is the tentative version of the draft prepared based on the

> comments I've received in this mailing list (Thanks a lot for that).

> It would be great if you could provide some comments on Clause 4, where
the

> IODEF extension is defined.

> As you know, there are many ways to embed structured information (e.g. CVE

> and CAPEC) in IODEF since IODEF is designed to be very flexible.

> Thus, I would be happy to change and develop the draft further based on
your

> comments.

> I would like to welcome any comments on that.

> By the way, I will be on vacation, thus my response might be slow, sorry
for

> the inconvenience.

> Take

> PS: I've changed the title of the email.

> 2011/7/29 <[email-masked]>

>> Thank you, the approach sounds good, especially since it is in use today

>> by at least the Research and Education ISAC.  Do others have opinions on

>> the proposal here?

>> Thanks for writing the first draft Take!

>> Best regards,

>> Kathleen

>> ________________________________________

>> From: [email-masked] [[email-masked]] On Behalf Of Takeshi

>> Takahashi [[email-masked]]

>> Sent: Friday, July 29, 2011 9:20 AM

>> To: 'Martin, Robert A.'; [email-masked]

>> Cc: [email-masked]

>> Subject: Re: [mile] Updated presentation from Side meeting

>> Thank you, Bob, for the email.

>> I also like Tom's suggestion very much.

>> Let me work on the "draft" of the draft for a while, then come back to
you

>> later.

>> Take

>> -----Original Message-----

>> From: Martin, Robert A. [mailto:[email-masked]]

>> Sent: Friday, July 29, 2011 9:10 AM

>> To: [email-masked]

>> Cc: [email-masked]; [email-masked];

>> [email-masked]; [email-masked]

>> Subject: Re: [mile] Updated presentation from Side meeting

>> I also like how this is evolving.

>> I think, as Tom's suggestions pointed, that any and all of the useful

>> types

>> of information that can help with understanding, diagnosing, and getting

>> ahead of an incident should be added but for now we should focus on those

>> the most established and well articulated.

>> This can be the compliance/patch/configuration/platform information

>> related

>> to the SCAP use case, or event signature/attack pattern/traffic

>> characteristics from events, or the vulnerability/threat characterization

>> space.

>> I look forward to Taki's draft to see how he suggests positioning these

>> concepts.

>> Bob

>> On 7/28/11 10:13 PM, [email-masked] wrote:

>> > I like where this is headed.

>> > Thanks Takeshi.  I look forward to your draft. It will give us
something

>> real to discuss. I appreciate you jumping in and getting this started.

>> > One question that I am not clear on. What do we envision as the actual

>> set

>> of deliverables?  From and SCAP related perspective, are we looking at a

>> single draft covering all the extensions?

>> > Kent

>> > Kent Landfield

>> > Director Content Strategy, Architecture and Standards

>> > McAfee, Inc.

>> > 5000 Headquarters Dr.

>> > Plano, Texas 75024

>> > Direct: +1.972.963.7096

>> > Mobile: +1.817.637.8026

>> > Web: www.mcafee.com<http://www.mcafee.com/>

>> > From: Takeshi

>> > Takahashi<[email-masked]<mailto:[email-masked]

>> > o.jp>>

>> > Date: Thu, 28 Jul 2011 18:21:56 -0500

>> > To:

>> > "[email-masked]<mailto:[email-masked]>"<Thomas.M

>> > [email-masked]<mailto:[email-masked]>>,

>> > "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:we

>> > [email-masked]>>,

>> > "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]

>> > rg>>

>> > Subject: Re: [mile] Updated presentation from Side meeting

>> > Thank you for the email, Tom.

>> > So, here is what the draft needs to describe (if I understand Wes and

>> > Tom correctly).

>> > The draft should define ext-dtype (an attribute of AdditionalData

>> > Class) to identify the information type, rather than defining new

>> > class under AdditionalData.

>> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec,

>> > ext-cvss, ext-cwss, In this way, we could keep the change minimal and

>> > could easily embed various structured information (CVE etc.) in the

>> > EventData.Record.RecordData.AdditionalData field.

>> > Then "should" statement should be carefully placed in the text of

>> > relevant class.

>> > I'll prepare some draft so that we could discuss and advance further.

>> > Take

>> > -----Original Message-----

>> > From: [email-masked]<mailto:[email-masked]>

>> > [mailto:[email-masked]] On Behalf Of

>> > [email-masked]<mailto:[email-masked]>

>> > Sent: Thursday, July 28, 2011 6:28 PM

>> > To: [email-masked]<mailto:[email-masked]>;

>> > [email-masked]<mailto:[email-masked]>

>> > Subject: Re: [mile] Updated presentation from Side meeting

>> > I think this approach makes more sense. One of the things I think

>> > could be helpful is to have a number of SHOULD statements further

>> > describing the possible types of other documents that would be

>> > expected to ride under the AdditionalData elements of each class (not

>> just

>> EventData).

>> > What I'm thinking of looks like this (very unpolished):

>> > "The Method Class:AdditionalData class SHOULD contain data elements

>> > that describe the methods, tools or techniques employed to cause the

>> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the

>> > method such as CVSS, CWSS, or CCE."

>> > "The Expectation Class[...] SHOULD contain data elements which

>> > describe configuration changes, detection heuristics, or [* (legal

>> > authorization?)] to assist in executing or implementing the requested

>> > action, such as XCCDF, OCIL, OVAL, etc"

>> > This could go towards encouraging better or at least more consistent

>> > use of "boundary objects" in the substance of incident reports. I

>> > could also go on about greater automation and such but that's probably

>> > out of scope for this e-mail.

>> > - Tom Millar, US-CERT

>> > [email-masked]<mailto:[email-masked]>

>> > BB: [email-masked]<mailto:[email-masked]>  /

>> > 202-631-1915

>> > 24x7: [email-masked]<mailto:[email-masked]>  / 888-282-0870

>> > -----Original Message-----

>> > From: [email-masked]<mailto:[email-masked]>

>> > [mailto:[email-masked]] On Behalf Of Wes Young

>> > Sent: Thursday, July 28, 2011 11:08 AM

>> > To: [email-masked]<mailto:[email-masked]>

>> > Subject: Re: [mile] Updated presentation from Side meeting

>> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM

>> > http://tools.ietf.org/html/rfc5070#section-3.19

>> > i've been sticking other "XML like" records under this (icsg1.1 data,

>> > etc...).

>> > pretty easy to do, just generate the "other standards" xml (or json or

>> > whatever), embed it there. turns iodef into a sharing platform for

>> > other data-types w/o having to extend it too much.

>> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote:

>> > So, maybe we could extend the IODEF as described in Figure 1 of the

>> > attached txt file. (correct me if I'm wrong) We could define

>> > Incident.EventData.AdditionalData elements and describe them by using

>> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC.

>> > Regarding OVAL, we might define Incident.AdditionalData element, but I

>> > am not sure at this moment, thus is not described in the figure yet.

>> > I would like to tackle CAPEC first since I believe Kent would like to

>> > tackle CVE and CAPEC.

>> > --

>> > Wes

>> > claimid.com/wesyoung

>> > [email-masked]<mailto:[email-masked]>

>> > * Wes Young<[email-masked]<mailto:[email-masked]>>

>> > * 0xDDB6E946 - Unverified(L)

>> > _______________________________________________

>> > mile mailing list

>> > [email-masked]<mailto:[email-masked]>

>> > https://www.ietf.org/mailman/listinfo/mile

>> > _______________________________________________

>> > mile mailing list

>> > [email-masked]<mailto:[email-masked]>

>> > https://www.ietf.org/mailman/listinfo/mile

>> > _______________________________________________

>> > mile mailing list

>> > [email-masked]<mailto:[email-masked]>

>> > https://www.ietf.org/mailman/listinfo/mile

>> > _______________________________________________

>> > 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: <[email-masked]>
Date: Tue, 9 Aug 2011 19:44:36 -0400

Hi Take,

For clarity I'd suggest not using "Version" as the name of both an extension attribute and one of the classes in each extension.  Renaming the class to SpecificationVersion would be clearer (so Version is the attribute with the version of the extension).

I also have a few questions:

(1) What strings are valid for SpecificationName?  If the recipient doesn't understand the SpecificationName, the information in the extension may be unparseable, so this probably needs to be controlled.

An IANA registry may be appropriate to list the valid strings and associate each string with its corresponding specification.

(2) How does one determine the format for information formatted according to an external specification?

For example, I believe that the XSD schema for the CVE list defines a complete XML document, but I suspect that less than a complete XML document is intended to be embedded because the proposed extension is part of an IODEF XML document.

(3) Why is the [Specification]Version limited to zero or one?

For example, CAPEC is currently at Release 1.6.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Monday, August 08, 2011 11:50 PM
To: [email-masked]
Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information

Sincerely,
Take

2011/8/5 Takeshi Takahashi <[email-masked]>:
> It would be great if you could provide some comments on Clause 4, where the
> Thus, I would be happy to change and develop the draft further based on your
> comments.
>
>
>
> By the way, I will be on vacation, thus my response might be slow, sorry for
> the inconvenience.
>
>
>
> Take
>
>
>
>> Let me work on the "draft" of the draft for a while, then come back to you
>
>> later.
>
>>
>
>> Take
>
>>
>
>> > Thanks Takeshi.  I look forward to your draft. It will give us something
>

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

---

From: lnunez <[email-masked]>
Date: Wed, 10 Aug 2011 16:22:58 -0400

I noticed CVRF mention briefly in this email thread (good I am thinking the
same). Looking at the draft-takahash-mile-sci-01.txt I see potential
synergies between the draft and CVRF. 

They both share some heritage.  Major vendors have indicated that they will
start publishing security advisories in the near future.  I could see this
IODEF-extension leveraging the CVRF content/components to provide additional
fidelity to the security incident exchange.  

CVRF link:
http://www.icasi.org/cvrf
Redhat CVRF sample:
http://www.awe.com/mark/blog/20110518.html

It would be interesting to see a CVRF advisory with OVAL checking content as
a mitigation method in this draft.

One thing to keep in mind is to realized how we can build and used the
various emerging set of standards in a cohesive way.

thanks.

On 8/8/11 11:49 PM, "Takeshi Takahashi" <[email-masked]>
wrote:

>> > comments I¹ve received in this mailing list (Thanks a lot for that).
>> > 
>> > By the way, I will be on vacation, thus my response might be slow, sorry >>
for
>> > the inconvenience.
>> > 
>> >  
>> > 
>> > Take
>> > 
>> >  
>> > 
>> > PS: I¹ve changed the title of the email.
>> > 
>> >  
>> > 
>> >  
>> >

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 10 Aug 2011 17:36:27 -0400

Hi Inunez,

In the Q4/17 workplan we have X.cvrm identified as a "CYBEX"
work item.  Do you think we can bring it into the upcoming meeting
in two weeks?  I'd be willing to work with the appropriate people
to make that happen.

--tony

On 8/10/2011 4:22 PM, lnunez wrote:
> I noticed CVRF mention briefly in this email thread (good I am 
> thinking the same). Looking at the draft-takahash-mile-sci-01.txt I 
> see potential synergies between the draft and CVRF.
>
> They both share some heritage.  Major vendors have indicated that they 
> will start publishing security advisories in the near future.  I could 
> see this IODEF-extension leveraging the CVRF content/components to 
> provide additional fidelity to the security incident exchange.
>
> CVRF link:
> It would be interesting to see a CVRF advisory with OVAL checking 
> content as a mitigation method in this draft.
>

---

From: <[email-masked]>
Date: Wed, 10 Aug 2011 21:53:56 -0400

Interesting questions, what do others think on this one?

CVRF is a way of reporting out vulnerability information, tying together some of the SCAP standards for more complete information on a vulnerability.  It could be a very good thing to be able to include in the extension.  Is this something the community wants to see in the extension?

Thanks,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of lnunez
Sent: Wednesday, August 10, 2011 4:23 PM
To: Takeshi Takahashi; [email-masked]
Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information

I noticed CVRF mention briefly in this email thread (good I am thinking the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF.

They both share some heritage.  Major vendors have indicated that they will start publishing security advisories in the near future.  I could see this IODEF-extension leveraging the CVRF content/components to provide additional fidelity to the security incident exchange.

CVRF link:

It would be interesting to see a CVRF advisory with OVAL checking content as a mitigation method in this draft.

One thing to keep in mind is to realized how we can build and used the various emerging set of standards in a cohesive way.

thanks.

On 8/8/11 11:49 PM, "Takeshi Takahashi" <[email-masked]> wrote:
Thank you for those of you who kindly gave me off-line messages .

Sincerely,
Take

2011/8/5 Takeshi Takahashi <[email-masked]>:
>> > Takahashi<[email-masked]<mailto:takeshi_takahashi<[email-masked]%3cmailto:takeshi_takahashi>@nict.g
>
>> > o.jp>>
>
>> > "[email-masked]<mailto:Thomas.Millar<[email-masked]%3cmailto:Thomas.Millar>@us-cert.gov>"<Thomas.M
>
>> > [email-masked]<mailto:Thomas.Millar<[email-masked]%3cmailto:Thomas.Millar>@us-cert.gov>>,
>
>> > "[email-masked]<mailto:wes<[email-masked]%3cmailto:wes>@ren-isac.net>"<[email-masked]<mailto:we<[email-masked]%3cmailto:we>
>
>> > [email-masked]><[email-masked]%3e>>,
>
>> > "[email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.org>"<[email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.o
>
>> > rg>>
>
>> > From: [email-masked]<mailto:mile-bounces<[email-masked]%3cmailto:mile-bounces>@ietf.org>
>
>> > [email-masked]<mailto:Thomas.Millar<[email-masked]%3cmailto:Thomas.Millar>@us-cert.gov>
>
>> > To: [email-masked]<mailto:wes<[email-masked]%3cmailto:wes>@ren-isac.net>;
>
>> > [email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.org>
>
>> > [email-masked]<mailto:thomas.millar<[email-masked]%3cmailto:thomas.millar>@us-cert.gov>
>
>> > BB: [email-masked]<mailto:thomas.millar<[email-masked]%3cmailto:thomas.millar>@dhs.gov>  /
>
>> > 202-631-1915
>
>> > 24x7: [email-masked]<mailto:soc<[email-masked]%3cmailto:soc>@us-cert.gov>  / 888-282-0870
>
>> > From: [email-masked]<mailto:mile-bounces<[email-masked]%3cmailto:mile-bounces>@ietf.org>
>
>> > To: [email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.org>
>
>> > [email-masked]<mailto:soc<[email-masked]%3cmailto:soc>@ren-isac.net>
>
>> >
>
>> > * Wes Young<[email-masked]<mailto:wes<[email-masked]%3cmailto:wes>@ren-isac.net>>
>
>> > [email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.org>
>
>> > [email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.org>
>
>> > [email-masked]<mailto:mile<[email-masked]%3cmailto:mile>@ietf.org>
>

---

From: luis nunez <[email-masked]>
Date: Thu, 11 Aug 2011 15:09:23 -0400

fyi > *Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting
Framework
*posted to ITU.

http://www.itu.int/md/T09-SG17-C-0538/en

-ln

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 11 Aug 2011 15:18:37 -0400

For those who don't have a TIES account to get access,
I've attached the document...although there's about to
be a rev 1 with a slight tweak.  (Accounts can be
arranged if you don't have them.)

The responsiveness here is pretty cool, and substantial
cudos are due to Gregg Schudel and Cisco.  It's about the
nearest thing to "just in time" standards work as it gets.

-tony

On 8/11/2011 3:09 PM, luis nunez wrote:
> fyi > *Proposed new work item - ITU-T X.cvrf, Common Vulnerability 
> Reporting Framework
> *posted to ITU.
>
> On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Inunez,
>

---

From: <[email-masked]>
Date: Thu, 11 Aug 2011 15:57:37 -0400

It looks like the ITU CYBEX model will incorporate CVRF from the vendors that manage the standard.  This is a big indication that the SCAP extension to IODEF should include CVRF.

Do folks agree or disagree with including this work as a reference?  I think it makes a lot of sense as vendors in the US are moving to support this model.

Best regards,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of luis nunez
Sent: Thursday, August 11, 2011 3:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information

fyi > Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting Framework
posted to ITU.

-ln

On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <[email-masked]<mailto:[email-masked]>> wrote:
Hi Inunez,

--tony

CVRF link:

---

From: <[email-masked]>
Date: Thu, 11 Aug 2011 16:26:36 -0500

We are planning on supporting it for the publication of product vulnerabilities. I think this makes a lot of sense.

Kent Landfield

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 11 Aug 2011 14:57:37 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information

Best regards,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of luis nunez
Sent: Thursday, August 11, 2011 3:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information

-ln

--tony

CVRF link:

---

From: "Martin, Robert A." <[email-masked]>
Date: Thu, 11 Aug 2011 20:58:38 -0400

As an organization that deals with lots of public vulnerability 
disclosures, MITRE's CVE team looks forward to more and more advisories 
taking up and utilizing the structured informatin that is covered in CVRF.

We especially look forward to the CVRF advisories that will utilize as 
many of the structured fields as possible - especially CWE and CPE - 
where this refined insight on what the root cause of the vulnerability 
being reported is with CWE Ids and what versions are impacted by listing 
CPEs - both will help a great deal.

We also look forward to the incorporation of OVAL into a future version 
of CVRF so that organizations will be able to quickly use the included 
OVAL definitions to review their deployed systems and immediately 
identify those that the advisory applies to.

Regards,

Bob

On 8/11/11 5:26 PM, [email-masked] wrote:
> From: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> fyi>  Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting Framework
> posted to ITU.
>
> On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski<[email-masked]<mailto:[email-masked]>>  wrote:
> Hi Inunez,
>

---

From: "Menkhus, Mark (HAS GSE SSRT)" <[email-masked]>
Date: Fri, 12 Aug 2011 13:15:50 +0100

Hi,

HP's security advisory team is not using CVRF, but I have followed CVRF for
a while, and advocate it's use when we have an opportunity.

I have not contributed other comments to mile, yet, but CVRF does bear
consideration into the extension.

Regards, 

Mark Menkhus CSSLP, ITIL v3 expert

Hewlett Packard Software Security Response Team
Team email: [email-masked]

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 10, 2011 7:54 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] draft on IODEF exstension to support structured
cybersecurity information

CVRF is a way of reporting out vulnerability information, tying together
some of the SCAP standards for more complete information on a vulnerability.
It could be a very good thing to be able to include in the extension.  Is
this something the community wants to see in the extension?

Thanks,

Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of
lnunez
Sent: Wednesday, August 10, 2011 4:23 PM
To: Takeshi Takahashi; [email-masked]
Subject: Re: [mile] draft on IODEF exstension to support structured
cybersecurity information

CVRF link:

thanks.

 
 
Sincerely,
Take

the
your
for
you
something

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Sun, 14 Aug 2011 22:25:00 +0900

Hi David,

Thank you for your kind comments.
I agree, I'll change the element class name.

Regarding the issues you kindly raised in the email, let me describe my
understanding.

1)
My assumption was, when parsing the xml data, the parser anyway reads the
namespace described in the embedded xml data and parse the data.
But I agree, it would be better to limit the description of
SpecificationName.
Maybe we could use ENUM (instead of ML_STRING), and enumerate possible
specifications.
For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use ENUM for
dtype and FraudType description.
Like the same way, the SpecificationName could use ENUM for describing
specifications, though we do not have that much specifications to enumerate
at this moment.

2)
I am not sure whether it is easier for information sender and receiver to
send/receive partial CVE data.
Maybe it would be easier for them to embed/receive/parse a complete CVE
data?
If we send a partial CVE or the other structured data, receiver may suffer
from some parsing problem, as you mentioned.
So, my assumption here is that a complete CVE (compatible with its schema)
will be embedded here.

3)
Maybe some text in the draft has caused mis-understanding.
Yes, the latest version of the XCCDF schema is 1.6.
I intended to say that the number of the version element is zero or one.
Most of specifications such as XCCDF etc. have versions while CVE does not.
Thus the number of this element class is ZERO or ONE.

Above are my viewpoint, but I might be wrong.
Let me develop the draft based on your kind comments after my vacation.
Please correct me if I am wrong, I would like to welcome feedbacks.

Thank you.

Take

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 10, 2011 8:45 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mile] draft on IODEF exstension to support structured
cybersecurity information

Hi Take,

For clarity I’d suggest not using “Version” as the name of both an extension
attribute and one of the classes in each extension.  Renaming the class to
SpecificationVersion would be clearer (so Version is the attribute with the
version of the extension).

(1) What strings are valid for SpecificationName?  If the recipient doesn’t
understand the SpecificationName, the information in the extension may be
unparseable, so this probably needs to be controlled.

An IANA registry may be appropriate to list the valid strings and associate
each string with its corresponding specification.

(2) How does one determine the format for information formatted according to
an external specification?

For example, I believe that the XSD schema for the CVE list defines a
complete XML document, but I suspect that less than a complete XML document
is intended to be embedded because the proposed extension is part of an
IODEF XML document.

Thanks,
--David

Takeshi Takahashi

Sincerely,
Take

2011/8/5 Takeshi Takahashi <[email-masked]>:
> comments I’ve received in this mailing list (Thanks a lot for that).
>
the
your
for
> the inconvenience.
>
>  
>
> Take
>
>  
>
> PS: I’ve changed the title of the email.
>
>  
>
>  
>
you
something

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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Sun, 14 Aug 2011 22:28:30 +0900

Thank you for the emails. I like CVRF's approach.
I believe supporting those industry-oriented specification is very
important, and this IODEF extension should be designed to be a container for
any evolving specifications.
(this is my motivation)

The "Method.AdditionalData.Vulnerability" element described in the draft can
be used to embed CVRF report with the "cvrf" SpecificationName.
I'll put reference to CVRF specification in the draft.

Having said that, I am not sure Method.AdditionalData.Vulnerability is the
right place to embed CVRF report.
Correct me if I'm wrong, but according to the CVRF schema 1.0, it defines
abstract-level information.
Though current focus of CVRF is on vulnerability (in my understanding), this
schema is flexible enough to convey not only vulnerability information but
also various incident-related information.

Anyway, at this stage, let me add text on and reference to CVRF in the draft
as one specification describing vulnerability, after I come back from my
vacation.

Take

From: Menkhus, Mark (HAS GSE SSRT) [mailto:[email-masked]] 
Sent: Friday, August 12, 2011 9:16 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [mile] draft on IODEF exstension to support structured
cybersecurity information

Hi,

HP’s security advisory team is not using CVRF, but I have followed CVRF for
a while, and advocate it’s use when we have an opportunity.

Regards, 

Thanks,
Kathleen

CVRF link:

thanks.

 
Sincerely,
Take

the
your
for
you
something

---

From: <[email-masked]>
Date: Mon, 15 Aug 2011 21:14:46 -0400

Hi Take,

Enjoy your vacation, here are some comments to look at when you return:

1)
> Maybe we could use ENUM (instead of ML_STRING), and enumerate possible specifications.

That sounds like a good approach - each RFC that registers a value for the ENUM should include a pointer to the XML Schema for that specification as part of making the registration with IANA (the IANA registry entry will reference the RFC for the details).  This may help recipients ensure that they have local copies of the XML schemas necessary to parse expected content.

2)
> So, my assumption here is that a complete CVE (compatible with its schema)

I don't have a problem with that assumption, but think it should be stated because that conclusion is not obvious [well, at least not to me ;-) ].  It should be sufficient to state that the embedded element is a complete XML document that is formatted according to the schema referenced by the IANA registration of the ENUM value used for SpecificationName (see item 1).

> Thus the number of this element class is ZERO or ONE.

I misread what you wrote, sorry about that.  I was looking for the syntax of the contents of the [Specification]Version element, and looked in the wrong place.

My concern is similar to item 1) - how does the recipient parse and check the version number?
The rules for this need to be precise, otherwise there may be unexpected string compare results.  It'd be good if the version number could be extracted from the XML Schema for the embedded content (and hence take advantage of the rules in the referenced specification for the syntax of [Specification]Version).

A simple (silly) example of what can go wrong is that OVAL is currently at version 5.10 - that's not the same as 5.1, but if it's converted to a number, the result is easy to misparse it as being equivalent to 5.1 ;-).  Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.' causes problems in some tooling?  All of these are easy for a human to sort out, but potential causes of problems in automated tools.

Thanks,
--David

> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Sunday, August 14, 2011 9:25 AM
> To: Black, David; [email-masked]
> Subject: RE: [mile] draft on IODEF exstension to support structured cybersecurity information
>
> Hi David,
>
> For clarity I'd suggest not using "Version" as the name of both an extension
> (1) What strings are valid for SpecificationName?  If the recipient doesn't

---

From: Brian Trammell <[email-masked]>
Date: Tue, 16 Aug 2011 10:09:56 +0200

Greetings, all,

I'm just back from vacation and catching up on things, and still need to review the document completely, so expect more from me on this thread, soon. However, I did want to point one thing out here...

In general, I agree: representing embedded information by ENUM as opposed to by freeform string is much preferable. However, if the embedded information is itself described by an XML Schema, then it may make sense to differentiate the embedded AdditionalData content not with a new ENUM, but rather by the namespace used by that schema. You still run into the subordinate namespace versioning problem, but this is now the job of the creator of the subordinate namespace to do correctly, which I would assume is the case for the SCAP use case.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 18 Aug 2011 16:14:10 +0200

Hi, Take, all, 

One point that came up here when we were discussing the draft at ETH follows...

It appears that the AttackPattern, Vulnerability, and Weakness classes should probably have a multiplicity of 0..n -- 0 to support cases where these are not known, or n for cases where multiple external references are necessary.

Thoughts?

Cheers,

Brian

On Aug 9, 2011, at 5:49 AM, Takeshi Takahashi wrote:

> <draft-takahashi-mile-sci-01.txt>_______________________________________________
> mile mailing list
> [email-masked]

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 24 Aug 2011 09:09:47 +0100

Hi David,	

Thanks for your email.

1)
specifications.
>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use 
>> ENUM for dtype and FraudType description.
>
> That sounds like a good approach - each RFC that registers a value for the
ENUM should include a pointer to the XML Schema for that specification as
part of making the registration with IANA (the IANA registry entry will
reference the RFC for the details).  This may help recipients ensure that
they have local copies of the XML schemas necessary to parse expected
content.

Thank you for telling me the IANA issue. I appreciate that.

2)
>> So, my assumption here is that a complete CVE (compatible with its 
>> schema) will be embedded here.
>
> I don't have a problem with that assumption, but think it should be stated
because that conclusion is not obvious [well, at least not to me ;-) ].  It
should be sufficient to state that the embedded element is a complete XML
document that is formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName (see item 1).

I see. I will. Thank you.

>The rules for this need to be precise, otherwise there may be unexpected
string compare results.  It'd be good if the version number could be
extracted from the XML Schema for the embedded content (and hence >take
advantage of the rules in the referenced specification for the syntax of
[Specification]Version).
>
>A simple (silly) example of what can go wrong is that OVAL is currently at
version 5.10 - that's not the same as 5.1, but if it's converted to a
number, the result is easy to misparse it as being equivalent to 5.1 ;-).
Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.'
causes problems in some tooling?  All of these are easy for a human to sort
out, but potential causes of problems in automated tools.

Yes, I agree.
To clarify this issue, I'll add a sentence "parsers are expected to read the
namespace of the embedded structured information and identify specification
name and data, whenever such information is available, and parse the
embedded data."

Then one potential question we might have is, do we need the
SpecificationName and SpecificationVersion elements?
If the namespace described in the embedded structured information identify
the specification name and its version, one might think these elements are
useless.
However, in my opinion, we still need these elements since some of the
embedded information could be non-xml in the future.

Thank you.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 10:15 AM
To: [email-masked]; [email-masked]
Subject: RE: [mile] draft on IODEF extension to support structured

Hi Take,

1)
specifications.
> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use 
> ENUM for dtype and FraudType description.

That sounds like a good approach - each RFC that registers a value for the
ENUM should include a pointer to the XML Schema for that specification as
part of making the registration with IANA (the IANA registry entry will
reference the RFC for the details).  This may help recipients ensure that
they have local copies of the XML schemas necessary to parse expected
content.

2)
> So, my assumption here is that a complete CVE (compatible with its 
> schema) will be embedded here.

I don't have a problem with that assumption, but think it should be stated
because that conclusion is not obvious [well, at least not to me ;-) ].  It
should be sufficient to state that the embedded element is a complete XML
document that is formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName (see item 1).

> Thus the number of this element class is ZERO or ONE.

I misread what you wrote, sorry about that.  I was looking for the syntax of
the contents of the [Specification]Version element, and looked in the wrong
place.

My concern is similar to item 1) - how does the recipient parse and check
the version number?
The rules for this need to be precise, otherwise there may be unexpected
string compare results.  It'd be good if the version number could be
extracted from the XML Schema for the embedded content (and hence take
advantage of the rules in the referenced specification for the syntax of
[Specification]Version).

A simple (silly) example of what can go wrong is that OVAL is currently at
version 5.10 - that's not the same as 5.1, but if it's converted to a
number, the result is easy to misparse it as being equivalent to 5.1 ;-).
Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.'
causes problems in some tooling?  All of these are easy for a human to sort
out, but potential causes of problems in automated tools.

Thanks,
--David

> Regarding the issues you kindly raised in the email, let me describe 
> my understanding.
>
> 1)
> My assumption was, when parsing the xml data, the parser anyway reads 
> the namespace described in the embedded xml data and parse the data.
> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use 
> ENUM for dtype and FraudType description.
> specifications, though we do not have that much specifications to 
> enumerate at this moment.
>
> 2)
> I am not sure whether it is easier for information sender and receiver 
> to send/receive partial CVE data.
> Maybe it would be easier for them to embed/receive/parse a complete 
> CVE data?
> If we send a partial CVE or the other structured data, receiver may 
> suffer from some parsing problem, as you mentioned.
> So, my assumption here is that a complete CVE (compatible with its 
> schema) will be embedded here.
>
> 3)
> For clarity I'd suggest not using "Version" as the name of both an 
> extension attribute and one of the classes in each extension.  
> Renaming the class to SpecificationVersion would be clearer (so 
> Version is the attribute with the version of the extension).
>
> (1) What strings are valid for SpecificationName?  If the recipient 
> doesn't understand the SpecificationName, the information in the 
> extension may be unparseable, so this probably needs to be controlled.
>
> An IANA registry may be appropriate to list the valid strings and 
> associate each string with its corresponding specification.
>
> complete XML document, but I suspect that less than a complete XML 
> document is intended to be embedded because the proposed extension is 
> part of an IODEF XML document.
>
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748
> > The attached is the tentative version of the draft prepared based on 
> > the comments I've received in this mailing list (Thanks a lot for that).
> >
> > As you know, there are many ways to embed structured information 
> > (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very
flexible.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 24 Aug 2011 09:11:15 +0100

Hi Brian,

Thanks for your email.

> In general, I agree: representing embedded information by ENUM as opposed
to by freeform string is much preferable. However, if the embedded
information is itself described by an XML Schema, then it may make sense to
differentiate the embedded AdditionalData content not with a new ENUM, but
rather by the namespace used by that schema. You still run into the
subordinate namespace versioning problem, but this is now the job of the
creator of the subordinate namespace to do correctly, which I would assume
is the case for the SCAP use case.

Basically, yes, I agree.
As mentioned in the other email, I'll add a sentence "parsers are expected
to read the namespace of the embedded structured information and identify
specification name and data, whehever such information is available, and
parse the embedded data."

But maybe we still need these ENUM-based elements, since these embedded
information could be non-xml in the future.
At the same time, we could allow omitting SpecificationName and
SpecificationVersion elements, since the namespace of the embedded xml data
uniquely identify specification and its version as you mentioned.

Thank you.

Take

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 5:10 PM
To: <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] draft on IODEF extension to support structured

Greetings, all,

I'm just back from vacation and catching up on things, and still need to
review the document completely, so expect more from me on this thread, soon.
However, I did want to point one thing out here...

In general, I agree: representing embedded information by ENUM as opposed to
by freeform string is much preferable. However, if the embedded information
is itself described by an XML Schema, then it may make sense to
differentiate the embedded AdditionalData content not with a new ENUM, but
rather by the namespace used by that schema. You still run into the
subordinate namespace versioning problem, but this is now the job of the
creator of the subordinate namespace to do correctly, which I would assume
is the case for the SCAP use case.

Regards,

Brian

specifications.
> I misread what you wrote, sorry about that.  I was looking for the syntax
of the contents of the [Specification]Version element, and looked in the
wrong place.
the version number?
>> Like the same way, the SpecificationName could use ENUM for 
>> describing specifications, though we do not have that much 
>> specifications to enumerate at this moment.
>> 
>> 2)
>> I am not sure whether it is easier for information sender and 
>> receiver to send/receive partial CVE data.
>> David L. Black, Distinguished Engineer EMC Corporation, 176 South 
>> St., Hopkinton, MA  01748
flexible.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 24 Aug 2011 09:11:48 +0100

Hi Brian,

Thank you for the kind comments.

> It appears that the AttackPattern, Vulnerability, and Weakness classes
should probably have a multiplicity of 0..n -- 0 to support cases where
these are not known, or n for cases where multiple external references are
necessary.

Yes, I agree. I'll add some sentences to clarify that.
Let me update the draft and come back to you and all here with revised draft
soon.

Thank you.

Take

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Thursday, August 18, 2011 11:14 PM
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] draft on IODEF exstension to support structured

Hi, Take, all, 

One point that came up here when we were discussing the draft at ETH
follows...

It appears that the AttackPattern, Vulnerability, and Weakness classes
should probably have a multiplicity of 0..n -- 0 to support cases where
these are not known, or n for cases where multiple external references are
necessary.

Thoughts?

Cheers,

Brian

On Aug 9, 2011, at 5:49 AM, Takeshi Takahashi wrote:

> > It would be great if you could provide some comments on Clause 4, 
> > where the IODEF extension is defined.
> > 
> > 
> > 
flexible.
> > 
> > Thus, I would be happy to change and develop the draft further based 
> > on your comments.
> > 
> > 
> > 
> > By the way, I will be on vacation, thus my response might be slow, 
> > sorry for the inconvenience.
> > 
> > 
> > 
> > Take
> > 
> > 
> >

---

From: Brian Trammell <[email-masked]>
Date: Wed, 24 Aug 2011 10:17:25 +0200

Hi, Take,

To my understanding, there are two possible answers to this last question, each with their own disadvantages:

1. The SpecificationName and SpecificationVersion are present and required, and MUST match any version information carried by the enclosed XML namespace and schema. This gives you a nice envelope for determining which version of the extension you're using, but can lead to inconsistency if improperly used. It is unclear what a reader should do when an inconsistency is detected. In line with common practice in protocol design (send conservatively, accept liberally), I would suggest "writers/senders MUST ensure the SpecificationName and SpecificationVersion are consistent with the contents; if a reader/receiver detects an inconsistency, it SHOULD prefer the specification and version derived from the content, and SHOULD log the inconsistency so a human can correct the problem." But it should be addressed in any case.

2. The SpecificationName and SpecificationVersion are only present when that information is not derivable from the enclosed XML namespace and schema. This is ugly, because it introduces two ways of doing the same thing...

Best regards,

Brian

On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote:

>>> where
>>> on
>>> sorry

---

From: Brian Trammell <[email-masked]>
Date: Wed, 24 Aug 2011 10:43:43 +0200

Hi, Take,

I prefer option 1 as well...

(This would additionally appear to resolve my previous question.)

Cheers,

Brian

On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote:

> Hi Brian,
> 
> I like the 1st option you kindly raised here.
> I appreciate your assistance.
> 
> Let me update the text and come back to the list soon.
> (I will make sure all the comments I've received in this list should be
> reflected.)
> 
> Best Regards,
> Take
> 
> 
> Sent: Wednesday, August 24, 2011 10:17 AM
> To: Takeshi Takahashi
> Cc: [email-masked]; [email-masked]
> 1. The SpecificationName and SpecificationVersion are present and required,
> and MUST match any version information carried by the enclosed XML namespace
> and schema. This gives you a nice envelope for determining which version of
> the extension you're using, but can lead to inconsistency if improperly
> used. It is unclear what a reader should do when an inconsistency is
> detected. In line with common practice in protocol design (send
> conservatively, accept liberally), I would suggest "writers/senders MUST
> ensure the SpecificationName and SpecificationVersion are consistent with
> the contents; if a reader/receiver detects an inconsistency, it SHOULD
> prefer the specification and version derived from the content, and SHOULD
> log the inconsistency so a human can correct the problem." But it should be
> addressed in any case.
> 
> 2. The SpecificationName and SpecificationVersion are only present when that
> information is not derivable from the enclosed XML namespace and schema.
> This is ugly, because it introduces two ways of doing the same thing...
> 
> Best regards,
> 
> Brian
> 
>> ENUM should include a pointer to the XML Schema for that specification 
>> as part of making the registration with IANA (the IANA registry entry 
>> will reference the RFC for the details).  This may help recipients 
>> ensure that they have local copies of the XML schemas necessary to 
>> parse expected content.
>> 
>> because that conclusion is not obvious [well, at least not to me ;-) 
>> ].  It should be sufficient to state that the embedded element is a 
>> complete XML document that is formatted according to the schema 
>> referenced by the IANA registration of the ENUM value used for
> SpecificationName (see item 1).
>> 
>> extracted from the XML Schema for the embedded content (and hence 
>>> take advantage of the rules in the referenced specification for the 
>> syntax of [Specification]Version).
>>> 
>> causes problems in some tooling?  All of these are easy for a human to 
>> sort out, but potential causes of problems in automated tools.
>> 
>> Yes, I agree.
>> To clarify this issue, I'll add a sentence "parsers are expected to 
>> read the namespace of the embedded structured information and identify 
>> specification name and data, whenever such information is available, 
>> and parse the embedded data."
>> 
>> If the namespace described in the embedded structured information 
>> identify the specification name and its version, one might think these 
>> elements are useless.
>> That sounds like a good approach - each RFC that registers a value for 
>> the ENUM should include a pointer to the XML Schema for that 
>> specification as part of making the registration with IANA (the IANA 
>> registry entry will reference the RFC for the details).  This may help 
>> recipients ensure that they have local copies of the XML schemas 
>> necessary to parse expected content.
>> 
>> 2)
>> I don't have a problem with that assumption, but think it should be 
>> stated because that conclusion is not obvious [well, at least not to 
>> me ;-) ].  It should be sufficient to state that the embedded element 
>> is a complete XML document that is formatted according to the schema 
>> referenced by the IANA registration of the ENUM value used for
> SpecificationName (see item 1).
>> 
>>> 3)
>>> Most of specifications such as XCCDF etc. have versions while CVE 
>>> does
>> not.
>> I misread what you wrote, sorry about that.  I was looking for the 
>> syntax of the contents of the [Specification]Version element, and 
>> looked in the wrong place.
>> 
>> The rules for this need to be precise, otherwise there may be 
>> unexpected string compare results.  It'd be good if the version number 
>> could be extracted from the XML Schema for the embedded content (and 
>> hence take advantage of the rules in the referenced specification for 
>> the syntax of [Specification]Version).
>> 
>> A simple (silly) example of what can go wrong is that OVAL is 
>> currently at version 5.10 - that's not the same as 5.1, but if it's 
>> converted to a number, the result is easy to misparse it as being
> equivalent to 5.1 ;-).
>> causes problems in some tooling?  All of these are easy for a human to 
>> sort out, but potential causes of problems in automated tools.
>> 
>> Thanks,
>> --David
>> 
>>> Most of specifications such as XCCDF etc. have versions while CVE 
>>> does
>> not.

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 09:08:06 -0400

I also prefer option 1.  Returning to Brian's earlier comment:

> In general, I agree: representing embedded information by ENUM as opposed to by
> freeform string is much preferable. However, if the embedded information is itself
> described by an XML Schema, then it may make sense to differentiate the embedded
> AdditionalData content not with a new ENUM, but rather by the namespace used by
> that schema. You still run into the subordinate namespace versioning problem,
> but this is now the job of the creator of the subordinate namespace to do
> correctly, which I would assume is the case for the SCAP use case.

I'm ok with SpecificationName being an XML namespace reference rather than an ENUM
(both work for me), but I still think the IANA registry of allowed XML namespace
references is needed, so that a recipient can prepare in advance for what might be
coming.  This avoids having to go fetch an XML schema in the middle of incident
handling and allows verification in advance that the recipient's automated tooling
can handle the content.

Thanks,
--David

> Sent: Wednesday, August 24, 2011 4:44 AM
> To: Takeshi Takahashi
> Cc: Black, David; [email-masked]
> Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information
>
> Hi, Take,
>
> >>> stated
> >>> unexpected
> >>> currently at

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 05:13:00 -0400

Hello David,

I would like to clarify your request, so please let me know if the following would satisfy the request.

1. SCAP and some of the other referenced schemas are maintained outside of the IETF currently, so namespaces and schemas are defined elsewhere.  IANA maintains a registry of XML schemas referenced by IETF documents (SCAP and other XML schemas are referenced from the proposed IODEF extension fit into this group).

2. IANA also registers identifiers that are allocated in IETF-controlled URI space (IODEF and IODEF extensions fit into this group).

Are you asking for each of the referenced schemes to be registered as described by #1 and then following the template, Take will register the IODEF extension following #2 following the guidance in RFC3688?  The IANA registration requests are all handled in the IANA Considerations section of a draft.

Registered schemas:
http://www.iana.org/assignments/xml-registry/ns.html

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, August 24, 2011 9:08 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] draft on IODEF extension to support structured      cybersecurity information

Thanks,
--David

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 10:30:51 -0400

Hi Kathleen,

The concern behind my request is:

>> This avoids having to go fetch an XML schema in the middle of incident

As long as that goal is achieved, I'm flexible in how we go about achieving it.

So, assuming that this IODEF extension uses XML namespace references rather than ENUM values to
designate external specifications, I would like to see something similar to the following
where the IANA registration is just the namespace, and the schema is maintained elsewhere:

> 1. SCAP and some of the other referenced schemas are maintained outside of the IETF currently, so
> namespaces and schemas are defined elsewhere.  IANA maintains a registry of XML schemas referenced by
> IETF documents (SCAP and other XML schemas are referenced from the proposed IODEF extension fit into
> this group).

However, the existing IANA XML registry (http://www.iana.org/assignments/xml-registry/ns.html)
appears (IMHO) to be too broad for this purpose - for example, the keyprov DSKPP namespaces
(e.g., for PKCS5 and PKCS12) aren't appropriate, among many other examples.  It also appears
that only IETF-defined (and maintained) namespaces are currently registered in that IANA registry.

FWIW, There's also an XML schema registry (http://www.iana.org/assignments/xml-registry/schema.html)
that does not appear to be appropriate, as registering SCAP and other external schemas there probably
gets in the way of external maintenance of those schemas.

So, in addition to registering the XML namespaces in the existing registry, I would like to see
creation of a new registry specific to this IODEF extension that lists only the XML namespaces
that are valid to use in this IODEF extension for structured cyber-security information.

> IODEF extensions fit into this group).

Yes, in the same IANA registries.

> Are you asking for each of the referenced schemes to be registered as described by #1 and then
> following the template, Take will register the IODEF extension following #2 following the guidance in
> RFC3688?  The IANA registration requests are all handled in the IANA Considerations section of a
> draft.

I believe so, and in addition, I'm asking that the draft create a new IANA registry that contains
only the schemas that are valid for use in this IODEF extension.

It may be useful to ask the IETF XML Directorate (http://www.apps.ietf.org/content/xml-directorate)
for guidance on the details of what should be done here.

Thanks,
--David

> From: Moriarty, Kathleen
> Sent: Friday, August 26, 2011 5:13 AM
> To: Black, David; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mile] draft on IODEF extension to support structured cybersecurity information
>
> Hello David,
>
> 1. SCAP and some of the other referenced schemas are maintained outside of the IETF currently, so
> namespaces and schemas are defined elsewhere.  IANA maintains a registry of XML schemas referenced by
> IETF documents (SCAP and other XML schemas are referenced from the proposed IODEF extension fit into
> this group).
>
> Are you asking for each of the referenced schemes to be registered as described by #1 and then
> following the template, Take will register the IODEF extension following #2 following the guidance in
> RFC3688?  The IANA registration requests are all handled in the IANA Considerations section of a
> draft.
>
> Registered schemas:

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 11:50:30 -0400

> only the schemas that are valid for use in this IODEF extension.

"schemas" -> "namespace references for the schemas"

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, August 26, 2011 10:31 AM
> To: Moriarty, Kathleen; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 29 Aug 2011 12:42:23 +0100

Hi all

Thank you for your kind comments.
As Sean kindly notified, we've submitted our initial draft.

Let me summarize the changes I made from the previous version (sheared to
this mailing list on 9th August).
I hope I have reflected all the comments you have kindly gave us.

1. Attribute name is changed. (Version -> SpecificationVersion) (Sec. 4.1,
4.2, 4.3, 4.4, 4.5, 4.6, 4.7)

2. Reference to CVRF is added. (Sec. 4.3)

3. The type of SpecificationName element is changed. (ML_STRING -> ENUM)
(Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7)

4. Texts are added to clarify that complete information (e.g. CVE
information) is embedded. (Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7)

"A complete document that is formatted according to the schema referenced by
the IANA registration of the ENUM value used for SpecificationName and
SpecificationVersion elements."

5. Texts are added to clarify the number of these embedded information
elements (e.g., AttackPattern, Vulnerability, Weakness etc.). (Sec. 4.1,
4.2, 4.3, 4.4, 4.5, 4.6, 4.7)

"It is recommended that Assessment class SHOULD contain one or more of the
extension elements whenever available."

6. Texts regarding how to parse specification name and version are added.
(Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7)

"Writers/senders MUST ensure the SpecificationName and SpecificationVersion
are consistent with the contents of the Score; if a reader/receiver detects
an inconsistency, it SHOULD prefer the specification and version derived
from the content, and SHOULD log the inconsistency so a human can correct
the problem."

7. namespace/IANA issue (Sec. 7 of the attached file... not to the one I
submitted to IETF secretaries)

"The schemata of the embedded structured information are maintained outside
of the IETF currently, so namespaces and schemata are defined elsewhere.
IANA maintains a registry of XML schemata referenced by IETF documents, so,
the schemata of the embedded structured information are referenced from the
proposed IODEF extension."

Thank you, David and Kathleen, for your kind assistance on this issue.
I do not think I have sufficiently addressed the concern you kindly raised
yet.
Let me study on this issue a bit, then I will query this issue to the
experts.

If you have any comments on the draft, I would be happy to listen to that.

Thank you.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 26, 2011 4:31 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mile] draft on IODEF extension to support structured
cybersecurity information

Hi Kathleen,

The concern behind my request is:

>> This avoids having to go fetch an XML schema in the middle of 
>> incident handling and allows verification in advance that the 
>> recipient's automated tooling can handle the content.

As long as that goal is achieved, I'm flexible in how we go about achieving
it.

So, assuming that this IODEF extension uses XML namespace references rather
than ENUM values to designate external specifications, I would like to see
something similar to the following where the IANA registration is just the
namespace, and the schema is maintained elsewhere:

> 1. SCAP and some of the other referenced schemas are maintained 
> outside of the IETF currently, so namespaces and schemas are defined 
> elsewhere.  IANA maintains a registry of XML schemas referenced by 
> IETF documents (SCAP and other XML schemas are referenced from the
proposed IODEF extension fit into this group).

However, the existing IANA XML registry
(http://www.iana.org/assignments/xml-registry/ns.html)
appears (IMHO) to be too broad for this purpose - for example, the keyprov
DSKPP namespaces (e.g., for PKCS5 and PKCS12) aren't appropriate, among many
other examples.  It also appears that only IETF-defined (and maintained)
namespaces are currently registered in that IANA registry.

FWIW, There's also an XML schema registry
(http://www.iana.org/assignments/xml-registry/schema.html)
that does not appear to be appropriate, as registering SCAP and other
external schemas there probably gets in the way of external maintenance of
those schemas.

So, in addition to registering the XML namespaces in the existing registry,
I would like to see creation of a new registry specific to this IODEF
extension that lists only the XML namespaces that are valid to use in this
IODEF extension for structured cyber-security information.

> 2. IANA also registers identifiers that are allocated in 
> IETF-controlled URI space (IODEF and IODEF extensions fit into this
group).

> Are you asking for each of the referenced schemes to be registered as 
> described by #1 and then following the template, Take will register 
> the IODEF extension following #2 following the guidance in RFC3688?  
> The IANA registration requests are all handled in the IANA Considerations
section of a draft.

I believe so, and in addition, I'm asking that the draft create a new IANA
registry that contains only the schemas t	hat are valid for use in
this IODEF extension.

It may be useful to ask the IETF XML Directorate
(http://www.apps.ietf.org/content/xml-directorate)
for guidance on the details of what should be done here.

Thanks,
--David

> 1. SCAP and some of the other referenced schemas are maintained 
> outside of the IETF currently, so namespaces and schemas are defined 
> elsewhere.  IANA maintains a registry of XML schemas referenced by 
> IETF documents (SCAP and other XML schemas are referenced from the
proposed IODEF extension fit into this group).
>
> 2. IANA also registers identifiers that are allocated in 
> IETF-controlled URI space (IODEF and IODEF extensions fit into this
group).
>
> Are you asking for each of the referenced schemes to be registered as 
> described by #1 and then following the template, Take will register 
> the IODEF extension following #2 following the guidance in RFC3688?  
> The IANA registration requests are all handled in the IANA Considerations
section of a draft.
> From: [email-masked] [[email-masked]] On Behalf Of 
> [email-masked] [[email-masked]]
> > In general, I agree: representing embedded information by ENUM as 
> > opposed to by freeform string is much preferable. However, if the 
> > embedded information is itself described by an XML Schema, then it 
> > may make sense to differentiate the embedded AdditionalData content 
> > not with a new ENUM, but rather by the namespace used by that 
> > schema. You still run into the subordinate namespace versioning 
> > problem, but this is now the job of the creator of the subordinate
namespace to do correctly, which I would assume is the case for the SCAP use
case.
>
> I'm ok with SpecificationName being an XML namespace reference rather 
> than an ENUM (both work for me), but I still think the IANA registry 
> of allowed XML namespace references is needed, so that a recipient can 
> prepare in advance for what might be coming.  This avoids having to go 
> fetch an XML schema in the middle of incident handling and allows 
> verification in advance that the recipient's automated tooling can handle
the content.
> > > To my understanding, there are two possible answers to this last 
> > > question, each with their own disadvantages:
> > >
> > > 1. The SpecificationName and SpecificationVersion are present and 
> > > required, and MUST match any version information carried by the 
> > > enclosed XML namespace and schema. This gives you a nice envelope 
> > > for determining which version of the extension you're using, but 
> > > can lead to inconsistency if improperly used. It is unclear what a 
> > > reader should do when an inconsistency is detected. In line with 
> > > common practice in protocol design (send conservatively, accept 
> > > liberally), I would suggest "writers/senders MUST ensure the 
> > > SpecificationName and SpecificationVersion are consistent with the 
> > > contents; if a reader/receiver detects an inconsistency, it SHOULD 
> > > prefer the specification and version derived from the content, and 
> > > SHOULD log the inconsistency so a human can correct the problem." But
it should be addressed in any case.
> > >
> > > 2. The SpecificationName and SpecificationVersion are only present 
> > > when that information is not derivable from the enclosed XML namespace
and schema.
> > >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) 
> > >>>> use ENUM for dtype and FraudType description.
> > >>>
> > >> ENUM should include a pointer to the XML Schema for that 
> > >> specification as part of making the registration with IANA (the 
> > >> IANA registry entry will reference the RFC for the details).  
> > >> This may help recipients ensure that they have local copies of 
> > >> the XML schemas necessary to parse expected content.
> > >>
> > >> because that conclusion is not obvious [well, at least not to me 
> > >> ;-) ].  It should be sufficient to state that the embedded 
> > >> element is a complete XML document that is formatted according to 
> > >> the schema referenced by the IANA registration of the ENUM value 
> > >> used for
> > >> string compare results.  It'd be good if the version number could 
> > >> be extracted from the XML Schema for the embedded content (and 
> > >> hence
> > >> version 5.10 - that's not the same as 5.1, but if it's converted 
> > >> to a number, the result is easy to misparse it as being equivalent to
5.1 ;-).
> > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., 
> > >> if the
> > > '.'
> > >> causes problems in some tooling?  All of these are easy for a 
> > >> human to sort out, but potential causes of problems in automated
tools.
> > >>
> > >> Yes, I agree.
> > >> To clarify this issue, I'll add a sentence "parsers are expected 
> > >> to read the namespace of the embedded structured information and 
> > >> identify specification name and data, whenever such information 
> > >> is available, and parse the embedded data."
> > >>
> > >> identify the specification name and its version, one might think 
> > >> these elements are useless.
> > >> However, in my opinion, we still need these elements since some 
> > >> of the embedded information could be non-xml in the future.
> > >>
> > >> Thank you.
> > >>
> > >> Take
> > >>
> > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) 
> > >>> use ENUM for dtype and FraudType description.
> > >>
> > >> That sounds like a good approach - each RFC that registers a 
> > >> value for the ENUM should include a pointer to the XML Schema for 
> > >> that specification as part of making the registration with IANA 
> > >> (the IANA registry entry will reference the RFC for the details).  
> > >> This may help recipients ensure that they have local copies of 
> > >> the XML schemas necessary to parse expected content.
> > >>
> > >> 2)
> > >> I don't have a problem with that assumption, but think it should 
> > >> be stated because that conclusion is not obvious [well, at least 
> > >> not to me ;-) ].  It should be sufficient to state that the 
> > >> embedded element is a complete XML document that is formatted 
> > >> according to the schema referenced by the IANA registration of 
> > >> the ENUM value used for
> > >>> Most of specifications such as XCCDF etc. have versions while 
> > >>> CVE does
> > >> not.
> > >> I misread what you wrote, sorry about that.  I was looking for 
> > >> the syntax of the contents of the [Specification]Version element, 
> > >> and looked in the wrong place.
> > >>
> > >> unexpected string compare results.  It'd be good if the version 
> > >> number could be extracted from the XML Schema for the embedded 
> > >> content (and hence take advantage of the rules in the referenced 
> > >> specification for the syntax of [Specification]Version).
> > >>
> > >> currently at version 5.10 - that's not the same as 5.1, but if 
> > >> it's converted to a number, the result is easy to misparse it as 
> > >> being
> > > equivalent to 5.1 ;-).
> > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., 
> > >> if the
> > > '.'
> > >> causes problems in some tooling?  All of these are easy for a 
> > >> human to sort out, but potential causes of problems in automated
tools.
> > >>> Regarding the issues you kindly raised in the email, let me 
> > >>> describe my understanding.
> > >>>
> > >>> 1)
> > >>> My assumption was, when parsing the xml data, the parser anyway 
> > >>> reads the namespace described in the embedded xml data and parse the
data.
> > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) 
> > >>> use ENUM for dtype and FraudType description.
> > >>> Maybe it would be easier for them to embed/receive/parse a 
> > >>> complete CVE data?
> > >>> If we send a partial CVE or the other structured data, receiver 
> > >>> may suffer from some parsing problem, as you mentioned.
> > >>> Most of specifications such as XCCDF etc. have versions while 
> > >>> CVE does
> > >> not.
> > >>> For clarity I'd suggest not using "Version" as the name of both 
> > >>> an extension attribute and one of the classes in each extension.
> > >>> (1) What strings are valid for SpecificationName?  If the 
> > >>> recipient doesn't understand the SpecificationName, the 
> > >>> information in the extension may be unparseable, so this probably
needs to be controlled.
> > >>>
> > >>> An IANA registry may be appropriate to list the valid strings 
> > >>> and associate each string with its corresponding specification.
> > >>>
> > >>> For example, I believe that the XSD schema for the CVE list 
> > >>> defines a complete XML document, but I suspect that less than a 
> > >>> complete XML document is intended to be embedded because the 
> > >>> proposed extension is part of an IODEF XML document.
> > >>>
> > >>> David L. Black, Distinguished Engineer EMC Corporation, 176 
> > >>> South St., Hopkinton, MA  01748
> > >>>> The attached is the tentative version of the draft prepared 
> > >>>> based on the comments I've received in this mailing list (Thanks a
lot for that).
> > >>>> As you know, there are many ways to embed structured 
> > >>>> information (e.g. CVE and CAPEC) in IODEF since IODEF is 
> > >>>> designed to be very
> > >> flexible.
> > >>>>
> > >>>>>> Takahashi<[email-masked]<mailto:takeshi_takahas
> > >>>>>> hi@n
> > >>>>>> ict.g
> > >>>>
> > >>>>>> o.jp>>
> > >>>>
> > >>>>>> "[email-masked]<mailto:[email-masked]>"
> > >>>>>> <Tho
> > >>>>>> mas.M
> > >>>>
> > >>>>>> "[email-masked]<mailto:[email-masked]>"<[email-masked]<
> > >>>>>> mail
> > >>>>>> to:we
> > >>>>
> > >>>>>> [email-masked]>>,
> > >>>>
> > >>>>>> "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:mi
> > >>>>>> le@i
> > >>>>>> etf.o
> > >>>>
> > >>>>>> rg>>
> > >>>>