Re: [Cacao] Updated Charter version 03

[Allan Thomson <[e-mail]>]

  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.
               [Qin]: Cyber attack may be perfect use case for collaborative course of action, but I assume ansible playbook has other network management automation use cases. Limit the scope to cyber attack is too   restrictive, in my opinion.

AT: The cyber security challenges are immense. It is true that this technology could be extended to consider other non-security use cases but trying to solve an even broader solution set when the cyber security solution is already huge will likely just result in failure for all use cases. My suggestion would be that we focus on cybersecurity and after we have *successful* defined something that is both workable and *implemented* by products in the marketplace then it is worthwhile considering how CACAO can be extended for non-security use cases.


  - 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. 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. However, by removing the reporting/monitoring requirements we are losing an important aspect of the work. 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.

[Qin]: Agree with Med, I am wondering COMI, NETCONF, RESTCONF, is not enough?

AT: No one has suggested what the solution is right now. We are discussing requirements and making sure requirements are clearly defined and agreed before we discuss what would solve those requirements. The charter is about requirements and making sure those requirements are clearly defined. Combining the 2 items (provisioning vs monitoring/reporting) into 1 item suggests an implementation or solution when that is neither the goal or intent of a requirement definition.

Allan

From: Qin Wu <[e-mail]>
Date: Sunday, March 10, 2019 at 6:27 AM
To: Allan Thomson <[e-mail]>, "[e-mail]" <[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,

发件人: Cacao [mailto:[e-mail]] 代表 Allan Thomson
发送时间: 2019年3月9日 0:12
收件人: [e-mail]; Bret Jordan <[e-mail]>; [e-mail]
抄送: JACQUENET Christian TGI/OLN <[e-mail]>
主题: 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’.



  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.
               [Qin]: Cyber attack may be perfect use case for collaborative course of action, but I assume ansible playbook has other network management automation use cases. Limit the scope to cyber attack is too   restrictive, in my opinion.

  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. 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. However, by removing the reporting/monitoring requirements we are losing an important aspect of the work. 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.

[Qin]: Agree with Med, I am wondering COMI, NETCONF, RESTCONF, is not enough?

  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?

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

From: Cacao <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 7, 2019 at 11:06 PM
To: Bret Jordan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: JACQUENET Christian TGI/OLN <[e-mail]<mailto:[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]<mailto:[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."