Re: [Cacao] [EXT] Re: [EXT] RE: Charter

"Jason Keirstead" <Jason.Keirstead@ca.ibm.com> Wed, 19 June 2019 13:04 UTC

Return-Path: <Jason.Keirstead@ca.ibm.com>
X-Original-To: cacao@ietfa.amsl.com
Delivered-To: cacao@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA66412045C for <cacao@ietfa.amsl.com>; Wed, 19 Jun 2019 06:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgkfxthrGNvm for <cacao@ietfa.amsl.com>; Wed, 19 Jun 2019 06:04:55 -0700 (PDT)
Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB3712007A for <cacao@ietf.org>; Wed, 19 Jun 2019 06:04:55 -0700 (PDT)
Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5JD11IE107391 for <cacao@ietf.org>; Wed, 19 Jun 2019 09:04:53 -0400
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.82]) by mx0b-001b2d01.pphosted.com with ESMTP id 2t7m46n716-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <cacao@ietf.org>; Wed, 19 Jun 2019 09:04:53 -0400
Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for <cacao@ietf.org> from <Jason.Keirstead@ca.ibm.com>; Wed, 19 Jun 2019 13:04:52 -0000
Received: from us1a3-smtp07.a3.dal06.isc4sb.com (10.146.103.14) by smtp.notes.na.collabserv.com (10.106.227.105) with smtp.notes.na.collabserv.com ESMTP; Wed, 19 Jun 2019 13:04:25 -0000
Received: from us1a3-mail191.a3.dal06.isc4sb.com ([10.146.77.51]) by us1a3-smtp07.a3.dal06.isc4sb.com with ESMTP id 2019061913042523-485296 ; Wed, 19 Jun 2019 13:04:25 +0000
In-Reply-To: <6C013E36-4F2C-4B9B-B2AB-7F45558836E9@interdiscount.ch>
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
To: Carolin.Baumgartner@interdiscount.ch
Cc: athomson@lookingglasscyber.com, Bret_Jordan@symantec.com, cacao@ietf.org, jordan.ietf@gmail.com, mohamed.boucadair@orange.com
Date: Wed, 19 Jun 2019 13:04:25 +0000
Sensitivity:
References: <6C013E36-4F2C-4B9B-B2AB-7F45558836E9@interdiscount.ch>, <BYAPR16MB30133C3DAF3CF2060CE4B565EDEA0@BYAPR16MB3013.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EAA890F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB30137AC9C00633E80C7C8D65EDEA0@BYAPR16MB3013.namprd16.prod.outlook.com> <779CCF55-FABB-4BA1-9D84-1D9761A32944@tzi.org> <BYAPR16MB30139D44233E0256099264DCEDEA0@BYAPR16MB3013.namprd16.prod.outlook.com> <25088b69-1225-3f3c-b0e2-38e25f1f48fb@article19.org> <A7038D6C-C1C3-4B6A-B928-AC87F7A87AFC@gmail.com> <6130.1560896363@dooku.sandelman.ca> <634A811D-3674-42ED-A46F-9CDD8EFD5CEE@symantec.com> <787AE7BB302AE849A7480A190F8B93302EAA8FE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <B29832F6-8239-498C-A65D-A22B70A4A691@gmail.com> <787AE7BB302AE849A7480A190F8B93302EAA905B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <05E3F9C3-20C6-47E4-9B68-DE9D81D9C358@lookingglasscyber.com> <787AE7BB302AE849A7480A190F8B93302EAA917C@OPEXCAUBMA2.corporate.adroot. infra.ftgroup> <92A6388D-ED3D-4B77-BA01-AE97E201681F@symantec.com> <787AE7BB302AE849A7480A190F8B93302EAA91C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <A8E5A7FB-F771-477C-90E5-4E2DE4FA69E6@gmail.com>
Importance: Normal
X-Priority: 3 (Normal)
X-Mailer: IBM Verse Build 17652-1619 | IBM Domino Build SCN1812108_20180501T0841_FP55 May 22, 2019 at 11:09
X-LLNOutbound: False
X-Disclaimed: 37267
X-TNEFEvaluated: 1
Content-Type: text/html; charset="UTF-8"
x-cbid: 19061913-5101-0000-0000-0000101061C0
X-IBM-SpamModules-Scores: BY=0.293961; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.371236; ST=0; TS=0; UL=0; ISC=; MB=0.098024
X-IBM-SpamModules-Versions: BY=3.00011290; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000286; SDB=6.01220225; UDB=6.00641889; IPR=6.01001366; BA=6.00006337; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00027374; XFM=3.00000015; UTC=2019-06-19 13:04:50
X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused
X-IBM-AV-VERSION: SAVI=2019-06-19 05:38:07 - 6.00010066
x-cbparentid: 19061913-5102-0000-0000-000072446880
Message-Id: <OFD12C0FCD.00FE8694-ON0025841E.0047A44B-0025841E.0047D0CA@notes.na.collabserv.com>
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-UnRewURL: 3 URL's were un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-19_07:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/xrstjGw4DsP-3L5qpANSGws8Kig>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter
X-BeenThere: cacao@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Collaborative Automated Course of Action Operations <cacao.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cacao>, <mailto:cacao-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cacao/>
List-Post: <mailto:cacao@ietf.org>
List-Help: <mailto:cacao-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cacao>, <mailto:cacao-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 13:04:58 -0000

I think it is also important to point out here that sharing of cybersecurity playbooks is not a high volume activity. It is not akin to sharing real-time cybersecurity data related to situational awareness, or even data like threat intelligence. Efficiencies gained at the wire protocol or on-disk regarding CBOR vs JSON will not be consequential to anyone in practice for this kind of data. What is more paramount is ease of interoperability between all of the many kinds of solutions looking to produce, revise, curate, and consume these playbooks.
 
-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson
 
 
----- Original message -----
From: <Carolin.Baumgartner@interdiscount.ch>
Sent by: "Cacao" <cacao-bounces@ietf.org>
To: <jordan.ietf@gmail.com>, <mohamed.boucadair@orange.com>
Cc: Bret_Jordan@symantec.com, cacao@ietf.org, athomson@lookingglasscyber.com
Subject: [EXTERNAL] Re: [Cacao] [EXT] Re: [EXT] RE: Charter
Date: Wed, Jun 19, 2019 9:58 AM
 

+1 If we want this to take off I support to be as close to the current market as possible

 

From: Cacao <cacao-bounces@ietf.org> on behalf of Bret Jordan <jordan.ietf@gmail.com>
Date: Wednesday, 19 June 2019 at 14:07
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cacao@ietf.org" <cacao@ietf.org>, Allan Thomson <athomson@lookingglasscyber.com>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

 

The initial version needs to be done in JSON, if we want the market as a whole to adopt this. I have walked the floor at RSA and Blackhat for the past 2 years talking to all of the vendors that would potentially implement this.  They all say the same thing.  If it was JSON, they could easily do it.  If it is something else, well, maybe, maybe not.  We would then be reliant on market pressure and consumers to influence vendors to adopt.  That can take 10 years or more. Usually by then, the standard is failed and the market has moved on.  Let us not be yet another standard on the dusty shelves of of the SDO Library.

 

Further, anything not JSON would require the Web2.0 world of products and APIs to support something totally different.  CBOR may take off at some point.  YANG my take off at some point.  XML may come back from the dead. But right now, today, JSON is the model that the developers of products use and know. Adding additional hurtles for the solution to be adopted is not a good idea for this first version.  

 

Overtime, once we get our first versions done and out the door and they get adopted, we can make changes or add functionality based on market demand.  If the market comes back and says, hey, we really need this done in a binary format like Protobuf, then great.  We can write a binding for that.   

 

 

 

Thanks,

Bret

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."



On Jun 19, 2019, at 1:41 PM, mohamed.boucadair@orange.com wrote:

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Bret Jordan [mailto:Bret_Jordan@symantec.com] 
Envoyé : mercredi 19 juin 2019 13:26
À : BOUCADAIR Mohamed TGI/OLN
Cc : Allan Thomson; Bret Jordan; cacao@ietf.org

Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

 

I fundamentally do not support the idea of not using JSON for this work.

[Med] Are you referring to application encoding or data modelling part?

 

 Over time we may write a binding document for some other serialization.  But we need something that can be implemented and have guaranteed interoperability.  

[Med] Why CBOR wouldn’t be an option here? BTW, there might be other requirements such as compactness (that may be worth when actions are enriched/augmented on-path). As a group, we don’t have yet the full set of requirements to make a design choice.

 

In order to gain mass adoption, we need a solution that can be used by the existing eco system.  

 

Bret 

Sent from my Commodore 128D