Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt
"Chandrashekhar B" <bchandra@secpod.com> Thu, 04 October 2012 13:33 UTC
Return-Path: <bchandra@secpod.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8275B21F8648; Thu, 4 Oct 2012 06:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.816
X-Spam-Level:
X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SARE_OBFU_SPLIT_HR2=0.183]
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 rasjn+zynzSo; Thu, 4 Oct 2012 06:33:46 -0700 (PDT)
Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8598D21F8647; Thu, 4 Oct 2012 06:33:46 -0700 (PDT)
Received: from [182.72.99.242] (port=2564 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <bchandra@secpod.com>) id 1TJlYe-0002l4-Qo; Thu, 04 Oct 2012 19:03:45 +0530
From: Chandrashekhar B <bchandra@secpod.com>
To: "'Field, John'" <johnp.field@emc.com>, 'Luis Nunez' <lnunez@c3isecurity.com>
References: <B7873C71FEFD6E41B5468506E231FB6E3636BA79@MX14A.corp.emc.com> <E3E9358F-E033-4635-A4BB-E19975625800@c3isecurity.com> <B7873C71FEFD6E41B5468506E231FB6E3A293EC9@MX14A.corp.emc.com>
In-Reply-To: <B7873C71FEFD6E41B5468506E231FB6E3A293EC9@MX14A.corp.emc.com>
Date: Thu, 04 Oct 2012 19:03:38 +0530
Organization: SecPod Technologies
Message-ID: <013e01cda234$def74ac0$9ce5e040$@secpod.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbiXHJXcYA==
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - secpod.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-Mailman-Approved-At: Thu, 04 Oct 2012 06:35:47 -0700
Cc: mile@ietf.org, sacm@ietf.org
Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: bchandra@secpod.com
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2012 13:33:47 -0000
Thanks John. Authentication was the primary reason for a POST request, we'll look into your suggestion. The example helped quickly grasp the idea. We'll look into the draft in detail and come back with any comments. There are three specs now which are somewhat related although each for different purposes, 1. SCAP Messages for IF-M draft - http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm 2. Resource-Oriented Lightweight Indicator Exchange - http://www.ietf.org/id/draft-field-mile-rolie-00.txt 3. Content Repository interface - http://tools.ietf.org/html/draft-waltermire-content-repository-00 I think all should align on a similar content exchange mechanism. Just a thought, am not sure if it really make sense, haven't gone through each of them in detail. Thanks, Chandra. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Field, John Sent: Thursday, October 04, 2012 1:28 AM To: Luis Nunez Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Luis, Sorry for the delay in responding, I have been quite busy with a few projects and also traveling. Thanks for the feedback; scaprepo does look interesting... I can easily imagine an integration where the representation of an "incident" or "indicator" resource could also include a link to a corresponding SCAP repository resource, say an OVAL benchmark or an OVAL def, etc. that is related to the requested resource...a quick hack of an example might look something like... HTTP/1.1 200 OK Date: Wed, 03 Oct 2012 17:30:11 GMT Content-Length: nnn Content-Type: application/atom+xml;type=entry;charset="utf-8" <?xml version="1.0" encoding="UTF-8"?> <entry> <id>http://www.example.org/csirt/private/incidents/123456</id> <title>Sample Incident</title> <link href="http://www.example.org/csirt/private/incidents/123456" rel="self"/> <!-- by convention --> <link href="http://www.example.org/csirt/private/incidents/123456" rel="alternate"/> <!-- required by Atom spec --> <published>2012-08-04T18:13:51.0Z</published> <updated>2012-08-05T18:13:51.0Z</updated> <!-- the next and previous are just sequential access, may not map to anything related to this IODEF Incident ID --> <link href="http://www.example.org/csirt/private/incidents/123457" rel="next"/> <link href="http://www.example.org/csirt/private/incidents/123455" rel="previous"/> <!-- link to SCAP Repo --> <link href=" https://www.scaprepo.com/SCAPRepoWebService/something..." rel="scaprepo"/> <content type="application/xml"> <iodef:IODEF-Document lang="en" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> <iodef:Incident purpose="traceback" restriction="need-to-know"> ... </iodef:IODEF-Document> </content> </entry> The possibility of such an integration is exactly what motivated the draft. 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. Thanks for commenting. I'll take a deeper look at scaprepo when I get some more time. Regards, John -----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] New draft for review and comment: draft-fi… Field, John
- Re: [mile] [sacm] New draft for review and commen… Luis Nunez
- Re: [mile] [sacm] New draft for review and commen… Field, John
- Re: [mile] [sacm] New draft for review and commen… Luis Nunez
- Re: [mile] [sacm] New draft for review and commen… Chandrashekhar B
- Re: [mile] [sacm] New draft for review and commen… Chandrashekhar B
- Re: [mile] [sacm] New draft for review and commen… Chandrashekhar B
- Re: [mile] [sacm] New draft for review and commen… Moriarty, Kathleen