OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu

 View Only
  • 1.  CSD for OpenC2 Extension published

    Posted 09-09-2024 09:23

    Fellow TC members: The OpenC2 Extension for CACAO CSD01 has been formally published by OASIS

    The files can be found here:  https://docs.oasis-open.org/openc2/openc2-cacao-ext/v1.0/csd01/



    ------------------------------
    David Lemire, CISSP
    HII / National Security Agency
    OpenC2 TC Secretary
    david.lemire@hii-tsd.com
    ------------------------------


  • 2.  RE: CSD for OpenC2 Extension published

    Posted 09-13-2024 18:52
      |   view attached
    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







  • 3.  RE: CSD for OpenC2 Extension published

    Posted 09-15-2024 11:50
    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


    On Sep 13, 2024, at 3:52 PM, David Kemp via OASIS <Mail@mail.groups.oasis-open.org> wrote:







  • 4.  RE: CSD for OpenC2 Extension published

    Posted 09-15-2024 12:38
    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





  • 5.  RE: CSD for OpenC2 Extension published

    Posted 09-15-2024 12:49
    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



    On Sep 15, 2024, at 9:37 AM, David Kemp via OASIS <Mail@mail.groups.oasis-open.org> wrote:

    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






  • 6.  RE: CSD for OpenC2 Extension published

    Posted 09-16-2024 11:10
    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




    On Sun, Sep 15, 2024 at 10:48 AM Allan Thomson via OASIS <Mail@mail.groups.oasis-open.org> wrote:
    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

    OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu

    Post New Message
    Re: CSD for OpenC2 Extension published
    Reply to Group Reply to Sender via Email
    Sep 15, 2024 12:49 PM
    Allan Thomson
    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



    On Sep 15, 2024, at 9:37 AM, David Kemp via OASIS <Mail@mail.groups.oasis-open.org> wrote:

    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  




     
    You are subscribed to "OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu" as bret.jordan.sdo@gmail.com. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.



    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



    On Sep 15, 2024, at 9:37 AM, David Kemp via OASIS <Mail@mail.groups.oasis-open.org> wrote:

    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


    On Sep 13, 2024, at 3:52 PM, David Kemp via OASIS <Mail@mail.groups.oasis-open.org> wrote:





    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






  • 7.  RE: CSD for OpenC2 Extension published

    Posted 09-16-2024 11:20

    I don't believe you'll find anything that proposes a breaking change to CACAO in the OpenC2 Extensions CSD.  As previously noted, it at best barely qualifies for the label "extension" and would probably be better described as a "profile" or "clarification" or "usage example". The concepts therein can be considered independently of any broader discussion of the appropriate level of abstraction for CACAO, which is a worthy topic but a matter that also a longer-term conversation(s).



    ------------------------------
    David Lemire, CISSP
    HII / National Security Agency
    OpenC2 TC Secretary
    david.lemire@hii-tsd.com
    ------------------------------



  • 8.  RE: CSD for OpenC2 Extension published

    Posted 09-16-2024 13:16
    Apologies. I'm on vacation so not following closely. I think we might be having terminology issues. Hopefully Dave and Dave can attend so you all can resolve in realtime. 

    Wrt OC2 actuator profiles - yes we only have one approved but a larger number of drafts - the number depending on how drafty (some are much further along than others). We are hoping to use the next Cybersecurity Automation Village to move a bunch of them along if we can figure out how to get OC2 and CACAO to work together. 

    iPhone, iTypo, iApologize