TC Members:  Those who attended this morning's TC Meeting session heard Duncan and I briefly discuss a candidate work product proposal that I elected to defer pending future discussion. I realized that it would benefit any future discussion to share the background and my current uncertain thinking, in preparation for the discussion I've placed on the agenda for next Wednesday's working meeting.

At the 27 March working meeting we talked a lot about the relationship between CACAO and OpenC2. I mentioned several issues I'd created in the CACAO GH Repo after a careful read of the CACAO v2.0 spec, particularly:

• #6: OpenC2 Support Should Be Updated (particularly, stale HTTP transfer info and no mention of pub/sub messaging)
• #7: Practicalities of CACAO / OpenC2 Integration (basically, how do you connect an action-oriented tech like OpenC2 to a somewhat less dynamic tech like playbooks?)

The CACAO TC leadership's response boils down to "tell us what we should do", and they suggested defining an OpenC2 extension for CACAO as a new OpenC2 TC work product, similar to the Layout Extension that the CACAO Roaster folks created. I took an action to define what an OpenC2 Extension work product might look like, gave it some thought, and came up with the following:

Title: CACAO OpenC2 Extension

Abstract:  Collaborative Automated Course of Action Operations (CACAO) is a schema and taxonomy for cyber security playbooks. The CACAO specification describes how these playbooks can be created, documented, and shared in a structured and standardized way across organizational boundaries and technological solutions. This extension builds on existing CACAO OpenC2 features to improve modularity and utilize the current OpenC2 Transfer Specifications for MQTT (v1.0) and HTTPS (v1.1).

Objectives:

• Define standardized CACAO MQTT and HTTPS Agents for OpenC2 message transfers

• Define an updated CACAO OpenC2 Command Type not bound to a specific transfer mechanism (extending the command-type-ov defined in section 5.2 of the CACAO v2.0 spec)

• Identify CACAO control flow capabilities needed for OpenC2 (e.g., await Consumer response) that may be missing from v2.0 spec.

Having done that, and then worked on a CACAO playbook for the CASP Village demo where I created notional (but possibly wrong) solutions for some of these items, I'm on the fence whether it's premature to actually hold a TC vote on adopting this as a new work product. I guess I'm not sure that we're really smart enough about CACAO (yet) to do this work. And with the release of SOARCA there's an opportunity to see how someone else decided to make OpenC2 / CACAO integration work.

There's an OpenC2 playbook on this page on the SOARCA site (https://cossas.github.io/SOARCA/docs/core-components/modules/), about 3/4 of the way down. I noted that both the SOARCA example and my demo playbook for the village used CACAO Agents for transfer capabilities and CACAO Targets for OpenC2 APs. I don't know if that's correct but at least two parties independently selected the same approach.

Dave

__________________

David Lemire
IA Systems Engineer
Mission Technologies
(301) 575-5190 (o)    (240) 938-9350 (m)
HII.com

My two cents is we should establish the work item.

There are three possibilities:

1. We establish the work item, learn CACAO, create the extension, put it out for comment with hopefully some OC2 experts attending CTI and pointing it out to them, and then either we standardize the extension or they take our work and incorporate into their standard
2. We establish the work item, learn CACAO, start creating the extension and get far enough that we/they then decide the work is better done in CTI and we move the work over.
3. We try to get them establish the work item, get "them" to learn OC2, they write the extension, ...

IMHO the only way #3 would work is if "we" (ie the experts of our TC) attend their TC and effectively do #1 anyway but over there. My opinion is having these OpenC2 extensions would benefit OC2 awareness and adoption. I also think us learning CACAO would benefit OpenC2 because we could then make playbooks for OpenC2 usecases. I don't see the CTI crowd (ie those not also in the OpenC2 crowd) thinking OpenC2 is valuable enough that they will take the trouble to learn OpenC2. This is especially true since we don't actually have the actuator profiles they will need and they won't be OpecC2 savy enough to hand wave it. I think if we did the work, made playbooks using the new extensions (maybe even finalized some AP's in conjunction with what is needed), that they would then see the value. I just don't seem them seeing it a priori – or they would have done this task already.

TC Members:  Those who attended this morning's TC Meeting session heard Duncan and I briefly discuss a candidate work product proposal that I elected to defer pending future discussion. I realized that it would benefit any future discussion to share the background and my current uncertain thinking, in preparation for the discussion I've placed on the agenda for next Wednesday's working meeting.

At the 27 March working meeting we talked a lot about the relationship between CACAO and OpenC2. I mentioned several issues I'd created in the CACAO GH Repo after a careful read of the CACAO v2.0 spec, particularly:

• #6: OpenC2 Support Should Be Updated (particularly, stale HTTP transfer info and no mention of pub/sub messaging)
• #7: Practicalities of CACAO / OpenC2 Integration (basically, how do you connect an action-oriented tech like OpenC2 to a somewhat less dynamic tech like playbooks?)

The CACAO TC leadership's response boils down to "tell us what we should do", and they suggested defining an OpenC2 extension for CACAO as a new OpenC2 TC work product, similar to the Layout Extension that the CACAO Roaster folks created. I took an action to define what an OpenC2 Extension work product might look like, gave it some thought, and came up with the following:

Title: CACAO OpenC2 Extension

Abstract:  Collaborative Automated Course of Action Operations (CACAO) is a schema and taxonomy for cyber security playbooks. The CACAO specification describes how these playbooks can be created, documented, and shared in a structured and standardized way across organizational boundaries and technological solutions. This extension builds on existing CACAO OpenC2 features to improve modularity and utilize the current OpenC2 Transfer Specifications for MQTT (v1.0) and HTTPS (v1.1).

Objectives:

• Define standardized CACAO MQTT and HTTPS Agents for OpenC2 message transfers

• Define an updated CACAO OpenC2 Command Type not bound to a specific transfer mechanism (extending the command-type-ov defined in section 5.2 of the CACAO v2.0 spec)

• Identify CACAO control flow capabilities needed for OpenC2 (e.g., await Consumer response) that may be missing from v2.0 spec.

Having done that, and then worked on a CACAO playbook for the CASP Village demo where I created notional (but possibly wrong) solutions for some of these items, I'm on the fence whether it's premature to actually hold a TC vote on adopting this as a new work product. I guess I'm not sure that we're really smart enough about CACAO (yet) to do this work. And with the release of SOARCA there's an opportunity to see how someone else decided to make OpenC2 / CACAO integration work.

There's an OpenC2 playbook on this page on the SOARCA site (https://cossas.github.io/SOARCA/docs/core-components/modules/), about 3/4 of the way down. I noted that both the SOARCA example and my demo playbook for the village used CACAO Agents for transfer capabilities and CACAO Targets for OpenC2 APs. I don't know if that's correct but at least two parties independently selected the same approach.

Dave

__________________

David Lemire
IA Systems Engineer
Mission Technologies
(301) 575-5190 (o)    (240) 938-9350 (m)
HII.com