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

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 5 Aug 2011 19:19:38 +0900

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