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

  • 1.  Re: [cacao] Agenda for next Tuesday's call

    Posted 10-14-2019 14:05




    Allen I think we (or at least you and I do) agree that BPMN is probably overkill for what we need.

     
    To re-iterate my perspective, I think a subset of what BPMN does in JSON is sufficient for most requirements. I m not sure I agree the JSON translation that was pointed to is the best approach from my perspective. Taking something that
    was designed for XML and much broader uses is not necessarily the most effective way to design something.

     
    My point was that the group should discuss the pros/cons in the upcoming meeting on approaches (not just BPMN) so that we can have consensus on an approach that works for all orgs participating.

     
    Regards
     
    Allan
     

    From: Allen Hadden <ahadden@us.ibm.com>
    Date: Monday, October 14, 2019 at 5:08 AM
    To: Allan Thomson <athomson@lookingglasscyber.com>
    Cc: "Bret_Jordan@symantec.com" <Bret_Jordan@symantec.com>, "cacao@lists.oasis-open.org" <cacao@lists.oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
    Subject: RE: [cacao] Agenda for next Tuesday's call


     



    Our product uses BPMN for playbooks today.  I'd say that there's nothing that CACAO will want to do that cannot in some way be represented in BPMN.  There is nothing (or at least
    very little) in BPMN that wouldn't be useful for CACAO.  This shouldn't be surprising since BPMN is intended to express business processes and what we're talking about with playbooks are exactly that...business processes, but in the security domain.


     


    The problem is that if you look at BPMN, a lot of what's there would just be considered "nice to have" from a CACAO perspective.  Good example:  swim lanes.  Could you come up
    with a CACAO use case that could make use of swim lanes?  Sure.  Would they be required?  Not really.


     


    A lot of the advanced BPMN features are only useful when you start trying to express general organizational playbooks (e.g. CompanyX's Malware Process) instead of playbooks targeted
    at mitigating specific threats (e.g. Mitigate MalwareX).


     


    Another problem is that full BPMN is so large that realistically the only way to develop a product with it is to integrate an existing BPMN product.  Implementing your own would
    be a ton of work and adapting it to fit a less flexible model in an existing product would be tough.  So on the one hand, it's great to be able to leverage an existing library.  OTOH, is that a position we want to take as a spec?


     


    One option worth of consideration is to take the JSON-translation that Jason K. linked and define the following:


     


    1) a "whitelist" showing which elements are to be included (e.g. don't include "swim lanes" if we don't think they're important).


    2) specific extensions to the model (BPMN supports extension elements and we'd very likely need some...for example, "service tasks" for OpenC2, Ansible, etc.)


    3) object models on which the process will depend (e.g. it could be that a playbook works against a "threat", which would probably be a STIX model)


     


    Probably there are other things we'd need besides those 3, but that should get the ball rolling if we decide to consider that path.


     


    Allen









    Allen Hadden
    STSM & Chief Architect IBM Resilient







     











    w:   508-560-3502
    e: ahadden@us.ibm.com  












     


     





  • 2.  Re: [cacao] Agenda for next Tuesday's call

    Posted 10-14-2019 14:34
    Hi everyone, I want to throw what we are doing into the ring. We utilize an open source WF language/engine called Orquesta which is part of the Stackstorm project, which, while already open source - was donated to the Linux Foundation recently. It's a graph based workflow language that in my opinion in many ways solves alot of what this group is trying to solve for. For sure - I have identified some areas for improvement, but we are using it for security workflows in production environments and it's fared quite well. My guess is that the biggest pushback from this group will be that it's written in YAML and not JSON. While I understand the drawbacks of YAML, I believe it's easier for a non-developer analyst to use YAML with the proper linting IDE. For evaluations for transitions it uses Jinja or YAQL to evaluate decisions similar to how Ansible works. Docs: https://docs.stackstorm.com/orquesta/index.html Some examples: https://github.com/StackStorm/st2/tree/master/contrib/examples/actions/workflows/ I have more security specific examples - but I'll leave it to everyone's imagination for now as I would need to sanitize them a bit. JP Bourget Syncurity www.syncurity.net t: https://twitter.com/syncurity https://twitter.com/jp_bourget in: https://www.linkedin.com/company/syncurity On Mon, Oct 14, 2019 at 10:04 AM Allan Thomson < athomson@lookingglasscyber.com > wrote: Allen I think we (or at least you and I do) agree that BPMN is probably overkill for what we need. To re-iterate my perspective, I think a subset of what BPMN does in JSON is sufficient for most requirements. I m not sure I agree the JSON translation that was pointed to is the best approach from my perspective. Taking something that was designed for XML and much broader uses is not necessarily the most effective way to design something. My point was that the group should discuss the pros/cons in the upcoming meeting on approaches (not just BPMN) so that we can have consensus on an approach that works for all orgs participating. Regards Allan From: Allen Hadden < ahadden@us.ibm.com > Date: Monday, October 14, 2019 at 5:08 AM To: Allan Thomson < athomson@lookingglasscyber.com > Cc: " Bret_Jordan@symantec.com " < Bret_Jordan@symantec.com >, " cacao@lists.oasis-open.org " < cacao@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Subject: RE: [cacao] Agenda for next Tuesday's call Our product uses BPMN for playbooks today. I'd say that there's nothing that CACAO will want to do that cannot in some way be represented in BPMN. There is nothing (or at least very little) in BPMN that wouldn't be useful for CACAO. This shouldn't be surprising since BPMN is intended to express business processes and what we're talking about with playbooks are exactly that...business processes, but in the security domain. The problem is that if you look at BPMN, a lot of what's there would just be considered "nice to have" from a CACAO perspective. Good example: swim lanes. Could you come up with a CACAO use case that could make use of swim lanes? Sure. Would they be required? Not really. A lot of the advanced BPMN features are only useful when you start trying to express general organizational playbooks (e.g. CompanyX's Malware Process) instead of playbooks targeted at mitigating specific threats (e.g. Mitigate MalwareX). Another problem is that full BPMN is so large that realistically the only way to develop a product with it is to integrate an existing BPMN product. Implementing your own would be a ton of work and adapting it to fit a less flexible model in an existing product would be tough. So on the one hand, it's great to be able to leverage an existing library. OTOH, is that a position we want to take as a spec? One option worth of consideration is to take the JSON-translation that Jason K. linked and define the following: 1) a "whitelist" showing which elements are to be included (e.g. don't include "swim lanes" if we don't think they're important). 2) specific extensions to the model (BPMN supports extension elements and we'd very likely need some...for example, "service tasks" for OpenC2, Ansible, etc.) 3) object models on which the process will depend (e.g. it could be that a playbook works against a "threat", which would probably be a STIX model) Probably there are other things we'd need besides those 3, but that should get the ball rolling if we decide to consider that path. Allen Allen Hadden STSM & Chief Architect IBM Resilient w: 508-560-3502 e: ahadden@us.ibm.com


  • 3.  Re: [EXT] Re: [cacao] Agenda for next Tuesday's call

    Posted 10-14-2019 18:52
    I have no heart burn over YAML.  I think for the most part you can go back and forth between JSON and YAML.  I like some of the things you have done in this.  What is the license on this design, if we decided to use parts of it? Bret From: JP Bourget (Syncurity) <jp@syncurity.net> Sent: Monday, October 14, 2019 8:34 AM To: Allan Thomson <athomson@lookingglasscyber.com> Cc: Allen Hadden <ahadden@us.ibm.com>; Bret Jordan <Bret_Jordan@symantec.com>; cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com> Subject: [EXT] Re: [cacao] Agenda for next Tuesday's call   Hi everyone,  I want to throw what we are doing into the ring. We utilize an open source WF language/engine called Orquesta which is part of the Stackstorm project, which, while already open source - was donated to the Linux Foundation recently. It's a graph based workflow language that in my opinion in many ways solves alot of what this group is trying to solve for. For sure - I have identified some areas for improvement, but we are using it for security workflows in production environments and it's fared quite well.  My guess is that the biggest pushback from this group will be that it's written in YAML and not JSON. While I understand the drawbacks of YAML, I believe it's easier for a non-developer analyst to use YAML with the proper linting IDE. For evaluations for transitions it uses Jinja or YAQL to evaluate decisions similar to how Ansible works. Docs:  https://docs.stackstorm.com/orquesta/index.html Some examples:  https://github.com/StackStorm/st2/tree/master/contrib/examples/actions/workflows/ I have more security specific examples - but I'll leave it to everyone's imagination for now as I would need to sanitize them a bit.  JP Bourget Syncurity www.syncurity.net t:  https://twitter.com/syncurity     https://twitter.com/jp_bourget in:  https://www.linkedin.com/company/syncurity On Mon, Oct 14, 2019 at 10:04 AM Allan Thomson < athomson@lookingglasscyber.com > wrote: Allen – I ‘think’ we (or at least you and I do) agree that BPMN is probably overkill for what we need.   To re-iterate my perspective, I think a subset of what BPMN does in JSON is sufficient for ‘most’ requirements. I’m not sure I agree the JSON translation that was pointed to is the best approach from my perspective. Taking something that was designed for XML and much broader uses is not necessarily the most effective way to design something.   My point was that the group should discuss the pros/cons in the upcoming meeting on approaches (not just BPMN) so that we can have consensus on an approach that works for all orgs participating.   Regards   Allan   From: Allen Hadden < ahadden@us.ibm.com > Date: Monday, October 14, 2019 at 5:08 AM To: Allan Thomson < athomson@lookingglasscyber.com > Cc: " Bret_Jordan@symantec.com " < Bret_Jordan@symantec.com >, " cacao@lists.oasis-open.org " < cacao@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Subject: RE: [cacao] Agenda for next Tuesday's call   Our product uses BPMN for playbooks today.  I'd say that there's nothing that CACAO will want to do that cannot in some way be represented in BPMN.  There is nothing (or at least very little) in BPMN that wouldn't be useful for CACAO.  This shouldn't be surprising since BPMN is intended to express business processes and what we're talking about with playbooks are exactly that...business processes, but in the security domain.   The problem is that if you look at BPMN, a lot of what's there would just be considered "nice to have" from a CACAO perspective.  Good example:  swim lanes.  Could you come up with a CACAO use case that could make use of swim lanes?  Sure.  Would they be required?  Not really.   A lot of the advanced BPMN features are only useful when you start trying to express general organizational playbooks (e.g. CompanyX's Malware Process) instead of playbooks targeted at mitigating specific threats (e.g. Mitigate MalwareX).   Another problem is that full BPMN is so large that realistically the only way to develop a product with it is to integrate an existing BPMN product.  Implementing your own would be a ton of work and adapting it to fit a less flexible model in an existing product would be tough.  So on the one hand, it's great to be able to leverage an existing library.  OTOH, is that a position we want to take as a spec?   One option worth of consideration is to take the JSON-translation that Jason K. linked and define the following:   1) a "whitelist" showing which elements are to be included (e.g. don't include "swim lanes" if we don't think they're important). 2) specific extensions to the model (BPMN supports extension elements and we'd very likely need some...for example, "service tasks" for OpenC2, Ansible, etc.) 3) object models on which the process will depend (e.g. it could be that a playbook works against a "threat", which would probably be a STIX model)   Probably there are other things we'd need besides those 3, but that should get the ball rolling if we decide to consider that path.   Allen Allen Hadden STSM & Chief Architect IBM Resilient   w:   508-560-3502 e: ahadden@us.ibm.com      


  • 4.  RE: [cacao] Agenda for next Tuesday's call

    Posted 10-14-2019 20:58




    All,
    I would like to add in some experimentation that JHU/APL has done with BPMN for Playbooks before we all dismiss the concept of using BPMN.
     
    First we determined that we only need a small subset of the BMPN symbols for the flow. Second, we worked with Demisto and Cybersponse tools to translate the XML produced from BPMN to the SOAR Platform native
    language. For  Cybersponse that was JSON (they did the translation for us). For Demisto we created the XML-YAML translation using Python. We found that although there are numerous (40+) free BPMN tools available, we could use the python code to translate
    any of the BPMN XML outputs to YAML.
     
    I have attached one of our BPMN (we called them workflows) playbooks and its XML output (these were demonstrated at one of our IACD ICs).  To see the video of this go to:
    https://www.youtube.com/watch?v=sG1S3BIpqrM
     
    Bottom-line there needs to be some sort of tool that can be used to create the playbooks and output some machine readable code. We chose BPMN because it s already a standard, most tools are free and many are
    pretty straight forward to use. Is it overkill? Maybe, BPMN is powerful but its far simpler than creating our own. The advantage to BPMN also includes having one tool that can be used to generate both the graphic representation for the developers/consumers
    to understand and machine readable code for SOAR Platforms to ingest. We have also taken a Cybersponse Playbook converted it to BPMN XML, altered it in BPMN and then uploaded it to Demisto, successfully.
     
    If you want more information and workflows (CACAO playbook) examples please see:
    https://www.iacdautomate.org/playbook-and-workflow-examples
     
    Thanks, look forward to tomorrow s call.

    Karin W. Marr

    240-228-7760

    Attachment(s)



  • 5.  Re: [EXT] RE: [cacao] Agenda for next Tuesday's call

    Posted 10-14-2019 22:00




    Karin,




    Can you look at the written playbook I have in the use cases document and prepare an example of what this would look like in BPMN / a JSON version of BPMN?




    Bret





    From: Marr, Karin W. <Karin.Marr@jhuapl.edu>
    Sent: Monday, October 14, 2019 2:58 PM
    To: Allan Thomson <athomson@lookingglasscyber.com>; Allen Hadden <ahadden@us.ibm.com>
    Cc: Bret Jordan <Bret_Jordan@symantec.com>; cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>
    Subject: [EXT] RE: [cacao] Agenda for next Tuesday's call
     




    All,
    I would like to add in some experimentation that JHU/APL has done with BPMN for Playbooks before we all dismiss the concept of using BPMN.
     
    First we determined that we only need a small subset of the BMPN symbols for the flow. Second, we worked with Demisto and Cybersponse tools to translate the XML produced from BPMN to the SOAR Platform native
    language. For  Cybersponse that was JSON (they did the translation for us). For Demisto we created the XML-YAML translation using Python. We found that although there are numerous (40+) free BPMN tools available, we could use the python code to translate
    any of the BPMN XML outputs to YAML.
     
    I have attached one of our BPMN (we called them workflows) playbooks and its XML output (these were demonstrated at one of our IACD ICs).  To see the video of this go to:

    https://www.youtube.com/watch?v=sG1S3BIpqrM
     
    Bottom-line there needs to be some sort of tool that can be used to create the playbooks and output some machine readable code. We chose BPMN because it s already a standard, most tools are free and many
    are pretty straight forward to use. Is it overkill? Maybe, BPMN is powerful but its far simpler than creating our own. The advantage to BPMN also includes having one tool that can be used to generate both the graphic representation for the developers/consumers
    to understand and machine readable code for SOAR Platforms to ingest. We have also taken a Cybersponse Playbook converted it to BPMN XML, altered it in BPMN and then uploaded it to Demisto, successfully.
     
    If you want more information and workflows (CACAO playbook) examples please see:
    https://www.iacdautomate.org/playbook-and-workflow-examples
     
    Thanks, look forward to tomorrow s call.

    Karin W. Marr

    240-228-7760



  • 6.  RE: [cacao] Agenda for next Tuesday's call

    Posted 10-15-2019 11:57
    +1 on BPMN combining the logical and graphical representation.  The alternative is to display the logic tree logically, which might not be how people are actually thinking about the problem (and would be different for different implementations).   Regarding translation to SOAR tools.  We've done similar translations for our customers who had pre-existing BPMN diagrams and wanted to convert them into Resilient's BPMN.  I think we may have actually done it for a JHU/APL example at some point too.  The trick with BPMN and portability between SOAR tools are the model bindings.  For example, if there's a condition (e.g. exclusive gateway in BPMN), on what variables is it acting?  If there's a script, what variables can it read/write and functions can it call?  If you can define the bindings, then achieving BPMN portability is achievable.   Having spent 3+ years working with BPMN in SOAR, I can say confidently that has had an answer for all workflow problems we've encountered in customer use cases.  It exposes many of the complexities that you encounter in process modeling. For example, the semantics for branching and joining are way more complicated in reality than most would initially expect.  If you roll your own, you're likely to oversimplify or get yourself into a quagmire that the BPMN spec has already dealt with.   After saying all that, I'm still on the fence about how BPMN-centric CACAO should be.  It is big and the full BPMN doesn't seem necessary and might deter adoption.  The desire for JSON is also incompatible, although a logical translation is possible (even if the JK posted isn't the one).   When we discussed this originally, I felt (like Allan T) that we could keep CACAO logically consistent with BPMN but limited to just the things we need.  I still think that's the best option, but am not sure if that's a new language or perhaps a BPMN subset realized as JSON instead of XML.   Allen Allen Hadden STSM & Chief Architect IBM Resilient w:   508-560-3502 e: ahadden@us.ibm.com      


  • 7.  Re: [cacao] Agenda for next Tuesday's call

    Posted 10-15-2019 12:05
    All I would personally more go for a programming language approach, This because my idea was a fully automated system. However following the discussion is seems that Cacao is more intended to automated the workflow, And not the actual actions. Just my opinion. Frans > On 15 Oct 2019, at 13:57, Allen Hadden <ahadden@us.ibm.com> wrote: > > +1 on BPMN combining the logical and graphical representation. The alternative is to display the logic tree logically, which might not be how people are actually thinking about the problem (and would be different for different implementations). > > Regarding translation to SOAR tools. We've done similar translations for our customers who had pre-existing BPMN diagrams and wanted to convert them into Resilient's BPMN. I think we may have actually done it for a JHU/APL example at some point too. The trick with BPMN and portability between SOAR tools are the model bindings. For example, if there's a condition (e.g. exclusive gateway in BPMN), on what variables is it acting? If there's a script, what variables can it read/write and functions can it call? If you can define the bindings, then achieving BPMN portability is achievable. > > Having spent 3+ years working with BPMN in SOAR, I can say confidently that has had an answer for all workflow problems we've encountered in customer use cases. It exposes many of the complexities that you encounter in process modeling. For example, the semantics for branching and joining are way more complicated in reality than most would initially expect. If you roll your own, you're likely to oversimplify or get yourself into a quagmire that the BPMN spec has already dealt with. > > After saying all that, I'm still on the fence about how BPMN-centric CACAO should be. It is big and the full BPMN doesn't seem necessary and might deter adoption. The desire for JSON is also incompatible, although a logical translation is possible (even if the JK posted isn't the one). > > When we discussed this originally, I felt (like Allan T) that we could keep CACAO logically consistent with BPMN but limited to just the things we need. I still think that's the best option, but am not sure if that's a new language or perhaps a BPMN subset realized as JSON instead of XML. > > Allen > Allen Hadden > STSM & Chief Architect IBM Resilient > > <Image.15235377696330.jpg> > w: 508-560-3502 > e: ahadden@us.ibm.com <Image.15235377696331.jpg> > > >