Subject: [Cacao] Updated Charter

From: Bret Jordan <[email-masked]>
Date: Wed, 12 Jun 2019 11:50:14 -0600

All,

Allan and I have updated the charter for CACAO based not he feedback given.  I hope this finally addresses everyone’s concerns and allows us to move forward with the formation of a working group.

# 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 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 or easily share them across organizational boundaries and technology stacks.

This working group will create a standard that implements the course of action playbook model for cybersecurity operations. 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. These courses of actions should be referenceable by other cyber threat intelligence that provides support for related data such as threat actors, campaigns, intrusion sets, malware, attack patterns, and other adversarial techniques, tactics, and procedures. 

This solution will specifically enable:

 1. the creation and documentation of course of action playbooks in a structured machine-readable format
 2. organizations to digitally sign course of action playbooks
 3. the securely sharing and distribution of course of action playbooks across organizational boundaries and technology stacks
 4. the creation and documentation of processing instructions for course of action playbooks in a machine readable format

This solution will contain at a minimum a data model specifying the course of action playbooks; a defined set of functional capabilities and associated interfaces; and an exchange protocol between products. Where possible the working group may reuse and/or reference existing data models, like OASIS OpenC2 and other IETF standards (e.g., I2NSF, YANG, NETCONF, etc) that define the atomic actions to be included in a process or sequence.

# 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 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. 

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."

---

From: Bret Jordan <[email-masked]>
Date: Wed, 12 Jun 2019 18:54:33 +0000

Small typo.  I really really hate autocorrect.

"Allan and I have updated the charter for CACAO based on the feedback given.  I hope this finally addresses everyone’s concerns and allows us to move forward with the formation of a working group."

Bret

________________________________
From: Cacao <[email-masked]> on behalf of Bret Jordan <[email-masked]>
Sent: Wednesday, June 12, 2019 11:50:14 AM
To: cacao
Subject: [EXT] [Cacao] Updated Charter

All,

# Introduction

# Goals and Deliverables

Thanks,
Bret

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 16 Jun 2019 21:27:26 -0700

Thanks for posting an update, I think it provides a tighter scope.  I have
a few questions on the deliverables and goals:

 1. Which deliverable addresses #4 "the creation and documentation of
processing instructions for course of action playbooks in a machine
readable format"?
 2. Do you intend for the same protocol to be used in the direct delivery
and publish subscribe cases?

On Wed, Jun 12, 2019 at 10:50 AM Bret Jordan <[email-masked]> wrote:

> All,
>
> Allan and I have updated the charter for CACAO based not he feedback
> given.  I hope this finally addresses everyone’s concerns and allows us to
> move forward with the formation of a working group.
>
> # 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 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 or
> easily share them across organizational boundaries and technology stacks.
>
> This working group will create a standard that implements the course of
> action playbook model for cybersecurity operations. 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. These
> courses of actions should be referenceable by other cyber threat
> intelligence that provides support for related data such as threat actors,
> campaigns, intrusion sets, malware, attack patterns, and other adversarial
> techniques, tactics, and procedures.
>
>  3. the securely sharing and distribution of course of action playbooks
> across organizational boundaries and technology stacks
>  4. the creation and documentation of processing instructions for course
> of action playbooks in a machine readable format
>
> This solution will contain at a minimum a data model specifying the course
> of action playbooks; a defined set of functional capabilities and
> associated interfaces; and an exchange protocol between products. Where
> possible the working group may reuse and/or reference existing data models,
> like OASIS OpenC2 and other IETF standards (e.g., I2NSF, YANG, NETCONF,
> etc) that define the atomic actions to be included in a process or sequence.
>
> # Goals and Deliverables
>    - 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 JSON Data Model
>    - 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.
>
>
>
> Thanks,
> Bret
> --
> Cacao mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao
>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Jun 2019 04:42:57 +0000

Responses in line

Sent from my Commodore 128D

On Jun 17, 2019, at 6:28 AM, Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for posting an update, I think it provides a tighter scope.  I have a few questions on the deliverables and goals:

 1. Which deliverable addresses #4 "the creation and documentation of processing instructions for course of action playbooks in a machine readable format"?

JSON data model

 2. Do you intend for the same protocol to be used in the direct delivery and publish subscribe cases?

No.  Something like an http restful design for direct delivery and something like MQTT for publish subscribe.  It is important to note that we will not be creating a new protocol, but rather define how to use an existing protocol in an interoperable manner.

Does that help ???

Bret

On Wed, Jun 12, 2019 at 10:50 AM Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
All,

# Introduction

# Goals and Deliverables

Thanks,
Bret

--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cacao<https://clicktime.symantec.com/3LfjJwqfo88gJaz7E4Z6xXe7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>
--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/3LfjJwqfo88gJaz7E4Z6xXe7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao

---

From: Allan Thomson <[email-masked]>
Date: Mon, 17 Jun 2019 10:24:59 +0000

Agree on Bret’s answers.

However, I would say that the role of the WG should be to identify those protocol choices rather than choosing ones upfront.

I’m sure we all have opinions on which protocols make sense in certain environments so hopefully we can come to consensus quickly on which choices are preferred for a particular use.

Allan

From: Cacao <[email-masked]> on behalf of Bret Jordan <Bret_Jordan=[email-masked]>
Date: Sunday, June 16, 2019 at 9:43 PM
To: Joseph Salowey <[email-masked]>
Cc: cacao <[email-masked]>, Bret Jordan <[email-masked]>
Subject: Re: [Cacao] [EXT] Re: Updated Charter

Responses in line

JSON data model

Does that help ???

Bret

# Introduction

# Goals and Deliverables

Thanks,
Bret

---

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Jun 2019 13:46:29 +0200

Exactly. Allan’s response is what I wanted to say

Bret 

> On Jun 17, 2019, at 12:24 PM, Allan Thomson <[email-masked]> wrote:
> 
> Agree on Bret’s answers.
>  
> On Jun 17, 2019, at 6:28 AM, Joseph Salowey <[email-masked]> wrote:
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 17 Jun 2019 15:05:12 +0200

Hi all,

TL;DR the charter text already looks really great - only 2,5 minor 
questions about steps, action, frameworks and playbooks in general in 
this email

So :)  The charter text progressed really well, I think. Especially the 
phrasing "identify those protocol choices rather than choosing ones 
upfront" is reasonable.

Although... :) I still think there are two structural nits, but that 
might only be from my point of view. I am relatively sure the proponents 
and stakeholders agree here, but I am not sure the text captures that 
consensus precisely yet.

Before I go into my two questions I'd like to raise a small terminology 
issue, too. I think it possible that a reader of the charter might not 
be sure if a step is the same thing as an action, or an action is a 
platform-specific instantiation of a step.

1.) steps and playbooks

A short summary: The beginning of the text focuses strongly on 
building-blocks regarding primarily two separate domains:

A.) the actors and their characteristics (e,g. procedures), and

B.) what to do about them (e.g. document prevention).

The charter text then elaborates on composing "these steps" into 
playbooks. I think it is not entirely clear to the reader, if these 
steps are about the above mentioned domain "B." or the domains "A. & B." 
At the moment, the text implies both ("A. & B.), but I think that should 
be made more clear.
For instance, I am not sure, because - on the one hand - "the tactics of 
a threat actor" does not sound like a step and - on the other hand - 
"remediation steps" literally are called out as steps.

2.) framework for steps or definition of steps

What is clear is that these steps will be the building blocks to compose 
playbooks. What is surprisingly unclear (text-wise, from my PoV as a 
reviewer, not context-wise, because I know what Bret et al are planning 
to do - I think ^^) is "what the solution will specifically enable":

Is it:

A.) a framework... or let's say "AVP"s in a data model structure, where 
the attributes, such as specific "remediation steps" are defined, or

B.) a data model structure _and_ the actual standardized, or specified 
enumeration of registered values that represent concrete "remediation 
steps" that go into the values of the "AVP"s.

Please mind, I am using "remediation step" exemplary here, because that 
was spelled out most unambiguously in the beginning of the text.

Viele Grüße,

Henk

On 6/17/19 1:46 PM, Bret Jordan wrote:
> On Jun 17, 2019, at 12:24 PM, Allan Thomson 
> <[email-masked] 
> <mailto:athomson@lookingglasscyber..com>> wrote:
> 
>> Agree on Bret’s answers.
>>
>> However, I would say that the role of the WG should be to identify 
>> those protocol choices rather than choosing ones upfront.
>>
>> I’m sure we all have opinions on which protocols make sense in certain 
>> environments so hopefully we can come to consensus quickly on which 
>> choices are preferred for a particular use.
>>
>> Allan
>>
>> *From: *Cacao <[email-masked] <mailto:[email-masked]>> 
>> on behalf of Bret Jordan <Bret_Jordan=[email-masked] 
>> <mailto:Bret_Jordan=[email-masked]>>
>> *Date: *Sunday, June 16, 2019 at 9:43 PM
>> *To: *Joseph Salowey <joe@salowey..net <mailto:[email-masked]>>
>> *Cc: *cacao <[email-masked] <mailto:[email-masked]>>, Bret Jordan 
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject: *Re: [Cacao] [EXT] Re: Updated Charter
>>
>> Responses in line
>>
>>     Thanks for posting an update, I think it provides a tighter
>>     scope.  I have a few questions on the deliverables and goals:
>>
>>      1. Which deliverable addresses #4 "the creation and documentation
>>     of processing instructions for course of action playbooks in a
>>     machine readable format"?
>>
>> JSON data model
>>
>>
>>
>> No.  Something like an http restful design for direct delivery and 
>> something like MQTT for publish subscribe.  It is important to note 
>> that we will not be creating a new protocol, but rather define how to 
>> use an existing protocol in an interoperable manner.
>>
>> Does that help ???
>>
>> Bret
>>
>>
>>
>>     On Wed, Jun 12, 2019 at 10:50 AM Bret Jordan
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         All,
>>
>>         Allan and I have updated the charter for CACAO based not he
>>         feedback given.  I hope this finally addresses everyone’s
>>         concerns and allows us to move forward with the formation of a
>>         working group.
>>
>>         # 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 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
>>         or easily share them across organizational boundaries and
>>         technology stacks.
>>
>>         This working group will create a standard that implements the
>>         course of action playbook model for cybersecurity operations.
>>         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. These
>>         courses of actions should be referenceable by other cyber
>>         threat intelligence that provides support for related data
>>         such as threat actors, campaigns, intrusion sets, malware,
>>         attack patterns, and other adversarial techniques, tactics,
>>         and procedures.
>>
>>          1. the creation and documentation of course of action
>>         playbooks in a structured machine-readable format
>>          3. the securely sharing and distribution of course of action
>>         playbooks across organizational boundaries and technology stacks
>>          4. the creation and documentation of processing instructions
>>         for course of action playbooks in a machine readable format
>>
>>         This solution will contain at a minimum a data model
>>         specifying the course of action playbooks; a defined set of
>>         functional capabilities and associated interfaces; and an
>>         exchange protocol between products. Where possible the working
>>         group may reuse and/or reference existing data models, like
>>         OASIS OpenC2 and other IETF standards (e.g., I2NSF, YANG,
>>         NETCONF, etc) that define the atomic actions to be included in
>>         a process or sequence.
>>
>>         # Goals and Deliverables
>>            - 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 JSON Data Model
>>            - Define and create a series of tests and documents to
>>         assist with interoperability of the various systems involved.
>>
>>         requirements; and test documents. That decision will be made
>>         during the lifetime of the working group.
>>
>>         Thanks,
>>
>>         Bret
>>
>>         "Without cryptography vihv vivc ce xhrnrw, however, the only
>>         thing that can not be unscrambled is an egg."
>>
>>         -- 
>>         Cacao mailing list
>>         [email-masked] <mailto:[email-masked]>
>>         <https://clicktime.symantec.com/3LfjJwqfo88gJaz7E4Z6xXe7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>
>>
>>     -- 
>>     Cacao mailing list
>>     [email-masked] <mailto:[email-masked]>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Jun 2019 17:44:29 +0200

Henk,

Thanks for the comments..  The goal of CACAO is to define how atomic actions can be documented in such a way to enable cyber defense. 

Right now they are all documented in an unstructured form. We do not plan on creating the atomic actions themselves.  Atomic actions may be “human process commands” like “reboot system in to safe mode” or “remove hard drive”.  They may also contain automated commands like an OpenC2 command, NETCONF command, or proprietary API command.  Say a CISCO CLI command to block a certain IP address. 

Here is a text - pseudo code examples

BEGIN-PLAYBOOK

Playbook-Name: InfectedHostMitigation1

Playbook-Trigger-Event: 

 - Indicator indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a command and control server based on CIDR 192.0.2.x that has been communicated to and from the host 198.51.100.12.
 - A trigger event may be defined in STIX2
 - A trigger defines an entry point into the playbook steps as follows.

BEGIN-COAs

COA: 

 - Id: 1
 - Type: Human
   - Question: Ask the user whether they wish to review the mitigation procedures before proceeding?
   - Answer-Y-or-N
     - If Y: Proceed to Id: 2
     - If N: Proceed to Id: 3

COA:

 - Id: 2
 - Type: Human
   - Operation: Display mitigation procedures. 

COA:

 - Id:3
 - Type: Machine
   - Operation: Vlan-Move 
   - Variable: $$HostVLANID = $$infected-host.vlan
   - Target: $$infected-host
   - Destination: Quarantine VLAN ID 

COA:

 - Id:4
 - Type: Machine
   - Operation: Host-Image
   - Target: $$infected-host
   - ImageName: Windows-Good-Image1

COA:

 - Id:5
 - Type: Machine
   - Operation: Vlan-Move
   - Target: $$infected-host
   - Destination: $$HostVLANID

END-COAs

END-PLAYBOOK

Are there any specific changes we need to make?  Your statements did not indicate specific changes, unless I am missing something????

Thanks,
Bret

> On Jun 17, 2019, at 3:05 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
> 
> TL;DR the charter text already looks really great - only 2,5 minor questions about steps, action, frameworks and playbooks in general in this email
> 
> So :)  The charter text progressed really well, I think. Especially the phrasing "identify those protocol choices rather than choosing ones upfront" is reasonable.
> 
> Although... :) I still think there are two structural nits, but that might only be from my point of view. I am relatively sure the proponents and stakeholders agree here, but I am not sure the text captures that consensus precisely yet.
> 
> Before I go into my two questions I'd like to raise a small terminology issue, too. I think it possible that a reader of the charter might not be sure if a step is the same thing as an action, or an action is a platform-specific instantiation of a step.
> 
> 1.) steps and playbooks
> 
> A short summary: The beginning of the text focuses strongly on building-blocks regarding primarily two separate domains:
> 
> The charter text then elaborates on composing "these steps" into playbooks. I think it is not entirely clear to the reader, if these steps are about the above mentioned domain "B." or the domains "A. & B." At the moment, the text implies both ("A. & B.), but I think that should be made more clear.
> For instance, I am not sure, because - on the one hand - "the tactics of a threat actor" does not sound like a step and - on the other hand - "remediation steps" literally are called out as steps.
> 
> What is clear is that these steps will be the building blocks to compose playbooks. What is surprisingly unclear (text-wise, from my PoV as a reviewer, not context-wise, because I know what Bret et al are planning to do - I think ^^) is "what the solution will specifically enable":
> 
> Is it:
> 
> A.) a framework... or let's say "AVP"s in a data model structure, where the attributes, such as specific "remediation steps" are defined, or
> 
> B.) a data model structure _and_ the actual standardized, or specified enumeration of registered values that represent concrete "remediation steps" that go into the values of the "AVP"s.
> 
> Please mind, I am using "remediation step" exemplary here, because that was spelled out most unambiguously in the beginning of the text.
> 
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> 
> 
> 
>> On Jun 17, 2019, at 12:24 PM, Allan Thomson <[email-masked] <mailto:athomson@lookingglasscyber..com>> wrote:
>>> Agree on Bret’s answers.
>>> 
>>> *From: *Cacao <[email-masked] <mailto:[email-masked]>> on behalf of Bret Jordan <Bret_Jordan=[email-masked] <mailto:Bret_Jordan=[email-masked]>>
>>> *Cc: *cacao <[email-masked] <mailto:[email-masked]>>, Bret Jordan <[email-masked] <mailto:[email-masked]>>
>>> On Jun 17, 2019, at 6:28 AM, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>        --         Cacao mailing list
>>>    --     Cacao mailing list

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 17 Jun 2019 19:28:45 +0200

Hi Bret,

thanks for your fast reply and the very helpful and illustrative 
example. In order to propose text changes I have to understand a few 
more things wrt to my question 1.)

Will "type" (e.g. human) be an enumeration that will be specified and 
registered in this charter context? At the moment, I assume: yes.

As far as I can see from your example, the scope I called "domain A" 
before is not-in-scope for this charter - e.g. the definition and 
enumeration of specific instances of a threat actor's characteristics 
(e.g. a tactic) is in not-in-scope. Is that correct?

Regarding my question 2.) the answer seems to be B.) as far as I 
understand it.

Viele Grüße,

Henk

On 6/17/19 5:44 PM, Bret Jordan wrote:
> Henk,
> 
> Thanks for the comments..  The goal of CACAO is to define how atomic 
> actions can be documented in such a way to enable cyber defense.
> 
> Right now they are all documented in an unstructured form. We do not 
> plan on creating the atomic actions themselves.  Atomic actions may be 
> “human process commands” like “reboot system in to safe mode” or “remove 
> hard drive”.  They may also contain automated commands like an OpenC2 
> command, NETCONF command, or proprietary API command.  Say a CISCO CLI 
> command to block a certain IP address.
> 
>   - Indicator indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a 
> command and control server based on CIDR 192.0.2.x that has been 
> communicated to and from the host 198.51.100.12.
> Are there any specific changes we need to make?  Your statements did not 
> indicate specific changes, unless I am missing something????
> 
> 
> Thanks,
> Bret
>> On Jun 17, 2019, at 3:05 PM, Henk Birkholz 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> So :)  The charter text progressed really well, I think. Especially 
>> the phrasing "identify those protocol choices rather than choosing 
>> ones upfront" is reasonable.
>>
>> might only be from my point of view. I am relatively sure the 
>> proponents and stakeholders agree here, but I am not sure the text 
>> captures that consensus precisely yet.
>>
>> Before I go into my two questions I'd like to raise a small 
>> terminology issue, too. I think it possible that a reader of the 
>> charter might not be sure if a step is the same thing as an action, or 
>> an action is a platform-specific instantiation of a step.
>>
>> 1.) steps and playbooks
>>
>> steps are about the above mentioned domain "B." or the domains "A. & 
>> B." At the moment, the text implies both ("A. & B.), but I think that 
>> should be made more clear.
>> For instance, I am not sure, because - on the one hand - "the tactics 
>> of a threat actor" does not sound like a step and - on the other hand 
>> - "remediation steps" literally are called out as steps.
>>
>> What is clear is that these steps will be the building blocks to 
>> compose playbooks. What is surprisingly unclear (text-wise, from my 
>> PoV as a reviewer, not context-wise, because I know what Bret et al 
>> are planning to do - I think ^^) is "what the solution will 
>> specifically enable":
>>
>> Is it:
>>
>> A.) a framework... or let's say "AVP"s in a data model structure, 
>> where the attributes, such as specific "remediation steps" are defined, or
>>
>> Please mind, I am using "remediation step" exemplary here, because 
>> that was spelled out most unambiguously in the beginning of the text.
>>
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>>
>>
>>
>>> <mailto:[email-masked]> 
>>>> I’m sure we all have opinions on which protocols make sense in 
>>>> certain environments so hopefully we can come to consensus quickly 
>>>> on which choices are preferred for a particular use.
>>>>
>>>> Allan
>>>>
>>>> *From: *Cacao <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> on 
>>>> behalf of Bret Jordan <Bret_Jordan=[email-masked] 
>>>> <mailto:Bret_Jordan=[email-masked]> 
>>>> *Cc: *cacao <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>>, Bret Jordan <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> On Jun 17, 2019, at 6:28 AM, Joseph Salowey <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> that we will not be creating a new protocol, but rather define how 
>>>> to use an existing protocol in an interoperable manner.
>>>>
>>>> Does that help ???
>>>>
>>>> Bret
>>>>
>>>>
>>>>
>>>>    <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>        All,
>>>>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 18 Jun 2019 09:44:44 +0000

Hi Bret,

Thank you for sharing the updated charter and for taking into account the comments.

The updated version looks good. Please see inline.

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Bret Jordan
Envoyé : mercredi 12 juin 2019 19:50
À : cacao
Objet : [Cacao] Updated Charter

All,

# 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 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 or easily share them across organizational boundaries and technology stacks.
[Med] (VERY MINOR) I still don’t get why “technology stacks” is cited here and how this will impact the proposed work of the WG. Protocol specifications do not make an assumption on the programming language or OS if that is what you have in mind.

This working group will create a standard that implements the course of action playbook model for cybersecurity operations. 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. These courses of actions should be referenceable by other cyber threat intelligence that provides support for related data such as threat actors, campaigns, intrusion sets, malware, attack patterns, and other adversarial techniques, tactics, and procedures.
[Med] A playbook may include information that is local (e.g., escalation contact or validation checks). This may be problematic if blindly shared across organizational boundaries. I guess the intent is to define a generic structure/template rather than getting into specifics. I suggest to call this out clearly in the text, e.g., by adding this NEW text:
“It is out of scope of the WG to define or recommend a set of actions to mitigation a given a threat. The WG will focus on a generic data model that is intended to be applicable to any course of action, including composite ones.“.
BTW, does the text needs to cover whether the validity/consistency of a set of CoAs is assumed as a pre-requisite or this is part of the things that wil be covered in the requirements document?

This solution will contain at a minimum a data model specifying the course of action playbooks; a defined set of functional capabilities and associated interfaces; and an exchange protocol between products.
[Med] What is meant by “products” here?
Where possible the working group may reuse and/or reference existing data models, like OASIS OpenC2 and other IETF standards (e.g., I2NSF, YANG, NETCONF, etc)
[Med] Please change “(e.g., I2NSF, YANG, NETCONF, etc)” to “(e.g., NETCONF, RESTCONF, DOTS, I2NSF, YANG modules, etc.)”
that define the atomic actions to be included in a process or sequence.
[Med] You may delete “to be included in a process or sequence” as these are not defined at this stage.

# 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
[Med]  You may refer explicitly to the interfaces to be defined in the Arch document, e.g., add the following at the end of the above sentence:
“over the interfaces identified in the CACAO functional architecture”.

 - CACAO JSON Data Model
   - Create a JSON data model that can capture and enable collaborative courses of action
[Med] This is one is conflicting with the sentence citing reusing YANG. I would cite YANG here especially that converting YANG to JSON and vice versa is well documented (RFC7951).

Thanks,
Bret

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Jun 2019 09:49:19 +0000

Comments in-line

________________________________
From: Henk Birkholz <[email-masked]>
Sent: Monday, June 17, 2019 11:28 AM
To: Bret Jordan
Cc: Allan Thomson; Joseph Salowey; cacao; Bret Jordan
Subject: [EXT] Re: [Cacao] [EXT] Re: Updated Charter

Hi Bret,

Bret: I would say either yes, or it would define a way to do it and how it should be done.

Bret: I believe the design right now is focused on mitigation, remediation, and prevention.  You would have some sort of indicator of compromise that you would / could link against a playbook.

Bret: If I understand your statements correctly, then yes, B.

Viele Grüße,

Henk

On 6/17/19 5:44 PM, Bret Jordan wrote:
>>>> https://clicktime.symantec.com/35qW29E4v1UZLX9TnGdX9e97Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Jun 2019 10:00:01 +0000

Mohamed,

Thanks for taking the time to review and provide comments.  Let me try and address in-line.

Bret

________________________________
From: Cacao <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, June 18, 2019 3:44 AM
To: Bret Jordan; cacao
Subject: [EXT] Re: [Cacao] Updated Charter

Hi Bret,

Cheers,

Med

All,

# Introduction

[BRET] It is meant to say that this playbook might be delivered between products in the network.  That is what we mean by technology stacks.  A SEIM to a Firewall to a Threat Intel solution etc.

[BRET] - Yes I agree 100%.  We are not going to be building a solution to sell.  But I see many startups coming along using this standard to develop playbooks they can sell.

[BRET] = I do not understand.

[BRET] A security product or network product.  A SEIM to a firewall to a Threat Intel platform. A product is just a device in the network. The whole point is to share these playbooks within an organizAtion and externally across the internet.

[BRET] - Sure.

[BRET] - Being able to define the sequence of steps is critical.  Some things must be done before something else.  Think malware cleanup.  You have to delete process 1 then regkeys, then files, and process 2, etc.  If you do it in a different way, then it does not work.

# Goals and Deliverables

[BRET] - I am all for adding or changing text, but I do not understand your change.

 - CACAO JSON Data Model

[BRET] - Then maybe we need to delete YANG for now.  We need to focus on simple things that the eco-system can implement and use very quickly. Most Web2.0 developers are very familiar with JSON.  This is why we picked it for version 1.

Thanks,

Bret

---

From: <[email-masked]>
Date: Tue, 18 Jun 2019 11:30:40 +0000

Re-,

Please see inline.

Cheers,
Med

De : Bret Jordan [mailto:[email-masked]]
Envoyé : mardi 18 juin 2019 12:00
À : BOUCADAIR Mohamed TGI/OLN; Bret Jordan; cacao
Objet : Re: [EXT] Re: [Cacao] Updated Charter

Mohamed,

Bret

Hi Bret,

Cheers,

Med

All,

Allan and I have updated the charter for CACAO based not he feedback given.  I hope this finally addresses everyone's concerns and allows us to move forward with the formation of a working group.

# Introduction

[Med] (VERY MINOR) I still don't get why "technology stacks" is cited here and how this will impact the proposed work of the WG. Protocol specifications do not make an assumption on the programming language or OS if that is what you have in mind.

[Med] Thank you for clarifying. Let's make this explicit then: s/technology stacks/security enforcement/decision points.

"It is out of scope of the WG to define or recommend a set of actions to mitigation a given a threat. The WG will focus on a generic data model that is intended to be applicable to any course of action, including composite ones.".

[BRET] - Yes I agree 100%.  We are not going to be building a solution to sell.

[Med] That is also my understand. Please add the above sentence the charter. Thanks.

  But I see many startups coming along using this standard to develop playbooks they can sell.

[Med] An action may be flawed because the proposed action is not adequate for a threat or it is missing a mandatory clause to be actionable. Such objects need to be detected and discarded somehow/somewhere. Things may be complicated when actions are chained/augmented by an intermediate function. Some (consistency) validation will be needed. The question is whether this is part of the work or not.

[Med] What is meant by "products" here?

[BRET] A security product or network product.  A SEIM to a firewall to a Threat Intel platform.

[Med] Let's call it then: "security service function" or simply "security function" (close to the I2NSF terminology).

A product is just a device in the network.

[Med] It can be a monolithic function, not a device.

The whole point is to share these playbooks within an organizAtion and externally across the internet.

[Med] Indeed.

[Med] Please change "(e.g., I2NSF, YANG, NETCONF, etc)" to "(e.g., NETCONF, RESTCONF, DOTS, I2NSF, YANG modules, etc.)"

[BRET] - Sure.

[Med] Thanks.

[Med] You may delete "to be included in a process or sequence" as these are not defined at this stage.

[Med] Fully agree. The point is that the text does not parse well because "sequence" and "process" are not defined.

# Goals and Deliverables

"over the interfaces identified in the CACAO functional architecture".

[Med] There will be interfaces that will defined in the architecture. The protocol work need to be linked to these interfaces.

 - CACAO JSON Data Model

[Med] We need to separate data modelling vs. application encoding. It is perfectly fine to use YANG for the modelling, but use JSON encoding for the application.

Thanks,

Bret