Practicalities of CACAO / OpenC2 Integration

[dlemire60]

After carefully reading the CACAO v2.0 spec and looking at the examples there and in playbooks from the GH repo, I have some questions regarding the realities of OpenC2 commands being sent from CACAO playbooks. This is loosely related to issue #6.

First, we describe OpenC2 as the Acting capability at the end of a cyber defense OODA loop (e.g., IACD's S-SM-D-A loop) so there's an expectation that the details of the action to be taken are determined dynamically. If the OpenC2 command message is b64encoded w/in the playbook that doesn't seem to offer much opportunity for real-time adjustment. Even if there was a Block-Traffic-OC2 playbook that incorporated knowledge of all of the “firewall” elements in the infrastructure:

1. The address / netblock to be denied is the Target in the OpenC2 command and would be different every execution, necessitating that the b64encoded value be supplied from the decision process and updated within the playbook prior to execution (or something similar).
2. There's an implicit need to update the playbook as the “firewall” structure changes, something that might be a manageable routine playbook maintenance action in an in-prem data center but would be very challenging in a dynamic cloud environment.

Second, there's a question of transferring (addressing) the OpenC2 command to the appropriate Consumer(s), either via the endpoint an HTTP POST would be sent to or the selection of a pub/sub topic to publish the comment onto. There's really nothing in the spec to indicate how the destination of a command would either be determined or passed to the transfer mechanism.
I’d be happy to learn more about how this is envisioned to operate in practice.

[Vasileios-Mavroeidis]

Hi Dave, The producer/consumer systems should handle encoding/decoding. For example, when you use the CACAO Roaster, you don't see the commands in base64, only plain text - JSON. If you check the JSON code while designing a playbook, though, you will see that it is encoded automatically in b64. 1. If the decision-making process is automated, add a variable in the target value. Previous steps in the playbook that collect/perform decision-making will provide the variable:value using the "out_args" property. That's one approach. For the second comment: Assuming that you are referring to a use case that the Consumer is not the Actuator, then you use an agent for the Consumer and a target (or targets) for the actuator(s). I hope this helps. Best, V On Feb 22, 2024, at 17:52, David Lemire ***@***.***> wrote: After carefully reading the CACAO v2.0 spec and looking at the examples there and in playbooks from the GH repo, I have some questions regarding the realities of OpenC2 commands being sent from CACAO playbooks. This is loosely related to issue #6<#6>. First, we describe OpenC2 as the Acting capability at the end of a cyber defense OODA loop (e.g., IACD's S-SM-D-A loop) so there's an expectation that the details of the action to be taken are determined dynamically. If the OpenC2 command message is b64encoded w/in the playbook that doesn't seem to offer much opportunity for real-time adjustment. Even if there was a Block-Traffic-OC2 playbook that incorporated knowledge of all of the “firewall” elements in the infrastructure: 1. The address / netblock to be denied is the Target in the OpenC2 command and would be different every execution, necessitating that the b64encoded value be supplied from the decision process and updated within the playbook prior to execution (or something similar). 2. There's an implicit need to update the playbook as the “firewall” structure changes, something that might be a manageable routine playbook maintenance action in an in-prem data center but would be very challenging in a dynamic cloud environment. Second, there's a question of transferring (addressing) the OpenC2 command to the appropriate Consumer(s), either via the endpoint an HTTP POST would be sent to or the selection of a pub/sub topic to publish the comment onto. There's really nothing in the spec to indicate how the destination of a command would either be determined or passed to the transfer mechanism. I’d be happy to learn more about how this is envisioned to operate in practice. — Reply to this email directly, view it on GitHub<#7>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AG6ZQAU4LSQNKMWYFBCFNULYU5ZU7AVCNFSM6AAAAABDVJT5HSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2DSNJQGE4TKMY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>