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 <>
To:
          ""
 <>
Date:
          09/17/2019
 03:49 PM
Subject:
          [EXTERNAL]
 [cacao] Use of Other Standards
Sent
 by:          <>
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 <>
Date:  Tuesday, September 17, 2019 at 12:56 PM
To:  "" <>, ""
 <>
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
 :  <> au nom de "duncan sfractal.com"
 <>  Date :  mardi, 17 septembre 2019 Ã 18:09  Ã :  "" <>  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
/