[mile] Less is More

"Stoecker, Paul" <Paul.Stoecker@rsa.com> Thu, 07 March 2013 12:44 UTC

Return-Path: <Paul.Stoecker@rsa.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 C807021F8A4E for <mile@ietfa.amsl.com>; Thu, 7 Mar 2013 04:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct5atd5MHHRc for <mile@ietfa.amsl.com>; Thu, 7 Mar 2013 04:44:21 -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 D703221F8CB4 for <mile@ietf.org>; Thu, 7 Mar 2013 04:44:20 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r27CiJrG031021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mile@ietf.org>; Thu, 7 Mar 2013 07:44:19 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <mile@ietf.org>; Thu, 7 Mar 2013 07:44:04 -0500
Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r27Ci4kR024662 for <mile@ietf.org>; Thu, 7 Mar 2013 07:44:04 -0500
Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 7 Mar 2013 07:44:04 -0500
Received: from MX103CL01.corp.emc.com ([169.254.5.162]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.02.0342.003; Thu, 7 Mar 2013 07:44:04 -0500
From: "Stoecker, Paul" <Paul.Stoecker@rsa.com>
To: "mile@ietf.org" <mile@ietf.org>
Thread-Topic: Less is More
Thread-Index: Ac4bMXJvoc30rQSbSmWkcAsaLlcWKA==
Date: Thu, 07 Mar 2013 12:44:02 +0000
Message-ID: <82B14152-7F29-49A0-90E9-3D1414B9D4F0@rsa.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <032C9505F7677E4090832C31FC9F1538@mail.corp.emc.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [mile] Less is More
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 07 Mar 2013 12:44:31 -0000

As we have gone through this process of changing IODEF to essentially morph it from something used to share incidents to something used to share indicators, I have been getting the feeling that we are trying to make it everything to everybody.

I had thought that the goal was to be able to share IOCs so that the adage of "my detection becomes your prevention" will ring true.  If that is our goal isn't there a design paradigm that for efficiency you do the minimum needed to effectively solve the problem?  To that end, what is the minimum amount of context that we need to share IOCs?  Do we really need to pull in ARF, RFC 5901, etc.?  

Is IODEF really the solution as it was based on sharing Incident Information rather than IOCs?  Should IODEF become the Indicator Object Definition Exchange Format?  If so, aren't there better ways to handle some of the indicator data..like the System and Node classes being rewritten to handle multiple IPs better?  I guess what I am saying is, if you had to design a schema for the purpose of sharing IOCs starting from nothing would it turn out to look like IODEF or would it be something fundamentally different?

I am not being critical of the work to date or of some of the ideas being put forward, but I do like to do these types of thought experiments during a design process to make sure that we are happy with the direction and don't need to make any course corrections.  I see all of the discussion about adding more context and it starts me thinking that we are adding "complexity" and moving away from "less is more".  

One of the things about me, having spent time in a SOC is that I want to get immediately down to the issue.  Just tell me what I need to know to detect the malicious activity.  Once I find it I can take some very coarse, rudimentary actions to protect my environment while it gets escalated to a team to research it and gather the context needed to create effective long-term permanent solutions.  Hence my concerns about trying to do too much with IODEF.

Anyway, this is what happens when I am on holiday and my mind frees up to think about things ;-). 

Regards,

Paul

Sent from my iPad