Re: [Cacao] Updated Charter version 03

[Allan Thomson <[e-mail]>]

Med – Given the focus has been on the BoF preparation and likely others will comment/share their perspectives also we are not planning to update the charter further until after that.

Allan

From: "[e-mail]" <[e-mail]>
Date: Friday, March 22, 2019 at 12:07 AM
To: Allan Thomson <[e-mail]>, Bret Jordan <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: JACQUENET Christian TGI/OLN <[e-mail]>
Subject: RE: [Cacao] Updated Charter version 03

Hi all,

Any update about integrating the changes into the proposed charter?

Cheers,
Med

De : Cacao [mailto:[e-mail]] De la part de [e-mail]
Envoyé : lundi 11 mars 2019 08:26
À : Allan Thomson; Bret Jordan; [e-mail]
Cc : JACQUENET Christian TGI/OLN
Objet : Re: [Cacao] Updated Charter version 03

Hi Allan,

Thank you for the follow-up.

Please see inline.

Cheers,
Med

De : Allan Thomson [mailto:[e-mail]]
Envoyé : vendredi 8 mars 2019 17:12
À : BOUCADAIR Mohamed TGI/OLN; Bret Jordan; [e-mail]
Cc : JACQUENET Christian TGI/OLN
Objet : Re: [Cacao] Updated Charter version 03

Mohamed –

A couple of responses to your input.


  1.  verify they were correctly executed, or easily share them across organizational boundaries and technology stacks.
[Med] Why “and technology stacks” is mentioned here?


AT: The intention is that CACAO works across different implementations and does not require a specific programming language or operating system as examples. That is what is intended ‘across technology stacks’.



[Med] Protocol specifications do not make an assumption on the programming language or OS. What is really key for CACAO is to share across administrative boundaries. How this is implemented is local to each domain. I still don’t see the need to mention “and technology stacks” in that sentence.



  1.  Each collaborative course of action will consist of a sequence of cyber defense actions
[Med] delete “cyber” (and in other parts of the text).



AT: Disagree with this suggestion. CACAO is focused on solving a cyber defense response. Removing cyber will cause confusion to what is the true intent of this work. Previous comments received were clear that making sure this work is focused on Cyber is important and I agree with that perspective. Unless you intend to broaden the scope of this work then I suggest we keep the term cyber.

[Med] Glad to see that we both agree on the need to have a restricted scope (as suggested in my proposal to select few applicability use cases). Nevertheless, “cyber” is hinting more vagueness to me than precise/restricted scope.


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

  - Identify and document the requirements to effectively report and alert on the deployment of CACAO actions and the potential threat response to those actions

 [Med] I’m not sure I would maintain this one as a separate item. I suggest to merge this item with the previous one. It is too early to decide whether one or more protocols will be required.


                AT: Respectfully, I disagree. We want to make it clear that we need a protocol for these different functions.

[Med] That can be easily added as an item under “CACAO Protocol Specification”.

If the group decides that a single protocol can support the requirements for both provisioning and monitoring/reporting later on then it is easy to state that.

[Med] The current language and structure seem to make a call. I do suggest we adopt something more neutral.

However, by removing the reporting/monitoring requirements we are losing an important aspect of the work.
[Med] That wasn’t my proposal.

On balance I think it is better to keep them separate for now and combine later on once everyone is on the same page regarding the requirements and how they are met.




  1.  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 connected data structure like the OASIS STIX V2 model that provides support for connected data such as threat actors, campaigns, intrusion sets, malware, attack patterns, and other adversarial techniques, tactics, and procedures (TTPs).

[Med] delete « TTPs ».

AT: TTPs are an important cyber construct that provides valuable context to this sentence. They are in addition to the other terms such as campaigns, intrusion sets, ….etc and an important aspect to be considered. STIX2 data model is very explicit on how TTPs are important to the overall threat analysis and mitigation. Suggest we keep unless you are suggesting that TTPs are not important?

[Med] The comment was purely editorial. TTP is not used in the text and therefore there is no need to define the acronym. The intent is to keep the text as simple without overloading it with acronyms.


Allan Thomson
CTO ([phone])
LookingGlass Cyber Solutions<http://www.lookingglasscyber.com/>

From: Cacao <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Thursday, March 7, 2019 at 11:06 PM
To: Bret Jordan <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: JACQUENET Christian TGI/OLN <[e-mail]>
Subject: Re: [Cacao] Updated Charter version 03

Hi Bret,

Thank you for taking my comments shared on an earlier version of the draft charter.

Please see inline.

Cheers,
Med

De : Cacao [mailto:[e-mail]] De la part de Bret Jordan
Envoyé : vendredi 1 février 2019 00:54
À : [e-mail]
Objet : [Cacao] Updated Charter version 03

All,

Thanks for all of the great feedback on the charter text.  We have updated the document to address all comments that we have received and are releasing a new version of the text.  You can see it here: https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ and copied below.


### BEGIN

# 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.
[Med]
OLD:
  need to manually identify, create, and document prevention, mitigation, and remediation steps
NEW
 usually identify, create, document, and update 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,

[Med] s/to document them/ to document and udpate them

verify they were correctly executed, or easily share them across organizational boundaries and technology stacks.

[Med] Why “and technology stacks” is mentioned here?

This working group will create a standard that implements the playbook model based on current industry best practices for cybersecurity.
[Med] s/cybersecurity/security

This solution will specifically enable:

1. the creation and documentation of COAs in a structured machine-readable format
2. organizations to perform attestations on COAs
3. the sharing and distribution of COAs across organizational boundaries and technology stacks
[Med] s/ organizational boundaries and technology stacks/boubndaries.
4. the verification of deployed COAs.


This solution will contain (at a minimum) a standard JSON based data model
[Med] I would vote for YANG as a data model (it can be augmented, obsoleted, etc.). Mapping to JSON is straightforward. We don’t need IMO to pick a protocol in the charter.

, a defined set of functional capabilities and associated interfaces, and a mandatory to implement protocol. This solution will also provide a data model for actuators to confirm the status of the COA execution,
[Med] I’m not sure if that part of the architecture will require a specific data model or if protocol-related considerations are to be taken into account. I suggest to make this change:

s/provide a data model for actuators/ provide means for actuators.

however, it will be agnostic of how the COA is implemented by the actuator.
[Med] This text is redundant with “The working group will not consider how shared actions are used/enforced”

Each collaborative course of action will consist of a sequence of cyber defense actions
[Med] delete “cyber” (and in other parts of the text).

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 connected data structure like the OASIS STIX V2 model that provides support for connected data such as threat actors, campaigns, intrusion sets, malware, attack patterns, and other adversarial techniques, tactics, and procedures (TTPs).

[Med] delete « TTPs ».


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.
[Med] What is meant by “process” here?

The working group will not consider how shared actions are used/enforced, except where a response is expected for a specific action or step.
[Med] Detete “step”.

# Goals and Deliverables
This working group has the following major goals and deliverables. Some of the deliverables may be published through the IETF RFC stream as informational or standards track documents.

- 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
  - Identify and document the requirements to effectively report and alert on the deployment of CACAO actions and the potential threat response to those actions

[Med] I’m not sure I would maintain this one as a separate item. I suggest to merge this item with the previous one. It is too early to decide whether one or more protocols will be required.

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

[Med] Please update to cover both YANG and JSON.

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

[Med] It would be helpful to scope the work to identify one or two applicability threats that will be used to assess/validate the proposed solution. Instead of the test document, it suggest to have one or more applicability statements focusing on specific attacks.

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


### END


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