Re: [Cacao] Call for CACAO Charter Consensus

Roman,

Thanks for your comments as well.  The goals of item 5 is to ensure that if product A sends a playbook to a product B, that product A can get a response back saying that product B received it, acted on it, successfully acted on it, etc.   To do this you need to call out an application layer protocol (say MQTT, RabbitMQ, HTTP, etc) that both ends can implement so you can have interoperability.  The whole goal of this work is to have a solution that is easy for vendors to adopt and make use of it. 

But if this is going to cause a problem, we could break this out of the work for now, and do it later after the first batch is done. 

I will try and address your comments in-line below.

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

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

I am not sure what other word to use.  If you could help suggested a different one, that would be awesome. The goal is for organizations to be able to digitally sign sections or parts of the COA or the entire COA to say that this does work as expected or does prevent, mitigate, or remediate this threat.  The fundamental goal is to be able to give organizations that have a less mature security operations center or cyber defense center some level of confidence that other organizations or vendors have verified that COA.  

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

For a complete deployment of the solution you would want the ability to do a dry run of the COA.  Maybe this does not have to be in the charter, but it was a goal item that we talked about very early on.  Maybe it is simply a flag or boolean that is added to the top of the COA that says “test run” or “dry run”.  

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

There would only be a single data model that we would define in this work. The goal of the protocol is to ensure that two products can share and collaborate on COAs.  More than likely some of this will be done via HTTP or MQTT/RabbitMQ.   The point is we need to pick one and define how it would be used so vendors can build products.  We would also want to define some interoperability tests so that vendors can self-verify that they are compliant. 

> The above text describes only one protocol, but the deliverables list two.  What is the second protocol doing?
> 

There are two types of communications.  One is the sharing of COAs between products that are being used to work on, collaborate on, etc.  The other is the execution side of the COA, when I send this COA to a device directly or to an orchestration device I would like to have defined messages that I get back to talk about if the COA was taken, deployed, failed, etc. So while they may both use the same application layer protocol, we called them out as two separate line items so we could work on them.  Does that help? 

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

The reason we have called out STIX is that is what the threat intelligence community and FIRST has adopted.  So we want to make sure that our playbooks and COAs can be referenced in the graph (nodes/vertices and edges). Because you will want to ensure that you can link CACAO playbooks against campaigns, threat actors, intrusion sets, TTPs, etc. 

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

A playbook may have many atomic actions,  Some may be human process based, some may be computer automation based, some may use vendor proprietary commands, some may use things like OpenC2 or I2NSF.  The goal is for an atomic action to be able to define “what command” is coming next.  OpenC2 and I2NSF do not define all the possible commands that we need to be able to define.  Thus those would be two options in a taxonomy.  For example:

[{
  “Id”: “cacao--123456”,
  “Action_type”: “cisco_ios”,
  “Action”: “deny ip 1.2.3.4"
},
{
  “Id”: “cacao-98765”,
  “Action_type”: “openc2”,
  “Action”: “<some openc2 blob of data>”
}]

> 
>> 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”)

The idea of sharing a COA with you and figuring out if you deployed it or not is out of scope.  But getting a response back from the devices in my network or my orchestration tool that I have deployed the COA to is in scope. When deploying this you want to be able to get back standard defined messages that mean something, are easily to understand, and allow vendors to add extra content if needed.  But you need a way of knowing did my firewall actually do what I told it to do. 

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

I tried to address this above and in my last email to Michael.  Does this now make sense? 

> 
>> - 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.
> -- 
> Cacao mailing list
> Cacao@ietf.org
> https://www.ietf.org/mailman/listinfo/cacao