Re: [EXT] Re: [cacao] Use of Other Standards

@Duncan, inline with Jason, maybe I didnât use the right term so let me be a bit more precise:

I am absolutely not to reinvent anything as much as possible because simply we will never have enough resources to do so, so YES we should use standards as much as they exist
I hope I donât need to convince you that I am a big OpenC2 fan
However what I donât know is which is the list of above standards we can use? Do you have such a list? For example

Do we have standards to describe security capabilities in a uniform manner? (IPS, IDS, HIPS, Proxy, Endpoint Security Solutions, etc.)
Do we have standards to describe the target assets in a uniform manner? (I can tell you I was extremely surprised to discover that after few decades there was still no endpoint definitions and many other definitions are missing when I had to do CLESS recently at IETF!)
Do we have standards to talk to different orchestrators? For example maybe a solution to a problem is to chain a new service with an SDN and NFV controller with specific NFVs? (ok here we have standards perhaps we should look at IETF I2NSF?)
Which standards are we going to use to âspeakâ to the SOC or the CDC people (is it what you meant Jason with M2H and H2M?)? Do we want to consider the work done at ITU with X.framcdc?
â

Then do we know well enough those standards to understand if we can use them asis or if we need some amendments?

I hope it clarifies

De : <cacao@lists.oasis-open.org> au nom de Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date : mardi, 17 septembre 2019 Ã 22:07
Ã : "duncan sfractal.com" <duncan@sfractal.com>
Cc : "cacao@lists.oasis-open.org" <cacao@lists.oasis-open.org>
Objet : [EXT] Re: [cacao] Use of Other Standards

I think OpenC2 is definitely going to be an option for the command-and-control side of the playbook, but I do not think it can be mandatory. The C&C side has to remain a bit more agnostic to operationalize CACAO in the near term as OpenC2 is not widely adopted yet.

We also need to remember that not all C&C is M2M (it is also M2H and H2M) so we have to remain open.

-
Jason Keirstead
Chief Architect - IBM Security Threat Management
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

From: duncan sfractal.com <duncan@sfractal.com>
To: "cacao@lists.oasis-open.org" <cacao@lists.oasis-open.org>
Date: 09/17/2019 03:49 PM
Subject: [EXTERNAL] [cacao] Use of Other Standards
Sent by: <cacao@lists.oasis-open.org>

Arnaud proposes âwe are going to have to spend quite some time on the gap analysisâ in response to my comment that we should make use of other standards where possible. I disagree. I think we should use them when we know of them and if someone in the TC brings it to the attention of the group. I wouldnât object to people doing gap analysis but I do not think itâs a necessary prerequisite and I do not think we should slow down to do such a gap analysis. But if there are existing standards, particularly from OASIS, then I think we should at least allow for their use.

Wrt âsomeone in the TC brings it to the attention of the groupâ, I would particularly like to bring up OpenC2 (https://www.oasis-open.org/apps/org/workgroup/openc2/) for the command and control of security technology (eg machine-to-machine atomic actions). The OpenC2 TC recently approved 3 Committee Specifications for the OpenC2 language, one particular actuator, and one particular transport mechanism. Clearly more actuators and more transport specs are needed (and are in preparation) but itâs also likely the language isnât perfect and will need to add something for CACAO use cases. As TC cochair of the OpenC2 TC, I can commit to working with the CACAO TC to fill in any gaps in the OpenC2 Specification so that hopefully OpenC2 can meet the âatomic actionâ needs of CACAO. I am not saying OpenC2 has to be the exclusive C2 mechanism (albeit I wouldnât object to it either) â just that it be one of the mechanisms.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

From: Arnaud Taddei <Arnaud_Taddei@symantec.com>
Date: Tuesday, September 17, 2019 at 12:56 PM
To: "duncan@sfractal.com" <duncan@sfractal.com>, "cacao@lists.oasis-open.org" <cacao@lists.oasis-open.org>
Subject: Re: [EXT] [cacao] Missing requirements

Thank you Duncan and sorry I was late Â hour and I couldnât attend the call 2 weeks ago (am WP3 chairman at ITU-T SG17 and it was WP closing plenary!)

I think we are going to have to spend quite some time on the gap analysis on point 3 from Duncan below before we can even give feedback. But that will produce a lot of value in itself

De : <cacao@lists.oasis-open.org> au nom de "duncan sfractal.com" <duncan@sfractal.com>
Date : mardi, 17 septembre 2019 Ã 18:09
Ã : "cacao@lists.oasis-open.org" <cacao@lists.oasis-open.org>
Objet : [EXT] [cacao] Missing requirements

This is to document my comments at the meeting. I see 4 requirements missing from the slides that got talked about:

Vendor independent interoperability
Agile â break the CACAO work into phases an get âminimum viable productâ out sooner rather than later, rather than a âcompleteâ standard taking much more time
Use other standards when possible
Give feedback to other standards if they are missing something CACAO needs (specifically OpenC2 as the command and control language is new and needs use cases like CACAO to move to itâs next phases). Point being (1)use other standard if possible. (2)If itâs not possible, see other standard can be changed so it is possible before inventing a new way.

I would like to see these included in the meeting notes as brought up as potentially missing from base set of requirements presented. Iâm not sure process on reaching consensus on the ones presented or on these âadditionsâ (no objections?).

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

cacao message