Subject: [Cacao] Call for CACAO Charter Consensus

From: Joseph Salowey <[email-masked]>
Date: Fri, 10 May 2019 06:39:15 -0700

At the CACAO meeting at IETF 105 in Prague there was significant
interest in the CACAO problem statement.  We want to reach consensus
for a charter for a working group.  A draft charter has been posted to
the list [1].

We need to continue this discussion on the email list as well as gauge
continued interest in participating in this work.  Please do so by
responding to the following questions:

  1.  Do you support this charter text (full text also provided at the
end of email or at [1])?  Please submit objections or blocking
concerns to the list.
  2.  Are you willing to author or participate in the development of
the drafts of this WG?
  3.  Are you willing to help review the drafts of this WG?
  4.  Are you interested in implementing drafts of this WG?

Please provide comments including proposed text changes ASAP to
provide ample time for discussion.  This call for consensus ends on
May 27, 2019.

Thanks,

Joe & Chris

[1] https://mailarchive.ietf.org/arch/msg/cacao/QKVvohhYvwU46jcsLYyYY1agPTU

Charter text copied below:

--------------

# Introduction
To defend against threat actors and their tactics, techniques, and
procedures, organizations need to manually identify, create, and
document prevention, mitigation, and remediation steps. These steps
when grouped together into a course of action (COA) / playbook are
used to protect systems, networks, data, and users. The problem is,
once these steps have been created there is no standardized and
structured way to document them, verify they were correctly executed,
or easily share them across organizational boundaries and technology
stacks.

This working group will create a standard that implements the playbook
model for cybersecurity operations.

This solution will specifically enable:

 1. the creation and documentation of COAs in a structured
machine-readable format
 2. organizations to perform attestation including verification and
authentication  on COAs
 3. the sharing and distribution of COAs across organizational
boundaries and technology stacks that may include protocols, apis,
interfaces and other related technology to support sharing.
 4. the verification of COA correctness prior to deployment.
 5. the monitoring of COA activity after successful deployment.

This solution will contain (at a minimum) a standard JSON based data
model, a defined set of functional capabilities and associated
interfaces, and a protocol. This solution will also provide a data
model for systems to confirm the status of the COA execution, however,
it will be agnostic of how the COA is implemented by the system.

Each collaborative course of action, such as recommended prevention,
mitigation and remediation steps, will consist of a sequence of cyber
defense actions that can be executed by the various systems that can
act on those actions. Further, these COAs will be coordinated and
deployed across heterogeneous cyber security systems such that both
the actions requested and the resultant outcomes may be verified.
These COA actions will be referenceable in a data structure like the
OASIS STIX V2 model that provides support for related data such as
threat actors, campaigns, intrusion sets, malware, attack patterns,
and other adversarial techniques, tactics, and procedures.

Where possible the working group will consider existing efforts, like
OASIS OpenC2 and IETF I2NSF that define the atomic actions to be
included in a process or sequence. The working group will not consider
how shared actions are used/enforced, except where a response is
expected for a specific action or step.

# Goals and Deliverables
This working group has the following major goals and deliverables

 - CACAO Use Cases and Requirements
   - Specify the use cases and requirements
 - CACAO Functional Architecture: Roles and Interfaces
   - Specify the system functions and roles that are needed to enable
Collaborative Courses of Action
 - CACAO Protocol Specification
   - Specify and standardize the configuration for at least one
protocol that can be used to distribute courses of action in both a
direct delivery and publish-subscribe method
 - CACAO Distribution and Response Application Layer Protocol
   - Specify the protocol which may include apis, interfaces and other
related technology to support the requirements identified for the
protocol.
 - CACAO JSON Data Model
   - Create a JSON data model that can capture and enable
collaborative courses of action
 - CACAO Interoperability Test Documents
   - Define and create a series of tests and documents to assist with
interoperability of the various systems involved.

The working group may decide to not publish the use cases and
requirements; and test documents. That decision will be made during
the lifetime of the working group.

---

From: <[email-masked]>
Date: Fri, 10 May 2019 13:52:41 +0000

I am still interested and support the charter. I am not sure what to make out of this sentence though

“The working group may decide to not publish the use cases and requirements; and test documents.”

I am willing to review documents

Carolin

From: Cacao <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Date: Friday, 10 May 2019 at 15:39
To: "[email-masked]" <[email-masked]>
Subject: [Cacao] Call for CACAO Charter Consensus

At the CACAO meeting at IETF 105 in Prague there was significant interest in the CACAO problem statement.  We want to reach consensus for a charter for a working group.  A draft charter has been posted to the list [1]..

We need to continue this discussion on the email list as well as gauge continued interest in participating in this work.  Please do so by responding to the following questions:

  1.  Do you support this charter text (full text also provided at the end of email or at [1])?  Please submit objections or blocking concerns to the list.

  2.  Are you willing to author or participate in the development of the drafts of this WG?

Please provide comments including proposed text changes ASAP to provide ample time for discussion.  This call for consensus ends on May 27, 2019.

Thanks,

Joe & Chris

--------------

# Introduction

To defend against threat actors and their tactics, techniques, and procedures, organizations need to manually identify, create, and document prevention, mitigation, and remediation steps. These steps when grouped together into a course of action (COA) / playbook are used to protect systems, networks, data, and users. The problem is, once these steps have been created there is no standardized and structured way to document them, verify they were correctly executed, or easily share them across organizational boundaries and technology stacks.

This working group will create a standard that implements the playbook model for cybersecurity operations.

 1. the creation and documentation of COAs in a structured machine-readable format

 2. organizations to perform attestation including verification and authentication  on COAs

 3. the sharing and distribution of COAs across organizational boundaries and technology stacks that may include protocols, apis, interfaces and other related technology to support sharing.

This solution will contain (at a minimum) a standard JSON based data model, a defined set of functional capabilities and associated interfaces, and a protocol. This solution will also provide a data model for systems to confirm the status of the COA execution, however, it will be agnostic of how the COA is implemented by the system.

Each collaborative course of action, such as recommended prevention, mitigation and remediation steps, will consist of a sequence of cyber defense actions that can be executed by the various systems that can act on those actions. Further, these COAs will be coordinated and deployed across heterogeneous cyber security systems such that both the actions requested and the resultant outcomes may be verified. These COA actions will be referenceable in a data structure like the OASIS STIX V2 model that provides support for related data such as threat actors, campaigns, intrusion sets, malware, attack patterns, and other adversarial techniques, tactics, and procedures.

Where possible the working group will consider existing efforts, like OASIS OpenC2 and IETF I2NSF that define the atomic actions to be included in a process or sequence. The working group will not consider how shared actions are used/enforced, except where a response is expected for a specific action or step.

# Goals and Deliverables

   - Specify the system functions and roles that are needed to enable Collaborative Courses of Action

   - Specify and standardize the configuration for at least one protocol that can be used to distribute courses of action in both a direct delivery and publish-subscribe method

   - Specify the protocol which may include apis, interfaces and other related technology to support the requirements identified for the protocol.

 - CACAO JSON Data Model

   - Create a JSON data model that can capture and enable collaborative courses of action

   - Define and create a series of tests and documents to assist with interoperability of the various systems involved.

The working group may decide to not publish the use cases and requirements; and test documents. That decision will be made during the lifetime of the working group.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 10 May 2019 18:31:28 +0100

I obviously fully support this work.  I will write documents, write code, and review documents.   This work is really the next step beyond CTI and is critically needed.  

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 May 10, 2019, at 2:52 PM, [email-masked] wrote:
> 
> From: Cacao <[email-masked] <mailto:[email-masked]>> on behalf of Joseph Salowey <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> [1] https://mailarchive.ietf.org/arch/msg/cacao/QKVvohhYvwU46jcsLYyYY1agPTU <https://mailarchive.ietf.org/arch/msg/cacao/QKVvohhYvwU46jcsLYyYY1agPTU>
>  
> -- 
> Cacao mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>

---

From: Allan Thomson <[email-masked]>
Date: Fri, 10 May 2019 18:33:34 +0000

Fully agree with the need for this work and will continue to contribute whether that is requirements, architecture specifications, test cases, test code….etc and support it moving forward.

Regards

Allan

From: Cacao <[email-masked]> on behalf of Bret Jordan <[email-masked]>
Date: Friday, May 10, 2019 at 10:31 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] Call for CACAO Charter Consensus

Thanks,
Bret

On May 10, 2019, at 2:52 PM, [email-masked]<mailto:[email-masked]> wrote:

Carolin

From: Cacao <[email-masked]<mailto:[email-masked]>> on behalf of Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Date: Friday, 10 May 2019 at 15:39
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Cacao] Call for CACAO Charter Consensus

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

 - CACAO JSON Data Model

The working group may decide to not publish the use cases and requirements; and test documents. That decision will be made during the lifetime of the working group.
--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cacao

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 10 May 2019 12:57:26 -0700

> requirements; and test documents.”

[Joe] Since these documents are informational it is the choice of the
working group and chairs to determine whether they want to spend the
resources to take these documents through the entire IETF process to
publication.   Since they are listed as deliverables the expectation is
that we would get working group consensus on these documents.

> *From: *Cacao <[email-masked]> on behalf of Joseph Salowey <
> [email-masked]>
> *Date: *Friday, 10 May 2019 at 15:39
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Cacao] Call for CACAO Charter Consensus
>
>
>
> [email-masked]

---

From: "Jyoti Verma (jyoverma)" <[email-masked]>
Date: Fri, 10 May 2019 20:21:24 +0000

I support this work and the need for it. Will continue to contribute towards any test code/documentation write-up, review etc.

Thanks,
Jyoti

From: Cacao <[email-masked]> on behalf of Allan Thomson <[email-masked]>
Date: Friday, May 10, 2019 at 11:33 AM
To: Bret Jordan <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] Call for CACAO Charter Consensus

Regards

Allan

Thanks,
Bret

Carolin

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

 - CACAO JSON Data Model

---

From: Jason Webb <[email-masked]>
Date: Fri, 10 May 2019 21:42:03 +0000

I also fully support this work and will continue to support and contribute going forward.

Jason Webb

________________________________
From: Cacao <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Sent: Friday, May 10, 2019 7:39 AM
To: [email-masked]
Subject: [Cacao] Call for CACAO Charter Consensus

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 12 May 2019 23:45:31 +0000

From: Cacao [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Friday, May 10, 2019 3:57 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Cacao] Call for CACAO Charter Consensus

On Fri, May 10, 2019 at 6:52 AM <[email-masked]<mailto:[email-masked]>> wrote:
I am still interested and support the charter. I am not sure what to make out of this sentence though

[Joe] Since these documents are informational it is the choice of the working group and chairs to determine whether they want to spend the resources to take these documents through the entire IETF process to publication.   Since they are listed as deliverables the expectation is that we would get working group consensus on these documents.

[Roman] Further background on this class of supporting documents can be found here:

https://www.ietf.org/blog/support-documents-ietf-working-groups/

Carolin

At the CACAO meeting at IETF 105 in Prague there was significant interest in the CACAO problem statement.  We want to reach consensus for a charter for a working group.  A draft charter has been posted to the list [1]...

Thanks,

Joe & Chris

--------------

# Introduction

 1.. the creation and documentation of COAs in a structured machine-readable format

 2.. organizations to perform attestation including verification and authentication  on COAs

 3.. the sharing and distribution of COAs across organizational boundaries and technology stacks that may include protocols, apis, interfaces and other related technology to support sharing.

 4.. the verification of COA correctness prior to deployment.

 5.. the monitoring of COA activity after successful deployment.

# Goals and Deliverables

 - CACAO JSON Data Model

---

From: Michael McBride <[email-masked]>
Date: Mon, 13 May 2019 23:02:56 +0000

I too support this work and will contribute.

mike

From: Cacao [mailto:[email-masked]] On Behalf Of Jason Webb
Sent: Friday, May 10, 2019 2:42 PM
To: Joseph Salowey <[email-masked]>; [email-masked]
Subject: Re: [Cacao] Call for CACAO Charter Consensus

Jason Webb

To: [email-masked]<mailto:[email-masked]>

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

 - CACAO JSON Data Model

---

From: <[email-masked]>
Date: Tue, 14 May 2019 10:16:23 +0000

Ah ok, that helps, thanks

From: Joseph Salowey <[email-masked]>
Date: Friday, 10 May 2019 at 21:57
To: Baumgartner Carolin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] Call for CACAO Charter Consensus

Carolin

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

 - CACAO JSON Data Model

---

From: Roelof DuToit <[email-masked]>
Date: Wed, 22 May 2019 12:26:29 -0400

I support this much needed work and are willing to review drafts (at a minimum.. perhaps contribute more as time allows).

--Roelof

From: Joseph Salowey <mailto:[email-masked]>
Date: May 10, 2019 at 7:39:15 AM MDT
To: mailto:[email-masked]
Subject: [Cacao] Call for CACAO Charter Consensus

Thanks, 

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

-- 
Cacao mailing list
mailto:[email-masked]

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Wed, 22 May 2019 19:36:57 +0000

I agree with the charter, I support this work and think this is important and urgent, I will provide reviews and documentation contributions

Sent from ProtonMail Mobile

Le ven., mai 10, 2019 à 15:39, Joseph Salowey <[email-masked]> a écrit :

> [1]
> https://mailarchive.ietf.org/arch/msg/cacao/QKVvohhYvwU46jcsLYyYY1agPTU
>

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 23 May 2019 19:37:46 +0000

Hi!

> Sent: Friday, May 10, 2019 9:39 AM
> To: [email-masked]
> At the CACAO meeting at IETF 105 in Prague there was significant interest in
> the CACAO problem statement.  We want to reach consensus for a charter
> for a working group.  A draft charter has been posted to the list [1]..
> continued interest in participating in this work.  Please do so by responding
> to the following questions:
> 
>   1.  Do you support this charter text (full text also provided at the end of
> email or at [1])?  Please submit objections or blocking concerns to the list.

I support the spirit of the proposed work.

Per the charter, at the macro level, I think it is a too broad in scope right now.  I support the work items related to use cases, architecture, test cases, data model and exchange protocol.  I believe this amounts to items #1 - 3 in the introduction.  The bounds of item #5 ("the monitoring of COA activity after successful deployment") which I'm assuming to be work item "CACAO Distribution and Response Application Layer Protocol" does not seem adequately explained or bounded to me.

I also have more detailed concerns and clarifying question with the current charter text noted inline below.

Regards,
Roman

> Please provide comments including proposed text changes ASAP to provide
> ample time for discussion.  This call for consensus ends on May 27, 2019.
> 
> Thanks,
> Joe & Chris
> [1]
> procedures, organizations need to manually identify, create, and document
> prevention, mitigation, and remediation steps. These steps when grouped
> together into a course of action (COA) / playbook are used to protect
> systems, networks, data, and users. The problem is, once these steps have
> been created there is no standardized and structured way to document
> them, verify they were correctly executed, or easily share them across
> organizational boundaries and technology stacks.
> 
> 
>  1. the creation and documentation of COAs in a structured machine-
> readable format  2. organizations to perform attestation including
> verification and authentication  on COAs  

I'm concerned that attestation is an overloaded term.  Does "attestation" mean more than "verification and authentication"?  This topic got a lot of discussion during the preparation for the RATS chartering process.

> 3. the sharing and distribution of
> COAs across organizational boundaries and technology stacks that may
> include protocols, apis, interfaces and other related technology to support
> sharing.

What is "correctness" in this context?

> model, a defined set of functional capabilities and associated interfaces, and
> a protocol. This solution will also provide a data model for systems to
> confirm the status of the COA execution, however, it will be agnostic of how
> the COA is implemented by the system.

Is the JSON data model mentioned in the first sentence the same one as mentioned in the second?  I'm assuming yes because the deliverables only list one.

The above text describes only one protocol, but the deliverables list two.  What is the second protocol doing?

> defense actions that can be executed by the various systems that can act on
> those actions. Further, these COAs will be coordinated and deployed across
> heterogeneous cyber security systems such that both the actions requested
> and the resultant outcomes may be verified. These COA actions will be
> referenceable in a data structure like the OASIS STIX V2 model that provides
> support for related data such as threat actors, campaigns, intrusion sets,
> malware, attack patterns, and other adversarial techniques, tactics, and
> procedures.

If you cite STIX, then cite the MILE work, unless this work is intended to be STIX-focused.

> Where possible the working group will consider existing efforts, like OASIS
> OpenC2 and IETF I2NSF that define the atomic actions to be included in a
> process or sequence. 

My understanding coming out of the BOF was that CACAO would re-use (i.e., not redefine/use as a normative reference) OpenC2/I2NSF to define all atomic action.  If that’s right, then I recommend being explicit in this dependency.  It will help shrink the perceived scope of the problem.

> The working group will not consider how shared
> actions are used/enforced, except where a response is expected for a specific
> action or step.

This text seems to conflict with my read of item #5 above ("5. the monitoring of COA activity after successful deployment").

>    - Specify and standardize the configuration for at least one protocol that
> can be used to distribute courses of action in both a direct delivery and
> publish-subscribe method
>    - Specify the protocol which may include apis, interfaces and other related
> technology to support the requirements identified for the protocol.

(Noted above) What is the difference between this protocol and the one above it -- "CACAO Protocol Specification" vs. "CACAO Distribution and Response Application Layer Protocol"?

> requirements; and test documents. That decision will be made during the
> lifetime of the working group.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 May 2019 23:16:13 -0400

In general, I think that the charter is probably okay, but I feel that my
concerns below should be addressed early in the WG process.

I have some difficulties understanding the "protocol" part of the charter,
which I have clipped below the questions.

    > end of email or at [1])?  Please submit objections or blocking concerns
    > to the list.

I feel very uncertain about what shape some of the products of the WG will take.

    > 2.  Are you willing to author or participate in the development of the

Not sure, I am concerned that there will be many references to other SDOs whose
documents are not freely available, and this will significantly reduce
understanding.  I.e. I may be simply unable to author or participate.

    > 3.  Are you willing to help review the drafts of this WG?

See above.

    > 4.  Are you interested in implementing drafts of this WG?

Yes.

    > boundaries and technology stacks that may include PROTOCOLS, apis,

...

    > interfaces, and a PROTOCOL. This solution will also provide a data

====

What I understand from the below is that I2NSF will provide the underlying
functions for the playbooks to invoke.  We won't have to invent an
abstraction of a router and firewall, because I2NSF already has done that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Bret Jordan <[email-masked]>
Date: Fri, 24 May 2019 09:53:12 -0600

Michael,

Thank you for your comments. The text around an application level protocol is really about calling out which application level protocol to use for CACAO (MQTT, RabbitMQ, HTTP, etc) and how one would use it.  You can not just leave it wide open, nor could you say just use HTTP or MQTT for example.  The hope is we could call out one, and how you would use it with examples, then we could build some interoperability test suites to help ensure vendors do it right.  Give them a way to self-verify.  We have done this in other projects and it has worked pretty well. 

Thanks,
Bret

> On May 23, 2019, at 9:16 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> ....

---

From: Bret Jordan <[email-masked]>
Date: Fri, 24 May 2019 10:23:24 -0600

Roman,

Thanks for your comments as well.  The goals of item 5 is to ensure that if product A sends a playbook to a product B, that product A can get a response back saying that product B received it, acted on it, successfully acted on it, etc.   To do this you need to call out an application layer protocol (say MQTT, RabbitMQ, HTTP, etc) that both ends can implement so you can have interoperability.  The whole goal of this work is to have a solution that is easy for vendors to adopt and make use of it. 

But if this is going to cause a problem, we could break this out of the work for now, and do it later after the first batch is done. 

I will try and address your comments in-line below.

Thanks,
Bret

> I'm concerned that attestation is an overloaded term.  Does "attestation" mean more than "verification and authentication"?  This topic got a lot of discussion during the preparation for the RATS c…

I am not sure what other word to use.  If you could help suggested a different one, that would be awesome. The goal is for organizations to be able to digitally sign sections or parts of the COA or the entire COA to say that this does work as expected or does prevent, mitigate, or remediate this threat.  The fundamental goal is to be able to give organizations that have a less mature security operations center or cyber defense center some level of confidence that other organizations or vendors have verified that COA.  

> What is "correctness" in this context?

For a complete deployment of the solution you would want the ability to do a dry run of the COA.  Maybe this does not have to be in the charter, but it was a goal item that we talked about very early on.  Maybe it is simply a flag or boolean that is added to the top of the COA that says “test run” or “dry run”.  

> Is the JSON data model mentioned in the first sentence the same one as mentioned in the second?  I'm assuming yes because the deliverables only list one.

There would only be a single data model that we would define in this work. The goal of the protocol is to ensure that two products can share and collaborate on COAs.  More than likely some of this will be done via HTTP or MQTT/RabbitMQ.   The point is we need to pick one and define how it would be used so vendors can build products.  We would also want to define some interoperability tests so that vendors can self-verify that they are compliant. 

> The above text describes only one protocol, but the deliverables list two.  What is the second protocol doing?

There are two types of communications.  One is the sharing of COAs between products that are being used to work on, collaborate on, etc.  The other is the execution side of the COA, when I send this COA to a device directly or to an orchestration device I would like to have defined messages that I get back to talk about if the COA was taken, deployed, failed, etc. So while they may both use the same application layer protocol, we called them out as two separate line items so we could work on them.  Does that help? 

> If you cite STIX, then cite the MILE work, unless this work is intended to be STIX-focused.

The reason we have called out STIX is that is what the threat intelligence community and FIRST has adopted.  So we want to make sure that our playbooks and COAs can be referenced in the graph (nodes/vertices and edges). Because you will want to ensure that you can link CACAO playbooks against campaigns, threat actors, intrusion sets, TTPs, etc. 

> My understanding coming out of the BOF was that CACAO would re-use (i.e., not redefine/use as a normative reference) OpenC2/I2NSF to define all atomic action.  If that’s right, then I recommend bei…

A playbook may have many atomic actions,  Some may be human process based, some may be computer automation based, some may use vendor proprietary commands, some may use things like OpenC2 or I2NSF.  The goal is for an atomic action to be able to define “what command” is coming next.  OpenC2 and I2NSF do not define all the possible commands that we need to be able to define.  Thus those would be two options in a taxonomy.  For example:

[{
  “Id”: “cacao--123456”,
  “Action_type”: “cisco_ios”,
  “Action”: “deny ip 1.2.3.4"
},
{
  “Id”: “cacao-98765”,
  “Action_type”: “openc2”,
  “Action”: “<some openc2 blob of data>”
}]

> This text seems to conflict with my read of item #5 above ("5. the monitoring of COA activity after successful deployment”)

The idea of sharing a COA with you and figuring out if you deployed it or not is out of scope.  But getting a response back from the devices in my network or my orchestration tool that I have deployed the COA to is in scope. When deploying this you want to be able to get back standard defined messages that mean something, are easily to understand, and allow vendors to add extra content if needed.  But you need a way of knowing did my firewall actually do what I told it to do. 

> (Noted above) What is the difference between this protocol and the one above it -- "CACAO Protocol Specification" vs. "CACAO Distribution and Response Application Layer Protocol”?

I tried to address this above and in my last email to Michael.  Does this now make sense?

---

From: <[email-masked]>
Date: Tue, 28 May 2019 15:00:43 +0000

Hi Joe,

The comments I shared on this charter text are still pending. Please check at: https://mailarchive.ietf.org/arch/msg/cacao/6jPvtjdsam0J9OAc1iIkQLcMLFE.

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Joseph Salowey
Envoyé : vendredi 10 mai 2019 15:39
À : [email-masked]
Objet : [Cacao] Call for CACAO Charter Consensus

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

 - CACAO JSON Data Model

---

From: Bret Jordan <[email-masked]>
Date: Tue, 28 May 2019 11:10:04 -0600

We tried to address many of them.  But some of them, we just did not agree with.  With that said, I would love to have a call with you to talk through it.  I am hoping we can talk live to better address your concerns. 

Thanks,
Bret

> On May 28, 2019, at 9:00 AM, [email-masked] wrote:
> 
> Hi Joe,
>  
> The comments I shared on this charter text are still pending. Please check at: https://mailarchive.ietf.org/arch/msg/cacao/6jPvtjdsam0J9OAc1iIkQLcMLFE <https://mailarchive.ietf.org/arch/msg/cacao/6jPvtjdsam0J9OAc1iIkQLcMLFE>.
>  
> Cheers,
> Med
>  
> De : Cacao [mailto:[email-masked] <mailto:[email-masked]>] De la part de Joseph Salowey
> À : [email-masked] <mailto:[email-masked]>

---

From: Allan Thomson <[email-masked]>
Date: Tue, 28 May 2019 17:14:27 +0000

And one other thing worth noting.

Are any of the points or concerns being raised, reasons to block forming a working group?

It seems that if the charter is sufficiently defined to form the working group then some of the issues can be resolved in the natural order of business.

However, if anyone feels that the working group should not be formed then that would be a reason or cause for the AD Chairs to pay attention to those particular concerns.

My personal opinion is that there is enough consensus to move forward and solve some very real problems.

Allan

From: Cacao <[email-masked]> on behalf of Bret Jordan <[email-masked]>
Date: Tuesday, May 28, 2019 at 10:10 AM
To: "[email-masked]" <[email-masked]>
Cc: Joseph Salowey <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] Call for CACAO Charter Consensus

Thanks,
Bret

On May 28, 2019, at 9:00 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Joe,

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Joseph Salowey
Envoyé : vendredi 10 mai 2019 15:39
À : [email-masked]<mailto:[email-masked]>
Objet : [Cacao] Call for CACAO Charter Consensus

Thanks,

Joe & Chris

--------------

# Introduction

# Goals and Deliverables

 - CACAO JSON Data Model

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 30 May 2019 01:39:31 +0000

Hi Bret!

> From: Bret Jordan [mailto:[email-masked]]
> Sent: Friday, May 24, 2019 12:23 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Thanks for your comments as well.  The goals of item 5 is to ensure that if
> product A sends a playbook to a product B, that product A can get a
> response back saying that product B received it, acted on it, successfully
> acted on it, etc.   To do this you need to call out an application layer
> protocol (say MQTT, RabbitMQ, HTTP, etc) that both ends can implement so
> you can have interoperability.  The whole goal of this work is to have a
> solution that is easy for vendors to adopt and make use of it.
> 
> But if this is going to cause a problem, we could break this out of the work
> for now, and do it later after the first batch is done.
> 

I think I understand the key distinction with item #5 now.  The clarity is appreciated.

I've responded inline ...

> > I'm concerned that attestation is an overloaded term.  Does "attestation"
> > mean more than "verification and authentication"?  This topic got a lot of
> > discussion during the preparation for the RATS chartering process.
> >
> 
> I am not sure what other word to use.  If you could help suggested a different
> one, that would be awesome. The goal is for organizations to be able to
> digitally sign sections or parts of the COA or the entire COA to say that this
> does work as expected or does prevent, mitigate, or remediate this
> threat.  The fundamental goal is to be able to give organizations that have a
> less mature security operations center or cyber defense center some level of
> confidence that other organizations or vendors have verified that COA.

For me this makes this explanation is even more confusing because it mixes the cryptographic assurances (integrity and authenticity)/object-level security with organizational processes uses to "gain confidence" in the fidelity/quality of the COA.

Is the less mature SOCs more confident in the COA it got because there is meta-data on how to use it; and it comes from and is signed by SOC whom it holds high esteem?  

It seems like object/channel security items don't need to be explicitly enumerated and could simply be covered in #3 by saying "_securely_ sharing ...".  This vagueness provides more latitude.

See related comment for item #4

> For a complete deployment of the solution you would want the ability to do
> a dry run of the COA.  Maybe this does not have to be in the charter, but it
> was a goal item that we talked about very early on.  Maybe it is simply a flag
> or boolean that is added to the top of the COA that says “test run” or “dry
> run”.

Thanks for the explanation.  If this will manifest in the work as only a single boolean flag in the data model, this doesn't seem a necessary item to include in the charter text.  It seems like this item and the #2 discussed above point to the significance of not just a data model for COAs but host of associated meta data (e.g., processing instructions, confidence measures).  Perhaps re-phrase the capability to be (something like):

"2.  Creation and documentation of meta-data about and processing instructions for COAs in a machine readable format" 

"3.  The securely sharing and distributing of COAs and related meta-data across ..."
 
>> Is the JSON data model mentioned in the first sentence the same one as
>> mentioned in the second?  I'm assuming yes because the deliverables only
>> list one.
> 
> There would only be a single data model that we would define in this work.
> The goal of the protocol is to ensure that two products can share and
> collaborate on COAs.  More than likely some of this will be done via HTTP or
> MQTT/RabbitMQ.   The point is we need to pick one and define how it
> would be used so vendors can build products.  We would also want to define
> some interoperability tests so that vendors can self-verify that they are
> compliant.

Understood.  Then the text as written isn't clear to me.  The first sentence mentions the existence of a JSON protocol but not what it does.  The second sentence references the JSON data model does additional things without explaining the initial body of work.  Practically, I think clarity could be realized by saying:

"This solution will contain at a minimum a data model specifying the COAs; a defined set of functional capabilities and associated interfaces; and an exchange protocol."

> There are two types of communications.  One is the sharing of COAs
> between products that are being used to work on, collaborate on, etc.  The
> other is the execution side of the COA, when I send this COA to a device
> directly or to an orchestration device I would like to have defined messages
> that I get back to talk about if the COA was taken, deployed, failed, etc. So
> while they may both use the same application layer protocol, we called
> them out as two separate line items so we could work on them.  Does that
> help?

It does clarify matters.  Thanks.  I support defining a protocol that "shares the COAs between products", but not defining a protocol to "deliver the COAs to a device directly" at this time.  It seems like too much scope to tackle and could be addressed (with re-chartering at a later date).

> The reason we have called out STIX is that is what the threat intelligence
> community and FIRST has adopted.  So we want to make sure that our
> playbooks and COAs can be referenced in the graph (nodes/vertices and
> edges). Because you will want to ensure that you can link CACAO playbooks
> against campaigns, threat actors, intrusion sets, TTPs, etc.

I'm arguing for precision.  If the quote is "like STIX" then support for other standard would be in scope.  I'd also argue for referencing other IETF work then.

> > My understanding coming out of the BOF was that CACAO would re-use (i.e.,
> > not redefine/use as a normative reference) OpenC2/I2NSF to define all
> > atomic action.  If that’s right, then I recommend being explicit in this
> > dependency.  It will help shrink the perceived scope of the problem.
> > 
>  
> A playbook may have many atomic actions,  Some may be human process
> based, some may be computer automation based, some may use vendor
> proprietary commands, some may use things like OpenC2 or I2NSF.  The goal
> is for an atomic action to be able to define “what command” is coming
> next.  OpenC2 and I2NSF do not define all the possible commands that we
> need to be able to define.  Thus those would be two options in a
> taxonomy.  For example:

Understood.  Perhaps a stronger statement could then be made "The WG will reuse existing data models for atomic actions where possible from related work in OASIS OpenC2 and IETF I2NSF"

>   “Action”: “deny ip 1.2.3.4"

Referencing Mohamed Boucadair's feedback, the above example makes me think of YANG.  RFC8519 already specified a robust data model for ACL that would operate on a router.  No new data model work.  No new protocol required to pass this to the device (with NETCONF).  Would something like this be in scope?

[{
"id": "cacao-1234",
"action_type":"yang-xxx-rfc8519",
"action":"<some yang blob>"
}]

If so, YANG models should be consider a source of atomic actions per my previous comment on explicit sources of re-use.

>   “Action”: “<some openc2 blob of data>”

What would be an example of the "human processes" that the WG would want to define?  The above examples don't seem to cover new ground (i.e., they reference the prior work)

> > The working group will not consider how shared actions are used/enforced,
> > except where a response is expected for a specific action or step.
> > 
> > This text seems to conflict with my read of item #5 above ("5. the monitoring
> > of COA activity after successful deployment”)
> 
> 
> The idea of sharing a COA with you and figuring out if you deployed it or not
> is out of scope.  But getting a response back from the devices in my network
> or my orchestration tool that I have deployed the COA to is in scope. When
> deploying this you want to be able to get back standard defined messages
> that mean something, are easily to understand, and allow vendors to add
> extra content if needed.  But you need a way of knowing did my firewall
> actually do what I told it to do.

As noted above.  I feel the orchestration (item #5 and CACAO Distribution and Response Application Layer Protocol) should be deferred for now.

Regards,
Roman

> (Noted above) What is the difference between this protocol and the one
> above it -- "CACAO Protocol Specification" vs. "CACAO Distribution and
> Response Application Layer Protocol”?
> 
>

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 30 May 2019 21:10:23 -0700

On Tue, May 28, 2019 at 10:14 AM Allan Thomson <
[email-masked]> wrote:

> It seems that if the charter is sufficiently defined to form the working
> group then some of the issues can be resolved in the natural order of
> business.
>
>
>
> However, if anyone feels that the working group should not be formed then
> that would be a reason or cause for the AD Chairs to pay attention to those
> particular concerns.
>
>
>

[Joe] We still have substantive comments on the scope of the work defined
by the charter that need to be addressed before the charter can be approved
to form a working group.

> Allan
>
>
>
> *From: *Cacao <[email-masked]> on behalf of Bret Jordan <
> [email-masked]>
> *Date: *Tuesday, May 28, 2019 at 10:10 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *Joseph Salowey <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Cacao] Call for CACAO Charter Consensus
>
>
>
> We tried to address many of them.  But some of them, we just did not agree
> with.  With that said, I would love to have a call with you to talk through
> it.  I am hoping we can talk live to better address your concerns.
>
>
>
>
>
> Thanks,
>
> Bret
>
> The comments I shared on this charter text are still pending. Please check
> at:
> https://mailarchive.ietf.org/arch/msg/cacao/6jPvtjdsam0J9OAc1iIkQLcMLFE.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Cacao [mailto:[email-masked] <[email-masked]>] *De
> la part de* Joseph Salowey
> *Envoyé :* vendredi 10 mai 2019 15:39
> *À :* [email-masked]
> *Objet :* [Cacao] Call for CACAO Charter Consensus
>
>
>

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 30 May 2019 21:17:46 -0700

On Thu, May 23, 2019 at 8:16 PM Michael Richardson <[email-masked]>
wrote:

> concerns
> the
>     > drafts of this WG?
[Joe] I believe that most of the references have been to documents in OASIS
which are publicly available.  You may not be able to participate in the
development of OASIS documents to the same level as you would in the IETF,
but the specifications are available.  Are there specific SDOs and
specifications you are concerned with?

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 30 May 2019 21:47:20 -0700

On Fri, May 24, 2019 at 8:53 AM Bret Jordan <[email-masked]> wrote:

> Michael,
>
> Thank you for your comments. The text around an application level protocol
> is really about calling out which application level protocol to use for
> CACAO (MQTT, RabbitMQ, HTTP, etc) and how one would use it.  You can not
> just leave it wide open, nor could you say just use HTTP or MQTT for
> example.  The hope is we could call out one, and how you would use it with
> examples, then we could build some interoperability test suites to help
> ensure vendors do it right.  Give them a way to self-verify.  We have done
> this in other projects and it has worked pretty well.
>
>
[Joe] I think the question is more about what the protocol would do.  The
charter suggests protocols to do the following:

1. Retrieve playbooks from a source  (numbered item 3)
1.5 Way to discover playbooks (this is probably heavily reliant on another
protocol)
2. Submit a playbook to be executed and obtain success/failure and a list
of results (numbered item 5)
3. Submit a playbook for verification and obtain a result of valid/invalid
(combination of 2 and 4?)

It seems like 1 is basic.  1.5 seems fundamental as well, although its
possible this could be work for another WG or SDO.

I think we are having some discussion on whether 2 is in scope.   I'm not
sure if 3 is a thing or not.