Open dlemire60 opened 6 months ago
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.
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 #6https://github.com/oasis-tcs/cacao/issues/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:
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 GitHubhttps://github.com/oasis-tcs/cacao/issues/7, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG6ZQAU4LSQNKMWYFBCFNULYU5ZU7AVCNFSM6AAAAABDVJT5HSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2DSNJQGE4TKMY. You are receiving this because you are subscribed to this thread.Message ID: @.***>
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:
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.