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