Re: [Cacao] Call for CACAO Charter Consensus

[Roman Danyliw <[e-mail]>]

Hi Bret!

> From: Bret Jordan [mailto:[e-mail]]
> Sent: Friday, May 24, 2019 12:23 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]
> Subject: 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.

I think I understand the key distinction with item #5 now.  The clarity is appreciated.

I've responded inline ...

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

For me this makes this explanation is even more confusing because it mixes the cryptographic assurances (integrity and authenticity)/object-level security with organizational processes uses to "gain confidence" in the fidelity/quality of the COA.

Is the less mature SOCs more confident in the COA it got because there is meta-data on how to use it; and it comes from and is signed by SOC whom it holds high esteem?  

It seems like object/channel security items don't need to be explicitly enumerated and could simply be covered in #3 by saying "_securely_ sharing ...".  This vagueness provides more latitude.

See related comment for item #4

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

Thanks for the explanation.  If this will manifest in the work as only a single boolean flag in the data model, this doesn't seem a necessary item to include in the charter text.  It seems like this item and the #2 discussed above point to the significance of not just a data model for COAs but host of associated meta data (e.g., processing instructions, confidence measures).  Perhaps re-phrase the capability to be (something like):

"2.  Creation and documentation of meta-data about and processing instructions for COAs in a machine readable format" 

"3.  The securely sharing and distributing of COAs and related meta-data across ..."
 
>> 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.

Understood.  Then the text as written isn't clear to me.  The first sentence mentions the existence of a JSON protocol but not what it does.  The second sentence references the JSON data model does additional things without explaining the initial body of work.  Practically, I think clarity could be realized by saying:

"This solution will contain at a minimum a data model specifying the COAs; a defined set of functional capabilities and associated interfaces; and an exchange protocol."

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

It does clarify matters.  Thanks.  I support defining a protocol that "shares the COAs between products", but not defining a protocol to "deliver the COAs to a device directly" at this time.  It seems like too much scope to tackle and could be addressed (with re-chartering at a later date).

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

I'm arguing for precision.  If the quote is "like STIX" then support for other standard would be in scope.  I'd also argue for referencing other IETF work then.

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

Understood.  Perhaps a stronger statement could then be made "The WG will reuse existing data models for atomic actions where possible from related work in OASIS OpenC2 and IETF I2NSF"

> [{
>   “Id”: “cacao--123456”,
>   “Action_type”: “cisco_ios”,
>   “Action”: “deny ip 1.2.3.4"
> },

Referencing Mohamed Boucadair's feedback, the above example makes me think of YANG.  RFC8519 already specified a robust data model for ACL that would operate on a router.  No new data model work.  No new protocol required to pass this to the device (with NETCONF).  Would something like this be in scope?

[{
"id": "cacao-1234",
"action_type":"yang-xxx-rfc8519",
"action":"<some yang blob>"
}]

If so, YANG models should be consider a source of atomic actions per my previous comment on explicit sources of re-use.

> {
>   “Id”: “cacao-98765”,
>   “Action_type”: “openc2”,
>   “Action”: “<some openc2 blob of data>”
> }]

What would be an example of the "human processes" that the WG would want to define?  The above examples don't seem to cover new ground (i.e., they reference the prior work)

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

As noted above.  I feel the orchestration (item #5 and CACAO Distribution and Response Application Layer Protocol) should be deferred for now.

Regards,
Roman

> 
> 
> 
> 
> # 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cacao