Re: [Cacao] Call for CACAO Charter Consensus

[Roman Danyliw <[e-mail]>]

Hi!

> From: Cacao [mailto:[e-mail]] On Behalf Of Joseph Salowey
> Sent: Friday, May 10, 2019 9:39 AM
> To: [e-mail]
> 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.

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

>   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/QKVvohhYvwU46jcsLYyYY1agP
> TU
> 
> 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  

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.
>  4. the verification of COA correctness prior to deployment.

What is "correctness" in this context?

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

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?

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

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

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

(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"?

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