Re: [Cacao] Updated Charter version 02

[Roman Danyliw <[e-mail]>]

Hi!



> From: Cacao [mailto:[e-mail]] On Behalf Of Bret Jordan

> Sent: Monday, January 28, 2019 12:07 PM

> To: [e-mail]<mailto:[e-mail]>

> Subject: [Cacao] Updated Charter version 02

>

> All,

>

> We tried to address all of the comments and feedback from Roman in this

> version of the Charter.  Please review.  If there are other changes, please let

> us know.



Thanks for responding to my comments and revising the proposed text.  I have a few more comments noted inline.

> https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/

>

>

>

> ### BEGIN

>

> # Introduction

> To defend against threat actors and advanced attacker toolkits known as

> intrusion sets, organizations need to manually identify, create, and

> document prevention, mitigation, and remediation steps.



Recommend:

s/To defend against threat actors and advanced attacker toolkits known as intrusion sets,/To defend against threat actors and their techniques, tactics and procedures, organizations need .../



IMO, you would need this work whether the attacker is "advanced" or not.  Furthermore, I think we have different definitions of "intrusion sets".



> 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, monitor them for correct execution, or easily and

> dynamically share them across organizational boundaries and technology

> stacks.



What does "dynamically share" mean in this context?  I understand "easily share".  Do you mean share with organizations without pre-agreed arrangements?



> This working group will create a standard that implements the playbook

> model based on current industry best practices for cybersecurity, such as

> those defined in the IACD work from Johns Hopkins APL.



I'm not sure how to take this reference.  Will some artifact from IACD be brought in as the starting point for the work?



> This solution will:

>

> 1. enable the creation and documentation of COAs in a structured machine-

> readable format



Check.  This is clear.



> 2. enable organizations to collaborate on COAs



To me, "collaborate" implies a back-and-forth refinement of the COA in an automated way with the protocol.  Are you suggesting that this level of workflow is needed, or is it something simpler like "sharing" or "exchanging" (per the language used in the first paragraph).  I'm questioning the need for #2 given #3 if you're envisioning a simpler workflow.



> 3. enable the

> sharing and distribution of COAs across organizational boundaries and

> technology stacks



Check.  This is clear.



> 4. enable the monitoring and verification of deployed

> COAs.



Editorial: the language in #3 and #4 seems like a duplicate to the text already stated in the first paragraph.



Do you mean providing a data format/protocol to convey status about the execution of the COAs between organizations (e.g., "Org-2, I got your COA-A and applied it")?  Or a format/protocol to actually query the devices (or a shim/proxy in that tasks the devices) executing the COAs to determine what happened (e.g., "Router-1 is ACL-1 applied?").  Is the language about capabilities/interfaces below enabling that verification?

> This solution will contain at a minimum; a standard data model,



How is this text different than what was stated in "[t]his solution will: 1. Enable the creation and documentation ..."



>  a set of

> functional capabilities and associated interfaces, and a mandatory to

> implement protocol.



The notion of functional capabilities and associated interfaces is introduced here.  I think it is worth adding a little text to refine what is meant by that.



> Each collaborative course of action will consist of a sequence of cyber

> defense actions that can be executed by the various systems that those

> actions target. Further, these COAs can be coordinated and deployed across

> heterogeneous cyber security systems such that both the actions requested

> and the resultant outcomes may be monitored and verified. These actions

> will be referenceable in a connected data structure that provides support for

> connected data such as threat actors, campaigns, intrusion sets, malware,

> attack patterns, and other adversarial techniques, tactics, and procedures

> (TTPs).



Specifying threat actors, campaigns, etc seems like it has been done by work such as OASIS STIX or MILE IODEF.  I recommend saying that this COAs format will provide a means to reference this class of data through a variety of previously developed formats.  You might have meant that by "these actions will be referenceable in ..." but I would be clearer.



> Where possible the working group will leverage existing efforts, like OpenC2

> that *may* 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.



What does the "*may*" mean in this context?  Perhaps "Where possible the working will consider existing work like OASIS OpenC2, IETF I2NSF, ..."



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

>   - Document the use cases and requirements



s/Document/Specify/



> - CACAO Functional Architecture: Roles and Interfaces

>   - Identify and document the system functions and roles that are needed to

> enable Collaborative Courses of Action.



s/Identify and document/Specify/



> - CACAO Protocol Specification

>   - Identify and document the configuration for a series of mandatory to

> implement protocols that can be used to distribute courses of action in both

> direct delivery and publish-subscribe methods



s/Identify and document/Standardize/



What's a "configuration for a protocol"?  Is that a profile for something that already exists?  Is that saying there is not a new protocol to develop only a matter of choosing one?



It isn't uncommon to include a reference to what starting points for these protocols might be.



IMO, "series of MTI protocols" boxes in the work too much.  Might there be a case for an alternative to the MTI protocol?



> - CACAO Distribution and Response Application Layer Protocol

>   - Identify and document the requirements to effectively monitor, report,

> and alert on the distribution of CACAO actions and the potential threat

> response to those actions



My questions above will help me understand this item better.



> - CACAO JSON Data Model

>   - Create a JSON data model (and possibly a general information model and

> CBOR model) that can capture and enable collaborative courses of action



Recommend removing the parenthetical, or making an explicit bullet for an information model.  CBOR would be another data model.



> - CACAO Interoperability Test Documents

>   - Define and create a series of tests and documents to assist with

> interoperability of the various systems involved.



Does this need to be an informational RFC or can it just be put in a wiki?  Would this be published?  I ask because the use cases/requirements were called out as potentially not being published.



> The working group may decide to not publish the use cases and

> requirements as RFCs. That decision will be made during the lifetime of the

> working group.

>

>

>

> ### END



Regards,

Roman