Subject: Re: [mile] SCI document and WG decision

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 15 Oct 2012 11:38:17 +0900

+1

Thank you very much for your kind assistance, and I am sorry for very late
response.

Take

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Panos Kampanakis (pkampana)
Sent: Tuesday, August 21, 2012 2:24 AM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] SCI document and WG decision

+1
Panos

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Moriarty, Kathleen
Sent: Monday, August 20, 2012 9:40 AM
To: [email-masked]
Subject: [mile] SCI document and WG decision

Hello,
 
At the IETF meeting in Vancouver, the WG consensus was to remove the
referenced specifications from the SCI draft so that the document could
progress without IP issues.  In this model, the draft would have empty
tables and the WG would then decide which specifications or standards
references would get added into the document.  The thought was that the WG
could think more carefully about what specifications were important to
reference to meet relevant use cases for the community.  The process would
include a review of the specification to ensure we could reference it,
including that the specification or standard is a document that the IETF can
normatively reference.
 
Does the WG agree on this approach?  (consensus needs to be shown on the
list in one direction or another to formalize and move forward).
 
We will give this a two week period for responses, finishing the morning of
September 3rd.
 
Thank you in advance!  
Kathleen

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 15 Oct 2012 14:36:26 +0900

Hello all,

I was late for the discussion, but let me join in.
One simple example scenario is as below.

It is a scenario where an organization is reporting possible incident to its
internal administrator, who analyzes and minimizes the damages caused by
that.

The organization realizes some anomaly and judges it as a potential
incident.
Multiple "sensors" inside the organization then send related log
information. (It could be IODEF with CEE/Cybox embedded)
In case if the sensors (or any other computer administered by operators) can
identify which vulnerability was exploited, they may also send the
identifier . (IODEF with CVE identifier)

The administrator then notify the organization's internal resources that may
have the same vulnerability.
To do so, it is assumed that the administrator collects system information
and security status (Asset Identification, ARF, CPE, etc.) periodically or
following certain rules.

Does it make sense?
CEE/Cybox, CVE identifier, AI, ARF, CPE can be seen in the above scenario.

Take

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Moriarty, Kathleen
Sent: Tuesday, September 11, 2012 11:23 PM
To: [email-masked]
Subject: Re: [mile] SCI document and WG decision

Hello,

The list is in agreement with the decision from the IETF meeting in
Vancouver and this message ends the call for opinions.  

This means that we as a group have some work to do.  We will start with the
SCI draft not having any included schemas, then decide what are the needed
schemas to incorporate in the draft prior to WGLC and publication.  The SCI
draft does create IANA tables where additional schemas can be added to the
SCI method of extending IODEF.

The SCI draft will incorporate developed schemas (not extensions specific to
IODEF as those can be drafts on their own) that add value by enabling the
IODEF schema to be extended and creating relationships to these schema
standards.  The format Take chose in the SCI draft categorizes schemas to
create those relationships and creates patterns for the schemas to be added.

I think the most useful approach here would be to have use case driven
discussions.  

We need at least ONE schema to be agreed upon for the entire draft to meet
the IETF definition and purpose for having a Mandatory To Implement (MTI)
schema for the SCI draft.  One MTI is beneficial for vendors to be able to
claim interoperability, but not necessarily to require full support for all
the schemas in the eventual tables as the vendors may be supporting
different use cases and we do not want to make it too hard to implement as
that could delay implementations or stop them altogether.

Let’s not get into the MTI discussion yet, but discuss schemas that are
needed to compliment IODEF is a standard way to enable business use cases to
be met.

I’ll start a new thread asking for use case driven examples and the schemas
that best fit those use cases.

Thank you,
Kathleen

From: Panos Kampanakis (pkampana) [mailto:[email-masked]] 
Sent: Monday, August 20, 2012 1:24 PM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: SCI document and WG decision

+1
Panos

Hello,

 
 
Thank you in advance!  
Kathleen