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