Re: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt

"Moriarty, Kathleen" <kathleen.moriarty@emc.com> Fri, 14 December 2012 15:02 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AAA21F85BF; Fri, 14 Dec 2012 07:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnKHFDbPlkpc; Fri, 14 Dec 2012 07:02:04 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E37AF21F85A6; Fri, 14 Dec 2012 07:02:03 -0800 (PST)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBEF22QH006166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 10:02:02 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 14 Dec 2012 10:01:48 -0500
Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBEF1gL1019645; Fri, 14 Dec 2012 10:01:42 -0500
Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 14 Dec 2012 10:01:41 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "bchandra@secpod.com" <bchandra@secpod.com>, 'Michael Hammer' <michael.hammer@yaanatech.com>
Date: Fri, 14 Dec 2012 10:01:40 -0500
Thread-Topic: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt
Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbgClUlQ2AHLYVJ/l2kwg0CAABEZoA==
Message-ID: <F5063677821E3B4F81ACFB7905573F24CE2B094E@MX15A.corp.emc.com>
References: <B7873C71FEFD6E41B5468506E231FB6E3636BA79@MX14A.corp.emc.com> <E3E9358F-E033-4635-A4BB-E19975625800@c3isecurity.com> <B7873C71FEFD6E41B5468506E231FB6E3A293EC9@MX14A.corp.emc.com> <010201cdd9d2$658b4d00$30a1e700$@secpod.com> <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> <017c01cdda05$6e594c10$4b0be430$@secpod.com>
In-Reply-To: <017c01cdda05$6e594c10$4b0be430$@secpod.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: "mile@ietf.org" <mile@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sacm>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 15:02:06 -0000

Yes, any document posted as an internet draft has been contributed to the IETF.  John has said he would work on a revision based on comments and we will be altering the MILE charter to have this part of the MILE WG documents as it was viewed favorably.  If you have comments, please post them to the MILE list.

The discussed changes were to show the generalized approach first, then the specific examples to MILE so it clearly applies more broadly.

Thank you!
Kathleen

-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Chandrashekhar B
Sent: Friday, December 14, 2012 9:15 AM
To: 'Michael Hammer'
Cc: mile@ietf.org; sacm@ietf.org
Subject: Re: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt

Mike,

There was a comment about SCAP Repo in this thread, which was not initiated
by me. I am responding to that comment now as we addressed that.

Now, is this contribution to IETF? There's a good amount of discussion
happening in the SACM list around content repository. If this is useful,
whoever authors the draft, am happy to share it. The intention is not to
influence anybody but to share it if it make sense.

Chandra.

-----Original Message-----
From: Michael Hammer [mailto:michael.hammer@yaanatech.com] 
Sent: Friday, December 14, 2012 7:22 PM
To: bchandra@secpod.com; johnp.field@emc.com; lnunez@c3isecurity.com
Cc: mile@ietf.org; sacm@ietf.org
Subject: RE: [mile] [sacm] New draft for review and comment:
draft-field-mile-rolie-00.txt

Is this intended to be a contribution to the IETF?

Mike


-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
Chandrashekhar B
Sent: Friday, December 14, 2012 3:10 AM
To: 'Field, John'; 'Luis Nunez'
Cc: mile@ietf.org; sacm@ietf.org
Subject: Re: [mile] [sacm] New draft for review and comment:
draft-field-mile-rolie-00.txt

Reopening an old thread...

>The issues that would need to be resolved include making the 
>authentication
to the scaprepo seamless >(possible, at least in principal, using existing
Web Single Sign On protocols) and dealing with differences in >interaction
style...for example, I notice that scaprepo seems to prefer the use of POST
for all operations >(including a read operation).  As a general rule, it is
best to support GET for read operations, and reserve POST >for write
operations.  But, this is a relatively minor issue at this point.  The more
important point is that by >using a REST approach such an integration would
become possible, and that would be of benefit to users >dealing with
indicators, incident response, and assessment and compliance, etc....we
could tie it all together >quite nicely.

We have now addressed these concerns in SCAP Repo's web service interface.
The authentication and authorization rely on an HTTP Authorization header
containing an optional authorization assertion. I say optional because that
is to be used by subscribers. 

Also, all the interfaces are now HTTP GET based. 

The interface document is available here:
https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be
downloaded from https://www.scaprepo.com

Appreciate your feedback!

Chandra.

-----Original Message-----
From: Luis Nunez [mailto:lnunez@c3isecurity.com]
Sent: Thursday, September 06, 2012 11:36 AM
To: Field, John
Cc: sacm@ietf.org; mile@ietf.org
Subject: Re: [sacm] New draft for review and comment:
draft-field-mile-rolie-00.txt

John,
this definitely is of interest and could be related to past discussions
around content repositories.  

I know of two publicly accessible (REST) repositories that could potential
host this type of content.

http://scaprepo.com/SCAPRepoWebService
http://scapsync.com/api/

NIST is also working on a repository with webservices.

It would be interesting to prototype a sample document and flesh out issues.


-ln

On Sep 6, 2012, at 11:10 AM, Field, John wrote:

> All,
> 
> Cross posting this announcement from MILE to SACM, as I think this may 
> be
of interest within the SCAP community as well.  
> 
> The new draft referenced below describes a RESTful HTTP binding for
sharing incident, indicator, and other cyber security-related information.
In particular, the draft includes a suggested approach to retrieving a
related benchmark resource.  
> 
> I hope you'll find this draft to be of interest.  
> 
> Please post any questions or comments to the MILE list.
> 
> Regards,
> John
> 
> // John P. Field
> // Security Architect
> // EMC Office of the CTO
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Field, John 
> Sent: Thursday, September 06, 2012 10:53 AM
> To: <mile@ietf.org>
> Subject: New draft for review and comment: draft-field-mile-rolie-00.txt
> 
> All,
> 
> Please note that I have just posted a new draft for review and comment.
As stated in the abstract, the draft describes a RESTful HTTP binding for
sharing incident, indicator, and other cyber security-related information.
I hope you'll find this document to be of interest, and I look forward to
discussing any questions and/or comments that the group may have.
> 
> Regards,
> John
> 
> // John P. Field 
> // Security Architect 
> // EMC Office of the CTO 
> 
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Wednesday, September 05, 2012 9:59 PM
> To: Field, John
> Subject: New Version Notification for draft-field-mile-rolie-00.txt
> 
> 
> A new version of I-D, draft-field-mile-rolie-00.txt
> has been successfully submitted by John P. Field and posted to the
> IETF repository.
> 
> Filename:	 draft-field-mile-rolie
> Revision:	 00
> Title:		 Resource-Oriented Lightweight Indicator Exchange
> Creation date:	 2012-09-05
> WG ID:		 Individual Submission
> Number of pages: 41
> URL:
http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-field-mile-rolie
> Htmlized:        http://tools.ietf.org/html/draft-field-mile-rolie-00
> 
> 
> Abstract:
>   This document defines a resource-oriented approach to cyber security
>   information sharing.  Using this approach, a CSIRT or other
>   stakeholder may share and exchange representations of cyber security
>   incidents, indicators, and other related information as Web-
>   addressable resources.  The transport protocol binding is specified
>   as HTTP(S) with a MIME media type of Atom+XML.  An appropriate set of
>   link relation types specific to cyber security information sharing is
>   defined.  The resource representations leverage the existing IODEF
>   [RFC5070] and RID [RFC6545] specifications as appropriate.
>   Coexistence with deployments that conform to existing specifications
>   including RID [RFC6545] and Transport of Real-time Inter-network
>   Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via
>   appropriate use of HTTP status codes.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm