I would agree with Allan here, we need to discuss on a call.
A lot of products these days are ditching the CLI. I for one love the standard Cisco (aka Stanford) style CLI, but I see less and less products having robust CLIs. Some have them, but they are very limited and often limited to setup / admin functions. So Playbooks need to work with the market is using today and they also need to fundamentally support manual / human processed commands and tasks.
From my understanding OpenC2 only has one actuator profile so far, is that correct? And if I remember correctly it was for a netfilter packet filter firewall. I would like to make sure CACAO can work with OpenC2 if it ever becomes adopted at scale. But I am also not interested in making significant breaking changes to CACAO unless they are really needed or things we did are really wrong. CACAO is already being adopted and integrated into production products.
Bret
Hi David - This is why I suggest we discuss in-person on the TC call. I believe that CACAO has such an approach for CLI approach to cybersecurity... -posted to the "OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Security" community
Re: CSD for OpenC2 Extension published | | | Hi David - This is why I suggest we discuss in-person on the TC call.
I believe that CACAO has such an approach for CLI approach to cybersecurity automation already. But I don't believe we will resolve this issue over email.
I would also say that not all cybersecurity automation needs or wants to follow the CLI approach. We tried to be flexible and support all forms of interactions that we were aware of at the time.
Please try to join the TC call on Tuesday if you can. I look forward to further discussions then.
Allan
Abstraction is the key to designing playbooks with comprehensible as well as comprehensive coverage of the security ecosystem. OpenC2 is just an... -posted to the "OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Security" community
| | Reply to Group via Email Reply to Sender via Email View Thread Recommend Forward |
Original Message: Sent: 9/15/2024 12:38:00 PM | |
| |
Original Message:
Sent: 9/15/2024 12:49:00 PM
From: Allan Thomson
Subject: RE: CSD for OpenC2 Extension published
Hi David - This is why I suggest we discuss in-person on the TC call.
I believe that CACAO has such an approach for CLI approach to cybersecurity automation already. But I don't believe we will resolve this issue over email.
I would also say that not all cybersecurity automation needs or wants to follow the CLI approach. We tried to be flexible and support all forms of interactions that we were aware of at the time.
Please try to join the TC call on Tuesday if you can. I look forward to further discussions then.
Allan
Abstraction is the key to designing playbooks with comprehensible as well as comprehensive coverage of the security ecosystem. OpenC2 is just an... -posted to the "OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Security" community
Original Message:
Sent: 9/15/2024 12:38:00 PM
From: David Kemp
Subject: RE: CSD for OpenC2 Extension published
Abstraction is the key to designing playbooks with comprehensible as well as comprehensive coverage of the security ecosystem. OpenC2 is just an example of layered design, whether CACAO has anything to do with OpenC2 or not.
View the entire security ecosystem as accessible from a command line - systems anywhere can be queried and modified in any manner from a playbook (given the required connectivity and authorization). Then view the command line as having structure, the way
Powershell uses text typed at a terminal to use objects with fields as other shells use simple variables.
Get-Process is analogous to an OpenC2 action "get" with target "Process".
No matter what needs to be done in the cybersecurity ecosystem, if you can think up a CLI command to do it, a playbook shell (runner/interpreter) can execute it. Using that approach, CACAO would be the documentation for that playbook interpreter. I'm not suggesting doing anything to accommodate OpenC2, I'm suggesting that CACAO use the CLI shell-ish approach to cybersecurity automation.
David
Original Message:
Sent: 9/15/2024 11:50:00 AM
From: Allan Thomson
Subject: RE: CSD for OpenC2 Extension published
CACAO was designed for playbooks that are much more comprehensive (read: broad) coverage of ideally as much of the security ecosystem as possible.
While I *think* I understand you are suggesting OpenC2 uses a slightly different model, I'm not sure what you are suggesting changes in CACAO to accommodate OpenC2 differences.
Certainly any disruptive change that would change the model of CACAO design philosophy should be weighed across all requirements supporting the entire security ecosystem not just OpenC2.
To be clear, I'm against disruptive change to CACAO 2.1 unless there are significant reasons to do so that are far reaching beyond one technology. And it also seems like such a change would require a major version change to CACAO and not be treated as a minor change if the TC decide to adopt such a change.
This topic is important and we should discuss at the TC's earliest convenience when we are able to consider all aspects. Debating over email is never easy, and especially what seems like a big change.
Allan
Original Message:
Sent: 9/13/2024 6:52:00 PM
From: David Kemp
Subject: RE: CSD for OpenC2 Extension published
Bret said: "What I am more interested in, is folding these ideas into the 2.1 release of CACAO. I understand the need, at times, to produce an extension and there are good use cases for them. But a core feature like this, is not one of them, IMHO."
I agree. The OpenC2 CACAO extension was built, after significant analysis, assuming that an extension is the least intrusive integration approach. That is true, but full integration into 2.1, though requiring more effort, time, and mindshifting, should yield a better result in the end.
The most significant obstacle, I believe, is deciding how to resolve the level-of-abstraction impedance mismatch between CACAO and OpenC2. OpenC2 has pursued from the beginning a high-level approach: a command represents the the desired effect to be achieved, separately from the means used to achieve it. An OpenC2 command is a very simple thing - a verb-noun pair (a "security action") and the domain-specific arguments needed to perform that action. That is specified separately from and independently of the target systems and agents used to perform the action. While CACAO defines things like "ssl command", OpenC2 says "scan wifi" which should perform the desired action whether it happens on the local host, an SSL connection to remote Windows cmd, an SSL connection to Windows PowerShell, a winrm remote management action, a Linux bash command or makefile, a docker container attach, etc, etc. A playbook author isn't going to know how organizations implement their networks, so it seems more appropriate to map the "security action" to the implementing technology on the target side.
I understand this approach may be considered disruptive, but understanding OpenC2's layered design is a necessity if the CACAO TC wishes to pursue integration rather than extension. "OpenC2 command" isn't just one of many command types; all actions would be commands based on a harmonized and meaningful set of verb-nouns.
Something to discuss.
David Kemp
NSA Cybersecurity Collaboration Center